Overview | Configuration Variables | Blocked Spammers | Whitelists | Blocklists | Pattern Matching Filters

The SpamBouncer

Blocklists
Supported by the SpamBouncer

This page contains a description of all blocklists supported in the SpamBouncer, and hyperlinks to the blocklist's web page so that you can learn what the blocklist maintainer has to say about blocklist policies and practices. For more information about blocklists in general, what they are, and what they do, see the Filtering page in the About Spam section of the SpamBouncer web site. For more information about any individual supported blocklist or blocklist family, click the heading for that blocklist to go to its home page.

Contents


The Abusive Hosts Blocklist (AHBL) Family

The Abusive Hosts Blocklist (AHBL) family is one of the most aggressive groups of blocklists supported in the SpamBouncer. They're also aggressively maintained and the operators are responsive when contacted. (They seem especially proud of lawsuit threats from people whose IP blocks and/or domains they've listed and post those prominently on their web site.) I would like to see a clearer statement on the web site of their overall spam philosophy, but I guess it's a bit much to ask that geeks spend time on documentation when they could be catching spammers. <G>

None of these blocklists is enabled by default because they are so aggressive. If you whitelist aggressively, however, you can safely use the AHBL blocklists and catch quite a bit of spam with them. The AHBL itself provides a whitelist especially designed to be used with its blocklists; the AHBL exemptions list. You should also use your .legitlists and .nobounce files (your local whitelists) heavily if you enable any AHBL blocklists.

Return to Table of Contents

The Blitzed Open Proxy Monitor (BOPM) Blocklist

The Blitzed Open Proxy Monitor lists open proxies of all kinds, including those created by trojan software. Spammers use open proxies to send spam while hiding the origin of that spam. The BOPM itself is disabled by default only because the SpamHaus XBL, which is enabled by default, contains the BOPM and other, similar data in a single blocklist, making it more efficient to check the XBL. If you prefer to check the BOPM directly, you can enable it by setting OPMBLITZEDCHECK=yes in the variables section at the top of your .procmailrc file.

Return to Table of Contents

The Composite Blocklist (CBL)

The CBL lists open proxies, many of them trojaned and compromised hosts that run open proxy software that spammers use to send spam while hiding the origin of that spam. It is probably the single most effective blocklist in existence at present. Used properly, it catches well over 80% of spam. (At least, that's true of the spam that comes into the SpamBouncer spamtrap.)

The CBL itself is disabled by default only because the SpamHaus XBL, which is enabled by default, contains the CBL and other, similar data in a single blocklist, making it more efficient to check the XBL. If you prefer to check the CBL directly, you can enable it by setting CBLCHECK=yes in the variables section at the top of your .procmailrc file.

Return to Table of Contents

The Completewhois Blocklist Family

The Completewhois family of blocklists list IPs that send no legitimate email, and that shouldn't be sending email at all. These blocklists are aggressive, and at times have contained listings that were in error and caused false positives, so they are disabled by default. If you use them with caution, however, they can be useful.

Return to Table of Contents

The DSBL Blocklist Family

The DSBL blocklist family has closed. Please disable this blocklist in your SpamBouncer configuration; it will be removed from the next release.

Return to Table of Contents

The Five-Ten Software Group (FTSG) Blocklist Family

The Five-Ten Software Group (FTSG) blocklists are probably the most aggressive that the SpamBouncer supports. The maintainer considers sending bulk email to any email address that has not opted in using a closed-loop confirmed opt-in (COI) process ("double opt-in" for you marketers) to be spamming. As I understand it, the maintainers are accessible and communicate their standards clearly, however, so if you use these lists and find them too aggressive, that's your problem. <wry grin>

None of these blocklists is enabled by default because they are so aggressive. If you enable any of the FTSG blocklists, you should whitelist aggressively. You might want to use the AHBL exemptions list in addition to religiously listing any regular correspondents in your .legitlists file (for mailing lists) and .nobounce file (for personal email).

The Invaluement Blocklist Family

The Invaluement blocklist family consists of three blocklists: a conservatively-run blocklist of single IPs that send spam, a more aggressive blocklist of /24 CIDRs that send significant amounts of spam, and a URI blocklist similar to the SURBL and URIBL blocklist. It is a business, not a free service, but the fee structure is reasonable for individual users, small home networks, and small businesses.

These blocklists are new as of 2008, and were created by long-time antispam activist Rob McEwen. McEwen has several good ideas that have led to a blocklist that catches a considerable amount of spam from spammers that often escape listing and filtering, especially mainsleaze spammers and "snowshoe" spammers. I have not used this blocklist yet because Rob has not got public DNSBLs set up for his users, but a number of other antispammers of my acquaintance have downloaded his data and included it in their local blocklists. They have gotten very good results.

I look forward to seeing what these blocklists can do with the next SpamBouncer version!

Return to Table of Contents

The NJABL Blocklist Family

The NJABL blocklist family is a good, conservative and well-maintained group of blocklists. Two are enabled by default, and the others are not primarily because enabling too many blocklists slows the SpamBouncer down.

Return to Table of Contents

The Open Relay Database (ORDB) Blocklist

Blocklist of single-stage open relays. It tests SMTP servers on request, and lists those that are open relays. The ORDB is somewhat more aggressive than the DSBL, and also more narrowly focused, since it lists only open SMTP relays, not open proxies, compromised hosts, or web servers with insecure CGI. It is probably the largest and most widely used list of open relays on the Internet.

It is disabled by default. You can enable it by setting ORDBCHECK=yes in the variables section at the top of your .procmailrc file.

Return to Table of Contents

The RFC Ignorant Blocklist Family

The RFC Ignorant blocklists are unique -- they target computer systems and services that do not properly implement the RFCs (the "building blocks" of the Internet), rather than those that send spam. The theory is that systems that do not implement the RFCs properly often are misconfigured in other ways and therefore easily abused by spammers. In addition, many of these systems lack any publicly available, valid email addresses that you can use to contact the system administrator when there's a problem.

In my experience over the years, there is some overlap between the systems listed in one or more of the RFC Ignorant blocklists and systems that send spam. Unfortunately, there are also a lot of mail systems that violate one or more of these RFCs and yet do not send spam and do respond to spam complaints. I expect that the RFC Ignorant lists will be extremely helpful for certain types of spam reporting as that feature develops and is implemented in SpamBouncer 2.1 and following, but they are aggressive and prone to false positives when used to block email.

If you enable the RFC Ignorant blocklists, you should whitelist aggressively. You might want to enable the AHBL exemptions list, in addition to whitelisting your regular correspondents locally using your .legitlists file (for bulk email) and .nobounce file (for personal email).

Return to Table of Contents

The SORBS Blocklist Family

The Spam and Open Relay Blocking System (SORBS) blocklists are among the most aggressive that the SpamBouncer supports. The maintainer has little or no patience with mail systems that hesitate to remove spammers or take any necessary measures to secure their systems against abuse by spammers. The web site states a policy of requiring systems correctly listed for spamming or failure to secure their systems against spammers to pay a fee under some circumstances to get unlisted. I'm not entirely comfortable with this, although I have been told by people I trust that the maintainer is conscientious, fairly easy to work with otherwise, and applies the fee only in circumstances when the listed system was clearly at fault.

On the unambiguously positive side, SORBS operates a wonderful set of open proxies blocklists. It has three of them, all well-maintained and helpful in stopping spam. Even users whose personal standards of spamminess are considerably more conservative than those of SORBS are likely to find these lists helpful if the SpamHaus XBL and NJABL Open Proxies lists do not catch all of the open proxy spam coming into mailboxes.

None of these blocklists is enabled by default because they are so aggressive. If you enable any of the SORBS blocklists, you should whitelist aggressively. You might want to use the AHBL exemptions list in addition to religiously listing any regular correspondents in your .legitlists file (for mailing lists) and .nobounce file (for personal email).

Return to Table of Contents

The Spamcop Blocklist

The Spamcop blocklist contains the IPs of mail servers that its users report were used to send spam recently. It is an "early warning system" blocklist, prone to false positives, but also frequently containing spamming IPs that have not made it into the more conservative blocklists yet. It was founded by Julian Haight, and is currently owned by Ironport Systems, a manufacturer of high-end mail servers that also operates the Senderbase email traffic monitoring system. You should use the Spamcop blocklist with caution, but you can use it to good effect if you whitelist aggressively.

It is disabled by default. You can enable it by setting SPAMCOPCHECK=yes in the variables section at the top of your .procmailrc file.

Return to Table of Contents

The SpamHaus Blocklist Family

SpamHaus is highly respected, and deserves to be for a number of reasons, only one of which is the blocklists it runs. SpamHaus follows a conservative policy to minimize false positives when listing spam sources, although a low false positive rate should be expected when using the SpamHaus Blocklist (SBL). It is one of the three most useful blocklists the SpamBouncer supports, and one of the other two is the SpamHaus eXploits Blocklist (XBL). The two together catch by far the majority of spam.

Return to Table of Contents

The SPEWS Blocklist

The Spam Prevention Early Warning System (SPEWS) blocklist has closed. Please disable it in your SpamBouncer configuration. It will be removed from the next release.

The SURBL Blocklist Family

The SURBL blocklist family is the first of a growing group of blocklists that lists, not IPs or domains in the headers of spam, but IPs and domains found in the message bodies of spam. These IPS and domains normally belong to the spammers, and are used as URLs to web sites owned or operated by the spammers. There are six SURBL blocklists at present, each representing data taken from a different source. The SURBL blocklists are conservative -- their stated aim is "no false positives," meaning that no false positives should be caused by reliance on any listing on any SURBL. My experience is that false positives traceable to a SURBL listing are, in fact, extremely rare. In addition, SURBLs catch a truly amazing amount of spam.

The SURBLs are the most useful and effective blocklists in the SpamBouncer other than the SBL and XBL. All six SURBL blocklists are enabled by default.

Return to Table of Contents

The Trend Micro MAPS Blocklist Family

The Trend Micro MAPS blocklist family was the original DNS-based blocklist family, back in the depths of Internet time. (Eight or nine years ago.) <G> Originally a free service, the first of its lists -- the venerable MAPS RBL -- was developed by Paul Vixie. It was probably the single most effective tool against spam at the time. Understandably, it attracted a lot of spammer ire, and a great deal of community support.

Some years ago MAPS went commercial and private, Vixie left, and it was taken over by others under circumstances that remain murky, but were clearly unfriendly. At least two lawsuits were involved, and many (most) of the original MAPS crew left. (To their credit, most remained active in anti-spam work.) The SpamBouncer supported MAPS near its inception, and the code to support its blocklists remains, although I have been unable to test that code for years and cannot guarantee that it will work.

NOTE: You must have a subscription to MAPS and Trend must have configured the MAPS servers to allow access to the server running the SpamBouncer, or none of the MAPS blocklists will work.

Return to Table of Contents

The URIBL Blocklist Family

The URIBL blocklist family lists, not IPs or domains in the headers of spam, but IPs and domains found in the message bodies of spam. These IPS and domains normally belong to the spammers, and are used as URLs to web sites owned or operated by the spammers. It was started in early 2005 by SARE members Chris Santerre and Dallas Engelken, and others who wanted a SURBL-type blocklist that was less conservative and allowed a larger degree of public participation.

Unlike the SURBL lists, the URIBL lists are not divided by data source, but by expected level of risk associated with blocking based on a particular domain or IP. The URIBL lists are URIBL Black, URIBL Grey, and URIBL Red. Although the URIBL is more of a grass-roots operation than the SURBL, in practice I have not seen a significantly greater rate of false positives from the URIBL Black list than from the SURBL lists, and it has a policy of "no false positives" as well. The URIBL Grey list contains domains and IPs that belong to companies that are involved in spam, but appear in both spam and legitimate email. If you use this list, you should expect a certain rate of false positives. The URIBL Red list contains domains that have the same registration information as domains in the URIBL Black list. It is risky, and should be considered experimental at present.

Return to Table of Contents