From owner-nanog@merit.edu Sat Dec 10 15:55:48 2005 Subject: Re: SMTP store and forward requires DSN for integrity From: Douglas Otis <dotis@mail-abuse.org> To: Andrew - Supernews <andrew@supernews.net> Cc: nanog@merit.edu 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: <fred@example.com>

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: <fred@example.com> 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/A237EDBA07@example.com> S: 250 2.1.5 <prvs=fred/A237EDBA07@example.com>... 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?