Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://www.spamhaus.org/whitepapers/dnsbl_function/ below:

Email Security | BEST PRACTICE | DNSBLs and email filtering

Domain Name System Blocklists (DNSBLs) are a low-cost and effective way of stopping the torrent of inbound email traffic associated with spam and other malicious emails.  There are multiple benefits to using blocklists, reducing infrastructure costs, and workforce hours to increasing catch rates.  However, to get the most from DNSBLs, it’s vital to use them at the right points in your email filtering process.

There’s a wide range of email security options for your infrastructure, from content filtering and scanning to network-based tools that use distributed and collaborative methods.

Unfortunately, the majority of the above are resource-heavy and expensive.  The key to email filtering is to remove the bulk of unwanted emails right at the beginning of the process before they reach the resource-intensive content inspection stage.

A DNSBL check is the simplest, quickest, and most economical method you have at your disposal….so why not use it?

When you accept and process an email, there are three areas that you should use blocklists:

1. At the initial connection – against the connecting IP.
2. Throughout the pre-data phase of an email, i.e., the SMTP transaction
3. Once the email data has been accepted i.e., during content inspection

• Saves on bandwidth – you significantly reduce the number of messages that require downloading.

• Saves on open connections – many connections are not needlessly held open.

• Saves on storage activity – rejection before content filtering doesn’t use any storage resources (with the exception of a few logging lines).

• General reduction in memory, storage, and CPU requirements – you have a far lower volume of emails that require expensive content scanning.

At the very beginning of an email transaction, a remote server attempts to initiate a connection with your server.  At this point, a quick lookup (query) to a blocklist can instantly (well, almost instantly) advise if the connecting IP address is associated with malicious behavior or not.

If the IP address is listed, you can choose to drop the connection immediately.  Remember, this query is undertaken even before the Simple Mail Transfer Protocol (SMTP) handshake occurs.

• Spamhaus Blocklist (SBL)
• eXploits Blocklist (XBL)
• Policy Blocklist (PBL)

For all email commands that occur after the initial email connection set-up (as detailed above) and before the DATA command during the SMTP connection, we term as the pre-data phase.

Once the connection is open, you (the receiver) should do a reverse DNS lookup of the connecting IP address.

The result of the above lookup should be queried against the domain contained in the HELO from the sender, e.g. (HELO mta-out.someisp.example). If they do not match, the connection should be dropped immediately.  This is an indication that the sender isn’t who they say they are e.g. spoofing.

The domain returned should be queried against the DBL and the ZRD.

The domain contained in the HELO should be queried against the DBL and the ZRD, alongside running a forward DNS lookup against the SBL.

Subsequent to the HELO, during the SMTP connection, is the MAIL FROM command.  This is often referred to as the “Envelope-from” or the “Return-path.” You should query the domain included in this string, e.g., user@someisp.example

Whenever a query is made against the DBL and ZRD and a positive response is returned, receivers can reject the email or tag it for further inspection during the content filtering process.

Once the RCPT TO command has been completed, the DATA command follows, and it is this that initiates the transfer of data, both the email header and content. After the receiver confirms this has been successfully executed, the sender transmits a QUIT command, either before or after content inspection, and the connection is closed.

This comes down to both your implementation decisions and software choices.  As with all options there are pros and cons for both:

Some implementations choose to keep the connection open, until they have the result of the content inspection.

Pros: Senders will always be notified of a rejection, which is the best strategy should false positives occur.

Cons: This is resource heavy and your MTA must be up to the task, even during peaks. Where resources are not sufficient delays may occur.

The majority of implementations close the connection before content inspection.

Pros: Lowers costs due to lower resource requirements.

Cons: Where false positives have occurred, the sender will not be notified.

As previously mentioned, content filtering and scanning are resource heavy. Reducing the number of emails that reach this point of the email filtering process saves on memory, reduces processing power and reduces latency.

Consider a situation where you receive hundreds of messages per second during a sustained or escalating spam campaign.  If you are reliant on content filtering or scanning to mitigate the attack, your email infrastructure has the potential to collapse under the load put on it by the sheer volume of inbound emails.

If you’re lucky enough for this not to happen, you will still incur high costs, as every email needs to be downloaded and scanned.

When an email is rejected at the initial connection or SMTP handshake, a Delivery Status Notification (DSN) is returned in real-time to the sender, advising them of the failed delivery.  From a sender’s perspective, this can help with identifying and resolving mail relay problems.

As a result of emails being rejected early on in the email transaction, potentially spammy emails aren’t downloaded and left, forgotten in a junk folder.  This stops end-users from hunting through their junk folder to find one legitimate email out of hundreds, if not thousands of spam ones.

If the sender address is forged, the innocent third party whose email was used in the forged sender address will be flooded with return messages.

Using domain blocklists as well as IP blocklists provides you with extra protection against hailstorm and snowshoe spam, in addition to other threats. For a deeper understanding of this subject matter, we suggest you read MTA developers: allow use of domain DNSBLs at the SMTP level.

It’s worth remembering that our domain blocklist will contain many domains before they’re seen in the wild!

Once the DATA command has run and the email header and content have transmitted to the receiver, content inspection commences, alongside running SPF, DKIM, and DMARC checks.

Email headers contain structured data making them far less resource-intensive to parse compared to that of the body of an email. To get a deeper understanding of an email header and body components, read Understanding the source code of a malicious email.

Here’s where blocklists can be used during the header inspection:

This is the IP address contained within the original transaction’s received chain, i.e., what initially generated the email.  This lookup can be done against the SBL and AUTH BL. An rDNS lookup can also be done against the DBL & ZRD.

The full email address in this field should be queried against the Hash Blocklist (HBL), which contains cryptographic hashes of email addresses.

Commonly referred to as the “Friendly From” address, it should be queried against the HBL, and the domain contained in it should be queried against the DBL & ZRD, with a forward DNS lookup against the SBL.

Finally, we’re onto the inspection of the content (scroll up to think of all the opportunities you have had to reject email before it reaches this more expensive part of the email filtering process!)

Website URLs or emails in the body content should all be queried against the DBL, ZRD, with a forward DNS lookup against the SBL.  Emails contained within the email body can also be queried against the HBL.

Query these against the HBL, which has a cryptowallet section containing hashes of bitcoin and other cryptocurrency addresses.

All attachments should be queried against the HBL, which lists malware files, in addition to email addresses and cryptocurrency addresses.

Sadly, with so many variances it’s not possible to cover all the specific operational details for different mail systems.  Where some of our checks can’t be implemented, we recommend reaching out to the support desk of the product you are using.

The good news is that we do have two plugins for opensource filters, SpamAssassin and Rspamd, for both pre-data (SMTP) filtering and content analysis.  Also here’s the full outline of what blocklists to apply where.

If you’d like to trial DNS Blocklists and run your own email server – then sign up to access the data free for 30 days. We’d love to hear how you get on.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3