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 10^th. 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

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.

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.