Understanding Realtime Blacklists

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.

Realtime Blackhole Lists: Boon or Bane?

by Chris Scharff, Exchange MVP

Realtime Blackhole Lists are essentially lists of IP addresses and subnets of spam senders. Servers can query these lists to determine of the originating IP address of a message is flagged by the list. Much has been written about a number of these lists and the people who manage them. Some lists and their maintainers are seen as overly aggressive in their classification of spam or in their inclusion of broad blocks of IP addresses (sometimes entire countries or continents are listed).

This is not another article bashing the RBLs or their maintainers, Google already contains a number of enlightening articles if you are interested. Instead, let's take a moment to discuss their place in the mail stream. For the vast majority of businesses e-mail exists in the organization to facilitate business communications. Communications with customers and suppliers is a critical component of the overall business process.

Given the regularity with which RBLs are known to contain inaccurate information, and the ability of that incorrect information to impede the business of doing business it's a wonder that they are used at all. Unfortunately too many IT professionals are focused on solving the 'spam problem' without adequately considering the broader implications to the overall business. Too often the response heard to protests that it impacts business process is that those listed can get themselves removed or they can be whitelisted. Experience has shown that with some RBLs getting delisted is neigh unto impossible and the process for getting a customer or partner whitelisted is either unknown to the rank and file worker or seen as too difficult.

That's not to say that RBLs don't have a place in filtering spam, but as the sole arbiter of the spam/not spam decision it makes little business sense. Instead, when used as part of a spam filtering package which can evaluate inclusion on an RBL along with additional criteria such as header and content checks it provides additional information for determining whether a message is legitimate or not. Unfortunately today too few organizations have deployed packages which use RBLs as an intelligent scoring mechanism, but that is beginning to change.