(... or how to publish a Sender Policy Framework (SPF) record and minimize "Joe-Job" e-mail attacks.)


Has this happened to you?

You get a nice but cryptic message from someone called 'Postmaster' saying that the e-mail you sent to someone you don't know has not been delivered because you are sending SPAM! You know you did not send anything to this e-mail address so it looks like someone has hacked your e-mail account or is impersonating you to send Spam. You don't want this as they are treading on your reputation and may get you blacklisted so you can't send legitimate e-mail. It can also slow down your e-mail as your mail server has to deal with all these postmaster messages. One client of ours, for example, was getting over 1.8 million of these a day!

What can you do?
 
While it is very possible that they have hacked into your e-mail account* and are really using your account to send Spam it is much more likely that all the spammer has done is taken your e-mail address and used it as the 'return address' on all the spam they are sending. This is called a "Joe-Job" and the end result is that any e-mail that gets rejected for any reason will end up sending you a Non-Delivery Report (NDR) that will clog up your mailbox.

(Don't get me started on mis-configured mail servers that don't reject at the protocol level... that is something for another day ... )

So what can you do? Publish your Sender Policy Framework (SPF) record.

What is an SPF record?

Basically you get to set and publish a policy stating what mail server your e-mail should come from and what policy you want the administrators of all the other mail servers out there to take when an e-mail 'claiming' to be from you fails your policy. This is a simple record that you publish in the DNS (Domain Name) Servers that are responsible for answering the other questions people have about your domain such as where is your website and where should they send e-mail so that it gets to you.

What does an SPF record look like?

Here is the SPF record for the domain CudaMail.com:

"v=spf1 mx a:mx1.cudamail.com a:mx2.cudamail.com a:mx3.cudamail.com include:optrics.net -all"

'v=spf1' means this is an SPF record version 1 and is required.

'mx' means to allow e-mail from the systems that are already in your MX records.

'a:mx1.cudamail.com a:mx2.cudamail.com a:mx3.cudamail.com' are all the same and say to allow e-mail from the IP addresses that resolve or reverse DNS to these names - you could also use the IP address here.

'include:optrics.net' means to lookup the SPF record of the domain Optrics.net and also allow the mail servers listed there. This is used when you have to send through your ISP's mail servers - just include their SPF record. This is a great way to distribute the management of the SPF records because any e-mail from Optrics.net must be able to pass their SPF record so if you have to send through their mail servers by including their SPF so will yours.

"-all' this is where you set the policy for 'all other' mail servers. In this case the minus sign says to reject all e-mail claiming to be from your domain that does not come from the list of allowed mail servers. If you use a tilde '~' instead then you're telling the other mail administrators that you're not 100% sure that e-mail should only come from this list and they can choose to reject or not.

Great! So how do you go about setting up and publishing one of these SPF records?

The place to start is at www.openspf.org where a simple wizard will walk you through some questions and then present you with an SPF record ready to be published in the common DNS servers. If you have a control panel that allows you to make changes to your DNS records then you can make them yourself but if not you can forward the SPF record that OpenSPF generates for you to your ISP. In either case you will want to get someone to double check the SPF record before publishing it just in case you forgot something. Your ISP should know about SPF records and can provide you with guidance.

What should I watch out for?

There is a list of common mistakes on the OpenSPF website (www.openspf.org/FAQ/Common_mistakes) you will want to review but here is my own short list.

1. Watch out for your web forms that send e-mail. These have to be configured to send through your mail server and not to send directly out to other mail servers or the messages will fail the SPF check for your domain.

2. Similar to the above - any website that has a 'send this article to a friend' button typically has a place for you to put in your e-mail address so they can impersonate you when the message goes to your friend. While this sounds like a good idea it will also fail the SPF check for your domain so don't expect it to go through.

3. Blackberries. This used to be a problem with the older BlackBerry Internet Service (BIS) but now they have implemented a Sender Rewriting Scheme (SRS) so it shouldn't be a problem but you will want to test for messages being rejected when you send from your Black Berry. If they are, you can use an 'include:srs.bis.na.blackberry.com' in your SPF records assuming you are in North America.

4. Hotels and WiFi hotspots. Some hotels and WiFi providers run a transparent proxy service that intercepts all e-mail so they can either scan it for virus or to make sure they bill you for the service. These transparent proxies make it look like you are talking to your mail server but they are really doing a store and forward e-mail delivery on you and thus your e-mail looks like it is coming from the mail server of the hotel or WiFi hotspot. These messages will fail your SPF policy. You can either send e-mail via a web mail interface or see item 5 below for another solution.

5. Other SMTP servers. Some ISP's are blocking the standard SMTP port number (25), which is the default for most e-mail clients and are forcing you to use their servers. Either add their SPF record to yours as an include if this is your ISP or setup your e-mail server and client to allow you to talk to your server on an alternative authenticated SMTP port.  Most mail servers are starting to support a second SMTP port and requiring that the client be authenticated before allowing them to send e-mail. Check to see if your mail server supports this alternate SMTP port feature and you will be able to take your laptop anywhere and still send e-mail.

5. Testing. There are a number of excellent third party tools out there to test your SPF record both before and after you publish your SPF record. Here is a short list:

Decludes SPF test - Can test before you go live and double check after.

  > http://tools.declude.com/

DNS Stuff - Used to be 100% free but have recently gone to a paid service with some basic tests still free but you can sign up for a 21 day eval. Well worth the money but only if you work with DNS a lot. It presents the results in an easy to read format with good explanations.

  > http://www.dnsstuff.com/

Scott Kitterman's SPF test site - A simple site but it gets the job done.

  > http://www.kitterman.com/spf/validate.html

While this post is a little longer than usual taking the time to read it and then implementing an SPF record will be a great step in the right direction to stop these "Joe-Job" attacks on your domain. The second step is to make sure your mail server or anti-spam service is checking for SPF records. That will be the next article.

- Shaun Sturby
CudaMail's Technical Services Manager


* If they really have hacked into your e-mail account you need to change your e-mail password right now being sure to use a strong password, set your client to use encryption if possible, scan your PC for malware like keystroke loggers and if found clean these up before resetting your password to a different one again - seriously!

**If you have an e-mail address @Hotmail.com or @Yahoo.com or any other common domain then they are responsible for publishing the SPF record and have probably already done so.

(really I'm not!)

1. Maybe because you misspelled something or are using text messaging shorthand, L337 (leet) speak or hacker jargon.

http://en.wikipedia.org/wiki/Text_messaging
http://en.wikipedia.org/wiki/L337

Anti-spam filters get suspicious when they see bad spelling or unusual characters inserted into words because this is what Spammers do all the time. Don't act like a Spammer and you won't get lumped in with them.

2. If you are at your corporate site you probably send e-mail out via your organization's mail server but when you work from home, at a hotel or at your favorite coffee spot they are probably either blocking outbound SMTP traffic to stop infected systems from sending Spam or are silently proxying port 25 'in your best interest'. This can cause your outbound e-mail to fail completely or fail something called an Sender Policy Framework (SPF) check or a domain check as an outgoing server whose name doesn't match your domain name raises a red flag, unless it's a well-known one, like Gmail or Yahoo.
 
What can you do about this?
 
A. Use webmail. Since you are connecting back to your real mail server the e-mail will not be blocked and it will be coming from your mail server so the mail server checks will pass. Make sure you use a secure connection (httpS) when you do this or the hotel or coffee shop may be able to read your e-mail. Not something to do if your working on your "super secret" plan!

B. Use a VPN to your office first then use your regular mail client. Again the e-mail is going from your laptop to your mail server first so you will pass these anti-spam checks. Some locations, like hotels, may not let you start a VPN connection so you will have to use webmail or the final solution - alternate SMTP port.

C. Use an alternate port for SMTP. Way back when the Internet was young and shiny and spammers weren't born things were a lot more permissive and so requiring people to identify themselves to send e-mail wasn't necessary. Today the best thing to do is run two SMTP services or e-mail server software that can listen for e-mail on more than one port. Leave port 25 to accept e-mail from the wild and do all your anti-spam checks on this port. The second port is going to be dedicated to accepting e-mail from your users only and therefore two things are needed:

1. An alternate port like 465 or 587 mapped through your firewall to your mail server.
2. A setting that forces your users to authenticate (provide a user name and password) FIRST before accepting e-mail from them.

This way your laptop connects to your mail server on a port that is not blocked and spammers can't use this port to send you spam because they don't have a username and password on your server - simple!
 
More about SPF records next week.

Shaun Sturby
Technical Services Manager
CudaMail