In our modern, sprawling, commercial dystopia, spam is an inevitability. Between phone numbers, messenger apps, email accounts, etc., most individuals have no less than three communication channels; all of which will be shared freely with the goal of accessing further services and apps. There are dozens of mutually shared datasets out there containing millions of numbers, addresses and usernames.
Bottom line, your email, your phone number and your social media accounts are all out there, freely available to marketing and sales agents, both legitimate and not. It takes almost no effort to aquire these manifests and bombard everyone on them with robocalls, automated emails and texts.
Simply due to low cost and near zero risk, it takes only one response to have this approach pay off. As it happens, this brute force market strategy is fantastically successful.
Since our attention and resources are limited, the cost of spam is borne by us, everyday users, one way or another. So, in order to reduce the cost to us, we have to set up some infrastructure to stop it.
For purposes of this article, we will be covering email spam, since this is the kind we will encounter the most of and because it's also the kind we have the most control over. Stopping most spam is directly related to how your email server is set up.
Don't use open relay
When you configure you SMTP server to run an open relay, you're allowing your server to accept mail for any destination and deliver it. Simply accepting this mail will already take up system resources, while basically guaranteeing spam delivery to everyone using this server. Don't do this.
Make sure your server is accepting mail on port 25 only for your own domain. Test your server by sending it an email with To: and From: addresses outside your domain. Your server should reject these messages.
Reject suspicious messages
Emails with IP addresses without a reverse DNS (PTR record) should be marked as spam or rejected entirely. Same goes for messages with non existent domain names in recepient or sender addresses. Reject connections that don't send a HELO/EHLO or where HELO/EHLO is not a qualified domain name or IP address or wrong altogether.
While it's impossible to authenticate inbound messages, outbound emails should always be authenticated. Failure to do this runs the risk of spambots nesting in your servers and using it for spam. Your filters should be set up to only have authenticated users as destinations, and reject all other inbound mail. If possible, using separate servers for inbound and outbound email with no unauthenticated users allowed in the outbound server.
If you're a corporate network, blocking outbound traffic on ports 25, 465 and 587 - for SMPT, SSL and Submission - for everything except your outbound mailservers is generally a good idea. If your network has spambots running on it, this will stop them from being able to send anything out.
This is a popular mail filter that uses a Bayesian engine to analyzie spam and regular mail and learn to differentiate ebtween the two. As such, it actively needs mail samples to learn from, so best practice when running it is to not reject incoming mail but separate it into a spam folder.
DNSBLs, or DNS blackhole lists, are lists of known IP addresses associated with spam. They're actively run by third parties that will have their own criteria for what addresses are and aren't making the lists. So, research is absolutely necessary before using one. The upside is that these lists are usually free.
This is a concept where you have your SMTP server temporarily reject an email. When the delivery is retried after a time period, it's allowed through. This is a simple way to filter spam issued by very basic software, but will probably not work against more intricate systems that can differentiate between a temporary and permanent rejections.
Spam filtering appliances
Devices like the Barracuda Spam & Virus Firewall are set up to intercept traffic before hitting your SMTP server, and filter messages using DNSBLs, Bayesian filters, etc., that are all curated and maintained by the manufacturer. If you can trust the device, this is the most hands off approach you can get.
This article covered some basic practices for fighting spam on your server. In our next one, I'll be going over methods for fighting spam as an end user.
Follow us on Twitter and Facebook to know when the next article drops, and learn more about ServerSuit.
Until next time!