Recording the return path (was Re: Clueless anti-virus products/vendors)

Mon Dec 12 14:50:06 UTC 2005

On Mon, 12 Dec 2005, Michael.Dillon at 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 at duh.org> <tv at pobox.com> <todd at vierling.name>