Sender Policy Framework (SPF)

SPF - Sender Policy Framework

What is it?

Sender Policy Framework. Anti-spam technique based on verifying the source of an email.

How does it work?

You create a list of all the mail servers that are allowed to send mail for your domain, and add it as a dns txt record. For example:

 gmx.net.        300   IN   TXT   "v=spf1 ip4:213.165.64.0/23 -all"

When an SPF-equipped mail server receives an email, it checks the FROM: header for the sender's address. It then does a dns query for that domain, and looks to see if it has a published SPF record. If it has, it checks to see if the server the mail has come from is in the list of approved mail servers. If it isn't, the mail is rejected because the sender's address is spoofed.

How does this help?

Although SPF isn't a complete solution to spam, and certainly isn't a replacement for good content filters, it does have some very useful qualities.

• It's a very quick test to perform. A dns lookup is substantially faster than accepting delivery for a mail, then running it through a content filter like SpamAssassin. This happens _before_ the smtp server accepts mail, so it can reject rather than bouncing.

• Zero false-positives. Unlike RBLs, no mail should be rejected by mistake, misconfigurations aside. All it relies on are sys admins listing their mail servers correctly.

• Just as useful against viruses and phishing attempts. Almost all viruses these days have a spoofed sender; wouldn't it be nice to reject these at the front door? Phishing mails _always_ have a spoofed sender, that's how the attack operates.

• Proof of origin. Let's say I get a spam which passes an SPF test. Well, then I _know_ the email really has come from aol.com etc, and I can legitimately complain to them about it.

What are the catches?

Email forwarding is completely broken. There's really no way around this; if mail is forwarded on, and it comes across a SPF-server, it will be rejected if the sender has an SPF record. Send a new email with the original as an attachment.

How effective is it?

The main stumbling block is there simply aren't enough domains with SPF records. None of the big mail domains (aol.com, gmail.com, hotmail.com, yahoo.com) have SPF records configured properly. They're present, but setup to allow the mail through. Seeing as a significant percentage of spoofed mail purports to come from these domains, it really wouldn't take much for SPF to have a significant impact.

It's often said, but one of the most effective techniques at reducing spam is straight-forward smtp restrictions. Most spam servers don't even bother to supply a fqdn for the HELO command, and quite a few don't spoof a valid mail domain for the FROM: address. You can eliminate a good chunk simply by requiring a fqdn for the HELO line, and checking for a valid MX record for the sender.

For more on SPF, including getting it working with most mail servers, see the website: http://spf.pobox.com/

Here is the RFC: http://www.ietf.org/rfc/rfc4408.txt

Here's a good page for smtp restrictions on postfix: http://www.freesoftwaremagazine.com/free_issues/issue_02/focus_spam_postfix/