I've talked about Domain Keys Identified Mail before (DKIM; pronounce it “DEE-kim”). Well, as of the end of this week, the DKIM base specification is in the RFC Editor queue, having passed review by the IESG. What that alphabet soup means is that it's pretty much officially a “Proposed Standard”, awaiting final cosmetic editing and an “RFC number”.
For a quick, oversimplified review: DKIM defines a standard mechanism for using digital signatures at the domain level to limit the opportunity for senders — the senders of spam in particular — to lie about their identities. To learn more about digital signatures, go here. What makes DKIM different from other uses of digital signatures in email is that it's transparent to you, the user. You don't have to deal with getting or managing encryption keys or digital certificates, you don't have to see or decipher the signatures, you don't have to worry about what any of it means. It's all meant to be done in the background, by your email service provider.
DKIM doesn't stop spam in any way. What it does is to allow a “sending” service provider to take responsibility for having sent the message to the Internet, and to allow a “receiving” service provider to decide what to do when someone — or no one — has taken that responsibility.
Suppose email is sent from accounts@yourbank.example to you, me-me-me@emailservice.example. Before the email server at YourBank sends the message to the Internet, it puts a signature on it that identifies the sending domain as yourbank.example. When the email server at emailservice.example receives it, and before it puts it into your inbox, it checks that the signature is valid. If it is, it can treat it differently — perhaps it skips the strict spam checking that it might otherwise do, because it trusts yourbank.example.
If someone who isn't really at yourbank.example tries to fool you by sending mail that appears to be from accounts@yourbank.example, it will not have a valid signature on it. In that case, emailservice.example can treat it more suspiciously, checking it thoroughly, or perhaps deleting it altogether if it has a trust relationship with YourBank that tells it that such suspicious mail must be bogus.
This doesn't fix everything, of course. Without other information, it's not safe to delete unsigned mail. And “spoofers” can still use similar-looking domain names, such as yoorbank.example. Even so, DKIM is a big step toward limiting a nasty tool that the spammers have in their toolbox, and that's a good thing.
We still have lots of work to do on other related protocols, such as one to convey some of that extra information that can help the receiving domain decide what to do with unsigned mail. We also expect reputation and accreditation services to take advantage of DKIM, and to add value to it. And so we continue to work. But getting this signature specification out as Proposed Standard is a major step.
Some useful links for those who're interested:
No comments:
Post a Comment