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)

  • From: Stephen Sprunk
  • Date: Mon Dec 12 13:05:33 2005

Thus spake "Per Heldal" <[email protected]>
On Mon, 12 Dec 2005 14:18:07 +0000, [email protected] 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