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 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.

People often ask me how they can search Outlook for folder names because they created so many folders, often nested so deeply, that they can't easily find folders when they need them. Unfortunately, Outlook doesn't support a way to search for folders, so it's important to use a good filing method, such as the one Keith Collyer uses:

"I gave up on complex folder structures and simply have a set of A-Z folders, with the folders containing messages under these. Now I don't have to worry about whether I put something under "Customers" or "Projects", I just need to remember the name of the customer. Unless I get a huge number of messages for a customer on very different topics, I just put all the stuff in one folder. So "Big Company" goes under "B / Big Company", unless I get a very different topic to work on for them, when I add "B / Big Company - Topic", at the same level as the original "B / Big Company" rather than nested. It sounds too simple to work, but it is much easier to use and find stuff than any structure I had before. Of course, my Windows file system has the same structure."

Use Exchange Server 2003's new tarpittime registry key to prevent the enumeration of Exchange Server 2003 e-mail addresses.

As you may know, Exchange 2003 can be configured to block emails sent to recipients that do not exist, blocking the e-mail message at the Simple Mail Transfer Protocol (SMTP) level. As a result, a sender can enumerate e-mail addresses that do exist by using a technique that is known as a directory harvest attack.

When you select the Filter recipients who are not in the Directory check box when configuring recipient filtering, directory lookup for recipients is enabled. This gives senders of unsolicited e-mail the ability to discover valid e-mail addresses in your organization by sending mail using a long list of popular aliases and name combinations, looking for valid addresses.

To address this issues, Microsoft released a security update which adds a feature called "tar pit" that delays the SMTP address verification responses for each invalid address. By delaying the response, it's costly in terms of time and resources for an attacker to try to obtain the Global Address List using a directory harvest attack against an SMTP server. By default, this feature is disabled and you can control the delay time by setting the value of the TarpitTime registry entry.

Because only anonymous connections are affected by the TarpitTime registry entry it's recommended that you only use this registry entry on the Internet-facing mail gateway servers.

To add the tar pit feature to Exchange 2003, install the MS04-035 security update for Windows Server 2003.3.

For additional information about this security update, see MS04-035 Vulnerability in SMTP could allow remote code execution in Microsoft Windows Server 2003.

See http://support.microsoft.com/?id=842851  for more information about the tarpittime key.