In <20050614051501(_dot_)GA15450(_at_)waltdnes(_dot_)org> Walter Dnes
<waltdnes(_at_)waltdnes(_dot_)org> writes:
The above draft concentrates on actions of MTAs sending email. I wish
to add a section regarding actions of MTAs receiving/rejecting email.
My proposed addition is as follows...
[snip]
[....] Best practices are:
* Where ever possible, rejections SHOULD be an smtp-stage 5xx message,
Yes, I highly agree with this
* Where the email is determined, by the receiving MTA to be a virus,
trojan, or other malware, it MUST NOT be bounced to envelope-sender
or any alleged sender listed in the headers. The receiving system
MUST NOT send any email notice-of-malware-detected to the envelope-
sender or any alleged sender listed in the headers. The receiving
provider MAY send a summary, no more than once a day, to the abuse
or postmaster or security contact listed in whois as being
responsible for the actual IP address that sent the malware.
* Where the email is determined, by the receiving MTA to be unwanted
promotional email (colloquially known as "spam"), it SHOULD NOT be
bounced (DSN) to envelope-sender or any alleged sender listed in
the headers.
I can't support these two as written. In particular, there has been a
lot of work done recently on sender authorization/authentication
systems, such as DomainKeys, SPF, SenderID, CSV, etc.
The problem with not sending bounces is that if an email is
misclassified, then neither the sender nor the recipient knows that
the email was dropped.
Maybe adding a phrase like "The envelope-from should be assumed to be
forged unless it can be determined otherwise."
Also, you shouldn't be sending DSN to anything other than the
envelope-from anyway, a point that is important enough to stress in
and of itself.
/me curses the number of out-of-office messages he gets by posting to
various mailing lists.
-wayne
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf