On Mon, 12 Dec 2005, Michael.Dillon@btradianz.com wrote:
No information you can collect from the SMTP-session or elsewhere can ever compete with the accuracy in notification gained if you reject the message in-line and leave the responsibility for sender-notification with the sending MTA.
On the other hand, sending the DSNs back to the sending MTA
That is contradictory. The sending MTA is known to be presenting a forged return path, but a DSN is defined as being sent to the presented sender address at the original MTA location. Thus any such notifications are not DSNs by definition. (Read RFC1894 for context, and note that virus-worms do not implement RFC1891 ORCPT -- nor should you ever expect them to do so.) In the case of virus-worm spew, there is better than 99% chance that there is no inbound MTA on port 25 of the connecting host. What's the point of generating an illegitimate DSN if no one will see it anyway? Again, we circle back around to 5xx in-band errors as the only way, that is usable in non-theoretical environments today, to provide virus rejection notifications. In lieu of rejecting in-band, an admin of such a broken product should follow a two-step process: 1. Drop viruses into the bit bucket without notification; and 2. Look for a product that can reject in-band, and switch to it. The days of multihop MTAs are coming to a close. In-band error signaling is used by nearly every other protocol commonly used on the Internet today; SMTP shouldn't be considered all that different anymore. The MUA and MDA leaf roles have clearly defined separation from the MTA infrastructure, and MTA-to-MTA communication should be perfectly capable of in-band error signaling in the modern Internet. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>