Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

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-virusproducts/vendors)

  • From: Todd Vierling
  • Date: Mon Dec 12 07:57:26 2005

On Mon, 12 Dec 2005, 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 <> <> <>

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.