This post is the final in a series that examines matters associated with running your own email server and email security. Previous entries included: Is outsourcing email the best option? and DNSBLs for email filtering: an introduction.
Applying Domain Name System Blocklists (DNSBLs) to the right part of your email filtering processes can provide considerable benefits, including reduced running costs and increased catch rates. Here’s a deeper dive into the world of blocklists.
A buffet of protection
There is a wide range of filtering options to consider when putting together a toolkit to protect your mailboxes. For example, content filtering and scanning use sophisticated models to decide on the likelihood of a message being malicious.
There are network-based tools that use distributed and collaborative methods for determining if a message is spam. Most of these tend to be expensive and resource-heavy. However, DNSBLs are a cost-effective way to stop a large percentage of unwanted mail at the Simple Mail Transfer (SMTP) connection before it even downloads the content to your mail server.
For a quick recap on some blocklist basics, look at this blog post. However, for those already familiar with the basics of DNSBLs, here’s a more detailed look into where you should apply them.
Firstly, at the very top…
DNSBLs should initially be the first line of defence for your mail system because they are the quickest and easiest method you have at your disposal.
During the first part of the SMTP connection, at the initial HELO, you can query a DNSBL in real-time. At this early stage in the email transaction, you haven’t accepted any part (header or content) of the inbound email, and you can choose to reject it there and then.
Resource efficiencies
Being able to reject up to 98% of unwanted emails at this initial filtering stage is far more resource efficient; saving memory, Central Processing Units (CPUs) and latency for more intensive checks on only ‘suspicious’ messages.
Consider if your mail infrastructure is targeted by a sustained or escalating spam campaign, and hundreds of messages per second are being received. If you were to rely on content filtering or scanning to mitigate a sustained attack, not only would your resource costs be far greater, but the attack could potentially melt your email infrastructure under the sheer load of the attack volume.
Moving blocklists to the top of your email anti-abuse stack means that far fewer messages are likely to reach the more expensive content filtering stages.
Additional benefits of rejecting at the SMTP connection
The real-time rejection of an email at the SMTP handshake has another benefit. It means a Delivery Status Notification (DSN) can be returned to the sender, providing immediate feedback if a message has been rejected. This can help with debugging any mail relay problems from the sender’s end.
Other means of processing and scanning of email don’t always provide this feedback during the SMTP connection. These methods will usually operate after the connection has closed, and if they do determine a message is spam, they may try to return it to the sender address in the message header. In the instance where a header is forged, a rejection can have the unintended consequence of flooding an innocent third party’s email infrastructure.
Alternatively, these processes may simply collect the suspected spam in a folder within your mail system, adding to infrastructure costs due to the additional storage and indexing.
From an end-user’s perspective, Spam Folders can become redundant, receiving hundreds if not thousands of messages a day. With such volume it’s almost impossible to find the one email that isn’t junk but ended up there. Additionally, let’s not forget the fact that the sender has no idea that the message hasn’t reached its intended recipient.
Where else should blocklists be applied?
Content blocklists, including domain and hash blocklists, should also be applied at the content filtering stage, to provide an additional layer of protection. We also recommend using domain blocklists at the SMTP transaction too, but to keep things simple we’ll focus on the content filtering stage.
Here you can query your email content against spam, phishing, and malware domains and from newly registered domains, which under normal circumstances would rarely send out emails within the first 24 hours of registration.
Meanwhile, hash blocklists will help you filter fraudulent emails coming from ISPs, domains, or IP addresses that blocklist providers are unable to list, for example, Gmail. In addition to this, they also can list malware files within seconds of researchers observing them.
For a full outline of what blocklists to apply to email source code, take a look at Where to apply Spamhaus blocklists for effective email filtering.
That’s all folks
Thanks for joining us on our journey into the world of DNSBLs and happy filtering!
WEBINAR — DNS Blocklist Basics
Register for our upcoming free webinar to learn more about DNS Blocklists, happening on Thursday, 26 November from 16:00 (UTC + 10).
DNSBL experts Carel and Skull will walk you through all the blocklist basics from how they’re compiled, to how they work, and how to use them in your email infrastructure.
Gianmarco Pagani is passionate about large-scale Internet threat management and email security.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.