North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: SMTP store and forward requires DSN for integrity
> From [email protected] Sat Dec 10 15:55:48 2005 > Subject: Re: SMTP store and forward requires DSN for integrity > From: Douglas Otis <[email protected]> > To: Andrew - Supernews <[email protected]> > Cc: [email protected] > Date: Sat, 10 Dec 2005 13:54:37 -0800 > > > On Sat, 2005-12-10 at 17:37 +0000, Andrew - Supernews wrote: > > > BATV doesn't help you if the problem is SMTP transaction volume, any > > more than a firewall will help you cope with a saturated network link. > > I agree with most of your statements. AV filters should be done within > the session when possible, etc. > > Your statement regarding BATV is not correct however. There are two > ways BATV reduces SMTP transaction volume when dealing with forged > DSNs. > > Previous return-path and real email-address: > <[email protected]> > > Is transformed by BATV with a private tag into: > prvs=fred/<KDDDSSSSSS>@example.com > > S: 220 mail.example.com ESMTP Ready > C: EHLO fred.example.com > S: 250-mail.example.com Hello fred.example.com > S: 250-ENHANCEDSTATUSCODES > S: 250-PIPELINING > S: 250-8BITMIME > S: 250-SIZE 20000000 > S: 250-DSN > S: 250-ETRN > S: 250-AUTH PLAIN LOGIN > S: 250-STARTTLS > S: 250-DELIVERBY > S: 250 HELP > C: MAIL FROM: <> > S: 250 2.1.0 <>... Sender ok > C: RCPT TO: <[email protected]> > S: 550 5.1.1 <fred.example.com>... User unknown > C: QUIT > > > When the MAIL FROM is <>, the only valid RCPT TO would be a BATV address > such as: > > ... > C: RCPT TO: <prvs=fred/[email protected]> > S: 250 2.1.5 <prvs=fred/[email protected]>... Recipient ok > C: DATA > S: 354 Enter mail, end with "." on a line by itself > C: This is a notification you sent a virus to <joe.tld> at ... > C: Blah, Blah, Blah, and by the way, here is the virus. ... > C: ... > C: . > S: 250 2.0.0 234fls89056789 Message accepted for delivery > C: QUIT > > The BATV is a few lines of code that adds a private tag with a time > limit set in days. BATV helps dramatically by eliminating the DATA phase > and all that is involved in handling messages. In addition, once BATV > becomes more widely deployed, the DSN refusal offers an alert about > accepting more such messages from that IP address. > > BATV will make forged DSNs a thing of the past, irrespective of where a > recipient list is checked, an AV or SPAM filter is added, etc. TWO FACED, DOUBLE STANDARD, "SPEAKS WITH FORKED TONGUE". BATV has the risk of false-positive detection of an 'invalid' DSN. All it takes is a remote mail system that keeps 'trying' to deliver to a tempfailing address for _longer_ than the lifetime of that 'private tag'. Congratulations, you have just blocked a *valid* DSN failure notice. Your approach has just demonstrably 'impaired the integrity of the email system'. Strange, isn't it, that your "solution" will do exactly what you insist is utterly unacceptable behavior for any other approach. Remember, the putative sender (the person, not the software) is the best judge of whether or not that NDR is a delayed response to a message they sent. Why not take advantage of that superior knowledge?