North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Recording the return path (was Re: Clueless anti-virus products/vendors)
Thus spake "Per Heldal" <firstname.lastname@example.org>
You think they'll notice, much less act on those logs?On Mon, 12 Dec 2005 14:18:07 +0000, Michael.Dillon@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.
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.
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