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