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 )
On Dec 9, 2005, at 1:12 PM, Todd Vierling wrote:
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?
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.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.