North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Recording the return path (was Re: Clueless anti-virusproducts/vendors)
- From: Todd Vierling
- Date: Mon Dec 12 13:40:56 2005
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
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
-- Todd Vierling <email@example.com> <firstname.lastname@example.org> <email@example.com>