SMTP store and forward requires DSN for integrity

Sat Dec 10 23:51:37 UTC 2005

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