rfc4871.txt   draft-ietf-dkim-rfc4871bis-00.txt >
Network Working Group E. Allman DKIM D. Crocker
Request for Comments: 4871 Sendmail, Inc. Internet-Draft Brandenburg InternetWorking
Obsoletes: 4870 J. Callas Obsoletes: 4871 (if approved) T. Hansen
Category: Standards Track PGP Corporation Intended status: Standards Track AT&T Laboratories
M. Delany Expires: February 16, 2011 M. Kucherawy
M. Libbey Cloudmark
Yahoo! Inc August 15, 2010
J. Fenton
M. Thomas
Cisco Systems, Inc.
May 2007
DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) Signatures
draft-ietf-dkim-rfc4871bis-00
Status of This Memo Abstract
This document specifies an Internet standards track protocol for the DomainKeys Identified Mail (DKIM) permits a person, role, or
Internet community, and requests discussion and suggestions for organization that owns the signing domain to claim some
improvements. Please refer to the current edition of the "Internet responsibility for a message by associating the domain with the
Official Protocol Standards" (STD 1) for the standardization state message. This can be an author's organization, an operational relay
and status of this protocol. Distribution of this memo is unlimited. 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.
Copyright Notice Status of this Memo
Copyright (C) The IETF Trust (2007). This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Abstract Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
DomainKeys Identified Mail (DKIM) defines a domain-level Internet-Drafts are draft documents valid for a maximum of six months
authentication framework for email using public-key cryptography and and may be updated, replaced, or obsoleted by other documents at any
key server technology to permit verification of the source and time. It is inappropriate to use Internet-Drafts as reference
contents of messages by either Mail Transfer Agents (MTAs) or Mail material or to cite them other than as "work in progress."
User Agents (MUAs). The ultimate goal of this framework is to permit
a signing domain to assert responsibility for a message, thus This Internet-Draft will expire on February 16, 2011.
protecting message signer identity and the integrity of the messages
they convey while retaining the functionality of Internet email as it Copyright Notice
is known today. Protection of email identity may assist in the
global control of "spam" and "phishing". Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 5 1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 6
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 5 1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 6
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6
2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 6 2.4. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 7
2.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 7 2.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 8
2.6. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 7 2.6. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 8
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8 2.7. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 8 2.8. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 10 2.9. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 10
3.3. Signing and Verification Algorithms . . . . . . . . . . . 11 2.10. Agent or User Identifier (AUID) . . . . . . . . . . . . . 10
3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 13 2.11. Identity Assessor . . . . . . . . . . . . . . . . . . . . 10
3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 17 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 10
3.6. Key Management and Representation . . . . . . . . . . . . 25 3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 10
3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 29 3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 12
3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 31 3.3. Signing and Verification Algorithms . . . . . . . . . . . 13
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 32 3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15
4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 32 3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 19
4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 33 3.6. Key Management and Representation . . . . . . . . . . . . 28
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 34 3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33
3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 35
3.9. Relationship between SDID and AUID . . . . . . . . . . . . 35
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 36
4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 36
4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 37
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1. Determine Whether the Email Should Be Signed and by 5.1. Determine Whether the Email Should Be Signed and by
Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2. Select a Private Key and Corresponding Selector 5.2. Select a Private Key and Corresponding Selector
Information . . . . . . . . . . . . . . . . . . . . . . . 35 Information . . . . . . . . . . . . . . . . . . . . . . . 39
5.3. Normalize the Message to Prevent Transport Conversions . . 35 5.3. Normalize the Message to Prevent Transport Conversions . . 39
5.4. Determine the Header Fields to Sign . . . . . . . . . . . 36 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 40
5.5. Recommended Signature Content . . . . . . . . . . . . . . 38 5.5. Recommended Signature Content . . . . . . . . . . . . . . 42
5.6. Compute the Message Hash and Signature . . . . . . . . . . 39 5.6. Compute the Message Hash and Signature . . . . . . . . . . 43
5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 40 5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 44
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 40 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 44
6.1. Extract Signatures from the Message . . . . . . . . . . . 41 6.1. Extract Signatures from the Message . . . . . . . . . . . 45
6.2. Communicate Verification Results . . . . . . . . . . . . . 46 6.2. Communicate Verification Results . . . . . . . . . . . . . 51
6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 47 6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 51
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 48 7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 52
7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 49 7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 53
7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 49 7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 53
7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 50 7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 54
7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 50 7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 55
7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 51 7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 55
7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 51 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 55
7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 52 7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 56
7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 52 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 56
8. Security Considerations . . . . . . . . . . . . . . . . . . . 52 8. Security Considerations . . . . . . . . . . . . . . . . . . . 56
8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 52 8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 56
8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 53 8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 57
8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 54 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 58
8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 54 8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 58
8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 55 8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 59
8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 55 8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 60
8.7. Intentionally Malformed Key Records . . . . . . . . . . . 56 8.7. Intentionally Malformed Key Records . . . . . . . . . . . 60
8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 56 8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 60
8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 56 8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 60
8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 56 8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 60
8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 56 8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 60
8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 56 8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 61
8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 57 8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 61
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61
9.1. Normative References . . . . . . . . . . . . . . . . . . . 57 9.1. Normative References . . . . . . . . . . . . . . . . . . . 61
9.2. Informative References . . . . . . . . . . . . . . . . . . 58 9.2. Informative References . . . . . . . . . . . . . . . . . . 62
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 60 Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 63
A.1. The user composes an email . . . . . . . . . . . . . . . . 60 A.1. The User Composes an Email . . . . . . . . . . . . . . . . 64
A.2. The email is signed . . . . . . . . . . . . . . . . . . . 61 A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 64
A.3. The email signature is verified . . . . . . . . . . . . . 61 A.3. The Email Signature is Verified . . . . . . . . . . . . . 65
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 62 Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 66
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 63 B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 66
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 65 B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 68
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 67 Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 70
Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 68 Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 71
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 69 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 72
Appendix F. RFC4871bis Changes . . . . . . . . . . . . . . . . . 73
F.1. TO DO . . . . . . . . . . . . . . . . . . . . . . . . . . 73
F.2. DONE . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 74
1. Introduction 1. Introduction
DomainKeys Identified Mail (DKIM) defines a mechanism by which email DomainKeys Identified Mail (DKIM) permits a person, role, or
messages can be cryptographically signed, permitting a signing domain organization that owns the signing domain to claim some
to claim responsibility for the introduction of a message into the responsibility for a message by associating the domain with the
mail stream. Message recipients can verify the signature by querying message. This can be an author's organization, an operational relay
the signer's domain directly to retrieve the appropriate public key, or one of their agents. Assertion of responsibility is validated
and thereby confirm that the message was attested to by a party in through a cryptographic signature and querying the signer's domain
possession of the private key for the signing 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. A message can contain multiple signatures, from the same
or different organizations involved with the message.
The approach taken by DKIM differs from previous approaches to The approach taken by DKIM differs from previous approaches to
message signing (e.g., Secure/Multipurpose Internet Mail Extensions message signing (e.g., Secure/Multipurpose Internet Mail Extensions
(S/MIME) [RFC1847], OpenPGP [RFC2440]) in that: (S/MIME) [RFC1847], OpenPGP [RFC2440]) in that:
o the message signature is written as a message header field so that o the message signature is written as a message header field so that
neither human recipients nor existing MUA (Mail User Agent) neither human recipients nor existing MUA (Mail User Agent)
software is confused by signature-related content appearing in the software is confused by signature-related content appearing in the
message body; message body;
skipping to change at page 5, line 42 skipping to change at page 6, line 43
requests the public key from a repository in the domain of the requests the public key from a repository in the domain of the
claimed signer directly rather than from a third party. claimed signer directly rather than from a third party.
The DNS is proposed as the initial mechanism for the public keys. The DNS is proposed as the initial mechanism for the public keys.
Thus, DKIM currently depends on DNS administration and the security Thus, DKIM currently depends on DNS administration and the security
of the DNS system. DKIM is designed to be extensible to other key of the DNS system. DKIM is designed to be extensible to other key
fetching services as they become available. fetching services as they become available.
2. Terminology and Definitions 2. Terminology and Definitions
This section defines terms used in the rest of the document. Syntax This section defines terms used in the rest of the document.
descriptions use the form described in Augmented BNF for Syntax
Specifications [RFC4234]. DKIM is designed to operate within the Internet Mail service, as
defined in [RFC5598]. Basic email terminology is taken from that
specification.
Syntax descriptions use Augmented BNF (ABNF) [RFC4234].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.1. Signers 2.1. Signers
Elements in the mail system that sign messages on behalf of a domain Elements in the mail system that sign messages on behalf of a domain
are referred to as signers. These may be MUAs (Mail User Agents), are referred to as signers. These may be MUAs (Mail User Agents),
MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other
skipping to change at page 6, line 38 skipping to change at page 7, line 42
(formal definition in [RFC4234]). (formal definition in [RFC4234]).
o LWSP is linear whitespace, defined as WSP plus CRLF (formal o LWSP is linear whitespace, defined as WSP plus CRLF (formal
definition in [RFC4234]). definition in [RFC4234]).
o FWS is folding whitespace. It allows multiple lines separated by o FWS is folding whitespace. It allows multiple lines separated by
CRLF followed by at least one whitespace, to be joined. CRLF followed by at least one whitespace, to be joined.
The formal ABNF for these are (WSP and LWSP are given for information The formal ABNF for these are (WSP and LWSP are given for information
only): only):
WSP = SP / HTAB
WSP = SP / HTAB LWSP = *(WSP / CRLF WSP)
LWSP = *(WSP / CRLF WSP) FWS = [*WSP CRLF] 1*WSP
FWS = [*WSP CRLF] 1*WSP
The definition of FWS is identical to that in [RFC2822] except for The definition of FWS is identical to that in [RFC2822] except for
the exclusion of obs-FWS. the exclusion of obs-FWS.
2.4. Common ABNF Tokens 2.4. Common ABNF Tokens
The following ABNF tokens are used elsewhere in this document: The following ABNF tokens are used elsewhere in this document:
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ]
base64string = 1*(ALPHA / DIGIT / "+" / "/" / [FWS]) ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/")
[ "=" [FWS] [ "=" [FWS] ] ] base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS)
[ [FWS] "=" [ [FWS] "=" ] ]
2.5. Imported ABNF Tokens 2.5. Imported ABNF Tokens
The following tokens are imported from other RFCs as noted. Those The following tokens are imported from other RFCs as noted. Those
RFCs should be considered definitive. RFCs should be considered definitive.
The following tokens are imported from [RFC2821]: The following tokens are imported from [RFC2821]:
o "Local-part" (implementation warning: this permits quoted strings) o "Local-part" (implementation warning: this permits quoted strings)
skipping to change at page 7, line 28 skipping to change at page 8, line 33
o "field-name" (name of a header field) o "field-name" (name of a header field)
o "dot-atom-text" (in the Local-part of an email address) o "dot-atom-text" (in the Local-part of an email address)
The following tokens are imported from [RFC2045]: The following tokens are imported from [RFC2045]:
o "qp-section" (a single line of quoted-printable-encoded text) o "qp-section" (a single line of quoted-printable-encoded text)
o "hex-octet" (a quoted-printable encoded octet) o "hex-octet" (a quoted-printable encoded octet)
INFORMATIVE NOTE: Be aware that the ABNF in RFC 2045 does not obey INFORMATIVE NOTE: Be aware that the ABNF in [RFC2045] does not
the rules of RFC 4234 and must be interpreted accordingly, obey the rules of [RFC4234] and must be interpreted accordingly,
particularly as regards case folding. particularly as regards case folding.
Other tokens not defined herein are imported from [RFC4234]. These Other tokens not defined herein are imported from [RFC4234]. These
are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF,
etc. etc.
2.6. DKIM-Quoted-Printable 2.6. DKIM-Quoted-Printable
The DKIM-Quoted-Printable encoding syntax resembles that described in The DKIM-Quoted-Printable encoding syntax resembles that described in
Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded
skipping to change at page 8, line 5 skipping to change at page 9, line 8
"0123456789ABCDEF" (no lowercase characters permitted) representing "0123456789ABCDEF" (no lowercase characters permitted) representing
the hexadecimal-encoded integer value of that character. All control the hexadecimal-encoded integer value of that character. All control
characters (those with values < %x20), 8-bit characters (values > characters (those with values < %x20), 8-bit characters (values >
%x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon %x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon
(";", %x3B) MUST be encoded. Note that all whitespace, including (";", %x3B) MUST be encoded. Note that all whitespace, including
SPACE, CR, and LF characters, MUST be encoded. After encoding, FWS SPACE, CR, and LF characters, MUST be encoded. After encoding, FWS
MAY be added at arbitrary locations in order to avoid excessively MAY be added at arbitrary locations in order to avoid excessively
long lines; such whitespace is NOT part of the value, and MUST be long lines; such whitespace is NOT part of the value, and MUST be
removed before decoding. removed before decoding.
ABNF: ABNF:
dkim-quoted-printable = *(FWS / hex-octet / dkim-safe-char)
dkim-quoted-printable = ; hex-octet is from RFC2045
*(FWS / hex-octet / dkim-safe-char) dkim-safe-char = %x21-3A / %x3C / %x3E-7E
; hex-octet is from RFC 2045 ; '!' - ':', '<', '>' - '~'
dkim-safe-char = %x21-3A / %x3C / %x3E-7E ; Characters not listed as "mail-safe" in
; '!' - ':', '<', '>' - '~' ; RFC2049 are also not recommended.
; Characters not listed as "mail-safe" in
; RFC 2049 are also not recommended.
INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted- INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted-
Printable as defined in RFC 2045 in several important ways: Printable as defined in [RFC2045] in several important ways:
1. Whitespace in the input text, including CR and LF, must be 1. Whitespace in the input text, including CR and LF, must be
encoded. RFC 2045 does not require such encoding, and does encoded. [RFC2045] does not require such encoding, and does
not permit encoding of CR or LF characters that are part of a not permit encoding of CR or LF characters that are part of a
CRLF line break. CRLF line break.
2. Whitespace in the encoded text is ignored. This is to allow 2. Whitespace in the encoded text is ignored. This is to allow
tags encoded using DKIM-Quoted-Printable to be wrapped as tags encoded using DKIM-Quoted-Printable to be wrapped as
needed. In particular, RFC 2045 requires that line breaks in needed. In particular, [RFC2045] requires that line breaks in
the input be represented as physical line breaks; that is not the input be represented as physical line breaks; that is not
the case here. the case here.
3. The "soft line break" syntax ("=" as the last non-whitespace 3. The "soft line break" syntax ("=" as the last non-whitespace
character on the line) does not apply. character on the line) does not apply.
4. DKIM-Quoted-Printable does not require that encoded lines be 4. DKIM-Quoted-Printable does not require that encoded lines be
no more than 76 characters long (although there may be other no more than 76 characters long (although there may be other
requirements depending on the context in which the encoded requirements depending on the context in which the encoded
text is being used). text is being used).
2.7. Identity
A person, role, or organization. In the context of DKIM, examples
include author, author's organization, an ISP along the handling
path, an independent trust assessment service, and a mailing list
operator.
2.8. Identifier
A label that refers to an identity.
2.9. Signing Domain Identifier (SDID)
A single domain name that is the mandatory payload output of DKIM and
that refers to the identity claiming responsibility for introduction
of a message into the mail stream. For DKIM processing, the name has
only basic domain name semantics; any possible owner-specific
semantics are outside the scope of DKIM. It is specified in
Section 3.5.
2.10. Agent or User Identifier (AUID)
A single identifier that refers to the agent or user on behalf of
whom the Signing Domain Identifier (SDID) has taken responsibility.
The AUID comprises a domain name and an optional <Local-part>. The
domain name is the same as that used for the SDID or is a sub-domain
of it. For DKIM processing, the domain name portion of the AUID has
only basic domain name semantics; any possible owner-specific
semantics are outside the scope of DKIM. It is specified in
Section 3.5 .
2.11. Identity Assessor
A module that consumes DKIM's mandatory payload, which is the
responsible Signing Domain Identifier (SDID). The module is
dedicated to the assessment of the delivered identifier. Other DKIM
(and non-DKIM) values can also be delivered to this module as well as
to a more general message evaluation filtering engine. However, this
additional activity is outside the scope of the DKIM signature
specification.
3. Protocol Elements 3. Protocol Elements
Protocol Elements are conceptual parts of the protocol that are not Protocol Elements are conceptual parts of the protocol that are not
specific to either signers or verifiers. The protocol descriptions specific to either signers or verifiers. The protocol descriptions
for signers and verifiers are described in later sections (Signer for signers and verifiers are described in later sections (Signer
Actions (Section 5) and Verifier Actions (Section 6)). NOTE: This Actions (Section 5) and Verifier Actions (Section 6)). NOTE: This
section must be read in the context of those sections. section must be read in the context of those sections.
3.1. Selectors 3.1. Selectors
skipping to change at page 9, line 27 skipping to change at page 11, line 27
mail submission agent for outgoing mail. mail submission agent for outgoing mail.
Periods are allowed in selectors and are component separators. When Periods are allowed in selectors and are component separators. When
keys are retrieved from the DNS, periods in selectors define DNS keys are retrieved from the DNS, periods in selectors define DNS
label boundaries in a manner similar to the conventional use in label boundaries in a manner similar to the conventional use in
domain names. Selector components might be used to combine dates domain names. Selector components might be used to combine dates
with locations, for example, "march2005.reykjavik". In a DNS with locations, for example, "march2005.reykjavik". In a DNS
implementation, this can be used to allow delegation of a portion of implementation, this can be used to allow delegation of a portion of
the selector namespace. the selector namespace.
ABNF: ABNF:
selector = sub-domain *( "." sub-domain )
selector = sub-domain *( "." sub-domain )
The number of public keys and corresponding selectors for each domain The number of public keys and corresponding selectors for each domain
is determined by the domain owner. Many domain owners will be is determined by the domain owner. Many domain owners will be
satisfied with just one selector, whereas administratively satisfied with just one selector, whereas administratively
distributed organizations may choose to manage disparate selectors distributed organizations may choose to manage disparate selectors
and key pairs in different regions or on different email servers. and key pairs in different regions or on different email servers.
Beyond administrative convenience, selectors make it possible to Beyond administrative convenience, selectors make it possible to
seamlessly replace public keys on a routine basis. If a domain seamlessly replace public keys on a routine basis. If a domain
wishes to change from using a public key associated with selector wishes to change from using a public key associated with selector
skipping to change at page 11, line 6 skipping to change at page 13, line 6
Unencoded semicolon (";") characters MUST NOT occur in the tag value, Unencoded semicolon (";") characters MUST NOT occur in the tag value,
since that separates tag-specs. since that separates tag-specs.
INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined
below (as "tag-value") only includes 7-bit characters, an below (as "tag-value") only includes 7-bit characters, an
implementation that wished to anticipate future standards would be implementation that wished to anticipate future standards would be
advised not to preclude the use of UTF8-encoded text in tag=value advised not to preclude the use of UTF8-encoded text in tag=value
lists. lists.
Formally, the syntax rules are as follows: Formally, the syntax rules are as follows:
tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ]
tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] tag-name = ALPHA 0*ALNUMPUNC
tag-name = ALPHA 0*ALNUMPUNC tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ]
tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ] ; WSP and FWS prohibited at beginning and end
; WSP and FWS prohibited at beginning and end tval = 1*VALCHAR
tval = 1*VALCHAR VALCHAR = %x21-3A / %x3C-7E
VALCHAR = %x21-3A / %x3C-7E ; EXCLAMATION to TILDE except SEMICOLON
; EXCLAMATION to TILDE except SEMICOLON ALNUMPUNC = ALPHA / DIGIT / "_"
ALNUMPUNC = ALPHA / DIGIT / "_"
Note that WSP is allowed anywhere around tags. In particular, any Note that WSP is allowed anywhere around tags. In particular, any
WSP after the "=" and any WSP before the terminating ";" is not part WSP after the "=" and any WSP before the terminating ";" is not part
of the value; however, WSP inside the value is significant. of the value; however, WSP inside the value is significant.
Tags MUST be interpreted in a case-sensitive manner. Values MUST be Tags MUST be interpreted in a case-sensitive manner. Values MUST be
processed as case sensitive unless the specific tag description of processed as case sensitive unless the specific tag description of
semantics specifies case insensitivity. semantics specifies case insensitivity.
Tags with duplicate names MUST NOT occur within a single tag-list; if Tags with duplicate names MUST NOT occur within a single tag-list; if
skipping to change at page 11, line 46 skipping to change at page 13, line 45
Tags that have an empty value are not the same as omitted tags. An Tags that have an empty value are not the same as omitted tags. An
omitted tag is treated as having the default value; a tag with an omitted tag is treated as having the default value; a tag with an
empty value explicitly designates the empty string as the value. For empty value explicitly designates the empty string as the value. For
example, "g=" does not mean "g=*", even though "g=*" is the default example, "g=" does not mean "g=*", even though "g=*" is the default
for that tag. for that tag.
3.3. Signing and Verification Algorithms 3.3. Signing and Verification Algorithms
DKIM supports multiple digital signature algorithms. Two algorithms DKIM supports multiple digital signature algorithms. Two algorithms
are defined by this specification at this time: rsa-sha1 and rsa- are defined by this specification at this time: rsa-sha1 and rsa-
sha256. The rsa-sha256 algorithm is the default if no algorithm is sha256. Signers MUST implement and SHOULD sign using rsa-sha256.
specified. Verifiers MUST implement both rsa-sha1 and rsa-sha256.
Signers MUST implement and SHOULD sign using rsa-sha256.
INFORMATIVE NOTE: Although sha256 is strongly encouraged, some INFORMATIVE NOTE: Although sha256 is strongly encouraged, some
senders of low-security messages (such as routine newsletters) may senders of low-security messages (such as routine newsletters) may
prefer to use sha1 because of reduced CPU requirements to compute prefer to use sha1 because of reduced CPU requirements to compute
a sha1 hash. In general, sha256 should always be used whenever a sha1 hash. In general, sha256 should always be used whenever
possible. possible.
3.3.1. The rsa-sha1 Signing Algorithm 3.3.1. The rsa-sha1 Signing Algorithm
The rsa-sha1 Signing Algorithm computes a message hash as described The rsa-sha1 Signing Algorithm computes a message hash as described
in Section 3.7 below using SHA-1 [FIPS.180-2.2002] as the hash-alg. in Section 3.7 below using SHA-1 [FIPS-180-2-2002] as the hash-alg.
That hash is then signed by the signer using the RSA algorithm That hash is then signed by the signer using the RSA algorithm
(defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the (defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the
signer's private key. The hash MUST NOT be truncated or converted signer's private key. The hash MUST NOT be truncated or converted
into any form other than the native binary form before being signed. into any form other than the native binary form before being signed.
The signing algorithm SHOULD use a public exponent of 65537. The signing algorithm SHOULD use a public exponent of 65537.
3.3.2. The rsa-sha256 Signing Algorithm 3.3.2. The rsa-sha256 Signing Algorithm
The rsa-sha256 Signing Algorithm computes a message hash as described The rsa-sha256 Signing Algorithm computes a message hash as described
in Section 3.7 below using SHA-256 [FIPS.180-2.2002] as the hash-alg. in Section 3.7 below using SHA-256 [FIPS-180-2-2002] as the hash-alg.
That hash is then signed by the signer using the RSA algorithm That hash is then signed by the signer using the RSA algorithm
(defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the (defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the
signer's private key. The hash MUST NOT be truncated or converted signer's private key. The hash MUST NOT be truncated or converted
into any form other than the native binary form before being signed. into any form other than the native binary form before being signed.
3.3.3. Key Sizes 3.3.3. Key Sizes
Selecting appropriate key sizes is a trade-off between cost, Selecting appropriate key sizes is a trade-off between cost,
performance, and risk. Since short RSA keys more easily succumb to performance, and risk. Since short RSA keys more easily succumb to
off-line attacks, signers MUST use RSA keys of at least 1024 bits for off-line attacks, signers MUST use RSA keys of at least 1024 bits for
skipping to change at page 13, line 19 skipping to change at page 15, line 12
See [RFC3766] for further discussion on selecting key sizes. See [RFC3766] for further discussion on selecting key sizes.
3.3.4. Other Algorithms 3.3.4. Other Algorithms
Other algorithms MAY be defined in the future. Verifiers MUST ignore Other algorithms MAY be defined in the future. Verifiers MUST ignore
any signatures using algorithms that they do not implement. any signatures using algorithms that they do not implement.
3.4. Canonicalization 3.4. Canonicalization
Empirical evidence demonstrates that some mail servers and relay Some mail systems modify email in transit, potentially invalidating a
systems modify email in transit, potentially invalidating a signature. For most signers, mild modification of email is
signature. There are two competing perspectives on such immaterial to validation of the DKIM domain name's use. For such
modifications. For most signers, mild modification of email is
immaterial to the authentication status of the email. For such
signers, a canonicalization algorithm that survives modest in-transit signers, a canonicalization algorithm that survives modest in-transit
modification is preferred. modification is preferred.
Other signers demand that any modification of the email, however Other signers demand that any modification of the email, however
minor, result in a signature verification failure. These signers minor, result in a signature verification failure. These signers
prefer a canonicalization algorithm that does not tolerate in-transit prefer a canonicalization algorithm that does not tolerate in-transit
modification of the signed email. modification of the signed email.
Some signers may be willing to accept modifications to header fields Some signers may be willing to accept modifications to header fields
that are within the bounds of email standards such as [RFC2822], but that are within the bounds of email standards such as [RFC2822], but
skipping to change at page 15, line 11 skipping to change at page 16, line 51
at the end of the message body. An empty line is a line of zero at the end of the message body. An empty line is a line of zero
length after removal of the line terminator. If there is no body or length after removal of the line terminator. If there is no body or
no trailing CRLF on the message body, a CRLF is added. It makes no no trailing CRLF on the message body, a CRLF is added. It makes no
other changes to the message body. In more formal terms, the other changes to the message body. In more formal terms, the
"simple" body canonicalization algorithm converts "0*CRLF" at the end "simple" body canonicalization algorithm converts "0*CRLF" at the end
of the body to a single "CRLF". of the body to a single "CRLF".
Note that a completely empty or missing body is canonicalized as a Note that a completely empty or missing body is canonicalized as a
single "CRLF"; that is, the canonicalized length will be 2 octets. single "CRLF"; that is, the canonicalized length will be 2 octets.
The sha1 value (in base64) for an empty body (canonicalized to a
"CRLF") is:
uoq1oCgLlTqpdDX/iUbLy7J1Wic=
The sha256 value is:
frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=
3.4.4. The "relaxed" Body Canonicalization Algorithm 3.4.4. The "relaxed" Body Canonicalization Algorithm
The "relaxed" body canonicalization algorithm: The "relaxed" body canonicalization algorithm MUST apply the
following steps (a) and (b) in order:
o Ignores all whitespace at the end of lines. Implementations MUST a. Reduce whitespace:
NOT remove the CRLF at the end of the line.
o Reduces all sequences of WSP within a line to a single SP * Ignore all whitespace at the end of lines. Implementations
character. MUST NOT remove the CRLF at the end of the line.
o Ignores all empty lines at the end of the message body. "Empty * Reduce all sequences of WSP within a line to a single SP
line" is defined in Section 3.4.3. character.
b. Ignore all empty lines at the end of the message body. "Empty
line" is defined in Section 3.4.3. If the body is non-empty, but
does not end with a CRLF, a CRLF is added. (For email, this is
only possible when using extensions to SMTP or non-SMTP transport
mechanisms.)
The sha1 value (in base64) for an empty body (canonicalized to a null
input) is:
2jmj7l5rSw0yVb/vlWAYkK/YBwk=
The sha256 value is:
47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
INFORMATIVE NOTE: It should be noted that the relaxed body INFORMATIVE NOTE: It should be noted that the relaxed body
canonicalization algorithm may enable certain types of extremely canonicalization algorithm may enable certain types of extremely
crude "ASCII Art" attacks where a message may be conveyed by crude "ASCII Art" attacks where a message may be conveyed by
adjusting the spacing between words. If this is a concern, the adjusting the spacing between words. If this is a concern, the
"simple" body canonicalization algorithm should be used instead. "simple" body canonicalization algorithm should be used instead.
3.4.5. Body Length Limits 3.4.5. Body Length Limits
A body length count MAY be specified to limit the signature A body length count MAY be specified to limit the signature
skipping to change at page 16, line 43 skipping to change at page 19, line 6
3.4.6. Canonicalization Examples (INFORMATIVE) 3.4.6. Canonicalization Examples (INFORMATIVE)
In the following examples, actual whitespace is used only for In the following examples, actual whitespace is used only for
clarity. The actual input and output text is designated using clarity. The actual input and output text is designated using
bracketed descriptors: "<SP>" for a space character, "<HTAB>" for a bracketed descriptors: "<SP>" for a space character, "<HTAB>" for a
tab character, and "<CRLF>" for a carriage-return/line-feed sequence. tab character, and "<CRLF>" for a carriage-return/line-feed sequence.
For example, "X <SP> Y" and "X<SP>Y" represent the same three For example, "X <SP> Y" and "X<SP>Y" represent the same three
characters. characters.
Example 1: A message reading: Example 1: A message reading:
A: <SP> X <CRLF>
A: <SP> X <CRLF> B <SP> : <SP> Y <HTAB><CRLF>
B <SP> : <SP> Y <HTAB><CRLF> <HTAB> Z <SP><SP><CRLF>
<HTAB> Z <SP><SP><CRLF> <CRLF>
<CRLF> <SP> C <SP><CRLF>
<SP> C <SP><CRLF> D <SP><HTAB><SP> E <CRLF>
D <SP><HTAB><SP> E <CRLF> <CRLF>
<CRLF> <CRLF>
<CRLF>
when canonicalized using relaxed canonicalization for both header and when canonicalized using relaxed canonicalization for both header and
body results in a header reading: body results in a header reading:
a:X <CRLF>
a:X <CRLF> b:Y <SP> Z <CRLF>
b:Y <SP> Z <CRLF>
and a body reading: and a body reading:
<SP> C <CRLF>
<SP> C <CRLF> D <SP> E <CRLF>
D <SP> E <CRLF>
Example 2: The same message canonicalized using simple Example 2: The same message canonicalized using simple
canonicalization for both header and body results in a header canonicalization for both header and body results in a header
reading: reading:
A: <SP> X <CRLF>
A: <SP> X <CRLF> B <SP> : <SP> Y <HTAB><CRLF>
B <SP> : <SP> Y <HTAB><CRLF> <HTAB> Z <SP><SP><CRLF>
<HTAB> Z <SP><SP><CRLF>
and a body reading: and a body reading:
<SP> C <SP><CRLF>
<SP> C <SP><CRLF> D <SP><HTAB><SP> E <CRLF>
D <SP><HTAB><SP> E <CRLF>
Example 3: When processed using relaxed header canonicalization and Example 3: When processed using relaxed header canonicalization and
simple body canonicalization, the canonicalized version has a header simple body canonicalization, the canonicalized version has a header
of: of:
a:X <CRLF>
a:X <CRLF> b:Y <SP> Z <CRLF>
b:Y <SP> Z <CRLF>
and a body reading: and a body reading:
<SP> C <SP><CRLF>
<SP> C <SP><CRLF> D <SP><HTAB><SP> E <CRLF>
D <SP><HTAB><SP> E <CRLF>
3.5. The DKIM-Signature Header Field 3.5. The DKIM-Signature Header Field
The signature of the email is stored in the DKIM-Signature header The signature of the email is stored in the DKIM-Signature header
field. This header field contains all of the signature and key- field. This header field contains all of the signature and key-
fetching data. The DKIM-Signature value is a tag-list as described fetching data. The DKIM-Signature value is a tag-list as described
in Section 3.2. in Section 3.2.
The DKIM-Signature header field SHOULD be treated as though it were a The DKIM-Signature header field SHOULD be treated as though it were a
trace header field as defined in Section 3.6 of [RFC2822], and hence trace header field as defined in Section 3.6 of [RFC2822], and hence
skipping to change at page 18, line 26 skipping to change at page 20, line 28
The encodings for each field type are listed below. Tags described The encodings for each field type are listed below. Tags described
as qp-section are encoded as described in Section 6.7 of MIME Part as qp-section are encoded as described in Section 6.7 of MIME Part
One [RFC2045], with the additional conversion of semicolon characters One [RFC2045], with the additional conversion of semicolon characters
to "=3B"; intuitively, this is one line of quoted-printable encoded to "=3B"; intuitively, this is one line of quoted-printable encoded
text. The dkim-quoted-printable syntax is defined in Section 2.6. text. The dkim-quoted-printable syntax is defined in Section 2.6.
Tags on the DKIM-Signature header field along with their type and Tags on the DKIM-Signature header field along with their type and
requirement status are shown below. Unrecognized tags MUST be requirement status are shown below. Unrecognized tags MUST be
ignored. ignored.
v= Version (MUST be included). This tag defines the version of this v= Version (MUST be included). This tag defines the version of this
specification that applies to the signature record. It MUST have specification that applies to the signature record. It MUST have
the value "1". Note that verifiers must do a string comparison the value "1". Note that verifiers must do a string comparison on
on this value; for example, "1" is not the same as "1.0". this value; for example, "1" is not the same as "1.0".
ABNF:
sig-v-tag = %x76 [FWS] "=" [FWS] "1"
INFORMATIVE NOTE: DKIM-Signature version numbers are expected
to increase arithmetically as new versions of this
specification are released.
a= The algorithm used to generate the signature (plain-text;
REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256";
signers SHOULD sign using "rsa-sha256". See Section 3.3 for a
description of algorithms.
ABNF:
sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg ABNF:
sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h sig-v-tag = %x76 [FWS] "=" [FWS] "1"
sig-a-tag-k = "rsa" / x-sig-a-tag-k
sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h
x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) ; for later extension
x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) ; for later extension
b= The signature data (base64; REQUIRED). Whitespace is ignored in INFORMATIVE NOTE: DKIM-Signature version numbers are expected
this value and MUST be ignored when reassembling the original to increase arithmetically as new versions of this
signature. In particular, the signing process can safely insert specification are released.
FWS in this value in arbitrary places to conform to line-length
limits. See Signer Actions (Section 5) for how the signature is
computed.
ABNF: a= The algorithm used to generate the signature (plain-text;
REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256";
signers SHOULD sign using "rsa-sha256". See Section 3.3 for a
description of algorithms.
sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data ABNF:
sig-b-tag-data = base64string a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg
sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h
sig-a-tag-k = "rsa" / x-sig-a-tag-k
sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h
x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) ; for later extension
x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) ; for later extension
bh= The hash of the canonicalized body part of the message as limited b= The signature data (base64; REQUIRED). Whitespace is ignored in
by the "l=" tag (base64; REQUIRED). Whitespace is ignored in this value and MUST be ignored when reassembling the original
this value and MUST be ignored when reassembling the original signature. In particular, the signing process can safely insert
signature. In particular, the signing process can safely insert FWS in this value in arbitrary places to conform to line-length
FWS in this value in arbitrary places to conform to line-length limits. See Signer Actions Section 5 for how the signature is
limits. See Section 3.7 for how the body hash is computed. computed.
ABNF: ABNF:
sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data
sig-b-tag-data = base64string
sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data bh= The hash of the canonicalized body part of the message as
sig-bh-tag-data = base64string limited by the "l=" tag (base64; REQUIRED). Whitespace is ignored
in this value and MUST be ignored when reassembling the original
signature. In particular, the signing process can safely insert
FWS in this value in arbitrary places to conform to line-length
limits. See Section 3.7 for how the body hash is computed.
c= Message canonicalization (plain-text; OPTIONAL, default is ABNF:
"simple/simple"). This tag informs the verifier of the type of sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data
canonicalization used to prepare the message for signing. It sig-bh-tag-data = base64string
consists of two names separated by a "slash" (%d47) character,
corresponding to the header and body canonicalization algorithms
respectively. These algorithms are described in Section 3.4. If
only one algorithm is named, that algorithm is used for the
header and "simple" is used for the body. For example,
"c=relaxed" is treated the same as "c=relaxed/simple".
ABNF: c= Message canonicalization (plain-text; OPTIONAL, default is
"simple/simple"). This tag informs the verifier of the type of
canonicalization used to prepare the message for signing. It
consists of two names separated by a "slash" (%d47) character,
corresponding to the header and body canonicalization algorithms
respectively. These algorithms are described in Section 3.4. If
only one algorithm is named, that algorithm is used for the header
and "simple" is used for the body. For example, "c=relaxed" is
treated the same as "c=relaxed/simple".
sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg ABNF:
sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg
["/" sig-c-tag-alg] ["/" sig-c-tag-alg]
sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg
x-sig-c-tag-alg = hyphenated-word ; for later extension x-sig-c-tag-alg = hyphenated-word ; for later extension
d= The domain of the signing entity (plain-text; REQUIRED). This is
the domain that will be queried for the public key. This domain
MUST be the same as or a parent domain of the "i=" tag (the
signing identity, as described below), or it MUST meet the
requirements for parent domain signing described in Section 3.8.
When presented with a signature that does not meet these
requirement, verifiers MUST consider the signature invalid.
Internationalized domain names MUST be encoded as described in
[RFC3490].
ABNF:
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name d= Specifies the SDID claiming responsibility for an introduction of
domain-name = sub-domain 1*("." sub-domain) a message into the mail stream (plain-text; REQUIRED). Hence, the
; from RFC 2821 Domain, but excluding address-literal SDID value is used to form the query for the public key. The SDID
MUST correspond to a valid DNS name under which the DKIM key
record is published. The conventions and semantics used by a
signer to create and use a specific SDID are outside the scope of
the DKIM Signing specification, as is any use of those conventions
and semantics. When presented with a signature that does not meet
these requirements, verifiers MUST consider the signature invalid.
h= Signed header fields (plain-text, but see description; REQUIRED). Internationalized domain names MUST be encoded as described in
A colon-separated list of header field names that identify the [RFC3490].
header fields presented to the signing algorithm. The field MUST
contain the complete list of header fields in the order presented
to the signing algorithm. The field MAY contain names of header
fields that do not exist when signed; nonexistent header fields
do not contribute to the signature computation (that is, they are
treated as the null input, including the header field name, the
separating colon, the header field value, and any CRLF
terminator). The field MUST NOT include the DKIM-Signature
header field that is being created or verified, but may include
others. Folding whitespace (FWS) MAY be included on either side
of the colon separator. Header field names MUST be compared
against actual header field names in a case-insensitive manner.
This list MUST NOT be empty. See Section 5.4 for a discussion of
choosing header fields to sign.
ABNF: ABNF:
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain) ; from
RFC 5321 Domain, but excluding address-literal
sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name h= Signed header fields (plain-text, but see description; REQUIRED).
0*( *FWS ":" *FWS hdr-name ) A colon-separated list of header field names that identify the
hdr-name = field-name header fields presented to the signing algorithm. The field MUST
contain the complete list of header fields in the order presented
to the signing algorithm. The field MAY contain names of header
fields that do not exist when signed; nonexistent header fields do
not contribute to the signature computation (that is, they are
treated as the null input, including the header field name, the
separating colon, the header field value, and any CRLF
terminator). The field MUST NOT include the DKIM-Signature header
field that is being created or verified, but may include others.
Folding whitespace (FWS) MAY be included on either side of the
colon separator. Header field names MUST be compared against
actual header field names in a case-insensitive manner. This list
MUST NOT be empty. See Section 5.4 for a discussion of choosing
header fields to sign.
INFORMATIVE EXPLANATION: By "signing" header fields that do not ABNF:
actually exist, a signer can prevent insertion of those sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name
header fields before verification. However, since a signer 0*( [FWS] ":" [FWS] hdr-name )
cannot possibly know what header fields might be created in
the future, and that some MUAs might present header fields
that are embedded inside a message (e.g., as a message/rfc822
content type), the security of this solution is not total.
INFORMATIVE EXPLANATION: The exclusion of the header field name INFORMATIVE EXPLANATION: By "signing" header fields that do not
and colon as well as the header field value for non-existent actually exist, a signer can prevent insertion of those header
header fields prevents an attacker from inserting an actual fields before verification. However, since a signer cannot
header field with a null value. possibly know what header fields might be created in the
future, and that some MUAs might present header fields that are
embedded inside a message (e.g., as a message/rfc822 content
type), the security of this solution is not total.
i= Identity of the user or agent (e.g., a mailing list manager) on INFORMATIVE EXPLANATION: The exclusion of the header field name
behalf of which this message is signed (dkim-quoted-printable; and colon as well as the header field value for non-existent
OPTIONAL, default is an empty Local-part followed by an "@" header fields prevents an attacker from inserting an actual
followed by the domain from the "d=" tag). The syntax is a header field with a null value.
standard email address where the Local-part MAY be omitted. The
domain part of the address MUST be the same as or a subdomain of
the value of the "d=" tag.
Internationalized domain names MUST be converted using the steps i= The Agent or User Identifier (AUID) on behalf of which the SDID is
listed in Section 4 of [RFC3490] using the "ToASCII" function. taking responsibility (dkim-quoted-printable; OPTIONAL, default is
an empty Local-part followed by an "@" followed by the domain from
the "d=" tag).
ABNF: The syntax is a standard email address where the Local-part MAY be
omitted. The domain part of the address MUST be the same as, or a
subdomain of the value of, the "d=" tag.
sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name Internationalized domain names MUST be converted using the steps
listed in Section 4 of [RFC3490] using the "ToASCII" function.
INFORMATIVE NOTE: The Local-part of the "i=" tag is optional ABNF:
because in some cases a signer may not be able to establish a sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ]
verified individual identity. In such cases, the signer may "@" domain-name
wish to assert that although it is willing to go as far as
signing for the domain, it is unable or unwilling to commit
to an individual user name within their domain. It can do so
by including the domain part but not the Local-part of the
identity.
INFORMATIVE DISCUSSION: This document does not require the value The AUID is specified as having the same syntax as an email
of the "i=" tag to match the identity in any message header address, but is not required to have the same semantics. Notably,
fields. This is considered to be a verifier policy issue. the domain name is not required to be registered in the DNS -- so
Constraints between the value of the "i=" tag and other it might not resolve in a query -- and the Local- part MAY be
identities in other header fields seek to apply basic drawn from a namespace that does not contain the user's mailbox.
authentication into the semantics of trust associated with a The details of the structure and semantics for the namespace are
role such as content author. Trust is a broad and complex determined by the Signer. Any knowledge or use of those details
topic and trust mechanisms are subject to highly creative by verifiers or assessors is outside the scope of the DKIM Signing
attacks. The real-world efficacy of any but the most basic specification. The Signer MAY choose to use the same namespace
bindings between the "i=" value and other identities is not for its AUIDs as its users' email addresses or MAY choose other
well established, nor is its vulnerability to subversion by means of representing its users. However, the signer SHOULD use
an attacker. Hence reliance on the use of these options the same AUID for each message intended to be evaluated as being
should be strictly limited. In particular, it is not at all within the same sphere of responsibility, if it wishes to offer
clear to what extent a typical end-user recipient can rely on receivers the option of using the AUID as a stable identifier that
any assurances that might be made by successful use of the is finer grained than the SDID.
"i=" options.
l= Body length count (plain-text unsigned decimal integer; OPTIONAL, INFORMATIVE NOTE: The Local-part of the "i=" tag is optional
default is entire body). This tag informs the verifier of the because, in some cases, a signer may not be able to establish a
number of octets in the body of the email after canonicalization verified individual identity. In such cases, the signer might
included in the cryptographic hash, starting from 0 immediately wish to assert that although it is willing to go as far as
following the CRLF preceding the body. This value MUST NOT be signing for the domain, it is unable or unwilling to commit to
larger than the actual number of octets in the canonicalized an individual user name within their domain. It can do so by
message body. including the domain part but not the Local-part of the
identity.
INFORMATIVE IMPLEMENTATION WARNING: Use of the "l=" tag might INFORMATIVE DISCUSSION: This specification does not require the
allow display of fraudulent content without appropriate value of the "i=" tag to match the identity in any message
warning to end users. The "l=" tag is intended for header fields. This is considered to be a verifier policy
increasing signature robustness when sending to mailing lists issue. Constraints between the value of the "i=" tag and other
that both modify their content and do not sign their identities in other header fields seek to apply basic
messages. However, using the "l=" tag enables attacks in authentication into the semantics of trust associated with a
which an intermediary with malicious intent modifies a role such as content author. Trust is a broad and complex
message to include content that solely benefits the attacker. topic and trust mechanisms are subject to highly creative
It is possible for the appended content to completely replace attacks. The real-world efficacy of any but the most basic
the original content in the end recipient's eyes and to bindings between the "i=" value and other identities is not
defeat duplicate message detection algorithms. Examples are well established, nor is its vulnerability to subversion by an
described in Security Considerations (Section 8). To avoid attacker. Hence reliance on the use of these options should be
this attack, signers should be extremely wary of using this strictly limited. In particular, it is not at all clear to
tag, and verifiers might wish to ignore the tag or remove what extent a typical end-user recipient can rely on any
text that appears after the specified content length. assurances that might be made by successful use of the "i="
options.
INFORMATIVE NOTE: The value of the "l=" tag is constrained to 76 l= Body length count (plain-text unsigned decimal integer; OPTIONAL,
decimal digits. This constraint is not intended to predict default is entire body). This tag informs the verifier of the
the size of future messages or to require implementations to number of octets in the body of the email after canonicalization
use an integer representation large enough to represent the included in the cryptographic hash, starting from 0 immediately
maximum possible value, but is intended to remind the following the CRLF preceding the body. This value MUST NOT be
implementer to check the length of this and all other tags larger than the actual number of octets in the canonicalized
during verification and to test for integer overflow when message body.
decoding the value. Implementers may need to limit the
actual value expressed to a value smaller than 10^76, e.g.,
to allow a message to fit within the available storage space.
ABNF: INFORMATIVE IMPLEMENTATION WARNING: Use of the "l=" tag might
allow display of fraudulent content without appropriate warning
to end users. The "l=" tag is intended for increasing
signature robustness when sending to mailing lists that both
modify their content and do not sign their messages. However,
using the "l=" tag enables attacks in which an intermediary
with malicious intent modifies a message to include content
that solely benefits the attacker. It is possible for the
appended content to completely replace the original content in
the end recipient's eyes and to defeat duplicate message
detection algorithms. Examples are described in Security
Considerations Section 8. To avoid this attack, signers should
be extremely wary of using this tag, and verifiers might wish
to ignore the tag or remove text that appears after the
specified content length.
sig-l-tag = %x6c [FWS] "=" [FWS] 1*76DIGIT INFORMATIVE NOTE: The value of the "l=" tag is constrained to
76 decimal digits. This constraint is not intended to predict
the size of future messages or to require implementations to
use an integer representation large enough to represent the
maximum possible value, but is intended to remind the
implementer to check the length of this and all other tags
during verification and to test for integer overflow when
decoding the value. Implementers may need to limit the actual
value expressed to a value smaller than 10^76, e.g., to allow a
message to fit within the available storage space.
q= A colon-separated list of query methods used to retrieve the ABNF:
public key (plain-text; OPTIONAL, default is "dns/txt"). Each sig-l-tag = %x6c [FWS] "=" [FWS]
query method is of the form "type[/options]", where the syntax 1*76DIGIT
and semantics of the options depend on the type and specified
options. If there are multiple query mechanisms listed, the
choice of query mechanism MUST NOT change the interpretation of
the signature. Implementations MUST use the recognized query
mechanisms in the order presented.
Currently, the only valid value is "dns/txt", which defines the DNS q= A colon-separated list of query methods used to retrieve the
TXT record lookup algorithm described elsewhere in this document. public key (plain-text; OPTIONAL, default is "dns/txt"). Each
The only option defined for the "dns" query type is "txt", which query method is of the form "type[/options]", where the syntax and
MUST be included. Verifiers and signers MUST support "dns/txt". semantics of the options depend on the type and specified options.
If there are multiple query mechanisms listed, the choice of query
mechanism MUST NOT change the interpretation of the signature.
Implementations MUST use the recognized query mechanisms in the
order presented. Unrecognized query mechanisms MUST be ignored.
ABNF: Currently, the only valid value is "dns/txt", which defines the
DNS TXT record lookup algorithm described elsewhere in this
document. The only option defined for the "dns" query type is
"txt", which MUST be included. Verifiers and signers MUST support
"dns/txt".
sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method ABNF:
*([FWS] ":" [FWS] sig-q-tag-method) sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method
sig-q-tag-method = "dns/txt" / x-sig-q-tag-type *([FWS] ":" [FWS] sig-q-tag-method)
sig-q-tag-method = "dns/txt" / x-sig-q-tag-type
["/" x-sig-q-tag-args] ["/" x-sig-q-tag-args]
x-sig-q-tag-type = hyphenated-word ; for future extension x-sig-q-tag-type = hyphenated-word ; for future extension
x-sig-q-tag-args = qp-hdr-value x-sig-q-tag-args = qp-hdr-value
s= The selector subdividing the namespace for the "d=" (domain) tag
(plain-text; REQUIRED).
ABNF:
sig-s-tag = %x73 [FWS] "=" [FWS] selector
t= Signature Timestamp (plain-text unsigned decimal integer; s= The selector subdividing the namespace for the "d=" (domain) tag
RECOMMENDED, default is an unknown creation time). The time that (plain-text; REQUIRED).
this signature was created. The format is the number of seconds
since 00:00:00 on January 1, 1970 in the UTC time zone. The
value is expressed as an unsigned integer in decimal ASCII. This
value is not constrained to fit into a 31- or 32-bit integer.
Implementations SHOULD be prepared to handle values up to at
least 10^12 (until approximately AD 200,000; this fits into 40
bits). To avoid denial-of-service attacks, implementations MAY
consider any value longer than 12 digits to be infinite. Leap
seconds are not counted. Implementations MAY ignore signatures
that have a timestamp in the future.
ABNF: ABNF:
sig-s-tag = %x73 [FWS] "=" [FWS] selector
sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT t= Signature Timestamp (plain-text unsigned decimal integer;
RECOMMENDED, default is an unknown creation time). The time that
this signature was created. The format is the number of seconds
since 00:00:00 on January 1, 1970 in the UTC time zone. The value
is expressed as an unsigned integer in decimal ASCII. This value
is not constrained to fit into a 31- or 32-bit integer.
Implementations SHOULD be prepared to handle values up to at least
10^12 (until approximately AD 200,000; this fits into 40 bits).
To avoid denial-of-service attacks, implementations MAY consider
any value longer than 12 digits to be infinite. Leap seconds are
not counted. Implementations MAY ignore signatures that have a
timestamp in the future.
x= Signature Expiration (plain-text unsigned decimal integer; ABNF:
RECOMMENDED, default is no expiration). The format is the same sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT
as in the "t=" tag, represented as an absolute date, not as a
time delta from the signing timestamp. The value is expressed as
an unsigned integer in decimal ASCII, with the same constraints
on the value in the "t=" tag. Signatures MAY be considered
invalid if the verification time at the verifier is past the
expiration date. The verification time should be the time that
the message was first received at the administrative domain of
the verifier if that time is reliably available; otherwise the
current time should be used. The value of the "x=" tag MUST be
greater than the value of the "t=" tag if both are present.
INFORMATIVE NOTE: The "x=" tag is not intended as an anti-replay x= Signature Expiration (plain-text unsigned decimal integer;
defense. RECOMMENDED, default is no expiration). The format is the same as
in the "t=" tag, represented as an absolute date, not as a time
delta from the signing timestamp. The value is expressed as an
unsigned integer in decimal ASCII, with the same constraints on
the value in the "t=" tag. Signatures MAY be considered invalid
if the verification time at the verifier is past the expiration
date. The verification time should be the time that the message
was first received at the administrative domain of the verifier if
that time is reliably available; otherwise the current time should
be used. The value of the "x=" tag MUST be greater than the value
of the "t=" tag if both are present.
ABNF: INFORMATIVE NOTE: The "x=" tag is not intended as an anti-
replay defense.
sig-x-tag = %x78 [FWS] "=" [FWS] 1*12DIGIT INFORMATIVE NOTE: Due to clock drift, the receiver's notion of
when to consider the signature expired may not match exactly
when the sender is expecting. Receivers MAY add a 'fudge
factor' to allow for such possible drift.
z= Copied header fields (dkim-quoted-printable, but see description; ABNF:
OPTIONAL, default is null). A vertical-bar-separated list of sig-x-tag = %x78 [FWS] "=" [FWS]
selected header fields present when the message was signed, 1*12DIGIT
including both the field name and value. It is not required to
include all header fields present at the time of signing. This
field need not contain the same header fields listed in the "h="
tag. The header field text itself must encode the vertical bar
("|", %x7C) character (i.e., vertical bars in the "z=" text are
metacharacters, and any actual vertical bar characters in a
copied header field must be encoded). Note that all whitespace
must be encoded, including whitespace between the colon and the
header field value. After encoding, FWS MAY be added at
arbitrary locations in order to avoid excessively long lines;
such whitespace is NOT part of the value of the header field, and
MUST be removed before decoding.
The header fields referenced by the "h=" tag refer to the fields in z= Copied header fields (dkim-quoted-printable, but see description;
the RFC 2822 header of the message, not to any copied fields in OPTIONAL, default is null). A vertical-bar-separated list of
the "z=" tag. Copied header field values are for diagnostic use. selected header fields present when the message was signed,
including both the field name and value. It is not required to
include all header fields present at the time of signing. This
field need not contain the same header fields listed in the "h="
tag. The header field text itself must encode the vertical bar
("|", %x7C) character (i.e., vertical bars in the "z=" text are
metacharacters, and any actual vertical bar characters in a copied
header field must be encoded). Note that all whitespace must be
encoded, including whitespace between the colon and the header
field value. After encoding, FWS MAY be added at arbitrary
locations in order to avoid excessively long lines; such
whitespace is NOT part of the value of the header field, and MUST
be removed before decoding.
Header fields with characters requiring conversion (perhaps from The header fields referenced by the "h=" tag refer to the fields
legacy MTAs that are not [RFC2822] compliant) SHOULD be converted in the [RFC2822] header of the message, not to any copied fields
as described in MIME Part Three [RFC2047]. in the "z=" tag. Copied header field values are for diagnostic
use.
ABNF: Header fields with characters requiring conversion (perhaps from
sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy legacy MTAs that are not [RFC2822] compliant) SHOULD be converted
*( [FWS] "|" sig-z-tag-copy ) as described in MIME Part Three [RFC2047].
sig-z-tag-copy = hdr-name ":" qp-hdr-value
qp-hdr-value = dkim-quoted-printable ; with "|" encoded
INFORMATIVE EXAMPLE of a signature header field spread across ABNF:
multiple continuation lines: sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy
*( "|" [FWS] sig-z-tag-copy )
sig-z-tag-copy = hdr-name [FWS] ":" qp-hdr-value
DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane; INFORMATIVE EXAMPLE of a signature header field spread across
multiple continuation lines:
DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;
c=simple; q=dns/txt; i=@eng.example.net; c=simple; q=dns/txt; i=@eng.example.net;
t=1117574938; x=1118006938; t=1117574938; x=1118006938;
h=from:to:subject:date; h=from:to:subject:date;
z=From:foo@eng.example.net|To:joe@example.com| z=From:foo@eng.example.net|To:joe@example.com|
Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700; Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR
VoG4ZHRNiYzR
3.6. Key Management and Representation 3.6. Key Management and Representation
Signature applications require some level of assurance that the Signature applications require some level of assurance that the
verification public key is associated with the claimed signer. Many verification public key is associated with the claimed signer. Many
applications achieve this by using public key certificates issued by applications achieve this by using public key certificates issued by
a trusted third party. However, DKIM can achieve a sufficient level a trusted third party. However, DKIM can achieve a sufficient level
of security, with significantly enhanced scalability, by simply of security, with significantly enhanced scalability, by simply
having the verifier query the purported signer's DNS entry (or some having the verifier query the purported signer's DNS entry (or some
security-equivalent) in order to retrieve the public key. security-equivalent) in order to retrieve the public key.
DKIM keys can potentially be stored in multiple types of key servers DKIM keys can potentially be stored in multiple types of key servers
and in multiple formats. The storage and format of keys are and in multiple formats. The storage and format of keys are
irrelevant to the remainder of the DKIM algorithm. irrelevant to the remainder of the DKIM algorithm.
Parameters to the key lookup algorithm are the type of the lookup Parameters to the key lookup algorithm are the type of the lookup
(the "q=" tag), the domain of the signer (the "d=" tag of the DKIM- (the "q=" tag), the domain of the signer (the "d=" tag of the DKIM-
Signature header field), and the selector (the "s=" tag). Signature header field), and the selector (the "s=" tag).
public_key = dkim_find_key(q_val, d_val, s_val)
public_key = dkim_find_key(q_val, d_val, s_val)
This document defines a single binding, using DNS TXT records to This document defines a single binding, using DNS TXT records to
distribute the keys. Other bindings may be defined in the future. distribute the keys. Other bindings may be defined in the future.
3.6.1. Textual Representation 3.6.1. Textual Representation
It is expected that many key servers will choose to present the keys It is expected that many key servers will choose to present the keys
in an otherwise unstructured text format (for example, an XML form in an otherwise unstructured text format (for example, an XML form
would not be considered to be unstructured text for this purpose). would not be considered to be unstructured text for this purpose).
The following definition MUST be used for any DKIM key represented in The following definition MUST be used for any DKIM key represented in
an otherwise unstructured textual form. an otherwise unstructured textual form.
The overall syntax is a tag-list as described in Section 3.2. The The overall syntax is a tag-list as described in Section 3.2. The
current valid tags are described below. Other tags MAY be present current valid tags are described below. Other tags MAY be present
and MUST be ignored by any implementation that does not understand and MUST be ignored by any implementation that does not understand
them. them.
v= Version of the DKIM key record (plain-text; RECOMMENDED, default v= Version of the DKIM key record (plain-text; RECOMMENDED, default
is "DKIM1"). If specified, this tag MUST be set to "DKIM1" is "DKIM1"). If specified, this tag MUST be set to "DKIM1"
(without the quotes). This tag MUST be the first tag in the (without the quotes). This tag MUST be the first tag in the
record. Records beginning with a "v=" tag with any other value record. Records beginning with a "v=" tag with any other value
MUST be discarded. Note that verifiers must do a string MUST be discarded. Note that verifiers must do a string
comparison on this value; for example, "DKIM1" is not the same as comparison on this value; for example, "DKIM1" is not the same as
"DKIM1.0". "DKIM1.0".
ABNF:
key-v-tag = %x76 [FWS] "=" [FWS] "DKIM1"
g= Granularity of the key (plain-text; OPTIONAL, default is "*").
This value MUST match the Local-part of the "i=" tag of the DKIM-
Signature header field (or its default value of the empty string
if "i=" is not specified), with a single, optional "*" character
matching a sequence of zero or more arbitrary characters
("wildcarding"). An email with a signing address that does not
match the value of this tag constitutes a failed verification.
The intent of this tag is to constrain which signing address can
legitimately use this selector, for example, when delegating a
key to a third party that should only be used for special
purposes. Wildcarding allows matching for addresses such as
"user+*" or "*-offer". An empty "g=" value never matches any
addresses.
ABNF: ABNF:
key-v-tag = %x76 [FWS] "=" [FWS] %x44 %x4B %x49 %x4D %x31
key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart g= Granularity of the key (plain-text; OPTIONAL, default is "*").
key-g-tag-lpart = [dot-atom-text] ["*" [dot-atom-text] ] This value MUST match the Local-part of the "i=" tag of the DKIM-
Signature header field (or its default value of the empty string
if "i=" is not specified), with a single, optional "*" character
matching a sequence of zero or more arbitrary characters
("wildcarding"). An email with a signing address that does not
match the value of this tag constitutes a failed verification.
The intent of this tag is to constrain which signing address can
legitimately use this selector, for example, when delegating a key
to a third party that should only be used for special purposes.
Wildcarding allows matching for addresses such as "user+*",
"*-offer" or "foo*bar". An empty "g=" value never matches any
addresses.
h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to ABNF:
allowing all algorithms). A colon-separated list of hash key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart
algorithms that might be used. Signers and Verifiers MUST key-g-tag-lpart = [dot-atom-text] ["*" [dot-atom-text] ]
support the "sha256" hash algorithm. Verifiers MUST also support
the "sha1" hash algorithm.
ABNF: h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
allowing all algorithms). A colon-separated list of hash
algorithms that might be used. Signers and Verifiers MUST support
the "sha256" hash algorithm. Verifiers MUST also support the
"sha1" hash algorithm. Unrecognized hash algorithms MUST be
ignored.
key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg ABNF:
key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg
0*( [FWS] ":" [FWS] key-h-tag-alg ) 0*( [FWS] ":" [FWS] key-h-tag-alg )
key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg
x-key-h-tag-alg = hyphenated-word ; for future extension x-key-h-tag-alg = hyphenated-word ; for future extension
k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and
verifiers MUST support the "rsa" key type. The "rsa" key type
indicates that an ASN.1 DER-encoded [ITU.X660.1997] RSAPublicKey
[RFC3447] (see Sections 3.1 and A.1.1) is being used in the "p="
tag. (Note: the "p=" tag further encodes the value using the
base64 algorithm.)
ABNF:
key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type
key-k-tag-type = "rsa" / x-key-k-tag-type
x-key-k-tag-type = hyphenated-word ; for future extension
n= Notes that might be of interest to a human (qp-section; OPTIONAL, k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and
default is empty). No interpretation is made by any program. verifiers MUST support the "rsa" key type. The "rsa" key type
This tag should be used sparingly in any key server mechanism indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey
that has space limitations (notably DNS). This is intended for [RFC3447] (see Sections Section 3.1 and A.1.1) is being used in
use by administrators, not end users. the "p=" tag. (Note: the "p=" tag further encodes the value using
the base64 algorithm.) Unrecognized key types MUST be ignored.
ABNF: ABNF:
key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type
key-k-tag-type = "rsa" / x-key-k-tag-type
x-key-k-tag-type = hyphenated-word ; for future extension
key-n-tag = %x6e [FWS] "=" [FWS] qp-section n= Notes that might be of interest to a human (qp-section; OPTIONAL,
default is empty). No interpretation is made by any program.
This tag should be used sparingly in any key server mechanism that
has space limitations (notably DNS). This is intended for use by
administrators, not end users.
p= Public-key data (base64; REQUIRED). An empty value means that ABNF:
this public key has been revoked. The syntax and semantics of key-n-tag = %x6e [FWS] "=" [FWS] qp-section
this tag value before being encoded in base64 are defined by the
"k=" tag.
INFORMATIVE RATIONALE: If a private key has been compromised p= Public-key data (base64; REQUIRED). An empty value means that
or otherwise disabled (e.g., an outsourcing contract has been this public key has been revoked. The syntax and semantics of
terminated), a signer might want to explicitly state that it this tag value before being encoded in base64 are defined by the
knows about the selector, but all messages using that "k=" tag.
selector should fail verification. Verifiers should ignore
any DKIM-Signature header fields with a selector referencing
a revoked key.
ABNF: INFORMATIVE RATIONALE: If a private key has been compromised or
otherwise disabled (e.g., an outsourcing contract has been
terminated), a signer might want to explicitly state that it
knows about the selector, but all messages using that selector
should fail verification. Verifiers should ignore any DKIM-
Signature header fields with a selector referencing a revoked
key.
key-p-tag = %x70 [FWS] "=" [ [FWS] base64string ] ABNF:
key-p-tag = %x70 [FWS] "=" [ [FWS] base64string]
INFORMATIVE NOTE: A base64string is permitted to include white INFORMATIVE NOTE: A base64string is permitted to include white
space (FWS) at arbitrary places; however, any CRLFs must be space (FWS) at arbitrary places; however, any CRLFs must be
followed by at least one WSP character. Implementors and followed by at least one WSP character. Implementors and
administrators are cautioned to ensure that selector TXT administrators are cautioned to ensure that selector TXT
records conform to this specification. records conform to this specification.
s= Service Type (plain-text; OPTIONAL; default is "*"). A colon- s= Service Type (plain-text; OPTIONAL; default is "*"). A colon-
separated list of service types to which this record applies. separated list of service types to which this record applies.
Verifiers for a given service type MUST ignore this record if the Verifiers for a given service type MUST ignore this record if the
appropriate type is not listed. Currently defined service types appropriate type is not listed. Unrecognized service types MUST
are as follows: be ignored. Currently defined service types are as follows:
* matches all service types * matches all service types
email electronic mail (not necessarily limited to SMTP) email electronic mail (not necessarily limited to SMTP)
This tag is intended to constrain the use of keys for other This tag is intended to constrain the use of keys for other
purposes, should use of DKIM be defined by other services in the purposes, should use of DKIM be defined by other services in the
future. future.
ABNF: ABNF:
key-s-tag = %x73 [FWS] "=" [FWS] key-s-tag-type
0*( [FWS] ":" [FWS] key-s-tag-type )
key-s-tag-type = "email" / "*" / x-key-s-tag-type
x-key-s-tag-type = hyphenated-word ; for future extension
key-s-tag = %x73 [FWS] "=" [FWS] key-s-tag-type t= Flags, represented as a colon-separated list of names (plain-
0*( [FWS] ":" [FWS] key-s-tag-type ) text; OPTIONAL, default is no flags set). Unrecognized flags MUST
key-s-tag-type = "email" / "*" / x-key-s-tag-type be ignored. The defined flags are as follows:
x-key-s-tag-type = hyphenated-word ; for future extension
t= Flags, represented as a colon-separated list of names (plain- y This domain is testing DKIM. Verifiers MUST NOT treat messages
text; OPTIONAL, default is no flags set). The defined flags are from signers in testing mode differently from unsigned email, even
as follows: should the signature fail to verify. Verifiers MAY wish to track
testing mode results to assist the signer.
y This domain is testing DKIM. Verifiers MUST NOT treat s Any DKIM-Signature header fields using the "i=" tag MUST have the
messages from signers in testing mode differently from same domain value on the right-hand side of the "@" in the "i="
unsigned email, even should the signature fail to verify. tag and the value of the "d=" tag. That is, the "i=" domain MUST
Verifiers MAY wish to track testing mode results to assist NOT be a subdomain of "d=". Use of this flag is RECOMMENDED
the signer. unless subdomaining is required.
s Any DKIM-Signature header fields using the "i=" tag MUST have ABNF:
the same domain value on the right-hand side of the "@" in key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag
the "i=" tag and the value of the "d=" tag. That is, the 0*( [FWS] ":" [FWS] key-t-tag-flag )
"i=" domain MUST NOT be a subdomain of "d=". Use of this key-t-tag-flag = "y" / "s" / x-key-t-tag-flag
flag is RECOMMENDED unless subdomaining is required. x-key-t-tag-flag = hyphenated-word ; for future extension
ABNF: Unrecognized flags MUST be ignored.
key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag 3.6.1.1. Compatibility Note for DomainKeys
0*( [FWS] ":" [FWS] key-t-tag-flag )
key-t-tag-flag = "y" / "s" / x-key-t-tag-flag
x-key-t-tag-flag = hyphenated-word ; for future extension
Unrecognized flags MUST be ignored. If a v= value is not found at the beginning of the DKIM key record,
the key record MAY be interpreted as for DomainKeys [RFC4870]. The
definition given here is upwardly compatible with what is used for
DomainKeys, with the exception of the "g=" value. In a DomainKeys
key record, an empty "g=" value would be interpreted as being
equivalent to DKIM's "g=*".
3.6.2. DNS Binding 3.6.2. DNS Binding
A binding using DNS TXT records as a key service is hereby defined. A binding using DNS TXT records as a key service is hereby defined.
All implementations MUST support this binding. All implementations MUST support this binding.
3.6.2.1. Namespace 3.6.2.1. Namespace
All DKIM keys are stored in a subdomain named "_domainkey". Given a All DKIM keys are stored in a subdomain named "_domainkey". Given a
DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag
skipping to change at page 29, line 34 skipping to change at page 33, line 17
The DNS Resource Record type used is specified by an option to the The DNS Resource Record type used is specified by an option to the
query-type ("q=") tag. The only option defined in this base query-type ("q=") tag. The only option defined in this base
specification is "txt", indicating the use of a TXT Resource Record specification is "txt", indicating the use of a TXT Resource Record
(RR). A later extension of this standard may define another RR type. (RR). A later extension of this standard may define another RR type.
Strings in a TXT RR MUST be concatenated together before use with no Strings in a TXT RR MUST be concatenated together before use with no
intervening whitespace. TXT RRs MUST be unique for a particular intervening whitespace. TXT RRs MUST be unique for a particular
selector name; that is, if there are multiple records in an RRset, selector name; that is, if there are multiple records in an RRset,
the results are undefined. the results are undefined.
TXT RRs are encoded as described in Section 3.6.1. TXT RRs are encoded as described in Section 3.6.1
3.7. Computing the Message Hashes 3.7. Computing the Message Hashes
Both signing and verifying message signatures start with a step of Both signing and verifying message signatures start with a step of
computing two cryptographic hashes over the message. Signers will computing two cryptographic hashes over the message. Signers will
choose the parameters of the signature as described in Signer Actions choose the parameters of the signature as described in Signer Actions
(Section 5); verifiers will use the parameters specified in the DKIM- Section 5; verifiers will use the parameters specified in the DKIM-
Signature header field being verified. In the following discussion, Signature header field being verified. In the following discussion,
the names of the tags in the DKIM-Signature header field that either the names of the tags in the DKIM-Signature header field that either
exists (when verifying) or will be created (when signing) are used. exists (when verifying) or will be created (when signing) are used.
Note that canonicalization (Section 3.4) is only used to prepare the Note that canonicalization (Section 3.4) is only used to prepare the
email for signing or verifying; it does not affect the transmitted email for signing or verifying; it does not affect the transmitted
email in any way. email in any way.
The signer/verifier MUST compute two hashes, one over the body of the The signer/verifier MUST compute two hashes, one over the body of the
message and one over the selected header fields of the message. message and one over the selected header fields of the message.
skipping to change at page 30, line 27 skipping to change at page 34, line 8
In hash step 2, the signer/verifier MUST pass the following to the In hash step 2, the signer/verifier MUST pass the following to the
hash algorithm in the indicated order. hash algorithm in the indicated order.
1. The header fields specified by the "h=" tag, in the order 1. The header fields specified by the "h=" tag, in the order
specified in that tag, and canonicalized using the header specified in that tag, and canonicalized using the header
canonicalization algorithm specified in the "c=" tag. Each canonicalization algorithm specified in the "c=" tag. Each
header field MUST be terminated with a single CRLF. header field MUST be terminated with a single CRLF.
2. The DKIM-Signature header field that exists (verifying) or will 2. The DKIM-Signature header field that exists (verifying) or will
be inserted (signing) in the message, with the value of the "b=" be inserted (signing) in the message, with the value of the "b="
tag deleted (i.e., treated as the empty string), canonicalized tag (including all surrounding whitespace) deleted (i.e., treated
using the header canonicalization algorithm specified in the "c=" as the empty string), canonicalized using the header
tag, and without a trailing CRLF. canonicalization algorithm specified in the "c=" tag, and without
a trailing CRLF.
All tags and their values in the DKIM-Signature header field are All tags and their values in the DKIM-Signature header field are
included in the cryptographic hash with the sole exception of the included in the cryptographic hash with the sole exception of the
value portion of the "b=" (signature) tag, which MUST be treated as value portion of the "b=" (signature) tag, which MUST be treated as
the null string. All tags MUST be included even if they might not be the null string. All tags MUST be included even if they might not be
understood by the verifier. The header field MUST be presented to understood by the verifier. The header field MUST be presented to
the hash algorithm after the body of the message rather than with the the hash algorithm after the body of the message rather than with the
rest of the header fields and MUST be canonicalized as specified in rest of the header fields and MUST be canonicalized as specified in
the "c=" (canonicalization) tag. The DKIM-Signature header field the "c=" (canonicalization) tag. The DKIM-Signature header field
MUST NOT be included in its own h= tag, although other DKIM-Signature MUST NOT be included in its own h= tag, although other DKIM-Signature
skipping to change at page 31, line 10 skipping to change at page 34, line 41
marker, as specified in [RFC2821]). marker, as specified in [RFC2821]).
With the exception of the canonicalization procedure described in With the exception of the canonicalization procedure described in
Section 3.4, the DKIM signing process treats the body of messages as Section 3.4, the DKIM signing process treats the body of messages as
simply a string of octets. DKIM messages MAY be either in plain-text simply a string of octets. DKIM messages MAY be either in plain-text
or in MIME format; no special treatment is afforded to MIME content. or in MIME format; no special treatment is afforded to MIME content.
Message attachments in MIME format MUST be included in the content Message attachments in MIME format MUST be included in the content
that is signed. that is signed.
More formally, the algorithm for the signature is as follows: More formally, the algorithm for the signature is as follows:
body-hash = hash-alg(canon_body) body-hash = hash-alg(canon_body)
header-hash = hash-alg(canon_header || DKIM-SIG) header-hash = hash-alg(canon_header || DKIM-SIG)
signature = sig-alg(header-hash, key) signature = sig-alg(header-hash, key)
where "sig-alg" is the signature algorithm specified by the "a=" tag, where "sig-alg" is the signature algorithm specified by the "a=" tag,
"hash-alg" is the hash algorithm specified by the "a=" tag, "hash-alg" is the hash algorithm specified by the "a=" tag,
"canon_header" and "canon_body" are the canonicalized message header "canon_header" and "canon_body" are the canonicalized message header
and body (respectively) as defined in Section 3.4 (excluding the and body (respectively) as defined in Section 3.4 (excluding the
DKIM-Signature header field), and "DKIM-SIG" is the canonicalized DKIM-Signature header field), and "DKIM-SIG" is the canonicalized
DKIM-Signature header field sans the signature value itself, but with DKIM-Signature header field sans the signature value itself, but with
"body-hash" included as the "bh=" tag. "body-hash" included as the "bh=" tag.
INFORMATIVE IMPLEMENTERS' NOTE: Many digital signature APIs INFORMATIVE IMPLEMENTERS' NOTE: Many digital signature APIs
skipping to change at page 31, line 35 skipping to change at page 35, line 18
steps in the algorithm would probably be combined into a single steps in the algorithm would probably be combined into a single
call that would perform both the "hash-alg" and the "sig-alg". call that would perform both the "hash-alg" and the "sig-alg".
3.8. Signing by Parent Domains 3.8. Signing by Parent Domains
In some circumstances, it is desirable for a domain to apply a In some circumstances, it is desirable for a domain to apply a
signature on behalf of any of its subdomains without the need to signature on behalf of any of its subdomains without the need to
maintain separate selectors (key records) in each subdomain. By maintain separate selectors (key records) in each subdomain. By
default, private keys corresponding to key records can be used to default, private keys corresponding to key records can be used to
sign messages for any subdomain of the domain in which they reside; sign messages for any subdomain of the domain in which they reside;
e.g., a key record for the domain example.com can be used to verify for example, a key record for the domain example.com can be used to
messages where the signing identity ("i=" tag of the signature) is verify messages where the AUID ("i=" tag of the signature) is
sub.example.com, or even sub1.sub2.example.com. In order to limit sub.example.com, or even sub1.sub2.example.com. In order to limit
the capability of such keys when this is not intended, the "s" flag the capability of such keys when this is not intended, the "s" flag
may be set in the "t=" tag of the key record to constrain the MAY be set in the "t=" tag of the key record, to constrain the
validity of the record to exactly the domain of the signing identity. validity of the domain of the AUID. If the referenced key record
If the referenced key record contains the "s" flag as part of the contains the "s" flag as part of the "t=" tag, the domain of the AUID
"t=" tag, the domain of the signing identity ("i=" flag) MUST be the ("i=" flag) MUST be the same as that of the SDID (d=) domain. If
same as that of the d= domain. If this flag is absent, the domain of this flag is absent, the domain of the AUID MUST be the same as, or a
the signing identity MUST be the same as, or a subdomain of, the d= subdomain of, the SDID.
domain. Key records that are not intended for use with subdomains
SHOULD specify the "s" flag in the "t=" tag. 3.9. Relationship between SDID and AUID
DKIM's primary task is to communicate from the Signer to a recipient-
side Identity Assessor a single Signing Domain Identifier (SDID) that
refers to a responsible identity. DKIM MAY optionally provide a
single responsible Agent or User Identifier (AUID).
Hence, DKIM's mandatory output to a receive-side Identity Assessor is
a single domain name. Within the scope of its use as DKIM output,
the name has only basic domain name semantics; any possible owner-
specific semantics are outside the scope of DKIM. That is, within
its role as a DKIM identifier, additional semantics cannot be assumed
by an Identity Assessor.
A receive-side DKIM verifier MUST communicate the Signing Domain
Identifier (d=) to a consuming Identity Assessor module and MAY
communicate the Agent or User Identifier (i=) if present.
To the extent that a receiver attempts to intuit any structured
semantics for either of the identifiers, this is a heuristic function
that is outside the scope of DKIM's specification and semantics.
Hence, it is relegated to a higher-level service, such as a delivery
handling filter that integrates a variety of inputs and performs
heuristic analysis of them.
INFORMATIVE DISCUSSION: This document does not require the value
of the SDID or AUID to match the identifier in any other message
header field. This requirement is, instead, an assessor policy
issue. The purpose of such a linkage would be to authenticate the
value in that other header field. This, in turn, is the basis for
applying a trust assessment based on the identifier value. Trust
is a broad and complex topic and trust mechanisms are subject to
highly creative attacks. The real-world efficacy of any but the
most basic bindings between the SDID or AUID and other identities
is not well established, nor is its vulnerability to subversion by
an attacker. Hence, reliance on the use of such bindings should
be strictly limited. In particular, it is not at all clear to
what extent a typical end-user recipient can rely on any
assurances that might be made by successful use of the SDID or
AUID.
4. Semantics of Multiple Signatures 4. Semantics of Multiple Signatures
4.1. Example Scenarios 4.1. Example Scenarios
There are many reasons why a message might have multiple signatures. There are many reasons why a message might have multiple signatures.
For example, a given signer might sign multiple times, perhaps with For example, a given signer might sign multiple times, perhaps with
different hashing or signing algorithms during a transition phase. different hashing or signing algorithms during a transition phase.
INFORMATIVE EXAMPLE: Suppose SHA-256 is in the future found to be INFORMATIVE EXAMPLE: Suppose SHA-256 is in the future found to be
skipping to change at page 35, line 32 skipping to change at page 39, line 50
key should be retained for a reasonable validation interval before key should be retained for a reasonable validation interval before
being removed from the key server. being removed from the key server.
5.3. Normalize the Message to Prevent Transport Conversions 5.3. Normalize the Message to Prevent Transport Conversions
Some messages, particularly those using 8-bit characters, are subject Some messages, particularly those using 8-bit characters, are subject
to modification during transit, notably conversion to 7-bit form. to modification during transit, notably conversion to 7-bit form.
Such conversions will break DKIM signatures. In order to minimize Such conversions will break DKIM signatures. In order to minimize
the chances of such breakage, signers SHOULD convert the message to a the chances of such breakage, signers SHOULD convert the message to a
suitable MIME content transfer encoding such as quoted-printable or suitable MIME content transfer encoding such as quoted-printable or
base64 as described in MIME Part One [RFC2045] before signing. Such base64 as described in [RFC2045] before signing. Such conversion is
conversion is outside the scope of DKIM; the actual message SHOULD be outside the scope of DKIM; the actual message SHOULD be converted to
converted to 7-bit MIME by an MUA or MSA prior to presentation to the 7-bit MIME by an MUA or MSA prior to presentation to the DKIM
DKIM algorithm. algorithm.
If the message is submitted to the signer with any local encoding If the message is submitted to the signer with any local encoding
that will be modified before transmission, that modification to that will be modified before transmission, that modification to
canonical [RFC2822] form MUST be done before signing. In particular, canonical [RFC2822] form MUST be done before signing. In particular,
bare CR or LF characters (used by some systems as a local line bare CR or LF characters (used by some systems as a local line
separator convention) MUST be converted to the SMTP-standard CRLF separator convention) MUST be converted to the SMTP-standard CRLF
sequence before the message is signed. Any conversion of this sort sequence before the message is signed. Any conversion of this sort
SHOULD be applied to the message actually sent to the recipient(s), SHOULD be applied to the message actually sent to the recipient(s),
not just to the version presented to the signing algorithm. not just to the version presented to the signing algorithm.
skipping to change at page 37, line 20 skipping to change at page 41, line 33
DKIM-Signature header field, and MUST sign such header fields in DKIM-Signature header field, and MUST sign such header fields in
order from the bottom of the header field block to the top. The order from the bottom of the header field block to the top. The
signer MAY include more instances of a header field name in h= than signer MAY include more instances of a header field name in h= than
there are actual corresponding header fields to indicate that there are actual corresponding header fields to indicate that
additional header fields of that name SHOULD NOT be added. additional header fields of that name SHOULD NOT be added.
INFORMATIVE EXAMPLE: INFORMATIVE EXAMPLE:
If the signer wishes to sign two existing Received header fields, If the signer wishes to sign two existing Received header fields,
and the existing header contains: and the existing header contains:
Received: <A>
Received: <A> Received: <B>
Received: <B> Received: <c>
Received: <C>
then the resulting DKIM-Signature header field should read: then the resulting DKIM-Signature header field should read:
DKIM-Signature: ... h=Received : Received : ... DKIM-Signature: ... h=Received : Received :...
and Received header fields <C> and <B> will be signed in that and Received header fields <C> and <B> will be signed in that
order. order.
Signers should be careful of signing header fields that might have Signers should be careful of signing header fields that might have
additional instances added later in the delivery process, since such additional instances added later in the delivery process, since such
header fields might be inserted after the signed instance or header fields might be inserted after the signed instance or
otherwise reordered. Trace header fields (such as Received) and otherwise reordered. Trace header fields (such as Received) and
Resent-* blocks are the only fields prohibited by [RFC2822] from Resent-* blocks are the only fields prohibited by [RFC2822] from
being reordered. In particular, since DKIM-Signature header fields being reordered. In particular, since DKIM-Signature header fields
may be reordered by some intermediate MTAs, signing existing DKIM- may be reordered by some intermediate MTAs, signing existing DKIM-
skipping to change at page 46, line 43 skipping to change at page 51, line 12
correctly formed, this will appear in the postlude and will not be correctly formed, this will appear in the postlude and will not be
displayed to the end user. displayed to the end user.
6.2. Communicate Verification Results 6.2. Communicate Verification Results
Verifiers wishing to communicate the results of verification to other Verifiers wishing to communicate the results of verification to other
parts of the mail system may do so in whatever manner they see fit. parts of the mail system may do so in whatever manner they see fit.
For example, implementations might choose to add an email header For example, implementations might choose to add an email header
field to the message before passing it on. Any such header field field to the message before passing it on. Any such header field
SHOULD be inserted before any existing DKIM-Signature or preexisting SHOULD be inserted before any existing DKIM-Signature or preexisting
authentication status header fields in the header field block. authentication status header fields in the header field block. The
Authentication-Results: header ([RFC5451]) MAY be used for this
purpose.
INFORMATIVE ADVICE to MUA filter writers: Patterns intended to INFORMATIVE ADVICE to MUA filter writers: Patterns intended to
search for results header fields to visibly mark authenticated search for results header fields to visibly mark authenticated
mail for end users should verify that such header field was added mail for end users should verify that such header field was added
by the appropriate verifying domain and that the verified identity by the appropriate verifying domain and that the verified identity
matches the author identity that will be displayed by the MUA. In matches the author identity that will be displayed by the MUA. In
particular, MUA filters should not be influenced by bogus results particular, MUA filters should not be influenced by bogus results
header fields added by attackers. To circumvent this attack, header fields added by attackers. To circumvent this attack,
verifiers may wish to delete existing results header fields after verifiers may wish to delete existing results header fields after
verification and before adding a new header field. verification and before adding a new header field.
6.3. Interpret Results/Apply Local Policy 6.3. Interpret Results/Apply Local Policy
It is beyond the scope of this specification to describe what actions It is beyond the scope of this specification to describe what actions
a verifier system should make, but an authenticated email presents an an Identity Assessor can make, but mail carrying a validated SDID
opportunity to a receiving system that unauthenticated email cannot. presents an opportunity to an Identity Assessor that unauthenticated
Specifically, an authenticated email creates a predictable identifier email does not. Specifically, an authenticated email creates a
by which other decisions can reliably be managed, such as trust and predictable identifier by which other decisions can reliably be
reputation. Conversely, unauthenticated email lacks a reliable managed, such as trust and reputation. Conversely, unauthenticated
identifier that can be used to assign trust and reputation. It is email lacks a reliable identifier that can be used to assign trust
reasonable to treat unauthenticated email as lacking any trust and and reputation. It is reasonable to treat unauthenticated email as
having no positive reputation. lacking any trust and having no positive reputation.
In general, verifiers SHOULD NOT reject messages solely on the basis In general, verifiers SHOULD NOT reject messages solely on the basis
of a lack of signature or an unverifiable signature; such rejection of a lack of signature or an unverifiable signature; such rejection
would cause severe interoperability problems. However, if the would cause severe interoperability problems. However, if the
verifier does opt to reject such messages (for example, when verifier does opt to reject such messages (for example, when
communicating with a peer who, by prior agreement, agrees to only communicating with a peer who, by prior agreement, agrees to only
send signed messages), and the verifier runs synchronously with the send signed messages), and the verifier runs synchronously with the
SMTP session and a signature is missing or does not verify, the MTA SMTP session and a signature is missing or does not verify, the MTA
SHOULD use a 550/5.7.x reply code. SHOULD use a 550/5.7.x reply code.
If it is not possible to fetch the public key, perhaps because the If it is not possible to fetch the public key, perhaps because the
key server is not available, a temporary failure message MAY be key server is not available, a temporary failure message MAY be
generated using a 451/4.7.5 reply code, such as: generated using a 451/4.7.5 reply code, such as:
451 4.7.5 Unable to verify signature - key server unavailable
451 4.7.5 Unable to verify signature - key server unavailable
Temporary failures such as inability to access the key server or Temporary failures such as inability to access the key server or
other external service are the only conditions that SHOULD use a 4xx other external service are the only conditions that SHOULD use a 4xx
SMTP reply code. In particular, cryptographic signature verification SMTP reply code. In particular, cryptographic signature verification
failures MUST NOT return 4xx SMTP replies. failures MUST NOT return 4xx SMTP replies.
Once the signature has been verified, that information MUST be Once the signature has been verified, that information MUST be
conveyed to higher-level systems (such as explicit allow/whitelists conveyed to the Identity Assessor (such as an explicit allow/
and reputation systems) and/or to the end user. If the message is whitelist and reputation system) and/or to the end user. If the SDID
signed on behalf of any address other than that in the From: header is not the same as the address in the From: header field, the mail
field, the mail system SHOULD take pains to ensure that the actual system SHOULD take pains to ensure that the actual SDID is clear to
signing identity is clear to the reader. the reader.
The verifier MAY treat unsigned header fields with extreme The verifier MAY treat unsigned header fields with extreme
skepticism, including marking them as untrusted or even deleting them skepticism, including marking them as untrusted or even deleting them
before display to the end user. before display to the end user.
While the symptoms of a failed verification are obvious -- the While the symptoms of a failed verification are obvious -- the
signature doesn't verify -- establishing the exact cause can be more signature doesn't verify -- establishing the exact cause can be more
difficult. If a selector cannot be found, is that because the difficult. If a selector cannot be found, is that because the
selector has been removed, or was the value changed somehow in selector has been removed, or was the value changed somehow in
transit? If the signature line is missing, is that because it was transit? If the signature line is missing, is that because it was
skipping to change at page 48, line 30 skipping to change at page 52, line 44
IANA. In all cases, new values are assigned only for values that IANA. In all cases, new values are assigned only for values that
have been documented in a published RFC that has IETF Consensus have been documented in a published RFC that has IETF Consensus
[RFC2434]. [RFC2434].
7.1. DKIM-Signature Tag Specifications 7.1. DKIM-Signature Tag Specifications
A DKIM-Signature provides for a list of tag specifications. IANA has A DKIM-Signature provides for a list of tag specifications. IANA has
established the DKIM-Signature Tag Specification Registry for tag established the DKIM-Signature Tag Specification Registry for tag
specifications that can be used in DKIM-Signature fields. specifications that can be used in DKIM-Signature fields.
The initial entries in the registry comprise: The initial entries in the registry comprise:
+------+-----------------+ +------+-----------------+
| TYPE | REFERENCE | | TYPE | REFERENCE |
+------+-----------------+ +------+-----------------+
| v | (this document) | | v | (this document) |
| a | (this document) | | a | (this document) |
| b | (this document) | | b | (this document) |
| bh | (this document) | | bh | (this document) |
| c | (this document) | | c | (this document) |
| d | (this document) | | d | (this document) |
| h | (this document) | | h | (this document) |
| i | (this document) | | i | (this document) |
| l | (this document) | | l | (this document) |
| q | (this document) | | q | (this document) |
| s | (this document) | | s | (this document) |
| t | (this document) | | t | (this document) |
| x | (this document) | | x | (this document) |
| z | (this document) | | z | (this document) |
+------+-----------------+ +------+-----------------+
DKIM-Signature Tag Specification Registry Initial Values Table 1: DKIM-Signature Tag Specification Registry Initial
Values
7.2. DKIM-Signature Query Method Registry 7.2. DKIM-Signature Query Method Registry
The "q=" tag-spec (specified in Section 3.5) provides for a list of The "q=" tag-spec (specified in Section 3.5) provides for a list of
query methods. query methods.
IANA has established the DKIM-Signature Query Method Registry for IANA has established the DKIM-Signature Query Method Registry for
mechanisms that can be used to retrieve the key that will permit mechanisms that can be used to retrieve the key that will permit
validation processing of a message signed using DKIM. validation processing of a message signed using DKIM.
The initial entry in the registry comprises: The initial entry in the registry comprises:
+------+--------+-----------------+ +------+--------+-----------------+
| TYPE | OPTION | REFERENCE | | TYPE | OPTION | REFERENCE |
+------+--------+-----------------+ +------+--------+-----------------+
| dns | txt | (this document) | | dns | txt | (this document) |
+------+--------+-----------------+ +------+--------+-----------------+
DKIM-Signature Query Method Registry Initial Values DKIM-Signature Query Method Registry Initial Values
7.3. DKIM-Signature Canonicalization Registry 7.3. DKIM-Signature Canonicalization Registry
The "c=" tag-spec (specified in Section 3.5) provides for a specifier The "c=" tag-spec (specified in Section 3.5) provides for a specifier
for canonicalization algorithms for the header and body of the for canonicalization algorithms for the header and body of the
message. message.
IANA has established the DKIM-Signature Canonicalization Algorithm IANA has established the DKIM-Signature Canonicalization Algorithm
Registry for algorithms for converting a message into a canonical Registry for algorithms for converting a message into a canonical
form before signing or verifying using DKIM. form before signing or verifying using DKIM.
The initial entries in the header registry comprise: The initial entries in the body registry comprise:
+---------+-----------------+
| TYPE | REFERENCE |
+---------+-----------------+
| simple | (this document) |
| relaxed | (this document) |
+---------+-----------------+
DKIM-Signature Header Canonicalization Algorithm Registry
Initial Values
The initial entries in the body registry comprise:
+---------+-----------------+ +---------+-----------------+
| TYPE | REFERENCE | | TYPE | REFERENCE |
+---------+-----------------+ +---------+-----------------+
| simple | (this document) | | simple | (this document) |
| relaxed | (this document) | | relaxed | (this document) |
+---------+-----------------+ +---------+-----------------+
DKIM-Signature Body Canonicalization Algorithm Registry DKIM-Signature Body Canonicalization Algorithm Registry
Initial Values Initial Values
7.4. _domainkey DNS TXT Record Tag Specifications 7.4. _domainkey DNS TXT Record Tag Specifications
A _domainkey DNS TXT record provides for a list of tag A _domainkey DNS TXT record provides for a list of tag
specifications. IANA has established the DKIM _domainkey DNS TXT Tag specifications. IANA has established the DKIM _domainkey DNS TXT Tag
Specification Registry for tag specifications that can be used in DNS Specification Registry for tag specifications that can be used in DNS
TXT Records. TXT Records.
The initial entries in the registry comprise: The initial entries in the registry comprise:
+------+-----------------+ +------+-----------------+
| TYPE | REFERENCE | | TYPE | REFERENCE |
+------+-----------------+ +------+-----------------+
| v | (this document) | | v | (this document) |
| g | (this document) | | g | (this document) |
| h | (this document) | | h | (this document) |
| k | (this document) | | k | (this document) |
| n | (this document) | | n | (this document) |
| p | (this document) | | p | (this document) |
| s | (this document) | | s | (this document) |
| t | (this document) | | t | (this document) |
+------+-----------------+ +------+-----------------+
DKIM _domainkey DNS TXT Record Tag Specification Registry DKIM _domainkey DNS TXT Record Tag Specification Registry
Initial Values Initial Values
The initial entries in the body registry comprise:
+---------+-----------------+
| TYPE | REFERENCE |
+---------+-----------------+
| simple | (this document) |
| relaxed | (this document) |
+---------+-----------------+
DKIM-Signature Body Canonicalization Algorithm Registry
Initial Values
7.5. DKIM Key Type Registry 7.5. DKIM Key Type Registry
The "k=" <key-k-tag> (specified in Section 3.6.1) and the "a=" <sig- The "k=" <key-k-tag> (specified in Section 3.6.1) and the "a=" <sig-
a-tag-k> (specified in Section 3.5) tags provide for a list of a-tag-k> (specified in Section 3.5) tags provide for a list of
mechanisms that can be used to decode a DKIM signature. mechanisms that can be used to decode a DKIM signature.
IANA has established the DKIM Key Type Registry for such mechanisms. IANA has established the DKIM Key Type Registry for such mechanisms.
The initial entry in the registry comprises: The initial entry in the registry comprises:
+------+-----------+ +------+-----------+
| TYPE | REFERENCE | | TYPE | REFERENCE |
+------+-----------+ +------+-----------+
| rsa | [RFC3447] | | rsa | [RFC3447] |
+------+-----------+ +------+-----------+
DKIM Key Type Initial Values DKIM Key Type Initial Values
7.6. DKIM Hash Algorithms Registry 7.6. DKIM Hash Algorithms Registry
The "h=" <key-h-tag> (specified in Section 3.6.1) and the "a=" <sig- The "h=" <key-h-tag> (specified in Section 3.6.1) and the "a=" <sig-
a-tag-h> (specified in Section 3.5) tags provide for a list of a-tag-h> (specified in Section 3.5) tags provide for a list of
mechanisms that can be used to produce a digest of message data. mechanisms that can be used to produce a digest of message data.
IANA has established the DKIM Hash Algorithms Registry for such IANA has established the DKIM Hash Algorithms Registry for such
mechanisms. mechanisms.
The initial entries in the registry comprise: The initial entries in the registry comprise:
+--------+-------------------+ +--------+-------------------+
| TYPE | REFERENCE | | TYPE | REFERENCE |
+--------+-------------------+ +--------+-------------------+
| sha1 | [FIPS.180-2.2002] | | sha1 | [FIPS-180-2-2002] |
| sha256 | [FIPS.180-2.2002] | | sha256 | [FIPS-180-2-2002] |
+--------+-------------------+ +--------+-------------------+
DKIM Hash Algorithms Initial Values DKIM Hash Algorithms Initial Values
7.7. DKIM Service Types Registry 7.7. DKIM Service Types Registry
The "s=" <key-s-tag> tag (specified in Section 3.6.1) provides for a The "s=" <key-s-tag> tag (specified in Section 3.6.1) provides for a
list of service types to which this selector may apply. list of service types to which this selector may apply.
IANA has established the DKIM Service Types Registry for service IANA has established the DKIM Service Types Registry for service
types. types.
The initial entries in the registry comprise: The initial entries in the registry comprise:
+-------+-----------------+ +-------+-----------------+
| TYPE | REFERENCE | | TYPE | REFERENCE |
+-------+-----------------+ +-------+-----------------+
| email | (this document) | | email | (this document) |
| * | (this document) | | * | (this document) |
+-------+-----------------+ +-------+-----------------+
DKIM Service Types Registry Initial Values DKIM Service Types Registry Initial Values
7.8. DKIM Selector Flags Registry 7.8. DKIM Selector Flags Registry
The "t=" <key-t-tag> tag (specified in Section 3.6.1) provides for a The "t=" <key-t-tag> tag (specified in Section 3.6.1) provides for a
list of flags to modify interpretation of the selector. list of flags to modify interpretation of the selector.
IANA has established the DKIM Selector Flags Registry for additional IANA has established the DKIM Selector Flags Registry for additional
flags. flags.
The initial entries in the registry comprise: The initial entries in the registry comprise:
+------+-----------------+ +------+-----------------+
| TYPE | REFERENCE | | TYPE | REFERENCE |
+------+-----------------+ +------+-----------------+
| y | (this document) | | y | (this document) |
| s | (this document) | | s | (this document) |
+------+-----------------+ +------+-----------------+
DKIM Selector Flags Registry Initial Values DKIM Selector Flags Registry Initial Values
7.9. DKIM-Signature Header Field 7.9. DKIM-Signature Header Field
IANA has added DKIM-Signature to the "Permanent Message Header IANA has added DKIM-Signature to the "Permanent Message Header
Fields" registry (see [RFC3864]) for the "mail" protocol, using this Fields" registry (see [RFC3864]) for the "mail" protocol, using this
document as the reference. document as the reference.
skipping to change at page 53, line 8 skipping to change at page 57, line 18
section (including the trailing "--CRLF" portion), then it is section (including the trailing "--CRLF" portion), then it is
possible for an attacker to intercept a properly signed multipart possible for an attacker to intercept a properly signed multipart
message and add a new body part. Depending on the details of the message and add a new body part. Depending on the details of the
MIME type and the implementation of the verifying MTA and the MIME type and the implementation of the verifying MTA and the
receiving MUA, this could allow an attacker to change the information receiving MUA, this could allow an attacker to change the information
displayed to an end user from an apparently trusted source. displayed to an end user from an apparently trusted source.
For example, if attackers can append information to a "text/html" For example, if attackers can append information to a "text/html"
body part, they may be able to exploit a bug in some MUAs that body part, they may be able to exploit a bug in some MUAs that
continue to read after a "</html>" marker, and thus display HTML text continue to read after a "</html>" marker, and thus display HTML text
on top of already displayed text. If a message has a on top of already displayed text. If a message has a "multipart/
"multipart/alternative" body part, they might be able to add a new alternative" body part, they might be able to add a new body part
body part that is preferred by the displaying MUA. that is preferred by the displaying MUA.
8.1.2. Addition of new HTML content to existing content 8.1.2. Addition of new HTML content to existing content
Several receiving MUA implementations do not cease display after a Several receiving MUA implementations do not cease display after a
""</html>"" tag. In particular, this allows attacks involving ""</html>"" tag. In particular, this allows attacks involving
overlaying images on top of existing text. overlaying images on top of existing text.
INFORMATIVE EXAMPLE: Appending the following text to an existing, INFORMATIVE EXAMPLE: Appending the following text to an existing,
properly closed message will in many MUAs result in inappropriate properly closed message will in many MUAs result in inappropriate
data being rendered on top of existing, correct data: data being rendered on top of existing, correct data:
<div style="position: relative; bottom: 350px; z-index: 2;"> <div style="position: relative; bottom:
<img src="http://www.ietf.org/images/ietflogo2e.gif" 350px; z-index: 2;"> <img
width=578 height=370> src="http://www.ietf.org/images/ietflogo2e.gif"
</div> width=578 height=370> </div>
8.2. Misappropriated Private Key 8.2. Misappropriated Private Key
If the private key for a user is resident on their computer and is If the private key for a user is resident on their computer and is
not protected by an appropriately secure mechanism, it is possible not protected by an appropriately secure mechanism, it is possible
for malware to send mail as that user and any other user sharing the for malware to send mail as that user and any other user sharing the
same private key. The malware would not, however, be able to same private key. The malware would not, however, be able to
generate signed spoofs of other signers' addresses, which would aid generate signed spoofs of other signers' addresses, which would aid
in identification of the infected user and would limit the in identification of the infected user and would limit the
possibilities for certain types of attacks involving socially possibilities for certain types of attacks involving socially
skipping to change at page 55, line 9 skipping to change at page 59, line 19
OpenPGP [RFC2440] and S/MIME [RFC3851] address those requirements. OpenPGP [RFC2440] and S/MIME [RFC3851] address those requirements.
A second security issue related to the DNS revolves around the A second security issue related to the DNS revolves around the
increased DNS traffic as a consequence of fetching selector-based increased DNS traffic as a consequence of fetching selector-based
data as well as fetching signing domain policy. Widespread data as well as fetching signing domain policy. Widespread
deployment of DKIM will result in a significant increase in DNS deployment of DKIM will result in a significant increase in DNS
queries to the claimed signing domain. In the case of forgeries on a queries to the claimed signing domain. In the case of forgeries on a
large scale, DNS servers could see a substantial increase in queries. large scale, DNS servers could see a substantial increase in queries.
A specific DNS security issue that should be considered by DKIM A specific DNS security issue that should be considered by DKIM
verifiers is the name chaining attack described in Section 2.3 of the verifiers is the name chaining attack described in Section 2.3 of
DNS Threat Analysis [RFC3833]. A DKIM verifier, while verifying a [RFC3833]. A DKIM verifier, while verifying a DKIM-Signature header
DKIM-Signature header field, could be prompted to retrieve a key field, could be prompted to retrieve a key record of an attacker's
record of an attacker's choosing. This threat can be minimized by choosing. This threat can be minimized by ensuring that name
ensuring that name servers, including recursive name servers, used by servers, including recursive name servers, used by the verifier
the verifier enforce strict checking of "glue" and other additional enforce strict checking of "glue" and other additional information in
information in DNS responses and are therefore not vulnerable to this DNS responses and are therefore not vulnerable to this attack.
attack.
8.5. Replay Attacks 8.5. Replay Attacks
In this attack, a spammer sends a message to be spammed to an In this attack, a spammer sends a message to be spammed to an
accomplice, which results in the message being signed by the accomplice, which results in the message being signed by the
originating MTA. The accomplice resends the message, including the originating MTA. The accomplice resends the message, including the
original signature, to a large number of recipients, possibly by original signature, to a large number of recipients, possibly by
sending the message to many compromised machines that act as MTAs. sending the message to many compromised machines that act as MTAs.
The messages, not having been modified by the accomplice, have valid The messages, not having been modified by the accomplice, have valid
signatures. signatures.
skipping to change at page 57, line 35 skipping to change at page 61, line 47
example, in the example above any of the domains could potentially example, in the example above any of the domains could potentially
simply delegate "example.podunk.ca.us" to a server of their choice simply delegate "example.podunk.ca.us" to a server of their choice
and completely replace all DNS-served information. Note that a and completely replace all DNS-served information. Note that a
verifier MAY ignore signatures that come from an unlikely domain verifier MAY ignore signatures that come from an unlikely domain
such as ".com", as discussed in Section 6.1.1. such as ".com", as discussed in Section 6.1.1.
9. References 9. References
9.1. Normative References 9.1. Normative References
[FIPS.180-2.2002] U.S. Department of Commerce, "Secure Hash [FIPS-180-2-2002]
Standard", FIPS PUB 180-2, August 2002. U.S. Department of Commerce, "Secure Hash Standard", FIPS
PUB 180-2, August 2002.
[ITU.X660.1997] "Information Technology - ASN.1 encoding rules: [ITU-X660-1997]
Specification of Basic Encoding Rules (BER), "Information Technology - ASN.1 encoding rules:
Canonical Encoding Rules (CER) and Distinguished Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (DER)", ITU-T Recommendation X.660, Encoding Rules (CER) and Distinguished Encoding Rules
1997. (DER)", 1997.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Internet Mail Extensions (MIME) Part One: Format Extensions (MIME) Part One: Format of Internet Message
of Internet Message Bodies", RFC 2045, Bodies", RFC 2045, November 1996.
November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Extensions) Part Three: Message header field Part Three: Message Header Extensions for Non-ASCII Text",
Extensions for Non-ASCII Text", RFC 2047, RFC 2047, November 1996.
November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Indicate Requirement Levels", BCP 14, RFC 2119, Extensions (MIME) Part Five: Conformance Criteria and
March 1997. Examples", RFC 2049, November 1996.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
RFC 2821, April 2001. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
Cryptography Standards (PKCS) #1: RSA Cryptography April 2001.
Specifications Version 2.1", RFC 3447,
February 2003.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
"Internationalizing Domain Names in Applications Standards (PKCS) #1: RSA Cryptography Specifications
(IDNA)", RFC 3490, March 2003. Version 2.1", RFC 3447, February 2003.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
for Syntax Specifications: ABNF", RFC 4234, "Internationalizing Domain Names in Applications (IDNA)",
October 2005. RFC 3490, March 2003.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
July 2009.
9.2. Informative References 9.2. Informative References
[BONEH03] Proc. 12th USENIX Security Symposium, "Remote [BONEH03] "Remote Timing Attacks are Practical", Proceedings 12th
Timing Attacks are Practical", 2003. USENIX Security Symposium, 2003.
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed "Security Multiparts for MIME: Multipart/Signed and
and Multipart/Encrypted", RFC 1847, October 1995. Multipart/Encrypted", RFC 1847, October 1995.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Writing an IANA Considerations Section in RFCs", IANA Considerations Section in RFCs", BCP 26, RFC 2434,
BCP 26, RFC 2434, October 1998. October 1998.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
Thayer, "OpenPGP Message Format", RFC 2440, "OpenPGP Message Format", RFC 2440, November 1998.
November 1998.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
for Public Keys Used For Exchanging Symmetric Public Keys Used For Exchanging Symmetric Keys", BCP 86,
Keys", RFC 3766, April 2004. RFC 3766, April 2004.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Domain Name System (DNS)", RFC 3833, August 2004. Name System (DNS)", RFC 3833, August 2004.
[RFC3851] Ramsdell, B., "S/MIME Version 3 Message [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Specification", RFC 3851, June 1999. Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
"Registration Procedures for Message Header Procedures for Message Header Fields", BCP 90, RFC 3864,
Fields", BCP 90, September 2004. September 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
and S. Rose, "DNS Security Introduction and Rose, "DNS Security Introduction and Requirements",
Requirements", RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4686] Fenton, J., "Analysis of Threats Motivating [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
DomainKeys Identified Mail (DKIM)", RFC 4686, Identified Mail (DKIM)", RFC 4686, September 2006.
September 2006.
[RFC4870] Delany, M., "Domain-Based Email Authentication [RFC4870] Delany, M., "Domain-Based Email Authentication Using
Using Public Keys Advertised in the DNS Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
(DomainKeys)", RFC 4870, May 2007. May 2007.
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007.
[RFC5451] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 5451, April 2009.
Appendix A. Example of Use (INFORMATIVE) Appendix A. Example of Use (INFORMATIVE)
This section shows the complete flow of an email from submission to This section shows the complete flow of an email from submission to
final delivery, demonstrating how the various components fit final delivery, demonstrating how the various components fit
together. The key used in this example is shown in Appendix C. together. The key used in this example is shown in Appendix C.
A.1. The User Composes an Email A.1. The User Composes an Email
From: Joe SixPack <joe@football.example.com> From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net> To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready? Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com> Message-ID: <;20030712040037.46341.5F8J@football.example.com>
Hi. Hi.
We lost the game. Are you hungry yet? We lost the game. Are you hungry yet?
Joe. Joe.
A.2. The Email Is Signed Figure 1: The User Composes an Email
A.2. The Email is Signed
This email is signed by the example.com outbound email server and now This email is signed by the example.com outbound email server and now
looks like this: looks like this:
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
c=simple/simple; q=dns/txt; i=joe@football.example.com; c=simple/simple; q=dns/txt; i=joe@football.example.com;
h=Received : From : To : Subject : Date : Message-ID; h=Received : From : To : Subject : Date : Message-ID;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
4bmp/YzhwvcubU4=; 4bmp/YzhwvcubU4=;
Received: from client1.football.example.com [192.0.2.1] Received: from client1.football.example.com [192.0.2.1]
by submitserver.example.com with SUBMISSION; by submitserver.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT) Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe@football.example.com> From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net> To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready? Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com> Message-ID: <20030712040037.46341.5F8J@football.example.com>
Hi. Hi.
We lost the game. Are you hungry yet? We lost the game. Are you hungry yet?
Joe. Joe.
The Email is Signed
The signing email server requires access to the private key The signing email server requires access to the private key
associated with the "brisbane" selector to generate this signature. associated with the "brisbane" selector to generate this signature.
A.3. The Email Signature Is Verified A.3. The Email Signature is Verified
The signature is normally verified by an inbound SMTP server or The signature is normally verified by an inbound SMTP server or
possibly the final delivery agent. However, intervening MTAs can possibly the final delivery agent. However, intervening MTAs can
also perform this verification if they choose to do so. The also perform this verification if they choose to do so. The
verification process uses the domain "example.com" extracted from the verification process uses the domain "example.com" extracted from the
"d=" tag and the selector "brisbane" from the "s=" tag in the DKIM- "d=" tag and the selector "brisbane" from the "s=" tag in the DKIM-
Signature header field to form the DNS DKIM query for: Signature header field to form the DNS DKIM query for:
brisbane._domainkey.example.com brisbane._domainkey.example.com
Signature verification starts with the physically last Received Signature verification starts with the physically last Received
header field, the From header field, and so forth, in the order header field, the From header field, and so forth, in the order
listed in the "h=" tag. Verification follows with a single CRLF listed in the "h=" tag. Verification follows with a single CRLF
followed by the body (starting with "Hi."). The email is canonically followed by the body (starting with "Hi."). The email is canonically
prepared for verifying with the "simple" method. The result of the prepared for verifying with the "simple" method. The result of the
query and subsequent verification of the signature is stored (in this query and subsequent verification of the signature is stored (in this
example) in the X-Authentication-Results header field line. After example) in the X-Authentication-Results header field line. After
successful verification, the email looks like this: successful verification, the email looks like this:
skipping to change at page 62, line 6 skipping to change at page 65, line 23
brisbane._domainkey.example.com brisbane._domainkey.example.com
Signature verification starts with the physically last Received Signature verification starts with the physically last Received
header field, the From header field, and so forth, in the order header field, the From header field, and so forth, in the order
listed in the "h=" tag. Verification follows with a single CRLF listed in the "h=" tag. Verification follows with a single CRLF
followed by the body (starting with "Hi."). The email is canonically followed by the body (starting with "Hi."). The email is canonically
prepared for verifying with the "simple" method. The result of the prepared for verifying with the "simple" method. The result of the
query and subsequent verification of the signature is stored (in this query and subsequent verification of the signature is stored (in this
example) in the X-Authentication-Results header field line. After example) in the X-Authentication-Results header field line. After
successful verification, the email looks like this: successful verification, the email looks like this:
X-Authentication-Results: shopping.example.net X-Authentication-Results: shopping.example.net
header.from=joe@football.example.com; dkim=pass header.from=joe@football.example.com; dkim=pass
Received: from mout23.football.example.com (192.168.1.1) Received: from mout23.football.example.com (192.168.1.1)
by shopping.example.net with SMTP; by shopping.example.net with SMTP;
Fri, 11 Jul 2003 21:01:59 -0700 (PDT) Fri, 11 Jul 2003 21:01:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
c=simple/simple; q=dns/txt; i=joe@football.example.com; c=simple/simple; q=dns/txt; i=joe@football.example.com;
h=Received : From : To : Subject : Date : Message-ID; h=Received : From : To : Subject : Date : Message-ID;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
4bmp/YzhwvcubU4=; 4bmp/YzhwvcubU4=;
Received: from client1.football.example.com [192.0.2.1] Received: from client1.football.example.com [192.0.2.1]
by submitserver.example.com with SUBMISSION; by submitserver.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT) Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe@football.example.com> From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net> To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready? Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com> Message-ID: <20030712040037.46341.5F8J@football.example.com>
Hi. Hi.
We lost the game. Are you hungry yet? We lost the game. Are you hungry yet?
Joe. Joe.
Successful verification
Appendix B. Usage Examples (INFORMATIVE) Appendix B. Usage Examples (INFORMATIVE)
DKIM signing and validating can be used in different ways, for DKIM signing and validating can be used in different ways, for
different operational scenarios. This Appendix discusses some common different operational scenarios. This Appendix discusses some common
examples. examples.
NOTE: Descriptions in this Appendix are for informational purposes NOTE: Descriptions in this Appendix are for informational purposes
only. They describe various ways that DKIM can be used, given only. They describe various ways that DKIM can be used, given
particular constraints and needs. In no case are these examples particular constraints and needs. In no case are these examples
intended to be taken as providing explanation or guidance intended to be taken as providing explanation or guidance
skipping to change at page 67, line 21 skipping to change at page 70, line 33
forwarder applies a new DKIM-Signature header field with the forwarder applies a new DKIM-Signature header field with the
signature, public key, and related information of the forwarder. signature, public key, and related information of the forwarder.
Appendix C. Creating a Public Key (INFORMATIVE) Appendix C. Creating a Public Key (INFORMATIVE)
The default signature is an RSA signed SHA256 digest of the complete The default signature is an RSA signed SHA256 digest of the complete
email. For ease of explanation, the openssl command is used to email. For ease of explanation, the openssl command is used to
describe the mechanism by which keys and signatures are managed. One describe the mechanism by which keys and signatures are managed. One
way to generate a 1024-bit, unencrypted private key suitable for DKIM way to generate a 1024-bit, unencrypted private key suitable for DKIM
is to use openssl like this: is to use openssl like this:
$ openssl genrsa -out rsa.private 1024 $ openssl genrsa -out rsa.private 1024
For increased security, the "-passin" parameter can also be added to For increased security, the "-passin" parameter can also be added to
encrypt the private key. Use of this parameter will require entering encrypt the private key. Use of this parameter will require entering
a password for several of the following steps. Servers may prefer to a password for several of the following steps. Servers may prefer to
use hardware cryptographic support. use hardware cryptographic support.
The "genrsa" step results in the file rsa.private containing the key The "genrsa" step results in the file rsa.private containing the key
information similar to this: information similar to this:
-----BEGIN RSA PRIVATE KEY-----
-----BEGIN RSA PRIVATE KEY----- MIICXwIBAAKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFC
MIICXwIBAAKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFC jxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gb
jxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gb to/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB
to/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB AoGBALmn+XwWk7akvkUlqb+dOxyLB9i5VBVfje89Teolwc9YJT36BGN/l4e0l6QX
AoGBALmn+XwWk7akvkUlqb+dOxyLB9i5VBVfje89Teolwc9YJT36BGN/l4e0l6QX /1//6DWUTB3KI6wFcm7TWJcxbS0tcKZX7FsJvUz1SbQnkS54DJck1EZO/BLa5ckJ
/1//6DWUTB3KI6wFcm7TWJcxbS0tcKZX7FsJvUz1SbQnkS54DJck1EZO/BLa5ckJ gAYIaqlA9C0ZwM6i58lLlPadX/rtHb7pWzeNcZHjKrjM461ZAkEA+itss2nRlmyO
gAYIaqlA9C0ZwM6i58lLlPadX/rtHb7pWzeNcZHjKrjM461ZAkEA+itss2nRlmyO n1/5yDyCluST4dQfO8kAB3toSEVc7DeFeDhnC1mZdjASZNvdHS4gbLIA1hUGEF9m
n1/5yDyCluST4dQfO8kAB3toSEVc7DeFeDhnC1mZdjASZNvdHS4gbLIA1hUGEF9m 3hKsGUMMPwJBAPW5v/U+AWTADFCS22t72NUurgzeAbzb1HWMqO4y4+9Hpjk5wvL/
3hKsGUMMPwJBAPW5v/U+AWTADFCS22t72NUurgzeAbzb1HWMqO4y4+9Hpjk5wvL/ eVYizyuce3/fGke7aRYw/ADKygMJdW8H/OcCQQDz5OQb4j2QDpPZc0Nc4QlbvMsj
eVYizyuce3/fGke7aRYw/ADKygMJdW8H/OcCQQDz5OQb4j2QDpPZc0Nc4QlbvMsj 7p7otWRO5xRa6SzXqqV3+F0VpqvDmshEBkoCydaYwc2o6WQ5EBmExeV8124XAkEA
7p7otWRO5xRa6SzXqqV3+F0VpqvDmshEBkoCydaYwc2o6WQ5EBmExeV8124XAkEA qZzGsIxVP+sEVRWZmW6KNFSdVUpk3qzK0Tz/WjQMe5z0UunY9Ax9/4PVhp/j61bf
qZzGsIxVP+sEVRWZmW6KNFSdVUpk3qzK0Tz/WjQMe5z0UunY9Ax9/4PVhp/j61bf eAYXunajbBSOLlx4D+TunwJBANkPI5S9iylsbLs6NkaMHV6k5ioHBBmgCak95JGX
eAYXunajbBSOLlx4D+TunwJBANkPI5S9iylsbLs6NkaMHV6k5ioHBBmgCak95JGX GMot/L2x0IYyMLAz6oLWh2hm7zwtb0CgOrPo1ke44hFYnfc=
GMot/L2x0IYyMLAz6oLWh2hm7zwtb0CgOrPo1ke44hFYnfc= -----END RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
To extract the public-key component from the private key, use openssl To extract the public-key component from the private key, use openssl
like this: like this:
$ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM $ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM
This results in the file rsa.public containing the key information This results in the file rsa.public containing the key information
similar to this: similar to this:
[-----BEGIN PUBLIC KEY-----
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM
oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R
tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI
MmPSPDdQPNUYckcQ2QIDAQAB MmPSPDdQPNUYckcQ2QIDAQAB
-----END PUBLIC KEY----- -----END PUBLIC KEY-----
This public-key data (without the BEGIN and END tags) is placed in This public-key data (without the BEGIN and END tags) is placed in
the DNS: the DNS:
brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ" brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ"
skipping to change at page 68, line 29 skipping to change at page 71, line 51
"IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v" "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v"
"/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi" "/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi"
"tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB") "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB")
Appendix D. MUA Considerations Appendix D. MUA Considerations
When a DKIM signature is verified, the processing system sometimes When a DKIM signature is verified, the processing system sometimes
makes the result available to the recipient user's MUA. How to makes the result available to the recipient user's MUA. How to
present this information to the user in a way that helps them is a present this information to the user in a way that helps them is a
matter of continuing human factors usability research. The tendency matter of continuing human factors usability research. The tendency
is to have the MUA highlight the address associated with this signing is to have the MUA highlight the SDID, in an attempt to show the user
identity in some way, in an attempt to show the user the address from the identity that is claiming responsibility for the message. An MUA
which the mail was sent. An MUA might do this with visual cues such might do this with visual cues such as graphics, or it might include
as graphics, or it might include the address in an alternate view, or the address in an alternate view, or it might even rewrite the
it might even rewrite the original From address using the verified original From address using the verified information. Some MUAs
information. Some MUAs might indicate which header fields were might indicate which header fields were protected by the validated
protected by the validated DKIM signature. This could be done with a DKIM signature. This could be done with a positive indication on the
positive indication on the signed header fields, with a negative signed header fields, with a negative indication on the unsigned
indication on the unsigned header fields, by visually hiding the header fields, by visually hiding the unsigned header fields, or some
unsigned header fields, or some combination of these. If an MUA uses combination of these. If an MUA uses visual indications for signed
visual indications for signed header fields, the MUA probably needs header fields, the MUA probably needs to be careful not to display
to be careful not to display unsigned header fields in a way that unsigned header fields in a way that might be construed by the end
might be construed by the end user as having been signed. If the user as having been signed. If the message has an l= tag whose value
message has an l= tag whose value does not extend to the end of the does not extend to the end of the message, the MUA might also hide or
message, the MUA might also hide or mark the portion of the message mark the portion of the message body that was not signed.
body that was not signed.
The aforementioned information is not intended to be exhaustive. The The aforementioned information is not intended to be exhaustive. The
MUA may choose to highlight, accentuate, hide, or otherwise display MUA may choose to highlight, accentuate, hide, or otherwise display
any other information that may, in the opinion of the MUA author, be any other information that may, in the opinion of the MUA author, be
deemed important to the end user. deemed important to the end user.
Appendix E. Acknowledgements Appendix E. Acknowledgements
The authors wish to thank Russ Allbery, Edwin Aoki, Claus Assmann, The previous IETF version of DKIM [RFC4871] was edited by: Eric
Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve Bellovin, Allman, Jon Callas, Mark Delany, Miles Libbey, Jim Fenton and Michael
Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis Dayman, Thomas.
Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark Fanto,
Stephen Farrell, Duncan Findlay, Elliot Gillum, Olafur That specification was the result of an extended, collaborative
effort, including participation by: Russ Allbery, Edwin Aoki, Claus
Assmann, Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve
Bellovin, Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis
Dayman, Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark
Fanto, Stephen Farrell, Duncan Findlay, Elliot Gillum, Olafur
Gu[eth]mundsson, Phillip Hallam-Baker, Tony Hansen, Sam Hartman, Gu[eth]mundsson, Phillip Hallam-Baker, Tony Hansen, Sam Hartman,
Arvel Hathcock, Amir Herzberg, Paul Hoffman, Russ Housley, Craig Arvel Hathcock, Amir Herzberg, Paul Hoffman, Russ Housley, Craig
Hughes, Cullen Jennings, Don Johnsen, Harry Katz, Murray S. Hughes, Cullen Jennings, Don Johnsen, Harry Katz, Murray S.
Kucherawy, Barry Leiba, John Levine, Charles Lindsey, Simon Kucherawy, Barry Leiba, John Levine, Charles Lindsey, Simon
Longsdale, David Margrave, Justin Mason, David Mayne, Thierry Moreau, Longsdale, David Margrave, Justin Mason, David Mayne, Thierry Moreau,
Steve Murphy, Russell Nelson, Dave Oran, Doug Otis, Shamim Pirzada, Steve Murphy, Russell Nelson, Dave Oran, Doug Otis, Shamim Pirzada,
Juan Altmayer Pizzorno, Sanjay Pol, Blake Ramsdell, Christian Renaud, Juan Altmayer Pizzorno, Sanjay Pol, Blake Ramsdell, Christian Renaud,
Scott Renfro, Neil Rerup, Eric Rescorla, Dave Rossetti, Hector Scott Renfro, Neil Rerup, Eric Rescorla, Dave Rossetti, Hector
Santos, Jim Schaad, the Spamhaus.org team, Malte S. Stretz, Robert Santos, Jim Schaad, the Spamhaus.org team, Malte S. Stretz, Robert
Sanders, Rand Wacker, Sam Weiler, and Dan Wing for their valuable Sanders, Rand Wacker, Sam Weiler, and Dan Wing.
suggestions and constructive criticism.
The DomainKeys specification was a primary source from which this The earlier DomainKeys was a primary source from which DKIM was
specification has been derived. Further information about DomainKeys derived. Further information about DomainKeys is at [RFC4870].
is at [RFC4870].
Authors' Addresses Appendix F. RFC4871bis Changes
Eric Allman F.1. TO DO
Sendmail, Inc.
6425 Christie Ave, Suite 400
Emeryville, CA 94608
USA
Phone: +1 510 594 5501 o Revise summary Introduction to reflect "authentic labeling" rather
EMail: eric+dkim@sendmail.org than "message authentication".
URI:
Jon Callas o Review interoperability items to consider dropping unused
PGP Corporation features.
3460 West Bayshore
Palo Alto, CA 94303
USA
Phone: +1 650 319 9016 o Review retention of other parameters, such as l=
EMail: jon@pgp.com
Mark Delany
Yahoo! Inc
701 First Avenue
Sunnyvale, CA 95087
USA
Phone: +1 408 349 6831 o "signatures inside parts shouldn't be processed"?
EMail: markd+dkim@yahoo-inc.com
URI:
Miles Libbey F.2. DONE
Yahoo! Inc
701 First Avenue
Sunnyvale, CA 95087
USA
EMail: mlibbeymail-mailsig@yahoo.com o Incorporate Updates RFC
URI:
Jim Fenton o Added RFC 5598 reference
Cisco Systems, Inc.
MS SJ-9/2
170 W. Tasman Drive
San Jose, CA 95134-1706
USA
Phone: +1 408 526 5914 o Errata ID: 1376 - Verified - sha value for empty bodies
EMail: fenton@cisco.com
URI:
Michael Thomas o Errata ID: 1377 - Verified - no trailing CR-LF
Cisco Systems, Inc.
MS SJ-9/2
170 W. Tasman Drive
San Jose, CA 95134-1706
Phone: +1 408 525 5386 o Errata ID: 1378 - Verified - no default algorithm
EMail: mat@cisco.com
Full Copyright Statement o Errata ID: 1379 - Verified - z= ABNF
Copyright (C) The IETF Trust (2007). o Errata ID: 1384 - Verified - clarify relaxed step order
This document is subject to the rights, licenses and restrictions o Errata ID: 1461 - Verified - h= ABNF
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an o Errata ID: 1487 - Verified - v= ABNF
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property o Errata ID: 1380 - Held for Document Update - x= fudge factor
The IETF takes no position regarding the validity or scope of any o Errata ID: 1381 - Held for Document Update - unknown q= value,
Intellectual Property Rights or other rights that might be claimed to h=/k=/s=/t= value
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any o Errata ID: 1382 - Held for Document Update - unknown s= values
assurances of licenses to be made available, or the result of an (dup of 1381)
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any o Errata ID: 1383 - Held for Document Update - add g= example
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement o Errata ID: 1386 - Held for Document Update - fix DKIM-Signature
example
Funding for the RFC Editor function is currently provided by the o Errata ID: 1532 - Held for Document Update - "v=DKIM1"
Internet Society.
o Errata ID: 1596 - Held for Document Update - *value* of the b= tag
o Add Authentication Results RFC 5451 to 6.2
Authors' Addresses
D. Crocker (editor)
Brandenburg InternetWorking
675 Spruce Dr.
Sunnyvale
USA
Phone: +1.408.246.8253
Email: dcrocker@bbiw.net
URI: http://bbiw.net
Tony Hansen (editor)
AT&T Laboratories
200 Laurel Ave. South
Middletown, NJ 07748
USA
Email: tony+dkimov@maillennium.att.com
M. Kucherawy (editor)
Cloudmark
Email: msk@cloudmark.com
 End of changes. 222 change blocks. 
892 lines changed or deleted 980 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/