SMTP store and forward requires DSN for integrity

Sun Dec 11 13:47:02 UTC 2005

I agree with nearly all of your analysis, but want to add
a few small points of my own.

On Sun, Dec 11, 2005 at 04:53:03AM -0600, Micheal Patterson wrote:
> Can BATV correct this? Possibly. 

After reading further and thinking about it: I believe the
answer isn't "possibly", but "almost certainly not".

Consider the ~100M zombies (hijacked Windows systems) out there.
Mail traffic emitted by any malware resident on them is externally
indistinguishable from mail traffic emitted by their former owners
(operating under the misconception that it's still "their" computer).

Nos suppose for a moment that we had Email Magic Bullet Technology
(EMBT) which enabled us to trace any/all messages back to their origination
point.  And suppose that 100,000 sites out there (using some form
of reliable malware detection) independently using EMBT conclude that
they have received copies of the Microsoft Windows virus du jour from
user at example.com at IP address 1.2.3.4.  Thus all 100,000 sites are
now in a position, if they wish, to emit a DSN addressed to user at example.com
stating "you have virus blah blah version blah blah" etc.

My first observation is that emitting these DSNs, even *with* EMBT,
is a pointless exercise.  Doing so increases, yet again, the volume
of useless mail traffic traversing the Internet.  It's just more
self-promoting spam from AV vendors -- it's not like anyone actually
_reads_ this stuff.  And even if they did: who's going to read
100,000 messages?

My second observation is that the combined volume of these DSNs may
constitute a rather effective DDoS on example.com's MXs.

My third observation is that such DDoS attacks could easily be redirected
against third party mail servers by manipulation of MX records.

4. (I got tired of saying "my Nth observation")  I'm beginning to
conclude that any technology which causes A, in response to traffic
from B, to generate traffic to C, is probably not a good idea.

5. Keep in mind that malware resident on a hijacked system is in complete
control of the box and thus has access to any cryptographic keys in use
as well as any incoming mail being retrieved with POP/IMAP.  So even if
we presume the existence of a clueful and attentive user (then why is
the box in a hijacked state?) there is no guarantee that the DSNs will
actually be presented to the user.

6. How is a recipient of a DSN to know that it's authentic?  After all,
the fact that EMBT enables someone to generate a DSN in response to
received virus-contaminated traffic doesn't prevent anyone else from
generating a DSN in response to...nothing.  Consider a piece of malware
which generates such DSNs and its impact on an EMBT.

7. All of the problems cited above become much more interesting if
the hijacked box isn't an end-user system, but a mail server.

8. (similar to observation 4) Adding more positive feedback loops
to an Internet-wide mail system that already carries far too much
junk traffic is a bad move.  We need to dampen, not amplify.

---Rsk