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

(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
    [email protected]
This allows tracking of bounces across forwards:
If in the above example
    [email protected] -> [email protected] -> [email protected]
and [email protected] fails the bounce will go back to
    [email protected]
and the bounce handler can easily detect that the failing subscribed address
is [email protected] 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:
   [email protected] send message to [email protected] which forwards to
   [email protected].
Now the mailserver at example.org notices that [email protected] 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
[email protected]. End.

With envelope sender rewriting the bounce will be sent to [email protected],
which will change the envelope sender to [email protected] and will forward
the message to [email protected] which is over quota so the mailserver will
generate a bounce to [email protected] 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 [email protected] to [email protected], as every new eMail arriving
at [email protected] will trigger the problem immediately again until
[email protected] 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"