Why I Won't Use SPEWS Brian Clapper, bmc @ clapper . org

Introduction For awhile, the spam blocking rules configured in the clapper.org email server included data from the SPEWS Level 2 blacklist. However, in mid-2002, I removed use of the SPEWS database, because I believe the criteria for inclusion in SPEWS Level 2 is too broad. This document explains why I no longer use SPEWS. (You're free to disagree with my position, of course, and I welcome well-reasoned, polite discourse on the topic. I will not respond to flames, though I will save--and possibly post--them.) Note: In this document, I take issue with SPEWS' Level 2 blacklist. SPEWS provides another blacklist, which it calls "Level 1." According to the SPEWS FAQ (item Q21), the the Level 1 blacklist is much narrower. It may not suffer from the problems I discuss in this document. However, the Level 2 list appears to be the more popular of the two lists. Plus, what SPEWS' most rabid adherents seem to like about SPEWS are precisely those features that are specific to the Level 2 blacklist—and those are the features I don't like, for the reasons discussed in this document. When this document refers to "SPEWS data," it means "SPEWS Level 2 data," unless otherwise qualified. Regarding email blacklists I am not against email blacklists. My mail server still uses other blacklists to screen and reject incoming mail, including a local blacklist I maintain solely for my own use. Blacklists can be a useful tool in the fight against spam. However, when using blacklists, one must balance the aggressiveness of the blacklist against the risk of rejecting legitimate messages (i.e., false positives). False positives are an unfortunate consequence of using any email blacklist; no blacklist is completely free of them. If you block email using a domain or IP blacklist, you run the risk of rejecting mail from a non-spammer. When using a blacklist, your goal should be to eliminate as much spam as possible, while minimizing the number of false positives. Those two goals are often contradictory, so using a blacklist can force you into a delicate balancing act. No one blacklist can meet everyone's needs; different sites have different spam profiles. For instance, if you receive a lot of spam via machines in South Korea, and no legitimate email ever comes to you from that country, it might be perfectly safe for you to block all incoming email from South Korea. That same broad blocking policy is probably inappropriate for an ISP, and it's certainly inappropriate for a company that has customers in South Korea. When using blacklists to control incoming spam, I believe the best approach is to use a local blacklist combined with several narrowly targeted blacklists. The blacklists should: list the smallest possible set of addresses or domains necessary to accomplish the required block have simple criteria and procedures for inclusion in and removal from the blacklist fit well with your site's spam profile It's especially important to be able to tailor and tune your spam blocking rules to maintain an appropriate balance between rejecting spam and rejecting legitimate email. You must be able to tune these rules on a site-by-site basis. Relying solely on someone else's spam-blocking policies is simply a bad idea. The SPEWS Level 1 blacklist appears to meet many of the above criteria. The SPEWS Level 2 blacklist fails to meet any of them. "It's okay if innocent bystanders get caught in the crossfire." When I did use it, SPEWS Level 2 was certainly effective. It managed to block spam that my other spam blocking rules did not catch. However, an SMTP server that uses the SPEWS data to block incoming email may also be blocking a surprising amount of legitimate, non-spam email. The SPEWS FAQ acknowledges this problem: Q16: I'm not a spammer or spam operation... heck I hate spam, but my email is getting bounced by someone using SPEWS, or I can't access a website due to SPEWS based blocking. A16: You maybe part of the rare "inadvertent blocking" that can occur when a spam friendly provider is listed in spews. Your best option is to try and educate your provider or switch to one who is not listed in SPEWS as spam friendly. SPEWS aims to avoid listing any non-spammer or non-spam support areas if possible - we just want to stop spam. However, the FAQ is disingenuous here: It seems that part of the strategy of those who maintain SPEWS and those who use its data is to deliberately cause inadvertent blocking (which SPEWS previously called "collateral damage"). By inconveniencing non-spamming customers of spam-tolerant (or merely slow-to-respond) ISPs, the SPEWS enthusiasts apparently hope to bring economic pressure to bear on those ISPs. See, for instance, this article, posted to the news.admin.net-abuse.email newsgroup; in it, the author states, "it's called 'targeted economic pressure.' Only innocent victims would be collateral damage." The author of that article has conveniently redefined "innocent" to exclude anyone who happens to have an address within a blocked IP range. As it turns out, I don't really have a philosophical problem with that approach, when it's applied by individuals. An individual is free to block access to his email in whatever manner he sees fit. I am free to configure my SMTP server or my mail reader however I choose. It's my computer, after all; I can put up as many "No Trespassing" signs as I wish. But the situation becomes murkier when the entity applying the block is an ISP that has made contractual arrangements with paying customers for email delivery. Many ISPs implement blanket spam-blocking policies without informing their customers of those policies or making any provisions for individual customers to customize the spam-blocking behavior. When those invisible spam-blocking measures include the use of SPEWS, the ISP will often block incoming mail from many non-spammers whose netblocks happen to be listed in SPEWS. As the above news.admin.net-abuse.email shows, some SPEWS adherents rationalize inadvertent blocking by demonizing the victim. A non-spammer caught in the net isn't "innocent," because he is "knowingly" buying service from an ISP that supports, or at least doesn't actively quash, spammers. This news.admin.net-abuse.email article is another good example of that sentiment. In it, the author writes, "How can you claim to be 'collateral damage' when you are paying money to an upstream provider who supports spamming activities on their network? The money you pay them helps put turds in my inbox. So I don't see you as an innocent victim of SPEWS. Instead, I see you as a menace." This logic is roughly equivalent (in concept, though certainly not in scope) to justifying the bombing of innocent cilivians by saying, "It's necessary to bomb such a large target to put an appropriate level of pressure on their government. Besides, they're not really innocent; after all, they chose to live in that country." Another twist on this reasoning can be found in this newsgroup article. The author essentially argues collateral damage is okay, because an affected innocent bystander will either (a) leave the provider (retaining his "innocent" status) or (b) stay, knowing that he is supporting a "bad" ISP, which renders him no longer innocent. This line of reasoning is overly simplistic. Despite what SPEWS fans argue, it's not always possible to determine ahead of time that an ISP hosts—or might, in the future, host—someone the SPEWS maintainers decide is a spammer. It's certainly possible to check out the ISP's Acceptable Use Policy, to determine its stance on spamming; however, it can be difficult to determine how well that ISP enforces that policy. Also, like it or not, it's not always simple or straightforward for people or small businesses to switch ISPs. There are contractual and business issues that may prevent an innocent bystander from switching ISPs. Consider this scenario: Company A establishes a contractual relationship with an apparently responsible ISP and buys (well, rents) a block of IP addresses. Sometime later, the ISP plays host to a spammer and fails to terminate the spammer's relationship quickly enough for the SPEWS maintainers, who add some of the ISP's netblocks to the SPEWS list. Company A's netblocks happen to be in the range of blocked IPs. Because of the large number of organizations subscribing to SPEWS, Company A now finds that a considerable percentage of its outgoing email is blocked. Company A is now faced with the choice of fighting with its ISP (and enduring sporadic blocking of outgoing email while doing so) or switching providers, which has real economic impact. If you think that situation is farfetched, here is one case where it has happened. Halliburton Systems is a small software consulting firm started in 1982 by Steve Halliburton. Halliburton's company was caught in the SPEWS net; with his permission, I've included some excerpts from an email exchange I had with him. Excerpt #1: Our address block is 63.220.34.0/24 and is contained within a larger block allocated originally to Cais Internet, later bought out by Ardent Communications. According to the SPEWS "evidence file" number S1352 the entire block 63.220.32.0-63.220.38.255 has been listed because of their displeasure with Cais' handling of an outfit called "fancypleasure" which seems to be located at 63.220.35.98-100. There is no claim that there has been any problem involving our address block, only that we happen to inhabit the address space originally allocated to Cais. I fail to see that blocking our email has anything to do with their problem either with the "fancypleasure" people or with Cais/Ardent. In their FAQ, SPEWS says, in effect, that our choice is either to spend our time/money/effort fighting with Cais or move to another ISP. ... Moving is not a simple prospect given that we have long-term contracts and have large complex systems that depend on the IP addresses we have used from our block. Aside from contractual penalties that would result from our moving, our contract is at a favorable price compared to current prices because it is older, so our monthly cost would go up considerably. We would also have to spend time and money making the change, operating two connections in parallel during the switch-over period, and so on. Excerpt #2: We have had several cases where our customers have not been able to receive an email service for which they pay us due to ISP filtering using SPEWS. None of these ISPs has made anything other than a token "get lost" response to my complaints. Excerpt #3 (which describes an interesting reversal of the "collateral damage" economic pressure disincentive): ... The problem I have is with large ISPs who filter their users' email, often without telling them. ... I received an email this morning asserting the right of an ISP to do exactly that; this was a case where their customer was paying us to send him some information in an email and he wasn't getting it. The ISPs answer to us was "tough luck". When our customer called and told the ISP he was dropping their service, things changed a bit. It turns out our customer had no idea the ISP was filtering anything, let alone our emails and he was quite annoyed. They now say they can "allow" the customer to receive our emails but he was so angry about this that he is switching anyway. I hope my efforts may have this effect elsewhere; here is irony in action: SPEWS causes those who use it to lose business. The logic SPEWS adherents use to justify this collateral damage is apparently becoming more widespread. See, for instance, some of the following accounts: Magdalena Donea posted a letter to Declan McCullagh's Politech mailing list, describing her own run-in with SPEWS. You can find her letter at http://www.politechbot.com/p-03741.html. Noted Princeton professor and security researcher, Ed Felten, posted a couple of articles to the well-regarded Risks Forum, describing some problems he has had with the popular SpamCop service. The articles are at http://catless.ncl.ac.uk/Risks/22.19.html#subj7 and http://catless.ncl.ac.uk/Risks/22.21.html#subj4. The second article contains responses Felten received from his first article; some of those responses contain the exact same logic SPEWS adherents use. Felten's rebuttals are interesting to read. The Politech mailing list itself has been blocked by SpamCop more than once, an apparent innocent bystander in SpamCop's attempts to apply economic pressure on Declan McCullagh's ISP. To read one of McCullagh's accounts of his travails with SpamCop, check out http://www.politechbot.com/p-04121.html. There are some interesting follow-ups at http://www.politechbot.com/p-04126.html, http://www.politechbot.com/p-04129.html and http://www.politechbot.com/p-04132.html. It can be very difficult to get a netblock removed from SPEWS Once a netblock is in the SPEWS database, it can be difficult and time-consuming to get it removed. SPEWS is not a formal organization; it is comprised of an undisclosed group of people who are surprisingly difficult to contact. There are no direct email contacts for the maintainers of the SPEWS data, and determining the identities of the SPEWS maintainers is a nontrivial task. No one will publicly admit to being one of the SPEWS maintainers. The anonymity of the SPEWS maintainers makes a certain amount of sense, for them. Other blacklists (notably, MAPS) have found themselves in the middle of time-consuming and expensive legal battles in the past. The SPEWS maintainers clearly seek to avoid that particular distraction. However, their anonymity means you cannot contact anyone official if you have a complaint about an item in the SPEWS database. The SPEWS FAQ addresses this issue. It suggests posting a message to the news.admin.net-abuse.email newsgroup; however, it also notes (in more than one place) that doing so may not help. Here's a quote from SPEWS FAQ item A41: Note that posting messages in these newsgroups & lists will not have any effect on SPEWS listings, only the discontinuation of spam and/or spam support will. In other words, it doesn't matter if you're caught in the crossfire. Until your ISP reforms to SPEWS' satisfaction, you're unlikely to get any response (other than, perhaps, verbal abuse) by posting your message to that newsgroup—and posting to the newsgroup is your only hope of getting your netblock delisted. SPEWS disclaims responsibility for its own data The SPEWS position, frequently repeated in the news.admin.net-abuse.email newsgroup, is that SPEWS is just a set of published "opinions." Whether an ISP chooses to agree with those opinions (i.e., use the blocklist) or not is really the ISP's business. The SPEWS maintainers essentially disclaim responsibility for the data they publish. Consider these entries from the SPEWS FAQ: A10: ... SPEWS is a list of areas of the Internet that some people do not wish to communicate with. Think of it as one group's Consumer Reports review of portions of the billions of Internet addresses. These are the ones SPEWS members have a poor opinion of. SPEWS is not anti-commerce and fully supports the USA's First Amendment and other nation's free speech protections. In fact, the USA's Supreme Court agrees with the SPEWS view. The creators of SPEWS are its main users and who it was designed for, if others decide to also use its data, they are exercising their own rights. No one is forced to use SPEWS. A12: ... SPEWS is just an opinion report, used by some to filter Internet traffic, others to read for amusement, it was not created, intended, or used to libel or defame anyone. A17: Unlike other block-lists, SPEWS does not take submissions or nominations. Entries in SPEWS are made by the people who run SPEWS for their own blocking and filtering needs. It is provided to the rest of the Internet as an educational tool, or an opinion to use if anyone wishes. Unfortunately, that argument doesn't really hold water. SPEWS isn't merely "publishing an opinion." The SPEWS maintainers are compiling a database of alleged spammers, a database they know is used by numerous ISPs to block incoming email messages. Every time a SPEWS maintainer puts a netblock into the SPEWS database, he knows that the entry will cause numerous ISPs to block messages from any machine with an address in that netblock. Disclaiming responsibility for the accuracy of the data doesn't absolve the SPEWS maintainer of responsibility for the consequences of adding the entry to the SPEWS database. Above, I mentioned Ed Felten's rebuttal to some SpamCop adherents' arguments. One of those rebuttals addresses this issue: Argument 3: SpamCop is just a clearinghouse for spam complaints and simply routes complaints that could have been sent even in the absence of SpamCop. . . . My response: SpamCop does more than just forward complaints. It anonymizes the complainant's address, thereby making it harder for the ISP receiving the complaint to judge the complaint's credibility. SpamCop puts the complaint on the Web for others to see. And SpamCop tries to find patterns among its complaints, and adds addresses to its block list based on these patterns. All of these factors contributed to my dilemma. If SpamCop were merely a complaint router, then SpamCop would be ineffectual. It is SpamCop's "value added" that caused me trouble. Argument 4: Blame the person who erroneously reported the "spam," don't blame SpamCop. . . . My response: This is really just a variant of Argument 3, and fails for the same reasons. SpamCop is ultimately responsible for its reporting, too. The 911 analogy doesn't apply, since the phone company merely receives the report but SpamCop repeats reports and amplifies them. SpamCop took what would otherwise have been a private report, to be dealt with between the reporter and my ISP, and posted it for the whole world to see. And it gave the report increased credibility and force. (See http://catless.ncl.ac.uk/Risks/22.21.html#subj4 for Felten's complete article.) There's another logical inconsistency in the SPEWS argument. Applying "targeted economic pressure" (in effect, a boycott) only has a chance of working when a large group joins the boycott. The SPEWS maintainers may claim that they only maintain the database for their own use, but if that were true, the stated aim of applying pressure on "offending" ISPs would be a pointless exercise. That kind of pressure only works when a large number of people are using the SPEWS database. In other words, there's no point putting broad netblocks in the database if the database isn't used widely; the SPEWS maintainers rely on the widespread use of the database to apply pressure on ISPs that host spammers. Diminishing Effectiveness? Even if you agree with the SPEWS philosophy, SPEWS seems destined to become less effective, as more and more spammers start using spam networks made of up compromised spam zombie machines. These spammers are no longer renting blocks of IP addresses and using them to send their spam. Instead, they use worms and viruses to compromise machines all over the Internet, and they farm out their spam delivery to those compromised machines. Many of these machines belong to unsuspecting home users who have always-on broadband connections and insufficiently protected computers; they often don't even notice that their machines have been co-opted by some spammers. This nefarious (and illegal) tactic renders SPEWS blocking strategy less useful. Those spammers are delivering their messages from IP addresses all across the Internet, not from easily identified blocks of IP addresses from one or two ISPs. Conclusion The SPEWS Level 2 blacklist is too broadly targeted. Its overly-broad blocking policy significantly raises the risk of false positives; for that reason alone, I cannot justify using it. Worse, the rationalizations for that policy are typically disingenuous and self-serving. I cannot, in good conscience, use a blocklist whose maintainers deliberately raise the risk of false positives, while justifying their actions with what I consider to be suspect reasoning. Sure, I could use the SPEWS Level 1 list, but I so fundamentally disagree with the philosophy behind SPEWS that I don't really feel comfortable using either list. The people who use and love SPEWS love it for its Level 2 blacklist. They don't seem to mind hanging innocent people; in fact, that seems to be one of the attractions of the list. That philosophy just doesn't work for me. I'll stick to more reasonable blacklists, such as MAPS and Spamhaus. Links to Other Relevant Information http://www.somethingawful.com/articles.php?a=1605 An anti-SPEWS article by a staff member of Something Awful, which states, "on July 20th [2003] SPEWS.ORG added a fat chunk of a class b subnet being hosted by our provider (Cogent Communications/New Horizons) to their blocklist. This fat chunk happened to include Something Awful, meaning that roughly 10-20% of our outgoing e-mails would bounce."