Re: [Asrg] 6. Proposals - Latest version of the LMAP discussion paper

[Markus Stumpf <maex-lists-spam-ietf-asrg@Space.Net>]

(Subject adjusted)

On Tue, Dec 09, 2003 at 04:02:07PM -0500, Alan DeKok wrote:
>   Comments and suggestions are welcome.  I have a little more time
> than I had a month ago, so I'm better able to discuss the document.

I am still not really happy with the forwarding issues, especially with

*> 5.1.16 Factor 4.5 (16), Mailing Lists
*>   Most current mailing list software rewrites the MAIL FROM, to permit
*>   bounces to be sent back to the mailing list administrator.  These
*>   lists will be unaffected by LMAP (other than the issues raised above).

This is not true. A lot of MLMs adopt VERP style senders, i.e. they use
    newsletter-bounces-maex=example.org@lists.example.com
This allows tracking of bounces across forwards:
If in the above example
    maex@example.org -> maex@example.net -> joe@example.com
and joe@example.com fails the bounce will go back to
    newsletter-bounces-maex=example.org@lists.example.com
and the bounce handler can easily detect that the failing subscribed address
is maex@example.org and remove that from the list.
This will no longer be possible with LMAP and envelope sender rewriting.

*>   However, commercial and proprietary mail-forwarding
*>   systems alter the sender envelope, and these are by far the most
*>   popular pure mail-forwarding instances.

What numbers can you base the "most popular" on?
Also it is *very* problemativ to alter the sender to the address of the
forwarder:
   a@example.com send message to b@example.com which forwards to
   c@example.org.
Now the mailserver at example.org notices that c@example.org ist over
mail quota. A bounce is sent back to the envelope sender. It is
important that the bounce is a fresh mail with fresh headers. The
original message may (or not) be attached to the bounce.

With the current Mail structure the bounce will go back to
a@example.com. End.

With envelope sender rewriting the bounce will be sent to b@example.com,
which will change the envelope sender to b@example.com and will forward
the message to c@example.org which is over quota so the mailserver will
generate a bounce to b@example.com which will change the ...
I think you get the point.
As the message is a fresh one no loop detection mechanisms will work:
not hop counting, not Delivered-To: checking, not Received: lines matching.

These kind of mailloops can only be broken by admins disabling the
forward from b@example.com to c@example.org, as every new eMail arriving
at b@example.com will trigger the problem immediately again until
c@example.org is working again.

I'm seeing this behaviour with MS Exchange forwarders *very* often with
customers using our mailserver as a relay. This gives me the possibility
to "save" the customer and break the loop. I've seen cases where such a
loop made > 10 GB traffic within an hour.

Forcing users to envelope rewriting will make this kind of errors occur
a lot more often that now, to I think this has to be mentioned as it will
have a large impact on Efficiency, Costs, Reliability.

Also rewriting the sender will stop bounces from being returned to the
real originator after they have been forwarded.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg