I don't think it is an easy task to find information to add to the
hash.
offhand:
- subject field (perhaps truncated to XX bytes)
- message body
- source IP address and port
- precise date/time (not the Date header field)
- *maybe* some form of the envelope recipient list
But all of this can be used for replay attacks. Get an account at
big-email-provider-1 and send the spam mail to your address at
big-email-provider-2.
either you strip off the originator-id field after it arrives at
big-email-provider-2, or you don't.
if you don't strip it off, then the original originator-id is still
there, and it associates your spam with your account at
big-email-provider-1.
if you do strip it off, another originator-id field gets added by
big-email-provider-2, and your spam gets associated with that account.
either way, the spam is traceable to an account that is associated with
you. recipients of the message can complain to whichever ISP issued
the originator-id field, and that ISP will figure out pretty quickly
that you're a spammer, and blacklist you. when other recipients
inquire about that originator-id (or even a different originator-id
that maps to the same account), they'll find out that you're
blacklisted.
Take the message and reinject it via a proxy
server by adding a fake Received: line and using a faked envelope
sender
to make it look like a forward and a consitent chain of mailservers.
You can use the same message some thousand times with any of some
thousand open proxy servers and for any envelope recipient you like
(replay attack).
if I understand what you're saying, it shouldn't matter. the number
of hops that the message takes, and the depth of branching in the tree,
should be irrelevant. what really matters is that you can't claim that
you didn't send the message.
the real trick is to prevent the other kind of attack - some miscreant
wants to discredit some vendor, so they take a single message that the
vendor sent legitimately and re-send it to a few million people. we
need to make sure that the message is traced to the miscreant, not the
vendor.
With Bcc mimic and multiple RCPT TOs in one stream it might be
dangerous
or impossible to use some form of the envelope recipient list.
there are a number of problems with using the recipient list. that's
why I said "maybe".
Keith