From: Stuart D. Gathman
Sent: Wednesday, July 06, 2005 4:30 PM
<...>
A harvested reverse-path is only marginally useful for current bulk
spamming practice. However, it is extremely useful for someone who
wants to impersonate me. That is why BATV and (original) SES are
great for blocking forged mail, but no good for authentication.
In other words, I don't want someone to get an email ostensibly from
me with a signed header that says it is really from my server, but
in reality it is not me, but anyone who got an email from me in the
last few hours, or controls a zombie that got such an email.
A harvested SES return path protects a body hash that will not match any
other message body but the one it was originally sent with. Therefore, it
is not useful to create forgeries. All you can do is send an identical copy
of the original message to the same recipients, and if they use SPF, even
that would be rejected. With the body hash strictly enforced, SES actually
_is_ good enough for authentication of normal email.
Now, I know the body hash in not a complete panacea in all cases, but it is
for all the important ones. The only cases it doesn't handle well are:
1) authenticating the original sender after remailing through a mailing
list, and
2) authenticating the original sender if any forwarders alter the message
body.
Neither of those are serious limitations. Let me give a little more detail
as to why I believe this.
First, consider mailing lists. They are not high security distribution
channels to begin with. They can certainly do SPF checks upon receipt of
posts and will hopefully reject on non-registered users. The mailing list
typically adds some information to the message body and substitutes its own
MAIL FROM before distributing the post. If they care to use an SES return
path, any recipient can validate that the message did come from the mailing
list even in the presence of the recipient's forwarders. To the extent that
you trust your mailing lists to validate incoming posts, you can trust the
claimed identity of the poster. Though not perfect, this is more identity
validation than you get with mailing lists today. Impersonation forgeries
in mailing lists do not seem to be a serious issue. If you need better
identity assurance than this, posters can use in-line PGP or some other
persistent signature scheme.
Next, consider forwarders changing message content. The extent that they
change the message body determines whether or not the SES body hash will
validate at the recipient. There was a lot of debate within the SES
project, as well as the DK/IIM group, about how to best do message
canonicalization at the recipient in order to survive typical changes at
forwarders. The bottom line is that for multi-part MIME messages, you can
probably get away with changing content-transfer encoding but not much more.
The limitation is on how permissive message canonicalization can be at the
recipient without making it prone to accept forgeries.
Adding text to the message body or rearranging MIME parts will break it, as
it should. If a forwarder is changing the message content, they should
probably stop pretending they are a forwarder and start acting like a
remailer. This means they use their own MAIL FROM instead of the original
sender's. Since they have changed the message content, this is appropriate.
Most of the debate about canonicalization, as it turns out, had to do with
the case of validating 2822 addresses after mailing list distribution or
forwarders that add content to the message. I now think that was a red
herring and we should not have gone down that path at all. The primary
purpose of SPF is to prevent 2821 address forgery and SES can solve the
forwarding problem inherent in SPF. We can use other mechanisms later to
deal with 2822 addresses.
--
Seth Goodman