Al Iverson's DNSBL Resource

Status of APEWS: Down

2010-08-10T09:47:00.000-05:00

Long-standing (though not very accurate) blacklist APEWS seems to be down for the count. Their website at www.apews.org has been down for more than a week now, according to reader Steven, who contacted me a few days ago. I last visited the APEWS website a few weeks ago, just curious if it was still out there, and it was up back then.

The APEWS zone files are hosted by third-parties, and my tests show them as still responding. However, their information is likely to grow out of date, as they're probably unable to update the data, provided by APEWS, that fills those blacklist zones.

My recommendation to mail administrators is to stop using APEWS. But then again, was anybody using APEWS recently, anyway?

If you find yourself blacklisted by APEWS, here's what to do.

Status of ybl.megacity.org: DEAD

2010-03-31T15:19:00.001-05:00

There once was a DNSBL called ybl.megacity.org. Exactly when it was created is lost to the mists of time, but I'm guessing it was somewhere around the end of 2001 or beginning of 2002, after its maintainer, Derek Balling, parted ways with Yahoo. I recall that the point of the blacklist was to be able to reject mail from Yahoo.

Today, reader John Carver kindly wrote in to let me know that this blacklist is indeed defunct and has "listed the world," installing a wildcard DNS record with the result that if you use ybl.megacity.org in your mail server configuration, you're going to reject 100% of your mail. Query of any domain or IP address under ybl.megacity.org will result in a "127.0.0.2" positive response, that will make a mail server think it should reject the email message in question.

If you use ybl.megacity.org as a blacklist in your mail server configuration, I strongly recommend you remove it immediately. The list is long dead, and use of the list will result in you accidentally rejecting 100% of inbound mail.

As recently as 2006, the DNSBL also responded with text warning that it was defunct: "521 The IP is Blacklisted by ybl.megacity.org. This zone has been deprecated for about two years. Maybe if it starts blocking your mail you'll notice and stop using it." This is no longer the case; the text record does not seem to be present.

See also the Ipswitch ImailServer knowledge base article on this topic.

Beware: "Fake" Blacklist at nszones.com

2010-03-31T08:58:00.000-05:00

Spamhaus reports that they have "uncovered a fake spam filter company which was pirating and selling DNSBL data stolen from major anti-spam systems including Spamhaus, CBL and SURBL, republishing the stolen data under the name 'nszones.com.'"

Ouch. I guess if you publish a free or easily accessed spam filtering tool, it is inevitable that at some point somebody would try to take the data and repackage it against copyright and against the data owner's wishes.

If you find yourself listed on this blacklist; don't fret. If what Spamhaus says is true (and I have little reason to doubt them), then this list is not really being used to block email. (And should not be used to block email.) Ignore it, stay listed, and eventually they'll move on to easier targets.

If you're a system administrator, DO NOT use any of the blacklists at nszones.com for spam filtering purposes. As its intent may not be above-board, I would have strong concerns about the possibility of listing things only to engender a payment for delisting -- for reasons having nothing to do with spam fighting.

SURBL Announces New Experimental Blacklist

2009-12-10T13:41:00.002-06:00

Today, the team behind the SURBL domain blaclists announced a new, experimental blacklist: xs.surbl.org.

As announced on the SURBL-Announce list: "An experimental source of some snowshoe and pill domains is now being published in xs.surbl.org. SURBL considers this feed to be experimental and would very much welcome feedback about it, particularly about any false positives. Does anyone know anyone who actually wants to receive snowshoe messages?"

You can read the entire announcement here.

Status of dnsbl.karmasphere.com: SHUTTING DOWN

2009-11-02T20:36:00.000-06:00

As messaged to the Karmasphere-Users and Karmasphere-Announce mailing lists, the Karmasphere Reputation Services data feeds are being retired. This means that the associated blacklist(s), including the karmasphere.email-sender.dnsbl.karmasphere.com DNSBL zone, and any other DNSBL/DNSWL zones under karmasphere.com. It is unclear to the author if karmasphere.org is similarly affected.

Karmasphere has indicated that the feed service will be discontinued on November 16, 2009. It's very important that all Karmasphere-using mail administrators remove any Karmasphere-hosted DNSBLs from their configuration before that date, else inbound receipt of legitimate email messages could be delayed or otherwise impacted.

For more information, click on over to Spam Resource to read a copy of the Karmasphere notice.

Status of rbl.cluecentral.net: DEAD

2009-10-13T08:05:00.003-05:00

The rbl.cluecentral.net DNSBLs were created in 2001 or 2002 by Sabri Berisha. The goal: To list "all known assigned IPv4 address space, by originating AS and by country. [This is based on] a full routing view is extracted daily from a router in the default free zone. The AS->country mapping is done via the statistics which are being provided by the four RIR's, ARIN, APNIC, LACNIC and RIPE."

Today, the website warns that the rbl.cluecentral.net service is closed. Sabri notes that "[it has become] more and more difficult and time-consuming to maintain a trustworthy list I started to notice more and more errors. The list is no longer of the quality needed to use in a production environment."

The website warns that if DNS queries continue at a high level, the DNS servers are likely to be configured in a way that will cause 100% of inbound mail attempts to be rejected, for all mail servers still using rbl.cluecentral.net. This makes it imperative that you remove any rbl.cluecentral.net zones from your mail server configuration, as soon as possible.

Status of blackholes.us: DEAD

2009-10-11T23:15:00.001-05:00

Created by Matthew Evans in 2002, the goal of the blackholes.us site was "to create (yet more) DNS blocklists of spammers, spam supporting ISPs, spamware hosts, dialup networks, and other notorious email abusers originating in the United States." Matthew published many different DNSBL zones, listing various countries, ISPs, netblocks, etc.

It is now no more. As of October 11, 2009, the website at www.blackholes.us makes it very clear that the blacklists are no more, and should no longer be used: "The listing services that used to be part of BLACKHOLES.US is no longer alive. The IP address space that they used for name servers now belongs to another, unrelated entity. We would like to use our space without the tens of thousands of DNS queries per second coming to us. So it would be MOST USEFUL if you or your email administrator would REMOVE any reference to blackholes.us from your anti-spam system. There is no LIST REMOVAL service. The "removal" process is simple, DO NOT USE the BLACKHOLES.US domain for your filtering or anti-spam system."

As reported today on the SPAM-L mailing list, all queries against the blackholes.us zones result in a positive match -- meaning that if you use this blacklist, you will block 100% of your inbound mail attempts until you remove any reference to blackholes.us from your mail server configuration.

Status of vox.schpider.com: DEAD

2009-10-07T11:33:00.003-05:00

Scott Glassbrook writes: "I ran a dnsbl, vox.schpider.com many many years ago. I stopped the DNSBL back in June of 2006, and shut down the server it was running on.

"Since that time, all queries to vox.schpider.com have timed out. I made an attempt to bring the domain name back up in 2008, only to find that people are still trying to query the domain name. [...] Because of that, I see no other option than to start returning positives for *any* query issued to vox.schpider.com, beginning 10/16/2009. If you happen to be trying to use a dead DNSBL, please update your mail server configuration."

Scott indicates that random mail administrators are still "pounding the hell" out of his DNSBL hundreds fo times per second, all day and all night, ever day. Not cool.

If you're still querying this DNSBL, it's important that you immediately remove it from your mail server configuration. As of October 16th, use of this DNSBL will result in you rejecting 100% of your inbound email.

Status of bl.open-whois.org: DEAD

2009-08-18T07:06:00.006-05:00

As of July, it looks like a popular blacklist used in default SpamAssassin installations is no more. Users were reporting false positive issues, where every message checked by SpamAssassin would receive a score of 2.43, supposedly due to the sender being listed in the blacklist bl.open-whois.org.

The Open Whois Blacklist appears to have been created in 2007, with a goal of promoting transparency in domain registrations. According to the (now deceased) website, "It is a list of domains which are privately (or anonymously) registered, e.g. through services such as Domains By Proxy, or Moniker Privacy Protection."

As of July 18, 2009, it appears that a squatter has taken over the open-whois.org domain name. At first, the new owner of the domain used a "wildcard" DNS record, resulting in the return of a positive response for any DNS query. The net effect is that every domain checked against this blacklist results in a DNS response that makes your spam filter think that the domain is blacklisted, usually incorrectly so.

Since the issue was first observed, the squatter must have noticed all of this DNS traffic coming from SpamAssassin users and decided that the traffic was undesirable, so they've modified the domain in whois so that its name servers point at obviously invalid IP addresses.

That's good, because it means there shouldn't be any more false positive issues, for now. But, it does mean that your SpamAssassin checks take longer than usual, as queries against this dead blacklist will time out. (And who is to say the squatter won't resurrect the domain with valid DNS servers and perhaps another DNS wildcard, causing a whole new batch of false positives for a whole bunch of SpamAssassin users.)

If you're a SpamAssassin user, it would be wise to remove or disable the SpamAssassin rule that check for that blacklist. The rule you're looking for is located in the "72_active.cf" file in the rules subdirectory of your SA installation.

To disable this check in your SpamAssassin installation (manually), move or delete the "72_active.cf" file from your rules directory. Where this directory is exactly located is going to depend on your installation. On my friend's Linux installation, the directory path is /etc/mail/spamassassin/rules .

The better thing to do, I was advised by friendly SpamAssassin user Phil Randal, is to run sa-update. It's best practice for SA users to run sa-update every week or few to load the latest "in between-release" updates. Running sa-update will ensure that the bl.open-whois.org check is disabled.

I suspect that this blacklist check will be removed from SpamAssassin in future releases, but as of today (8/18/2009), the check is still in the most recent version available for download (3.2.5). As long as you run sa-update or manually disable this check, you should be all set.

TQMCUBE Status Updated

2009-08-17T15:43:00.004-05:00

Here's a quick note to let you know that I've updated my page of information on the long-dead TQMCUBE blacklist. Click here for more information.

Status of dnsbl.net.au: Dead

2009-04-29T11:17:00.003-05:00

The blacklist at dnsbl.net.au has announced it is winding down. As noted in a February 25, 2009 posting on its website, "Please note that as of Wednesday, April 1, 2009 the DNSBL.NET.AU blacklist will cease to exist."

As of this writing on April 29th, 2009, I do still see active entries when querying via DNS, but I assume that these are likely to go away soon. If you utilize this blacklist, I'd recommend removing it from your MTA or spam filter configuration.

Status of DSBL: Dead

2009-03-31T10:54:00.007-05:00

The DNSBL called "DSBL" is no more. As of March 11, 2009, their website reports: "DSBL is GONE and highly unlikely to return. Please remove it from your mail server configuration."

DSBL was an open relay/open proxy DNSBL. From the website: "DSBL relied on volunteers who, upon receiving spam, would test the IP addresses that sent them spam for open relay and open proxy vulnerabilities.

"The tests consisted of doing a straightforward open relay test on the sending IP address, as well as open proxy tests on a few well-known proxy ports (1080, 3128, etc), with the aim of relaying a test message to DSBL. Upon receipt of the test message, DSBL would add the IP address to its database."

A noble cause, if perhaps a bit of a manual process. Sad to see it go, though it does sound like perhaps its time has come and gone.

DSBL had DNSBL zone names of list.dsbl.org, unconfirmed.dsbl.org and multihop.dsbl.org.

Shutting Down Blacklists

2008-10-06T10:26:00.007-05:00

As I often do, today I'm receiving reports about a DNSBL (which I've previously warned was dead) is returning false positive entries for those still using it today.

What does this mean?

IF YOU ARE AN EMAIL ADMINISTRATOR WHO USES BLACKLISTS, you need to start paying attention. Blacklists are not "set it and forget it." Instead, you should periodically check the blacklists you're using. Ensure they are still active. Test to see that legitimate mail sent to your server is being delivered. When looking to see if a blacklist is still alive and running, look for a test entry (usually 127.0.0.2) in DNS. Make sure the DNSBL's website is still alive and doesn't mention the blacklist having been shut down. Look on sites like this one (DNSBL.com) and SpamLinks to ensure that your favorite blacklist isn't listed there as deceased.

STOP USING blacklists that are dead, or might be dead, or are observed as having problems. This is an ounce of prevention that'll prevent many pounds of pain later. Some DNSBLs, when they die, they eventually "list the world" -- making your mail server block every single piece of mail, spam or not. You lose a lot of mail, very quickly, when that happens.

IF YOU ARE A BLACKLIST OPERATOR, or you're considering becoming a blacklist operator, then you need to read this proposed BCP document: Guidelines for Management of DNSBLs for Email. It's fairly new, so I can understand that not everybody who runs a BL has read it, or understands everything in it, or listens to it. But it's very important that people start reading it, start understanding it, and start incorporating its guidance into their practices.

Why? Because it tells you the right way to run a DNSBL. It explains the best way to provide notice to potential users as to how the DNSBL is implemented, what your policies are, best practices for test entries, and most importantly: Best practice for shutting down a DNSBL in a way that doesn't screw things up for the system admins who are using your DNSBL currently.

This wasn't written in a vacuum; it was written collaboratively with input from a wide range of folks involved in DNSBLs and spam filtering efforts both current and past. And it is by no means set in stone -- but somebody has to start somewhere, and this is what a bunch of smart folks came up with. This should be a must read for any current or future blacklist operator.

Security Sage Update

2008-05-26T13:19:00.002-05:00

It seems today as though the Security Sage domains have expired and/or replaced by "placeholder" pages by their registrar. Net result: Bad things. If you were still using their BL, you're probably having problems receiving inbound mail right about now.

DSBL Current Status: DOWN

2008-05-20T10:06:00.006-05:00

DSBL, the Distributed Sender Blackhole List, seems to have gone missing. The list appears to have been in operation since at least May, 2002.

The website at www.dsbl.org is not currently responding. Their mail server specified in their MX record is non-responsive, and any DNS mirrors still responding seem to be hosting an out-of-date copy of the blacklist's zone data.

I've talked to the maintainer. The server hosting DSBL died; attempts are underway to find new hosting and a new project maintainer, but it doesn't sound as though anything that would cause immediate resurrection of the site and data.

Three zones were available: list.dsbl.org, multihop.dsbl.org, and unconfirmed.dsbl.org. At this time, I would recommend that you remove these lists from your mail server configuration, as queries may time out, and any responses returned will be out of date.

Watch this space; it will be updated as more information becomes available.

Help, we're listed on ORDB!

2008-03-26T10:51:00.006-05:00

I've received multiple queries about this today, so I figured it would be wise to put up a quick message about this.

ORDB is a long dead blacklist, gone for more than a year.

Recently, they started "listing the world" -- meaning everybody using ORDB is now blocking 100% of inbound mail. Blacklists do this to shed themselves of any excess DNS query traffic from sites who haven't yet ceased querying their data. It can very much be considered a slap in the face -- hey, we tried shutting down the nice way, but since you're not listening, we're going to make all your mail bounce.

But what does that mean? Why am I listed?

You're not actually listed on ORDB. ORDB is returning a "yup, they're listed" answer for any IP address that people check. Meaning the whole world is listed. Everybody, not just you. It's not because they hate you, it's because they want people to stop querying their blacklist.

If you received bounces from somebody that suggests that you're listed on ORDB, here's what to do:

Call that person on the phone, if you can. Tell them all of their inbound mail is probably not working, and won't work, until they stop using ORDB. Point them to this page for more information.
Don't worry. The person who bounced your mail is suddenly now having problems receiving any mail at all. They're likely to figure this out very quickly and fix it. Try your mail again, in a day or two.

False Positives

2007-11-19T17:03:00.002-06:00

One of the things I measure over at the Blacklist Statistics Center is false positives. What are false positives? How do I use the term, exactly?'

Ultimately, there are three different ways to define false positives, depending on whom you ask and who they are. Allow me to explain.

Here's what I think of as a false positive(1) in the context of DNSBLs: You did not receive a mail message you signed up for, and wanted to receive, because it was blocked by your use (or your ISP's use) of that DNSBL.

This is what I consider a false positive. If you signed up to receive news alerts and wanted to receive those alerts, but you couldn't receive them because your spam filter blocked that email, that's what I would call a false positive. This is very end-user focused, or recipient system focused.

That can be quite a bit different than what a blacklist calls a false positive(2). The example above might not be a false positive as far as the blacklist operator is concerned. Maybe somebody sent mail to their spam traps from that IP address. Or maybe the blacklist's policies are such that they choose to list an entire net block because of spam issues elsewhere in that net block.

I used to be a blacklist operator myself. Back then, what I considered a false positive(2) was a blacklisting that shouldn't have taken place, by my own reckoning. I primarily dealt with open relaying mail servers. If I had accidentally listed an IP address, even though it wasn't an open relay, that probably would be considered a false positive.

But, to the person whose mail is getting blocked as a result, that could constitute a whole other kind of false positive(3). Getting deep into that kind of false positive is a bit beyond the scope of what I'm doing here. Anybody whose mail has been blocked for any reason can feel it's unwarranted. Sometimes I would agree, sometimes I would not. But, that's not a debate for right here and right now.

Instead, I focus on the definition of false positives I think is most applicable to end users of DNSBLs: Mail you (or I) wanted to receive, but didn't receive, because receipt of that mail was blocked by that DNSBL.

That's the only kind of false positive I'm measuring and reporting on.

The Union of UCEPROTECT

2007-11-10T17:53:00.001-06:00

The folks behind UCEPROTECT asked me what it would look like if I were using all three UCEPROTECT backlist zones together. I thought it was a neat idea and decided to share the results publicly. Click here to take a look.

Spam & Ham: Overview & FAQ

2007-11-10T17:27:00.002-06:00

A lot of people have asked how the spam and ham (non-spam) data is compiled for the Blacklist Statistics Center here at DNSBL Resource. Where does it come from? What senders does it represent? Here's an updated overview of what goes in to the spam and ham (non-spam) feeds here at DNSBL Resource.

On the spam side of things, the input comes from a series of spamtrap domains and email addresses.

When I first set this project up, I took a bunch of old, dead email addresses and domains that I have had for years but haven't been using lately. I turned them back on, reviewed long snaphots of incoming data, and weeded out a lot of “edge case” stuff – things that I probably did actually sign up for (like virus notifications, updates from my domain registrar, etc.). Anything that didn't look like something I might have signed up for was assumed to be spam.
I also have some filtering in place to try to keep out backscatter. Backscatter (or outscatter) usually consists of misdirected bounces received in response to somebody else's spam run, bounced back by a mail server that should know better. This is clearly a problem, but there is vast disagreement on the anti-spam front as to whether or not backscatter equals spam. Since few agree, and I want to focus on spam, I ignore this as much as possible. A little leaks through here and there, but I don't think it's enough to skew any stats.
I recently registered some new domains that I and others knew were already were on spam lists. Anybody sending to these new domains clearly is doing a bad thing – sending to very old addresses, ignoring bounces, forging header information, etc. These also feed into the spam results.
From all of these sources, I get an average of over twelve thousand spam messages a day.

On the ham (non-spam) side of things, here's what I've done:

First, I signed up for a bunch of email lists. Stuff that I think regular users sign up for. Some of it is commercial, some of it isn't.
By commercial, I mean newsletters from different retailers, ones where I have a pretty strong suspicion that people actually sign up for their mail. Clothing stores, electronics retailers, etc.
Restaraunts. Some national chains and etc., but mostly info from my favorites in and around Chicago, Minneapolis, and other places I travel to.
Lots of media-related things. By this I mean news alerts from different newspaper and TV stations. Weekly newsletters for my favorite public radio shows. International media, national media, some local media. Movie reviews, too.
Some travel-related things. Notifications from different travel sites on upcoming sales, airport delays, etc.
A bit of geek stuff. Virus alerts, some how-to newsletters, various tech and science newsletters, etc.
In addition to all of this, there's a lot of one-to-one mail in the loop now, too. Mail from users at AOL, Hotmail, Yahoo, Gmail, and other big ISPs.

Frequently Asked Questions about the Spam and Ham Sources

What happens if I receive both spam and ham from the same IP address?
There's no evidence that this is happening yet, but if it happens, the spam is going to show up in the spam bucket, and the ham is going to show up in the ham bucket. I'm calculating based on specific email messages received, not just the IP address of the sender. Under no circumstances have I ever taken spam and counted it as ham, or vice versa.

But big company X is sending you ham (desired mail) and sending other people spam!
I kick senders out of the hamtrap feed if I see them doing something bad, like sending spam or re-purposing email addresses. I don't, however, take a blacklist's word alone that somebody must be a spammer simply because they're blacklisted. Clearly, not every blacklist gets it right every time. Even a good blacklist might list somebody who is sending me wanted mail, perhaps because they're sending unwanted mail to someone else. My take on this is that the more often this happens, the more likely it is that the blacklist is overly aggressive or questionably accurate. It's up to readers of my site to decide if the data I report suggests the same to them. Not everyone is likely to come to the same conclusion.

But the big ISP mail servers also send spam – aren't you going to mislead people by counting a mail from AOL as a false positive hit if that same AOL server is also sending spam?
Sure, every network emits spam sometimes, to some degree. I think the big mail servers at the big ISPs are probably no different. But, can you safely block mail from these IP addresses? After all, they send millions of legitimate messages daily. If you care about not blocking mail that your users want, you are probably going to tread lightly when it comes to deciding whether or not to block servers like that. I suspect that blacklist publishes face similar challenges. Maybe this data reveals exactly how quick on the trigger a blacklist may be in that situation.

But this is too much ham (non-spam) for one person to receive; it's not reflective of normal mail.
Sure, it's a bit concentrated, and the volume is somewhat high, but it's not supposed to be reflective of one single person's mailbox. Instead, it's actually a combination of a bunch of kinds of desired mail, from a bunch of different sources, that regular users are (in my humble estimation) are likely to receive. A single user at an ISP is unlikely to receive the 12,000+ spam messages I receive every day – it's similarly a combination of spam sent to a bunch of different users.

Clearly, you must be gaming the ham and spam feeds to make blacklist X look good at the expense of blacklist Y.
No, I am not. I'm simply reporting how these blacklists intersect with my own mail streams. Your mail streams may be different than mine. The same goes for any blacklist – not all are created equal. Not all have access to the same amount, or same quality, of data from which to decide what to list. Some might work better in foreign countries (I am in the US), some might work better in a hobbyist or educational setting (I think my data is more reflective of what a small to midsize ISP might see.) I have had some blacklist operators tell me that my data nearly exactly matches theirs, and I have had other blacklist operators tell me that my data is nothing like theirs. As always, your results may vary.

You really need to show results based on unique IP addresses.
I don't dedupe (remove duplicates from) the results based on IP address because I'm not counting IP addresses; I'm counting email messages. This isn't about who has the biggest list with the most IP addresses; it's about how accurate it is against my own mail stream. Any regular user who finds that a blacklist blocked ten spams from the same IP address is going to call that ten hits; not one hit.

I don't like this data because of X, Y or Z.
The best recommendation I can give in this situation is that you should consider generating your own statistics and sharing them with the world. I know that my mail streams and results definitely match what some people see – because in a lot of cases those people have contacted me and told me so. It's also exactly reflective of my own mail stream. Just because it's what we see doesn't mean that this is exactly what you'll see if you use the same blacklists. There are too many open variables, from the side of my spamtraps, to which spam lists I'm on, the composition of the mail your users sign up for, etc. As I said above, your results may vary.

Incidentally, I'm not above some friendly competition. I'd love to see more sites like this out there.

If you have any questions or comments about anything here, about the Blacklist Statistics Center, or anything on DNSBL Resource, please don't hesitate to contact me.

Status of bl.csma.biz: ALIVE

2007-11-03T10:35:00.002-05:00

McFadden Associates has been publishing two different, spamtrap-driven DNSBL zones since October 2003.

A primary zone, bl.csma.biz, containing only aggressive hosts that have spammed repeatedly during a short (recent) timeframe.
An additional zone, sbl.csma.biz, with more aggressive listing criteria. It lists hosts that have generated spam within a 45-day period. They recommend that this one not be used for outright rejections; indicating that it was instead more suitable for use in scoring systems like SpamAssassin.

I personally use these lists in my day job as one of many data points to vet potential clients. In late October, coworkers asked me to look into repeated timeouts in our DNSBL lookup tools. Investigation revealed that the McFadden blacklist name servers and website were no longer reachable on the Internet.

I contacted one of the administrators behind these lists on Saturday, November 3, 2007, who indicated to me that the issue was unintentional; related to problems with a new piece of hardware. The situation has been corrected, and these lists are now again responding to queries.

Status of rbl.spamhaus.org: NOT A BLACKLIST

2007-11-03T10:16:00.002-05:00

My friend Mickey Chandler pointed out recently that he's been seeing some unusual bounces that look like this:

Host blacklisted - Found on Realtime Black List server blocklist.address.is.wrong.spamhaus.org

It turns out that you block all of your inbound mail with an error like this if you configure "rbl.spamhaus.org" in your mail server as a DNSBL zone for blocking purposes.

Why? Because there is no such zone as rbl.spamhaus.org. Looks like Spamhaus set up these DNS responses to queries of this non-existent zone so that people would quickly realize that they're querying the wrong thing.

Actual Spamhaus DNSBL zones include sbl.spamhaus.org, xbl.spamhaus.org, zen.spamhaus.org, and others. I recommend using them, the ZEN zone in particular, as they're very accurate. But, regardless of what zone you use, it's important to use one that actually exists.

Users of rbl.spamhaus.org will find no spam blocking value from use of this zone, and are likely to find all of their inbound mail rejected.

Status of blackhole.securitysage.com: DOWN

2007-10-26T15:30:00.004-05:00

The RHSBL (right hand side blacklist) blackhole.securitysage.com appears to have been created by Jeffrey Posluns and appears to have been around since at least August, 2004.

I received a report today indicating that a mail administrator has been unable to reliably query the blackhole.securitysage.com blacklist zone. With the help of my friends, I was able to confirm this issue.

It looks to be a DNS issue. What we see from here is that the zone blackhole.securitysage.com is delegated to nameserver blackhole.securitysage.com. The two DNS "glue entries" for the zone are servers that aren't configured to be authoritative for the zone, so no results are returned. Ultimately, this points toward a DNS configuration issue with this domain and/or sub-domain.

The popular anti-spam filter SpamAssassin has been tracking this issue since at least October 8, 2007. On October 17th, SpamAssassin decide to remove support for this blacklist (implemented in the DNS_FROM_SECURITYSAGE rule), due to the ongoing issues with accessing this blacklist.

As a result of this ongoing issue, I recommend against using the blackhole.securitysage.com blacklist. If you continue to check against this blacklist; queries are likely to time out and it could delay the receipt of inbound mail. Use of this list while this issue persists is likely to provide no blocking or filtering benefit.

I, and others, have contacted Security Sage and Mr. Posluns, making him aware of the issue and asking for more information. I'll be sure to update this page with more information as I have it.

11/03/2007 update: I've seen no response to my email to Mr. Posluns, nor to a friend's email to Security Sage's support address. I emailed that support address today, and my attempt bounced. The error message suggested an SPF failure. The fact that I publish a working SPF record, and other information in the bounce, suggest that it is in error. I guess that means either nobody's home, or they don't want anyone to contact them.

5/26/2008 update: Way back in November, I talked to Jeffrey Posluns. He is no longer actively involved with Security Sage, but was kind enough to nudge the folks running things, in hopes of making things better. It fell off my radar, until a few days ago, when I was alerted to the fact that Security Sage's domains have expired.

Net result: Broken blacklist. Has a wildcard listing, meaning that if you use their list, you're probably negatively impacting your own email delivery.

My recommendation: Stop using this blacklist immediately and permanently. Even if they do somehow manage to pull things back together, they don't have a good track record of staying online.

Expanded Spamtraps and Hamtraps

2007-10-18T16:19:00.002-05:00

As always, I'm looking to maintain and improve the accuracy of the data behind the reports over at the Blacklist Statistics Center here at DNSBL Resource. Here's a quick overview of a couple of recent improvements I've made.

Just this week, I've turned up an additional spamtrap feed. This data is based on a set of domains that were no longer routed, but are found on many spammer lists. Not sure how much this will change the spamtrap data, but we will see. It's always good to mix things up.

What this means: I'm broadening my view of the net, working to keep things on the up-and-up by expanding the inbound spam feed to keep this data from becoming biased; if my spamtrap feeds were small enough that they overlapped with one list's traps significantly, but not another's, it could potentially bias results in favor of that list. I don't think this is happening currently, but I'm going to continue to change things up periodically in an attempt to pro-actively attempt to prevent this from ever happening.

On the hamtrap front, I'm now periodically testing to see if various blacklists are blocking large webmail provider outbound mail servers. So far, I'm checking AOL, Hotmail, Yahoo, and Gmail. I don't have a complete view of what all of the outbound IP addresses are for each site; only AOL seems to publish a comprehensive list. I've determined what I can based on headers from real mail that I've sent and/or received over the past week or so. Feel free to contact me if you have pointers to official, published information from the bigger sites.

What this means: If a blacklist blocks all mail from various Yahoo IP addresses, and you have friends who use Yahoo, they're going to have trouble emailing you. If that's the case, this is going to generate significant false positives. It certainly would generate false positives for me; all of my friends seem to use one of those four webmail providers.

Some blacklists might not like that I now make, and publish, this measurement. It's true that some ISP outbound mail servers send spam sometimes, and it's true that those ISP outbound mail servers might be appropriately listed on a given blacklist. But it's also true that even though those servers might send some spam, they also send quite a bit of legitimate mail, and avoiding false positives in that situation becomes near impossible.

Ultimately, it's up to you, as a potential user of a given blacklist, to decide if that risk of false positives is acceptable. In some cases, it is acceptable. In other cases, it may not be.

Also, this makes the hamtrap measurements more likely to reflect real, one-to-one email, in addition to the newsletter and (non-spam) list mail already being tracked. I think this is a good thing.

(More good stuff is on the way...stay tuned!)

PSBL: Easy On, Easy Off

2007-10-14T16:56:00.002-05:00

The Passive Spam Block List, or PSBL (psbl.surriel.com) is a spamtrap-driven anti-spam blacklist that has been around since at least June, 2003. Created by Rik van Riel, who explains on the PSBL website that “the idea is that 99% of the hosts that send me spam never send me legitimate email, but that people whose mail server was used by spammers should still be able to send me email."

The passive nature of the list means that there's no probing or poking of remote servers on the internet (which tends to make ISPs very angry and was a significant issue back in the days of testing for open relays). It also means that there is no debate or argument with listees. As the PSBL website states, “Want to remove your mail server from PSBL? Go ahead.” No need for lawsuit threats, arguments over why listing is denied, or anything of the sort. Anyone can remove any entry for any reason.

Sounds scary, doesn't it? In theory, bad guys could game the system, and rob PSBL of its ability to stop spam. Thankfully, the data shows that this isn't something to worry about. PSBL is a pretty neat tool that can help system administrators filter or reject spam in a way that makes it very easy to prevent false positives. And even though it doesn't take a line as hard as Spamhaus or Spamcop, it manages to block some spam that they do not.

Success Rates
PSBL's success rate seems to greatly vary from week to week. Over the past ninety days, its overall effective rate is 41.4% against the spam hitting my spamtraps. Over the past thirty days, it has been 36.5% effective against spam.

False Positives
False positives are often non-zero, but generally very low. For the past eleven weeks, consistently under 1%. I suspect that this is due to the “easy on, easy off” removal policy-- If anyone trying to send you mail receives a bounce message back from you referring to the PSBL website, it's very easy for them to have their sending IP address removed from the list.

For the most up-to-date numbers, visit the PSBL page in the Blacklist Statistics Center.

Additive Numbers
Even though PSBL catches a lower amount of spam (on its own) than some other more well-known blacklists, it manages to catch some spam that those other lists do not. To determine this, I took the last thirty days worth of results, and looked for intersection and overlap between PSBL and other blacklists.

What I found is that about 9% of successful PSBL hits against spam stopped spam from IP addresses not found on Spamhaus ZEN. When compared against Spamcop, the numbers were even higher -- about 13% of successful PSBL hits stopped spam from IP addresses not listed on Spamcop.

This suggests to me that PSBL would be an excellent blacklist to configure second or third in your mail server configuration. That 9% of IP addresses not found on both Spamhaus and PSBL won't lead to a straight 9% boost in spam filtering effectiveness, due to lists being different sizes. But, if your data is like mine, you're likely to receive a boost of 3% or more.

Conclusion: I recommend PSBL. It helps to block spam that some other lists could miss, and it has friendly anti-false positive policies that make any revealed blocking issues easy to resolve.

The usual caveats applies here: This data illustrates how my own mail streams intersect with PSBL. Your mileage may vary, and I strongly recommend that you test and review results against your own mail streams.

The Fiveten Blacklist: Not Accurate

2007-10-13T13:53:00.002-05:00

“Fiveten” (blackholes.five-ten-sg.com) is a combination anti-spam blacklist run by Carl Byington, publishing under the name of “510 Software Group.” This blacklist has been available since at least February, 2001.

It has a multitude of criteria for listings.

As of this writing, the website lists the following current criteria:

Individual spam sources: “These are generally taken from spam samples that have arrived here, and from discussions on news.admin.net-abuse.email.”
Bulk mailers that don't require closed loop confirmed opt-in from all their customers, or that have have allowed known spammers to become clients.”
“Networks that provide services to spammers.”
Web servers running software vulnerable to spam relay, such as FormMail.
Open relaying mail servers.
“Free mail providers.” One assumes this relates to sites like Yahoo or Hotmail.
“Systems that send virus notifications (klez, sobig, etc) to the supposed sender.” In other words, a specific type of backscatter.
“Systems that have delivered challenge-response” messages to Carl's mail server. Yet another type of backscatter.
“Systems that are owned by organizations that latently violate the TCPA.” This refers to what most would call phone spammers, entities where Carl is aware them sending pre-recorded telephone message solicitations. (In other words, not email related.)

I've been tracking the effectiveness of the Fiveten blacklist going back to March, 2007. It, along with Spamcop, were two blacklists where I had little data about their current effectiveness. I was intensely curious as to what it targeted and how well it succeeded at stopping spam.

Over the years, I've answered a lot of questions from a lot of companies trying to figure out how to do the right thing with regard to list management and application of abuse prevention best practices. One of the recurring themes in the many emails I receive is blacklisting. I'm blacklisted! What do I do? How do I get un-blacklisted? How do I prevent myself from being blacklisted? Interestingly, one of the blacklists I'm most frequently asked about is Fiveten. Why is that?

Well, after tracking the effectiveness of Fiveten for many months, I've figured out why: Fiveten is inexact and inaccurate. It blocks only a so-so level of spam, and, on a percentage basis, it tends to block more non-spam than spam.

The chart above shows the thirteen-week average effectiveness as measured against my spamtrap and hamtrap mail sources. Fiveten has an approximately 40% success rate with regard to filtering spam. However, it gets it wrong a staggering 44% (approximate) of the time with regard to non spam.

Analysis of the raw data suggests to me that Fiveten's poor (high) false positive rates is primarily due to Fiveten's listing of “bulk mailers that don't require closed loop confirmation opt-in from all their customers.” As a result, Fiveten has thousands of senders listed that have never send spam, specifically because they choose not to utilize double opt-in. This means that Fiveten is effectively a tool that blocks “things the maintainer doesn't like,” which is a wholly different criteria than blocking spam. Against my own data, it appears that there is no direct correlation between spam and the blacklist maintainer's choices for listing criteria.

There's nothing wrong with making a blacklist that requires that any sender not utilizing double opt-in be listed. It's fair to ask how accurate such a list would be, or is. Is there a correlation between lack of confirmed opt-in and spam? Double opt-in, or confirmed opt-in, is a practice that I have strongly promoted for many years. Indeed, I've designed and built a number of confirmed opt-in systems myself over the years, and continue to promote it to this day. However, ISPs generally do not block mail from senders only because they don't utilize double opt-in. What do they know that Fiveten doesn't know?

It's perfectly acceptable to create and publish a blacklist that operates on specific, arbitrary criteria. Blacklist operators clearly have the right to block any email, or any sender, even if only because their email messages might contain the letter “T” or the number “7.” Blacklists are opinions, and I support a blacklist publisher's right to define whatever listing criteria they feel appropriate. But, how does arbitrary relate to accuracy? What if there was a blacklist that listed any IP address containing the number 7? I'm in a good position to test exactly how well a blacklist like that might work. Since March, over 1.6 million email messages (a combination of spam and non-spam) have crossed my tracking mechanism, and I've saved the IP address (and other data) for each. So, it's actually pretty easy for me comb through that data and measure the effectiveness of this type of hypothetical, clearly arbitrary (and some would add, silly) blacklist.

After a few minutes of coding and data compilation, here's what I've come up with: The “Luckyseven” blacklist. As the name suggests, any mail server “lucky” enough to have an IP address containing the number 7 is listed. When comparing Luckyseven to Fiveten, it is approximately 10% more accurate against spam (50% vs. 40%), and slightly less inaccurate against non-spam (43% vs 44%).

I think this exercise suggests that arbitrary listing criteria not based on direct correlation to spam can result in a blacklist that doesn't target spam accurately or successfully.

Any ISP who uses this list is going to block a lot of mail that their users actually desire to receive. As just a sampling, using Fiveten means rejecting various email messages from Microsoft, multiple public radio newsletters (from different radio stations in different states), travel notifications and newsletters from Expedia and Hotwire, lots of other newsletters and news updates from various newspapers and TV shows, and even the newsletter from my favorite pizza place back in my home town of Minneapolis.

Could any of these senders have list management issues? Could any of them be spammers, or be engaging in bad acts warranting blacklisting? Potentially, yes. I know nothing about the practices of any of these entities listed. But, I do know that even the “good guys” can go off the rails once in a while and end up on a blacklist. But it seems unlikely that this is the case with all of them. To me, this is further indication that Fiveten is unsuitable for use as a spam blocking mechanism.

For the most up-to-date Fiveten accuracy data available from DNSBL Resource, visit the Fivten data page at the Blacklist Statistics Center.

(Please note: The Luckyseven list is fake; an exercise; do not use it for spam filtering.)