Site Index

Introduction

FAQ
Blog

Executive Summary

Problems with the current email model

How SPF Helps

For Sysadmins:
Setup Wizard
Mechanisms

Received-SPF:

Sender Rewriting Scheme

Downloads

Mailing List

Adoption Strategy

Objections Answered

RFCs


To-Do

Sender Policy Framework (SPF)
Mar 12 2004

  • SPF fights email address forgery and
  • makes it easier to identify spams, worms, and viruses
  • when domain owners designate sending mail servers in DNS, so that
  • SMTP receivers can distinguish legitimate mail from spam
  • by verifying the envelope sender address against client IP
  • before any message data is transmitted.

SMTP has a security hole: any connecting client can assert any sender address. This flaw has been exploited by spammers to forge mail. The result: your mailbox fills up with bounces to messages that you didn't send. Close the hole, and we can easily block spammers by sender domain.

I am a system administrator. How do I implement SPF? (Answer: You start with the wizard.)

I am a manager. Give me the executive summary.

SPF was originally designed to prevent joe-jobs. In this mode, an MTA uses SPF to verify the envelope sender (SMTP MAIL FROM) address during SMTP time. But some people pointed out that SPF can also be used to verify headers to prevent phishing. When used to verify headers, the agent could be an MTA or an MUA, and slightly different rules apply: you have to consider Sender and Resent-From as well as just the "From:" header.

... all experience hath shewn, that mankind are more disposed to suffer, while evils are sufferable, than to right themselves by abolishing the forms to which they are accustomed.

News

March 13th 2004: We're in the April Linux Journal! Check out our exciting three-page centerfold where we bare it all! Actually, the article just discusses how to publish SPF records. Next month's issue will talk about how to check SPF in your MTA.

February 26th 2004: The latest version of Mail::SPF::Query will parse Caller-ID records! SPF-enabled MTAs can now read Hotmail and Microsoft.com's records and translate them into SPF format. As a reminder: SPF is designed to protect the envelope sender so you don't get bounces that say "You sent us a virus". Caller-ID is designed to protect the headers so eBay and PayPal can limit the damage of phishing spams that say "Your credit card has expired, please re-enter it here." If you are annoyed by viruses that cause you to get bounces, you should publish SPF. If you are a big institution or a bank and are concerned about phishing, you should publish Caller-ID records as well, but first you should check with Microsoft because you may need a technology license; they control the patent on Caller-ID.

February 24th 2004: Microsoft have announced Caller-ID for E-mail, a close relative of SPF. Some people have reported that Microsoft Word is unable to open the documents at that web site; we provide PDF versions for your convenience. In other news we are up to 7500 domains registered.

February 12th 2004: An eWeek article discusses SPF's interaction with the IETF standards process. While it would be really nice to see the SPF draft approved as an Experimental or Draft Standard within the next few weeks, the conservatism inherent in the IETF process may require that we follow procedure, hold a BOF, charter a Working Group, and meet a few times over the next year or two. Conservatism has served the IETF well in the past, and you certainly don't want to rush something as important as this. But the problems are urgent, and people are beginning to abandon email entirely. We need to act as quickly as prudence allows.

February 11th 2004: The spec has been published as an Internet-Draft with the version number 00. This marks the first step on the road toward RFC standard status. Oh, and we changed the name from "Sender Permitted From" to "Sender Policy Framework".

February 4th 2004: The registry crosses the 6000 mark. Major publishing domains include: AOL.com Altavista.com DynDNS.org E!Online.com (the ! is silent) GNU.org LiveJournal.com MotleyFool.com OReilly.com Oxford.ac.uk PairNIC.com Perl.org PhilZimmermann.com SAP.com Symantec.com Ticketmaster.com w3.org and of course foo.com.

February 2nd 2004: The registry crosses the 5500 mark.

January 28th 2004: Eine Deutsche Version von dieser Webseite gibt es hier.

January 16th 2004: Eric Raymond mentions SPF in his talk at the MIT Spam Conference. A handout is distributed to the audience. The registry crosses the 4000 mark.

January 9th 2004: Slashdot noticed that AOL experimentally turned on SPF for 24 hours. During that time, thousands of spams were blocked. They have turned it off over the weekend to assess the results of the experiment, and will turn it on again next week.

December 16th 2003: Mail::SPF::Query (available on CPAN) has a few updates, and matches the draft version 02.9.4 which is the latest RFC draft. You are encouraged to publish records. Independent client implementations in C and Python have begun. MTA plugins for Sendmail, Postfix, and Exim are available for download. The Slashdot thread contains a number of questions and criticisms based on an incomplete understanding of SPF. All those questions and criticisms are already answered or addressed on this website. To the trolls, I say: please engage eyeballs before operating fingers.

December 10th 2003: Design freeze announced.

October 5th 2003: Slashdot. Load on Slashdotted servers: 0.02 ...

October 2nd 2003: A unification project has begun under the aegis of the ASRG: the authors of SPF, RMX, DMP, and other designated sender schemes are working together to produce a single proposal that gathers the strengths of the different approaches. Early adopters, please join the mailing list; the spec is very likely to grow additional features by the time we're done.