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.