(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(_dot_)org(_at_)lists(_dot_)example(_dot_)com
This allows tracking of bounces across forwards:
If in the above example
maex(_at_)example(_dot_)org -> maex(_at_)example(_dot_)net ->
joe(_at_)example(_dot_)com
and joe(_at_)example(_dot_)com fails the bounce will go back to
newsletter-bounces-maex=example(_dot_)org(_at_)lists(_dot_)example(_dot_)com
and the bounce handler can easily detect that the failing subscribed address
is maex(_at_)example(_dot_)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(_at_)example(_dot_)com send message to b(_at_)example(_dot_)com which
forwards to
c(_at_)example(_dot_)org(_dot_)
Now the mailserver at example.org notices that c(_at_)example(_dot_)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(_at_)example(_dot_)com(_dot_) End.
With envelope sender rewriting the bounce will be sent to
b(_at_)example(_dot_)com,
which will change the envelope sender to b(_at_)example(_dot_)com and will
forward
the message to c(_at_)example(_dot_)org which is over quota so the mailserver
will
generate a bounce to b(_at_)example(_dot_)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(_at_)example(_dot_)com to c(_at_)example(_dot_)org, as every new
eMail arriving
at b(_at_)example(_dot_)com will trigger the problem immediately again until
c(_at_)example(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg