Status of dnsbl.tqmcube.com: DEAD

The DNSBL TQMCUBE was created by David Cary Hart sometime in 2004 or 2005. The front page of the website www.tqmcube.com was modified to specifically become the homepage of the TQM blocking list in January of 2006. August 17, 2009 update: A reader was kind enough to let me know that the TQMCUBE list is now officially dead and gone. The TQMCUBE website now redirects to the website of another list called the invaluement Anti-Spam DNSBL. Please see this page for more information. Below find my commentary from 2007 from around the time the TQMCUBE project seemed to have first gone dormant.

From 2007: Various sources and my own investigation show that the website seems to be running on autopilot with nobody at the helm.

A postmaster at a large ISP contacted me and indicated that he had received no response to DNSBL remove requests submitted to TQM. Those requests were submitted on March 27th, and it is now June 30th (2007) that I write this article.

Other data points showing that the list appears to be unmanned and likely abandoned:

  • The list's website has a "last update" date of March 11, 2007.

  • The last known response received in reply to a blocking list remove request seems to have been in February, 2007.

  • I contacted David Cary Hart via email to the address on his domain registration on June 20th, 2007, and have not received a reply.

  • I contacted the abuse desk of his ISP (Fortress ITX) and asked them to confirm that he was alive. This was on June 24th. I received a ticket number but no other response.

  • The DNSBL's experimental world zone has not been operational since December, 2006.

  • The last known sighting of Mr. Hart online appears to be here, from April 2007.

  • This newsgroup posting from Colin Leroy on June 14, 2007 indicates that Colin had last seen email from Mr. Hart back in December, 2006. The email was a message posted to a mailing list that they both participate in.

  • Others have indicated to me that they have called the telephone number in the TQMCUBE domain registration, and that the voice mail box associated with this phone number is full, no longer accepting new messages.

This thread in the news.admin.net-abuse.email newsgroup wondering why the list's administrators are non-responsive is typical of the discussion I've come across during my investigation. I am receiving numerous reports of issues with listings going unresolved. Additionally, when checked against my personal spamtrap data (8000+ spams/day) I am seeing the effectiveness of this list trending downward over the past few weeks.

After careful consideration of all of the facts and discussion surrounding the status of TQM and its maintainer, I do not think it is wise to use the TQMCUBE DNSBL.

November 25, 2007 update: Within the past week, a large number of entries have been removed from the TQMCUBE blocking list database. The Internet Wayback Machine suggests that TQMCUBE had 1.37 million IP addresses listed on August 29, 2007. As of today, November 25th, the TQMCUBE website suggests that there are approximately 851,000 active listings.

Status of blackholes.intersil.net: DEAD

I've recently received a few requests regarding blackholes.intersil.net. According to this message to news.admin.net-abuse.blocklisting, this blocking list was retired in July, 2006. Confusingly, the zone still contains a test entry. Regardless, I've seen no hits against it in a very long time. Therefore, if you are using this DNSBL for spam blocking, I recommend you cease doing so. If you have any further information about this list, please feel free to contact me.

Status of blacklist.spambag.org: DEAD

As of Sunday, May 27th, 2007, the blocking list Spambag, with the DNSBL zone blacklist.spambag.org, is no longer available. The website www.spambag.org does not resolve to an IP address, and there appear to be no DNS entries under the DNSBL sub-zone.

Spambag, created and run by Sam Varshavchik, developer of the Courier mail server, has been operating this list since at least November, 2001.

The list had the following listing criteria: "[Spambag is my] personal list of networks who I block from sending me mail or accessing my web servers, because I believe the networks actively or passively allow abusive or antisocial behavior. Examples of what I consider abusive or antisocial behavior are: spamming, mailbombing, mail server dictionary attacks, and web page E-mail address harvesting."

I last noted a hit against this DNSBL on May 26th, at 1:34 am US central time. Note that I was not a user of this list; I simply measure its effectiveness and status, like I do for many other lists.

This post to news.admin.net-abuse.email explains that Sam Varshavchik shut the list down, and that he felt his efforts had not been as productive as he would've liked them to be.

I would recommend removing blacklist.spambag.org from your list of DNSBLs to check, as it is no longer in operation.

Spamcop BL: Take Another Look (It’s Accurate!)

If you know me, you know that in the past, I’ve made no secret of my disdain for the Spamcop DNSBL, aka the SCBL. I’ve worked in spam prevention, deliverability, and the email realm for a long time, in various capacities. I’ve created and run at least two blocking lists that you know about. Later, I helped to design and create a system that processed thousands of confirmed opt-in/double opt-in newsletter signups a day. Combine those two details together and that’s what led me to take issue with Spamcop. My employer’s COI/DOI signup servers kept getting listed by Spamcop, based on some really bad math to measure email volume thresholds and make a determination as to what to list.

I was trying to do the right thing. I was implementing what Spamcop (and other anti-spam groups) want: confirmed opt-in/double opt-in. Yet Spamcop was listing the servers and subsequent mailings regardless. It made me really frustrated, and I was very disappointed. See, it’s not really fighting spam. It’s just blocking mail you don’t like, or don’t care about. While perfectly allowed, I am of the opinion that it’s lame to do so under the banner of “fighting the good fight” to stop spam. I’ve shared my thoughts on this topic in just about every available forum—websites, blogs, discussion lists. I know I’ve personally guided many sysadmins away from using the SCBL in the past, because it was easily, demonstrably, listing things that were obviously not spam.

In February 2007, I found that Microsoft was using the SCBL to filter/reject inbound corporate email. (Note that I said corporate email—mail sent to users at micrsoft.com, not users of MSN or Hotmail. I don’t know whether or not SCBL data is used in MSN Hotmail delivery determination, but from what I’ve observed, it doesn’t seem to be.) This started me off on another rant on how ill-advised I felt this was, based on my prior experiences with Spamcop. Some kindly folks (and some less kindly) suggested that I needed to revisit my opinion of the Spamcop blocking list, because things have changed.

After a lot of measuring and discussion, I’m here to tell you: Spamcop’s DNSBL has changed, and for the better. It works very well nowadays, as personally measured by me. The open question on Spamcop was what drove me to dive into my massive DNSBL tracking project. I started that back on March 10th. Ever since then I’ve been compiling data on Spamcop blocking list matches against both spam and non-spam. Here’s what I see:

DNSBL

Spam hits

Acc %

Ham hits

Failure Rate

Spamcop SCBL

156194

49.37%

0

0.00%

Spamhaus ZEN

255521

80.77%

5

0.10%

Spamcop+ZEN

267795

84.65%

5

0.10%

Range:

~ 74 days

Total Spam

316348

Total Ham

4999

As you can see, Spamcop helps you attack nearly 50% of spam received, while affecting no legitimate senders. Very few lists do better. Spamhaus ZEN (which combines multiple lists) does better, but will occasionally have a false positive, based on some reputational issue perceived with a given sender.

My recommendation: Spamcop’s blocking list is safe to use, and will effectively help you reduce the amount of spam you have to deal with. Where I find it particularly useful is as an addition to Spamhaus ZEN: If you block mail from entities on either list, you get a 3.8% percent boost in effectiveness. Meaning, just under four percent of my spam hits are found on the Spamcop list, but not on Spamhaus.

For historical reasons only, here are links to my previous articles on Spamcop:

Spamcop Roundup http://www.dnsbl.com/2007/03/spamcop-roundup.html Spamcop BL: A blocklist with a hair trigger http://www.dnsbl.com/2007/02/spamcop-bl-list-with-hair-trigger.html Microsoft using Spamcop BL http://www.spamresource.com/2007/02/microsoft-using-spamcop-and-spamhaus.html My Problems with Spamcop http://www.spamresource.com/2003/03/problems-with-spamcop.html

Status of relays.orbs.org: Shut down, legal troubles in 2001

Remember ORBS? Short for “Open Relay Behavior Modification System,” it was a blocking list run by Alan Brown from New Zealand. (Mr. Brown ran the second version of ORBS. The first version had been run by Canadian Alan Hodgson.)

People keep asking me about the situation regarding ORBS and its eventual downfall. It happened so long ago, that I don't feel that it would be appropriate to try to fill people in from memory alone. Instead, here's links to a lot of the articles I've found regarding Alan Brown and ORBS. If you have any others, drop me a line and I'll add them to this page.
Please note that I'm not linking to any commentary or conspiracy theories put forth by emotional, anti-blocklisting “how dare you block my guaranteed opt-in email” people. There are many blocklists run correctly and appropriately. There were then, and there are now. The lists themselves weren't the problem, and aren't the problem now. Like with any other field of study, type of product, or process, some manage it well, and others do not.

Status of rbl.cluecentral.net: ALIVE

The DNSBL “rbl.cluecentral.net” has been revived. Its maintainer, Sabri Berisha, had previously shut it down in November 2005.

This list aims to allow you to allow or block mail from specific countries, or from certain routers (by AS number). For example, if you wish to block all mail from the US, you could configure us.rbl.cluecentral.net as a DNSBL to be used for mail blocking in your email server software, and you would then block all mail from the US, as identified by Sabri’s categorization. For more information, see Sabri’s post to the NANOG mailing list, announcing resuscitation of the list, or click here visit the list’s website.

Note that while these lists may be used to block spam, they're not exactly spam-blocking lists. Rejecting all mail from China simply means that you're going to reject all mail from China, spam or non-spam. It's up to you to determine whether or not this is an acceptable compromise. I assume, like with users of korea.services.net, administrators who choose to use this list are fed up with spam from a certain country's servers, and receive little enough legitimate mail from a country that the risk of false positives is considered acceptable.

Which DNSBLs work well?

This is a question I get quite often and it’s a tough one to answer. I don’t really bother with running my own mail system any more, as I’m tired of the headache and happy to leave the server-level spam prevention to somebody else.

And I'm tired of taking other peoples' word for it that a certain blocklist works well or doesn't work well -- I've been burned a number of times by people listing stuff on a blocklist outside of a list's defined charter. It's very frustrating. And lots of people publish stats on how much mail they block with a given list, which is an incomplete measure of whether or not a list is any good. Think about it. If you block all mail, you're going to block all spam. But you're going to block all the rest of your inbound mail, too. And when you block mail with a DNSBL, you don't always have an easy way to tell if that mail was actually wanted or not.

So, I decided to tackle it a bit differently than other folks have. See, I have my own very large spamtrap, and the ability to compare lots of data on the fly.

For this project, I've created two feeds. One is a spam feed, composed of mail received by my many spamtrap addresses, with lots of questionable mail and obvious non-spam weeded out. I then created a non-spam feed. In this “hamtrap” I am directed solicited mail that I signed up for from over 400 senders, big and small. Now, I just have to sit back, watch the mail roll in, and watch the data roll up.

For the past week or so, I’ve been checking every piece of mail received at either the spamtrap or hamtrap against a bunch of different blocklists. I wrote software to ensure that the message is checked within a few minutes of receipt, a necessary step to gather accurate blocklist “hit” data.

After that first week, here’s what I’ve found. It might be obvious to you, or it might not: Spamhaus is a very accurate blocklist, and some others...aren't. Spamhaus’s “ZEN” blocklist correctly tagged about two-thirds of my spam, and tagged no desired mail incorrectly. Fairly impressive, especially when compared to some other blocklists. SORBS correctly tagged 55% of my spam mail, but got it wrong on the non-spam side of things ten percent of the time. If you think throwing away ten percent of the mail you want is troublesome, how about rejecting a third of desired mail? That’s what happens if you use the Fiveten blocklist. It correctly would block 58% of my spam during the test period, but with a false positive rate of 34%, that would make it unacceptable blocklist to use in any corporate environment where you actually want to receive mail your users asked to receive.

One fairly surprising revelation is that Spamcop’s blocklist is nowhere as bad as I had previously believed it to be. I’ve complained periodically here about how Spamcop’s math is often wrong, how it too often lists confirmed opt-in senders, how it is too aggressive against wanted mail, but...my data (so far) shows a complete lack of false positives. This is a nice change, and it makes me very happy to see. Assuming this trend keeps up, I think you'll see me rewriting and putting disclaimers in front of some of my previous rants on that topic.

NJABL Dynablock List Now Obsolete

With the advent of Spamhaus's new PBL anti-spam blocking list, it appears that the NJABL Dynablock list is now obsolete. I just saw the following post on the public SPAM-L mailing list, from the NJABL folks: The following text was sent to list AT njabl.org on Jan 19, 2007. Judging from the number of DNS queries still being handled for dynablock.njabl.org, the message doesn't seem to have made it to a wide enough audience.

If you use or know people who use dynablock.njabl.org, this is important information:

With the advent of Spamhaus's PBL (http://spamhaus.org/pbl/), dynablock.njabl.org has become obsolete. Rather than maintain separatesimilar DNSBL zones, NJABL will be working with Spamhaus on the PBL. Effective immediately, dynablock.njabl.org exists as a copy of the Spamhaus PBL. After dynablock users have had ample time to update their configurations, the dynablock.njabl.org zone will be emptied.

Other NJABL zones (i.e. dnsbl, combined, bhnc, and the qw versions) will continue, business as usual, except that combined will eventually lose its dynablock component.

If you currently use dynablock.njabl.org we recommend you switch immediately to pbl.spamhaus.org.

If you currently use combined.njabl.org, we recommend you add pbl.spamhaus.org to the list of DNSBLs you use.

You may also want to consider using zen.spamhaus.org, which is a combination zone consisting of Spamhaus's SBL, XBL, and PBL zones.

(Editor's note: I'm very happy with ZEN so far. See this post detailing my recent experiences.)

Spamcop Roundup

5/22/2007: This information is out of date. Please click here for my latest take on Spamcop's SCBL.

My most recent take on Spamcop, from February 2007, can be found here. In that commentary, I talk about the history of the Spamcop spam reporting service, its current corporate ownership, and my take on how this type of DNSBL works, especially as to how it relates to to the impact against solicited (wanted) mail.

In February 2007, I found that Microsoft is using Spamcop to filter inbound (corporate) mail. By corporate mail, I mean mail to microsoft.com users, not mail to MSN/Hotmail users. This surprised me, because of what I believe are aggressive listing practices on the part of Spamcop. Indeed, how the issue was brought to my attention was by an unhappy person mad because he couldn't send one-to-one mail to Microsoft, because Spamcop blocked it.

Also, back in 2003, I published an article about the ongoing issues I was having with Spamcop blocking opt-in confirmation requests. Back then I found (through some admittedly unscientific survey techniques) that admins using the SCBL seemed to assume that all blocked mail must be spam because Spamcop blocked it. Not a very encouraging find. It was also a bit insulting to be lectured on how confirmed opt-in worked by people who were blocking confirmed opt-in requests, especially considering I've been pushing senders to implement and utilize confirmed opt-in/double opt-in for many years.

Spamhaus ZEN: Recommended

Look for a longer article from me in the near future on Spamhaus; I'm collecting a ton of data against a large spam corpus and hope to summarize and publish my findings within the next month or so.

Until then, feel free to bop on over to Spam Resource, where I talk about my experience using the Spamhaus ZEN list to tag and filter inbound mail to our abuse desk. I've been quite pleased with the results.

Also of note is that Microsoft is using both Spamcop and Spamhaus to reject mail to their corporate users. (They're NOT using it on MSN Hotmail.)

Update: Find my full review of Spamhaus ZEN here on DNSBL Resource.

DCC: Spam filter?

The Distributed Checksum Clearinghouse (DCC), created by Vernon Schryver, is a very powerful tool to help system administrators identify and block bulk mail. The project's website suggests a strong correlation between "bulk" and "spam," but as I do a bit more research, I don't think it's always that simple.

There's a common misconception in the spam filtering world (and the sending world) -- people think DCC is a spam blocking list. It's not, though. It's a tool to help users block bulk mail, not spam mail. That's an important distinction.

Think about it. There are a lot of types of bulk mail you might have signed up for and might want, things like newsletters you actually subscribed to, messages from companies you've done business with and actually want to hear from, or news, weather and traffic alerts you might be waiting for. (I don't need an email message to warn me that it's snowing outside, but I know that lots of people sign up for these.)

DCC tells you whether or not the mail attempting to be delivered was sent to lots of people besides you. Sure, spam is sent to lots of people all at once, but so is a bunch of solicited mail. What defines spam is whether or not you signed up to receive it. If you signed up to receive it, whether or not other people are getting it too has no bearing on the fact that you asked for it.

If a filter like DCC rejects a piece of mail you actually solicited and wished to receive, I would consider that a "false positive." To help prevent false positives, proper DCC usage dictates that you whitelist, ahead of time, all the sources of legitimate list or bulk mail you wish to receive. They include this sample file to get started, and they recommend this whitelist of example small messages that are most likely to be caught up in the filtering, even if solicited.

As Vernon Schryver himself said on the DCC mailing list recently, false positives "speak to a misuse or misunderstanding of [DCC]." He says that in a sense, there's no such thing as a DCC false positive. My interpretation of his comments is that he means that it's up to users of DCC to know what they're getting in to. DCC blocks mail sent to multiple recipients, and it's up to you to whitelist any mail sources you want to receive mail from.

DCC is a very powerful tool. That's both a plus and a minus. If you know what you're doing, comfortable working without a safety net, manually compiling lists of sites you want to receive any sort of bulk or list mail from, then maybe it can work for you to help reduce spam.

But, if you're not clear on the difference between bulk and spam, are not clear on what sites are sending you bulk or list mail that you or your users will want, then it's not going to work the way you think, and it's going to reject mail that you or your users asked for.

Internet Service Providers (ISPs), when deciding whether or not to accept a sender's mail, do measure whether or not your message is being sent to multiple people. It's not the only thing they look at, though. The smarter ISPs tie in a reputation measurement to that process. Meaning, is this mail coming from a good sender, or a bad sender? Does this sender generate spam complaints? Does this sender generate an above average percentage of bounces? Wrap that all up together, and an ISP has good info available to them to decide what mail to accept. Don't measure any of those things, and you're left with an incomplete view -- no easy way to tell the good mail from the bad. It's up to you to know about and whitelist the good senders ahead of time. If you don't, you're going to reject mail from them, presumably mail that you or your users wanted to receive.

Spamcop BL: A blacklist with a hair trigger

The Spamcop Blocking List (SCBL) is a DNSBL populated with data obtained from spamtrap hits and spam reports from users of the popular Spamcop spam reporting service. The Spamcop spam reporting service was originally created by Julian Haight. It was later purchased by Ironport Systems. Ironport has since been purchased by networking and communications technology company Cisco. (In spite of this transition to corporate ownership, the Spamcop site's front page contains a prominent legal defense fund link, and contains further information on the fund in the Spamcop FAQ.) 

Unlike the more privately-run CBL, which is designed to minimize the impact on legitimate mail, the SCBL regularly blocks sources of mail that some feel are legitimate. It has been described as having a "hair trigger" by respected anti-spam and internet guru John Levine, and I related some of the issues I've had with Spamcop from 2003 over here on spamresource.com. In fact, back around that time, the SCBL information page said this regarding using the list: "This blocking list is somewhat experimental and should not be used in a production environment where legitimate email must be delivered." As I look at the same page today, in February, 2006, I can see that guidance has since been modified somewhat. Spamcop now recommends "use of the SCBL in concert with an actively maintained whitelist of wanted email senders. SpamCop encourages SCBL users to tag and divert email, rather than block it outright." Both then and now, they go on to add, "The SCBL is aggressive and often errs on the side of blocking mail." 

Translated: "Don't block mail with this blocking list, it will block mail you want." 

Like ISP feedback loops, the spam complaints lodged by Spamcop users are sometimes found to be erroneous. That's not to say that where there's smoke, there's never a fire. But just like with feedback loop reports, significant spam issues generate far more reports than than the day-to-day noise of people lodging spam reports about email from a company they previously did business with, or otherwise had a potentially legitimate reason to be contacted by a given sender. (As an example, I noted my issues with confirmed opt-in/double opt-in systems being listed by Spamcop in 2003; I don't believe I'm the only one to ever have observed that kind of issue.) My experience with Spamcop has taught me that it's not always that good at drawing the line between blocking spam and blocking wanted mail. 

Spamcop's probably really good at blocking spam-in-progress from infected servers spewing illegal spam. (Though, the CBL isn't too shabby at that, either.) The problem is, Spamcop will block mail in a number of edge cases, like if an email service provider is tasked with serving mail on behalf of some e-commerce or travel site. If you want to ensure that you're always going to receive your follow up emails from the department store you ordered that purse from, or the hotel reservation from a booking site that outsources their confirmation email, choosing to outright block mail from servers listed on the SCBL may not be your best choice.