Hi - I've been reading over the SPF RFC drafts, FAQs, etc.
I like the underlying idea of SPF, In fact, I can't help
but agree that this sort of thing should've been in SMTP
from the beginning.
However, I have some concerns and questions about
SPF and SRS as currently specified. Please forgive me for
what's been hashed through before (maybe you could
add more of this info to the FAQ?).
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?
A much nastier flaw, though, is that as currently specified
SPF only checks the envelope sender, and not the "from" (etc) addresses.
Only serious "SMTP weenies" know there's a difference; even
most technically astute people don't know about that flaw (my opinion)
in the SMTP protocol. A system can filter incoming email using SPF
as specified, the envelope can say it's from "nasty" and the mail header
"from" address is from "ebay.com". Users will only see the "from"
address in the mail header, and be MISLED by SPF into believing it's
legitimate. You can argue that comparing the two values is a
"local decision", but there has to be a reasonable default/expected type
of processing or SPF will fail to do what people expect it to do.
If it's easy to avoid, spammers will do it.
And as of yet, I don't see the clear answer for what to do.
The simple answer is that the "from" address (and/or resender)
in the header should be same as the envelope-sender.
But that will mess up forwarding using SRS, unless SRS mangles the
"from" address as well as the envelope-sender address. And if SRS
mangles both, users will be presented with very ugly (and implausible)
from addresses. If end-systems can't reasonably validate the
"from" header in email using SPF, it's not clear there's much value in SPF.
It _appears_ to me that there's some effort to deal with this.
I'm particularly happy to see Meng Weng Wong's email
("Re: [spf-discuss] Is Return-Path as available as we think?"
dated Tue Feb 03 2004 - 14:56:56 EST), where Meng says:
"There is a huge demand for header verification.
And it doesn't make sense to have two different standards, one for
envelope verification, and one for header verification, when the
underlying logic is the same in both cases --- you're verifying an IP
against an email address....
So I'm going to put the "Resent/Sender/From" rules into the SPF draft
and basically say to people "SPF was designed to work on the envelope."
But I think it's critical to have more than just a "here's a
suggestion"; it needs to work as a reasonable DEFAULT, or the
whole exercise is moot. Spammers will gladly give "real" domains
in the envelope, as long as they can forge the from headers. From
an end-user's viewpoint, there has been no improvement.
I'm also trying to figure out how a small-time forwarder
for a vanity domain can _easily_ implement forwarding to some
big-time mailbox system (like Yahoo, Runbox, etc.), in particular so
that "from" addresses in the email itself can be checked by the
big-time mailbox system.
Simple forwarding won't work; the envelope sender won't match.
SRS modifies the envelope, but now the "from" address in the
mail body is wrong. SRS could modify both, but now the forwarder
has to handle all email going backwards, and the user has UGLY
email addresses to deal with (and probably WON'T accept them).
One way to counter all this would be if the end-systems let
each users specify "trusted forwarders" for themselves.
In other words, a forwarder whitelist. You could even use SPF
syntax. Thus, a user at yahoo.com could specify that they trust
email forwarded to them by "+mx:mydomain.com -all", and any email
forwarded by one of their mail servers would be automatically trusted
as having valid Received-From information that they could use for
an SPF check. I haven't thought this through in detail; ideally,
you'd want to be able to use SPF filtering (of both the envelope and
header) at the forwarder(s), final receiver, or combination.
One serious problem, of course, is that current big-time mailboxes
don't support whitelisting forwarders at all. Still, it might be
easier to get a few of them to implement forwarder whitelisting,
especially if that turns out to be the way to allow forwarding.
I think it'd be good for organizations to start advertizing
their SPF data in their domains. It takes time to add this
information for a lot of domains. And I'm already doing so.
But these concerns give me pause before actually filtering using
this information. And in fact, if my mail provider actually
started using SPF, _ALL_ my email would be currently marked as
"throw it away", because I use a forwarder, and the current
solutions for forwarders _seem_ to have serious problems.
Sorry for this long email. I'm just trying to grok a lot of information
in a short time, and end up with a lot of questions.
--- David A. Wheeler <dwheeler(_at_)dwheeler(_dot_)com>
-------
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_)œ§ÅvÂŒðŠŸØߎë ù1Ií-»Fqx(_dot_)com