DKIM is Done

This was posted to the IETF DKIM Working Group mailing list this morning:

The dkim working group has completed its primary charter items, and is officially closing. The mailing list will be retained for future discussions involving dkim. The list archive will also be retained.
The dkim working group was primarily focused on DomainKeys Identified Mail (DKIM) Signatures and DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) (RFC 5617). We applaud the working group for progressing DomainKeys Identified Mail (DKIM) Signatures from proposed standard (RFC 4871) to Draft Standard (RFC 6376). The working group also produced the following Informational RFCs: Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) (RFC 4868), DomainKeys Identified Mail (DKIM) Service Overview (RFC 5585), Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol (RFC 5016), and DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations (RFC 5863). The proposed standard DKIM And Mailing Lists (RFC 6737) was the final RFC produced by the working group.

What does this mean for DKIM-the-protocol?

DKIM as a protocol is finished and stable. It’s possible that there could be an incompatible “DKIM version 2” in the future, but it’s fairly unlikely. It’s also possible that there’ll be a clarification of the existing spec in the future, if someone flushes out some bugs or inconsistencies while they’re implementing it, but that won’t break any existing usage.
If you want to attach an identifier to mail you send, or you want to use those identifiers to handle whitelisting or reputation-tracking or to drive domain-based feedback loops for mail you receive, DKIM is the way to do it.
What’s left to do?
DomainKeys Must Go
DomainKeys was the forerunner to DKIM. It’s been obsolete for several years and at this point nobody should be signing with it (or paying any attention to DomainKeys signatures). I’ve seen several cases recently where attempting to support both DomainKeys and DKIM lead to operational problems with the DKIM signing. It’s dead, let it go.

Good operational practices for signing with DKIM
This is the big bit of work left to do. While verifying a DKIM message and extracting the d= identifier from it is very well-defined, how best to sign with DKIM – including how best to do key management, key delegation and what DKIM options to use when signing – still hasn’t crystallized. Our suggestions for that are here: www.dkimcore.org
Configuration API support in smarthosts
While messages can be signed with DKIM anywhere in the mail pipeline they’re almost always signed at the sender smarthost. Many of the smarthosts added DKIM support by evolving the code they already had to sign with DomainKeys, which was a good engineering decision at the time. But DKIM is a much more flexible protocol than DomainKeys was, yet I’m told some of the smarthosts haven’t evolved far enough and only really support a “DomainKeys-like subset” of DKIM. Limited APIs like that reduce your flexibility in how you deploy DKIM, and will mean you can’t even try some of the smarter ways to use it.
As a minimum, your smarthost should be able to sign a message with any arbitrary private key / d= value pair rather than being tied to any email address or domain in the email headers. If it can’t do that, it’s not really supporting DKIM. If it can sign a message twice or three times efficiently – while processing the body of the message just once – that’s a DKIM feature that’s likely to be useful for ESPs.
Some sort of API to allow key management automation (deployment, delegation, rotation and invalidation) would make rich DKIM use much easier to deploy at scale, but I don’t know if anyone has looked at that sort of support in smarthosts yet. Anyone know?
Semantics
There’s still some misunderstanding about what some elements of DKIM mean.
What is the identity that DKIM conveys? (Usually the “d=” field, though the additional information in the “i=” field might sometimes be part of that too).
What does the selector mean? (Absolutely nothing! If you try and claim it does, you’re doing it wrong. It’s intended for key rotation and key delegation, and attempting to use it for anything else will make key management harder, and likely end up making the signature less secure).
What do multiple signatures mean? (That it was signed by each of those domains. None is more important than the others, and there’s no “primary” signing domain. What you do with that information is a whole other thing, though).
What about ADSP?
ADSP is effectively dead. The discussions that happened as part of it’s development, and the results (both good and bad) of limited testing with it will probably lead to something with similar goals in the near future – more limited in scope, probably, but less fundamentally flawed.
Whence SPF?
SPF isn’t dead, by any means. I expect some mail recipients will check both DKIM and SPF for the near future (though I’ve heard some interesting discussion about receivers keeping a local cache of DKIM results correlated with sending IP which may end up replacing one common SPF-based performance hack).
And what’s next?
Thanks to everyone involved in the DKIM specification process for creating this unobtrusive, robust way of attaching an identity to an email!
It’s going to be interesting to see what features people build on top of the DKIM foundation.

Related Posts

Who can you trust?

I’ve been recently dealing with a client who is looking at implementing authentication on their domains. He’s done a lot of background research into the schemes and has a relatively firm grasp on the issue. At this point we’re working out what policies he wants to set and how to correctly implement those policies.
His questions were well informed for the most part. A few of them were completely out of left field, so I asked him for some of his references. One of those references was the EEC Email Authentication Whitepaper.
My client was doing the best he could to inform himself and relies on industry groups like the EEC to provide him with accurate information. In this case, their information was incomplete and incorrect.
We all have our perspectives and biases (yes, even me!) but there are objective facts that can be independently verified. For instance, the EEC Authentication whitepaper claimed that Yahoo requires DKIM signing for access to their whitelist program. This is incorrect, a sender does not have to sign with DKIM in order to apply for the Yahoo whitelist program. A bulk sender does have to sign with DKIM for a Y! FBL, but ISPs are given access to an IP based FBL by Yahoo. I am shocked that none of the experts that contributed to the document caught that error.
Independent verification is one reason I publish the Delivery Wiki. It’s a resource for everyone and a way to share my knowledge and thought processes. But other experts can “check my work” as it were and provide corrections if my information is outdated or faulty. All too often, senders end up blaming delivery problems on evil spirits, or using “dear” in the subject line or using too much pink in the design.
Delivery isn’t that esoteric or difficult if you have a clear understanding of the policy and technical decisions at a range of ESPs and ISPs, the history and reasoning behind those decisions, and enough experience to predict the implications when they collide.
Many senders do face delivery challenges and there is considerable demand for delivery experts to provide delivery facts. That niche has been filled by a mix of people, of all levels of experience, expertise and technical knowledge, leading to the difficult task of working out which of those “experts” are experts, and which of those “facts” are facts.

Read More

SPF records: not really all that important

I’ve been working through some Hotmail issues with a client over the last few months. One of the things that has become clear to me is how little Hotmail actually does with SPF records. In fact, Hotmail completely ignored my client’s SPF record and continued to deliver email into the inbox.
This isn’t just a sender that had a “well, we think most of our email will come from these IPs but aren’t telling you to throw away email that doesn’t” record. In fact, this client specifically said “if email doesn’t come from this /28 range of email addresses, then it is unauthorized and should be thrown away.” The email was being sent from an IP outside of the range listed in the SPF record.
As part of the process involved in fixing the delivery problems, I had the client update their SPF record and then I enrolled their domain in the SenderID program at Hotmail. This didn’t have any effect, though. Hotmail is still not checking SPF for this client. When I asked Hotmail what was going on they said, “We do not do lookups on every sender’s mail.”
So, there you have it folks. The last bastion of SPF/SenderID has abandoned the technology. Even a totally invalid SPF record doesn’t matter, mail can still reach the inbox at Hotmail.

Read More

DKIM: what it's not

An ESP twittered this past week about their new DKIM implementation going live. They were quite happy with themselves. Unfortunately, in their blog post, they mentioned 3 things that DKIM would provide for their customers, and got it wrong on all 3 points. Their confusion is something that a lot of people seem to get wrong about DKIM so I thought I would explain what was wrong.

Read More