FrankDzedzy.com

Some time ago I wrote an article explaining how email spoofing worked. See here. I concluded that there was no good way to prevent your email address from being spoofed. Several people commented on that article and told me to look into Sender Policy Framework (SPF). I have done some research on SPF, and decided to write an article describing how to use SPF and some of the related issues.

Sender Policy Framework is a concept that validates that the IP address that an email is coming from is permitted to send mail for the domain found in the Return-Path. The concept was first introduced in 2003. It is not yet an RFC, but the IETF has accepted it as an experimental protocol. Microsoft is also involved in developing this concept, and they are calling it SenderID.

The concept of SPF is very simple. It is nothing more than a DNS entry that specifies which IP addresses are allowed to send mail from a domain. When an SMTP server receives an email, it checks for an SPF record in the DNS and checks the Originating IP address in the email against the approved IP addresses in the SPF entry.

How it Works

An SPF entry is recorded in DNS using a txt record. A basic SPF record would look like this:

“v=spf1 a mx ptr ~all”

The v=spf1 signifies the version of SPF to use. The ‘a’ represents the ‘a’ record in DNS for this domain. Similarly the ‘mx’ signifies the ‘mx’ record in DNS. ‘ptr’ lets any host whose IP has a reverse DNS record that ends in the domain to send mail. ‘-all’ tells a query to fail the message if it does not match any of the previous qualifications.

There are seven mechanisms that can be used to define where mail is coming from:
A -> the A record corresponding to the domain
MX -> the MX record
IP4 -> used to specifiy an ip address ie: ip4:192.168.0.1, or a range can be entered using cidr notation ip4:192.168.0.0/24
IP6 -> same as IP4, only with IPv6 addresses
PTR -> any sender whose IP reverse resolves to this domain
EXISTS -> if the domain name resolves. This one is not used, because it will pass any domain that exists.
INCLUDE -> This will check the SPF policy of a specified domain. For Example: ‘include:google.com’ will check the SPF policy of google.com

One of four qualifiers can be placed in front of any of these mechanisms.
+ returns a PASS result. This does not need to be specified. ‘+a’ is the same as ‘a’
? returns a NEUTRAL result. This is viewed as a NONE or no policy result.
~ returns SOFTFAIL This is for debugging. It passes the message, but still returns a fail result.
- returns FAIL. Tells the client to discard the message as illegitimate.

A ‘:’ can be placed after a mechanism to specify a different record. For example: ‘a:google.com’ would pass the ‘a’ record of google.com as permitted to send mail.

How to use SPF to protect your domain
To protect your domain from spoofing simply create the necessary SPF record in your DNS zone file. You can write out the txt record your self, or you can use the wizard at http://www.openspf.org/wizard.html?mydomain=&x=28&y=9 or http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/ both will create the same record, and explain what each part is that you put in. Then, copy the resulting text and add it to the DNS, or have your DNS provider add it, if you don’t manage your own DNS.

Using SPF to block spam
You can also implement SPF on your mail server to block spam emails, and phishing attacks. All email servers made in the past year probably support SPF since it is gaining in popularity. Microsoft added SPF support to Exchange with Service Pack 2. And there are plugins that can be downloaded for Sendmail and Postfix. Make sure your mail server software is up to date, and check your documentation to find the correct setting. If you do not manage your own email server, there are some mail clients that will do SPF checking. Mozilla Thunderbird has a plugin http://taubz.for.net/code/spf/ that will check the SPF for an email and let you know the results. Also, gmail (which I use for email) checks SPF and will put the message in the spam folder.

Problems with SPF
While SPF is a good system for stopping spoofed emails, it is far from perfect. In fact there are several major problems with it.
1. Lack of support – This is probably the biggest problem as not a lot of domains are using SPF. It is rapidly gaining support, and many of the large domains have started using it. Aol, Google, and Microsoft are just a few of the big names who have implemented SPF.
2. SPF only checks the HELO and Return-Path email address. It does not check the From: field in the data portion of an email. So you could still get an email and it would appear to be spoofed, depending on how your mail client handles the From: field.
3. SPF breaks email forwarding. When an email is forwarded from one domain to another. If a mail transfer agent in another domain simply forwards the message, an SPF query will cause the message to fail, since the MTA is in a different domain than what is shown in the Return-Path. This could cause some annoying problems with users who have aliases that forward mail from one domain to another. This problem can be solved if the MTA uses remailing instead of the traditional forwarding. A new technology called Sender Rewriting Scheme will change the email address, but still allow the user to reply correctly. From the little I have read about it, it seams that SRS only obfuscates basic information, and it looks like it could be easily fooled by spoofing the SRS changed email.
4. One obvious problem is that SPF will not work if the Return-Path: <> (Null return-path). Since there is nothing to look up, how can it work? The email server could just require all mail to have a valid return-path, but that could still be a problem.
5. SPF will lock in users to there ISPs. It will force someone to use the ISPs mail servers to send out email with their email address. The user cannot send out email with that address from there own system.
6. Since AOL is a big supporter of SPF, they will cause problems for everybody. I have seen so many problems with sending mail to AOL users, because of their tight SMTP restrictions. Once they start to enforce SPF, it will block a ton of legitimate emails.
7. In my opinion one of the biggest problems with SPF is that it uses DNS. DNS was not designed to be a security system, but instead it provides information on a domain. SPF uses the txt record, which was designed to provide free flowing text about a domain, not semantically correct entries. Spammers could easily create a disposable domain with the correct SPF information. There will also be problems with DNS changes, since it takes some time for changes to propagate and with the use of DNS caching, mail servers could block legitimate mail for days when an SPF record gets changed.
For more information on the problems with SPF see here

Conclusions
I am not a big supporter of SPF. It seems like it is a good idea, but I feel that it has not been thoroughly thought out. There are too many problems that it creates that break the original intent of the SMTP protocol. In my opinion, I feel that SPF will ultimately block more legitimate email than forged email. It seems to me that there should be a better way to create this system, without causing all of these problems. But I do feel that this system will gain in popularity and use. With AOL getting very involved, mail administrator will be forced implement SPF in order to be able to deliver mail to AOL. I like how GMail currently implements SPF, by sending the mail to my spam folder, instead of just rejecting it completely. But eventually, the will start blocking failed messages, to cut down on overhead.

More informarion on SPF
OpenSPF.org
Wikipedia entry
More info