rfc4871.txt   draft-ietf-dkim-rfc4871bis-02.txt 
Network Working Group E. Allman DKIM D. Crocker, Ed.
Request for Comments: 4871 Sendmail, Inc. Internet-Draft Brandenburg InternetWorking
Obsoletes: 4870 J. Callas Obsoletes: 4871 (if approved) T. Hansen, Ed.
Category: Standards Track PGP Corporation Intended status: Standards Track AT&T Laboratories
M. Delany Expires: April 14, 2011 M. Kucherawy, Ed.
M. Libbey Cloudmark
Yahoo! Inc October 11, 2010
J. Fenton
M. Thomas
Cisco Systems, Inc.
DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) Signatures
draft-ietf-dkim-rfc4871bis-02
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 April 14, 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. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 6 2.4. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 7 2.5. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 7
2.6. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 7 2.6. Agent or User Identifier (AUID) . . . . . . . . . . . . . 7
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8 2.7. Identity Assessor . . . . . . . . . . . . . . . . . . . . 8
3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 8 2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 10 2.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 8
3.3. Signing and Verification Algorithms . . . . . . . . . . . 11 2.10. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 9
3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 13 2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . 38
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 39
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
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 . . 40
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 . . . . . . . . . . 44
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 . . . . . . . . . . . . . . . . . . . . . . . 45
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 . . . . . . . . . . . 52
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 48 7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 53
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 . . . . . . . . . 54
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 . . . . . . . . . . . . . . 56
7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 51 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 56
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 . . . . . . . . . . . . . . . 57
8. Security Considerations . . . . . . . . . . . . . . . . . . . 52 8. Security Considerations . . . . . . . . . . . . . . . . . . . 57
8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 52 8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 57
8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 53 8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 58
8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 54 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 59
8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 54 8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59
8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 55 8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 60
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 . . . 61
8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 56 8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 61
8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 56 8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61
8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 56 8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 61
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 . . . . . . . . . 62
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 8.14. Attacks Involving Addition of Header Fields . . . . . . . 62
9.1. Normative References . . . . . . . . . . . . . . . . . . . 57 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
9.2. Informative References . . . . . . . . . . . . . . . . . . 58 9.1. Normative References . . . . . . . . . . . . . . . . . . . 63
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 60 9.2. Informative References . . . . . . . . . . . . . . . . . . 64
A.1. The user composes an email . . . . . . . . . . . . . . . . 60 Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 65
A.2. The email is signed . . . . . . . . . . . . . . . . . . . 61 A.1. The User Composes an Email . . . . . . . . . . . . . . . . 65
A.3. The email signature is verified . . . . . . . . . . . . . 61 A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 65
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 62 A.3. The Email Signature is Verified . . . . . . . . . . . . . 66
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 63 Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 67
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 65 B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 68
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 67 B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 70
Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 68 Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 72
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 69 Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 73
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 74
Appendix F. RFC4871bis Changes . . . . . . . . . . . . . . . . . 74
F.1. TO DO . . . . . . . . . . . . . . . . . . . . . . . . . . 74
F.2. DONE . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75
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 [RFC4880]) 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;
o there is no dependency on public and private key pairs being o there is no dependency on public and private key pairs being
issued by well-known, trusted certificate authorities; issued by well-known, trusted certificate authorities;
o there is no dependency on the deployment of any new Internet o there is no dependency on the deployment of any new Internet
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 23 skipping to change at page 7, line 27
leaves the administrative domain of the signer. leaves the administrative domain of the signer.
2.2. Verifiers 2.2. Verifiers
Elements in the mail system that verify signatures are referred to as Elements in the mail system that verify signatures are referred to as
verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs.
In most cases it is expected that verifiers will be close to an end In most cases it is expected that verifiers will be close to an end
user (reader) of the message or some consuming agent such as a user (reader) of the message or some consuming agent such as a
mailing list exploder. mailing list exploder.
2.3. Whitespace 2.3. 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.4. Identifier
A label that refers to an identity.
2.5. 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.6. 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.7. 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.
2.8. Whitespace
There are three forms of whitespace: There are three forms of whitespace:
o WSP represents simple whitespace, i.e., a space or a tab character o WSP represents simple whitespace, i.e., a space or a tab character
(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
skipping to change at page 6, line 38 skipping to change at page 8, line 34
(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 [RFC5322] except for
the exclusion of obs-FWS. the exclusion of obs-FWS.
2.4. Common ABNF Tokens 2.9. 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.10. 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 [RFC5321]:
o "Local-part" (implementation warning: this permits quoted strings) o "Local-part" (implementation warning: this permits quoted strings)
o "sub-domain" o "sub-domain"
The following tokens are imported from [RFC2822]: The following tokens are imported from [RFC5322]:
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.11. 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
as an "=" followed by two hexadecimal digits from the alphabet as an "=" followed by two hexadecimal digits from the alphabet
"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 = dkim-quoted-printable = *(FWS / hex-octet / dkim-safe-char)
*(FWS / hex-octet / dkim-safe-char)
; hex-octet is from RFC 2045 ; hex-octet is from RFC 2045
dkim-safe-char = %x21-3A / %x3C / %x3E-7E dkim-safe-char = %x21-3A / %x3C / %x3E-7E
; '!' - ':', '<', '>' - '~' ; '!' - ':', '<', '>' - '~'
; Characters not listed as "mail-safe" in ; Characters not listed as "mail-safe" in
; RFC 2049 are also not recommended. ; [RFC2049] 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).
skipping to change at page 8, line 51 skipping to change at page 11, line 4
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
To support multiple concurrent public keys per signing domain, the To support multiple concurrent public keys per signing domain, the
key namespace is subdivided using "selectors". For example, key namespace is subdivided using "selectors". For example,
selectors might indicate the names of office locations (e.g., selectors might indicate the names of office locations (e.g.,
"sanfrancisco", "coolumbeach", and "reykjavik"), the signing date "sanfrancisco", "coolumbeach", and "reykjavik"), the signing date
(e.g., "january2005", "february2005", etc.), or even the individual (e.g., "january2005", "february2005", etc.), or even an individual
user. user.
Selectors are needed to support some important use cases. For Selectors are needed to support some important use cases. For
example: example:
o Domains that want to delegate signing capability for a specific o Domains that want to delegate signing capability for a specific
address for a given duration to a partner, such as an advertising address for a given duration to a partner, such as an advertising
provider or other outsourced function. provider or other outsourced function.
o Domains that want to allow frequent travelers to send messages o Domains that want to allow frequent travelers to send messages
skipping to change at page 10, line 14 skipping to change at page 12, line 19
the transition period. However, a signing domain could elect to the transition period. However, a signing domain could elect to
revoke the key (but maintain the key record) for a further period. revoke the key (but maintain the key record) for a further period.
There is no defined semantic difference between a revoked key and There is no defined semantic difference between a revoked key and
a removed key. a removed key.
While some domains may wish to make selector values well known, While some domains may wish to make selector values well known,
others will want to take care not to allocate selector names in a way others will want to take care not to allocate selector names in a way
that allows harvesting of data by outside parties. For example, if that allows harvesting of data by outside parties. For example, if
per-user keys are issued, the domain owner will need to make the per-user keys are issued, the domain owner will need to make the
decision as to whether to associate this selector directly with the decision as to whether to associate this selector directly with the
user name, or make it some unassociated random value, such as a name of a registered end-user, or make it some unassociated random
fingerprint of the public key. value, such as a fingerprint of the public key.
INFORMATIVE OPERATIONS NOTE: Reusing a selector with a new key INFORMATIVE OPERATIONS NOTE: Reusing a selector with a new key
(for example, changing the key associated with a user's name) (for example, changing the key associated with a user's name)
makes it impossible to tell the difference between a message that makes it impossible to tell the difference between a message that
didn't verify because the key is no longer valid versus a message didn't verify because the key is no longer valid versus a message
that is actually forged. For this reason, signers are ill-advised that is actually forged. For this reason, signers are ill-advised
to reuse selectors for new keys. A better strategy is to assign to reuse selectors for new keys. A better strategy is to assign
new keys to new selectors. new keys to new selectors.
3.2. Tag=Value Lists 3.2. Tag=Value Lists
skipping to change at page 11, line 5 skipping to change at page 13, line 5
The name of the tag will determine the encoding of each value. The name of the tag will determine the encoding of each value.
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 ABNF 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 / "_"
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 [RFC5322], but
are unwilling to accept any modification to the body of messages. are unwilling to accept any modification to the body of messages.
To satisfy all requirements, two canonicalization algorithms are To satisfy all requirements, two canonicalization algorithms are
defined for each of the header and the body: a "simple" algorithm defined for each of the header and the body: a "simple" algorithm
that tolerates almost no modification and a "relaxed" algorithm that that tolerates almost no modification and a "relaxed" algorithm that
tolerates common modifications such as whitespace replacement and tolerates common modifications such as whitespace replacement and
header field line rewrapping. A signer MAY specify either algorithm header field line rewrapping. A signer MAY specify either algorithm
for header or body when signing an email. If no canonicalization for header or body when signing an email. If no canonicalization
algorithm is specified by the signer, the "simple" algorithm defaults algorithm is specified by the signer, the "simple" algorithm defaults
for both header and body. Verifiers MUST implement both for both header and body. Verifiers MUST implement both
skipping to change at page 14, line 29 skipping to change at page 16, line 22
3.4.2. The "relaxed" Header Canonicalization Algorithm 3.4.2. The "relaxed" Header Canonicalization Algorithm
The "relaxed" header canonicalization algorithm MUST apply the The "relaxed" header canonicalization algorithm MUST apply the
following steps in order: following steps in order:
o Convert all header field names (not the header field values) to o Convert all header field names (not the header field values) to
lowercase. For example, convert "SUBJect: AbC" to "subject: AbC". lowercase. For example, convert "SUBJect: AbC" to "subject: AbC".
o Unfold all header field continuation lines as described in o Unfold all header field continuation lines as described in
[RFC2822]; in particular, lines with terminators embedded in [RFC5322]; in particular, lines with terminators embedded in
continued header field values (that is, CRLF sequences followed by continued header field values (that is, CRLF sequences followed by
WSP) MUST be interpreted without the CRLF. Implementations MUST WSP) MUST be interpreted without the CRLF. Implementations MUST
NOT remove the CRLF at the end of the header field value. NOT remove the CRLF at the end of the header field value.
o Convert all sequences of one or more WSP characters to a single SP o Convert all sequences of one or more WSP characters to a single SP
character. WSP characters here include those before and after a character. WSP characters here include those before and after a
line folding boundary. line folding boundary.
o Delete all WSP characters at the end of each unfolded header field o Delete all WSP characters at the end of each unfolded header field
value. value.
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
MUST NOT remove the CRLF at the end of the line.
* Reduce all sequences of WSP within a line to a single SP
character. character.
o Ignores all empty lines at the end of the message body. "Empty b. Ignore all empty lines at the end of the message body. "Empty
line" is defined in Section 3.4.3. 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 17, line 48 skipping to change at page 20, line 4
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 [RFC5322], and hence
SHOULD NOT be reordered and SHOULD be prepended to the message. SHOULD NOT be reordered and SHOULD be prepended to the message.
The DKIM-Signature header field being created or verified is always The DKIM-Signature header field being created or verified is always
included in the signature calculation, after the rest of the header included in the signature calculation, after the rest of the header
fields being signed; however, when calculating or verifying the fields being signed; however, when calculating or verifying the
signature, the value of the "b=" tag (signature value) of that DKIM- signature, the value of the "b=" tag (signature value) of that DKIM-
Signature header field MUST be treated as though it were an empty Signature header field MUST be treated as though it were an empty
string. Unknown tags in the DKIM-Signature header field MUST be string. Unknown tags in the DKIM-Signature header field MUST be
included in the signature calculation but MUST be otherwise ignored included in the signature calculation but MUST be otherwise ignored
by verifiers. Other DKIM-Signature header fields that are included by verifiers. Other DKIM-Signature header fields that are included
in the signature should be treated as normal header fields; in in the signature should be treated as normal header fields; in
particular, the "b=" tag is not treated specially. particular, the "b=" tag is not treated specially.
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.11.
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: ABNF:
sig-v-tag = %x76 [FWS] "=" [FWS] "1" sig-v-tag = %x76 [FWS] "=" [FWS] "1"
INFORMATIVE NOTE: DKIM-Signature version numbers are expected INFORMATIVE NOTE: DKIM-Signature version numbers are expected
to increase arithmetically as new versions of this to increase arithmetically as new versions of this
specification are released. specification are released.
a= The algorithm used to generate the signature (plain-text; a= The algorithm used to generate the signature (plain-text;
REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256";
signers SHOULD sign using "rsa-sha256". See Section 3.3 for a signers SHOULD sign using "rsa-sha256". See Section 3.3 for a
description of algorithms. description of algorithms.
skipping to change at page 18, line 45 skipping to change at page 21, line 6
INFORMATIVE NOTE: DKIM-Signature version numbers are expected INFORMATIVE NOTE: DKIM-Signature version numbers are expected
to increase arithmetically as new versions of this to increase arithmetically as new versions of this
specification are released. specification are released.
a= The algorithm used to generate the signature (plain-text; a= The algorithm used to generate the signature (plain-text;
REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256";
signers SHOULD sign using "rsa-sha256". See Section 3.3 for a signers SHOULD sign using "rsa-sha256". See Section 3.3 for a
description of algorithms. description of algorithms.
ABNF: ABNF:
a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg
sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg
sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h 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-k = "rsa" / x-sig-a-tag-k
sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h 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-k = ALPHA *(ALPHA / DIGIT) ; for later extension
x-sig-a-tag-h = 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 b= The signature data (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 Signer Actions Section 5 for how the signature is
computed. computed.
ABNF: ABNF:
sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data
sig-b-tag-data = base64string sig-b-tag-data = base64string
bh= The hash of the canonicalized body part of the message as limited bh= The hash of the canonicalized body part of the message as
by the "l=" tag (base64; REQUIRED). Whitespace is ignored in limited by the "l=" tag (base64; REQUIRED). Whitespace is ignored
this value and MUST be ignored when reassembling the original in 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 Section 3.7 for how the body hash is computed. limits. See Section 3.7 for how the body hash is computed.
ABNF: ABNF:
sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data
sig-bh-tag-data = base64string sig-bh-tag-data = base64string
c= Message canonicalization (plain-text; OPTIONAL, default is c= Message canonicalization (plain-text; OPTIONAL, default is
"simple/simple"). This tag informs the verifier of the type of "simple/simple"). This tag informs the verifier of the type of
canonicalization used to prepare the message for signing. It canonicalization used to prepare the message for signing. It
consists of two names separated by a "slash" (%d47) character, consists of two names separated by a "slash" (%d47) character,
corresponding to the header and body canonicalization algorithms corresponding to the header and body canonicalization algorithms
respectively. These algorithms are described in Section 3.4. If respectively. These algorithms are described in Section 3.4. If
only one algorithm is named, that algorithm is used for the only one algorithm is named, that algorithm is used for the header
header and "simple" is used for the body. For example, and "simple" is used for the body. For example, "c=relaxed" is
"c=relaxed" is treated the same as "c=relaxed/simple". treated the same as "c=relaxed/simple".
ABNF: ABNF:
sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg 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 d= Specifies the SDID claiming responsibility for an introduction of
the domain that will be queried for the public key. This domain a message into the mail stream (plain-text; REQUIRED). Hence, the
MUST be the same as or a parent domain of the "i=" tag (the SDID value is used to form the query for the public key. The SDID
signing identity, as described below), or it MUST meet the MUST correspond to a valid DNS name under which the DKIM key
requirements for parent domain signing described in Section 3.8. record is published. The conventions and semantics used by a
When presented with a signature that does not meet these signer to create and use a specific SDID are outside the scope of
requirement, verifiers MUST consider the signature invalid. 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.
Internationalized domain names MUST be encoded as described in Internationalized domain names MUST be encoded as described in
[RFC3490]. [RFC3490].
ABNF: ABNF:
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain) domain-name = sub-domain 1*("." sub-domain)
; from RFC 2821 Domain, but excluding address-literal ; from RFC 5321 Domain, but excluding address-literall
h= Signed header fields (plain-text, but see description; REQUIRED). h= Signed header fields (plain-text, but see description; REQUIRED).
A colon-separated list of header field names that identify the A colon-separated list of header field names that identify the
header fields presented to the signing algorithm. The field MUST header fields presented to the signing algorithm. The field MUST
contain the complete list of header fields in the order presented contain the complete list of header fields in the order presented
to the signing algorithm. The field MAY contain names of header to the signing algorithm. The field MAY contain names of header
fields that do not exist when signed; nonexistent header fields fields that do not exist when signed; nonexistent header fields do
do not contribute to the signature computation (that is, they are not contribute to the signature computation (that is, they are
treated as the null input, including the header field name, the treated as the null input, including the header field name, the
separating colon, the header field value, and any CRLF separating colon, the header field value, and any CRLF
terminator). The field MUST NOT include the DKIM-Signature terminator). The field MUST NOT include the DKIM-Signature header
header field that is being created or verified, but may include field that is being created or verified, but may include others.
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: 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:
sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name
0*( *FWS ":" *FWS hdr-name ) 0*( [FWS] ":" [FWS] hdr-name )
hdr-name = field-name
INFORMATIVE EXPLANATION: By "signing" header fields that do not INFORMATIVE EXPLANATION: By "signing" header fields that do not
actually exist, a signer can prevent insertion of those actually exist, a signer can prevent insertion of those header
header fields before verification. However, since a signer fields before verification. However, since a signer cannot
cannot possibly know what header fields might be created in possibly know what header fields might be created in the
the future, and that some MUAs might present header fields future, and that some MUAs might present header fields that are
that are embedded inside a message (e.g., as a message/rfc822 embedded inside a message (e.g., as a message/rfc822 content
content type), the security of this solution is not total. type), the security of this solution is not total.
INFORMATIVE EXPLANATION: The exclusion of the header field name INFORMATIVE EXPLANATION: The exclusion of the header field name
and colon as well as the header field value for non-existent and colon as well as the header field value for non-existent
header fields prevents an attacker from inserting an actual header fields prevents an attacker from inserting an actual
header field with a null value. header field with a null value.
i= Identity of the user or agent (e.g., a mailing list manager) on i= The Agent or User Identifier (AUID) on behalf of which the SDID is
behalf of which this message is signed (dkim-quoted-printable; taking responsibility (dkim-quoted-printable; OPTIONAL, default is
OPTIONAL, default is an empty Local-part followed by an "@" an empty Local-part followed by an "@" followed by the domain from
followed by the domain from the "d=" tag). The syntax is a the "d=" tag).
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 syntax is a standard email address where the Local-part MAY be
the value of the "d=" tag. 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 Internationalized domain names MUST be converted using the steps
listed in Section 4 of [RFC3490] using the "ToASCII" function. listed in Section 4 of [RFC3490] using the "ToASCII" function.
ABNF: ABNF:
sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ]
"@" domain-name
The AUID is specified as having the same syntax as an email
address, but is not required to have the same semantics. Notably,
the domain name is not required to be registered in the DNS -- so
it might not resolve in a query -- and the Local-part MAY be drawn
from a namespace unrelated to any mailbox. The details of the
structure and semantics for the namespace are determined by the
Signer. Any knowledge or use of those details by verifiers or
assessors is outside the scope of the DKIM Signing specification.
The Signer MAY choose to use the same namespace for its AUIDs as
its users' email addresses or MAY choose other means of
representing its users. However, the signer SHOULD use the same
AUID for each message intended to be evaluated as being within the
same sphere of responsibility, if it wishes to offer receivers the
option of using the AUID as a stable identifier that is finer
grained than the SDID.
INFORMATIVE NOTE: The Local-part of the "i=" tag is optional INFORMATIVE NOTE: The Local-part of the "i=" tag is optional
because in some cases a signer may not be able to establish a because, in some cases, a signer may not be able to establish a
verified individual identity. In such cases, the signer may verified individual identity. In such cases, the signer might
wish to assert that although it is willing to go as far as wish to assert that although it is willing to go as far as
signing for the domain, it is unable or unwilling to commit signing for the domain, it is unable or unwilling to commit to
to an individual user name within their domain. It can do so an individual user name within their domain. It can do so by
by including the domain part but not the Local-part of the including the domain part but not the Local-part of the
identity. identity.
INFORMATIVE DISCUSSION: This document does not require the value INFORMATIVE DISCUSSION: This specification does not require the
of the "i=" tag to match the identity in any message header value of the "i=" tag to match the identity in any message
fields. This is considered to be a verifier policy issue. header fields. This is considered to be a verifier policy
Constraints between the value of the "i=" tag and other issue. Constraints between the value of the "i=" tag and other
identities in other header fields seek to apply basic identities in other header fields seek to apply basic
authentication into the semantics of trust associated with a authentication into the semantics of trust associated with a
role such as content author. Trust is a broad and complex role such as content author. Trust is a broad and complex
topic and trust mechanisms are subject to highly creative topic and trust mechanisms are subject to highly creative
attacks. The real-world efficacy of any but the most basic attacks. The real-world efficacy of any but the most basic
bindings between the "i=" value and other identities is not bindings between the "i=" value and other identities is not
well established, nor is its vulnerability to subversion by well established, nor is its vulnerability to subversion by an
an attacker. Hence reliance on the use of these options attacker. Hence reliance on the use of these options should be
should be strictly limited. In particular, it is not at all strictly limited. In particular, it is not at all clear to
clear to what extent a typical end-user recipient can rely on what extent a typical end-user recipient can rely on any
any assurances that might be made by successful use of the assurances that might be made by successful use of the "i="
"i=" options. options.
l= Body length count (plain-text unsigned decimal integer; OPTIONAL, l= Body length count (plain-text unsigned decimal integer; OPTIONAL,
default is entire body). This tag informs the verifier of the default is entire body). This tag informs the verifier of the
number of octets in the body of the email after canonicalization number of octets in the body of the email after canonicalization
included in the cryptographic hash, starting from 0 immediately included in the cryptographic hash, starting from 0 immediately
following the CRLF preceding the body. This value MUST NOT be following the CRLF preceding the body. This value MUST NOT be
larger than the actual number of octets in the canonicalized larger than the actual number of octets in the canonicalized
message body. message body.
INFORMATIVE IMPLEMENTATION WARNING: Use of the "l=" tag might INFORMATIVE IMPLEMENTATION WARNING: Use of the "l=" tag might
allow display of fraudulent content without appropriate allow display of fraudulent content without appropriate warning
warning to end users. The "l=" tag is intended for to end users. The "l=" tag is intended for increasing
increasing signature robustness when sending to mailing lists signature robustness when sending to mailing lists that both
that both modify their content and do not sign their modify their content and do not sign their messages. However,
messages. However, using the "l=" tag enables attacks in using the "l=" tag enables attacks in which an intermediary
which an intermediary with malicious intent modifies a with malicious intent modifies a message to include content
message to include content that solely benefits the attacker. that solely benefits the attacker. It is possible for the
It is possible for the appended content to completely replace appended content to completely replace the original content in
the original content in the end recipient's eyes and to the end recipient's eyes and to defeat duplicate message
defeat duplicate message detection algorithms. Examples are detection algorithms. Examples are described in Security
described in Security Considerations (Section 8). To avoid Considerations Section 8. To avoid this attack, signers should
this attack, signers should be extremely wary of using this be extremely wary of using this tag, and verifiers might wish
tag, and verifiers might wish to ignore the tag or remove to ignore the tag or remove text that appears after the
text that appears after the specified content length. specified content length.
INFORMATIVE NOTE: The value of the "l=" tag is constrained to 76 INFORMATIVE NOTE: The value of the "l=" tag is constrained to
decimal digits. This constraint is not intended to predict 76 decimal digits. This constraint is not intended to predict
the size of future messages or to require implementations to the size of future messages or to require implementations to
use an integer representation large enough to represent the use an integer representation large enough to represent the
maximum possible value, but is intended to remind the maximum possible value, but is intended to remind the
implementer to check the length of this and all other tags implementer to check the length of this and all other tags
during verification and to test for integer overflow when during verification and to test for integer overflow when
decoding the value. Implementers may need to limit the decoding the value. Implementers may need to limit the actual
actual value expressed to a value smaller than 10^76, e.g., value expressed to a value smaller than 10^76, e.g., to allow a
to allow a message to fit within the available storage space. message to fit within the available storage space.
ABNF: ABNF:
sig-l-tag = %x6c [FWS] "=" [FWS]
sig-l-tag = %x6c [FWS] "=" [FWS] 1*76DIGIT 1*76DIGIT
q= A colon-separated list of query methods used to retrieve the q= A colon-separated list of query methods used to retrieve the
public key (plain-text; OPTIONAL, default is "dns/txt"). Each public key (plain-text; OPTIONAL, default is "dns/txt"). Each
query method is of the form "type[/options]", where the syntax query method is of the form "type[/options]", where the syntax and
and semantics of the options depend on the type and specified semantics of the options depend on the type and specified options.
options. If there are multiple query mechanisms listed, the If there are multiple query mechanisms listed, the choice of query
choice of query mechanism MUST NOT change the interpretation of mechanism MUST NOT change the interpretation of the signature.
the signature. Implementations MUST use the recognized query Implementations MUST use the recognized query mechanisms in the
mechanisms in the order presented. order presented. Unrecognized query mechanisms MUST be ignored.
Currently, the only valid value is "dns/txt", which defines the DNS Currently, the only valid value is "dns/txt", which defines the
TXT record lookup algorithm described elsewhere in this document. DNS TXT record lookup algorithm described elsewhere in this
The only option defined for the "dns" query type is "txt", which document. The only option defined for the "dns" query type is
MUST be included. Verifiers and signers MUST support "dns/txt". "txt", which MUST be included. Verifiers and signers MUST support
"dns/txt".
ABNF: ABNF:
sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method
*([FWS] ":" [FWS] sig-q-tag-method) *([FWS] ":" [FWS] sig-q-tag-method)
sig-q-tag-method = "dns/txt" / x-sig-q-tag-type 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 s= The selector subdividing the namespace for the "d=" (domain) tag
(plain-text; REQUIRED). (plain-text; REQUIRED).
skipping to change at page 23, line 18 skipping to change at page 26, line 23
*([FWS] ":" [FWS] sig-q-tag-method) *([FWS] ":" [FWS] sig-q-tag-method)
sig-q-tag-method = "dns/txt" / x-sig-q-tag-type 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 s= The selector subdividing the namespace for the "d=" (domain) tag
(plain-text; REQUIRED). (plain-text; REQUIRED).
ABNF: ABNF:
sig-s-tag = %x73 [FWS] "=" [FWS] selector sig-s-tag = %x73 [FWS] "=" [FWS] selector
t= Signature Timestamp (plain-text unsigned decimal integer; t= Signature Timestamp (plain-text unsigned decimal integer;
RECOMMENDED, default is an unknown creation time). The time that RECOMMENDED, default is an unknown creation time). The time that
this signature was created. The format is the number of seconds 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 since 00:00:00 on January 1, 1970 in the UTC time zone. The value
value is expressed as an unsigned integer in decimal ASCII. This is expressed as an unsigned integer in decimal ASCII. This value
value is not constrained to fit into a 31- or 32-bit integer. is not constrained to fit into a 31- or 32-bit integer.
Implementations SHOULD be prepared to handle values up to at Implementations SHOULD be prepared to handle values up to at least
least 10^12 (until approximately AD 200,000; this fits into 40 10^12 (until approximately AD 200,000; this fits into 40 bits).
bits). To avoid denial-of-service attacks, implementations MAY To avoid denial-of-service attacks, implementations MAY consider
consider any value longer than 12 digits to be infinite. Leap any value longer than 12 digits to be infinite. Leap seconds are
seconds are not counted. Implementations MAY ignore signatures not counted. Implementations MAY ignore signatures that have a
that have a timestamp in the future. timestamp in the future.
ABNF: ABNF:
sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT
x= Signature Expiration (plain-text unsigned decimal integer; x= Signature Expiration (plain-text unsigned decimal integer;
RECOMMENDED, default is no expiration). The format is the same RECOMMENDED, default is no expiration). The format is the same as
as in the "t=" tag, represented as an absolute date, not as a in the "t=" tag, represented as an absolute date, not as a time
time delta from the signing timestamp. The value is expressed as delta from the signing timestamp. The value is expressed as an
an unsigned integer in decimal ASCII, with the same constraints unsigned integer in decimal ASCII, with the same constraints on
on the value in the "t=" tag. Signatures MAY be considered the value in the "t=" tag. Signatures MAY be considered invalid
invalid if the verification time at the verifier is past the if the verification time at the verifier is past the expiration
expiration date. The verification time should be the time that date. The verification time should be the time that the message
the message was first received at the administrative domain of was first received at the administrative domain of the verifier if
the verifier if that time is reliably available; otherwise the that time is reliably available; otherwise the current time should
current time should be used. The value of the "x=" tag MUST be be used. The value of the "x=" tag MUST be greater than the value
greater than the value of the "t=" tag if both are present. of the "t=" tag if both are present.
INFORMATIVE NOTE: The "x=" tag is not intended as an anti-replay INFORMATIVE NOTE: The "x=" tag is not intended as an anti-
defense. replay defense.
ABNF: 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.
sig-x-tag = %x78 [FWS] "=" [FWS] 1*12DIGIT ABNF:
sig-x-tag = %x78 [FWS] "=" [FWS]
1*12DIGIT
z= Copied header fields (dkim-quoted-printable, but see description; z= Copied header fields (dkim-quoted-printable, but see description;
OPTIONAL, default is null). A vertical-bar-separated list of OPTIONAL, default is null). A vertical-bar-separated list of
selected header fields present when the message was signed, selected header fields present when the message was signed,
including both the field name and value. It is not required to including both the field name and value. It is not required to
include all header fields present at the time of signing. This include all header fields present at the time of signing. This
field need not contain the same header fields listed in the "h=" field need not contain the same header fields listed in the "h="
tag. The header field text itself must encode the vertical bar tag. The header field text itself must encode the vertical bar
("|", %x7C) character (i.e., vertical bars in the "z=" text are ("|", %x7C) character (i.e., vertical bars in the "z=" text are
metacharacters, and any actual vertical bar characters in a meta-characters, and any actual vertical bar characters in a
copied header field must be encoded). Note that all whitespace copied header field must be encoded). Note that all whitespace
must be encoded, including whitespace between the colon and the must be encoded, including whitespace between the colon and the
header field value. After encoding, FWS MAY be added at header field value. After encoding, FWS MAY be added at arbitrary
arbitrary locations in order to avoid excessively long lines; locations in order to avoid excessively long lines; such
such whitespace is NOT part of the value of the header field, and whitespace is NOT part of the value of the header field, and MUST
MUST be removed before decoding. be removed before decoding.
The header fields referenced by the "h=" tag refer to the fields in The header fields referenced by the "h=" tag refer to the fields
the RFC 2822 header of the message, not to any copied fields in in the [RFC5322] header of the message, not to any copied fields
the "z=" tag. Copied header field values are for diagnostic use. in the "z=" tag. Copied header field values are for diagnostic
use.
Header fields with characters requiring conversion (perhaps from Header fields with characters requiring conversion (perhaps from
legacy MTAs that are not [RFC2822] compliant) SHOULD be converted legacy MTAs that are not [RFC5322] compliant) SHOULD be converted
as described in MIME Part Three [RFC2047]. as described in MIME Part Three [RFC2047].
ABNF: ABNF:
sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy
*( [FWS] "|" sig-z-tag-copy ) *( "|" [FWS] sig-z-tag-copy )
sig-z-tag-copy = hdr-name ":" qp-hdr-value sig-z-tag-copy = hdr-name [FWS] ":" qp-hdr-value
qp-hdr-value = dkim-quoted-printable ; with "|" encoded
INFORMATIVE EXAMPLE of a signature header field spread across INFORMATIVE EXAMPLE of a signature header field spread across
multiple continuation lines: multiple continuation lines:
DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;
DKIM-Signature: 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.
skipping to change at page 26, line 14 skipping to change at page 29, line 32
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: ABNF:
key-v-tag = %x76 [FWS] "=" [FWS] %x44 %x4B %x49 %x4D %x31
key-v-tag = %x76 [FWS] "=" [FWS] "DKIM1"
g= Granularity of the key (plain-text; OPTIONAL, default is "*"). g= Granularity of the key (plain-text; OPTIONAL, default is "*").
This value MUST match the Local-part of the "i=" tag of the DKIM- 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 Signature header field (or its default value of the empty string
if "i=" is not specified), with a single, optional "*" character if "i=" is not specified), with a single, optional "*" character
matching a sequence of zero or more arbitrary characters matching a sequence of zero or more arbitrary characters
("wildcarding"). An email with a signing address that does not ("wildcarding"). An email with a signing address that does not
match the value of this tag constitutes a failed verification. match the value of this tag constitutes a failed verification.
The intent of this tag is to constrain which signing address can The intent of this tag is to constrain which signing address can
legitimately use this selector, for example, when delegating a legitimately use this selector, for example, when delegating a key
key to a third party that should only be used for special to a third party that should only be used for special purposes.
purposes. Wildcarding allows matching for addresses such as Wildcarding allows matching for addresses such as "user+*",
"user+*" or "*-offer". An empty "g=" value never matches any "*-offer" or "foo*bar". An empty "g=" value never matches any
addresses. addresses.
ABNF: ABNF:
key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart
key-g-tag-lpart = [dot-atom-text] ["*" [dot-atom-text] ] key-g-tag-lpart = [dot-atom-text] ["*" [dot-atom-text] ]
h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
allowing all algorithms). A colon-separated list of hash allowing all algorithms). A colon-separated list of hash
algorithms that might be used. Signers and Verifiers MUST algorithms that might be used. Signers and Verifiers MUST support
support the "sha256" hash algorithm. Verifiers MUST also support the "sha256" hash algorithm. Verifiers MUST also support the
the "sha1" hash algorithm. "sha1" hash algorithm. Unrecognized hash algorithms MUST be
ignored.
ABNF: ABNF:
key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg 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 k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and
verifiers MUST support the "rsa" key type. The "rsa" key type verifiers MUST support the "rsa" key type. The "rsa" key type
indicates that an ASN.1 DER-encoded [ITU.X660.1997] RSAPublicKey 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=" [RFC3447] (see Sections Section 3.1 and A.1.1) is being used in
tag. (Note: the "p=" tag further encodes the value using the the "p=" tag. (Note: the "p=" tag further encodes the value using
base64 algorithm.) the base64 algorithm.) Unrecognized key types MUST be ignored.
ABNF: ABNF:
key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type
key-k-tag-type = "rsa" / x-key-k-tag-type key-k-tag-type = "rsa" / x-key-k-tag-type
x-key-k-tag-type = hyphenated-word ; for future extension x-key-k-tag-type = hyphenated-word ; for future extension
n= Notes that might be of interest to a human (qp-section; OPTIONAL, n= Notes that might be of interest to a human (qp-section; OPTIONAL,
default is empty). No interpretation is made by any program. default is empty). No interpretation is made by any program.
This tag should be used sparingly in any key server mechanism This tag should be used sparingly in any key server mechanism that
that has space limitations (notably DNS). This is intended for has space limitations (notably DNS). This is intended for use by
use by administrators, not end users. administrators, not end users.
ABNF: ABNF:
key-n-tag = %x6e [FWS] "=" [FWS] qp-section key-n-tag = %x6e [FWS] "=" [FWS] qp-section
p= Public-key data (base64; REQUIRED). An empty value means that p= Public-key data (base64; REQUIRED). An empty value means that
this public key has been revoked. The syntax and semantics of this public key has been revoked. The syntax and semantics of
this tag value before being encoded in base64 are defined by the this tag value before being encoded in base64 are defined by the
"k=" tag. "k=" tag.
INFORMATIVE RATIONALE: If a private key has been compromised INFORMATIVE RATIONALE: If a private key has been compromised or
or otherwise disabled (e.g., an outsourcing contract has been otherwise disabled (e.g., an outsourcing contract has been
terminated), a signer might want to explicitly state that it terminated), a signer might want to explicitly state that it
knows about the selector, but all messages using that knows about the selector, but all messages using that selector
selector should fail verification. Verifiers should ignore should fail verification. Verifiers should ignore any DKIM-
any DKIM-Signature header fields with a selector referencing Signature header fields with a selector referencing a revoked
a revoked key. key.
ABNF: ABNF:
key-p-tag = %x70 [FWS] "=" [ [FWS] base64string ] 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.
skipping to change at page 28, line 8 skipping to change at page 31, line 33
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:
skipping to change at page 28, line 20 skipping to change at page 32, line 6
* 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 key-s-tag = %x73 [FWS] "=" [FWS] key-s-tag-type
0*( [FWS] ":" [FWS] key-s-tag-type ) 0*( [FWS] ":" [FWS] key-s-tag-type )
key-s-tag-type = "email" / "*" / x-key-s-tag-type key-s-tag-type = "email" / "*" / x-key-s-tag-type
x-key-s-tag-type = hyphenated-word ; for future extension x-key-s-tag-type = hyphenated-word ; for future extension
t= Flags, represented as a colon-separated list of names (plain- t= Flags, represented as a colon-separated list of names (plain-
text; OPTIONAL, default is no flags set). The defined flags are text; OPTIONAL, default is no flags set). Unrecognized flags MUST
as follows: be ignored. The defined flags are as follows:
y This domain is testing DKIM. Verifiers MUST NOT treat y This domain is testing DKIM. Verifiers MUST NOT treat messages
messages from signers in testing mode differently from from signers in testing mode differently from unsigned email, even
unsigned email, even should the signature fail to verify. should the signature fail to verify. Verifiers MAY wish to track
Verifiers MAY wish to track testing mode results to assist testing mode results to assist the signer.
the signer.
s Any DKIM-Signature header fields using the "i=" tag MUST have s Any DKIM-Signature header fields using the "i=" tag MUST have the
the same domain value on the right-hand side of the "@" in same domain value on the right-hand side of the "@" in the "i="
the "i=" tag and the value of the "d=" tag. That is, the tag and the value of the "d=" tag. That is, the "i=" domain MUST
"i=" domain MUST NOT be a subdomain of "d=". Use of this NOT be a subdomain of "d=". Use of this flag is RECOMMENDED
flag is RECOMMENDED unless subdomaining is required. unless subdomaining is required.
ABNF: ABNF:
key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag
0*( [FWS] ":" [FWS] key-t-tag-flag ) 0*( [FWS] ":" [FWS] key-t-tag-flag )
key-t-tag-flag = "y" / "s" / x-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 x-key-t-tag-flag = hyphenated-word ; for future extension
Unrecognized flags MUST be ignored. Unrecognized flags MUST be ignored.
3.6.1.1. Compatibility Note for DomainKeys
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
of "foo.bar", the DNS query will be for of "foo.bar", the DNS query will be for
skipping to change at page 29, line 34 skipping to change at page 33, line 34
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 25
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
header fields MAY be signed (see Section 4). header fields MAY be signed (see Section 4).
When calculating the hash on messages that will be transmitted using When calculating the hash on messages that will be transmitted using
base64 or quoted-printable encoding, signers MUST compute the hash base64 or quoted-printable encoding, signers MUST compute the hash
after the encoding. Likewise, the verifier MUST incorporate the after the encoding. Likewise, the verifier MUST incorporate the
values into the hash before decoding the base64 or quoted-printable values into the hash before decoding the base64 or quoted-printable
text. However, the hash MUST be computed before transport level text. However, the hash MUST be computed before transport level
encodings such as SMTP "dot-stuffing" (the modification of lines encodings such as SMTP "dot-stuffing" (the modification of lines
beginning with a "." to avoid confusion with the SMTP end-of-message beginning with a "." to avoid confusion with the SMTP end-of-message
marker, as specified in [RFC2821]). marker, as specified in [RFC5321]).
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)
skipping to change at page 31, line 35 skipping to change at page 35, line 35
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 hnamas 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 an 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 40, line 23
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.
Similarly, a message that is not compliant with RFC5322, RFC2045
correct or interpret such content. See Section 8 of [RFC4409] for
examples of changes that are commonly made. Such "corrections" may
break DKIM signatures or have other undesirable effects. Therefore,
a verifier SHOULD NOT validate a message that is not conformant.
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 [RFC5322] 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.
More generally, the signer MUST sign the message as it is expected to More generally, the signer MUST sign the message as it is expected to
be received by the verifier rather than in some local or internal be received by the verifier rather than in some local or internal
form. form.
5.4. Determine the Header Fields to Sign 5.4. Determine the Header Fields to Sign
The From header field MUST be signed (that is, included in the "h=" The From header field MUST be signed (that is, included in the "h="
tag of the resulting DKIM-Signature header field). Signers SHOULD tag of the resulting DKIM-Signature header field). Signers SHOULD
NOT sign an existing header field likely to be legitimately modified NOT sign an existing header field likely to be legitimately modified
or removed in transit. In particular, [RFC2821] explicitly permits or removed in transit. In particular, [RFC5321] explicitly permits
modification or removal of the Return-Path header field in transit. modification or removal of the Return-Path header field in transit.
Signers MAY include any other header fields present at the time of Signers MAY include any other header fields present at the time of
signing at the discretion of the signer. signing at the discretion of the signer.
INFORMATIVE OPERATIONS NOTE: The choice of which header fields to INFORMATIVE OPERATIONS NOTE: The choice of which header fields to
sign is non-obvious. One strategy is to sign all existing, non- sign is non-obvious. One strategy is to sign all existing, non-
repeatable header fields. An alternative strategy is to sign only repeatable header fields. An alternative strategy is to sign only
header fields that are likely to be displayed to or otherwise be header fields that are likely to be displayed to or otherwise be
likely to affect the processing of the message at the receiver. A likely to affect the processing of the message at the receiver. A
third strategy is to sign only "well known" headers. Note that third strategy is to sign only "well known" headers. Note that
skipping to change at page 37, line 20 skipping to change at page 42, line 12
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 [RFC5322] 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-
Signature header fields is error-prone. Signature header fields is error-prone.
INFORMATIVE ADMONITION: Despite the fact that [RFC2822] permits INFORMATIVE ADMONITION: Despite the fact that [RFC5322] permits
header fields to be reordered (with the exception of Received header fields to be reordered (with the exception of Received
header fields), reordering of signed header fields with multiple header fields), reordering of signed header fields with multiple
instances by intermediate MTAs will cause DKIM signatures to be instances by intermediate MTAs will cause DKIM signatures to be
broken; such anti-social behavior should be avoided. broken; such anti-social behavior should be avoided.
INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this
specification, all end-user visible header fields should be signed specification, all end-user visible header fields should be signed
to avoid possible "indirect spamming". For example, if the to avoid possible "indirect spamming". For example, if the
Subject header field is not signed, a spammer can resend a Subject header field is not signed, a spammer can resend a
previously signed mail, replacing the legitimate subject with a previously signed mail, replacing the legitimate subject with a
skipping to change at page 38, line 15 skipping to change at page 43, line 6
5.5. Recommended Signature Content 5.5. Recommended Signature Content
In order to maximize compatibility with a variety of verifiers, it is In order to maximize compatibility with a variety of verifiers, it is
recommended that signers follow the practices outlined in this recommended that signers follow the practices outlined in this
section when signing a message. However, these are generic section when signing a message. However, these are generic
recommendations applying to the general case; specific senders may recommendations applying to the general case; specific senders may
wish to modify these guidelines as required by their unique wish to modify these guidelines as required by their unique
situations. Verifiers MUST be capable of verifying signatures even situations. Verifiers MUST be capable of verifying signatures even
if one or more of the recommended header fields is not signed (with if one or more of the recommended header fields is not signed (with
the exception of From, which must always be signed) or if one or more the exception of From, which must always be signed) or if one or more
of the disrecommended header fields is signed. Note that verifiers of the dis-recommended header fields is signed. Note that verifiers
do have the option of ignoring signatures that do not cover a do have the option of ignoring signatures that do not cover a
sufficient portion of the header or body, just as they may ignore sufficient portion of the header or body, just as they may ignore
signatures from an identity they do not trust. signatures from an identity they do not trust.
The following header fields SHOULD be included in the signature, if The following header fields SHOULD be included in the signature, if
they are present in the message being signed: they are present in the message being signed:
o From (REQUIRED in all signatures) o From (REQUIRED in all signatures)
o Sender, Reply-To o Sender, Reply-To
skipping to change at page 46, line 43 skipping to change at page 51, line 36
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 field ([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.
skipping to change at page 47, line 32 skipping to change at page 52, line 29
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
never there, or was it removed by an overzealous filter? For never there, or was it removed by an overzealous filter? For
diagnostic purposes, the exact reason why the verification fails diagnostic purposes, the exact reason why the verification fails
SHOULD be made available to the policy module and possibly recorded SHOULD be made available to the policy module and possibly recorded
in the system logs. If the email cannot be verified, then it SHOULD in the system logs. If the email cannot be verified, then it SHOULD
be rendered the same as all unverified email regardless of whether or be rendered the same as all unverified email regardless of whether or
not it looks like it was signed. not it looks like it was signed.
7. IANA Considerations 7. IANA Considerations
DKIM introduces some new namespaces that have been registered with DKIM has registered new namespaces with IANA. In all cases, new
IANA. In all cases, new values are assigned only for values that values are assigned only for values that have been documented in a
have been documented in a published RFC that has IETF Consensus published RFC that has IETF Consensus [RFC5226].
[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:
+------+-----------------+ +------+-----------------+
skipping to change at page 48, line 51 skipping to change at page 53, line 43
| 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.
skipping to change at page 49, line 34 skipping to change at page 54, line 29
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:
+---------+-----------------+
| TYPE | REFERENCE |
+---------+-----------------+
| simple | (this document) |
| relaxed | (this document) |
+---------+-----------------+
DKIM-Signature Header Canonicalization Algorithm Registry
Initial Values
The initial entries in the body registry comprise: 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
skipping to change at page 50, line 41 skipping to change at page 55, line 21
| 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:
skipping to change at page 51, line 29 skipping to change at page 56, line 19
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
skipping to change at page 53, line 8 skipping to change at page 57, line 45
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:
skipping to change at page 53, line 21 skipping to change at page 58, line 14
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: 350px; z-index: 2;">
<img src="http://www.ietf.org/images/ietflogo2e.gif" <img src="http://www.ietf.org/images/ietflogo2e.gif" width=578 height=370> </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 54, line 47 skipping to change at page 59, line 40
Since the DNS is a required binding for key services, specific Since the DNS is a required binding for key services, specific
attacks against the DNS must be considered. attacks against the DNS must be considered.
While the DNS is currently insecure [RFC3833], these security While the DNS is currently insecure [RFC3833], these security
problems are the motivation behind DNS Security (DNSSEC) [RFC4033], problems are the motivation behind DNS Security (DNSSEC) [RFC4033],
and all users of the DNS will reap the benefit of that work. and all users of the DNS will reap the benefit of that work.
DKIM is only intended as a "sufficient" method of proving DKIM is only intended as a "sufficient" method of proving
authenticity. It is not intended to provide strong cryptographic authenticity. It is not intended to provide strong cryptographic
proof about authorship or contents. Other technologies such as proof about authorship or contents. Other technologies such as
OpenPGP [RFC2440] and S/MIME [RFC3851] address those requirements. OpenPGP [RFC4880] and S/MIME [RFC5751] 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 31 skipping to change at page 62, line 26
domain. domain.
INFORMATIVE NOTE: This is considered an acceptable risk for the INFORMATIVE NOTE: This is considered an acceptable risk for the
same reason that it is acceptable for domain delegation. For same reason that it is acceptable for domain delegation. For
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.
8.14. Attacks Involving Addition of Header Fields
Many email implementations do not enforce [RFC5322] with strictness.
As discussed in Section 5.3 DKIM processing is predicated on a valid
mail message as its input. However, DKIM implementers should be
aware of the potential effect of having loose enforcement by email
components interacting with DKIM modules.
For example, a message with multiple From: header fields violates
Section 3.6 of [RFC5322]. With the intent of providing a better user
experience, many agents tolerate these violations and deliver the
message anyway. An MUA then might elect to render to the user the
value of the last, or "top", From: field. This may also be done
simply out of the expectation that there is only one, where a "find
first" algorithm would have the same result. Such code in an MUA can
be exploited to fool the user if it is also known that the other
From: field is the one checked by arriving message filters. Such is
the case with DKIM; although the From: field must be signed, a
malformed message bearing more than one From: field might only have
the first ("bottom") one signed, in an attempt to show the message
with some "DKIM passed" annotation while also rendering the From:
field that was not authenticated. (This can also be taken as a
demonstration that DKIM is not designed to support author
validation.)
A signer wishing to be resistant to this specific attack can include
in the signed header field list an additional instance of each field
that was present at signing. For example, a proper message with one
From: field could be signed using "h=From:From:..." Because of the
way header fields are canonicalized for input to the hash function,
this would prevent additional fields from being added, after signing,
as this would render the signature invalid.
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:
Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)", ITU-T Recommendation X.660,
1997.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose [ITU-X660-1997]
Internet Mail Extensions (MIME) Part One: Format "Information Technology - ASN.1 encoding rules:
of Internet Message Bodies", RFC 2045, Specification of Basic Encoding Rules (BER), Canonical
November 1996. Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", 1997.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions) Part Three: Message header field Extensions (MIME) Part One: Format of Internet Message
Extensions for Non-ASCII Text", RFC 2047, Bodies", RFC 2045, November 1996.
November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Indicate Requirement Levels", BCP 14, RFC 2119, Part Three: Message Header Extensions for Non-ASCII Text",
March 1997. RFC 2047, November 1996.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
RFC 2821, April 2001. Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, November 1996.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
April 2001. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Cryptography Standards (PKCS) #1: RSA Cryptography Standards (PKCS) #1: RSA Cryptography Specifications
Specifications Version 2.1", RFC 3447, Version 2.1", RFC 3447, February 2003.
February 2003.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications "Internationalizing Domain Names in Applications (IDNA)",
(IDNA)", RFC 3490, March 2003. RFC 3490, March 2003.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
for Syntax Specifications: ABNF", RFC 4234, Specifications: ABNF", RFC 4234, October 2005.
October 2005.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
October 2008.
[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 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Writing an IANA Considerations Section in RFCs", Public Keys Used For Exchanging Symmetric Keys", BCP 86,
BCP 26, RFC 2434, October 1998. RFC 3766, April 2004.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Thayer, "OpenPGP Message Format", RFC 2440, Name System (DNS)", RFC 3833, August 2004.
November 1998.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
for Public Keys Used For Exchanging Symmetric Procedures for Message Header Fields", BCP 90, RFC 3864,
Keys", RFC 3766, April 2004. September 2004.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Domain Name System (DNS)", RFC 3833, August 2004. Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC3851] Ramsdell, B., "S/MIME Version 3 Message [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
Specification", RFC 3851, June 1999. RFC 4409, April 2006.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
"Registration Procedures for Message Header Identified Mail (DKIM)", RFC 4686, September 2006.
Fields", BCP 90, September 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., [RFC4870] Delany, M., "Domain-Based Email Authentication Using
and S. Rose, "DNS Security Introduction and Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
Requirements", RFC 4033, March 2005. May 2007.
[RFC4686] Fenton, J., "Analysis of Threats Motivating [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
DomainKeys Identified Mail (DKIM)", RFC 4686, J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
September 2006. Signatures", RFC 4871, May 2007.
[RFC4870] Delany, M., "Domain-Based Email Authentication [RFC4880] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
Using Public Keys Advertised in the DNS "OpenPGP Message Format", RFC 4880, November 2007.
(DomainKeys)", RFC 4870, May 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5451] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 5451, April 2009.
[RFC5751] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 5751, January 2010.
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;
skipping to change at page 61, line 33 skipping to change at page 66, line 29
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 35 skipping to change at page 67, line 33
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 10 skipping to change at page 72, line 8
adding their own signatures (e.g., mailing-list-name@example.net). adding their own signatures (e.g., mailing-list-name@example.net).
Since (re-)signing is taking responsibility for the content of the Since (re-)signing is taking responsibility for the content of the
message, these signing forwarders are likely to be selective, and message, these signing forwarders are likely to be selective, and
forward or re-sign a message only if it is received with a valid forward or re-sign a message only if it is received with a valid
signature or if they have some other basis for knowing that the signature or if they have some other basis for knowing that the
message is not spoofed. message is not spoofed.
A common practice among systems that are primarily redistributors of A common practice among systems that are primarily redistributors of
mail is to add a Sender header field to the message, to identify the mail is to add a Sender header field to the message, to identify the
address being used to sign the message. This practice will remove address being used to sign the message. This practice will remove
any preexisting Sender header field as required by [RFC2822]. The any preexisting Sender header field as required by [RFC5322]. The
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:
skipping to change at page 67, line 50 skipping to change at page 72, line 45
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 73, line 28
"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. o Errata ID: 1376 - Verified - sha value for empty bodies
MS SJ-9/2
170 W. Tasman Drive
San Jose, CA 95134-1706
USA
Phone: +1 408 526 5914 o Errata ID: 1377 - Verified - no trailing CR-LF
EMail: fenton@cisco.com
URI:
Michael Thomas o Errata ID: 1378 - Verified - no default algorithm
Cisco Systems, Inc.
MS SJ-9/2
170 W. Tasman Drive
San Jose, CA 95134-1706
Phone: +1 408 525 5386 o Errata ID: 1379 - Verified - z= ABNF
EMail: mat@cisco.com
Full Copyright Statement o Errata ID: 1384 - Verified - clarify relaxed step order
Copyright (C) The IETF Trust (2007). o Errata ID: 1461 - Verified - h= ABNF
This document is subject to the rights, licenses and restrictions o Errata ID: 1487 - Verified - v= 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: 1380 - Held for Document Update - x= fudge factor
"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: 1381 - Held for Document Update - unknown q= value,
h=/k=/s=/t= value
The IETF takes no position regarding the validity or scope of any o Errata ID: 1382 - Held for Document Update - unknown s= values
Intellectual Property Rights or other rights that might be claimed to (dup of 1381)
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: 1383 - Held for Document Update - add g= example
assurances of licenses to be made available, or the result of an
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: 1386 - Held for Document Update - fix DKIM-Signature
copyrights, patents or patent applications, or other proprietary example
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: 1532 - Held for Document Update - "v=DKIM1"
Funding for the RFC Editor function is currently provided by the o Errata ID: 1596 - Held for Document Update - *value* of the b= tag
Internet Society.
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. 198 change blocks. 
589 lines changed or deleted 736 lines changed or added

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