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

Link roundup June 18, 2010

Hotmail has released a new version of their software with some changes. Return Path discusses the changes in depth, but there are a couple that senders may find helpful.

Read More

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

How to disable a domain

Sometimes you might want to make it clear that a domain isn’t valid for email.
Perhaps it’s a domain or subdomain that’s just used for infrastructure, perhaps it’s a brand-specific domain you’re only using for a website. Or perhaps you’re a target for phishing and you’ve acquired some lookalike domains, either pre-emptively or after enforcement action against a phisher, and you want to make clear that the domain isn’t legitimate for email.
There are several things to check before disabling email.
1. Are you receiving email at the domain? Is anyone else?
Check the MX records for the domain, using “host -t mx example.com” from a unix commandline, or using an online DNS tool such as xnnd.com.
If they’re pointing at a mailserver you control, check to see where that mail goes. Has anything been sent there recently?
If they’re pointing at a mailserver that isn’t yours, try and find out why.
If there are no MX records, but there is an A record for the domain then mail will be delivered there instead. Check whether that machine receives email for the domain and, if so, what it does with it.
Try sending mail to postmaster@ the domain, for instance postmaster@example.com. If you don’t get a bounce within a few minutes then that mail may be being delivered somewhere.
2. Are you sending email from the domain? Is anyone else?
You’re more likely to know whether you’re sending mail using the domain, but there’s a special case that many people forget. If there’s a server that has as it’s hostname the domain you’re trying to shut down then any system software running no that server – monitoring software, security alerts, output from cron and so on – is probably using that hostname to send mail. If so, fix that before you go any further.
3. Will you need mail sent to that domain for retrieving passwords?
If there are any services that might have been set up using an email address at the domain then you might need a working email address there to retrieve lost passwords. Having to set email back up for the domain in the future to recover a password is time consuming and annoying.
The domain registration for the domain itself is a common case, but if there’s any dns or web hosting being used for the domain, check the contact information being used there.
4. How will people contact you about the domain?
Even if you’re not using the domain for email it’s quite possible that someone may need to contact you about the domain, and odds are good they’ll want to use email. Make sure that the domain registration includes valid contact information that identifies you as the owner and allows people to contact you easily.
If you’re hosting web content using the domain, make sure there’s some way to contact you listed there. If you’re not, consider putting a minimal webpage there explaining the ownership, with a link to your main corporate website.
5. Disabling email
The easiest way to disable email for a domain is to add three DNS records for the domain. In bind format, they look like:

Read More