Showing posts with label dnsbl. Show all posts
Showing posts with label dnsbl. Show all posts

Which DNSBLs work well?

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

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

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

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

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

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

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

NJABL Dynablock List Now Obsolete

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

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

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

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

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

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

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

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

Spamcop Roundup

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

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

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

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

Spamhaus ZEN: Recommended

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

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

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

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

DCC: Spam filter?

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

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

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

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

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

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

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

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

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

Spamcop BL: A blacklist with a hair trigger

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

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

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

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

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

Status of block.blars.org: DEAD

The “Blars” DNSBL (block.blars.org) appears to have gone on walkabout.

Created in 2002, the “Blars Block List” was an aggressive, semi-private blocking list 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 list has been criticized 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."

The list appears to be no more. The websites www.blars.org and block.blars.org both resolve to a “This domain is parked free with GoDaddy” placeholder page.

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 “listing the whole world.” Intentional or not, this means that if you continue to use this blocking list, 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.

Status of relays.ordb.org: DEAD

Created by Thomas Jensen in 2001, the Open Relay Database (ORDB) was one of the multitude of open relay spam blocking lists to come about in the wake of the legal troubles of Alan Brown and his New Zealand-based ORBS DNSBL.

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.

Status of opm.blitzed.org: DEAD

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.

Status of relays.visi.com: DEAD

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.

Status of relays.radparker.com: DEAD

The DNSBL relays.radparker.com is no longer valid. If you are using relays.radparker.com in a mail server or spam filtering product, please stop doing so immediately. It will not block any spam. No DNSBL has been available under this domain for years, and unexpected results may be returned.

It used to be the home to a list called the Radparker Relay Spam Stopper (RRSS). The RRSS was a list that I myself (Al Iverson) created in early 1999 to help mail server administrators reject mail from open relaying mail servers. Back then, open relays were the primary transmission vector for the worst-of-the-worst kinds of spam. I created the list primarily to offer an alternative to ORBS, an open relay blocking list run by Alan Brown out of New Zealand. (This ORBS was a sort of descendant of a previous ORBS, run in Canada by Alan Hodgson.) Alan (Brown) had a habit of getting into arguments with people who were listed, actively probing mail servers without permission, listing things that didn't actually qualify as an open relays, and so forth. I found it distasteful and unfriendly.

Major policy differences for my new alternative open-relay list included:

  • A remote server was not tested for open relay unless a spam message was received.

  • Public record was kept of the spam message, and test proving the site was an open relay.

  • Anybody could request that any listing be removed, and it would be removed.

The net result was that ORBS ended up imploding under various legal challenges, and the RRSS ended up becoming the Mail Abuse Prevention System (MAPS) RSS, later a component of a commercial spam-filtering solution, provided as of late by MAPS' current owners, Trend Micro.

Throughout the spring and summer of 1999, the RRSS list grew in popularity. At its peak, we figured that it was protecting over 350,000 mailboxes from open relay spam, and was used by quite a few local and regional ISPs, including USWest/Qwest.

I created the list on my own, on my spare time. Back then, it was hosted by my employer, with their permission. This meant that the company would occasionally get a screaming goober phone call from somebody whose mail got blocked, who couldn't figure out how to resolve the issue, and was sure that there was some giant conspiracy in place to harass them. (I probably wasn't as polite to some of those folks as I should have been, either.) Eventually enough of those calls started coming in that I decided it wasn't very wise to continue hosting the RRSS from my office at work. That's when I started talking to MAPS. They offered to host the project for me under the MAPS umbrella, a partnership I entered into somewhere around August or September 1999. Eventually my volunteer work turned into a full time job working for MAPS, where I continued to manage and develop the RSS project, as well as working as an investigator for the MAPS RBL (Realtime Blackhole List) project.

I left MAPS in October, 2000.

The zone relays.radparker.com was emptied out sometime after the project was moved to the MAPS' servers in California. That was back sometime in 1999 or 2000. It's not been used to host a DNSBL since.

Interestingly, the RRSS data, process, and code was my own intellectual property that I brought with me to MAPS, and never had any sort of formal agreement to transfer ownership to them. When I later left, I decided my heart lay elsewhere and I never pursued any sort of plan to take the project back unto myself. My friend Gordon Fecyk, who created what became the MAPS DUL, found himself in a similar situation when he left MAPS in 2002. In his case, he attempt to continue with his DUL project. This resulted in him being sued by MAPS, having been accused of stealing MAPS' own intellectual policy-- a claim I suspect was distorted and probably unfounded, as did others.

MAPS founder Paul Vixie recently posted to a mailing list that the original, long-dead MAPS RBL zone of rbl.maps.vix.com is still receiving may queries against it. This got me to thinking – I did a bit of Google searching myself and found that there are still some people out there wondering if the RRSS zone of relays.radparker.com is working. So, here I am, posting this information, in the hope that the next time somebody's wondering, they'll query Google for more information, and find this page with the definitive answer: Nope, there is no DNSBL to be found at relays.radparker.com.

CBL: Block those exploits!

The Composite Blocking List (CBL) is a DNSBL that helps you block mail from exploited computers. That includes abused open proxy servers, as well as virus and trojan-infected spam spewers, the primary vector for most of the illegal spam people are receiving nowadays. By some counts, there are millions of these computers in the world, and besides spam, they’re also responsible for denial-of-service attacks, virus distribution, phishing, etc.

As the CBL website indicates, the data behind the listings is sourced from very large spamtrap-receiving domains and various email infrastructures. Their intent is to list only IP addresses that exhibit characteristics specific to open proxies, viruses, stealth spamware applications loaded on a computer without the user’s knowledge, etc. They don’t knowingly attempt to block any sort of legitimate mail. And I would characterize “legitimate” very broadly here – legitimate senders like most email service providers (and their clients) should rarely, if ever find their mail blocked by a CBL listing.

Though, on occasion, it does happen. CBL doesn’t ever list good senders intentionally. The problem is that some computers share IP addresses with others, behind a NAT (network address translation) device or firewall. Your legitimate mail could be going out to the internet over an IP address shared with an infected, spam-spewing Windows desktop. It’s fairly rare, but when it does happen, CBL makes it easy for you to address those kinds of issues, by allowing you to remove any entry from the list. This allows you to again send mail to the site that was rejecting it due to the listing. Keep in mind that if they again later see bad traffic coming from that IP, it could get listed again. That means it’s important to figure out what on your network is infected or spewing, and fix it.

I recommend use of the CBL (or one of the other lists that includes the CBL data) to filter or reject inbound mail. It helps to block some of the worst types of illegal spam out there, and the risk of blocking legitimate mail is very low.

The CBL listing data is integrated into the Spamhaus XBL (and is therefore also part of Spamhaus ZEN). If you use either of these Spamhaus DNSBLs to tag, filter or reject inbound mail, then there’s no need to utilize the CBL as well – you’re already doing so.

Status of rbl.maps.vix.com: INVALID DOMAIN

In January 2007, MAPS (Mail Abuse Prevention System) co-founder Paul Vixie noted on the NANOG mailing list that he continues to receive significant traffic from sites attempting to query the “rbl.maps.vix.com” blocking list.

The DNS zone “rbl.maps.vix.com” was the original zone for the MAPS Realtime Blackhole List (RBL), the first widely-used anti-spam DNSBL. The zone has long since been replaced with another, named blackholes.mail-abuse.org.

The queries against rbl.maps.vix.com will never return anything valid. It’s my understanding that you currently would get no response, and it will block no more mail. You risk eventually blocking wanted mail, if Vixie later decides to implement a wildcard listing strategy, to force sites to stop using his list. (This would make all inbound mail to any site using the list bounce.)

If you currently have rbl.maps.vix.com on the list of DNSBLs you are querying, please remove it. As indicated above, there is currently no spam-blocking value, and there is potential for future risk.

It appears that RBLSMTPD, a tool to allow sites to utilize DNSBLs to block mail, widely utilized in conjunction with qmail, will default to querying rbl.maps.vix.com. If you use RBLSMTPD, please review your configuration to ensure that you’re not contributing to this problem.

If you are attempting to use the MAPS RBL, please do not simply change over to the blackholes.mail-abuse.org zone. The MAPS services are not free, and are blocked from unregistered access. Please see the MAPS website for more information.

If you’re looking for a free, reputable blocking list suite to try, my recommendation would be to consider Spamhaus’s ZEN combined list. I plan to post an article about them very soon, and I’ll link to that from here, after it’s posted.

It's very unlikely that you would see a bounced email message making reference to rbl.maps.vix.com. If you do see such a bounce, it is likely in error. Contact the site (from another email account or via telephone call) and point them toward this site for further information.

Status of lbl.lagengymnastik.dk: DEAD

The DNSBL lbl.lagengymnastik.dk is no longer active. It ceased operation back in 2003 or 2004.

In January 2007, Henrik, the operator of this DNSBL, indicated that his bandwidth is still being greatly consumed by DNS queries against his list. Because of this, he has implemented a “wildcard listing strategy” to force sites to stop using the list.

In a wildcard listing strategy, a DNSBL lists all IP addresses in the world. That means that anybody using this list will no longer be able to receive any mail at all. This controversial “last resort” is done as a wake-up call for sites using the list. Suddenly they stop receiving all inbound mail, and hopefully they soon realize what’s going on and resolve it.

If you find your mail bouncing with a reference to the lbl.lagengymnastik.dk list, contact the site that blocked your mail. I assume you’ll have to do that via telephone, since mail to them will not go through. Inform them that the list is no longer around. Direct them to this site or recommend they do a Google search to learn more.

For more information, visit the LBL website, and this posting to the usenet newsgroup news.admin.net-abuse.blocklisting. (Note that “the Osirusoft solution” refers to a wildcard listing strategy.)

What is a DNSBL?

A DNSBL is a DNS (domain name service)-based spam blocking list. Some people call them blacklists, while others call them blocklists.

They are most often IP address-based. This means that they contain IP addresses, generally of email servers that you might receive spam from, or that the list maintainer has indeed received spam from. There are dozens of such lists available, all compiled with different criteria, at every conceivable point in the sanity spectrum. Some lists work better than others, and some list maintainers are more trustworthy and respectable than others.

The original (and still primary) use for DNSBLs is to block mail. Most mail servers nowadays have DNSBL support (either built in, or through use of a plug-in) that allows a mail server administrator to block mail from sites listed on a specific DNSBL. The site would choose to do this as part of their attempt to reduce the amount of spam their users would receive.

More recently, DNSBLs are often used as a part of spam scoring system, such as SpamAssassin. If you’re listed on a spam blocklist that is referenced in a spam scoring system, your spam score could be increased by some amount. (The amount varies and is often configurable.) If that, in addition to other scoring tests performed, makes an email’s score rise above a certain level, it could be discarded, or routed to the spam folder.

Note: you might hear people refer to “RBLs” when talking about spam blocking. The first DNSBL was called the RBL, created by a company I once worked for, the Mail Abuse Prevention System (MAPS). MAPS claims “RBL” as a service mark, but as far as I can tell, anybody using the term RBL is usually using it interchangeably with DNSBL.

How to confirm the current status of SPEWS

I figured it would be helpful if people were able to check my work. If you’d like to confirm for yourself whether or not SPEWS has been updated recently, here’s a couple different ways you could do that.

Go to this page on the SPEWS site, using the Mozilla Firefox web browser. You’ll get a list of network blocks and IP addresses. Right click on an empty space on the page, and select “View Page Info.” The window that pops up contains a “modified” field. That indicates the last time the SPEWS data was updated.

If you don’t use Firefox, here’s another way you can check. Go to http://web-sniffer.net and paste in this URL: http://www.spews.org/spews_list_level1.txt

Then, hit the submit button. You’ll get a page of output that includes a “last modified” field. This field indicates the last time SPEWS data was updated.

From here you can return to “SPEWS Current Status,” or return to “What to do if you’re listed on SPEWS.”

SPEWS Current Status: DEAD

Please note: I have no involvement in SPEWS. I publish this information simply to be helpful to people I see trying to figure out what to do about a SPEWS listing.

SPEWS is clearly dead/abandoned. SPEWS data has not been updated since Wednesday, August 23, 2006 11:03:29 PM.

This means that the SPEWS data has not changed since August, 2006. This data likely would not be intentionally frozen in time. I am told that the data was generally updated periodically. This probably means that whoever maintains the SPEWS list is unwilling to make updates, or has abandoned this data. I'm not sure -- I don’t know what’s going on behind the scenes. I just know that the data is out of date.

If you'd like to confirm this for yourself, I explain how to do that here.

I confirmed with other smart anti-spam folks to ensure that I am checking this properly, and I’m pretty sure it’s correct.

I will update this page with more information as I have it. Please feel free to contact me if you have any information regarding the SPEWS site or data.

Update as of Thursday, February 1, 2007: Matthew Sullivan of SORBS has emptied out the SPEWS data he was previously serving via his nameservers. Read more >>

If you are listed on SPEWS, don't despair. I've compiled some tips on how to deal with the situation. Click here to read on.

What to do if you're listed on SPEWS

The newsgroup news.admin.net-abuse.blocklisting (NANAB) regularly plays host to blocklist removal requests. Most of those requests seem to be aimed at SPEWS (the Spam Prevention Early Warning System). The SPEWS FAQ says that “general blocklist related issues can be discussed in the public forums” including NANAB. The end result is that lots of folks post to NANAB, asking that their IP address(es) be removed from SPEWS. Those folks get lots of responses, and only some of them are helpful. Because (as of January, 2007) SPEWS seems to have been frozen in time for many months, I’m sharing this information on my site to help affected folks get the facts on what’s going on, and provide suggestions on how to handle the situation.

Note: This isn’t guidance on how to avoid getting listed or sidestep anti-spam groups. This is information regarding how to address an issue with a now-defunct blocklist, where there’s nobody at the group to contact to request delisting.

If you’re listed on the SPEWS blocking list, as confirmed by checking their website, then I’m of the opinion that the following steps are probably what you should take to deal with the issue.

  1. Check the status of SPEWS here. If it’s long out of date, proceed with the steps below. If it’s been updated recently, read the SPEWS website for information on how to proceed.
  2. Assuming that SPEWS has not been updated in months, your next step should be a review your bounce data. Does it contain bounce data that references a SPEWS block?
  3. If no, don’t worry about it. You just determined that you’re not having blocking issues that you can trace back to SPEWS. It’s annoying that you’re listed on the website, but there’s little easy recourse available to you to address that. However, if your bounce data does indicate blocking that you can trace to a SPEWS listing, proceed with the following steps.
  4. If you have a spam issue, resolve it. Just because SPEWS may be gone, doesn’t mean that your spam blocking issues are going to magically going to go away. If SPEWS is listing you, other blocklists or ISPs are probably blocking your mail. Make sure you’re doing everything possible to comply with best practices, and remember that complying with the law just isn’t enough. I realize that this guidance is pretty brief and high level. Reach out to an email service provider (ESP) or email deliverability/reputation consultant for further assistance, as appropriate.
  5. Contact the site bouncing your mail. Show them that SPEWS is out of date and is no longer updating. Feel free to point them at this site. You should be able to demonstrate to them that you do not spam. Be polite. ISPs and companies are perfectly free to block your mail. Attempts to strong-arm a site into accepting your mail are legally and ethically questionable, and will cause far more problems than realize.
  6. Read the bounce to see if you can determine who is serving up the SPEWS blocklist. SPEWS doesn’t publish the data as a blocklist themselves; they leave that to others. As of February 1, 2007, Matthew Sullivan of SORBS has stopped serving the stale SPEWS data. I assume that other sites serve it up as well. If you find that a site is serving up this outdated info from SPEWS, contact them and let them know that the information they’re sharing is out of date. Feel free to point them toward this site. Recommend they follow Matthew's example with regard to nulling out the listings until (if) SPEWS returns.
I hope you find this information helpful. Please feel free to contact me with your comments or feedback. But, please note that I'm unable to consult with you regarding your specific situation -- I've already got a full time day job, and I'm not looking for consulting clients.