On Fri, 9 Dec 2005, Douglas Otis 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.
None of these are my problem. I am a non-involved third party to the malware detection software, so I should not be a party to its outgoing spew. I have not requested the virus "warnings" (unsolicited), they are being sent via an automated trigger (bulk, by extension of the viruses also being bulk), and they are e-mail -- UBE by definition. Whether they are also formatted as DSNs or delivered like DSNs doesn't take away their UBE status. If you want to notify someone about a filtered malware instance, notify the intended *recipient*, and provide that user with the email address of the alleged sender. If it's a false positive, the intended recipient of the filtered mail can contact the other party to fix the situation. Oh, but I know the response already: "But our users don't want to see those notices, they're not much better than the viruses getting through, all that spam to delete." And an otherwise non-involved third party should be burdened with this crap because...? (Do you know what "cost shifting" means, and why it's considered bad, and why it is illegal in some forms?) The more important part is that the afflicted products usually DO know the forgery status of the malware it is detecting -- so there should be nearly no question as to when "warnings" would be UBE. That notwithstanding, the probability of a forgery case is better than 99%, so the assuption for anti-malware products should now be "forged unless proven otherwise". Hell, I'd give that forgery probability a Five Nines these days.
5) SMTP should appear to be point-to-point.
There are ways to limit the scope of this problem as it applies to non-virus-warning bounces, without going to direct point to point delivery. There are schemes by which a 5xx reject can propagate up a delivery path without requiring a bounce to be generated. *This* is the direction SMTP should be headed, and it need not be forcibly point to point. This too is irrelevant when considering the Five Nines probability above.
6) MTAs with AV filters are the only problem.
Not the only problem, but they are currently taking up the vast majority of the problem space of blowback UBE instances. They aren't always constant, but when a worm surge starts, the blowback floods.
Defending against DSN exploits with BATV will remove this vector, which in turn will end DSN exploits attempts over the long term.
Besides this being another rewording of the classic "victim must fend for him/herself" mantra, and a complete misrepresentation of the problem of scale in implementing BATV the way you describe, you're calling these "DSN exploits" -- not "DSNs" -- here. Maybe the clue is finally sinking in? Naaaah:
If you can't trust AV handling of DSNs, why trust their detections?
You can claim that these virus "warnings" are DSNs all you want. Just like politicians' talking points, just saying it a lot doesn't automatically make it true. Prove it, to wit: Since I never sent the original virus-worms that triggered the UBE in question, exactly how is one of these virus "warnings" is a *valid* DSN, and not UBE...? (Here's a hint for the boys and girls at home: DSNs are supposed to go to the real, original sender.) If the general case for e-mail borne viruses weere non-forged senders, I could buy the DSN argument. But that's not the general case at all.
While I agree whole heartily this malware notification problem stinks, there is a much safer and surer solution.
Yes, there is: Notify the intended recipient of the virus, not the (almost surely forged) sender. Don't cost shift the burden onto third parties, and don't try to rebrand spew that *never* hits the real original sender as some kind of "DSN". "Paging a T. Roll to the white courtesy clue-phone...." -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>