Skip navigation

The Legal Implications of RBLs

Sometimes it's hard to find a good topic to write about for the UPDATE; other times, something just jumps out at me and I almost can't help writing about it. This week's column is the result of the latter: A respected legal scholar, Jonathan I. Ezor, has written an interesting paper that covers the legal implications of Realtime Blackhole Lists (RBLs). The paper, “Busting Blocks: Appropriate Legal Remedies for Wrongful Inclusion in Spam Filters Under U.S. Law,” (http://papers.ssrn.com/sol3/papers.cfm?abstract_id=944551) is interesting to Exchange administrators for several reasons, not least that Professor Ezor "argues for a higher standard of care among block list vendors"—something that an administrator for any mistakenly blocked business would no doubt welcome.

The paper begins by defining spam and presenting a brief history; it's probably safe to say that most UPDATE readers can skip that part. Ezor goes on to discuss the Internet tradition of finding self-policing technical solutions to behavioral problems whenever possible, and he places RBLs in this tradition. However, as with many other self-regulated environments, there's no guarantee that all the involved parties will either follow the regulations or act reasonably in the context of the environment. Thus we've seen a rise in litigation involving RBLs, including several companies who have sued claiming that they were wrongly added to a list. (My own ISP, Buckeye Express, has filed such a suit, but it's still pending.)

Ezor explains that entities wrongly added to an RBL have sued for defamation, "intentional interference with prospective business relationships" (which is just about what it sounds like), restraint of trade, and a variety of other grievances. There's no doubt that when your server's IP address is added to a blacklist, you'll have trouble exchanging legitimate email with other organizations; the only real questions are how fast you'll figure out what the problem is and how fast you can fix it. Filing suit is certainly an extreme measure, but some RBL providers take a surprisingly casual approach to fixing mistakes. Clearly the good professor is on to something when he says, "For the sender, though, the consequences \[of a mistake\] can be severe, and without the ability to use the courts to force a change, the sender may have little recourse."

Instead of spamming the courts with litigation, Ezor proposes an alternative solution:

  • RBL vendors should use objective standards to decide who they add to their lists.
  • Senders who complain should be automatically delisted unless there's proof that they're spammers.
  • RBLs should list the IP address of only the offending sender, not another party who might benefit from the message (such as the advertiser whose product is being touted).
  • Providers should "be held to professional standards of conduct, including objectivity, reasonable care, and (to the extent their activities cause harm) accountability."

This is a pretty strong set of suggestions, especially the last one. The Internet, and the IT world in general, has a long history of trouble with the idea that "professional standards of conduct" should apply. It doesn't seem likely that RBL providers (many of which are operated by volunteers) who have historically refused to apply these standards will suddenly start doing so unless someone makes them, and in that case the cure might be worse than the disease.

However, it's an interesting argument, particularly in light of the complaints I've been hearing from administrators who have been incorrectly added to blacklists. What do you think? Would you be willing to pay a fee to subscribe to an RBL service if you could find one that followed these recommendations? Drop me a note and let me know.

One last reminder: This is the final week to submit proposals for the spring 2007 Exchange Connections show, which will be held April 1-4 at the Hyatt Regency Grand Cypress in Orlando, Florida. If you're interested in speaking or would like to see particular sessions presented, drop me a note at [email protected]. (Note that this address is different from my regular email address.)

TAGS: Security
Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish