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 (was Re:Cluelessanti-virus )

  • From: Joe Maimon
  • Date: Fri Dec 09 15:26:49 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