An RBL is a Realtime Blackhole List, also known as a block list or black list, containing IP addresses of spammers, suspected spammers, netblocks belonging to ISPs deemed friendly to spammers, lists of IPs assigned to dial up accounts, and servers allowing an open relay. There are more than 150 RBLs available and they vary in how successful they are at blocking unwanted email. The less restrictive ones will be less effective, possibly to the point that it's not worth using while the most restrictive ones can hamper your ability to receive email from your customers.

RBLs were originally used to block open relays to mail servers, which were often used by spammers. In general, this was good. It worked, it eliminated spam and when an open relay was closed, the server was removed from the list. Now, it's all too easy to get on an RBL, often for what seem like silly reasons, and it can take years to get off an RBL.

Case in point, just visiting any page at dsbl.org using Internet Explorer can get your IP on their list. This warning is on the homepage:

"You seem to be accessing this website with a web browser susceptible to a security vulnerability. Proceeding to any other page on this site may cause you to list your IP address in DSBL. We highly recommend that you switch to a secure browser and/or pressure your current browser vendor for a fixed version."

However, if you access it using a bookmark or outside link, you won't see the warning and may find yourself on the RBL. While this shouldn't affect larger organizations who use different IP addresses for email and internet access, smaller companies with just one IP address may find themselves on this block list, regardless of how tightly locked down their network and mail server is.

Getting off this RBL is much more difficult than getting on it was. But as bad as it was, it could be worse. Some RBLs, such as blars.org, charge upwards of $1000 just to ask to be removed from their lists. You'll have a difficult time learning why you are even on the blars list because they prevent addresses on their block list from accessing their site. It's not surprising that many companies find its easier to get a new IP, one that's not on any RBLs.

SpamCop's RBL is easy to get on and get off of because addresses are on it only as long as they continue to get reports of spam originating from the IP address. Once the reports stop, the address is removed from the database. While this works well most of the time, since any level of user can report spammers to SpamCop, errors can and do occur. All it takes is someone using a backup mail service to report spam that is forwarded through their backup mail service to cause all messages that are routed through that server to bounce for several days. While it's humorous when someone inadvertently adds their own mail server to the RBL, it causes problem for the other users of the service who know better than to report spam received through the same backup mail service.

Rfc-ignorant.org's RBL is a list of IP addresses which are not following RFC's in their Whois, DSN, abuse and postmaster configurations. This can include things like missing or incorrect email addresses for the registrant's contact person, as happened with Sprint. Several Sprint netblocks were on rfc-ignorant's list for years while some Sprint subsidiaries used that same RBL to block spam, effectively preventing some Sprint subscribers from emailing Sprint-owned companies. According to Sprint, they updated the records but RFC-ignorant was using old copies of the records. Regardless of who is to blame, the end result was legitimate messages from Sprint customers were rejected by sites using the rfc-ignorant RBL.

If you choose to use an RBL, you can reduce the problems they cause if you follow a few simple rules:

1. Don't trust any RBL as your only means of fighting spam. Use RBLs as part of a larger Bayesian filtering system--use it to assign points to the message, or flag a message for additional scanning if the IP address is on an RBL, but don't use RBLs to refuse messages outright.

2. If you want to refuse messages using an RBL, setup your own DNS server and create your own RBL list by adding the IPs of servers who send you spam. Yes, it takes time to build such a list but you are in control of who is on the list and you have no one but yourself to blame if you lose a $50,000 contract because a potential customer is on your RBL. If you don't want to create an RBL in a DNS zone, you can configure Exchange server (or most firewalls) to refuse connections from specific IPs.

3. If you are thinking about using an RBL someone else created, read up on the criteria they use to decide who to add to their RBL, before enabling the RBL. Find out how easy it is remove an IP that is not sending spam or an open relay. Every RBL provider includes information containing the criteria for addition to the RBL, the requirements needed to have an IP removed, and many include disclaimers warning that their RBL should not be used in a production environment. That is one warning that should be taken to heart.

4. Use RBLs for several weeks in a test mode and log the results or archive the filtered messages to insure it's not bouncing legitimate messages then check the RBL logs regularly after you enable it.