On Mon, 12 Dec 2005, Stephen Sprunk wrote:
It still doesn't make sense to send notification in any form other than a "5xx stuff your malware..." response.
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.
The majority of worms currently try to do direct-to-MX delivery, making this point moot. On the flip side, as to the "secondary MX issue", I won't comment but to say this: If the primary MX will reject mail for which the secondary MX will not, then wormspew is just one of many of the secondary MX's problems. (The problems with using "blind" secondary MXs in today's world have been discussed elsewhere at great length.) Now, a few worms are getting smarter about it by using the upstream's SMTP server. While it is likely true that this will still cause DSNs...
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.
...it does put the blame much closer to home -- as the DSN generator is very likely to be the same provider whose downlinks (often broadband home users) have been infected. The clustick can then be applied to folks who should be more capable of stopping the problem children, and escalation (if needed) will be more likely to attract the attention of the correct people. It also becomes a much bigger argument for proper implementation of SMTP AUTH at that point. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>