The hashcash scheme, which requires the sender to spend CPU cycles generating an ID number for each message, dates back to about 1992 or so. And “caller ID for email” derives from RMX (Reverse MX), a more recent proposal to bind senders to authorised relays via DNS records.
The truth is, we’ve had plenty of innovation through the years. What we’ve lacked is follow-through. Consider S/MIME digital signatures. It’s very likely that your email client supports them. But it’s overwhelmingly unlikely that you’ve ever digitally signed an email message.
Every time an identity-spoofing worm shows up, I realise how sad it is that we don’t yet expect to receive signed email from legitimate correspondents. Then I review our current implementations of signing and I remember why.
The first hurdle is getting the digital certificate you need to sign messages. For years, I’ve been using the free certificates available from Thawte (now a VeriSign subsidiary). But when I visited Thawte.com the other day to acquire a cert for Mac OS X’s Mail (which, as of 10.3, finally supports S/MIME), I realised that I was part of an elite group that knew where to go and what to do.
It’s commendable that Thawte/VeriSign continue to support free certificates. I can hardly blame them for burying the option amid promotions for their paid products.
Getting people to activate the identity-management features latent within their email software is a thankless, unprofitable, but socially responsible chore. So why not enlist the help of US state governments? As former Utah CIO Phil Windley likes to point out, they are already our baseline identity providers.
Once you’ve acquired a certificate, the next hurdle is installing it. In the case of PantherMail, this was a typically excruciating procedure. Although I’ve used a dozen different implementations of S/MIME, I wouldn’t have succeeded without the help of the detailed recipe that Google found for me. Here’s the short version. Ignoring the fact that Thawte makes no mention of Apple mail clients, I used Mozilla’s Firefox to fetch the certificate (because Apple’s native Safari browser can’t handle the certificate request protocol), then exported the cert from Mozilla and imported it into OS X’s Keychain. Yeah, right. I’m sure Eric Raymond's Aunt Tillie will have no problem doing that little dance.
Then there’s the issue of securely using the certificate. In Outlook I’ve set things up so that I have to unlock the certificate database not just once per session, but once per message. This prevents rogue programs from using cached credentials to send a message I didn’t sign. The option is so obscure, though, that I may be the only person ever to use it. (Hint: When installing the cert, use the Set Security Level button and boost the level to High.) You can achieve the same effect on OS X in a similarly obscure way. (Hint: In Keychain Access, find your private key and visit its Access Control tab.) It doesn’t have to be this way. We’ve had workable solutions to the problem of spoofed email identity for years. Let’s dust them off, spruce them up, and put them to use.
Udell is lead analyst for the InfoWorld Test Center.