SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )

Fri Dec 9 23:08:49 UTC 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