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

Todd Vierling tv at duh.org
Mon Dec 12 18:37:58 UTC 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
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 at duh.org> <tv at pobox.com> <todd at vierling.name>



More information about the NANOG mailing list