Reputation: It Isn’t Black or White

Blocklists have come a long way from the early days of simple “yes” or “no” decisions – new resources to classify, reputation grey areas, and a need for a deeper understanding of context. Choosing the right blocklists, understanding their listing policies, and applying them appropriately is more than a technical task – it’s a strategic decision. 

DNSBLs: In simpler times

Over 20+ years ago, “binary only” DNS-based blocklists (DNSBL) were a revolutionary breakthrough in online threat detection. It all began with IPs – the foundation of early blocklists. If an IP was listed, you would block it and no longer accept mails from it. Although simple, they didn’t come without challenges. When you block mail from an IP, every domain sending from that mail server is impacted – not just the one that was hacked and started sending spam, malware, or phishing.

Today, the blocklist landscape has evolved dramatically. They are far more flexible and powerful than ever:

• They go beyond just IP addresses, listing a wider range of resources (malware files, crypto wallets, email addresses, and URLs) based on different policies.
• They often include reputation scores and additional context, such as a domain’s age or the reason it was listed.

In an era of short-lived domains, malicious content hidden behind hacked legitimate websites, and the abuse of services like URL shorteners, this level of flexibility isn’t just useful – it’s essential.

While blocklists have evolved, they can still contain resources you may or may not want to block, depending on your specific use case and local policies. Each type serves a different purpose in the fight against online threats. Understanding and using them correctly, however, is a different story.

More resources to classify: A targeted approach

Classifying resources beyond just IPs or even entire networks allows for more targeted blocking. The increased precision helps reduce false positives, minimizes the impact on legitimate use cases, and can lead to fewer support requests. 

It’s common to block and filter based not only on IPs, but also on domains and even specific message elements like URLs, email addresses, crypto wallets, or file hashes. For instance:

URLs: URL blocking is a great example of targeted filtering. It allows you to block messages containing a specific URL path on a hacked domain. Links to the legitimate content remain unaffected, along with any other domains or services hosted on the same server. 

Email addresses: Filtering by email address allows you to target a specific spam-sending mailbox without affecting the entire domain. You can check for matches during the SMTP dialog to reject a message before it’s accepted, or match parts of the message content later to move it into the spam folder. In some cases, depending on your jurisdiction, you may even reject it, based on the message content. 

The earlier a message is rejected, the more efficient and cost-effective the filtering process is. Domain-based lists are a valuable addition to traditional IP lists, as domain information is available early in the SMTP dialog: such as the MAIL FROM domain, the HELO, and the reverse DNS of the sending IP. 

In addition, you can also build local statistics by domain, analyzing sending patterns and spam complaints to inform filtering decisions. However, IP listings can still play an important role, to escalate blocking further when needed.

Blocklists: The “grey area”

Many blocklists are effective at detecting threats early. By identifying known attack patterns, they can detect suspicious IPs and domains during the preparation of the attack, before any actual abuse begins. However, not everything can be detected in advance. 

This is where the grey “reputation” area comes into play. Some domains are not clearly malicious but they haven’t yet earned trust.

For instance, allowing unlimited mail flows from a newly registered domain (zero reputation domain) is a risk. Why would a brand-new domain suddenly send large volumes of emails shortly after registration? At the same time, blocking might not be right, as it still might be legitimate. 

To address this, special blocklists exist to deal with “grey-area” domains. They can be used to apply rate limits, giving time to monitor incoming traffic, and more accurately classify the domain. If users mark the incoming email as suspicious, it can help inform the reputation score of the domain. 

Another valuable use case of modern blocklists is post-delivery warning messages. An email might be delivered successfully, but when a user opens it later and clicks on a message in your app or web frontend, another scan using updated domain or URL lists can trigger warnings. These can be shown in the message view or in your dereferer when the user clicks a link in the message. 

Blocklists have developed into cyber threat intelligence (CTI) feeds that go far beyond email filtering:

• Registrars and registries can use them to investigate and suspend domains.
• Hosting providers can detect misbehaving servers on their networks.
• Network operators can apply domain-based blocklists at the DNS level to prevent malware-infected machines from contacting command and control servers or phishing web sites. 

As these examples show, the use cases and impact are broad. Choosing the right lists and knowing how to use them effectively comes down to understanding their listing policies.

Choosing the right blocklist: listing policies

Selecting the right lists with policies that match your use case is where the challenge lies. For example, using zero reputation domains as a hard blocklist would prevent those domains from building a reputation based on their content or user feedback. Such lists are often better used for rate limiting, rather than outright blocking.

Blocking email from end-user IP ranges (where no legitimate mail server should operate) is a sound policy for email filtering. However, using the same lists to block logins or signups would lock out many legitimate users.

Other lists might provide a domain reputation score. In these cases, you need to think about which score (or classification) to use as a threshold for your blocking policies, or how to combine it with other signals to make an informed decision. 

In short, understanding the purpose and policy behind each list – and aligning it with your specific needs – is essential for achieving reliable and accurate filtering.

Sven Krohlas is a detection engineer at Spamhaus Technology, responsible for detecting phishing attempts and assessing new contributors on the Spamhaus Threat Intel Community portal. With almost ten years of experience, Sven started his career in the email security team of a large mailbox provider. Afterward, he joined a German provider specializing in taking down malicious websites.

Interesting fact: Sven is a member of Retrogames e.V. and a self-confessed retro gaming addict who owns hundreds of retro games!