On Fri, Feb 06, 2004 at 02:51:35AM +0000, David A. Wheeler wrote:
|
| 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?
Firstly, a HELO with no FQDN is an instant ticket into most spamboxes.
Ditto for a HELO with no A or MX record.
Secondly, if a mail server sees MAIL FROM: <>, if there is more than one
recipient, it knows the message is bogus. Why? Because only
nondelivery notifications have <>, and nondelivery notifications only
ever have one recipient.
Third, if the message is not formatted like a bounce message, you know
it's spam. If the bounce wasn't for a message you generated (which your
MUA or MTA could track) it's spam.
| 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.
Yes, they will do it.
But I couldn't think of a way to protect against
From: transient(_at_)spammer(_dot_)domain (service(_at_)paypa1(_dot_)com)
that would be compatible with most MUAs --- most MUAs only display the
"real name" part of an email address. I thought it would be wiser not
to go there.
| 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.
SRS implementations will also prepend a Resent-Sender header.
| 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 feel that header verification is a very important goal, but given the
current state of MUAs, header forgery, and so on, it is wiser not to
promise what we cannot confidently deliver. I do not think it is
possible to confidently deliver assurance regarding responsible senders
in the headers without cryptography. The natural subject of IP-based
authentication is the envelope sender, the natural time the SMTP
transaction, the natural operator the MTA. The natural mode of header
author authentication is a cryptographic signature, the natural operator
the MUA, and the natural protocol something like Domain Keys or S/MIME.
Crossing the beams is an experiment I will leave to more confident hands
than mine: I understand Microsoft's Caller-ID attempts to authenticate
the headers based on IP information. I wish them luck.
| 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).
This will be solved by the SRS patches we roll out --- if the forwarding
server's admin chooses to flip the "caller-id compatibility" flag,
you'll get a Resent-Sender prepended, which will pass header-checking
rules.
| 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.
I accept the responsibility for breaking forwarding.
I plan to fix what I break.
Stay tuned for SRS patches: we plan to provide them for Sendmail, Exim,
Qmail, and Postfix. (Development assistance would be appreciated and
will be funded to the best of my ability. Please join spf-devel.)
-------
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;±¤Ö¤Íµø?¡