Archives for August 2002

Nice article by Charles Mann in the September 2002 issue of the The Atlantic, about Bruce Schneier and his opinions on homeland security. Bruce thinks insightfully about security, and is a great communicator as well. If you’re interested in computer security, Bruce’s CryptoGram newsletter is a must-read.

Bruce says that much of the money and effort being spent on improving homeland security is wasted, going to high-tech systems that fail often and sometimes catastrophically, and to new procedures that have little connection to any real threat. He argues that we should match our defenses carefully to the threat, and that we should rely more on human judgment and less on gee-whiz machines. All of this makes sense.

The article is properly skeptical about biometric identification technologies like fingerprint readers and iris scanning, explaining how many of them can be defeated by low-tech methods. Skepticism is the right response to any new security technology, but for some reason biometrics and the like often get a free pass. Many people know that new technologies are unreliable; yet they seem strangely predisposed to assume that big-brotherish ones will work.

I received 59 responses to my SpamCop narrative. Because there are so many, I cannot respond individually to each one. Instead, I summarize below the major arguments raised by the messages. I give sample text from messages that asserted each argument, and I respond.

This posting is rather long, and some readers may not be interested in the whole thing, but I think the people who sent me constructive messages about the SpamCop incident deserved a response.

Argument 1: Blame the ISP, not SpamCop.

Sample:

“The problem is not with Spamcop, but rather with your ISP. The ISP is required to assert that they have dealt with the issue, not that they have shut the website down. They can mark the issue ‘resolved’ with spamcop and then work with you to discover the true nature of the problem. The choice to shut the web site down now, and investigate later, was your ISP’s, not Spamcop’s. ”

Another sample:

“However, in this case, your ISP is responsible for bouncing your domain, not SpamCop. All SpamCop e-mails come with a link to the original report, so it was _your_ ISP who failed to research this and _your_ ISP who is to blame for suspending your site.”

My response: Certainly my ISP is the party who actually pulled the plug on my site. The ISP was intimidated by SpamCop and seemed to be trying to show that it was responsive to SpamCop complaints. Hence the quick shutoff of my account.

Yet even after I convinced my ISP that I was not a spammer, they still refused to reinstate my site, saying that to do so before SpamCop removed the complaint against me from its site would put the ISP’s other customers at risk. This refusal to reinstate my account is what convinced me that the ISP was afraid of SpamCop.

Whether the ISP was right to fear SpamCop, I cannot say. What I know is that the ISP chose to anger a paying customer, rather than risking what they perceived as the wrath of SpamCop. The fact that SpamCop engenders such fear is a big part of the problem. For me, the bottom line is this: if SpamCop didn’t exist, my site would not have been shut off.

Argument 2: SpamCop doesn’t block sites, ISPs block sites.

Sample:

“SpamCop (http://www.spamcop.net) blocks nothing. SpamCop does have a DNS-based blackhole list that ISPs have the option of using—for example, I use it for all my domains as a backup to my own block list.”

Another sample:

“The spamcop blocklist is supposed to be used in order to tag certain email as possible spam. It is not to be used to block email (although some ISP’s do use it that way).”

Another sample:

“ISPs also use Spamcop, but it is the ISP, not Spamcop, that makes the determination whether something listed by Spamcop is deleted, flagged, or passed through. I happen to delete.”

My response: Nearly everybody who made this argument followed it by saying that they themselves do automatically block sites on the block list, or that many others do. This is hardly surprising. Even a perfect block list would do little good unless people used it to block. The alternative use of shunting aside email from sites on the list, and reading it later, doesn’t do much to address the spam problem. As far as I can see, there are only two sensible things to do with a block list: you can ignore the list, or you can use it to block sites.

That’s why they call it a “block list.” That’s why SpamCop’s site gives instructions for configuring common mail servers to block addresses on the list. SpamCop can hardly be surprised to see ISPs following these instructions and blocking the addresses on what SpamCop itself calls a “block list.”

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.

Sample:

“SpamCop is a machine. It summarizes and reports what human individuals feed it.

Another sample:

“SpamCop is primarily a _reporting_ service which allows a user to easily report email abuse to the appropriate authorities. It has a parser which cracks email header information and figures out the true source of the email (as much as possible) despite forged header information.

This is just the same as manually email[ing] a complaint, but automates the header analysis (which can save a lot of time when the headers are intentionally obfuscated).

A user does not ‘send an accusation to SpamCop’ but uses SpamCop to email a complaint to abuse or postmaster addresses.”

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.

“The SpamCop user, not SpamCop itself, is ultimately responsible for what is sent. Each report has been individually submitted by a user, then individually selected by the user before sending.”

Another sample:

“The ‘mistaken’ reporter of spam violated SpamCop’s terms of service, period. It doesn’t matter if you call 911 to report a fire or a burglary: at the end of the day, individuals are responsible for their reporting, the telephone company is not to be blamed for prank calls to 911.”

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.

Argument 5: The attributes of SpamCop that Felten complained about are necessary to prevent spam, or to prevent retaliation by spammers.

Sample:

“In the absence of anti-spam laws with teeth, technical[ly] shunning ISPs who deliberately harbor spammers is the only alternative to control spam.”

Another sample:

“[SpamCop anonymizes the complainant’s address because] real spammers might take action against a spam reporter, such as using their address as the ‘From’ on a spam run.”

My response: Yes, SpamCop’s designers had good intentions. Yes, effective spam-fighting was their goal. My point is that in their zeal to fight spam, they built a system that overreacts to erroneous or malicious spam reports. I for one would not be willing to accept that kind of collateral damage, even if doing so would completely prevent spam (which it cannot).

Several people said that SpamCop is slower to act against accused parties than some other anti-spam services are. That may well be true. If it is, then the other services are presumably causing even more collateral damage.

Argument 6: Felten really is a spammer.

“[Quoting Felten: ]’Never mind that I had never sent a single e-mail message from the site.’

Reply: Someone did:

Mail for freedom-to-tinker.com is handled by freedom-to-tinker.com (0) 209.51.158.242

http://www.samspade.org/t/dns?a=freedom-to-tinker.com

If you look here, you will see two different headers that came from this IP address, both of which are dated July, 31:

http://spamcop.net/w3m?action=checkblock&ip=209.51.158.242

Those are only examples; there could have been many more spams reported through that address.”

My response: I did not send those messages. The writer apparently believes that if the messages came from “my” IP address, then I must be responsible for them. But it’s not my IP address – it’s shared by many of my ISP’s customers. Perhaps the cited messages came from one of them.

This argument nicely illustrates the problem with SpamCop. By collecting complaints in one place and indexing them, SpamCop facilitates the making of this kind of accusation. And by repeating allegations made by others, SpamCop gives them more credibility than they deserve.

I have gotten plenty of email from SpamCop advocates in response to my previous posts. Due to a work-related deadline, it will take me several days to sort through them and post a response. I hope to have my response up here by the end of Monday.

Freedom to Tinker is hosted by Princeton's Center for Information Technology Policy, a research center that studies digital technologies in public life. Here you'll find comment and analysis from the digital frontier, written by the Center's faculty, students, and friends.