The following is my opinion. While I am not alone in thinking these things, you may feel differently. I will present the facts and editorialize... and I'm sorry. But this is something I feel rather strongly about. Take this information or leave it. Ultimately, it doesn't matter because you can implement your mail gateway however you want.
A Realtime Blackhole List (sometimes refered to by the more "politically correct" term Relay Blocking List), or RBLs, are lists that contain IP addresses or IP spaces which are to be used by mail systems to block potential spam. Each e-mail a system receives is checked against the RBL. If the e-mail originates from an address or space contained inside the RBL, the e-mail is assumed to be SPAM (it is bounced, dropped, tagged, etc.)
Originally, RBLs were created by individual sysadmins on a case-by-case basis. As the internet grew, and SPAM become more and more of a problem, an RBL community was formed. Before long, due to conflicts within the community, several RBLs split off to form different factions. Today, there are more than 30 free RBLs with different content, maintainers, and implimenations.
RBLs are the most common SPAM-fighting tool in use today. However, as we shall see, they are not exactly the best tool for the job.
RBLs are Bad, M'Kay
RBLs have a number of significant shortcomings that should be considered before using them in your network. Some of these shortcomings are:
Collateral Damage and Legitimate Users
Perhaps the biggest problem with RBLs is the collateral damage caused to legitimate users. Consider an ISP with thousands of subscribers. This ISP may have a very strong anti-SPAM policy. However, because they do have so many subscribers, and because a subscriber's account can be easily compromised, it becomes very difficult for the ISP to deal with SPAM complaints in a speedy fashion. This can become even more complicated for ISPs providing dial-up as their user may be located in a foreign country.
Often, RBL maintainers will become impatient with how slow it can take for an ISP to respond, and will simply drop their SMTP server (or servers) into the RBL. This will stop the spammer abuse, but it will also block a large portion of legitimate mail sources.
The response from RBL maintainers is that the users of such an ISP should complain to their ISP until their ISP "changes their ways" or switch ISPs. Persons working on mail networks that utilize such RBLs should inform their contacts of the problem and complain to the ISP with them. Thus, the brunt of the responsability falls on the shoulders of innocent users. In many cases, the users will not have the technical know-how to confront such issues. In others they will not have an option for an alternative ISP (besides, who's to say that some alternative ISP isn't being blocked by another RBL). In most cases, the users will simply think that the procedure isn't worth the effort and decide to take their business elsewhere.
"If you had a mail system that rejected all inbound emails, you would not have a very useful mail system. Likewise, as RBL lists grow in size and their use amongst mail system administrators increases, their value diminishes."
Geopolitics and Blackholes
A huge amount of SPAM is being sent through unsecured relays in Asia and South America. Most of these relays are associated with ISPs and also relay a huge amount of legitimate e-mail. An overwhelming amount of address spaces listed in RBLs are relays originating in these countries. Thus, using an RBL can effectively wall your mail system off from entire geographic regions. (See the Wired article, [Not All Asian E-mail is Spam])
Invisible Authorities
Perhaps the biggest concern for you, as a system administrator, is that by using an RBL you are relying upon an "Invisible Authority" to make security decisions for your network.
There have been cases where RBL maintainers have intentionally blocked IPs of legitimate sources to censor or silence. There is a well documented case where one of the most popular RBLs actually blocked the IPs of the competitors of the project maintainer's business, blocked a non-profit organization dedicated to fighting "censorware", and blocked Amnesty International.
Appeals and Corrections
A big problem with most RBLs is that it is very easy to get on them, but very hard to be removed. In essence, getting on to most RBLs means being tagged a spammer forever.
In some cases, RBL maintainers place unreasonable requirements for you to be removed from their list (from http://www.sandes.dk/abusers/)
E-mail addresses and domains are removed from the sandes.dk blocking lists when they are no longer valid. Networks and hosts are delisted when they are disconnected permanently or when they are no longer owned by the abusers. Blacklisted ISPs and website hosting providers may be delisted if they stop providing support for spammers, but this is only done exceptionally and takes at least six months.
In other cases, you are considered guilty as aiding spammers forever and without appeal (from http://www.blackholes.us/)
Please note that you cannot be removed from the list. Unless you give me a compelling reason not to, I may ignore your removal requests.
Reliance on Unknown Third-Party
This is another big reason. Whomever is maintaining your RBL may be flaky, unreliable, or even a complete nut. Sometimes entire RBL sources go inactive, which may result in your server blocking the entire world. [Here] is a story on Slashdot detailing a situation where this happenned for one of the most widely used RBLs.
Alternatives to RBLs
The main alternatives to RBLs consist of SPAM filtration based upon a per-message analysis. This can be resource intensive (and, is in fact, the reason most grey beard sysadmins will not use them), but will yeild considerably fewer false positives when set up correctly and be much less of a hassle to system administrators and users alike. Besides, with hardware as inexpensive as it is today, resources such as CPU speed and system memory are not as big of a concern.
We will now examine a setup using per-message filtration. We will also setup our system to filter viruses easily when and if an anti-virus scanner is "snapped" into the system.
