[Top] [All Lists]

Re: fix forwarding: sect. 3.9 of draft-klensin-rfc2821bis

2008-02-04 02:43:52

Frank Ellermann wrote:
Alessandro Vesely wrote:
| Because of its administrative relevance, this address MAY
| be used to devise local acceptance policies based on the
| While recognizing the existence of such policies, this
| paragraph only describes general issues intended for
| efficient and reliable transport and delivery of mail messages.

I'd remove that part, it is rather vague.  Of course the
MAIL FROM like anything else in the envelope can be used
for the decision to reject or accept a mail.  And as the
reverse path MUST be used to report non-delivery to the
originator it's arguably not only an option (MAY) to make
sure that it's no nonsense when accepting it.

I agree that having a reliable envelope sender is necessary for mail delivery reliability, even if that conflicts with current specifications and practices. However, what should an MTA do when it has a piece of spam with a faked return path?

In the context and notes for the draft, the spam problem is dismissed because its solutions change too rapidly. That situation somehow resembles the status of SMTP extensions. However, spam defense methods are _not_ quite similar to SMTP extensions. One key difference is that they alter the semantics of SMTP rather than altering the protocol. For example, viruses require an accept-and-discard approach to avoid bounces to yet another victim in the return path; large ESPs, e.g. Hotmail, discard legitimate mail in the same manner. Not mentioning that, IMHO, may put 2821bis beyond belief.

<Prev in Thread] Current Thread [Next in Thread>
  • Re: fix forwarding: sect. 3.9 of draft-klensin-rfc2821bis, Alessandro Vesely <=