I seem to be one of a very small number of people here consistently advocating the use of RBLs against spam and may well have said it all before - but forgive me, I can't resist responding.
You don't have to Google too hard to find plenty of articles like the one you cite from Information Week.
One thing all these articles tend to have in common is that they are written by people who do not administer Internet mail hosts and who maybe do not understand SMTP (in particular, how absurdly primitive it is and how easy to spoof).
These articles variously describe RBLs as blunt instruments, as seriously flawed due to false positives and as disrupting legitimate business. They even occasionally claim that block lists block all email from a particular email address, which seems to suggest that the authors of these articles do not understand how block listing works. You will see impressive, but uncorroborated claims of high false positive rates and suggestions that alternatives such as Bayesian filters, distributed checksumming and (God help us) even legislation are the ultimate answer.
Don't get me wrong - looking at the content of spam in these or similar ways is probably a very valuable approach but this should be regarded as supplementary to, not as a replacement for blocking techniques.
Why? Because there are two thefts going on for every spam your users receive. The one that people rightly focus on first is theft of users' time. The one that is often ignored is theft of service (bandwidth, storage, processing resources).
You may well say (as many have) that you don't care about the latter - after all you have plenty of both bandwidth and storage, so losing a fractional percentage to spam doesn't bother you.
But accepting spam from open relays or proxies makes you complicit in the theft of a third party's resource. Also, as others have pointed out, because anti spam techniques (including blocking) are working, spammers are having to dump more and more of their rubbish into the network in order to get any delivered, thus the amount of bandwidth, storage and other services consumed in this fruitless manner will grow, probably close to exponentially. If you rely solely on content analysis to combat spam, in a year or two the most powerful host in your computer room will not be the one running your ERP system, it will be the one handling inbound mail.
Since we started using an aggressive blocking policy, largely using Domino 6, I have gathered a substantial body of empirical data on RBLs and their effect. The last time I published any stats
, we were blocking close to 40% of all inbound mail. Now it is closer to 70%. False positives remain very low (c. 0.4%).Too high, you say? This is Internet email we are talking about - the lowest common denominator of communication; the least reliable, least secure most abused messaging system in existence. If it is really business critical to you, engineer that criticality out before it's too late.
My latest "false positive" (last week) was a supplier's open relay which had correctly been listed at dsbl.org. It took 24 hours to close the relay and have the listing removed. The theft of service, both ours and our supplier's, has been discontinued.
There was a survey recently that said that most users of business email systems, as opposed to private, home users, do not regard spam as problematic. If you ask most of my users, they will echo that sentiment (actually, a couple would probably disagree because they seem to be spammed as relentlessly as I am). However, spam is not a problem that most of my users care about. Why? Precisely because blocking works (we have no content filtering here).
Finally, one fact that emerges very clearly from my data is this:
The ratio between relay spam and spamhaus spam is changing. Six months ago, it was lose to 50:50. Now, fully two thirds of spam blocked here is coming from spamhausen, with only a third coming from unsecure relays, proxies and dial-ups.
The Spamhaus Blocklist is your friend. Try it - you might be pleasantly surprised.
Return to top
. . . . RE: RBL usage: No experience yet, b... (~Kelly Zekwebur... 20.Jan.03) 
Print this page
