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...
Email Rejection Practices
Many emails are unwanted advertising, viruses, worms, and other
malware. They almost always have forged headers showing innocent 3rd
parties as the sender. Many MDAs and receiving MTAs administratively
block emails that are believed to be in those categories. This document
does not comment on or recommend specific criteria for rejection of
emails. Its recommendations concern the rejection mechanism used by
receiving MTAs and MDAs in order to minimize negative consequences for
innocent 3rd parties. Best practices are:
* Where ever possible, rejections SHOULD be an smtp-stage 5xx message,
before the receiving MTA issues the final "250 Ok" to the DATA
transaction, rather than a bounce. The rejection MAY occur as early
as the HELO stage, or TCP/IP traffic may be blocked from particular
sources, at the discretion of the system owners.
* 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.
--
Walter Dnes <waltdnes(_at_)waltdnes(_dot_)org>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf