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 07:57:26 2005
On Mon, 12 Dec 2005, Michael.Dillon@btradianz.com wrote:
> > > This assumes all messages are rejected within the SMTP session.
> > Yes, exactly and the point several of us have been making is that
> > this is (a) easy (well, provided you're using a quality MTA; if not,
> > then switch to one) (b) running a sane mail system (c) fast
> > (d) resource-friendly and
> >(e) most important of all, the _only_ way to
> > avoid sending UBE in response to forgeries (which are not going away
> > any time soon or quite possibly ever).
> Not quite the only way. If a postprocessing step is needed,
> it is trivial for the SMTP server to record any return path info
> that it knows in order for the post-processor to be able to
> send DSN's as accurately as the SMTP server itself.
The point is not to send a DSN *at all* for virus-based rejections, because
doing so even at the SMTP server level will still result in UBE to a forged
original sender address. The return path is *known* to be invalid, so it
doesn't matter where you put the DSN generator; it will still send spew to
an uninvolved third party.
Rejecting with 5xx during the SMTP transaction does not have this undesired
behavior. In that case, the connecting MTA, which should have a much better
idea of who sent the virus-worm instance, receives the rejection in-band.
-- Todd Vierling <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>