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:Clueless anti-virus )

  • From: Douglas Otis
  • Date: Fri Dec 09 18:10:06 2005 
On Dec 9, 2005, at 1:12 PM, Todd Vierling wrote:

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.
This is a third-party acting in good faith, albeit performing a check better done within the session. In your view, there is less concern about delivery integrity, and so related DSNs should be tossed. Being done within the session would be ideal, of course. When their architecture does not support this approach, you want them to toss the DSNs, because you _think_ the number of otherwise valid DSNs to be inconsequential (whether or not malware is actually detected).

Where do you draw the line, as AV filtering is not the only source of a spoofed DSN problem?

How would the third-party acting in good faith know who really sent the message?


(Do you know what "cost shifting" means, and why it's considered bad, and why it is illegal in some forms?)
In this case however, it is in keeping with a general expectation that a DSNs will be sent when a message can not be delivered. If this party wanted to save costs, they would toss the DSN.

How can this entity know whether the DSN is going to the correct party?

How can this be called cost shifting?


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.
This is a remarkable argument. DSNs with spoofed return-paths will not go away even after getting all the AV filters performed within the session sometime in the few years. In fact, in session filtering will likely increase costs related to email by making all exchanges take longer to complete. BATV can refuse invalid DSNs before the data phase, after expending a few microseconds to make and check tags. The cost savings provided by a BATV approach can be rather large which will only increase the scalability of email.

-Doug