SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )

Fri Dec 9 21:35:55 UTC 2005

----- Original Message ----- 
From: "Douglas Otis" <dotis at mail-abuse.org>
To: "Todd Vierling" <tv at duh.org>
Cc: "Steven J. Sobol" <sjsobol at JustThe.net>; "Geo." <geoincidents at nls.net>; 
<nanog at merit.edu>
Sent: Friday, December 09, 2005 1:58 PM
Subject: Re: SMTP store and forward requires DSN for integrity (was 
Re:Clueless anti-virus )

>
>
> On Dec 9, 2005, at 10:15 AM, Todd Vierling wrote:
>>
>>    1. Virus "warnings" to forged addresses are UBE, by definition.
>
> This definition would be making at least two of the following 
> assumptions:
>
> 1) Malware detection has a 0% false positive.
> 2) Lack of DSN for email falsely detected containing malware is okay.
> 3) Purported malware should be assumed to use a forged return-path.
> 4) The return-path can be validated prior to accepting a message.
> 5) SMTP should appear to be point-to-point.
> 6) MTAs with AV filters are the only problem.
>
> While there could be best practices created for AV filtering, it  seems 
> unlikely to be effective.  Simplistic filters for DSNs also  seem counter 
> to ensuring the integrity of email delivery.  Defending  against DSN 
> exploits with BATV will remove this vector, which in turn  will end DSN 
> exploits attempts over the long term.  Why expect others  to fix this 
> problem, when there is a solution that one could make the  investment in 
> to deploy.  This will reduce this problem over the long  term.  The BATV 
> alternative would not cause otherwise valuable DSNs  to be lost, nor make 
> assumptions about the quality of malware detection.
>
> If you can't trust AV handling of DSNs, why trust their detections?
>
> Would you rather see emails simply disappear?

I would rather see the problem stop at the source instead of the current 
issue being used as a crutch to attempt to get people to go to BATV or 
Mass-Rep (as described in your draft).  There's an old military comm saying 
that fits perfectly here. "Clean House". For those of you ex comm folks, 
you'll probably recognize it. For those of you who don't, it simply means, 
fix your stuff before you point blame at the distant end for the problem.

>>    2. It is the responsibility of the *SENDER* not to send UBE.
>
> When the recipient is a legitimate email provider, it could seriously 
> lower the integrity of email delivery for these providers to toss  DSNs 
> because many fall into a category you want to define as UBE.   While I 
> agree whole heartily this malware notification problem  stinks, there is a 
> much safer and surer solution.
>
> -Doug

Do you not comprehend what's really being said here Doug? Yes, blocking / 
rejecting of a DSN is a BAD thing and should never be done. Rejecting of a 
notification of malware != the same thing.  If the reciever of "your" DSN 
didn't sent the message, then it's no longer a DSN.. It's now officially, by 
definition, UBE from YOU to the incorrect originator now isn't it. This is 
the case in the majority of malware notifications by anyone / anything that 
generates them. More than likely, the viri / trojan writer is "depending" on 
them to help propogate their ilk because they too can be network admins and 
are aware that DSN's don't get tossed. What better method to get them out to 
the masses but to have our main feeds, and huge pipes help them along? I 
mean, really, who's better to help them? Mom and dat with the 56k dialup or 
us with the DS3's - OC12's to help them along? Look at the big picture Doug 
instead of 45 degrees to the left and right. You hate spam, I hate spam, I 
don't send DSN's to senders because I know that roughly 90% of them are 
bogus.  You feel that's bad. You have the right to disagree. I have the 
right to deny traffic that is in response to traffic that didn't originate 
from my network(s) regardless of your belief.

Mike P. 