The IESG has approved the following document: - 'DomainKeys Identified Mail (DKIM) Signatures' (draft-ietf-dkim-rfc4871bis-15.txt) as a Draft Standard This document is the product of the Domain Keys Identified Mail Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dkim-rfc4871bis/ Technical Summary DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay or one of their agents. DKIM separates the question of the identity of the signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and querying the signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. Working Group Summary Getting this document finished has been a controversial process, with strong disagreement about a number of points. There is certainly broad agreement that DKIM is a widely deployed, useful protocol, and that it's ready for advancement. There are major differences of opinion on several things, including 1. The importance of giving specific advice on which email header fields to sign. 2. What information should be considered "output" from the signature verifier. 3. How the DKIM signature ties into, or should tie into, domain names that appear in other parts of the email message, particularly the RFC 5322 "from" header field. 4. How to handle potential attacks mounted by adding extra header fields to the message after it has been signed. This is a particular issue with the RFC 5322 "from" header field, but affects other header fields as well. There have been other controversies; this list is not exhaustive. See the mailing list archives for more details. In the end, though, the document as submitted has rough and significant consensus of the working group as a whole, even when it doesn't represent unanimity. Document Quality The DKIM base protocol is widely deployed, with many implementations (see http://www.ietf.org/iesg/implementation/report-rfc4871.txt ). This version of the spec comes after a thorough working group review and publication of RFC 5672, which added significant clarifications to the language. Diffs between RFC 4871 and this draft can be found at: http://www.trusteddomain.org/dkim-diff.html Personnel Barry Leiba (barryleiba@computer.org) is the Document Shepherd. Sean Turner (turners@ieca.com) is the Responsible Area Director. RFC Editor Note Note that draft-ietf-dkim-mailinglists depends heavily on draft-ietf-dkim-rfc4871bis, and will be waiting in the editor queue for a reference to it. That document has references to specific sections in draft-ietf-dkim-rfc4871bis, so the RFC Editor should process rfc4871bis first, and make sure the section references in dkim-mailinglists are correct afterward. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
