In <20050614051501.GA15450@xxxxxxxxxxxx> Walter Dnes <waltdnes@xxxxxxxxxxxx> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf