[Note: I've only been reading the list on-and-off, so apologies if some of
these issues have already been discussed.]
One of the biggest concerns I have is that it appears
trivial for a forger to evade SPF as currently specified,
at least from the point-of-view of an end-user.
A trivial example: the draft 02.9.5 version of SPF (dated Jan 2003)
in section 2.2.1 says that I can switch to "unknown" just
by using an envelope sender with no domain, and a HELO
(and EHLO?) with no FQDN. Great, a few blank entries and
no checking is done at all. Is that right? Or am I
misunderstanding something?
Yes, it looks like that's what the draft says. Since RFC 2821 says
that the argument field for HELO/EHLO "contains the fully-qualified domain
name of the SMTP client", I think it would be reasonable to change the
result when no FQDN is provided to "fail" instead of "unknown", and to
change the NXDOMAIN case to "MUST return `fail'" (disallow "none"). There
really shouldn't be any reason for not giving a valid domain in HELO.
A much nastier flaw, though, is that as currently specified
SPF only checks the envelope sender, and not the "from" (etc) addresses.
Unfortunately, this isn't an easy problem to solve (I ran into this
issue while writing my own SPF-like I-D, and punted). You can implement
all the technical measures you want, but in the end, people want to be able
to change the name/address other people see when the open the message, and
saying "we won't let you do that because it lets spam through" is probably
akin to implementing new antiterrorism security measures in airports--it'll
just drive people away.
Forwarding is the major issue here; when a message is forwarded,
people want to see who originally sent it, not the last machine that
forwarded it. If you enforce SPF on From: lines, people will complain and
mailreaders will switch to displaying Resent-From:. If you enforce SPF on
Resent-From too, people will start implementing X-Originally-From or what
have you, or people will just stop looking at the From: line altogether and
rely on message contents (at which point spammers no longer need to forge
their address to do joe-jobs). It's the old convenience-versus-security
argument, and my impression is that the vast majority of users would prefer
the "convenience" side, even at the cost of continued spam.
If end-systems can't reasonably validate the
"from" header in email using SPF, it's not clear there's much value in SPF.
This, however, I would disagree with. Even if SPF can't prevent
forgeries (as most people would see them) entirely, it's a step toward
accountability for E-mail: in an all-SPF world, the envelope sender has to
point to a valid location, or at least domain, and that provides a definite
starting point for taking further action--technical, legal, etc. If
spammers know that their spam can eventually be traced back to them, they
will probably be more hesitant. SPF may be only a single step, but it's
better than none at all.
[P.S. to Meng: Trivial numbering error in the draft--section 5.6 "exists"
is followed by section 7 "Macros" with no section 6 in-between.]
--Andrew Church
achurch(_at_)achurch(_dot_)org
http://achurch.org/
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.5.txt
Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡