DKIM Is Done

Discussion in 'Mail Chat' started by roundabout, Sep 27, 2011.

  1. roundabout

    roundabout VIP

    Joined:
    Feb 17, 2011
    Messages:
    2,713
    Likes Received:
    154
    Trophy Points:
    63
    DKIM is Done

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

    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***8243; 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.

    Source:
    http://blog.wordtothewise.com/
     
  2. roundabout

    roundabout VIP

    Joined:
    Feb 17, 2011
    Messages:
    2,713
    Likes Received:
    154
    Trophy Points:
    63
    I heard they're abandoning DK and DKIM in favor of the new DKPMO.
     
  3. erbux

    erbux VIP

    Joined:
    Apr 21, 2011
    Messages:
    266
    Likes Received:
    38
    Trophy Points:
    28
    Location:
    eastern empire
    LOL! That's a good one.
     
  4. DKPMO

    DKPMO VIP

    Joined:
    Mar 31, 2011
    Messages:
    1,452
    Likes Received:
    68
    Trophy Points:
    48
    Location:
    Elaborate Underground Base
    DKPMO is still in the stealth mode and has not been announced. Stay tuned, ladies and gentlemen!
     
  5. PushSend

    PushSend VIP

    Joined:
    Apr 12, 2011
    Messages:
    1,927
    Likes Received:
    141
    Trophy Points:
    63
    Location:
    Paradise
    I heard that DKPMO is only for IPv6 though....

    :34:
     
  6. DKPMO

    DKPMO VIP

    Joined:
    Mar 31, 2011
    Messages:
    1,452
    Likes Received:
    68
    Trophy Points:
    48
    Location:
    Elaborate Underground Base
    That is not accurate, DKPMO is all about improving monetization on all platforms.
     

Share This Page