|
This resource is intended for people responsible for administration of networks and mail servers. |
DRBL FAQ
Q: Remove me from your list! IMMEDIATELY!!! A: First of all, stop yelling. It won't help you anyway. The second step towards getting removed is to understand what exactly happened. Q: I don't care what's happened! I'll drag you through all courts! A: [yawning] Oh, well... you are welcome. However, for many years no one of your hmm... predecessors had succeeded with that. Are you still feeling lucky? So, further we go. If you've found your address listed in one of the working DRBL NS zones (hereafter work zone), it is useless to bother the owner of that zone. And it is just stupid to contact the maintainer of this or other DRBL sites, because we don't have neither any authority nor even influence at the owners of other DRBL nodes. Are you confused? If so, it's time to read the remaining text. Not really? So the rest of this FAQ also wouldn't confuse you. The only real human-controlled source of blacklisting are the voting DRBL NS zones (hereafter vote zone). Once you'd find which ones contain your addresses, contact the people responsible for these zones. However, you are strongly encouraged to check the next question prior to doing that. Q: I'm not a spammer, why my network is blacklisted? A: Primary mission of DRBL is to provide postmasters with a method to share their local filtering rules. The project participants vary from large ISPs to private amateurs (for example, the owner of this site maintains two independent DRBL zones, private and corporate). As the Internet consists of independent systems who agreed to perform information exchange, all participants are on their own to choose where they want to get information from, and this applies to all types of communication, including e-mail. That means, if you run your own mail server that's you and only you who defines its' policies on accepting or rejecting messages. Also that means nobody can demand or request to delist some address or network - if you want someone to change their policies, you can only ask them to do so. Please keep that in mind when writing messages. Q: So, what is DRBL? A: DRBL stands for Distributed Realtime Black List. Instead of a proprietary database controlled by certain people, DRBL encourages administrators to maintain their own databases and share this information with colleagues. DRBL method of operation is similar to other DNS-based black lists, but the main difference is in (1) using many "local" databases instead of one centralized and (2) sharing information among them, so many other systems can decide whether some network is a spam source and has to be banned, or even do that automatically by getting and analyzing the information from different sources. Q: How does it work? A: The DRBL participants should carry two DNS zones - voting (hereafter vote) and working (hereafter work) usually named vote.drbl.domain.tld and work.drbl.domain.tld. Also, optional info zone (info.drbl.domain.tld) may be created. Blacklisted hosts and networks are placed into vote zone as a pair of A and TXT records - e.g.:
*.57.168.192 IN A 127.0.0.2
IN TXT "Spam-friendly ISP"
This blocks mail from 192.168.57.0/24 network with "Spam-friendly ISP"
being the publicly available comment.
The next step is to set up policies used to generate work zone. You should decide which vote zones will be used as sources and how much you trust their maintainers. The latter are defined with scalar values of weight assigned to each source vote zone, and a threshold value used when generating the work zone. Each address from one or more vote zones gives weight equal to the sum of weights for all zones containing this address. If the weight of an address hits or exceeds the threshold value, it is listed in the work zone. Suppose we maintain example1.tld and decided to use DRBL. For that, we create vote.drbl.example1.tld and work.drbl.example1.tld NS zones. To fill the latter we would use the information from some other systems - vote.drbl.example[2-6].tld, with our colleagues from example2 being fully trusted, people maintaining example3 are less known (so less we trust) and, finally, we don't know the administrators of example4, example5 and example6, but there are no reasons not to trust them (is there are, we simply wouldn't use their zones at all). Finally, we set a threshold value of 1 (or 100, to assign weights as a percentage of trust, or some other value) and assign the following weights to voting zones: vote.drbl.example1.tld 1 vote.drbl.example2.tld 1 vote.drbl.example3.tld 0.8 vote.drbl.example4.tld 0.4 vote.drbl.example5.tld 0.4 vote.drbl.example6.tld 0.4 Now, if some address apears in our own vote.drbl.example1.tld zone or in a fully trusted vote.drbl.example2.tld zone maintained by our fellows, then this address will be automatically put in our work zone, and incoming mail from this address will be rejected. If some address is banned in example3, it will not be put into our work zone immediately: it should be banned in some other network as well. For example, if some address is banned in example3 and example5, the total weight will be 1.2 - and this exceeds the threshold value. Here we suppose that blocking given address in example5 as well as in example3 is a good reason to do the same. Finally, if none of the example[1-3] systems have blocked some given address, example[4-6] should join their efforts to make it appear in our work zone. Q: Why I could need it? A: Most systems have their own mail filters, and many administrators are ready and wish to share the information with colleagues. DRBL, being the automated decision-making system, is expected to help doing that. Q: Why distributed? A: First of all, distributed architecture is immune to any and all types of legal prosecution attempts by blocked spammers and spam-friendly companies and people: the higher is the quality and popularity of such service, the greater are dissatisfyed spammers and spam supporters, whose networks are blacklisted. It could become necessary to be to ready to constant expenditures for attorneys and judicial expenses - otherwise any spammer with a big moneybag and a smart lawyers will be able to destroy the whole system. Being distributed, DRBL lacks this problem. In the most cases there is noone to sue: "against all at once" is physically impossible, useless and can't be taken seriously. Anyone can block anything within their own network, so everything is legal. For other networks using such information, this is voluntary - DRBL has a great amount of concurrent zones. Finally, if some node will be exterminated, the whole system will keep its functionality. Also, under the conditions of law anarchy in the modern internet caused by attempts to put it under control of various governments and even some companies, running any type of centralized service ends with it being either destroyed or taken under full control. And again: being distributed, DRBL can't become proprietary so you wouldn't depend on any government, organization or person. Q: What should I do to get my system removed from blacklist? A: Most likely, you've got a bounce message similar to this:
Why:
Now find how to contact the maintainers of vote zones. The
traditional method is to query the zone for SOA record: Some maintainers run sites dedicated to their DRBL zones (like this one). Try accessing vote.drbl.example.net or drbl.example.net using HTTP - sometimes that would give you additional information, including unlisting policies. Q: Can I use work DRBL zones as sources for generating other zones? A:
Short answer: NO! Q: What software would I need to run my own DRBL node? A: See DRBL software list. Q: How should I select source zones and set weights? A: Here's no common answer. Generally, you may use any and all vote zones you know of. As for assigning weights, that's simple: the more you trust the given system, the higher would be its weight. With a threshold of 1.0, assigning the weight 1.0 to ISP, 0.7 to corporate and 0.4 to all other (including private) vote zones had proved itself to be a good start with further correction of these values. Just remember: the weight of your own vote zone should be above the threshold - or don't you trust yourself? Q: Ok, I've made a voting zone. Are there any restrictions for networks I can put there? A: Only one: your mail system must use your voting zone as a sufficient condition to reject messages from listed networks. Once you blacklist some network, that's like saying "I don't accept mail from here", not just "I don't like it" - the former assertion has substantially larger weight. Besides that, take the task of blacklisting responsibly - otherwise your zone will not be popular and effective. Q: I don't want to participate in DRBL by running my own node. May I still use it to protect my servers? A: Of course. You may use one or more external WORK zones - most (if not all) of them are publicly accessible. Just put a list of such zones into DNSBL (DNS Black List) in your MTA. However, setting up your own node is quite simple and there are no real reasons to refuse to set it up (except for laziness, of course). |
SoftwareWritten for GNU/Linux systems, requires perl, generally should work in any UNIX-like system. |
Policy of vote.drbl.gremlin.ru DRBL nodeVoting NS zone vote.drbl.gremlin.ru is populated automatically: once some of spamtrap addresses is hit by an unsolicited mail (spam), that message is processed by a robot which finds the least whois object containing the source IP address (for example, RIPE database allows the inetnum to be as small as single IPv4 address and inet6num as small as /64 subnet) and lists all found addresses. Working NS zone work.drbl.gremlin.ru is publicly available and had earned (hopefully, deserved) popularity across the whole world. Delisting requests are accepted only from network administrators according to the whois information. If you aren't the network administrator, don't try to "jump over a head": the effect will be null or even negative. |