TechTheftBuilding a DNSBL |
|||||||||
|
|
Why you should _NOT_ start a new list. An interesting view, not admitted too by many yet, but one that holds merit. Don't start a new list. Bill Cole sums it up well with his description below. Bill Cole:"Given that there are about 500 blacklists who maintainers have never been sued for their listings and half of those lists which have generated lawsuits have survived essentially unchanged, I think the legal risk is generally overblown. I am no fan of the concept of a jungle of blacklists, but it is not the legal risks that I think should persuade people to not take their blacklists public." It's fairly simple. The relevance of each of the 500+ public blacklists
is reduced as more pop up, and the result is an environment where mail
admins are faced with a serious challenge of selecting and vetting the
trustworthiness of far too many lists. In addition, the hundreds of different lists mean that there are some run by incompetents and/or kooks, and the very worst behavior of blacklist maintainers is what sticks in the minds of people who don't deal with this stuff up close every day, but do have to make decisions on policies. It becomes harder to 'sell' the idea of using public blacklists to Guys In Suits as the shear number of lists causes them to look a bit like a sea of sameness punctuated by islands of laziness, incompetence, and stupidity. Many lists also inevitably leads to no single list having much significance to anyone. We hear a lot about SPEWS here because of the non-spam it recommends rejecting, but the actual fraction of the total email address space it is used to shield is rather small and not that important to most spammers. The SBL and perhaps by now the CBL have wider effect, but they are minor compared to the scope of the RBL in 1999, when there was essentially no competition for its flavor of blacklist. The estimate then was that it blocked or impaired delivery to 40% of the email addresses on the net, and I expect that was conservative relative to a full analysis of the effect of its BGP usage. Beyond those 'overpopulation' issues, I think that would-be DNSBL maintainers should consider the question of whether they can really offer anything truly useful to the world with that effort or if they are really just doing it for an ego boost. If you publish a blacklist that is 90% duplicative of existing lists, particularly of lists that have wide use, is it worth the effort? Will listing that 10% really have a meaningful and worthwhile effect? In addition, I think too little attention has been paid by some people who have briefly run lists of the negative impact of that brevity. Any list maintainer should look at all the ex-blacklisters and consider why they have quit. A list that starts up with a lot of hope and big promises only to go away in 6 months because the operator is broke, tired, or unable to withstand the DDoS aimed at him is a net negative. The vanishing blacklist trick doesn't amuse the people who make decisions about whether to use public blacklists at all, even when the shutoff is sane and polite like Easynet, MAPS, and ORBZ rather than needlessly user-hostile like ORBS and Osirusoft. Turning off a list means that people start getting spam that they would not have. The final reason is really simple: running a public blacklist sucks on a personal level. It may look fun and exciting from the outside and even be fun and exciting for a while, but so is Crystal Meth. It is a hobby that when successful becomes an all-consuming lifestyle and does damage to its practioners in both internal and tangible ways. I am somewhat hesitant to get too detailed there because people I respect might well take it incorrectly as a slur. In general terms, a stint operating a DNSBL is likely to leave the operator meaner, sadder, and poorer.
So what to do instead? Check for a list or lists that already do what you want to do. Most means of listing, and policies worth blocking on already have a group of maintainers with lists. Pledge your support and resources to join the existing groups. |
||||||||