North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
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:
Near enough so that reject at SMTP data phase will cover all legitimate
cases that may exist.
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.
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.
Exactly, only then is DSN's acceptable to otherwise near guaranteed
4) The return-path can be validated prior to accepting a message.
Obeying the SMTP standard should not generate crap unneedlessly.
5) SMTP should appear to be point-to-point.
That means reject virus at data phase, discard them afterwards since the
DSN violated the much more important rule not spewing crap at innocent
To generalize it:
6) MTAs with AV filters are the only problem.
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
I havent been keeping on top of the sender/return path verification scene.
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.
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.
I would rather my MTA return the DSN it generates when it receives your
MTA's smtp rejection to the data command contents.
Would you rather see emails simply disappear?
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.