In the continually escalating and increasingly frustrating battle against spam, email administrators are resorting to increasingly draconian measures. Some of my customers receive ten to twenty times as much spam as legitimate emails. One of the stringent measures admins are turning to is the use of Realtime Black-hole Lists (RBLs) to head off spam before it ever reaches your mailserver. RBLs are the aggressive bouncers of the Internet; anything listed in the RBL is unceremoniously bounced.
There are many different RBLs, with some blocking only connections from open relays while others also block known spammers. Those that handle lookups via DNS (DNSBLs) are the easiest to use. Most MTAs (mail transfer agents), such as qmail, postfix, exim, and sendmail, support DNSBLs; you simply need to configure your MTA to query the DNSBL.
Obviously, we can build our own blocklists; this is how the whole RBL thing started after all. Individual admins created and maintained their own lists, and as spam became more prevalent, lists were shared. Admins can still build and maintain their own blocklists, and modern MTAs come with arrays of filtering features built-in. The problem is that spammers are constantly moving targets, especially those that exploit dialup accounts, which often makes maintaining a blocklist a full-time job.
The theory behind RBLs is simple: block traffic from spammer IP addresses. Don’t even waste your system resources on filtering; just dump the identified spam before anyone ever sees it. Sounds great, right? For once, the harassed admin doesn’t have to do things the hard way! Reality, of course, is not so easy or pleasant. Spammers invest considerable resources and creativity in finding new ways to penetrate our defenses…if only that energy were directed towards earning an honest living.
Collateral Damage
MAPS, Mail Abuse Prevention System, is the granddaddy of all RBLs. MAPS calls spam and exploiting open relays “thefts of service.” The MAPS RBL lists both spammers and open relays (see Resources for a sampling of RBL operators). I agree with the “theft of service” service concept, but before rushing out to deploy RBLs, let’s look at some of the downsides.
Take this introduction from the MAPS website, for example. “The Mail Abuse Prevention System’s Realtime Blackhole List can be used by any interested party in the configuration of their own network or mail relay, toward the goal of limiting theft of resources by spammers. This step must not be taken lightly — the MAPS RBL creates intentional loss of connectivity for anyone who chooses to use it. … if you are not willing to occasionally throw out a baby with the bathwater (figuratively speaking, of course), then the MAPS RBL is not for you.”
And from a recent news.admin.net-abuse.email:
“> My company (deleted) does not spam, but we are listed because we are
> in a block with “cyberfuse”. We dealt directly with Sprint to get
> this ip block, so I don’t know exactly who cyberfuse is. (Are they a
> reseller for sprint?) How do I get our mail server (deleted) off
> the spews list?
You are not listed, nor is Cyberfuse.
It is SPRINT that is listed.
You can either:
1 Live with it.
2 Have SPRINT kick-off spammers from their network.
3 Arrange with a unblacklisted server to relay e-mail for you.”
That’s a rather hardcore attitude, but one that’s typical of some RBL operators. The theory is that customers will arise in wrath and demand that their allegedly-spam-friendly ISP mend its ways, or they’ll take their business elsewhere. In the real world, this gets tricky. Many users are in communities with limited service providers where there is no other place to go. Or the offender is so far upstream, such as Sprint, that it is not possible to get away from them. Or users like their service providers and think RBLs are stupid and unfair. Some RBL operators have such stringent definitions of what constitutes spam and are so aggressive in their listings that hardly anyone escapes.
Customers of ISPs that use RBLs may never know what they are missing. This magnifies the consequences considerably. It’s one thing to put blocks on traffic to your personal email; it’s quite another to affect large numbers of users.
RBL operators do not promise accuracy or accountability. Each one has different policies; removals, once you prove your worthiness, can take anywhere from a couple of days (Spamcop) to 4-6 months (Dorkslayers). Some post warnings and carefully-worded disclaimers, like this one from the MAPS website:
“If your network seems to have been blackholed by us, be aware that the places you cannot reach have deliberately chosen not to exchange traffic with you. We are not the network’s police force, but rather, a method to identify likely spam origin.”
This is rather disingenuous, as they are indeed acting as the Internet’s spam cops. Their entire reason for existing is to combat spam.
Saving the Baby
So, the responsible admin can’t just “set it and forget it.” Legitimate traffic will be lost. But RBLs can still be useful, with some tweaking. MTAs that are RBL-aware can override RBL checks for specific IPs. Users who expect a lot of mail from new and diverse sources, such as a business, can have RBL-flagged messages diverted into a folder for manual review. Of course, this may be more trouble than it is worth.
Extensive use of whitelists is important; it’s the best way to ensure that people you want to hear from will be able to successfully get through.
Careful selection of which blocklist to use will save a lot of aggravation. I’ve found Spamcop’s to be reliable, though it’s still not quite “set it and forget it.” MAPS is rather controversial; a quick Google search will provide hours of entertainment. Spamcop and MAPS both offer paid services.
Some other useful measures:
- Have email addresses that are not blackholed, such as postmaster, so that legitimate users can find you when they have problems.
- Bounce a message explaining that their mail did not get through, and tell what to do about it. Link to a Web-based mail form.
- Include this information on the contacts page on your Web site. Provide a phone number, and be sure the person(s) answering the phone can be helpful.
It’s a darn shame that we have to waste so much time and energy managing spam. I am optimistic that someday there will be a good solution…if we can hold out that long.
Resources
MAPS
RFC 821, Simple Mail Transfer Protocol
The Spam Problem: Moving Beyond RBLs
DNSBL.org
Osirusoft rbcheck
Spamcop
SPEWS
Spamhaus
dorkslayers
Open Relays Database
Filtering E-Mail with Postfix and Procmail
»
See All Articles by Columnist Carla Shroder
