Last month, in an item about SpamBayes, I mentioned IronPort's SenderBase service and Bonded Sender (1, 2) program. SenderBase is an extraordinary resource for investigating email senders. The homepage lists the top high-volume senders, but you can drill all the way down to small-fry IP addresses. If you're on a DSL or cable connection with a static IP address, try looking yourself up:
Now, here's part of the result screen you get when you look up 206.16.1.160, which is a CNET address:
CNET is a bonded sender. The company promises not to send spam, and stands to forfeit its bond (to TrustE, not IronPort) if it breaks the promise. The SenderBase service provides a DNSBL-style lookup service that works like this:
1% nslookup 160.1.16.206.query.bondedsender.org
Name: 160.1.16.206.query.bondedsender.org
Address: 127.0.0.10
Normally any IP-address response from such a query means the queried address is listed on an RBL (realtime black list), but in this case it's the converse: an RWL (realtime white list).
I had a long talk with IronPort's founder and CTO Scott Banister yesterday, as part of my research for an upcoming InfoWorld article. I've long been fascinated with digital identity schemes. This one certifies what Scott calls the single unforgeable element of an email message: the sender's IP address. It's a really interesting way for legitimate high-volume senders to bypass content filters deployed in gateways, servers, and clients.
Today, when I interviewed Mark Mallett, who runs my local ISP, I learned of an individual variation on the bonded-sender theme: Habeas. With Habeas, senders license a haiku that they embed (along with legalese) in message headers, like so:
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
The idea, as Mark explains, is that in the absence of anti-spam laws with teeth, it's nevertheless possible to use existing copyright and trademark law to attack spammers who misappropriate the copyrighted and trademarked haiku (lines 1-3 of the headers).
But would it hold up in court? Jonathan Zittrain, assistant professor at the Harvard Law School and co-director of the Berkman Center on Internet and Society, has his doubts about the haiku copyright infringement charge. [Hiawatha Bray]
I'm not a lawyer, and can't evaluate that. I will note, though, that there are usability challenges for individuals who want to self-certify messages using the version of the Habeas license that's free for non-commercial purposes. Consider this HOWTO for OS X Mail.app users:
Here's the command I typed at the Terminal prompt in order to add the Habeas custom headers:
[localhost:~] rvaessen% defaults write com.apple.mail UserHeaders '{"X-Habeas-SWE-1" = "winter into spring";"X-Habeas-SWE-2" = "brightly anticipated";"X-Habeas-SWE-3" = "like Habeas SWE (tm)";"X-Habeas-SWE-4" = "Copyright 2002 Habeas (tm)";"X-Habeas-SWE-5" = "Sender Warranted Email (SWE) (tm). The sender of this";"X-Habeas-SWE-6" = "email in exchange for a license for this Habeas";"X-Habeas-SWE-7" = "warrant mark warrants that this is a Habeas Compliant";"X-Habeas-SWE-8" = "Message (HCM) and not spam. Please report use of this";"X-Habeas-SWE-9" = "mark in spam to <http://www.habeas.com/report/>.";}'
[Habeas discussion list]
I dunno. If you're really ready to get that geeky, why not go all the way and set yourself up with a regular S/MIME cert, which is also useful for signing and encryption? Of course, OCSP (online certificate status protocol) lookups can't leverage the same DNS-oriented infrastructure that the RBLs and RWLs use. But from the perspective of an implementor who's doing lookups from an email gateway, server, or client, it's six of one, half-dozen of the other, I would think. Why haven't VeriSign, Baltimore, and the rest of the PKI gang glommed onto this?
Well, the answer's pretty obvious. OCSP and CRL (certificate revocation list) have never been heavily used, and are unlikely to scale. (For the same reason, I suspect that if Habeas or any other individual certification scheme became popular, it would become a victim of its own success.) There are, however, some new approaches in the PKI space that aim to make massive scale-up practical -- see, for example, CoreStreet Technology's Real Time Credentials Validation Authority. I'll be watching this area with interest.
Former URL: http://weblog.infoworld.com/udell/2003/06/20.html#a728