>> This article assumes that you have your own domain and are not using a generic e-mail address
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.
No comments:
Post a Comment