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

Mon Dec 12 14:18:07 UTC 2005

> 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
is not UBE because a 3rd party is not involved. Of course,
the sending MTA may not accept incoming sessions and your
queues may fill. But, if you record the MTA that passed
you the message, then your post-processing applications have
a right to send whatever notifications they want to that
MTA owner. The MTA owner *IS* directly involved in the 
incident in question since the SMTP session originated 
on their server. The owner can take direct action to stop
the virus transmissions by filtering, changing server
config, stopping the source or setting up an ACL to block
rogue mail servers on their network.

This whole discussion centered around the fact that
innocent 3rd parties with no ability to act, were being
sent large volumes of notifications. Once you remove the
innocent 3rd party from the equation, the shape of the
problem is quite different.

I agree that notices should not be sent to addresses that
are likely to be forged because then innocent 3rd parties
are being spammed. However that does not mean that all 
notifications are bad.

--Michael Dillon