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

Spoofed email is email that appears to come from one source, when it actually does not. Because of the simplicity of Simple Mail Transfer Protocol (SMTP), email spoofing is extremely easy to do.

Some background on SMTP. SMTP is one of the earliest email protocols developed. It was written by Jonathan Postel in 1982 and is officially documented in RFC 821. SMTP was designed to be reliable and easily usable. It has been the standard for transferring email for the last 23 years. Virtually every mail server in existence uses SMTP. However, its ease of use has allowed spammers and phishers to abuse the email system.

The first step in transferring an email through SMTP is to establish a connection. SMTP uses TCP port 25 for this. The client host then sends the HELO or EHLO command to the server. Some servers require that a domain be specified along with the HELO. But this can be spoofed, for example HELO xyz.com is usually valid. Most servers only check the IP address. Next the client sends the MAIL FROM: command. The email address entered here can be anything. Most servers do not check to see if it is valid. Some servers even accept a blank address. SMTP really has no way of even checking that the email address is valid since it is not from their system anyway. The domain on the address does not have to be the domain specified earlier in the HELO. The next command is the RCPT TO: command. An open relay will allow any email address to be entered here, but a properly configured server will only accept an email address with the same domain as the mail server. The next command is the DATA command. This notifies the SMTP server that everything else that follows is part of the message. This can be simply the message, but it also includes all the client header information. This is the information that is interpreted by the email client. It includes date, to, from, cc, subject, and more depending on the email client. The simplest way to enter header information is to enter the field, ie Subject: this is the subject. You can also enter to and from information here. This is how email can show up as being sent from Joe Schmoe instead of joeschmoe@email.com. This is a very nice feature of email clients, but it also makes email spoofing very easy.

This all sounds really confusing, so to understand this better, you can use telnet to communicate with an SMTP server. Here is an example of a spoofed email being sent to frankdzedzy@frankdzedzy.com.

C:\>telnet mail.frankdzedzy.com 25
220 ss71.shared.server-system.net ESMTP Sendmail 8.12.11/8.12.11; Fri, 9 Dec 2005 10:17:19 -0800
helo xyz.com
250 ss71.shared.server-system.net Hello [12.178.219.195], pleased to meet you
mail from: joeschmoe@emailserver.com
250 2.1.0 joeschmoe@emailserver.com… Sender ok
rcpt to: frankdzedzy@frankdzedzy.com
250 2.1.5 frankdzedzy@frankdzedzy.com… Recipient ok
data
354 Enter mail, end with “.” on a line by itself
subject: this is a spoofed email
you have just been spoofed
.
250 2.0.0 jB9IHJIY001987 Message accepted for delivery
quit
221 2.0.0 ss71.shared.server-system.net closing connection

When I open up the email, it shows it as being from joeschmoe@emailserver.com. If I don’t know who this is I could open up the source. This is what the source looks like:

Return-Path: <joeschmoe@emailserver.com>
Received: from ss71.shared.server-system.net (root@localhost)
by frankdzedzy.com (8.12.11/8.12.11) with ESMTP id jB9IJ4Sd002707
for <frankdzedzy@frankdzedzy.com> Fri, 9 Dec 2005 10:19:04 -0800
X-ClientAddr: 12.178.219.195
Received: from xyz.com ([12.178.219.195])
by ss71.shared.server-system.net (8.12.11/8.12.11) with SMTP id jB9IHJIY001987
for frankdzedzy@frankdzedzy.com; Fri, 9 Dec 2005 10:18:30 -0800
Date: Fri, 9 Dec 2005 10:17:19 -0800
From: joeschmoe@emailserver.com
Message-Id: <200512091818.jB9IHJIY001987@ss71.shared.server-system.net>
subject: this is a spoofed email

you have just been spoofed

I use the RoundCube webmail client, which is a very nice looking and simple email client. Other email systems and clients will probably add a lot of other stuff to the header, but this here is nice and simple. As you can see, the only item that can really identify who I actually am is the IP address. Everything else is either related to my email server, or is fake information. Obviously, this is a great way to pull pranks on your friends. I have done it on a couple of occasions at college, with great results. However, you can use spoofing to pretend to be someone you are not. This is a form of social engineering known as phishing. This is fast becoming a major problem, as phishers send spoofed emails that are carefully constructed to look like a reputable organization. They then direct you to a website, which collects information from people who can’t tell they are being misled. Spammers also use spoofing to disguise their real identity and to help get the email past spam filters.

After looking through the headers of the emails, I was sent back, I was able to tell that most of them were just generic spam emails. The subjects had product names, celebrity names, and phrases like “Your Password” in them. Also a lot of them had viruses in them. I was able to find the originating IP addresses in the headers I got back too. (Probably 80% of the undeliverable email did not send back any of the original header information, which was really irritating.) Out of all the emails, I have received, I have found about 14 different IP addresses. Most were only used once, but some have been used dozens of times. All are IP addresses that are part of various home broadband ISPs, around the US. I have not been able to ping any of the addresses successfully. This makes me wonder if the spammer is spoofing IP addresses. A better explanation for this would be that he is sending his emails through these unsecured home PCs. They may be part of some small zombie network. I received dozens of undeliverable emails sent to me over the last weekend, but very few the last few days. So either he is no longer using our emails, or he is sending emails to valid addresses.

So what can you do if somebody is spoofing your email address? Well, nothing at all. Since they are able to enter all the fake information into the email there is no way you can stop them. If you have a similar situation with your email server that I described here, I would recommend making sure your server is not an open relay. Because of the many open relay databases out there, there are few open relay servers in the United States. If your server is relaying mail, it won’t be long before you start getting blocked from sending mail, by other email servers. I would also recommend keeping a close eye on your logs, to make sure that the emails really aren’t coming from your server. This would be happening if one of your users was sending out spam, or if you had a worm sending out emails. If so, you would notice the local IP address in the log information, and could easily find the culprit.

Now here’s how you spoof your email address, if you only want to prank your friends. The easiest way is to change your display name and return address in your email client. I mostly use Outlook (because we use Exchange), Thunderbird, or Gmail, but you can do similar things in other email clients. I have been unable to do it very well with Outlook. It does work well in Thunderbird though. Go to your accounts settings, and change the display name and email address to whatever you want them to be. Most clients have a separate place to enter your logon information, and don’t use the email address for this. Just remember that whatever email address you set here, will be the address any reply is sent to. After you have sent the message, the only way to identify you is the IP address in the header. Depending on the client, this can be tricky to find.

You can also use this form here to send a basic email with a spoofed address. It will send a simple email that can disguise your name and email address. The script does place a link in the source header to this webpage. This is only visible if the victim looks at the header though. Script downloaded from www.digi-dl.com.

I have provided this information to educate on the SMTP protocol and methods used by spammers and phishers. It is not intended to be used for the purpose of phishing. Email spoofing is not considered illegal by the FBI, because no hacking is involved. However, most spamming and phishing is illegal. I would recommend only using email spoofing techniques for pranks, and even then remember to use your discretion.