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.
Host blacklisted - Found on Realtime Black List server blocklist.address.is.wrong.spamhaus.org
Please take a moment to check out the new DNSBL Resource Blacklist Statistics Center. Replacing the old DNSBL stats page, this new section of DNSBL Resource provides week-by-week graphs for twenty different blacklists. At a glance, one can easily see the accuracy rates and false positive rates for the past thirteen weeks for any blacklist in the system. This data will be refreshed weekly, automatically, and new blacklists can be added easily.
Please don't hesitate to drop me a line with your feedback on this new functionality.
In the future, look for a more detailed index page for the statistics center, one that will show information on mail-in-progress.
Additionally, work is under way to add “second stage” filtering and URIBL-style blacklists to the statistics center. Stay tuned!
Previous updates follow.
APEWS, the "anonymous" blacklist meant to be an early warning system for spam, generates a lot of worry from administrators and end users who find themselves listed by way of plugging their IP address into an online lookup tools like DNSStuff. Though it doesn't result in much (if any) of anyone's mail being rejected, as it's not widely used, some people still think they're being labeled a spammer, and don't know what to do about it.
Note: This isn’t guidance on how to avoid a blacklisting or sidestep anti-spam groups. If you have a spam issue, fix it. Don't spam, ever, for any reason. This is information is regarding how to address an issue with a blacklist that is very aggressive at listing non-abusing IP addresses and networks, with no published, attainable path to resolution.
APEWS, the Anonymous Postmasters Early Warning System, is an “anonymous” blacklist that claims to run in the style of SPEWS. That is to say, its goal is to be an “early warning system,” catching and stopping spam before other blacklists or filters have the opportunity to do so.
The APEWS blacklist was first announced by way of an anonymous posting to the newsgroup news.admin.net-abuse.blocklisting on January 12, 2007. Though this newsgroup post originated from the IP address 22.214.171.124 (registered to US provider PSI/Cogent), the blacklist is widely believed to be run from Germany.
If you are listed on APEWS and wondering what to do, visit this page for my suggestions.
A quick review of the past thirteen weeks of my own stats.dnsbl.com data shows that the list has been ramping up in aggressiveness the entire time that I've been tracking it. What was barely a 20% effectiveness rate against spam eleven weeks ago is up to 80+ percent on a week-by-week basis. However, false positives have risen similarly.
The rising spam match rate is based on what I would characterize as the “stopped clock is right twice a day” principle. Blacklist enough IP addresses, and eventually you're going to stop some spam. The side effect is that you're going to block legitimate mail (and lots of it) at the same time. Against my personal hamtrap data, APEWS blocks two out of ten of every legitimate piece of newsletter or list mail that I've signed up for.
I'm not kidding about "listing enough IP addresses," either. As of today (August 11, 2007), APEWS lists just about 1.8 billion IP addresses - by the raw numbers alone, this is 42% of the entire IP4 networking space. Much of the IP space listed isn't even routable; suggesting little attention is being paid to what IP addresses are actually able to transmit traffic (email or otherwise). Also, APEWS has been growing at a very fast rate. From July 20th through today, they have added an additional 7.5 million IP addresses. These are data points that, in my opinion, suggest that the list is bloated, questionably targeted, and inaccurate.
09/30/2007 update: Click here to read about how I can similarly block around 60% of spam just by arbitrarily listing 42% of the internet.
Based on this data, and the recommendations of other trusted blacklist operators and anti-abuse folks, I personally would not use APEWS to filter incoming mail.
Controversy and Commentary
The blacklist is considered controversial by many other blacklist operators, ISP abuse staff, and anti-spam advocates.
Matthew Sullivan, SORBS maintainer, indicates that as of August 9, 2007, SORBS will no longer be publishing the APEWS blacklist zones via DNS.
Claus V. Wolfhausen, maintainer of UCEPROTECT, another German-run blacklist, indicates that UCEPROTECT will no longer publish the APEWS blacklist zones. (Previously: Claus warned that unless APEWS were to make immediate, significant changes to its policies, UCEPROTECT will no longer publish the APEWS blacklist zones.)
Suresh Ramasubramanian, respected anti-abuse manager for large mailbox provider Outblaze, categorizes APEWS as “meant to be used by fools.”
- Kevin Liston and others from the Internet Storm Center have indicated that APEWS is using the ISC "top source" data to support blacklist entries, in violation of the data's license, and against the wishes of those who provide this data. ISC says that the data "is not supposed to be used as a blocklist as it is bound to include false positives" and that "APEWS may be a useful 'anti-spam" list if you do not mind losing a lot of valid e-mail as well."
Misplaced Newsgroup Discussion
If you read either of the two popular anti-spam newsgroups (news.admin.net-abuse.blocklisting and news.admin.net-abuse.email), you already know that both groups are often overrun with requests (example) from people who find that they are blacklisted by APEWS. I find over 2,000 messages on these groups relating to APEWS remove requests, which is a high number considering that the blacklist is less than a year old.
The blacklist group is run “anonymously.” Question 41 of the APEWS FAQ asks how one contacts APEWS. The answer includes the following: One does not. APEWS does not accept removal request by email, fax, voicemail or letters.” [...] “General blocklist related issues can be discussed in the public forums mentioned above. The newsgroups news.admin.net-abuse.blocklisting (NANABL) and news.admin.net-abuse.email (NANAE) are good choices.
This is likely why many administrators post to these newsgroups, asking for assistance, when finding their IP addresses are listed. The FAQ does warn that “abusing these newsgroups & lists by posting removal request you will make a fool of yourself,” but that doesn't seem to be a deterrent. I would theorize that this is because a lot of the people on the wrong side of listings do not understand why they are listed and do not now how to “fix” whatever issue led to the listing, as the listings are often broad and vague.
Vincent Schönau, an ISP abuse adminstrator, has related his APEWS experiences to me in email, and given me permission to share them here.
Other blacklists have employed the 'escalations' strategy in the past, but APEWS has taken it to a whole new level; a few spams from a providers ip ranges will cause all or most of the providers ip space to be listed in APEWS, with comments such as 'unprofessional / negligent provider'. What this means is that if your provider is a noticeable source of e-mail, sooner or later, it's going to get listed.
Several providers of 'blacklist checks','blacklist comparisons', 'e-mail reputation checks' and include APEWS data. Apparently this is causing systems administrators who are desperate to reduce the amount of spam they're receiving to think that using it might work - perhaps because not all of those sources include the data on false positives for the blacklists.
In practice, this means that several times a week, I'm spending time explaining to my users how they should work around the e-mail delivery-problems they're seeing which may or may not be related to APEWS. I could be spending this time taking action against compromised hosts in our network instead. This hurts providers who do take action against the abuse from their network more than providers who didn't care in the first place.
Others have related similar stories to me, of how long after spammers were booted, that a listing still persists. In one instance, a provider had a compromised machine, which was identified and disconnected within two hours of sending spam. Three days later APEWS listed it, and six weeks later, the listing persists, even though the issue is long since addressed.
If you are listed on APEWS and wondering what to do, visit this page for my suggestions.
The blacklist SORBS (aka the “Spam and Open Relay Blocking System”) was created in 2002 by Australian Matthew Sullivan. SORBS publishes a main “aggregate zone” (dnsbl.sorbs.net) containing listings meeting a multitude of criteria beyond open relaying mail services. SORBS also publishes multiple other zones meeting various criteria.
As related previously, SORBS appears to be undergoing changes. Some of these changes appear to relate to the fact that the SORBS maintainer has repeatedly taken issue with the methodology used by DNSBL.com to measure accuracy rates and false positive rates.
SORBS has indicated that they have the ability to feed false or different data in response to queries from DNSBL.com. As such, it's unclear if recent query results are indicative of results seen by other users. Because of concerns that SORBS may be attempting to sway the data reported, it's important to share current data and information, so that system administrators can make an educated determination as to whether or not it would be wise to use this DNSBL.
I've been tracking data on the main SORBS zone, dnsbl.sorbs.net, since March, 2007. Here's what I've found.
For most of the past fifteen weeks, the DNSBL had an effectiveness rate varying between fifty percent and fifty six percent, week over week. This means that SORBS correctly blocked a piece of spam in my spamtrap about five to six times out of ten.
For many weeks, I believe SORBS clearly suffered from significant false positive issues. As measured by my own calculations (see here and here for more info), the false positive rate is in the 7.9% - 11.1% range. This means that if your users sign up for the same kind of mail that I did, that for every one hundred pieces of solicited mail your users signed up for and expected to receive, SORBS is likely to block seven to twelve of them.
Recent Data Changes
On July 9, 2007, changes were made to SORBS. As you can see from the chart above, around this time (near the start of week 12), the net result is that the effectiveness rate and false positive rates have both significantly declined.
Since July 9, 2007, I have not noted any additional false positive from the main SORBS zone. Because of indication from SORBS that they are able to feed false data, it is unclear if the results I am seeing are accurate.
Similarly, the effectiveness rate of the main SORBS zone seems to have greatly declined as well. Since July 9, 2007, it is hovering in the 18% range.
There are two possible conclusions to make here:
SORBS is somehow able to feed different blacklist data to DNSBL.com than to others. If so, then the historical data I have summarized above is likely to be the most accurate view of SORBS. Or,
SORBS has gutted its lists and the poor effectiveness rates I'm now seeing are reflective of how it would likely work for others.
It's hard to say which scenario is the more accurate one, and what future testing will reveal. I'll certainly continue to collect data, but right now, there's an open question of SORBS' effectiveness and false positives.
As of Thursday, July 19, 2007, SORBS changed the default zone mentioned in configuration guidance pages from dnsbl.sorbs.net to a domain not owned by SORBS. As a result, if any SORBS user copies and pastes a configuration snippet from one of the SORBS configuration pages verbatim, the result is that 100% of a site's inbound email will be blocked. My recommendation is to proceed with caution – if you are not sure what you're doing with DNSBL use and mail server configuration, a misstep here will have significant consequences.
SORBS has leveled the following criticism, assumably as justification for for the results published on DNSBL.com. Below is an overview and response to the points raised:
SORBS claims that the DNSBL.com email feed data is US-centric. This is true. The domains involved in these hamtraps and spamtraps are "dot com " domains, and have always been hosted in the US. If this means that SORBS is inaccurate as a result, it suggests that SORBS is Australia-centric, and likely will not work as well for those in other countries.
SORBS claims that a false positive as defined on DNSBL.com is not what everyone calls a false positive. This is true. I consider a false positive to be a requested message that was blocked. Others have different definitions. I believe the definition used on DNSBL.com to be accurate. I further believe that the most common definition of a false positive as used by regular end users or system administrators is most likely to align with my own.
SORBS is unable to verify false positive hits, as DNSBL.com does not provide IP addresses correlating to false positive hits. This is true. If data were provided to any blacklist operator regarding false positives, this would enable the DNSBL to whitewash over the issues by removing the IP addresses reported (and no others). This is similar to why blacklist groups do not provide spamtrap information – they do not want their spamtraps “compromised,” which would allow a bad sender to simply stop sending to spamtraps, but continue spamming elsewhere. Therefore, this information is not provided to any blacklist. (Other list operators have been more understanding.)
SORBS claims that the zone “dnsbl.sorbs.net” being queried by DNSBL.com is not the zone used by most users or recommended by SORBS as the main or default zone. This is untrue. It has or had clearly been positioned as the default zone or default recommended configuration choice, and remains the zone first listed, positioned as the “aggregate zone” as of July 20, 2007.
SORBS claims that Spamhaus volunteers have (or had) access to the SORBS database and have entered listings in the past to drive significant false positive issues. I am not associated with either SORBS or Spamhaus so I can't speak to this accusation.
- SORBS claims that the methodology of checking mail against DNSBLs within 15 minutes of receipt is inaccurate. This is untrue. Anyone who uses a DNSBL is enabling their mail server or spam filter to check the mail against the DNSBL within seconds to minutes of receipt. If, as SORBS states, their DNSBL distribution model is such that it suffers from this methodology, then it suggests that it may be slow to respond to real spam trends.
(10/29/2007 update: At a recent conference, over a beer with a colleague who builds tools to block spam for a living, I was gently chided over this bit of methodology. I was told that I was letting mail get far too old. 15 minutes is a hundred years as far as spam vector measurement is concerned; the vendor in question uses a 60 second interval at maximum. By this logic, I was being too forgiving as far as slowly updating anti-spam blacklists were concerned. This is further at odds with the criticism from SORBS.)
- SORBS has picked a specific sender as the source for the SORBS false positive rates I report, saying that this sender is a "habitual source of spam." I have no financial interest or any other connection to the sender in question, except that I ordered pillows from them in December, 2006, and was happy with the product and service they provided. As a result, I signed up to receive mail from them, and happily do so. If I used SORBS to reject mail, that mail would not reach me. Additionally, this sender is far from the only source of false positives I found when utilizing the SORBS blacklist.
(11/09/2007 update: The specific sender is/was Overstock.com. SORBS categorizes Overstock as a spammer. Matthew Sullivan (now known as Michelle Sullivan), in fact, indicated that "1000's of people who receive unsolicited commercial/bulk email from them." There are two additional problems with his characterizations here.
First, Overstock.com is not listed on ANY OTHER of the approximately 47 blacklists I check, except FIVETEN (which lists many hundreds of potentially legitimate senders, and therefore, is not very useful as a second opinion here.) It's not on any of the lists that commonly do list supposedly-legitimate senders who may have run afoul of spamtraps.
Second, the last mail I had received from Overstock.com was on May 25, 2007. This is significantly before the July 9th cutoff of my data, and measured false positives were on the rise even with no further mail from Overstock.com in the data set. Incidentally, I have no idea why I've received no mail since. I didn't unsubscribe.)
Additionally, SORBS has made numerous statements questioning the accuracy of data published here, and characterizing this project as something other than honest and transparent. Here's how it works: I have a feed of mail, and I check all mail received for DNSBL hits. I give internet users a live, rolling snapshot of how various lists intersect with my mail steams. That's all there is to it. I leave it to you, the reader, to decide if I've been honest and clear at every step of this process, and as always, I welcome your feedback.
(11/18/2007 Update: Added the phrase "that if your users sign up for the same kind of mail that I did" above to clarify false positive comments.)
The real problem was for potential SORBS users – if they followed the instructions verbatim, they ended up rejecting 100% of your inbound mail. Sadly, I've seen traffic, which implies that this has happened to some degree.
If you're going to use the SORBS blacklist, be very careful to make sure you've implemented it correctly. Both this, and SORBS' claim that dnsbl.sorbs.net is an unsafe zone to use, suggest that the SORBS' list may not be a wise starting point for those looking to simply, safely block spam.
More information on SORBS can be found here.
There has never been a blacklist with a zone name of dnsbl.radparker.com -- and if you type that into the DNSBL section of your mail server config, you will break your inability to receive inbound mail.
Newsgroup participant Ian Manners reports that SORBS maintainer Matthew Sullivan posted about this to the SORBS-Announce mailing list:
Some of you have noticed that the DUHL (dul.dnsbl.sorbs.net) and Spam (*.spam.dnsbl.sorbs.net) zones are empty on the Rsync and DNS server. This is quite deliberate and I apologise for not posting a message about it previously.
Ian goes on to explain that he believes Matthew is "taking a break due to emotional and SORBS stress and has emptied those databases that need his constant attention."
From review of the data I track on SORBS main DNSBL zone (dnsbl.sorbs.net), it's clear that changes started taking place on July 9th. Since then, the false positive rate as dropped to zero, and the effectiveness rate has also plummeted (from around 47% percent effectiveness on recent 7 day averages, down to 14-19% effectiveness on recent daily averages). Based on the fact that dnsbl.sorbs.net is a combined zone, I would suspect that this is in line with the SORBS maintainer removing the significant amounts of data provided by the "spam" and "DUHL" zones.
Over the past thirteen weeks, my measured effectiveness of the main SORBS zone had been on a slight, but steady, decline. From 56% effective in March, to 47% effective for the week before the data changes took place. False positives (measured against the solicited mail I sign up for, of course), varied slightly but generally were around 9% week over week.
I've been reading all I can on the topic of SORBS lately (and engaging in occasionally-heated discussions with Matthew, learning more on how he runs things), with the intent of writing a more detailed review. I'm not quite ready to do that yet, and these changes suggest that I should wait and see what happens, first. Stay tuned for more on this topic in the future.
Whatever your opinion of UCEPROTECT, hold on to your hat, as things are apparently about to change.This posting to the USENET newsgroup news.admin.net-abuse.email indicates that Johann Steigenberger is no longer involved with UCEPROTECT. Going forward, Claus v. Wolfhausen has indicated that he is charge of the lists.
At first there was some concern that this post wasn’t true, that it was a deception. I’ve spoken to Claus via email, and that, along with other information, leads me to believe that this is in fact true and correct. (I’ve met neither individual in person, so I suppose this could be a giant hoax, but I’ve got no reason to believe so at this time.)
Claus indicates that UCEPROTECT will no longer list for backscatter and sender verification callouts. These two listing criteria were controversial and I am told that they resulted in numerous complaints of false positives relating to UCEPROTECT. These data relating to listings based on these criteria are being repurposed into a new blacklist at www.backscatterer.org.
He went on to say due to his intervention, UCEPROTECT has ceased publishing the controversial “anonymous” APEWS blacklist data, and that he is unsure if UCEPROTECT will again publish the APEWS data in the future.
APEWS, an “anonymous” list widely thought to be created as a replacement for the defunct SPEWS, has been regularly criticized by respected anti-spam advocates such as Steve Linford of Spamhaus and Suresh Ramasubramanian of ISP Outblaze. Controversy includes listing policies considered to be broad and inaccurate, and contact/removal policies perceived as cruel to listees (by deflecting all contact away from the blacklist and toward public discussion forums where listees are often subject to abuse from unrelated parties).
I have yet to write and post reviews of UCEPROTECT or APEWS for dnsbl.com. Look for this in the future.
August 17, 2009 update: A reader was kind enough to let me know that the TQMCUBE blacklist is now officially dead and gone. The TQMCUBE website now redirects to the website of another blacklist 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 blacklist 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 blacklist 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 blacklist.
November 25, 2007 update: Within the past week, a large number of entries have been removed from the TQMCUBE blacklist 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.
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 blacklist, please feel free to contact me.
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 blacklists.
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.
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 blacklists 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 blacklisted 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 blacklisting 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 blacklist, because things have changed.
After a lot of measuring and discussion, I’m here to tell you: Spamcop’s blacklist 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 blacklist tracking project. I started that back on March 10th. Ever since then I’ve been compiling data on Spamcop blacklist matches against both spam and non-spam. Here’s what I see:
| || || || || |
~ 74 days
| || || |
| || || |
| || || |
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 blacklist 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 BL: A blacklist 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
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.
- Wikipedia's page on ORBS.
- Thread from the newsgroup nz.comp that discusses the shutdown and contains opinions regarding ORBS' listing policies.
- Here's an overview of legal action against Alan Brown, I believe around the same times as ORBS was imploding. Apparently he was sued for defamation over this newsgroup post, and lost. (More commentary on that here, from someone else involved, writing about it a couple of years after the fact.)
- This Register article talks about the legal action against Alan Brown and ORBS regarding Alan's blacklisting of Xtra and Actrix. Courts found that they were falsely listed on the ORBS blacklist.
- An Actrix rep points out that the reason they were listed is due to getting sucked into the disagreement between Alan Brown and Domainz Followups from others indicate that the Actrix IP address was listed as an open relay input. According to Actrix, it was not an open relay.
- Some newsgroup commentary regarding the defamation suit and ORBS listing policies.
- Tom Betz posts Alan Brown's statement to SPAM-L encouraging the blocking of Telecom NZ and indicating that he's no longer in New Zealand.
- Here's an interesting article about ORBS and the controversy surrounding its practices, from Salon.com.
This list aims to allow you to whitelist or blacklist mail from specific countries, or from certain routers (by AS number).
For example, if you wish to block all mail from the
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.
Looking for a blacklist that helped you block mail from people who send mail to lists of people who have unsubscribed? Well, that’s what Lashback’s Unsubscribe Blacklist (UBL) does.
To find out how it works, I went straight to the source. Here’s how Brandon Phillips, Lashback’s CEO, described it to me during a recent email exchange: “LashBack continually places seed/probe email addresses on every suppression file we discover (300k+ so far). We do this so we can monitor to see when email addresses (consumer unsubscribe requests) are harvested from those files and start receiving email. This is one of many internal checks our systems perform in an effort to establish "Trust" with an advertiser/sender.
“We know that if those uniquely identifiable probes start receiving email it's because a specific unsubscribe request has been misused. The IP address of the sender who's sending to that probe then ends up on our UBL.”
Lashback’s in a unique position to help identify and track bad guys who misuse unsubscribe requests. Here’s how they can do that.
First, they provide a service called Unsub Monitor. If you’re a list manager, this helps to notify you if your unsubscribe processing system ever breaks. All modern list management systems are a combination of code and data, and like anything else, where code and data intersect, bugs and crashes can follow. It’s great tool to help you, as a list manager, make sure you’re not breaking the law. (As the Yesmail/FTC case showed, people with the power to fine you are indeed watching to ensure that people, once unsubscribed, stay unsubscribed.)
In addition to that, they offer the Lashback Toolbar for end user. This is an Outlook plug-in that gives email users a standardized unsubscribe link for emails. It links back to a specific unsubscribe process for a specific list, and Lashback is able to track which ones work, and which ones don’t. This enables them to be able to tellwhen somebody continues to send email to a user even after that user has unsubscribed. Bad senders who abuse their unsubscribe list by sending mail to it can then end up on the UBL.
They obviously haven’t listed every bad actor in the whole world, but the fact that they are tracking 130,000 bad senders in the UBL currently (as of March 29) suggests that they mean business.
If you want to use their blacklist on your own system, the DNSBL zone is ubl.unsubscore.com. You can also download a text or XML file of the listed IPs for use in other spam filtering applications. See their UBL Resources page for more information.
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 blacklist works well or doesn't work well -- I've been burned a number of times by people listing stuff on a blacklist 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 blacklists. I wrote software to ensure that the message is checked within a few minutes of receipt, a necessary step to gather accurate blacklist “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 blacklist, and some others...aren't. Spamhaus’s “ZEN” blacklist correctly tagged about two-thirds of my spam, and tagged no desired mail incorrectly. Fairly impressive, especially when compared to some other blacklists. 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 blacklist. 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 blacklist 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 blacklist 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.
Want to see for yourself? I'm posting summary data daily, automatically, over on stats.dnsbl.com.
The second chart provides a day-by-day breakdown of this data.
For example, on March 10, 2007, the Spamhaus blacklist correctly tagged 71% of spam received, and incorrectly tagged no non-spam mail. The Fiveten blacklist correctly tagged 66% of the spam, but incorrectly reported one third of the non-spam mail as spam. The determination I make from this data is that Spamhaus blocks more spam than Fiveten, and does it more accurately. If I used the Fiveten list, I would block much desired mail. With Spamhaus, no desired mail would have been blocked on that day.
Note that not everyone is going to agree with my classification of false positives, and that's fine. In my determination, a false positive is a piece of mail that I signed up for that would've been blocked by a given blacklist. I think that's accurate. You will find, though, that some blacklists list things that I would not consider spam. For example, some lists will block mail from any sender who is not 100% confirmed opt-in (aka double opt-in). Since very few senders are fully 100% confirmed opt-in, lists such as these inherently block mail from many senders. A list operated in this fashion would have a vastly different interpretation of what constitutes a false positive than I would. It would be within their charter to list and facilitate the blocking of mail from sites like this, even if they haven't sent spam. This wouldn't be considered a false positive by such a list, but would potentially be considered a false positive by me.
Click here for information on what and how I determine to be spam and not spam.
Updated: November 10, 2007.
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 this data 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 mailstreams 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.
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.)
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 blacklist 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.
Until then, feel free to bop on over to Spam Resource, where I talk about my experience using the Spamhaus ZEN blacklist 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.
There's a common misconception in the spam filtering world (and the sending world) -- people think DCC is a spam blacklist. 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.
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 blacklist, 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 blacklisted 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.
The “Blars” DNSBL (block.blars.org) appears to have gone on walkabout.
Created in 2002, the “Blars Block List” was an aggressive, semi-private blacklist run by a gentleman known to the greater internet community only by the pseudonym of “Blars.”
The "BlarsBL" had a broad criteria for listing. This included spam sending domains, open relays, sites with disagreeable spam reporting policies, sites lacking abuse addresses, those who host spammer dropboxes or websites, those who have threatened Blars or others with legal action, and sites originating break-in attempts and other exploits (open proxy, open relay, etc.).
The blacklist has been critizied for implying that payment was required for removal. From the site: "If you would like a site be added or removed from BlarsBL, you may hire Blars at his normal consulting rates (currently $250/hour, 2 hour minimum, $1000 deposit due in advance for non-established customers) to investigate your evidence about the site. If it is found that the entry was a mistake, no charge will be made and the entire deposit will be refunded."
Note: I confirmed today that all lookups against block.blars.org DSNBL will result in a match. This is the “Osirusoft solution,” also known as “blacklisting the whole world.” Intentional or not, this means that if you continue to use this blacklist, you will receive no incoming mail whatsoever.
If you are using this list to reject mail, I recommend you cease doing so immediately. It will block all of your inbound mail.
See this page at MXToolbox.com further confirmation of BLARS mysterious disappearance. This post from the newsgroup news.admin.net-abuse.email indicates that it has likely been out of operation since approximately December 18, 2006.
Created by Thomas Jensen in 2001, the Open Relay Database (ORDB) was one of the multitude of open relay spam blacklists to come about in the wake of the legal troubles of Alan Brown and his New Zealand-based ORBS blacklist.
The ORDB service ceased operation on December 18, 2006. The website was retired on December 31, 2006.
The website indicated that blocking open relays is no longer as effective as it once was.
"It's been a case of a long goodbye as very little work has gone into maintaining ORDB for a while. Our volunteer staff has been pre-occupied with other aspects of their lives. In addition, the general consensus within the team is that open relay RBLs are no longer the most effective way of preventing spam from entering your network as spammers have changed tactics in recent years, as have the anti-spam community.”
If you have checks against relays.ordb.org configured in your mail server or spam filtering software, please stop querying the list immediately. Use of the list will no longer block any unwanted spam, and the nameservers listed in the domain registration are likely overwhelmed with traffic. This is especially heightened due to the fact that the list was in wide, popular use, and also that it was so recently retired.
3/26/08 Update: ORDB has "listed the entire world" -- returning any query with a "listed" response. The result is that if you still have ORDB in your mail server config files, you're now blocking 100% of your inbound mail. For anyone still trying to "use" ORDB, you're not going to receive any inbound mail until you disable queries to it.
The primary project of the “Blitzed” group is the Blitzed Internet Relay Chat (IRC) network.
They also operated a DNSBL zone called opm.blitzed.org. This was the Blitzed Open Proxy Monitor (OPM). This popular open proxy DNSBL was run in such a way as to not probe a remote server to determine its open proxy status unless the server was implicated in reports of abuse. It did not list open relays.
The Blitzed group seems to have suffered a database or server failure as of May, 2006. This email to the “OPM Announce” mailing list details the situation, and explains that the OPM list would not be resurrected.
The list is not active at this time.
Based on this information, I would recommend that you remove opm.blitzed.org from the list of DNSBLs being checked in your mail server. It will no longer block any spam, and the potential exists for unpredictable results to be returned. Additionally, you'll be generating unnecessary DNS query traffic to the Blitzed network.
The zone relays.visi.com was home to the VISI.com Relay Stop List (RSL). According to the site, “RSL was created by volunteers, VISI.com users who wanted a conservative open relay list to use to assist VISI.com's "nospam" server filters. We are happy to share it with others in the Internet community.”
Hosted by VISI.com, a strong regional internet service provider with thousands of clients, it was positioned as a free alternative to the MAPS RSS relay blocking list. (The MAPS lists were originally free, but were converted to a “paid access only” system in 2001.)
In 2003, the RSL suffered from a hardware failure that resulted in a loss of data, but the system was restored by August.
The RSL website was last known to have been active in 2004. I have it on pretty good authority that since then, the people behind the project have moved on to other things.
The list is not active at this time. It will not block any spam, and I recommend against including it in any DNSBL checks, as it generates unnecessary DNS traffic to VISI.com.