Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

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:Cluelessanti-virus )

  • From: JC Dill
  • Date: Fri Dec 09 21:34:36 2005

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






Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.