SPF Overview

You can help eliminate the spam problem by making it easy to detect forgeries. Protect your e-mail address reputation with a simple DNS technique.
SPF by Example

Suppose example.com wants to publish SPF. It expects MTAs everywhere to read its SPF record and use it to reject forgery attempts. It hopes SPF reduces the volume of joe-job bounces and bogus abuse reports. So it adds the following line to its zone file:

example.com.  IN TXT  "v=spf1 a mx ptr -all"

The v=spf1 version string identifies this as an SPF record. The -all means reject all mail by default. Domains that don't send any mail, such as altavista.com, can get by with simply v=spf1 -all. But if the domain does send mail, it declares mechanisms that describe how legitimate mail should look. Mechanisms go in the middle, before -all. The first mechanism to match provides a result for the SPF query. -all always matches and so belongs at the end.

Mechanisms are interpreted left-to-right. Using v=spf1 a mx ptr -all first would check whether the connecting client was found in the A record for the domain or, failing that, in its list of MX servers. Then the MTA would check to see whether the hostname of the client matched the domain. If none of the mechanisms matched, -all would be evaluated, the result would be fail and the MTA would be justified in rejecting the mail.

A, MX, PTR and IP4 are enough for the overwhelming majority of domains. The setup wizard at spf.pobox.com/wizard.html can help you configure SPF for your domain. But if your situation is complex, you can use the mechanisms described in the “Advanced SPF” sidebar.

Extensibility

SPF has a number of built-in mechanisms. The basic ones let you designate the hosts that send mail from your domain. This works well for almost all domains out there, because each domain's mail comes only from a small set of hosts. But if mail from your domain is distinguished in some other way, say you always sign it with S/MIME, instead of typing a or mx you can type smime.

Using designated sender mechanisms (A, MX, PTR and IP4) is one possible approach to sender authentication. New sender authentication methods are being developed. SPF is extensible, though, so it can work gracefully with them. SPF plugins that understand future extension mechanisms will be able to interpret them correctly. SPF plugins that don't understand those mechanisms will return unknown, and your domain will be treated as though it did not have an SPF record at all.

Protecting Subdomains and MX Servers

Today, spammers forge domain names. Tomorrow, they might forge hostnames. They might try to joe-job your laptop by making up username@ibook.example.com. It's a good idea to protect your subdomains as well. You should start with your MX servers and move on to other hosts with A records. Here's why.

Bounce messages are sent with MAIL FROM: <>. The null sender address ensures that bounces don't themselves bounce and create a loop. When SPF sees the null sender address, it falls back to the hostname given in the HELO command. When your MTA sends a bounce message, it announces its hostname in the HELO command it sends. If that hostname has an SPF A mechanism listed, the message passes. So SPF prevents HELO forgery as well.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: SPF Overview

Anonymous's picture

I read this article after reading the May 2004 article because my subscription just started up. So, interestingly, everything seemed to flow. Thank goodness Linux Journal posts their articles!

I found this one here because I read the other article and thought "Hey, I need to do/learn this! Where's that previous article." A few clicks later, there it was. :)

I can understand the first person's frustrational comment about the definition of SPF. I explained a little of what I was doing to my signifigant other, and the initial response, after defining SPF, was "Oh, I thought it was like sunblock. You know, like SPF-15, SPF-45.."

In a way, it is like sunblock. It prevents your systems from burning up from processing all of that spam!

Re: SPF Overview

Anonymous's picture

Just for the record, the other half of this article, which is obviously more detailed due to the complexity (setting up the email side of thigns), is in the April issue:

http://www.linuxjournal.com/article.php?sid=7328

SPF?

Anonymous's picture

I don't believe this article even once tells us what SPF stands for.* Perhaps it means nothing, the latest fad in (non-) acronyms.

How did this piece make it past an editor?

*For the frustrated reader: it stands for Sender Policy Framework.

Re: SPF?

Anonymous's picture

You seem to be in the possession of Internet access... A quick trip over to spf.pobox.com would have answered your question rather quickly ;)

Re: SPF?

Anonymous's picture

I think you are missing out on some experience when it comes to technical writing. Technical lingo should be explained, but not to the depth of the PDR (Physician's Desk Refeence). Because the industry is so acronym-laden, many have found a common style to use the acronum once and place an explanation in parantheses afterwards, describing the acronym or term, but after that, to use the acronym (only) as the meaning has been explained. The initial reference can be seen in my reference to the PDR above.
And finally, but most importantly, material should be written|developed|edited so a reader doesn't have to read a sentence more than once for comprehension. Have you ever found yourself halfway into a sentence (technical, romance, etc. and say, "Huh?" then go back to the beginning of the sentence and start reading it again? That's an example of a bad book. Bad book! Bad bad book.

Re: SPF?

Anonymous's picture

I agree. Thanks for suppling the definition. I though the article was good.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState