John Levine wrote, On 1/20/09 9:53 AM:
[...]
Why do you keep harping on SPF? Of all of the proposed security
schemes on offer, it is by far the worst. It doesn't even attempt to
secure any part of the message visible to recipients, and it only
works for the subset of mail that is sent from a fixed point to
recipients who don't remail or forward it. (Despite endless claims by
SPF's fans, that last part is a fundamental design failure of SPF, not
of the mail system.)
I should preface this by saying that I deeply regret my public and private
discussions of the embryonic source concepts that spawned SPF and Sender-ID
and if in any way I helped evangelize a single SPF fan in my 2000-2004
delusional state, I am terribly sorry and beg forgiveness. I was so wrong.
My only excuse is that a lot of other smarter and/or more influential people
were also wrong...
The reason that SPF is here to stay is that it is good enough authentication
for most of the mail that most receivers and senders care the most about. A
lot of people get significant quantities of mail they care about via
forwarding systems or have to send through paths that can't get them a SPF
'+' anywhere that matters without +all, but we are a minority. Legitimate
bulk senders, consumer retail ISP's, and non-bulk business mail senders can
all make their outbound mail pass SPF at their border, and the largest (i.e.
consumer ISP) and pickiest (i.e. corporate) receiving systems can get some
benefit by using SPF in some way on some of their incoming mail. The people
who encounter significant breakage in SPF are an elite class, including a
large fraction of the people who actually work with mail technology directly
(i.e. *US*) but having created this breakage with our eyes open and having
given the masses a tool that mostly works for them, we are stuck with SPF
until something that works significantly better for them with similar or
less effort can replace it.
DKIM at least starts to address those problems, but it still doesn't
begin to try to deal with the much harder problem of lookalike
domains. Let's say you get a message from security(_at_)pay-pal(_dot_)com,
which
is 100% DKIM, SPF, and Sender-ID approved. Is that Paypal? How can
you tell short of manually looking up WHOIS registrations?
Which is half of why DKIM is not a SPF-killer. It shares a key gap with SPF
that actually makes a difference to the masses: some way to tell whether an
authenticated sender is actually a good sender. The other half is that it is
significantly harder to deploy on both ends. The fact that it is more
robust than SPF when dealing with mail that takes interesting paths can't
make up for the big gap: it is only an authentication tool, and the
authentication only goes as far as demonstrating the cooperation of a mail
admin and a dns admin (or someone who can crack the relevant mail and DNS
systems) with a sender.
It seems to me that if anyone ever devises a trustworthy and broadly
deployable/applicable shared *authorization* layer for mail, SPF and DKIM
will both be too weak on other grounds to be the dominant authentication
mechanism. If there were such a thing as a trustworthy domain vouching
system to tell me that I can be sure that mail definitely from a paypal.com
sender is not phishing and mail definitely from a pay-pal.com sender is,
then I don't see why I'd use DKIM to do the authentication instead of
nagging the paypal.com folks to sign their mail with S/MIME so that I don't
have to support 2 signing technologies.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg