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.)