Talk:Domain Name System blocklist

Template:WPI Is it worth going into the several broad groups of DNSBL?:

Classification of DNSBLs

Those which attempt to list compromised machines, often based on tests they have undertaken.

This class of DNSBL usually has a very objective policy about what can be listed, and they usually also run automatically or with very little human input. Examples of these lists: CBL, NJABL proxy, SORBS proxy, OPM, DSBL.

Those which attempt to map dynamic IP addresses (for various interpretations of "dynamic").

In reality, most of these just try to list anything which is domestic, dynamic, and not supposed to host mail servers. A very high proportion of spam comes directly from domestic broadband and dialup accounts, often via insecure proxies and other malware running without the users' consent. Using this type of DNSBL to reject email that comes directly from such machines is popular and effective, but can be problematic since there are many people who do operate their own mail servers and send legitimate email in this fashion. Examples of these lists: NJABL DUL, SORBS DUL, PDL

Those which attempt to document all IP ranges belonging to a geographic area or particular ISP.

These lists can be useful for scoring, or for small-scale, specialist or personal use. For example, if you were running your own mail server and were not expecting to receive any email from China, you might find it worthwile to make use of china.blackholes.us, a DNSBL that attempts to document all IP ranges delegated to networks in China. The blackholes.us site contains many other examples of geographic and ISP lists.

Those which reflect the opinion of their human reporters on sources of spam.

The types of DNSBL mentioned above rely on a minimum of human input (or in some cases, no human input at all), but some of the most popular DNSBLs are based upon human-generated reports of spamming.

These are traditionally the most controversial types of DNSBL, because humans make mistakes. The fact that there is no widely-accepted definition of spam within the Internet and email marketing industries does not help -- spammers continue to redefine spamming as "that which we do not do", and many email recipients will mark as spam anything which they do not want, whether it is or not.

Some opinion-based DNSBLs attempt to list what they believe to be sources of spam, others attempt to document the activites and current hosts of spam gangs, still others list ISPs who they believe knowingly host spammers. Examples of this type include SpamCop, Spamhaus, SPEWS

Those which attempt to list networks that they believe operate contrary to accepted best current practice.

There are many recommended technical practices for operating an Internet presence, especially when the presence in question is a large organisation, ISP, or even an entire country's Internet infrastructure. Very few of these recommendations are solid prerequisites for connectivity, so it is possible to communicate with the rest of the Internet even while going against these accepted BCPs.

Examples of widely-accepted Internet BCPs:

• Internet sites should have working abuse@ and postmaster@ addresses for all domain names that are visible externally.
• Emails sent to a role account such as abuse@ or postmaster@ should be dealt with, not just swallowed by an automatic responder which tells the complainant to take other action.
• Domain name registrars should provide a whois service that shows contact details for the actual owner of any domain name provided through them.

Although it is usually not possible to directly link non-adherance to BCPs with increased spam or other abuse, some people deem the matter important enough to create and use DNSBLs that list networks that do not conform. Because of the lack of an obvious link between abuse of the Internet and strict adherence to BCP, use of this category of DNSBL is often seen as more controversial and political. They can also be surprisingly far-reaching; one such popular DNSBL of this type lists the entire of the .uk TLD for not consistently displaying domain name contact addresses in its whois. Perhaps the best known set of DNSBLs of this type are supplied by RFC Ignorant - "rfc-ignorant.org is the clearinghouse for sites who think that the rules of the internet don't apply to them."

Those of a non-serious nature.

There are many DNSBLs which are created whimsically, and serve no useful administrative purpose. Some purport to exist in order to re-educate people who will configure any DNSBL they find, the idea being that after configuring use of such a DNSBL, a large portion of their email will be rejected based on some arbitrary process, and the user will learn to be more careful in future. GRIP is an example of one such DNSBL - it returns random results.

AndySmith 09:38, Mar 6, 2004 (UTC)

Criticism section is weak

I feel that the Criticisms section of this article is a bit weak, and doesn't adequately address the potential harm to average e-mail users.

I've found that many ISPs have taken to using DNSBLs to discard incoming e-mails. I first ran into this when I found myself getting put into suspended status in various yahoo groups. On investigating the bounce message sent by yahoo when they again managed to get through to me I found that messages were getting rejected because random yahoo mail servers were on the spamcop.net list. Ironically, another problem this caused was an inability to sign up for various sourceforge mailing lists because their servers were also on the list. The confirmation e-mails, which are sent as an anti-spam measure!, were being blocked.

The spamcop list uses arbitrary reports of spam in a time-weighted scheme to place servers on the list. It takes very little to put a server on the list at least temporarily. In the case of mailing lists, users who don't know how to unsubscribe might resort to reporting legitimate mail from the list as spam in desperation.

Spamcop warns that they are very aggressive and recommend against using the list to block e-mails but rather to either quarrantine them or to use the existence of a server on the list as evidence in a spam filtering scheme such as Spamassassin rules[1]

Despite these warnings, some ISPs are quite happy to block e-mail in the mistaken belief that they are ONLY blocking spam, the problem is that if users don't know that legitimate e-mail isn't reaching them they aren't going to complain unless they find out by other means. My ISP also told me that they saw a reduction on their server load when then instituted the policy, so they were loathe to listen to the complaint that they were blocking valid e-mails.

Another irony is that I use my own anti-spam measures on my local machine, including spamassassin filtering, and a large number of actual spam e-mail was getting by the ISPs measures.

As much as I hate spam, I hate the collateral damage of losing valid e-mails even more. As a result I've gone to establishing my own domain, and my own e-mail server which does a better job of spam filtering than my ISP, while avoiding the problems of using DNSBLs for blocking. --Rick 15:58, 26 November 2005 (UTC)

I understand your frustration that some sites do not accept your email. When people come to depend on a service, anything that looks like deliberate refusal to provide that service is going to elicit suspicion. However, I'm not sure you're correct in claiming that ISPs use those DNSBLs "in the mistaken belief that they are ONLY blocking spam".

First off, as you note, the DNSBL services in question do make it abundantly clear that using their lists to block mail will cause the rejection of some non-spam mail. In some cases, this is an intentional feature -- e.g. MAPS RBL, which lists badly-run mailing lists and spam-support services as well as spam sources. Sites which choose to use a list like that are saying they want to block non-spam mail from irresponsibly-operated sites in order to make a statement.

Second, mail system administrators' responsibility is to their own users. Mail admins are in the position of having to balance between overblocking and underblocking. A complaint about erroneous blocking is a lot stronger when it comes from a user, than when it comes from some random fool who claims not to be a spammer. Meanwhile, for every complaint about erroneous blocking, a mail admin may be getting hundreds of complaints about spam that went unblocked. So in terms of maximizing user satisfaction, it may be that using tools that block a lot of spam at the expense of blocking a tiny bit of legitimate mail turns out to be a good balance.

Third, keep in mind that there's a huge advantage of blocking-based systems like DNSBLs over client-side filtering systems that file suspected spam in a "spam folder" or just delete it. If your mail is erroneously blocked by a mail server using a DNSBL, you get a bounce message. You're told specifically that your mail was blocked, and the reason for it. You have a chance to get that problem fixed and re-send your message; or contact the recipient by another medium (IM, phone, whatever). But if your mail is erroneously filed in your recipient's spam folder, or deleted, then you don't get a bounce message. Your mail simply disappears unread. The rules of SMTP say that mail systems are supposed to deliver messages or return them; making messages disappear is forbidden. Mail admins who care about reliability will prefer to avoid filtering techniques that, when they fail, destroy messages rather than just returning them.

Last, remember that you always have other options. Mail accounts are ridiculously easy to come by these days. If you find that a given site refuses mail from one account of yours, you can always get a different account. This is most specifically recommended if the reason that you're blocked is that the site you're sending from is a spam supporter. Some rogue ISPs make a hell of a lot of money from spammers, and use their non-spam customers as "human shields" -- "Don't block us for our spammers, because you'll be blocking all these legitimate users!" Many mail admins have precious little patience for that kind of crap these days. Sites that support spamming don't get any sympathy for getting blocked, since they're the cause of the problem in the first place. --FOo 22:07, 26 November 2005 (UTC)

NPOV violation

The folowing paragraph does not represent a neutral point of view:

"The proprietary term RBL is sometimes erroneously used in place of the generic DNSBL. RBL is a service mark of MAPS LLC. Some pieces of mail software have configuration parameters for the use of "RBLs" or "RBL domains", used to set the DNSBLs that the software should use. This may be trademark dilution."

The author is apparently expressing his own non-NPOV opinion that "RBL" is a service mark with legal validity and that the use of the abbreviation "RBL" may cause trade mark dilution. An alternative non-NPOV opinion would be that RBL is just an abbreviation of a descriptive English phrase that nobody can legally monopolize. See cases holding that "Lite beer" and "IM" and "Instant Message" could not get trade mark protection.

(added) Furthermore, trade mark dilution applies only to FAMOUS names. These would be names like Wendy's, Coca Cola, and Xerox -- names familiar to almost anybody. It is mere hubris to suggest that RBL is in the same class.

Either both non-NPOsV should be included or (preferably) neither.

Rahul

Please provide a verifiable source for the claim that RBL is "just an abbreviation of a descriptive English phrase". MAPS LLC and its successors have been consistently claiming it as a trademark for some years now, and various parties including the authors of Sendmail and Postfix mail clients have made a point of respecting that trademark by explicitly changing their software to use other terms rather than "RBL" for DNSBLs. --FOo 05:44, 16 October 2006 (UTC)

Another NPOV

The following paragraph does not represent a neutral point of view:

"The most common mistake, which has led to a bad reputation of DNSBLs in general, was to use them as a single decision-factor on the MX-servers. Mistake because the receiving MTA hands the decision "to accept or reject the client" to a single 3rd party."

It would only be a mistake if such a decision were taken without understanding the implications. Many mail server operators make the decision in full knowledge of the results and hence it is not a mistake. It is a course of action that can be argued against, but at the end of the day the server owner makes the decisions, and not all such decisions are mistakes.

Nothing about why they use DNS

There is nothing in the article telling why DNS is used instead of, say, HTTP. I suppose it's because DNS responses are cached by all DNS servers on the way. --Apoc2400 05:32, 16 October 2006 (UTC)

Some (not entirely uninformed) guesses:

• DNS was available. Today, there are other options for a distributed, cacheable database (say, LDAP) but these didn't exist or weren't in wide use then.
• At the time DNSBLs were invented, the advancement of Internet mail systems was being done on the Unix platform, by Unix programmers and sysadmins (such as Paul Vixie). Such folks were likely to be comfortable with DNS; Vixie, as the maintainer of BIND, especially. :)
• DNS has some useful technical properties, such as caching, and the fact that it is very lightweight on the network. A simple DNS lookup consumes much less network bandwidth than the spam email that it avoids.
• The idea of RPC-over-HTTP wasn't exactly widely heard-of in 1997; XML-RPC wasn't invented until 1998. In any event, it would have been much less welcome; such queries would be several times slower than DNS lookups (due to TCP setup and teardown -- DNS uses UDP for small queries) and rather more expensive in bandwidth.

--FOo 05:54, 16 October 2006 (UTC)

I'll add a few more comments

• I think the "light weight" part is critical. A UDP DNS transaction usually requires sending one packet and then receiving one packet. A minimal TCP transaction requires a 3-way handshake to start, plus another 2-way handshake to end, plus a lot more information about the connection needs to be kept in the OS and firewalls. Another UDP-based protocol could have been developed, but it would have looked almost identical to DNS.

• The original MAPS RBL *wasn't* DNS based, it was actually a format used by routers to blackhole *all* communication with spam-related hosts. This was distributed via FTP and rsync, if I recall correctly. This type of system proved to not be very popular and no one uses it any more.

• Mail systems already make extensive use of DNS, so it was much easier to add.

Wrs1864 13:13, 16 October 2006 (UTC)

Expansion of the abbreviation "DNSBL"

I recongize that for the last several years, there have been some people who have been pushing to redefine "DNSBL" to mean "DNS blocklist", or some other term that doesn't use "blacklist". I do not think that wikipedia is the appropriate place to try and push this point of view. Wikipedia is not supposed to be censored.

A quick check on google shows 48k hits for "DNS blacklist", 3k hits for "DNS blocklist", and 416 hits for "DNS blackhole list". The oldest reference to "DNS blacklist" on google groups dates from 1998, for "DNS blocklist" it is 2001, for "DNS blackhole list" there is a reference from 1999 but it appears to be referring more to MAPS's RBL and uses "DNS blacklist also".

I have yet to find an original definition or first use of DNSBL, but it is clear to me that wikipedia should primarily use "DNS blacklist". Wrs1864 05:36, 9 December 2006 (UTC)

The term "blackhole list" dates back to the original MAPS RBL, and is based on the idea of "blackholing" a network block.

Your accusations of censorship are uncivil and unfounded. Please retract them if you expect to engage in a civil discussion here. --FOo 20:06, 9 December 2006 (UTC)

Sure, "blackhole list" goes back to the RBL and that is mentioned in the terminology section. However, it is important to remember that the original RBL didn't use DNS, it was a set of commands to configure BGP routes to cause all packets to be dropped, not just SMTP connections. In the area of routers/BGP, the term "blackhole" is still used. There are also conflicting claims that abovenet (IIRC) announced these blackhole BGP routes to everyone with a low-cost advertising, effectively sucking packets for these IP addresses into the blackhole from all across the Internet.

Basically, when the technology switched from BGP-based to DNS-based, the "blackhole" term was no longer quite as appropriate and people switched to calling them blacklists. Yes, MAPS stuck with their trademarked name, RBL, but from what I remember, almost everyone else switched to "DNS blacklist". The earliest reference I can find to "DNSBL" is sendmail's 8.10 release, where it uses the terms "DNS base blacklist", "DNS based rejection list" and left unchanged from earlier the 8.9.3 version, several references to "blackhole list".

It was only later, after various DNSBL operators were sued and such, that concerns were raised about the term "blacklist" being inappropriate and some people started to push to redefine the term to blocklist or boycott list or whatever.

As far as censorship goes, I have to disagree with you on this too. By trying to surpress or eliminate the word "blacklist", you are censoring. Yes, there is more than a little irony in the idea of the word "blacklist" being censored. Wrs1864 21:03, 9 December 2006 (UTC)

If you expect to elicit cooperation here, you will cease making uncivil accusations. I have nothing more to say to you here. --FOo 04:38, 10 December 2006 (UTC)