1. You are relying on the judgement of a third party (whom you've very likely never met) to decide whether a MailServer^? is truly guilty of sending spam. Although most DnsBlackholeLists are reputable, imagine the ensuing havoc if they changed their DNS system so that it returned a positive answer for any incoming query; your system would bounce mail from every system on the InterNet. Now, imagine that this is a great group of people, and that they'd never do something like that. Keep in mind, though, that their very existence infuriates a large group of well-financed "people": spammers. Suppose that an irate spammer were to pay a cracker to access their systems and make that change in order to destroy their reputation. In either of those cases, are you prepared to deal with the consequences?

1. If the netblock grows to cover the entire ISP, then they escalate the process by reporting the incident to the ISP's UpstreamProvider^?. Go back to step two and replace "ISP" with UpstreamProvider^?. Repeat the process until somebody finally handles the situation, or they blacklist the entire InterNet.

Why Base It On DNS?

Suggestions

Ones I like

These are the lists that I personally use on my own servers, and that I recommend to my clients. They have a history of reliable service, a decent "hit rate", and a low false positve rate.

• Open Relay Database (relays.ordb.org)
  • This is a list of proven OpenRelays^?. They are responsive to removal requests.
• Distributed Server Boycott List (list.dsbl.org)
  • Lists mailservers that delivered mail to a special HoneyPot^? address. Only servers that have directly sent spam to this system are recorded.
• Spamhaus Block List (sbl.spamhaus.org)
  • Updated continually throughout the day to block spam outburts as they happen.

Ones I avoid

I recommend staying away from any list that advertises itself as being affiliated with, or including the contents of, the SPEWS blacklist. This group responds to spam reports with a simple algorithm:

1. They list the IP address or NetBlock^? of the spammer and send a report to the ISP.
2. If the ISP does nothing to prevent further bulk mailings, then they increase the size of their listing to include more and more of the ISP's entire NetBlock^?, including all of the ISP's non-spamming customers.
3. If the netblock grows to cover the entire ISP, then they escalate the process by reporting the incident to the ISP's UpstreamProvider^?. Go back to step two and replace "ISP" with UpstreamProvider^?. Repeat the process until somebody finally handles the situation, or they blacklist the entire InterNet^?.

One the one hand, I can sympathize with their goals. Their theory is that by increasing the size of the CollateralDamage^? of their blacklist, someone will eventually put enough pressure on the offending ISP to make them fix the problem. Unfortunately, they can (and do) end up blacklisting entire communities who are far-removed from the original spam broadcast and who have little direct power to do anything about it. Because of this, I can't recommend using SPEWS or their affiliates. Their hit rate is good, but the false positives are just too high.

What Is It?

A DnsBlackholeList is a method of configuring your email server to block messages from servers that are believed to have directly sent spam, or have relayed spam because of intentional or unintentional misconfiguration.

How Does It Work?

Private organizations administer DnsBlackholeLists. Whenever they detect a server with a spam problem (either by proactively probing MailServers^? on the InterNet^? or by receiving an email complaint), they take technical steps to verify that the server is, in fact, a source of spam. Once they've done that, they make a DNS entry for that MailServer^?'s IP address under their own domain name. For example, suppose that the offending server's IP address is "23.45.67.89", and the DnsBlackholeList is "badmailer.org". They would make an entry for "23.45.67.89.badmailer.org" in their ZoneFile^?.

Whenever a MailServer^? tries to deliver a message to your local server, your server will attempt to look up a DNS entry based on the sending server's IP address and the DnsBlackholeList you've decided to use. If it is able to resolve the address, then the MailServer^? has been listed as a source of spam, and your server will refuse to deliver the message.

Why Base It On DNS?

The brilliant part of this setup is that it uses the global DNS system as a cache for the information. If 50 MailServers^? from the same InterNetServiceProvider^? are all contacted by the same spam source, the ISP's DNS server would remember the results of the first query, and would return those results to the other 49 servers. That way, the DnsBlackholeList's DNS server would only by queried one time (rather than 50 times).

Good Points

A good DnsBlackholeList is rather effective. By blocking all email from systems known to transmit spam, you can seriously decrease the amount of spam sent to you and your users.

Even if your MailServer^? is configured to FilterMailWithSpamAssassin, this is still a good first-line defense. SpamAssassin is very, very good at its job, but since it has to compute spam probabilities from a long list of pattens for every incoming email, it can use a lot of processing power on a busy email system with many users. Putting a DnsBlackholeList before SpamAssassin means that SpamAssassin will have to process many fewer emails, which enables the system to handle a much higher amount of traffic.

Bad Points

There are two, really:

1. You are relying on the judgement of a third party (whom you've very likely never met) to decide whether a MailServer^? is truly guilty of sending spam. Although most DnsBlackholeLists are reputable, imagine the ensuing havoc if they changed their DNS system so that it returned a positive answer for any incoming query; your system would bounce mail from every system on the InterNet^?. Now, imagine that this is a great group of people, and that they'd never do something like that. Keep in mind, though, that their very existence infuriates a large group of well-financed "people": spammers. Suppose that an irate spammer were to pay a cracker to access their systems and make that change in order to destroy their reputation. In either of those cases, are you prepared to deal with the consequences?
2. If you make your living as a SystemAdministrator^? who does consulting work for several companies, imagine this scenario: a customer is trying to send you an email because their MailServer^? was misconfigured and they've been added to various DnsBlackholeLists, and they want to pay you a small fortune to fix their system. Your server bounces that email because their server happens to be listed in the DnsBlackholeList you use on your own system. Your customer gets upset and goes to someone else for help.

In the latter case, I think you can explicitly list your customers' domains in your SendmailAccessFile^?, and that the file is processed before any DnsBlackholeLists, so that you will always accept email from their servers regardless of whether they are listed as spammers. Please verify this for yourself before relying on my guessing to protect you from lost income.

In the former case, there's not much you can do but search UseNet^? and TheWeb^? to get an idea of a particular DnsBlackholeLists's reputation before you begin to use them, and periodically thereafter to make sure that their goals and methods are compatible with your purposes.

Summary

If you do your homework, a DnsBlackholeList is an excellent way to reduce the amount of spam your system has to deal with. You can use one (or more than one) by itself or with another method (see: FilterSpam). Be sure you understand the implications of using such a system beforehand.

-- KirkStrauser - 31 Mar 2003