You Have Invested In A Spam Filter But Continue Getting Spam - What Is Wrong With This Picture?

Let's talk about what you can to do help make your e-mail both more reliable and keep Spam out of your client's mailboxes.

First, most people have this idea that e-mail is both near instant and 100% reliable - unfortunately, both of these ideas are 100% wrong!

The SMTP protocol was designed when Internet links were both unreliable and slow, therefore the protocol was built to be resilient and to retry failed messages. However, the link speeds have now increased and have become more reliable, therefore people have gotten used to their e-mail arriving really quickly and so they have come to the unreasonable expectation that e-mail is near instant and 100% reliable.

Let's look at a couple of scenarios that will show that this is not the case as well as address some ways to increase your control over your e-mail server's level of reliability.

Case 1 - Single Mail Exchanger

A lot of e-mail domains right now have only 1 Mail eXchanger (or MX record) typically pointing to a single mail server at the head office.

So what happens if your internet connection goes down or there is some "hiccup" with the mail server or your firewall (you do have a hardware firewall don't you?). Anyone who tries to e-mail you will not be able to and the sender may get an undeliverable messages (or not) from their mail server after some period of time.

The Sending mail server should be configured to retry this message to you a number of times at some interval both of which are set solely by the administrator of the sending mail server. In other words, you have no control over how often they will try again or for how long and it will be different for each and every mail server that is trying to send to you. Talk about a troubleshooting nightmare!

Case 2 - Backup Mail Exchanger

When you publish an MX record via DNS one of the properties of the record is a preference. Here is an example (fictitious) domain and the tools you would use to see what your MX record points to:

nslookup -type=mx somedomain.com
Non-authoritative answer:
somedomain.com MX preference = 10, mail exchanger =
mail.somedomain.com
somedomain.com MX preference = 99, mail exchanger =
smtp.SomedomainISP.com

What the above record is saying is that when sending e-mail to 'yourbuddy@somedomain.com' to first try sending it to the mail server named 'mail.somedomain.com' and if that fails to try and send the e-mail through the mail server named 'smtp.SomedomainISP.com'. Your ISP may even include this service for free if you ask them, however these 'store and forward' backup mail servers typically just accept and forward messages WITHOUT anti-spam processing and since they are from a trusted source (your ISP) most mail servers are configured to accept without further processing.

Guess what? The Spammers are aware of this little fact and will, in violation of the standard, try to send e-mail to your domain through your backup or secondary MX record. This is how a lot of Spam sneaks in today - it takes the back door and doesn't get challenged by the security guard at the front door - your primary anti-spam solution.

So what is the solution to this problem?

Case 3 - Spam filtered MX Backup service.

Make sure your backup or secondary MX record points to a system or systems that are as hard on Spam as the protection on or in front of your mail server. This is the reasoning behind our CudaMail MX Backup Service.

We (Optrics Engineering) have been Barracuda Diamond Partners for a number of years and have seen the above problems (Case 1 and Case 2) a number of times with the clients we deal with and are offering not just an MX backup service but a Spam Filtered MX Backup Service. We have a redundant cluster of Barracuda Spam Firewalls that we use to provide primary anti-spam protection for smaller organizations but can use these same servers to accept, scan for Spam and deliver to your mail server in the event that your anti-spam solution goes off-line or your Internet connection or firewall has an issue.

This cluster is configured to retry delivery to your mail server every 15 minutes for up to 48 hours. Those pesky Spammers who try to sneak in through the back door are going to be very surprised when they run into the CudaMail service on your secondary MX records and you now know how often and how long you have before people get an 'undeliverable' response back.

While e-mail is not 100% guaranteed the above service puts you in control and slams the door in the face of the Spammers.

Now go have a nice (Spam-free) day!

- Shaun