|
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)
On Mon, 12 Dec 2005, [email protected] 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 <[email protected]> <[email protected]> <[email protected]>
|