7Network Working Group D. Crocker, Ed.
8Request for Comments: 5672 Brandenburg InternetWorking
9Updates: 4871 August 2009
10Category: Standards Track
13 RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update
17 This document updates RFC 4871, "DomainKeys Identified Mail (DKIM)
18 Signatures". Specifically, the document clarifies the nature, roles,
19 and relationship of the two DKIM identifier tag values that are
20 candidates for payload delivery to a receiving processing module.
21 The Update is in the style of an Errata entry, albeit a rather long
26 This document specifies an Internet standards track protocol for the
27 Internet community, and requests discussion and suggestions for
28 improvements. Please refer to the current edition of the "Internet
29 Official Protocol Standards" (STD 1) for the standardization state
30 and status of this protocol. Distribution of this memo is unlimited.
34 Copyright (c) 2009 IETF Trust and the persons identified as the
35 document authors. All rights reserved.
37 This document is subject to BCP 78 and the IETF Trust's Legal
38 Provisions Relating to IETF Documents in effect on the date of
39 publication of this document (http://trustee.ietf.org/license-info).
40 Please review these documents carefully, as they describe your rights
41 and restrictions with respect to this document.
43 This document may contain material from IETF Documents or IETF
44 Contributions published or made publicly available before November
45 10, 2008. The person(s) controlling the copyright in some of this
46 material may not have granted the IETF Trust the right to allow
47 modifications of such material outside the IETF Standards Process.
48 Without obtaining an adequate license from the person(s) controlling
49 the copyright in such materials, this document may not be modified
50 outside the IETF Standards Process, and derivative works of it may
51 not be created outside the IETF Standards Process, except to format
52 it for publication as an RFC or to translate it into languages other
58Crocker Standards Track [Page 1]
60RFC 5672 RFC 4871 Update August 2009
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
66 2. RFC 4871, Abstract . . . . . . . . . . . . . . . . . . . . . . 4
67 3. RFC 4871, Section 1, Introduction . . . . . . . . . . . . . . 4
68 4. RFC 4871, Section 2.7, Identity . . . . . . . . . . . . . . . 4
69 5. RFC 4871, Section 2.8, Identifier . . . . . . . . . . . . . . 5
70 6. RFC 4871, Section 2.9, Signing Domain Identifier (SDID) . . . 5
71 7. RFC 4871, Section 2.10, Agent or User Identifier (AUID) . . . 5
72 8. RFC 4871, Section 2.11, Identity Assessor . . . . . . . . . . 6
73 9. RFC 4871, Section 3.5, The DKIM-Signature Header Field . . . . 6
74 10. RFC 4871, Section 3.5, The DKIM-Signature Header Field . . . . 7
75 11. RFC 4871, Section 3.8, Signing by Parent Domains . . . . . . . 9
76 12. RFC 4871, Section 3.9, Relationship between SDID and AUID . . 10
77 13. RFC 4871, Section 6.3, Interpret Results/Apply Local Policy . 11
78 14. RFC 4871, Section 6.3, Interpret Results/Apply Local Policy . 11
79 15. RFC 4871, Appendix D, MUA Considerations . . . . . . . . . . . 12
80 16. Security Considerations . . . . . . . . . . . . . . . . . . . 12
81 17. Normative References . . . . . . . . . . . . . . . . . . . . . 12
82 Appendix A. ABNF Fragments . . . . . . . . . . . . . . . . . . . 13
83 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14
88 About the purpose for DKIM, [RFC4871] states:
90 The ultimate goal of this framework is to permit a signing domain
91 to assert responsibility for a message, thus protecting message
94 Hence, DKIM has a signer that produces a signed message, a verifier
95 that confirms the signature, and an assessor that consumes the
96 validated signing domain. So, the simple purpose of DKIM is to
97 communicate an identifier to a receive-side assessor module. The
98 identifier is in the form of a domain name that refers to a
99 responsible identity. For DKIM to be interoperable and useful, the
100 signer and assessor must share the same understanding of the details
101 about the identifier.
103 However, the RFC 4871 specification defines two, potentially
104 different, identifiers that are carried in the DKIM-Signature: header
105 field, d= and i=. Either might be delivered to a receiving
106 processing module that consumes validated payload. The DKIM
107 specification fails to clearly define which is the "payload" to be
108 delivered to a consuming module, versus what is internal and merely
109 in support of achieving payload delivery.
114Crocker Standards Track [Page 2]
116RFC 5672 RFC 4871 Update August 2009
119 This currently leaves signers and assessors with the potential for
120 making different interpretations between the two identifiers and may
121 lead to interoperability problems. A signer could intend one to be
122 used for assessment, and have a different intent in setting the value
123 in the other. However the verifier might choose the wrong value to
124 deliver to the assessor, thereby producing an unintended (and
125 inaccurate) assessment.
127 This Update resolves that confusion. It defines additional, semantic
128 labels for the two values, clarifies their nature, and specifies
129 their relationship. More specifically, it clarifies that the
130 identifier intended for delivery to the assessor -- such as one that
131 consults a whitelist -- is the value of the "d=" tag. However, this
132 does not prohibit message filtering engines from using the "i=" tag,
133 or any other information in the message's header, for filtering
136 For signers and verifiers that have been using the i= tag as the
137 primary value that is delivered to the assessor, a software change to
138 using the d= tag is intended.
140 So, this Update clarifies the formal interface to DKIM, after
141 signature verification has been performed. It distinguishes DKIM's
142 internal signing and verification activity, from its standardized
143 delivery of data to that interface.
145 The focus of the Update is on the portion of DKIM that is much like
146 an API definition. If DKIM is implemented as a software library for
147 use by others, it needs to define what outputs are provided, that is,
148 what data that an application developer who uses the library can
149 expect to obtain as a result of invoking DKIM on a message.
151 This Update defines the output of that library to include the yes/no
152 result of the verification and the "d=" value. In other words, it
153 says what (one) identifier was formally specified for use by the
154 signer and whether the use of that identifier has been validated.
155 For a particular library, other information can be provided at the
156 discretion of the library developer, since developers of assessors --
157 these are the consumers of the DKIM library -- well might want more
158 information than the standardized two pieces of information.
159 However, that standardized set is the minimum that is required to be
160 provided to a consuming module, in order to be able to claim that the
161 library is DKIM compliant.
163 This does not state what the implicit value of "i=" is, relative to
164 "d=". In this context, that fact is irrelevant.
170Crocker Standards Track [Page 3]
172RFC 5672 RFC 4871 Update August 2009
175 Another example is the difference between the socket interface to TCP
176 versus the TCP protocol itself. There is the activity within the
177 protocol stack, and then there is the activity within in the software
178 libraries that are actually used.
180 NOTE: The text provided here updates [RFC4871]. Text appearing in
181 the "Corrected Text:" replaces text in RFC 4871. Hence,
182 references that appear in the "Original Text:" can be found in RFC
183 4871, and are not duplicated in this document.
185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
187 document are to be interpreted as described in [RFC2119].
193 The ultimate goal of this framework is to permit a signing domain
194 to assert responsibility for a message,
198 The ultimate goal of this framework is to permit a person, role or
199 organization that owns the signing domain to assert responsibility
2023. RFC 4871, Section 1, Introduction
206 ...permitting a signing domain to claim responsibility
210 permitting a person, role, or organization that owns the signing
211 domain to claim responsibility
2134. RFC 4871, Section 2.7, Identity
217 (None. New section. Additional text.)
226Crocker Standards Track [Page 4]
228RFC 5672 RFC 4871 Update August 2009
233 A person, role, or organization. In the context of DKIM, examples
234 include author, author's organization, an ISP along the handling
235 path, an independent trust assessment service, and a mailing list
2385. RFC 4871, Section 2.8, Identifier
242 (None. New section. Additional text.)
246 A label that refers to an identity.
2486. RFC 4871, Section 2.9, Signing Domain Identifier (SDID)
252 (None. New section. Additional text.)
256 A single domain name that is the mandatory payload output of DKIM
257 and that refers to the identity claiming responsibility for
258 introduction of a message into the mail stream. For DKIM
259 processing, the name has only basic domain name semantics; any
260 possible owner-specific semantics are outside the scope of DKIM.
261 It is specified in Section 3.5.
2637. RFC 4871, Section 2.10, Agent or User Identifier (AUID)
267 (None. New section. Additional text.)
271 A single identifier that refers to the agent or user on behalf of
272 whom the Signing Domain Identifier (SDID) has taken
273 responsibility. The AUID comprises a domain name and an optional
274 <Local-part>. The domain name is the same as that used for the
275 SDID or is a sub-domain of it. For DKIM processing, the domain
276 name portion of the AUID has only basic domain name semantics; any
277 possible owner-specific semantics are outside the scope of DKIM.
278 It is specified in Section 3.5.
282Crocker Standards Track [Page 5]
284RFC 5672 RFC 4871 Update August 2009
2878. RFC 4871, Section 2.11, Identity Assessor
291 (None. New section. Additional text.)
295 A module that consumes DKIM's mandatory payload, which is the
296 responsible Signing Domain Identifier (SDID). The module is
297 dedicated to the assessment of the delivered identifier. Other
298 DKIM (and non-DKIM) values can also be delivered to this module as
299 well as to a more general message evaluation filtering engine.
300 However, this additional activity is outside the scope of the DKIM
301 signature specification.
3039. RFC 4871, Section 3.5, The DKIM-Signature Header Field
307 d= The domain of the signing entity (plain-text; REQUIRED). This is
308 the domain that will be queried for the public key. This domain
309 MUST be the same as or a parent domain of the "i=" tag (the
310 signing identity, as described below), or it MUST meet the
311 requirements for parent domain signing described in Section 3.8.
312 When presented with a signature that does not meet these
313 requirement, verifiers MUST consider the signature invalid.
315 Internationalized domain names MUST be encoded as described in
320 sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
321 domain-name = sub-domain 1*("." sub-domain)
322 ; from RFC 2821 Domain,
323 but excluding address-literal
329 Specifies the SDID claiming responsibility for an introduction
330 of a message into the mail stream (plain-text; REQUIRED).
331 Hence, the SDID value is used to form the query for the public
332 key. The SDID MUST correspond to a valid DNS name under which
333 the DKIM key record is published. The conventions and
334 semantics used by a signer to create and use a specific SDID
338Crocker Standards Track [Page 6]
340RFC 5672 RFC 4871 Update August 2009
343 are outside the scope of the DKIM Signing specification, as is
344 any use of those conventions and semantics. When presented
345 with a signature that does not meet these requirements,
346 verifiers MUST consider the signature invalid.
348 Internationalized domain names MUST be encoded as described in
353 sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
354 domain-name = sub-domain 1*("." sub-domain)
355 ; from RFC 5321 Domain,
356 but excluding address-literal
35810. RFC 4871, Section 3.5, The DKIM-Signature Header Field
362 i= Identity of the user or agent (e.g., a mailing list manager) on
363 behalf of which this message is signed (dkim-quoted-printable;
364 OPTIONAL, default is an empty Local-part followed by an "@"
365 followed by the domain from the "d=" tag). The syntax is a
366 standard email address where the Local-part MAY be omitted. The
367 domain part of the address MUST be the same as or a subdomain of
368 the value of the "d=" tag.
370 Internationalized domain names MUST be converted using the steps
371 listed in Section 4 of [RFC3490] using the "ToASCII" function.
375 sig-i-tag = %x69 [FWS] "=" [FWS]
376 [ Local-part ] "@" domain-name
378 INFORMATIVE NOTE: The Local-part of the "i=" tag is optional
379 because in some cases a signer may not be able to establish a
380 verified individual identity. In such cases, the signer may
381 wish to assert that although it is willing to go as far as
382 signing for the domain, it is unable or unwilling to commit
383 to an individual user name within their domain. It can do so
384 by including the domain part but not the Local-part of the
387 INFORMATIVE DISCUSSION: This document does not require the value
388 of the "i=" tag to match the identity in any message header
389 fields. This is considered to be a verifier policy issue.
390 Constraints between the value of the "i=" tag and other
394Crocker Standards Track [Page 7]
396RFC 5672 RFC 4871 Update August 2009
399 identities in other header fields seek to apply basic
400 authentication into the semantics of trust associated with a
401 role such as content author. Trust is a broad and complex
402 topic and trust mechanisms are subject to highly creative
403 attacks. The real-world efficacy of
404 bindings between the "i=" value and other identities is not
405 well established, nor is its vulnerability to subversion by
406 an attacker. Hence reliance on the use of these options
407 should be strictly limited. In particular, it is not at all
408 clear to what extent a typical end-user recipient can rely on
409 any assurances that might be made by successful use of the
416 The Agent or User Identifier (AUID) on behalf of which the SDID
417 is taking responsibility (dkim-quoted-printable; OPTIONAL,
418 default is an empty Local-part followed by an "@" followed by
419 the domain from the "d=" tag).
421 The syntax is a standard email address where the Local-part MAY
422 be omitted. The domain part of the address MUST be the same
423 as, or a subdomain of the value of, the "d=" tag.
425 Internationalized domain names MUST be converted using the
426 steps listed in Section 4 of [RFC3490] using the "ToASCII"
431 sig-i-tag = %x69 [FWS] "=" [FWS]
432 [ Local-part ] "@" domain-name
434 The AUID is specified as having the same syntax as an email
435 address, but is not required to have the same semantics.
436 Notably, the domain name is not required to be registered in
437 the DNS -- so it might not resolve in a query -- and the Local-
438 part MAY be drawn from a namespace that does not contain the
439 user's mailbox. The details of the structure and semantics for
440 the namespace are determined by the Signer. Any knowledge or
441 use of those details by verifiers or assessors is outside the
442 scope of the DKIM Signing specification. The Signer MAY choose
443 to use the same namespace for its AUIDs as its users' email
444 addresses or MAY choose other means of representing its users.
445 However, the signer SHOULD use the same AUID for each message
446 intended to be evaluated as being within the same sphere of
450Crocker Standards Track [Page 8]
452RFC 5672 RFC 4871 Update August 2009
455 responsibility, if it wishes to offer receivers the option of
456 using the AUID as a stable identifier that is finer grained
459 INFORMATIVE NOTE: The Local-part of the "i=" tag is optional
460 because, in some cases, a signer may not be able to establish a
461 verified individual identity. In such cases, the signer might
462 wish to assert that although it is willing to go as far as
463 signing for the domain, it is unable or unwilling to commit to
464 an individual user name within their domain. It can do so by
465 including the domain part but not the Local-part of the
46811. RFC 4871, Section 3.8, Signing by Parent Domains
472 e.g., a key record for the domain example.com can be used to
473 verify messages where the signing identity ("i=" tag of the
474 signature) is sub.example.com, or even sub1.sub2.example.com. In
475 order to limit the capability of such keys when this is not
476 intended, the "s" flag may be set in the "t=" tag of the key
477 record to constrain the validity of the record to exactly the
478 domain of the signing identity. If the referenced key record
479 contains the "s" flag as part of the "t=" tag, the domain of the
480 signing identity ("i=" flag) MUST be the same as that of the d=
481 domain. If this flag is absent, the domain of the signing
482 identity MUST be the same as, or a subdomain of, the d= domain.
486 ...for example, a key record for the domain example.com can be
487 used to verify messages where the AUID ("i=" tag of the signature)
488 is sub.example.com, or even sub1.sub2.example.com. In order to
489 limit the capability of such keys when this is not intended, the
490 "s" flag MAY be set in the "t=" tag of the key record, to
491 constrain the validity of the domain of the AUID. If the
492 referenced key record contains the "s" flag as part of the "t="
493 tag, the domain of the AUID ("i=" flag) MUST be the same as that
494 of the SDID (d=) domain. If this flag is absent, the domain of
495 the AUID MUST be the same as, or a subdomain of, the SDID.
506Crocker Standards Track [Page 9]
508RFC 5672 RFC 4871 Update August 2009
51112. RFC 4871, Section 3.9, Relationship between SDID and AUID
513 Original Text: (None. New section. Additional text.)
517 DKIM's primary task is to communicate from the Signer to a
518 recipient-side Identity Assessor a single Signing Domain
519 Identifier (SDID) that refers to a responsible identity. DKIM MAY
520 optionally provide a single responsible Agent or User Identifier
523 Hence, DKIM's mandatory output to a receive-side Identity Assessor
524 is a single domain name. Within the scope of its use as DKIM
525 output, the name has only basic domain name semantics; any
526 possible owner-specific semantics are outside the scope of DKIM.
527 That is, within its role as a DKIM identifier, additional
528 semantics cannot be assumed by an Identity Assessor.
530 A receive-side DKIM verifier MUST communicate the Signing Domain
531 Identifier (d=) to a consuming Identity Assessor module and MAY
532 communicate the Agent or User Identifier (i=) if present.
534 To the extent that a receiver attempts to intuit any structured
535 semantics for either of the identifiers, this is a heuristic
536 function that is outside the scope of DKIM's specification and
537 semantics. Hence, it is relegated to a higher-level service, such
538 as a delivery handling filter that integrates a variety of inputs
539 and performs heuristic analysis of them.
541 INFORMATIVE DISCUSSION: This document does not require the value
542 of the SDID or AUID to match the identifier in any other message
543 header field. This requirement is, instead, an assessor policy
544 issue. The purpose of such a linkage would be to authenticate the
545 value in that other header field. This, in turn, is the basis for
546 applying a trust assessment based on the identifier value. Trust
547 is a broad and complex topic and trust mechanisms are subject to
548 highly creative attacks. The real-world efficacy of any but the
549 most basic bindings between the SDID or AUID and other identities
550 is not well established, nor is its vulnerability to subversion by
551 an attacker. Hence, reliance on the use of such bindings should
552 be strictly limited. In particular, it is not at all clear to
553 what extent a typical end-user recipient can rely on any
554 assurances that might be made by successful use of the SDID or
562Crocker Standards Track [Page 10]
564RFC 5672 RFC 4871 Update August 2009
56713. RFC 4871, Section 6.3, Interpret Results/Apply Local Policy
571 It is beyond the scope of this specification to describe what
572 actions a verifier system should make, but an authenticated email
573 presents an opportunity to a receiving system that unauthenticated
574 email cannot. Specifically, an authenticated email creates a
575 predictable identifier by which other decisions can reliably be
576 managed, such as trust and reputation. Conversely,
577 unauthenticated email lacks a reliable identifier that can be used
578 to assign trust and reputation.
582 It is beyond the scope of this specification to describe what
583 actions an Identity Assessor can make, but mail carrying a
584 validated SDID presents an opportunity to an Identity Assessor
585 that unauthenticated email does not. Specifically, an
586 authenticated email creates a predictable identifier by which
587 other decisions can reliably be managed, such as trust and
59014. RFC 4871, Section 6.3, Interpret Results/Apply Local Policy
594 Once the signature has been verified, that information MUST be
595 conveyed to higher-level systems (such as explicit allow/
596 whitelists and reputation systems) and/or to the end user. If the
597 message is signed on behalf of any address other than that in the
598 From: header field, the mail system SHOULD take pains to ensure
599 that the actual signing identity is clear to the reader.
603 Once the signature has been verified, that information MUST be
604 conveyed to the Identity Assessor (such as an explicit allow/
605 whitelist and reputation system) and/or to the end user. If the
606 SDID is not the same as the address in the From: header field, the
607 mail system SHOULD take pains to ensure that the actual SDID is
618Crocker Standards Track [Page 11]
620RFC 5672 RFC 4871 Update August 2009
62315. RFC 4871, Appendix D, MUA Considerations
627 The tendency is to have the MUA highlight the address associated
628 with this signing identity in some way, in an attempt to show the
629 user the address from which the mail was sent.
633 The tendency is to have the MUA highlight the SDID, in an attempt
634 to show the user the identity that is claiming responsibility for
63716. Security Considerations
639 This Update clarifies core details about DKIM's payload. As such, it
640 affects interoperability, semantic characterization, and the
641 expectations for the identifiers carried with a DKIM signature.
642 Clarification of these details is likely to limit misinterpretation
643 of DKIM's semantics. Since DKIM is fundamentally a security
644 protocol, this should improve its security characteristics.
64617. Normative References
648 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
649 Requirement Levels", BCP 14, RFC 2119, March 1997.
651 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
652 "Internationalizing Domain Names in Applications (IDNA)",
653 RFC 3490, March 2003.
655 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
656 J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
657 Signatures", RFC 4871, May 2007.
674Crocker Standards Track [Page 12]
676RFC 5672 RFC 4871 Update August 2009
679Appendix A. ABNF Fragments
681 This appendix contains the full set of corrected ABNF fragments
682 defined in this document.
684 Copyright (c) 2009 IETF Trust and the persons identified as authors
685 of the code. All rights reserved.
687 Redistribution and use in source and binary forms, with or without
688 modification, are permitted provided that the following conditions
691 - Redistributions of source code must retain the above copyright
692 notice, this list of conditions and the following disclaimer.
694 - Redistributions in binary form must reproduce the above copyright
695 notice, this list of conditions and the following disclaimer in the
696 documentation and/or other materials provided with the
699 - Neither the name of Internet Society, IETF or IETF Trust, nor the
700 names of specific contributors, may be used to endorse or promote
701 products derived from this software without specific prior written
704 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
705 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
706 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
707 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
708 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
709 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
710 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
711 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
712 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
713 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
714 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
716 This version of this MIB module is part of RFC 5672; see the RFC
717 itself for full legal notices.
719 sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
720 domain-name = sub-domain 1*("." sub-domain)
721 ; from RFC 5321 Domain,
722 but excluding address-literal
724 sig-i-tag = %x69 [FWS] "=" [FWS]
725 [ Local-part ] "@" domain-name
730Crocker Standards Track [Page 13]
732RFC 5672 RFC 4871 Update August 2009
735Appendix B. Acknowledgements
737 This document was initially formulated by an ad hoc design team,
738 comprising: Jon Callas, D. Crocker, J. D. Falk, Michael Hammer, Tony
739 Hansen, Murray Kucherawy, John Levine, Jeff Macdonald, Ellen Siegel,
740 and Wietse Venema. The final version of the document was developed
741 through vigorous discussion in the IETF DKIM working group.
746 Brandenburg InternetWorking
748 Phone: +1.408.246.8253
749 EMail: dcrocker@bbiw.net
786Crocker Standards Track [Page 14]