Douglas Otis wrote:
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,
No it isn't. This is a third-party acting in their own interest with absolutely zero concern for how their actions affect others. The third party WANTS to return the DSN so it can advertise its filtering service. There is NO other possible reason or excuse for this. The third-party obviously has a vested interest in justifying and continuing this reprehensible behavior.
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).
We KNOW the percentage of valid DSNs tossed by this action will be 0, or very very very close to 0. We know that if there were a significant percentage of DSNs that were desired by the "sender" then it would be just as easy for you to give those DSNs to the purported recipient so that they can notify the "sender" themselves. If the purported recipient doesn't want to see the DSNs because the false positive rate is 0 or close to 0, then you can be quite sure that the "senders" (most of whom never "sent" the message) certainly don't want to see them either.
Where do you draw the line, as AV filtering is not the only source of a spoofed DSN problem?
Because other systems aren't perfect is not an acceptable reason to let your system continue to do bad things.
How would the third-party acting in good faith know who really sent the message?
If the filtering system has any knowledge (or *should* have such knowledge) regarding the message received to indicate that the sender is forged, then it should not send a DSN to the sender address. Period. It should either discard the message and not generate a DSN or it should give the DSN to the purported recipient. If the purported recipient doesn't want to get a notice, then the system shouldn't inflict the notice on anyone else either.
(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.
And lose the opportunity to market their product in the guise of sending a "desired DSN" to someone whose address they are 99.999% certain was forged by the virus? We all know that email marketing is very low cost (low cost mostly due to cost shifting, as noted above) so they would have to replace this low cost marketing technique with real marketing at a much higher cost.
How can this entity know whether the DSN is going to the correct party?
See above.
How can this be called cost shifting?
See above.
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.
No, they will go away by dropping DSNs on the floor when there is a high likelihood that the sender is forged. jc