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

Joe Maimon jmaimon at ttec.com
Fri Dec 9 20:24:22 UTC 2005




Douglas Otis wrote:

> 
> 
> 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.

Near enough so that reject at SMTP data phase will cover all legitimate 
cases that may exist.

> 2) Lack of DSN for email falsely detected containing malware is okay.

1 dropped email is NOT worth thousands of to-forged addresses DSN's

The admins that care will design their systems to reject by smtp DATA pohase

> 3) Purported malware should be assumed to use a forged return-path.

Yup, thats true of everything in the wild today.

> 4) The return-path can be validated prior to accepting a message.

Exactly, only then is DSN's acceptable to otherwise near guaranteed 
incorrect destinations.

> 5) SMTP should appear to be point-to-point.

Obeying the SMTP standard should not generate crap unneedlessly.

That means reject virus at data phase, discard them afterwards since the 
DSN violated the much more important rule not spewing crap at innocent 
3rd parties.


> 6) MTAs with AV filters are the only problem.

To generalize it:

Systems which generate DSN's to known incorrect destinations are the 
EXACT problem discussed here. Currently that fits all "scan after 
receipt of messafe" av systems that send DSN's

> 
> 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.

I havent been keeping on top of the sender/return path verification scene.

But blacklisting abusive systems to create pressure on admins to turn 
the spewage off is the current time honored mechanism.


> 
> If you can't trust AV handling of DSNs, why trust their detections?

One is fairly easy to measure. The other SHOULD be fairly easy to turn off.

> 
> Would you rather see emails simply disappear?

I would rather my MTA return the DSN it generates when it receives your 
MTA's smtp rejection to the data command contents.

> 
> 
>>    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.

Blocklisting them should even things out eventually.

> 
> -Doug
> 
> 
> 
> 
> 
> 



More information about the NANOG mailing list