In <20041122041855(_dot_)13AF1590103(_at_)radish(_dot_)jmason(_dot_)org>
jm(_at_)jmason(_dot_)org (Justin Mason) writes:
wayne writes:
Even a straight replay can be a problem. [...]
hmm. if the message was sent from webmail.com to goodrecip.com, then the
signed message was spammed via proxy.com to spamee.com, as far as I know
the message headers would look like this:
Received: from ... by spamee.com;
...
Received: from [forged] by proxy.com;
...
Received: from webmail.com by goodrecip.com;
...
Minor point: The spammer could easily remove or modify the above
trace headers, hideing goodrecip.com.
Whatever-Signature: ....
Received: from [injection address] by webmail.com;
From: spamtest /at/ webmail.com
Subject: [...]
[...body]
So in other words, 'Whatever-Signature:' covers the stuff from there
down.
Yes.
hmm, you might be on to something there, that does indeed seem to be a
replay attack that can be used to deliver spam.
But note that the From: header can't be changed, so webmail.com can
whack the spamtest account (after verifying the reports are legitimate
and not designed just to get a legitimate account whacked).
webmail.com can probably use signup information to help trace back who
spamtest is. They might even leave to spamtest account open for a
while to investigate who is using it.
Also, if the crypto system has a way of saying "all mail from
mybank.com" is signed, then spammers/phishers can't forge the From:
header with that domain at all. (Well, assuming that the MUA doesn't
make the pretty name look like the email address.)
Another thing to consider is that if webmail.com publishes SPF
records, the proxy.com replaying the emails can not use a
2821.MAILFROM of webmail.com. They could use proxy.com in the
2821.MAILFROM, but then it wouldn't match the 2822.From: header. This
mismatch between the 2821 and 2822 identities isn't the norm and can
be used as a spam sign.
Times when the 2821.MAILFROM and 2822.From: legitimately don't match
are generally things like mailing lists, when a users routes email
through a forwarder that does SRS, or when the sender uses SES. The
first two tend to not change often, for a given recipient. That is,
most people don't sign up to lots of new mailing lists or use
forwarding services every day. In the case of a sender who uses SES,
the domains will still match, even if the local parts don't.
So, the legitimate cases where there is a mismatch can often be
detected, which can make the mismatch an even stronger spam sign.
From what I can see, crypto systems are not a Final and Ultimate
Solution to the Spam Problem. It can, however, be useful when you
understand the limits.
-wayne