It’s been a while since my last anti-spam post. But I haven’t been idle! I’ve been reading the DomainKeys Identified Mail (DKIM) RFC that was released in May this year.

This protocol is so similar to my own idea that I’ve decided to drop my idea and look more closely at DKIM more closely. The difference, I guess, is that my idea was a whole separate protocol, whereas DKIM is built on top of SMTP and MIME. The basic idea is that you put a signature for the message in the header, and the receiver can use DNS to query the domain of the sender for the public key to decrypt the header.

The end result is almost identical to my idea: when you receive a piece of mail at your server, you know that the domain of the “From” is taking responsibility for the message.

At first glance, that may not sound like a big deal. But it’s what you do with that knowledge that makes sense. You see, the biggest problem with spam is that it is very processor intensive – you have to scan every single email using Baysian filters, look up RBLs, internal blacklists/whitelists, etc. Anything you can do to ensure email can bypass those checks is a win.

In addition, anything you can do to ensure a mail is marked as spam more quickly (i.e. with less filtering and so on) the better as well.

And that’s what DKIM allows. Like I said, it’s what you build on top that matters.

Stay tuned for my ideas