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

Mon Dec 12 17:49:53 UTC 2005

Thus spake "Per Heldal" <heldal at eml.cc>
> On Mon, 12 Dec 2005 14:18:07 +0000, Michael.Dillon at btradianz.com said:
> [snip]
>> 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.
>
> It still doesn't make sense to send notification in any form other
> than a "5xx stuff your malware..." response. Any MTA-admin with
> half a clue seeing lots of such in the logs for outbound messages
> should know what to do.

You think they'll notice, much less act on those logs?

The sending MTA, provided it's not the malware or spam software itself, will 
simply read the in-band 5xx and send a DSN to the forged originator.  This 
moves the error closer to the source, but the result is still that the 
innocent third party still gets a DSN for mail they didn't send.  I fail to 
see how this is a meaningful improvement.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking 