This is a multi-part message in MIME format.
From: Lars Dybdahl
Sent: Tuesday, April 20, 2004 6:17 PM
SPF _cannot_ validate that the sender of that message was
indeed the claimed sender.
SPF does not publish whether the domain owner prevents forgery of
e-mail addresses within the same domain, but that's not what SPF
is around to do. Please regard SPF in context with what it's
trying to do. SPF is not trying to save the world - actually, it
allows a certain degree of freedom in how to handle your e-mail
systems, both technically and administrative.
The more you want to check, the more complicated it gets. SPF was
designed for a simple task, and can therefore be kept simple.
There are many parameters in handling e-mails:
If you want to be 100% sure identity of a sender, you will need
digital signatures, and you will need certificates to ensure that
the digital signature actually belongs to the identity that you
expect. If you don't trust authorities, don't get your signature
from such one. If you want to communicate with digital signatures
with authorities, you will need to get your signature from such one.
Actually, what we have been talking about with SES is part way between SPF
and digital certificates, in terms of authentication. How does SES fit into
the continuum between normal, SPF and S/MIME validated email? The short
answer is that SES is part way between SPF and S/MIME. Here are a few
scenarios with SES to illustrate what it does and doesn't do.
1) The user authenticates themselves to the local MSA. The user submits a
message using their local account address as return-path. The MSA creates
an SES signed return path using a hash secret unique to that user (typically
the user's account password). The MSA passes the message to the outgoing
MTA for transmission. The message may or may not go through forwarding
hops. When the message reaches the final gateway MTA, that MTA does a CBV
to the MX for the domain in the return-path, which is the same as the
originating gateway MTA. The MTA receiving the callback first looks at the
domain and the local part, and if they exist it looks up the user's password
and checks the hash cookie. If the hash cookie matches, the MTA answers
with a 250, otherwise it responds with an error code. A 250 response tells
the MTA doing the CBV that the return path is in fact the user who validated
themselves to the MSA.
2) The user authenticates themselves to the local MSA. The user submits a
message using the local domain but with a local part that is not the same as
their local account address. In order for the MSA to accept the message,
the user's MUA must create an appropriate SES-signed return path using the
correct hash secret (the password for the other local account). The MSA
looks up the hash secret (user password) for the local part claimed and
attempts to verify the hash cookie. If it verifies, the MSA accepts the
message and passes it to the MTA for transmission. In order to create a
hash cookie that the MSA will accept for another local account, the user
must know the password for that account.
3) The user authenticates themselves to the local MSA. The user submits a
message using a foreign domain in the return path. In order for the MSA to
accept the message, the user's MUA must create an appropriate SES-signed
return path using the correct hash secret (the password for the foreign
account). The MSA does a CBV to the foreign domain with the SES return path
provided by the MUA. If it verifies, the MSA accepts the message and passes
it to the MTA for transmission. In order for the CBV to validate the SES
return path that the MUA created, the user must know the password for that
account at the foreign domain.
As you can see, this method allows the final recipient's MTA, or any MTA in
the message path, to verify that the return path claimed was created by
someone who knows the password (or hash secret, if they are different) for
that account. This is fairly good authentication, but not as good as
signing with a real digital certificate that is backed up by a reputable
certification authority. However, since it is just a simple signature that
is transmitted during the SMTP session, the recipient can verify it with a
CBV before DATA and decline the message if it does not validate.
In contrast, SPF can validate that the sending MTA is a designated sender
for the return path domain. If the SPF record uses 'exists' mechanisms for
all the domain users, the recipient can verify that the user name exists at
that domain and the sending MTA was a designated sender for that user name.
However, SPF cannot make any assertion that the author of the message had
the right to claim that user name. The local MSA may enforce that policy or
not. The SPF specification does not require this.
A S/MIME signed message gives you extremely high confidence that you know
who signed the message, that the return-path is accurate, that the From:
header is accurate, that the signer had the right to use those email
addresses and that the content has not been altered in transmission.
Neither SES nor SPF can accomplish all this without extensions. As far as I
know, the S/MIME signature does not assure that the user has the right to
use the address in the Reply-To: header. With that small exception, it is
excellent authentication, but it requires receiving the entire message and
checking with the PKI for certificate validation, revocation, etc. It is
expensive enough that this is normally left to the MUA.
If you want to kill spam 100%, you will need to define "spam"
extremely precisely. Please note, that e-mails on this list is
spam to some people, if they aren't clever enough to find out how
to unsubscribe to the list. Good spamfilters should be able to
filter away e-mails from this list for those people, while
letting it through to other people.
I'm not suggesting that any of these technologies will stop spam. SPF was
designed to validate the envelope-from address in a lightweight manner. I
am trying to show that an SES protocol can do a superior job of validating
the envelope-from address and can even do so from foreign MTA's without the
domain owner publishing anything. The MSA and MX already know, or can
easily find out, what they need to verify an SES return path. If it is a
local address, they already know the user password. If it is a foreign
address, they can do a CBV to the MX for the domain and ask it to verify the
SES signed return path provided by the MUA.
This won't stop spam, but it does tell you with high certainty that the
person sending the message had full rights to use that particular email
address in their return path. That's a stronger assertion than SPF can
make.
<...>
If you want a real-life e-mail system for many people, you will
have to compromise. What you are doing, is to describe some
characteristica of some technologies - but this doesn't change
the fact, that SPF will benefit a lot of e-mail systems at a low
cost, and is even able to give the early adopters immediate and
remarkable benefits.
I haven't seen anyone on this list claim immediate and remarkable benefits
from implementing SPF. It is a work in progress and it has great potential.
My argument is simply that there is an alternative that gives stronger
validation for the return-path, is more flexible, has a few ancillary
benefits (rejects bounce spam) and is easier to implement end-to-end. If
people are convinced that CBV's are too costly to the sending MTA, we can
work on the asymmetric crypto version that puts a public key for validation
in the DNS.
--
Seth Goodman