draft-ietf-dkim-deployment-04.txt   draft-ietf-dkim-deployment-05.txt 
DomainKeys Identified Mail T. Hansen DomainKeys Identified Mail T. Hansen
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Intended status: Informational E. Siegel Intended status: Informational E. Siegel
Expires: September 10, 2009 Constant Contact, Inc. Expires: December 5, 2009 Constant Contact, Inc.
P. Hallam-Baker P. Hallam-Baker
VeriSign Inc. VeriSign Inc.
D. Crocker D. Crocker
Brandenburg InternetWorking Brandenburg InternetWorking
March 9, 2009 June 3, 2009
DomainKeys Identified Mail (DKIM) Development, Deployment and Operations DomainKeys Identified Mail (DKIM) Development, Deployment and Operations
draft-ietf-dkim-deployment-04 draft-ietf-dkim-deployment-05
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009. This Internet-Draft will expire on December 5, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 23 skipping to change at page 3, line 23
2.5. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 12
3. DKIM Key Generation, Storage, and Management . . . . . . . . . 14 3. DKIM Key Generation, Storage, and Management . . . . . . . . . 14
3.1. Private Key Management: Deployment and Ongoing 3.1. Private Key Management: Deployment and Ongoing
Operations . . . . . . . . . . . . . . . . . . . . . . . . 15 Operations . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Storing Public Keys: DNS Server Software Considerations . 16 3.2. Storing Public Keys: DNS Server Software Considerations . 16
3.3. Per User Signing Key Management Issues . . . . . . . . . . 17 3.3. Per User Signing Key Management Issues . . . . . . . . . . 17
3.4. Third Party Signer Key Management and Selector 3.4. Third Party Signer Key Management and Selector
Administration . . . . . . . . . . . . . . . . . . . . . . 17 Administration . . . . . . . . . . . . . . . . . . . . . . 17
3.5. Key Pair / Selector Lifecycle Management . . . . . . . . . 18 3.5. Key Pair / Selector Lifecycle Management . . . . . . . . . 18
4. Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. DNS Records . . . . . . . . . . . . . . . . . . . . . . . 19 4.1. DNS Records . . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Signing Module . . . . . . . . . . . . . . . . . . . . . . 20 4.2. Signing Module . . . . . . . . . . . . . . . . . . . . . . 20
4.3. Signing Policies and Practices . . . . . . . . . . . . . . 20 4.3. Signing Policies and Practices . . . . . . . . . . . . . . 21
5. Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5. Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. Intended Scope of Use . . . . . . . . . . . . . . . . . . 21 5.1. Intended Scope of Use . . . . . . . . . . . . . . . . . . 21
5.2. Signature Scope . . . . . . . . . . . . . . . . . . . . . 21 5.2. Signature Scope . . . . . . . . . . . . . . . . . . . . . 22
5.3. Design Scope of Use . . . . . . . . . . . . . . . . . . . 22 5.3. Design Scope of Use . . . . . . . . . . . . . . . . . . . 22
5.4. Inbound Mail Filtering . . . . . . . . . . . . . . . . . . 22 5.4. Inbound Mail Filtering . . . . . . . . . . . . . . . . . . 23
5.5. Messages sent through Mailing Lists and other 5.5. Messages sent through Mailing Lists and other
Intermediaries . . . . . . . . . . . . . . . . . . . . . . 23 Intermediaries . . . . . . . . . . . . . . . . . . . . . . 23
5.6. Generation, Transmission and Use of Results Headers . . . 23 5.6. Generation, Transmission and Use of Results Headers . . . 24
6. Taxonomy of Signatures . . . . . . . . . . . . . . . . . . . . 24 6. Taxonomy of Signatures . . . . . . . . . . . . . . . . . . . . 24
6.1. Single Domain Signature . . . . . . . . . . . . . . . . . 24 6.1. Single Domain Signature . . . . . . . . . . . . . . . . . 25
6.2. Parent Domain Signature . . . . . . . . . . . . . . . . . 25 6.2. Parent Domain Signature . . . . . . . . . . . . . . . . . 25
6.3. Third Party Signature . . . . . . . . . . . . . . . . . . 25 6.3. Third Party Signature . . . . . . . . . . . . . . . . . . 26
6.4. Using Trusted 3rd Party Senders . . . . . . . . . . . . . 27 6.4. Using Trusted Third Party Senders . . . . . . . . . . . . 27
6.5. Multiple Signatures . . . . . . . . . . . . . . . . . . . 28 6.5. Multiple Signatures . . . . . . . . . . . . . . . . . . . 28
7. Example Usage Scenarios . . . . . . . . . . . . . . . . . . . 30 7. Example Usage Scenarios . . . . . . . . . . . . . . . . . . . 30
7.1. Author's Organization - Simple . . . . . . . . . . . . . . 30 7.1. Author's Organization - Simple . . . . . . . . . . . . . . 30
7.2. Author's Organization - Differentiated Types of Mail . . . 30 7.2. Author's Organization - Differentiated Types of Mail . . . 31
7.3. Author Signature . . . . . . . . . . . . . . . . . . . . . 30 7.3. Author Signature . . . . . . . . . . . . . . . . . . . . . 31
7.4. Author Domain Signing Practices . . . . . . . . . . . . . 31 7.4. Author Domain Signing Practices . . . . . . . . . . . . . 31
7.5. Delegated Signing . . . . . . . . . . . . . . . . . . . . 33 7.5. Delegated Signing . . . . . . . . . . . . . . . . . . . . 33
7.6. Independent Third Party Service Providers . . . . . . . . 33 7.6. Independent Third Party Service Providers . . . . . . . . 34
7.7. Mail Streams Based on Behavioral Assessment . . . . . . . 34 7.7. Mail Streams Based on Behavioral Assessment . . . . . . . 34
7.8. Agent or Mediator Signatures . . . . . . . . . . . . . . . 34 7.8. Agent or Mediator Signatures . . . . . . . . . . . . . . . 35
8. Usage Considerations . . . . . . . . . . . . . . . . . . . . . 35 8. Usage Considerations . . . . . . . . . . . . . . . . . . . . . 35
8.1. Non-standard Submission and Delivery Scenarios . . . . . . 35 8.1. Non-standard Submission and Delivery Scenarios . . . . . . 35
8.2. Protection of Internal Mail . . . . . . . . . . . . . . . 36 8.2. Protection of Internal Mail . . . . . . . . . . . . . . . 36
8.3. Signature Granularity . . . . . . . . . . . . . . . . . . 36 8.3. Signature Granularity . . . . . . . . . . . . . . . . . . 37
8.4. Email Infrastructure Agents . . . . . . . . . . . . . . . 37 8.4. Email Infrastructure Agents . . . . . . . . . . . . . . . 38
8.5. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 39 8.5. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 39
9. Other Considerations . . . . . . . . . . . . . . . . . . . . . 40 9. Other Considerations . . . . . . . . . . . . . . . . . . . . . 40
9.1. Security Considerations . . . . . . . . . . . . . . . . . 40 9.1. Security Considerations . . . . . . . . . . . . . . . . . 40
9.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 40 9.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 41
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
11. Informative References . . . . . . . . . . . . . . . . . . . . 40 11. Informative References . . . . . . . . . . . . . . . . . . . . 41
Appendix A. Migrating from DomainKeys . . . . . . . . . . . . . . 42 Appendix A. Migrating from DomainKeys . . . . . . . . . . . . . . 42
A.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 42 A.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 43
A.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 45 A.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 46
Appendix B. General Coding Criteria for Cryptographic Appendix B. General Coding Criteria for Cryptographic
Applications . . . . . . . . . . . . . . . . . . . . 46 Applications . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
DomainKeys Identified Mail (DKIM) allows an organization to claim DomainKeys Identified Mail (DKIM) allows an organization to claim
responsibility for transmitting a message, in a way that can be responsibility for transmitting a message, in a way that can be
validated by a recipient. This document provides practical tips for: validated by a recipient. This document provides practical tips for:
those who are developing DKIM software, mailing list managers, those who are developing DKIM software, mailing list managers,
filtering strategies based on the output from DKIM verification, and filtering strategies based on the output from DKIM verification, and
DNS servers; those who are deploying DKIM software, keys, mailing DNS servers; those who are deploying DKIM software, keys, mailing
list software, and migrating from DomainKeys; and those who are list software, and migrating from DomainKeys; and those who are
responsible for the on-going operations of an email infrastructure responsible for the on-going operations of an email infrastructure
that has deployed DKIM. that has deployed DKIM.
The document is organized around the key concepts related to DKIM. The document is organized around the key concepts related to DKIM.
Within each section, additional considerations specific to Within each section, additional considerations specific to
development, deployment, or ongoing operations are highlighted where development, deployment, or ongoing operations are highlighted where
appropriate. appropriate. The possibility of use of DKIM results as input to a
local reputation database is also discussed.
[[anchor2: MSK: maybe this is a good place to mention the possibility
of collecting verification history for selectors domains as a means
of observing over time behaviour of signers for the purpose of
asserting local reputation]]
2. Using DKIM as Part of Trust Assessment 2. Using DKIM as Part of Trust Assessment
2.1. A Systems View of Email Trust Assessment 2.1. A Systems View of Email Trust Assessment
DKIM participates in a trust-oriented enhancement to the Internet's DKIM participates in a trust-oriented enhancement to the Internet's
email service, to facilitate message handling decisions, such as for email service, to facilitate message handling decisions, such as for
delivery and for content display. Trust-oriented message handling delivery and for content display. Trust-oriented message handling
has substantial differences from approaches that consider messages in has substantial differences from approaches that consider messages in
terms of risk and abuse. With trust, there is a collaborative terms of risk and abuse. With trust, there is a collaborative
skipping to change at page 6, line 5 skipping to change at page 5, line 48
the sender, risk-oriented mechanisms will be based on heuristics, the sender, risk-oriented mechanisms will be based on heuristics,
that is, on guessing. Guessing produces statistical results with that is, on guessing. Guessing produces statistical results with
some false negatives and some false positives. For trust-based some false negatives and some false positives. For trust-based
exchanges, the goal is the deterministic exchange of information. exchanges, the goal is the deterministic exchange of information.
For DKIM, that information is the one identifier that represents a For DKIM, that information is the one identifier that represents a
stream of mail for which an independent assessment is sought (by the stream of mail for which an independent assessment is sought (by the
signer.) signer.)
A trust-based service is built upon a validated Responsible A trust-based service is built upon a validated Responsible
Identifier that labels a stream of mail and is controlled by an Identifier that labels a stream of mail and is controlled by an
identity (role, person or organization.) The identity is identity (role, person or organization). The identity is
acknowledging some degree of responsibility for the message stream. acknowledging some degree of responsibility for the message stream.
Given a basis for believing that an identifier is being used in an Given a basis for believing that an identifier is being used in an
authorized manner, the recipient site can make and use an assessment authorized manner, the recipient site can make and use an assessment
of the associated identity. An identity can use different of the associated identity. An identity can use different
identifiers, on the assumption that the different streams might identifiers, on the assumption that the different streams might
produce different assessments. For example, even the best-run produce different assessments. For example, even the best-run
marketing campaigns will tend to produce some complaints that can marketing campaigns will tend to produce some complaints that can
affect the reputation of the associated identifier. Whereas a stream affect the reputation of the associated identifier, whereas a stream
of transactional messages is likely to have a more pristine of transactional messages is likely to have a more pristine
reputation. reputation.
Determining that the identifier's use is valid is quite different Determining that the identifier's use is valid is quite different
from determining that the content of a message is valid. The former from determining that the content of a message is valid. The former
means only that the identifier for the responsible role, person or means only that the identifier for the responsible role, person or
organization has been legitimately associated with a message. The organization has been legitimately associated with a message. The
latter means that the content of the message can be believed and, latter means that the content of the message can be believed and,
typically, that the claimed author of the content is correct. DKIM typically, that the claimed author of the content is correct. DKIM
validates only the presence of the identifier used to sign the validates only the presence of the identifier used to sign the
message. Even when this identifier is validated, DKIM carries no message. Even when this identifier is validated, DKIM carries no
implication that any of the message content, including the implication that any of the message content, including the
RFC5322.From field, is valid. Surprisingly, this limit to the RFC5322.From field, is valid. Surprisingly, this limit to the
semantics of a DKIM signature applies even when the validated signing semantics of a DKIM signature applies even when the validated signing
identifier is the same domain name as is used in the From: field! identifier is the same domain name as is used in the From: field!
DKIM's only claim about message content is that the content cited in DKIM's only claim about message content is that the content cited in
the DKIM-Signature: field's h= tag have been delivered without the DKIM-Signature: field's h= tag has been delivered without
modification. That is, it asserts message content integrity, not modification. That is, it asserts message content integrity, not
message content validity. message content validity.
As shown in Figure 1, this enhancement is a communication between a As shown in Figure 1, this enhancement is a communication between a
responsible role, person or organization that signs the message and a responsible role, person or organization that signs the message and a
recipient organization that assesses its trust in the signer and then recipient organization that assesses its trust in the signer and then
makes handling decisions based on a collection of assessments, of makes handling decisions based on a collection of assessments, of
which the DKIM mechanism is only a part. In this model, validation which the DKIM mechanism is only a part. In this model, validation
is an intermediary step, having the sole task of passing a validated is an intermediary step, having the sole task of passing a validated
Responsible Identifier to the Identity Assessor. The communication Responsible Identifier to the Identity Assessor. The communication
skipping to change at page 8, line 6 skipping to change at page 7, line 49
side, then the sender cannot know what basis for assessment will be side, then the sender cannot know what basis for assessment will be
used. DKIM has three values that specify identification information used. DKIM has three values that specify identification information
and it is easy to confuse their use, although only one defines the and it is easy to confuse their use, although only one defines the
formal input and output of DKIM, with the other two being used for formal input and output of DKIM, with the other two being used for
internal protocol functioning and adjunct purposes, such as auditing internal protocol functioning and adjunct purposes, such as auditing
and debugging. and debugging.
The salient values include the s=, d= and i= parameters in the DKIM- The salient values include the s=, d= and i= parameters in the DKIM-
Signature: header field. In order to achieve the end-to-end Signature: header field. In order to achieve the end-to-end
determinism needed for this collaborative exchange from the signer to determinism needed for this collaborative exchange from the signer to
the assessor, the core model needs to specify that the signer MUST the assessor, the core model needs to specify what the signer is
provide the assessor with a single, opaque value that the signer required to provide to the assessor. The Update to RFC4871
wishes to have used for assessment. This value MUST be the basis for [rfc4871-update]now specifies:
DKIM-based assessment. The signer MAY provide the assessor with a
second, opaque value that MAY be used when reporting problems with DKIM's primary task is to communicate from the Signer to a
the end-to-end DKIM process and MAY be used for additional analysis, recipient-side Identity Assessor a single Signing Domain
such as by the higher-level Handling Filter. These values are Identifier (SDID) that refers to a responsible identity. DKIM MAY
opaque, in that any internal semantics are known only to the signer optionally provide a single responsible Agent or User Identifier
and MUST NOT be assumed by the Assessor, within the confines of (AUID)... A receive-side DKIM verifier MUST communicate the
DKIM's formal signing specification. Assessment MUST use a value as Signing Domain Identifier (d=) to a consuming Identity Assessor
a single, complete and uninterpreted string. module and MAY communicate the User Agent 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.
The single, mandatory value that DKIM supplies as its output is: The single, mandatory value that DKIM supplies as its output is:
d= This specifies the "domain of the signing entity." It is a d= This specifies the "domain of the signing entity." It is a
domain name and is combined with the Selector to form a DNS domain name and is combined with the Selector to form a DNS
query. query... A receive-side DKIM verifier MUST communicate the
Signing Domain Identifier (d=) to a consuming Identity Assessor
module and MAY communicate the User Agent Identifier (i=) if
present.
The adjunct values are: The adjunct values are:
s= This tag specifies the Selector. It is used to discriminate s= This tag specifies the Selector. It is used to discriminate
among different keys that can be used for the same d= domain among different keys that can be used for the same d= domain
name. As discussed in Section 4.3 of [I-D.ietf-dkim-overview]: name. As discussed in Section 4.3 of [I-D.ietf-dkim-overview]:
"If verifiers were to employ the selector as part of a name "If verifiers were to employ the selector as part of a name
assessment mechanism, then there would be no remaining assessment mechanism, then there would be no remaining
mechanism for making a transition from an old, or compromised, mechanism for making a transition from an old, or compromised,
key to a new one." Consequently, the Selector is not key to a new one." Consequently, the Selector is not
skipping to change at page 9, line 23 skipping to change at page 9, line 24
* Look like a mailbox address but might have different semantics * Look like a mailbox address but might have different semantics
and therefore not function as a valid email address and therefore not function as a valid email address
* Be unique for each message, such as indicating access details * Be unique for each message, such as indicating access details
of the user for the specific posting of the user for the specific posting
This underscores why the tag needs to be treated as being opaque, This underscores why the tag needs to be treated as being opaque,
since it can represent any semantics, known only to the signer. since it can represent any semantics, known only to the signer.
Hence, i= serves well as a token that is usable like an Web cookie, Hence, i= serves well as a token that is usable like a Web cookie,
for return to the signing ADMD -- such as for auditing and debugging. for return to the signing ADMD -- such as for auditing and debugging.
Of course in some scenarios the i= string might provide a useful Of course in some scenarios the i= string might provide a useful
adjunct value for additional (heuristic) processing by the Handling adjunct value for additional (heuristic) processing by the Handling
Filter. Filter.
2.3. Choosing the Signing Domain Name 2.3. Choosing the Signing Domain Name
A DKIM signing entity can serve different roles, such as author of A DKIM signing entity can serve different roles, such as author of
content, versus operator of the mail service, versus operator of a content, versus operator of the mail service, versus operator of a
reputation service. In these different roles, the basis for reputation service. In these different roles, the basis for
distinguishing among portions of email traffic can vary. For an distinguishing among portions of email traffic can vary. For an
entity creating DKIM signatures it is likely that different portions entity creating DKIM signatures it is likely that different portions
of their mail will warrant different levels of trust. For example: of its mail will warrant different levels of trust. For example:
* Mail is sent for different purposes, such as marketing vs. * Mail is sent for different purposes, such as marketing vs.
transactional, and recipients demonstrate different patterns of transactional, and recipients demonstrate different patterns of
acceptance between these. acceptance between these.
* For an operator of an email service, there often are distinct * For an operator of an email service, there often are distinct
sub-populations of users warranting different levels of trust sub-populations of users warranting different levels of trust
or privilege, such as paid vs. free users, or users engaged in or privilege, such as paid vs. free users, or users engaged in
direct correspondence vs. users sending bulk mail. direct correspondence vs. users sending bulk mail.
skipping to change at page 12, line 7 skipping to change at page 12, line 7
Assessor can know that two messages with the same DKIM d= identifier Assessor can know that two messages with the same DKIM d= identifier
are, in fact, signed by the same person or organization. This are, in fact, signed by the same person or organization. This
permits a far more stable and accurate assessment of mail traffic permits a far more stable and accurate assessment of mail traffic
using that identifier. using that identifier.
DKIM is distinctive, in that it provides an identifier which is not DKIM is distinctive, in that it provides an identifier which is not
necessarily related to any other identifier in the message. Hence, necessarily related to any other identifier in the message. Hence,
the signer might be the author's ADMD, one of the operators along the the signer might be the author's ADMD, one of the operators along the
transit path, or a reputation service being used by one of those transit path, or a reputation service being used by one of those
handling services. In fact, a message can have multiple signatures, handling services. In fact, a message can have multiple signatures,
possibly by different of these actors. possibly by any number of these actors.
As discussed above, the choice of identifiers needs to be based on As discussed above, the choice of identifiers needs to be based on
differences that the signer thinks will be useful for the recipient differences that the signer thinks will be useful for the recipient
Assessor. Over time, industry practices establish norms for these Assessor. Over time, industry practices establish norms for these
choices. choices.
Absent such norms, it is best for signers to distinguish among Absent such norms, it is best for signers to distinguish among
streams that have significant differences, while consuming the streams that have significant differences, while consuming the
smallest number of identifiers possible. This will limit the smallest number of identifiers possible. This will limit the
burden on recipient Assessors. burden on recipient Assessors.
skipping to change at page 12, line 30 skipping to change at page 12, line 30
assurance about some or all of the message contents, and in assurance about some or all of the message contents, and in
particular that the RFC5322.From field is likely to be valid. In particular that the RFC5322.From field is likely to be valid. In
fact, DKIM makes assurances only about the integrity of the data and fact, DKIM makes assurances only about the integrity of the data and
not about its validity. Still, presumptions of From: field validity not about its validity. Still, presumptions of From: field validity
remain a concern. Hence a signer using a domain name that is remain a concern. Hence a signer using a domain name that is
unrelated to the domain name in the From: field can reasonably expect unrelated to the domain name in the From: field can reasonably expect
that the disparity will warrant some curiosity, at least until that the disparity will warrant some curiosity, at least until
signing by independent operators has produced some established signing by independent operators has produced some established
practice among recipient Assessors. practice among recipient Assessors.
With the identifier(s) supplied by DKIM, the Assessor can consult an
independent assessment service about the entity associated with the
identifier(s). Another possibility is that the Assessor can develop
its own reputation rating for the identifier(s). That is, over time,
the Assessor can observe the stream of messages associated with the
identifier(s) developing a reaction to associated content. For
example, if there is a high percentage of user complaints regarding
signed mail with a "d=" value of "widgetco.example.net", the Assessor
might include that fact in the vector of data it provides to the
Handling Filter. This is also discussed briefly in Section 5.4.
2.5. Filtering 2.5. Filtering
After assessing the signer of a message, each receiving site creates After assessing the signer of a message, each receiving site creates
and tunes its own Handling Filter according to criteria specific for and tunes its own Handling Filter according to criteria specific for
that site. Still, there are commonalities across sites, and this that site. Still, there are commonalities across sites, and this
section offers a discussion, rather than a specification, of some section offers a discussion, rather than a specification, of some
types of input to that process and how they can be used. types of input to that process and how they can be used.
The discussion focuses on variations in Organizational Trust versus The discussion focuses on variations in Organizational Trust versus
Message Risk. That is, the degree of positive assessment of a DKIM- Message Risk, that is, the degree of positive assessment of a DKIM-
signing organization, and the potential danger present in the message signing organization, and the potential danger present in the message
stream signed by that organization. While it might seem that higher stream signed by that organization. While it might seem that higher
trust automatically means lower risk, the experience with real-world trust automatically means lower risk, the experience with real-world
operations provides examples of every combination of the two factors, operations provides examples of every combination of the two factors,
as shown in Table 1. Only 3 levels of granularity are listed, in as shown in Table 1. Only three levels of granularity are listed, in
order to keep discussion manageable. This also ensures extensive order to keep discussion manageable. This also ensures extensive
flexibility for each site's detailed choices. flexibility for each site's detailed choices.
+---+---------------------+--------------------+--------------------+ +---+---------------------+--------------------+--------------------+
| | Low | Medium | High | | | Low | Medium | High |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| O | | | | | O | | | |
skipping to change at page 14, line 15 skipping to change at page 14, line 18
3. DKIM Key Generation, Storage, and Management 3. DKIM Key Generation, Storage, and Management
By itself, verification of a digital signature only allows the By itself, verification of a digital signature only allows the
verifier to conclude with a very high degree of certainty that the verifier to conclude with a very high degree of certainty that the
signature was created by a party with access to the corresponding signature was created by a party with access to the corresponding
private signing key. It follows that a verifier requires means to private signing key. It follows that a verifier requires means to
(1) obtain the public key for the purpose of verification and (2) (1) obtain the public key for the purpose of verification and (2)
infer useful attributes of the key holder. infer useful attributes of the key holder.
In a traditional Public Key Infrastructure (PKI), the functions of In a traditional Public Key Infrastructure (PKI), the functions of
key distribution and key accreditation are separated. In DKIM, these key distribution and key accreditation are separated. In DKIM
functions are both performed through the DNS [RFC4871] (Allman, E., [RFC4871], these functions are both performed through the DNS.
Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas,
"DomainKeys Identified Mail (DKIM) Signatures," May 2007.).
In either case, the ability to infer semantics from a digital In either case, the ability to infer semantics from a digital
signature depends on the assumption that the corresponding private signature depends on the assumption that the corresponding private
key is only accessible to a party with a particular set of key is only accessible to a party with a particular set of
attributes. In traditional PKI a Trusted Third Party (TTP) vouches attributes. In traditional PKI, a Trusted Third Party (TTP) vouches
that the key holder has been validated with respect to a specified that the key holder has been validated with respect to a specified
set of attributes. The range of attributes that may be attested in set of attributes. The range of attributes that may be attested in
such a scheme is thus limited only to the type of attributes that a such a scheme is thus limited only to the type of attributes that a
TTP can establish effective processes for validating. TTP can establish effective processes for validating. In DKIM,
Trusted Third parties are not employed and the functions of key
distribution and accreditation are combined.
In DKIM, TTPs are not employed and the functions of key distribution Consequently there are only two types of inference that a signer may
and accreditation are combined. Consequently there are only two make from a key published in a DKIM Key Record:
types of inference that a signer may make from a key published in a
DKIM Key Record:
1. That a party with the ability to control DNS records within a DNS 1. That a party with the ability to control DNS records within a DNS
zone intends to claim responsibility for messages signed using zone intends to claim responsibility for messages signed using
the corresponding private signature key. the corresponding private signature key.
2. That use of a specific key is restricted to a particular subset 2. That use of a specific key is restricted to the particular subset
of messages. of messages identified by the selector.
The ability to draw any useful conclusion from verification of a The ability to draw any useful conclusion from verification of a
digital signature relies on the assumption that the corresponding digital signature relies on the assumption that the corresponding
private key is only accessible to a party with a particular set of private key is only accessible to a party with a particular set of
attributes. In the case of DKIM, this means that the party that attributes. In the case of DKIM, this means that the party that
created the corresponding DKIM key record in the specific zone created the corresponding DKIM key record in the specific zone
intended to claim responsibility for the signed message. intended to claim responsibility for the signed message.
Ideally we would like to draw a stronger conclusion, that if we Ideally we would like to draw a stronger conclusion, that if we
obtain a DKIM key record from the DNS zone example.com, that the obtain a DKIM key record from the DNS zone example.com, that the
skipping to change at page 15, line 14 skipping to change at page 15, line 17
of the DNS zone and corresponding private key are adequate. of the DNS zone and corresponding private key are adequate.
3.1. Private Key Management: Deployment and Ongoing Operations 3.1. Private Key Management: Deployment and Ongoing Operations
Access to signing keys MUST be carefully managed to prevent use by Access to signing keys MUST be carefully managed to prevent use by
unauthorized parties and to minimize the consequences if a compromise unauthorized parties and to minimize the consequences if a compromise
were to occur. were to occur.
While a DKIM signing key is used to sign messages on behalf of many While a DKIM signing key is used to sign messages on behalf of many
mail users, the signing key itself SHOULD be under direct control of mail users, the signing key itself SHOULD be under direct control of
as few key-holders as possible. If a key-holder were to leave the as few key holders as possible. If a key holder were to leave the
organization, all signing keys held by that key holder SHOULD be organization, all signing keys held by that key holder SHOULD be
withdrawn from service and if appropriate, replaced. withdrawn from service and if appropriate, replaced.
If key management hardware support is available, it SHOULD be used. If key management hardware support is available, it SHOULD be used.
If keys are stored in software, appropriate file control protections If keys are stored in software, appropriate file control protections
MUST be employed, and any location in which the private key is stored MUST be employed, and any location in which the private key is stored
in plaintext form SHOULD be excluded from regular backup processes in plaintext form SHOULD be excluded from regular backup processes
and SHOULD not be accessible through any form of network including and SHOULD not be accessible through any form of network including
private local area networks. Auditing software SHOULD be used private local area networks. Auditing software SHOULD be used
periodically to verify that the permissions on the private key files periodically to verify that the permissions on the private key files
skipping to change at page 15, line 40 skipping to change at page 15, line 43
and only the public key component transferred to another party. If and only the public key component transferred to another party. If
this is not possible, the private key MUST be transported in an this is not possible, the private key MUST be transported in an
encrypted format that protects the confidentiality of the signing encrypted format that protects the confidentiality of the signing
key. A shared directory on a local file system does not provide key. A shared directory on a local file system does not provide
adequate security for distribution of signing keys in plaintext form. adequate security for distribution of signing keys in plaintext form.
Key escrow schemes are not necessary and SHOULD NOT be used. In the Key escrow schemes are not necessary and SHOULD NOT be used. In the
unlikely event of a signing key becomming lost, a new signature key unlikely event of a signing key becomming lost, a new signature key
pair may be generated as easily as recovery from a key escrow scheme. pair may be generated as easily as recovery from a key escrow scheme.
Responsibility for the security of a signing key SHOULD ultimately To enable accountability and auditing:
vest in a single named individual. Where multiple parties are
authorized to sign messages, each signer SHOULD use a different key o Responsibility for the security of a signing key SHOULD ultimately
to enable accountability and auditing. vest in a single named individual.
o Where multiple parties are authorized to sign messages, each
signer SHOULD use a different key to enable accountability and
auditing.
Best practices for management of cryptographic keying material Best practices for management of cryptographic keying material
require keying material to be refreshed at regular intervals, require keying material to be refreshed at regular intervals,
particular where key management is achieved through software. While particularly where key management is achieved through software.
this practice is highly desirable it is of considerably less While this practice is highly desirable it is of considerably less
importance than the requirement to maintain the secrecy of the importance than the requirement to maintain the secrecy of the
corresponding private key. An operational practice in which the corresponding private key. An operational practice in which the
private key is stored in tamper proof hardware and changed once a private key is stored in tamper proof hardware and changed once a
year is considerably more desirable than one in which the signature year is considerably more desirable than one in which the signature
key is changed on an hourly basis but maintained in software. key is changed on an hourly basis but maintained in software.
3.2. Storing Public Keys: DNS Server Software Considerations 3.2. Storing Public Keys: DNS Server Software Considerations
In order to use DKIM a DNS domain holder requires (1) the ability to In order to use DKIM a DNS domain holder requires (1) the ability to
create the necessary DKIM DNS records and (2) sufficient operational create the necessary DKIM DNS records and (2) sufficient operational
security controls to prevent insertion of spurious DNS records by an security controls to prevent insertion of spurious DNS records by an
attacker. attacker.
DNS record management is usually operated by an administrative staff DNS record management is often operated by an administrative staff
that is different from those who operate an organization's email that is different from those who operate an organization's email
service. In order to ensure that DKIM DNS records are accurate, this service. In order to ensure that DKIM DNS records are accurate, this
imposes a requirement for careful coordination between the two imposes a requirement for careful coordination between the two
operations groups. If the best practices for private key management operations groups. If the best practices for private key management
described above are observed, such deployment is not a one time described above are observed, such deployment is not a one time
event, DNS DKIM selectors will be changed over time signing keys are event; DNS DKIM selectors will be changed over time signing keys are
terminated and replaced. terminated and replaced.
At a minimum, a DNS server that handles queries for DKIM key records At a minimum, a DNS server that handles queries for DKIM key records
MUST allow the server administrators to add free-form TXT records. MUST allow the server administrators to add free-form TXT records.
It would be better if the the DKIM records could be entered using a It would be better if the the DKIM records could be entered using a
structured form, supporting the DKIM-specific fields. structured form, supporting the DKIM-specific fields.
Ideally DNSSEC [RFC4034] SHOULD be employed in a configuration that Ideally DNSSEC [RFC4034] SHOULD be employed in a configuration that
provides protection against record insertion attacks and zone provides protection against record insertion attacks and zone
enumeration. In the case that NSEC3 [RFC5155] records are employed enumeration. In the case that NSEC3 [RFC5155] records are employed
skipping to change at page 17, line 21 skipping to change at page 17, line 26
there is no means by which external parties may make use of such keys there is no means by which external parties may make use of such keys
to attribute messages with any greater granularity than a DNS domain. to attribute messages with any greater granularity than a DNS domain.
If per-user signing keys are assigned for internal purposes (e.g. If per-user signing keys are assigned for internal purposes (e.g.
authenticating messages sent to an MTA for distribution), the authenticating messages sent to an MTA for distribution), the
following issues need to be considered before using such signatures following issues need to be considered before using such signatures
as an alternative to traditional edge signing at the outbound MTA: as an alternative to traditional edge signing at the outbound MTA:
External verifiers will be unable to make use of the additional External verifiers will be unable to make use of the additional
signature granularity without access to additional information signature granularity without access to additional information
passed out of band with respect to DKIM-base. passed out of band with respect to [RFC4871].
If the number of user keys is large, the efficiency of local If the number of user keys is large, the efficiency of local
caching of key records by verifiers will be lower. caching of key records by verifiers will be lower.
A large number of end users may be less likely to be able to A large number of end users may be less likely to be able to
manage private key data securely on their personal computer than manage private key data securely on their personal computer than
an administrator running an edge MTA. an administrator running an edge MTA.
3.4. Third Party Signer Key Management and Selector Administration 3.4. Third Party Signer Key Management and Selector Administration
A DKIM key record only asserts that the holder of the corresponding A DKIM key record only asserts that the holder of the corresponding
domain name makes a claim of responsibility for messages signed under domain name makes a claim of responsibility for messages signed under
the corresponding key. In some applications, such as bulk mail the corresponding key. In some applications, such as bulk mail
delivery it is desirable to delegate the ability to make a claim of delivery, it is desirable to delegate the ability to make a claim of
responsibility to another party. In this case the trust relationship responsibility to another party. In this case the trust relationship
is established between the domain holder and the verifier but the is established between the domain holder and the verifier but the
private signature key is held by a third party. private signature key is held by a third party.
Signature keys used by a third party signer SHOULD be kept entirely Signature keys used by a third party signer SHOULD be kept entirely
separate from those used by the domain holder and other third party separate from those used by the domain holder and other third party
signers. As with any other private key, the signature key pair signers. To limit potential exposure of the private key, the
SHOULD be generated by the third party signer and the public signature key pair SHOULD be generated by the third party signer and
component of the key transmitted to the domain holder rather than the public component of the key transmitted to the domain holder,
have the domain holder generate the key pair and transmit the private rather than have the domain holder generate the key pair and transmit
component to the third party signer. the private component to the third party signer.
Domain holders SHOULD adopt a least privilege approach and grant Domain holders SHOULD adopt a least privilege approach and grant
third party signers the minimum access necessary to perform the third party signers the minimum access necessary to perform the
desired function. Limiting the access granted to Third Party Signers desired function. Limiting the access granted to Third Party Signers
serves to protect the interests of both parties. The domain holder serves to protect the interests of both parties. The domain holder
minimizes their security risk and the Trusted Third Party Signer minimizes its security risk and the Trusted Third Party Signer avoids
avoids unnecessary liability. unnecessary liability.
In the most restrictive case a domain holder maintains full control In the most restrictive case a domain holder maintains full control
over the creation of key records and employ appropriate key record over the creation of key records and employs appropriate key record
restrictions to enforce restrictions on the messages for which the restrictions to enforce restrictions on the messages for which the
third party signer is able to sign. If such restrictions are third party signer is able to sign. If such restrictions are
impractical, the domain holder SHOULD delegate a DNS subzone for impractical, the domain holder SHOULD delegate a DNS subzone for
publishing key records to the third party signer. The domain holder publishing key records to the third party signer. The domain holder
SHOULD not allow a third party signer unrestricted access to their SHOULD not allow a third party signer unrestricted access to its DNS
DNS service for the purpose of publishing key records. service for the purpose of publishing key records.
3.5. Key Pair / Selector Lifecycle Management 3.5. Key Pair / Selector Lifecycle Management
Deployments SHOULD establish, document and observe processes for Deployments SHOULD establish, document and observe processes for
managing the entire lifecycle of a public key pair. managing the entire lifecycle of a public key pair.
3.5.1. Example Key Deployment Process 3.5.1. Example Key Deployment Process
When it is determined that a new key pair is required: When it is determined that a new key pair is required:
1. A Key Pair is generated by the signing device 1. A Key Pair is generated by the signing device.
2. A proposed key selector record is generated and transmitted to 2. A proposed key selector record is generated and transmitted to
the DNS administration infrasrtructure. the DNS administration infrasrtructure.
3. The DNS administration infrastructure verifies the authenticity 3. The DNS administration infrastructure verifies the authenticity
of the key selector registration request. If accepted of the key selector registration request. If accepted
1. A key selector is assigned. 1. A key selector is assigned.
2. The corresponding key record published in the DNS. 2. The corresponding key record published in the DNS.
skipping to change at page 19, line 16 skipping to change at page 19, line 21
2. Signer deletes all records of the private key, including in- 2. Signer deletes all records of the private key, including in-
memory copies at the signing device. memory copies at the signing device.
3. Signer notifies the DNS administration infrasrtructure that the 3. Signer notifies the DNS administration infrasrtructure that the
signing key is withdrawn from service and that the corresponding signing key is withdrawn from service and that the corresponding
key records may be withdrawn from service at a specified future key records may be withdrawn from service at a specified future
date. date.
4. The DNS administration infrastructure verifies the authenticity 4. The DNS administration infrastructure verifies the authenticity
of the key selector termination request. If accepted of the key selector termination request. If accepted,
1. The key selector is scheduled for deletion at a future time 1. The key selector is scheduled for deletion at a future time
determined by site policy. determined by site policy.
2. Wait for deletion time to arrive 2. Wait for deletion time to arrive.
3. The key selector is deleted 3. The signer either publishes a revocation key selector with an
empty "p=" field, or deletes the key selector record
entirely.
5. As far as the verifier is concerned, there is no functional
difference between verifying against a key selector with an empty
"p=" field, and verifying against a missing key selector: both
result in a failed signature and the signature should be treated
as if it had not been there. However, there is a minor semantic
difference: with the empty "p=" field, the signer is explicitly
stating that the key has been revoked. The empty "p=" record
provides a gravestone for an old selector, making it less likely
that the selector might be accidently reused with a different
public key.
4. Signing 4. Signing
Creating messages that have one or more DKIM signatures, requires Creating messages that have one or more DKIM signatures, requires
support in only two outbound email service components: support in only two outbound email service components:
o A DNS Administrative interface that can create and maintain the o A DNS Administrative interface that can create and maintain the
relevant DNS names -- including names with underscores -- and relevant DNS names -- including names with underscores -- and
resource records (RR). resource records (RR).
skipping to change at page 22, line 13 skipping to change at page 22, line 30
message as being authenticated by the signature. message as being authenticated by the signature.
For example, if the l= option is employed to specify a content length For example, if the l= option is employed to specify a content length
for the scope of the signature, only the part of the message that is for the scope of the signature, only the part of the message that is
within the scope of the content signature would be considered within the scope of the content signature would be considered
authentic. authentic.
5.3. Design Scope of Use 5.3. Design Scope of Use
Public Key cryptography provides an exceptionally high degree of Public Key cryptography provides an exceptionally high degree of
assurance bordering on absolute certainty, that the party that assurance, bordering on absolute certainty, that the party that
created a valid digital signature had access to the private key created a valid digital signature had access to the private key
corresponding to the public key indicated in the signature. corresponding to the public key indicated in the signature.
In order to make useful conclusions from the verification of a valid In order to make useful conclusions from the verification of a valid
digital signature, the verifier is obliged to make assumptions that digital signature, the verifier is obliged to make assumptions that
fall far short of absolute certainty. Consequently, mere validation fall far short of absolute certainty. Consequently, mere validation
of a DKIM signature does not represent proof positive that a valid of a DKIM signature does not represent proof positive that a valid
claim of responsibility was made for it by the indicated party, that claim of responsibility was made for it by the indicated party, that
the message is authentic or that the message is not abusive. In the message is authentic, or that the message is not abusive. In
particular: particular:
o The legitimate private key holder may have lost control of their o The legitimate private key holder may have lost control of its
private key. private key.
o The legitimate domain holder may have lost control of the DNS o The legitimate domain holder may have lost control of the DNS
server for the zone from which the key record was retrieved. server for the zone from which the key record was retrieved.
o The key record may not have been delivered from the legitimate DNS o The key record may not have been delivered from the legitimate DNS
server for the zone from which the key record was retrieved. server for the zone from which the key record was retrieved.
o Ownership of the DNS zone may have changed. o Ownership of the DNS zone may have changed.
In practice these limitations have little or no impact on the field In practice these limitations have little or no impact on the field
of use for which DKIM is designed but may have a bearing if use is of use for which DKIM is designed but may have a bearing if use is
made of the DKIM message signature format or key retrieval mechanism made of the DKIM message signature format or key retrieval mechanism
in other specifications. in other specifications.
In particular the DKIM key retrieval mechanism is designed for ease In particular the DKIM key retrieval mechanism is designed for ease
of use and deployment rather than to provide a high assurance public of use and deployment rather than to provide a high assurance Public
Key Infrastructure suitable for purposes that require robust non- Key Infrastructure suitable for purposes that require robust non-
repudiation such as establishing legally binding contracts. repudiation such as establishing legally binding contracts.
Developers seeking to extend DKIM beyond its design application Developers seeking to extend DKIM beyond its design application
SHOULD consider replacing or supplementing the DNS key retreival SHOULD consider replacing or supplementing the DNS key retreival
mechanism with one that is designed to meet the intended purposes. mechanism with one that is designed to meet the intended purposes.
5.4. Inbound Mail Filtering 5.4. Inbound Mail Filtering
DKIM is frequently employed in a mail filtering strategy to avoid the DKIM is frequently employed in a mail filtering strategy to avoid
need to perform content analysis on email originating from trusted performing content analysis on email originating from trusted
sources. Messages that carry a valid DKIM signature from a trusted sources. Messages that carry a valid DKIM signature from a trusted
source may be whitelisted, avoiding the need to perform computation source may be whitelisted, avoiding the need to perform computation
and hence energy intensive content analysis to determine the and hence energy intensive content analysis to determine the
disposition of the message. disposition of the message.
Mail sources may be determined to be trusted by means of previously Mail sources may be determined to be trusted by means of previously
observed behavior and/or reference to external reputation or observed behavior and/or reference to external reputation or
accreditation services. The precise means by which this is accreditation services. The precise means by which this is
acomplished is outside the scope of DKIM. acomplished is outside the scope of DKIM.
skipping to change at page 23, line 34 skipping to change at page 24, line 8
intermediary may cause the message content to change in ways that intermediary may cause the message content to change in ways that
prevent the signature passing verification. prevent the signature passing verification.
Such intermediaries are strongly encouraged to deploy DKIM signing so Such intermediaries are strongly encouraged to deploy DKIM signing so
that a verifiable claim of responsibility remains available to that a verifiable claim of responsibility remains available to
parties attempting to verify the modified message. parties attempting to verify the modified message.
5.6. Generation, Transmission and Use of Results Headers 5.6. Generation, Transmission and Use of Results Headers
In many deployments it is desirable to separate signature In many deployments it is desirable to separate signature
verification from the application relying on the verification. For verification from the application relying on the verification. A
example, if: system may choose to relay information indicating the results of its
message authentication efforts using various means; adding a "results
header" to the message is one such mechanism. [RFC5451] For example,
consider the cases where:
o The relying application is not capable of performing DKIM o The application relying on DKIM signature verification is not
signature verification. capable of performing the verification.
o The message may be modified after the signature verification is o The message may be modified after the signature verification is
performed. performed.
o The signature key may not be available by the time that the o The signature key may not be available by the time that the
message is read. message is read.
In such cases it is important that the communication link between the In such cases it is important that the communication link between the
signature verifier and the relying application be sufficiently secure signature verifier and the relying application be sufficiently secure
to prevent insertion of a message that carries a bogus results to prevent insertion of a message that carries a bogus results
header. header.
An intermediary that generates results headers SHOULD ensure that An intermediary that generates results headers SHOULD ensure that
relying applications are able to distinguish valid results headers relying applications are able to distinguish valid results headers
issued by the intermediary from those introduced by an attacker. For issued by the intermediary from those introduced by an attacker. For
example, this can be accomplished by signing the results header. At example, this can be accomplished by signing the results header. At
a minimum, results headers on incoming messages SHOULD be removed if a minimum, results headers on incoming messages SHOULD be removed if
they purport to have been issued by the intermediary but cannot be they purport to have been issued by the intermediary but cannot be
verified as authentic. verified as authentic.
Further discussion on trusting the results as relayed from a verifier
to something downstream can be found in [RFC5451]
6. Taxonomy of Signatures 6. Taxonomy of Signatures
A DKIM signature tells the signature verifier that the owner of a A DKIM signature tells the signature verifier that the owner of a
particular domain name accepts some responsibility for the message. particular domain name accepts some responsibility for the message.
It does not, in and of itself, provide any information about the It does not, in and of itself, provide any information about the
trustworthiness or behavior of that identity. What it does provide trustworthiness or behavior of that identity. What it does provide
is a verified identity to which such behavioral information can be is a verified identity to which such behavioral information can be
associated, so that those who collect and use such information can be associated, so that those who collect and use such information can be
assured that it truly pertains to the identity in question. assured that it truly pertains to the identity in question.
This section lays out a taxonomy of some of the different identities, This section lays out a taxonomy of some of the different identities,
or combinations of identities, that might usefully be represented by or combinations of identities, that might usefully be represented by
a DKIM signature. a DKIM signature.
6.1. Single Domain Signature 6.1. Single Domain Signature
Perhaps the simplest case is when an organization signs its own Perhaps the simplest case is when an organization signs its own
outbound email using its own domain in the d= tag of the signature. outbound email using its own domain in the SDID ([rfc4871-update]) of
For example, Company A would sign the outbound mail from its the signature. For example, Company A would sign the outbound mail
employees with d=companyA.example. from its employees with d=companyA.example.
In the most straightforward configuration, the addresses in the RFC In the most straightforward configuration, the addresses in the RFC
5322 From would also be in the companyA.example domain, but that 5322 From would also be in the companyA.example domain, but that
direct correlation is not required. direct correlation is not required.
A special case of the Single Domain Signature is an Author Signature A special case of the Single Domain Signature is an Author Signature
as defined by the Author Domain Signing Practices specification. as defined by the Author Domain Signing Practices specification
Author signatures are signatures from an author's organization that ([I-D.ietf-dkim-ssp]). Author signatures are signatures from an
have an i= value that matches the From: address of the message. author's organization that have an SDID value that matches that of an
Under the ADSP specification, an i= value matches a RFC 5322 From RFC5322 From: address of the signed message.
address when the domains of the two match exactly, and if the i=
value contains a local part it also matches the local part of the
From: address exactly.
Although an author signature might in some cases be proof against Although an author signature might in some cases be proof against
domain name spoofing the RFC 5322 From address, it is important to spoofing the domain name of the RFC 5322 From address, it is
note that the DKIM and ADSP validation apply only to the exact important to note that the DKIM and ADSP validation apply only to the
address string and not to look-alike addresses nor to the human- exact address string and not to look-alike addresses nor to the
friendly "display-name" or names and addresses used within the body human-friendly "display-name" or names and addresses used within the
of the message. That is, it protects only against the misuse of a body of the message. That is, it protects only against the misuse of
precise address string within the RFC5322 From field and nothing a precise address string within the RFC5322 From field and nothing
else. For example, a message from bob@domain.example with a valid else. For example, a message from bob@domain.example with a valid
signature where i=d0main.example would fail an ADSP check because the signature where d=d0main.example would fail an ADSP check because the
signature domain, however similar, is distinct; however a message signature domain, however similar, is distinct; however a message
from bob@d0main.example with a valid signature where i=d0main.example from bob@d0main.example with a valid signature where d=d0main.example
would pass an ADSP check, even though to a human it might be obvious would pass an ADSP check, even though to a human it might be obvious
that d0main.example is likely a malicious attempt to spoof the domain that d0main.example is likely a malicious attempt to spoof the domain
domain.example. This example highlights that ADSP, like DKIM, is domain.example. This example highlights that ADSP, like DKIM, is
only able to validate a signing identifier: it still requires some only able to validate a signing identifier: it still requires some
external process to attach a meaningful reputation to that external process to attach a meaningful reputation to that
identifier. identifier.
6.2. Parent Domain Signature 6.2. Parent Domain Signature
Another approach that might be taken by an organization with multiple Another approach that might be taken by an organization with multiple
skipping to change at page 25, line 38 skipping to change at page 26, line 13
Section 2.3, if the type of mail sent from the different subdomains Section 2.3, if the type of mail sent from the different subdomains
is significantly different or if there is reason to believe that the is significantly different or if there is reason to believe that the
reputation of the subdomains would differ, then it may be a good idea reputation of the subdomains would differ, then it may be a good idea
to acknowledge this and provide distinct signatures for each of the to acknowledge this and provide distinct signatures for each of the
subdomains (d=marketing.domain.example, sales.domain.example, etc.). subdomains (d=marketing.domain.example, sales.domain.example, etc.).
However, if the mail and reputations are likely to be similar, then However, if the mail and reputations are likely to be similar, then
the simpler approach of using a single common parent domain in the the simpler approach of using a single common parent domain in the
signature may work well. signature may work well.
Another approach to distinguishing the streams using a single DKIM Another approach to distinguishing the streams using a single DKIM
key would be to leverage the i= tag in the DKIM signature to key would be to leverage the AUID [rfc4871-update] (i= tag) in the
differentiate the mail streams. For example, marketing email would DKIM signature to differentiate the mail streams. For example,
be signed with i=marketing.domain.example and d=domain.example. marketing email would be signed with i=marketing.domain.example and
d=domain.example.
It's important to remember, however, that under core DKIM semantics It's important to remember, however, that under core DKIM semantics
the i= identifer is opaque to receivers. That means that it will the AUID is opaque to receivers. That means that it will only be an
only be an effective differentiator if there is an out of band effective differentiator if there is an out of band agreement about
agreement about the i= semantics (e.g., the semantics specified in the i= semantics.
ADSP).
6.3. Third Party Signature 6.3. Third Party Signature
A signature whose domain does not match the domain of the RFC 5322 A signature whose domain does not match the domain of the RFC 5322
From address is sometimes referred to as a third party signature. In From address is sometimes referred to as a third party signature. In
certain cases even the parent domain signature described above would certain cases even the parent domain signature described above would
be considered a third party signature because it would not be an be considered a third party signature because it would not be an
exact match for the domain in the From: address. exact match for the domain in the From: address.
Although there is often heated debate about the value of third-party Although there is often heated debate about the value of third party
signatures, it is important to note that the DKIM specification signatures, it is important to note that the DKIM specification
attaches no particular significance to the identity in a DKIM attaches no particular significance to the identity in a DKIM
signature. The identity specified within the signature is the signature. The identity specified within the signature is the
identity that is taking responsibility for the message, and it is identity that is taking responsibility for the message, and it is
only the interpretation of a given receiver that gives one identity only the interpretation of a given receiver that gives one identity
more or less significance than another. In particular, most more or less significance than another. In particular, most
independent reputation services assign trust based on the specific independent reputation services assign trust based on the specific
identifier string, not its "role": in general they make no identifier string, not its "role": in general they make no
distinction between, for example, an author signature and a third distinction between, for example, an author signature and a third
party signature. party signature.
For some, a signature unrelated to the author (identity in the RFC For some, a signature unrelated to the author domain (the domain in
5322 From address) is less valuable because there is an assumption the RFC 5322 From address) is less valuable because there is an
that the presence of an author signature guarantees that the use of assumption that the presence of an author signature guarantees that
the address in the From: header is authorized. the use of the address in the From: header is authorized.
For others, that relevance is tied strictly to the recorded For others, that relevance is tied strictly to the recorded
behavioral data assigned to the identity in question, i.e. its trust behavioral data assigned to the identity in question, i.e. its trust
assessment or reputation. The reasoning here is that an identity assessment or reputation. The reasoning here is that an identity
with a good reputation is unlikely to maintain that good reputation with a good reputation is unlikely to maintain that good reputation
if it is in the habit of vouching for messages that are unwanted or if it is in the habit of vouching for messages that are unwanted or
abusive; in fact, doing so will rapidly degrade its reputation so abusive; in fact, doing so will rapidly degrade its reputation so
that future messages will no longer benefit from it. It is therefore that future messages will no longer benefit from it. It is therefore
low risk to facilitate the delivery of messages that contain a valid low risk to facilitate the delivery of messages that contain a valid
signature of a domain with a strong positive reputation, independent signature of a domain with a strong positive reputation, independent
of whether or not that domain is associated with the address in the of whether or not that domain is associated with the address in the
RFC5322 From header field of the message. RFC5322 From header field of the message.
Third party signatures encompass a wide range of identities. Some of Third party signatures encompass a wide range of identities. Some of
the more common are: the more common are:
Service Provider: In cases where email is outsourced to an Email Service Provider: In cases where email is outsourced to an Email
Service Provider (ESP), Internet Service Provider (ISP), or other Service Provider (ESP), Internet Service Provider (ISP), or other
type of service provider, that service provider may choose to DKIM type of service provider, that service provider may choose to DKIM
sign outbound mail with either its own identifier -- relying on sign outbound mail with either its own identifier -- relying on
its own, aggregate reptutation -- or with a subdomain of the its own, aggregate reputation -- or with a subdomain of the
provider that is unique to the message author but still part of provider that is unique to the message author but still part of
the provider's aggregate reputation. Such service providers may the provider's aggregate reputation. Such service providers may
also encompass delegated business functions such as benefit also encompass delegated business functions such as benefit
management, although these will more often be treated as trusted management, although these will more often be treated as trusted
third party senders (see below). third party senders (see below).
Parent Domain. As discussed above, organizations choosing to sign Parent Domain. As discussed above, organizations choosing to apply a
for mail originating from subdomains with a parent domain parent domain signature to mail originating from subdomains may
signature may also considered to be using 3rd party signatures in have their signatures treated as third party by some verifiers,
some configurations, depending on whether or not the "t=s" tag is depending on whether or not the "t=s" tag is used to constrain the
used to constrain the parent signature to apply to only its own parent signature to apply only to its own specific domain. The
specific domain. The default is that a parent domain signature is default is to consider a parent domain signature valid for its
considered valid for its subdomains. subdomains.
Reputation Provider: Another possible category of third party Reputation Provider: Another possible category of third party
signature would be the identity of a 3rd party reputation signature would be the identity of a third party reputation
provider. Such a signature would indicate to receivers that the provider. Such a signature would indicate to receivers that the
message was being vouched for by that 3rd party. message was being vouched for by that third party.
6.4. Using Trusted 3rd Party Senders 6.4. Using Trusted Third Party Senders
For most of the cases described so far, there has been an assumption For most of the cases described so far, there has been an assumption
that the identity doing the signing was responsible for creating and that the signing agent was responsible for creating and maintaining
maintaining their own DKIM signing infrastructure, including their its own DKIM signing infrastructure, including its own keys, and
own keys, and signing with their own identity. signing with its own identity.
A different model arises when an organization uses a trusted third A different model arises when an organization uses a trusted third
party sender for certain key business functions, but still wants that party sender for certain key business functions, but still wants that
email to benefit from the organization's own identity and reputation: email to benefit from the organization's own identity and reputation:
in other words, the mail would come out of the trusted 3rd party's in other words, the mail would come out of the trusted third party's
mail servers, but the signature applied would be that of the mail servers, but the signature applied would be that of the
controlling organization. controlling organization.
This can be done by having the 3rd party generate a key pair that is This can be done by having the third party generate a key pair that
designated uniquely for use by that trusted 3rd party and publishing is designated uniquely for use by that trusted third party and
the public key in the controlling organization's DNS domain, thus publishing the public key in the controlling organization's DNS
enabling the third party to sign mail using the signature of the domain, thus enabling the third party to sign mail using the
controlling organization. For example, if Company A outsources its signature of the controlling organization. For example, if Company A
employee benefits to a 3rd party, they can use a special keypair that outsources its employee benefits to a third party, it can use a
enables the benefits company to sign mail as "companyA.example". special keypair that enables the benefits company to sign mail as
Because the keypair is unique to that trusted 3rd party, it is easy "companyA.example". Because the keypair is unique to that trusted
for Company A to revoke the authorization if necessary by simply third party, it is easy for Company A to revoke the authorization if
removing the public key from the companyA.example DNS. necessary by simply removing the public key from the companyA.example
DNS.
In this scenario, it is usually a good idea to limit the specific In this scenario, may be a good idea to limit the specific identities
identities that can be used by even trusted third parties. The DKIM that can be used by even trusted third parties. The DKIM g= tag
g= tag enables a key record to specify one particular From: address enables a key record to specify one particular From: address local
local part that must be specified in the i= tag of the signature: for part that must be specified in the i= tag of the signature: for
example, "g=benefits" would require a signature header tag of example, "g=benefits" would require a signature header tag of
"i=benefits@companyA.example". It is important to note that although "i=benefits@companyA.example". It is important to note that although
this distinction will be clear to the verifier it may be invisible to this distinction will be clear to the verifier it may be invisible to
the recipient: there is no constraint within the DKIM verification the recipient: there is no constraint within the DKIM verification
process that constrains that specific i= value to correspond to any process that constrains that specific i= value to correspond to any
of the other message headers. of the other message headers, including the From: header.
A more reliable way of distinguishing the third part mail stream A more reliable way of distinguishing the third party mail stream
would be to create a dedicated subdomain (e.g. would be to create a dedicated subdomain (e.g.
benefits.companyA.example) and publish the public key there; the benefits.companyA.example) and publish the public key there; the
signature would then use d=benefits.companyA.example. signature would then use d=benefits.companyA.example.
6.4.1. DNS Delegation 6.4.1. DNS Delegation
Another possbility for configuring trusted third party access is to Another possibility for configuring trusted third party access, as
have Company A use DNS delegation and have the designated subdomain discussed in section 3.4, is to have Company A use DNS delegation and
managed directly by the trusted third party. In this case, Company A have the designated subdomain managed directly by the trusted third
would create a subdomain benefits.companya.example, and delegate the party. In this case, Company A would create a subdomain
DNS management of that subdomain to the benefits company so it could benefits.companya.example, and delegate the DNS management of that
maintain its own key records. Should revocation become necessary, subdomain to the benefits company so it could maintain its own key
Company A could simply remove the DNS delegation record. records. Should revocation become necessary, Company A could simply
remove the DNS delegation record.
6.5. Multiple Signatures 6.5. Multiple Signatures
A simple configuration for DKIM-signed mail is to have a single A simple configuration for DKIM-signed mail is to have a single
signature on a given message. This works well for domains that signature on a given message. This works well for domains that
manage and send all of their own email from a single source, or for manage and send all of their own email from single sources, or for
cases where multiple email streams exist but each has its own unique cases where multiple email streams exist but each has its own unique
key pair. It also represents the case in which only one of the key pair. It also represents the case in which only one of the
participants in an email sequence is able to sign, no matter whether participants in an email sequence is able to sign, no matter whether
they represent the author or one of the operators. it represents the author or one of the operators.
The examples thus far have considered the implications of using The examples thus far have considered the implications of using
different identities in DKIM signatures, but have used only one such different identities in DKIM signatures, but have used only one such
identity for any given message. In some cases, it may make sense to identity for any given message. In some cases, it may make sense to
have more than one identity claiming responsiblity for the same have more than one identity claiming responsibility for the same
message. message.
One important caveat to the use of multiple signatures is that there
is currently no clear consensus amoung receivers on how they plan to
handle them. The opinions range from ignoring all but one signature
(and the specification of which of them is verified differs from
receiver to receiver), to verifying all signatures present and
applying a weighted blend of the trust assessments for those
identifiers, to verifying all signatures present and simply using the
identfier that represents the most positive trust assessment. It is
likely that the industry will evolve to accept multiple signatures
using either option two or three, but it may take some time before
that approach becomes pervasive.
There are a number of situations where applying more than one DKIM There are a number of situations where applying more than one DKIM
signature to the same message might make sense. A few examples are: signature to the same message might make sense. A few examples are:
Companies with multiple subdomain identities: A company that has Companies with multiple subdomain identities: A company that has
multiple subdomain sending distinct categories of mail might multiple subdomains sending distinct categories of mail might
choose to sign with distinct subdomain identities to enable each choose to sign with distinct subdomain identities to enable each
subdomain to manage its own identity. However, it might also want subdomain to manage its own identity. However, it might also want
to provide a common identity that cuts across all of the distinct to provide a common identity that cuts across all of the distinct
subdomains. For example, Company A may sign mail for its sales subdomains. For example, Company A may sign mail for its sales
department with a signature where d=marketing.companya.example, department with a signature where d=sales.companya.example, and a
and a second signature where d=companya.example second signature where d=companya.example
Service Providers: Service providers may, as described above, choose Service Providers: A service providers may, as described above,
to sign outbound messages with either their own identity or with choose to sign outbound messages with either its own identity or
an identity unique to each of their clients (possibly delegated). with an identity unique to each of its clients (possibly
However, they may also do both: sign each outbound message with delegated). However, it may also do both: sign each outbound
their own identity as well as the identity of each individual message with its own identity as well as with the identity of each
client. For example, ESP A might sign mail for their client individual client. For example, ESP A might sign mail for its
Company B with their service provider signature d=espa.example, client Company B with its service provider signature
and a second client-specific signature where d= either d=espa.example, and a second client-specific signature where d=
companyb.example, or companyb.espa.example. The existence of the either companyb.example, or companyb.espa.example. The existence
service provider signature could, for example, help cover a new of the service provider signature could, for example, help cover a
client while they establish their own reputation, or help a very new client while it establishes its own reputation, or help a very
small volume client who might never reach a volume threshold small volume client who might never reach a volume threshold
sufficient to establish an individual reputation. sufficient to establish an individual reputation.
Forwarders Forwarded mail poses a number of challenges to email Forwarders Forwarded mail poses a number of challenges to email
authentication. DKIM is relatively robust in the presence of authentication. DKIM is relatively robust in the presence of
forwarders as long as the signature is designed to avoid message forwarders as long as the signature is designed to avoid message
parts that are likely to be modified, although some forwarders do parts that are likely to be modified, although some forwarders do
make modifications that can invalidate a DKIM signature. make modifications that can invalidate a DKIM signature.
However, some forwarders such as mailing lists or forward article However, some forwarders such as mailing lists or "forward article
to a friend services, might choose to add their own signature to to a friend" services, might choose to add their own signatures to
outbound messages to vouch for it having legitimately originated outbound messages to vouch for them having legitimately originated
from the designated service. In this case, the signature would be from the designated service. In this case, the signature would be
added even in the presence of a pre-existing signature, and both added even in the presence of a preexisting signature, and both
signatures would be relevant to the verifier. signatures would be relevant to the verifier.
Any forwarder that modifies messages in ways that will break pre- Any forwarder that modifies messages in ways that will break
existing DKIM signatures SHOULD always sign its forwarded preexisting DKIM signatures SHOULD always sign its forwarded
messages. messages.
Reputation Providers: Although third party reputation providers Reputation Providers: Although third party reputation providers
today use a variety of protocols to communicate their information today use a variety of protocols to communicate their information
to receivers, it is possible that they, or other organizations to receivers, it is possible that they, or other organizations
willing to put their "seal of approval" on an email stream might willing to put their "seal of approval" on an email stream might
choose to use a DKIM signature to do it. In nearly all cases, choose to use a DKIM signature to do it. In nearly all cases,
this "reputation" signature would be in addition to the author or this "reputation" signature would be in addition to the author or
originator signature. originator signature.
One important caveat to the use of multiple signatures is that there
is currently no clear consensus among receivers on how they plan to
handle them. The opinions range from ignoring all but one signature
(and the specification of which of them is verified differs from
receiver to receiver), to verifying all signatures present and
applying a weighted blend of the trust assessments for those
identifiers, to verifying all signatures present and simply using the
identifier that represents the most positive trust assessment. It is
likely that the industry will evolve to accept multiple signatures
using either the second or third of these, but it may take some time
before one approach becomes pervasive.
7. Example Usage Scenarios 7. Example Usage Scenarios
Signatures are created by different types of email actors, based on Signatures are created by different types of email actors, based on
different criteria, such as where the actor operates in the sequence different criteria, such as where the actor operates in the sequence
from author to recipient, whether they want different messages to be from author to recipient, whether they want different messages to be
evaluated under the same reputation or different, and so on. This evaluated under the same reputation or a different one, and so on.
section provides some examples of usage scenarios for DKIM This section provides some examples of usage scenarios for DKIM
deployments; the selection is not intended to be exhaustive, but to deployments; the selection is not intended to be exhaustive, but to
illustrate a set of key deployment considerations. illustrate a set of key deployment considerations.
7.1. Author's Organization - Simple 7.1. Author's Organization - Simple
The simplest DKIM configuration is to have some mail from a given The simplest DKIM configuration is to have some mail from a given
organization (Company A) be signed with the same d= value (e.g. organization (Company A) be signed with the same d= value (e.g.
d=companya.example). If there is a desire to associate a user d=companya.example). If there is a desire to associate a user
identity or some other related information, the i= value can become identity or some other related information, the AUID [rfc4871-update]
uniqueID@companya.example, or @uniqueID.companya.example. value can become uniqueID@companya.example, or
@uniqueID.companya.example.
In this scenario, Company A need only generate a single signing key In this scenario, Company A need only generate a single signing key
and publish it under their top level domain (companya.example); the and publish it under their top level domain (companya.example); the
signing module would then tailor the i= value as needed at signing signing module would then tailor the AUID value as needed at signing
time. time.
7.2. Author's Organization - Differentiated Types of Mail 7.2. Author's Organization - Differentiated Types of Mail
A slight variation of the one signature case is where Company A signs A slight variation of the one signature case is where Company A signs
some of its mail, but it wants to differentiate different categories some of its mail, but it wants to differentiate different categories
of its outbound mail by using different identifiers. For example, it of its outbound mail by using different identifiers. For example, it
might choose to distinguish marketing mail, billing or transactional might choose to distinguish marketing mail, billing or transactional
mail, and individual corporate email into marketing.companya.example, mail, and individual corporate email into marketing.companya.example,
billing.companya.example, and companya.example, where each category billing.companya.example, and companya.example, where each category
is assigned a unique subdomain and unique signing keys. is assigned a unique subdomain and unique signing keys.
7.3. Author Signature 7.3. Author Signature
As discussed in Section 6.1, author signatures are a special case of As discussed in Section 6.1, author signatures are a special case of
signatures from an author's organization where at least one signature signatures from an author's organization where at least one signature
on the message has an i= value that matches the From: address of the on the message has a SDID [rfc4871-update] value that matches the
message. From: address of the message.
Signers wishing to publish an ADSP record describing their signing Signers wishing to publish an Author Domain Signing Practices (ADSP)
practices will want to include an author signature on their outbound [I-D.ietf-dkim-ssp] record describing their signing practices will
mail to avoid ADSP verification failures. For example, if the want to include an author signature on their outbound mail to avoid
address in the RFC 5322 From is bob@company.example, the d= value of ADSP verification failures. For example, if the address in the RFC
the author signature would be company.example, and the i= value would 5322 From is bob@company.example, the SDID value of the author
be either company.example or bob@company.example. signature would be company.example.
7.4. Author Domain Signing Practices 7.4. Author Domain Signing Practices
7.4.1. Introduction 7.4.1. Introduction
DomainKeys Identified Mail (DKIM) defines a mechanism by which email The legacy of the Internet is such that not all messages will be
messages can be cryptographically signed, permitting a signing domain signed, so the absence of a signature on a message is not an a priori
to claim responsibility for the introduction of a message into the indication of forgery: in fact, during early phases of deployment it
mail stream. is very likely that most messages will remain unsigned.
However, the legacy of the Internet is such that not all messages Some domains may decide to sign all of their outgoing mail, for
will be signed, and the absence of a signature on a message is not an example, to assist in protecting their brand names. If all of the
a priori indication of forgery. In fact, during early phases of legitimate mail for a brand is signed, recipients can be more
deployment it is very likely that most messages will remain unsigned. aggressive in their filtering of mail that uses the brand but is not
However, some domains might decide to sign all of their outgoing signed by the domain name associated with the brand, because in such
mail, for example, to assist in protecting their brand names: If all a configuration, the absence of a signature should be more
of the legitimate mail for that brand is signed, recipients can by significant than it would be for the general case. It might be
more aggressive in their filtering of mail that uses the brand but is desirable for such domains to be able to advertise their intent to
not signed by the domain name associated with the brand. It might be other hosts: this is the topic of Author Domain Signing Practices
desirable for such domains to be able to advertise that fact to other (ADSP).
hosts: this is the topic of Author Domain Signing Practices (ADSP).
Note that ADSP is not for everyone. Sending domains that do not have Note that ADSP is not for everyone. Sending domains that do not
complete control of all legitimate outbound mail purporting to be control all legitimate outbound mail purporting to be from their
from their domain (i.e., with a From address in their domain) are domain (i.e., with a From address in their domain) are likely to
likely to experience delivery problems with some percentage of that experience delivery problems with some percentage of that mail.
mail. Administrators evaluating ADSP for their domains SHOULD
carefully weigh the risk of phishing attacks against the likelihood Administrators evaluating ADSP for their domains SHOULD carefully
of undelivered mail. weigh the risk of phishing attacks against the likelihood of
undelivered mail.
This section covers some examples of ADSP usage: for the complete This section covers some examples of ADSP usage: for the complete
specification, see [I-D.ietf-dkim-ssp] specification, see [I-D.ietf-dkim-ssp]
7.4.2. A Few Definitions 7.4.2. A Few Definitions
In the ADSP specification, an <addr-spec> in the From header field of In the ADSP specification, an <addr-spec> in the From header field of
a message [RFC5322] is defined as an "Author Address", and an "Author a message [RFC5322] is defined as an "Author Address", and an "Author
Domain" is defined as anything to the right of the '@' in an Author Domain" is defined as anything to the right of the '@' in an Author
Address. Address.
An "Author Signature" is thus any Valid Signature where the identity An "Author Signature" is thus any valid signature where the value of
of the user or agent on behalf of which the message is signed (listed the SDID matches an Author Address in the message.
in the "i=" tag or its default value from the "d=" tag) matches an
Author Address in the message. (When the identity of the user or
agent includes a Local-part, the identities match if the Local-parts
are the same string, and the domains are the same string. Otherwise,
the identities match if the domains are the same string. Following
[RFC5321], Local-part comparisons are case sensitive, but domain
comparisons are case insensitive.)
It is important to note that unlike the DKIM specification which It is important to note that unlike the DKIM specification which
makes no correlation between the signature domain and any message makes no correlation between the signature domain and any message
headers, the ADSP specification applies only to the author domain. headers, the ADSP specification applies only to the author domain.
In essence, under ADSP, any non-author signatures are ignored In essence, under ADSP, any non-author signatures are ignored
(treated as if they are not present). (treated as if they are not present).
7.4.3. Some ADSP Examples 7.4.3. Some ADSP Examples
An organization (Company A) may specify its signing practices by An organization (Company A) may specify its signing practices by
publishing an ADSP record with "dkim=all" or "dkim=discardable". In publishing an ADSP record with "dkim=all" or "dkim=discardable". In
order to avoid misdelivery of its mail at receivers that are order to avoid misdelivery of its mail at receivers that are
validating ADSP, Company A MUST first have done an exhaustive validating ADSP, Company A MUST first have done an exhaustive
analysis to determine all sources of outbound mail from its domain analysis to determine all sources of outbound mail from its domain
(companyA.example) and ensure that they all have valid author (companyA.example) and ensure that they all have valid author
signatures from that domain. signatures from that domain.
For example, email with an RFC 5322 From <addr-spec> of bob@ For example, email with an RFC 5322 From <addr-spec> of bob@
companyA.example MUST have an author signature where the i= value is companyA.example MUST have an author signature where theSDID value is
either "@companyA.example" or "bob@companyA.example", or it will fail either "companyA.example" or it will fail an ADSP validation.
an ADSP validation.
Note that once an organization publishes an ADSP record using Note that once an organization publishes an ADSP record using
dkim=all or dkim=discardable, any email with a RFC 5322 From address dkim=all or dkim=discardable, any email with a RFC 5322 From address
that uses the domain where the ADSP record is published that does not that uses the domain where the ADSP record is published that does not
have a valid author signature is at risk of being mis-delivered or have a valid author signature is at risk of being mis-delivered or
discarded. For example, if a message with an RFC 5322 From <addr- discarded. For example, if a message with an RFC 5322 From <addr-
spec> of newsletter@companyA.example has a signature with spec> of newsletter@companyA.example has a signature with
i=@marketing.companyA.example or i=jsmith@companyA.example, that d=marketing.companyA.example, that message will fail the ADSP check
message will fail the ADSP check because the signature would not be because the signature would not be considered a valid author
considered a valid author signature. signature.
Because the semantics of an ADSP author signature are more Because the semantics of an ADSP author signature are more
constrained than the semantics of a "pure" DKIM signature, it is constrained than the semantics of a "pure" DKIM signature, it is
important to make sure you understand the nuances before deploying an important to make sure the nuances are well understood before
ADSP record. The ADSP specification [I-D.ietf-dkim-ssp] provides deploying an ADSP record. The ADSP specification [I-D.ietf-dkim-ssp]
some fairly extensive lookup examples (in Appendix A) and usage provides some fairly extensive lookup examples (in Appendix A) and
examples (in Appendix B). usage examples (in Appendix B).
In particular, in order to prevent mail from being negatively In particular, in order to prevent mail from being negatively
impacted or even discarded at the receiver, it is essential to impacted or even discarded at the receiver, it is essential to
perform a thorough survey of outbound mail from a domain before perform a thorough survey of outbound mail from a domain before
publishing an ADSP policy of anything stronger than "unknown". This publishing an ADSP policy of anything stronger than "unknown". This
includes mail that might be sent from external sources that may not includes mail that might be sent from external sources that may not
be authorized to use your domain signature, as well as mail that be authorized to use the domain signature, as well as mail that risks
risks modification in transit that might invalidate an otherwise modification in transit that might invalidate an otherwise valid
valid author signature (e.g. mailing lists, courtesy forwarders, and author signature (e.g. mailing lists, courtesy forwarders, and other
other paths that could add or modify headers, or modify the message paths that could add or modify headers, or modify the message body).
body).
7.5. Delegated Signing 7.5. Delegated Signing
An organization may choose to outsource certain key services to an An organization may choose to outsource certain key services to an
independent company. For example, Company A might outsource its independent company. For example, Company A might outsource its
benefits management, or Organization B might outsource its marketing benefits management, or Organization B might outsource its marketing
email. email.
If Company A wants to ensure that all of the mail sent on its behalf If Company A wants to ensure that all of the mail sent on its behalf
through the benefits providers email servers shares the Company A through the benefits providers email servers shares the Company A
reputation, as discussed in Section 6.4 it can either publish keys reputation, as discussed in Section 6.4 it can either publish keys
designated for the use of the benefits provider under designated for the use of the benefits provider under
companyA.example (preferably under a designated subdomain of companyA.example (preferably under a designated subdomain of
companyA.example), or they can delegate a subdomain (e.g. companyA.example), or it can delegate a subdomain (e.g.
benefits.companyA.example) to the provider and enable the provider to benefits.companyA.example) to the provider and enable the provider to
generate the keys and manage the DNS for the designated subdomain. generate the keys and manage the DNS for the designated subdomain.
In both of these cases, mail would be physically going out of the In both of these cases, mail would be physically going out of the
benefit provider's mail servers with a signature of e.g. benefit provider's mail servers with a signature of e.g.
d=benefits.companya.example. Note that the From: address is not d=benefits.companya.example. Note that the From: address is not
constrained: it could either be affiliated with the benefits company constrained: it could either be affiliated with the benefits company
(e.g. benefits-admin@benefitprovider.example, or (e.g. benefits-admin@benefitprovider.example, or
benefits-provider@benefits.companya.example). benefits-provider@benefits.companya.example), or with the companyA
domain.
Note that in both of the above scenarios, security concerns dictate Note that in both of the above scenarios, as discussed in
that the keys be generated by the organization that plans to do the Section 3.4, security concerns dictate that the keys be generated by
signing so that there is no need to transfer the private key. In the organization that plans to do the signing so that there is no
other words, the benefits provider would generate keys for both of need to transfer the private key. In other words, the benefits
the above scenarios. provider would generate keys for both of the above scenarios.
7.6. Independent Third Party Service Providers 7.6. Independent Third Party Service Providers
Another way to manage the service provider configuration would be to Another way to manage the service provider configuration would be to
have the service provider sign the outgoing mail on behalf of its have the service provider sign the outgoing mail on behalf of its
client Company A with its own (provider) identifier. For example, an client Company A with its own (provider) identifier. For example, an
Email Service Provider (ESP A) might want to share its own mailing Email Service Provider (ESP A) might want to share its own mailing
reputation with its clients, and may sign all outgoing mail from its reputation with its clients, and may sign all outgoing mail from its
clients with its own d= domain (e.g. d=espa.example). clients with its own d= domain (e.g. d=espa.example).
Should the ESP want to distinguish among its clients, it has two Should the ESP want to distinguish among its clients, it has two
options: options:
Share the d= domain and use the i= value to distinguish among the o Share the SDID domain, and use the AUID value to distinguish among
clients: e.g. a signature on behalf of client A would have the clients: e.g. a signature on behalf of client A would have
d=espa.example and i=clienta.espa.example (or d=espa.example and i=clienta.espa.example (or
i=clienta@espa.example) i=clienta@espa.example)
Extend the d= domain so there is a unique value (and subdomain) for
each client: e.g. a signature on behalf of client A would have o Extend the SDID domain, so there is a unique value (and subdomain)
for each client: e.g. a signature on behalf of client A would have
d=clienta.espa.example. d=clienta.espa.example.
Note that this scenario and the delegation scenario are not mutually Note that this scenario and the delegation scenario are not mutually
exclusive: in some cases, it may be desirable to sign the same exclusive: in some cases, it may be desirable to sign the same
message with both the ESP and the ESP client identities. message with both the ESP and the ESP client identities.
7.7. Mail Streams Based on Behavioral Assessment 7.7. Mail Streams Based on Behavioral Assessment
An ISP (ISP A) might want to assign signatures to outbound mail from An ISP (ISP A) might want to assign signatures to outbound mail from
their users according to each user's past sending behavior its users according to each user's past sending behavior
(reputation). In other words, the ISP would segment its outbound (reputation). In other words, the ISP would segment its outbound
traffic according to its own assessment of message quality, to aid traffic according to its own assessment of message quality, to aid
recipients in deciding to process these different streams recipients in deciding to process these different streams
differently. Since the semantics of behavioral assessments aren't differently. Since the semantics of behavioral assessments aren't
allowed as i= values, ISP A (ispa.example) may configure subdomains allowed as AUID values, ISP A (ispa.example) may configure subdomains
corresponding to the assessment categories (e.g. good.ispa.example, corresponding to the assessment categories (e.g. good.ispa.example,
neutral.ispa.example, bad.ispa.example), and use these subdomains in neutral.ispa.example, bad.ispa.example), and use these subdomains in
the d= value of the signature. the d= value of the signature.
The signing module can also optionally set the i= value to have a The signing module can also optionally set the AUID value to have a
unique user id (distinct from the users email address local part), unique user id (distinct from the local-part of the user's email
for example user3456@neutral.domain.example. Using a userid that is address), for example user3456@neutral.domain.example. Using a
distinct from a given email alias is useful in environments where a userid that is distinct from a given email alias is useful in
single user might register multiple email aliases. environments where a single user might register multiple email
aliases.
Note that in this case the i= values are only partially stable. They Note that in this case the AUID values are only partially stable.
are stable in the sense that a given i= value will always represent They are stable in the sense that a given i= value will always
the same identity, but they are unstable in the sense that a given represent the same identity, but they are unstable in the sense that
user can migrate among the assessment subdomains depending on their a given user can migrate among the assessment subdomains depending on
sending behavior (i.e., the same user might have multiple i= values their sending behavior (i.e., the same user might have multiple AUID
over the lifetime of their account). values over the lifetime of a single account).
In this scenario, ISP A may generate as many keys as there are In this scenario, ISP A may generate as many keys as there are
assessment subdomains (d= values), so that each assessment subdomain assessment subdomains (SDID values), so that each assessment
has its own key. The signing module would then choose its signing subdomain has its own key. The signing module would then choose its
key based on the assessment of the user whose mail was being signed, signing key based on the assessment of the user whose mail was being
and if desired include the user id in the i= tag of the signature. signed, and if desired include the user id in the AUID of the
signature. As discussed earlier, the per-user granularity of the
AUID may be ignored by many verifiers, so organizations choosing to
use it should not rely on its use for receiver side filtering
results; however, some organizations may also find the information
useful for thier own purposes in processing bounces or abuse reports.
7.8. Agent or Mediator Signatures 7.8. Agent or Mediator Signatures
Another scenario is that of an agent, usually a re-mailer of some Another scenario is that of an agent, usually a re-mailer of some
kind, that signs on behalf of the service or organization that it kind, that signs on behalf of the service or organization that it
represents. Some examples of agents might be a mailing list manager, represents. Some examples of agents might be a mailing list manager,
or the "forward article to a friend" service that many online or the "forward article to a friend" service that many online
publications offer. In most of these cases, the signature is publications offer. In most of these cases, the signature is
asserting that the message originated with, or was relayed by, the asserting that the message originated with, or was relayed by, the
service asserting responsibility. service asserting responsibility. In general, if the service is
configured in such a way that its forwarding would break existing
DKIM signatures, it should always add its own signature.
8. Usage Considerations 8. Usage Considerations
8.1. Non-standard Submission and Delivery Scenarios 8.1. Non-standard Submission and Delivery Scenarios
The robustness of DKIM's verification mechanism is based on the fact The robustness of DKIM's verification mechanism is based on the fact
that only authorized signing modules have access to the designated that only authorized signing modules have access to the designated
private key. This has the side effect that email submission and private key. This has the side effect that email submission and
delivery scenarios that originate or relay messages from outside the delivery scenarios that originate or relay messages from outside the
domain of the authorized signing module will not have access to that domain of the authorized signing module will not have access to that
protected private key, and thus will be unable to attach the expected protected private key, and thus will be unable to attach the expected
domain signature to those messages. Such scenarios include mailing domain signature to those messages. Such scenarios include mailing
lists, courtesy forwarders, MTAs at hotels, hotspot networks used by lists, courtesy forwarders, MTAs at hotels, hotspot networks used by
travelling users, and other paths that could add or modify headers, travelling users, and other paths that could add or modify headers,
or modify the message body. or modify the message body.
For example, assume Joe works for Company A and has an email address For example, assume Joe works for Company A and has an email address
joe@companya.example. Joe also has a GMail account joe@gmail.com, joe@companya.example. Joe also has a ISP-1 account
and he uses GMails multiple address feature to attach his work email joe@isp1.example.com, and he uses ISP-1's multiple address feature to
joe@companya.example to his GMail account. When Joe sends email from attach his work email joe@companya.example to his ISP-1 account.
his GMail account and uses joe@companya.example as his designated When Joe sends email from his ISP-1 account and uses
From: address, that email cannot have a signature with joe@companya.example as his designated From: address, that email
d=companya.example because the GMail servers have no access to cannot have a signature with d=companya.example because the ISP-1
Company A's private key. In GMail's case it will have a GMail servers have no access to Company A's private key. In ISP-1's case
signature, but for some other mail clients offering the same multiple it will have a ISP-1 signature, but for some other mail clients
address feature there may be no signature at all on the message. offering the same multiple address feature there may be no signature
at all on the message.
Another example might be the use of a forward article to a friend Another example might be the use of a forward article to a friend
service. Most instances of these services today allow someone to service. Most instances of these services today allow someone to
send an article with their email address in the RFC 5322 From to send an article with their email address in the RFC 5322 From to
their designated recipient. If Joe used either of his two addresses their designated recipient. If Joe used either of his two addresses
(joe@companya.example or joe@gmail.com), the forwarder would be (joe@companya.example or joe@isp1.example.com), the forwarder would
equally unable to sign with a corresponding domain . As in the mail be equally unable to sign with a corresponding domain . As in the
client case, the forwarder may either sign as its own domain, or may mail client case, the forwarder may either sign as its own domain, or
put no signature on the message. may put no signature on the message.
A third example is the use of privately configured forwarding. A third example is the use of privately configured forwarding.
Assume that Joe has another account at Yahoo, joe@yahoo.com, but he'd Assume that Joe has another account at ISP-2, joe@isp-2.example.com,
prefer to read his Yahoo mail from his GMail account. He sets up his but he'd prefer to read his ISP-2 mail from his ISP-1 account. He
Yahoo account to forward all incoming mail to joe@gmail.com. Assume sets up his ISP-2 account to forward all incoming mail to
alice@companyb.example sends joe@yahoo.com an email. Depending on joe@isp1.example.com. Assume alice@companyb.example sends
how companyb.example configured its signature, and depending on joe@isp-2.example.com an email. Depending on how companyb.example
whether or not Yahoo modifies messages that it forwards, it is configured its signature, and depending on whether or not ISP-2
possible that when Alice's message is received in Joe's gmail account modifies messages that it forwards, it is possible that when Alice's
the original signature fails verification. message is received in Joe's ISP-1 account the original signature
fails verification.
8.2. Protection of Internal Mail 8.2. Protection of Internal Mail
One identity is particularly amenable to easy and accurate One identity is particularly amenable to easy and accurate
assessment: the organization's own identity. Members of an assessment: the organization's own identity. Members of an
organization tend to trust messages that purport to be from within organization tend to trust messages that purport to be from within
that organization. However Internet Mail does not provide a that organization. However Internet Mail does not provide a
straightforward means of determining whether such mail is, in fact, straightforward means of determining whether such mail is, in fact,
from within the organization. DKIM can be used to remedy this from within the organization. DKIM can be used to remedy this
exposure. If the organization signs all of its mail, then its exposure. If the organization signs all of its mail, then its
skipping to change at page 36, line 41 skipping to change at page 37, line 19
or otherwise adjust signatures in a way that supports per-user or otherwise adjust signatures in a way that supports per-user
identification. This user level granularity can be specified in two identification. This user level granularity can be specified in two
ways: either by sharing the signing identity and specifying an ways: either by sharing the signing identity and specifying an
extension to the i= value that has a per-user granularity, or by extension to the i= value that has a per-user granularity, or by
creating and signing with unique per-user keys. creating and signing with unique per-user keys.
A subdomain or local part in the i= tag SHOULD be treated as an A subdomain or local part in the i= tag SHOULD be treated as an
opaque identifier and thus need not correspond directly to a DNS opaque identifier and thus need not correspond directly to a DNS
subdomain or be a specific user address. subdomain or be a specific user address.
The primary way to sign with per-user keys require that each user The primary way to sign with per-user keys requires each user to have
have a distinct DNS (sub)domain, where each distinct d= value has a a distinct DNS (sub)domain, where each distinct d= value has a key
key published (it is possible, although not recommended, to publish published. (It is possible, although not recommended, to publish the
the same key in more than one distinct domain). same key in more than one distinct domain.)
It is technically possible, to publish per-user keys within a single It is technically possible to publish per-user keys within a single
domain or subdomain by utilizing different selector values. This is domain or subdomain by utilizing different selector values. This is
not recommended and is unlikely to be treated uniquely by Identity not recommended and is unlikely to be treated uniquely by Assessors:
Assessors: the primary purpose of selectors is to facilitate key the primary purpose of selectors is to facilitate key management, and
management, and the DKIM specification recommends against using them the DKIM specification recommends against using them in determining
in determining or assessing identies. or assessing identies.
In most cases, it would be impractical to sign email on a per-user In most cases, it would be impractical to sign email on a per-user
granularity. Such an approach would be granularity. Such an approach would be
likely to be ignored: In most cases today, if receivers are likely to be ignored: In most cases today, if receivers are
verifying DKIM signatures they are in general taking the simplest verifying DKIM signatures they are in general taking the simplest
possible approach. In many cases maintaining reputation possible approach. In many cases maintaining reputation
information at a per user granularity is not interesting to them, information at a per user granularity is not interesting to them,
in large part because the per user volume is too small to be in large part because the per user volume is too small to be
useful or interesting. So even if senders take on the complexity useful or interesting. So even if senders take on the complexity
skipping to change at page 37, line 29 skipping to change at page 38, line 6
enhancements or extensive administrative expertise. For domains enhancements or extensive administrative expertise. For domains
of any size, maintaining a valid per-user keypair, knowing when of any size, maintaining a valid per-user keypair, knowing when
keys need to be revoked or added due to user attrition or keys need to be revoked or added due to user attrition or
onboarding, and the overhead of having the signing engine onboarding, and the overhead of having the signing engine
constantly swapping keys can create significant and often constantly swapping keys can create significant and often
unnecessary managment complexity. It is also important to note unnecessary managment complexity. It is also important to note
that there is no way within the scope of the DKIM specification that there is no way within the scope of the DKIM specification
for a receiver to infer that a sender intends a per-user for a receiver to infer that a sender intends a per-user
granularity. granularity.
What may make sense, however, is to use the infrastructure that As mentioned before, what may make sense, however, is to use the
enables finer granularity in signatures to identify segments smaller infrastructure that enables finer granularity in signatures to
than a domain but much larger than a per-user segmentation. For identify segments smaller than a domain but much larger than a per-
example, a university might want to segment student, staff, and user segmentation. For example, a university might want to segment
faculty mail into three distinct streams with differing reputations. student, staff, and faculty mail into three distinct streams with
This can be done by creating seperate sub-domains for the desired differing reputations. This can be done by creating seperate sub-
segments, and either specifying the subdomains in the i= tag of the domains for the desired segments, and either specifying the
DKIM Signature or by adding subdomains to the d= tag and assigning subdomains in the i= tag of the DKIM Signature or by adding
and signing with different keys for each subdomain. subdomains to the d= tag and assigning and signing with different
keys for each subdomain.
For those who choose to represent user level granularity in For those who choose to represent user level granularity in
signatures, the performance and management considerations above signatures, the performance and management considerations above
suggest that it would be more effective to do it by specifying a suggest that it would be more effective to do it by specifying a
local part or subdomain extension in the i= tag rather than by local part or subdomain extension in the i= tag rather than by
extending the d= domain and publishing individual keys. extending the d= domain and publishing individual keys.
8.4. Email Infrastructure Agents 8.4. Email Infrastructure Agents
It is expected that the most common venue for a DKIM implementation It is expected that the most common venue for a DKIM implementation
skipping to change at page 38, line 17 skipping to change at page 38, line 42
advertised email sending policy. It SHOULD also be able to advertised email sending policy. It SHOULD also be able to
generate an operator alert if it determines that the email generate an operator alert if it determines that the email
messages do not comply with the published DKIM sending policy. messages do not comply with the published DKIM sending policy.
An MSA SHOULD be aware that some MUAs may add their own An MSA SHOULD be aware that some MUAs may add their own
signatures. If the MSA needs to perform operations on a signatures. If the MSA needs to perform operations on a
message to make it comply with its email sending policy, if at message to make it comply with its email sending policy, if at
all possible, it SHOULD do so in a way that would not break all possible, it SHOULD do so in a way that would not break
those signatures. those signatures.
[[anchor48: MSK: MUAs being able to sign is a security MUAs equipped with the ability to sign SHOULD NOT be
consideration; MUAs are more prone to vulnerabilities, so an encouraged. In terms of security, MUAs are generally not under
MUA having direct access to signing keys is a security concern; the direct control of those in responsible roles within an
general MUA vulnerability came up during the IETF Security organization and are thus more vulnerable to attack and
Directorate review of draft-kucherawy-sender-auth-header]] compromise, which would expose private signing keys to
intruders and thus jeopardize the integrity and reputation of
the organization.
Inbound: When an organization deploys DKIM, it needs to make Inbound: When an organization deploys DKIM, it needs to make
sure that it email infrastructure components that do not have sure that its email infrastructure components that do not have
primary roles in DKIM handling do not modify message in ways primary roles in DKIM handling do not modify message in ways
that prevent subsequent verification. that prevent subsequent verification.
An inbound MTA or an MDA may incorporate an indication of the An inbound MTA or an MDA may incorporate an indication of the
verification results into the message, such as using an verification results into the message, such as using an
Authentication-Results header field. Authentication-Results header field. [RFC5451]
[I-D.kucherawy-sender-auth-header]
Intermediaries: An email intermediary is both an inbound and Intermediaries: An email intermediary is both an inbound and
outbound MTA. Each of the requirements outlined in the outbound MTA. Each of the requirements outlined in the
sections relating to MTAs apply. If the intermediary modifies sections relating to MTAs apply. If the intermediary modifies
a message in a way that breaks the signature, the intermediary a message in a way that breaks the signature, the intermediary
+ SHOULD deploy abuse filtering measures on the inbound mail, + SHOULD deploy abuse filtering measures on the inbound mail,
and and
+ MAY remove all signatures that will be broken + MAY remove all signatures that will be broken
In addition the intermediary MAY: In addition the intermediary MAY:
+ Verify the message signature prior to modification. + Verify the message signature prior to modification.
+ Incorporate an indication of the verification results into + Incorporate an indication of the verification results into
the message, such as using an Authentication-Results header the message, such as using an Authentication-Results header
field. [I-D.kucherawy-sender-auth-header] field. [RFC5451]
+ Sign the modified message including the verification results + Sign the modified message including the verification results
(e.g., the Authentication-Results header field). (e.g., the Authentication-Results header field).
8.5. Mail User Agent 8.5. Mail User Agent
The DKIM specification is expected to be used primarily between The DKIM specification is expected to be used primarily between
Boundary MTAs, or other infrastructure components of the originating Boundary MTAs, or other infrastructure components of the originating
and receiving ADMDs. However there is nothing in DKIM that is and receiving ADMDs. However there is nothing in DKIM that is
specific to those venues. In particular, MUAs MAY also support DKIM specific to those venues. In particular, MUAs MAY also support DKIM
signing and verifying directly. signing and verifying directly.
Outbound: An MUA MAY support signing even if mail is to be Outbound: An MUA MAY support signing even if mail is to be
relayed through an outbound MSA. In this case the signature relayed through an outbound MSA. In this case the signature
applied by the MUA will be in addition to any signature added applied by the MUA will be in addition to any signature added
by the MSA. by the MSA. However, the warnings in the previous section
should be taken into consideration.
Some user software goes beyond simple user functionality and Some user software goes beyond simple user functionality and
also perform MSA and MTA functions. When this is employed for also perform MSA and MTA functions. When this is employed for
sending directly to a receiving ADMD, the user software SHOULD sending directly to a receiving ADMD, the user software SHOULD
be considered an outbound MTA. be considered an outbound MTA.
Inbound: An MUA MAY rely on a report of a DKIM signature Inbound: An MUA MAY rely on a report of a DKIM signature
verification that took place at some point in the inbound MTA/ verification that took place at some point in the inbound MTA/
MDA path (e.g., an Authentication-Results header field), or an MDA path (e.g., an Authentication-Results header field), or an
MUA MAY perform DKIM signature verification directly. A MUA MAY perform DKIM signature verification directly. A
verifying MUA SHOULD allow for the case where mail has modified verifying MUA SHOULD allow for the case where mail has modified
in the inbound MTA path; if a signature fails, the message in the inbound MTA path; if a signature fails, the message
SHOULD NOT be treated any different than if it did not have a SHOULD NOT be treated any different than if it did not have a
signature. signature.
An MUA that looks for an Authentication-Results header field An MUA that looks for an Authentication-Results header field
MUST be configurable to choose which Authentication-Results are MUST be configurable to choose which Authentication-Results are
considered trustable. considered trustable. The MUA developer is encouraged to re-
read the Security Considerations of [RFC5451].
DKIM requires that all verifiers treat messages with signatures DKIM requires that all verifiers treat messages with signatures
that do not verify as if they are unsigned. that do not verify as if they are unsigned.
If verification in the client is to be acceptable to users, it If verification in the client is to be acceptable to users, it
is essential that successful verification of a signature not is essential that successful verification of a signature not
result in a less than satisfactory user experience compared to result in a less than satisfactory user experience compared to
leaving the message unsigned. The mere presence of a verified leaving the message unsigned. The mere presence of a verified
DKIM signature MUST NOT by itself be used by an MUA to indicate DKIM signature MUST NOT by itself be used by an MUA to indicate
that a message is to be treated better than a message without a that a message is to be treated better than a message without a
skipping to change at page 40, line 35 skipping to change at page 41, line 21
TBD TBD
11. Informative References 11. Informative References
[I-D.ietf-dkim-overview] [I-D.ietf-dkim-overview]
Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
Identified Mail (DKIM) Service Overview", Identified Mail (DKIM) Service Overview",
draft-ietf-dkim-overview-10 (work in progress), July 2008. draft-ietf-dkim-overview-10 (work in progress), July 2008.
[I-D.ietf-dkim-ssp] [I-D.ietf-dkim-ssp]
Local-part, a., Domain, A., error, r., Allman, E., Fenton, field, h., Domain, A., error, r., Allman, E., Fenton, J.,
J., Delany, M., and J. Levine, "DomainKeys Identified Mail Delany, M., and J. Levine, "DomainKeys Identified Mail
(DKIM) Author Domain Signing Practices (ADSP)", (DKIM) Author Domain Signing Practices (ADSP)",
draft-ietf-dkim-ssp-09 (work in progress), February 2009. draft-ietf-dkim-ssp-10 (work in progress), May 2009.
[I-D.ietf-openpgp-rfc2440bis] [I-D.ietf-openpgp-rfc2440bis]
Callas, J., "OpenPGP Message Format", Callas, J., "OpenPGP Message Format",
draft-ietf-openpgp-rfc2440bis-22 (work in progress), draft-ietf-openpgp-rfc2440bis-22 (work in progress),
April 2007. April 2007.
[I-D.kucherawy-sender-auth-header]
Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status",
draft-kucherawy-sender-auth-header-20 (work in progress),
January 2009.
[RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement
for Internet electronic mail: Part I: Message encipherment for Internet electronic mail: Part I: Message encipherment
and authentication procedures", RFC 989, February 1987. and authentication procedures", RFC 989, February 1987.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME [RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME
Object Security Services", RFC 1848, October 1995. Object Security Services", RFC 1848, October 1995.
skipping to change at page 42, line 9 skipping to change at page 42, line 35
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008. Existence", RFC 5155, March 2008.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[RFC5451] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 5451, April 2009.
[rfc4871-update]
Crocker, D., Ed., "RFC 4871 DomainKeys Identified Mail
(DKIM) Signatures -- Update",
I-D draft-ietf-dkim-rfc4871-errata-03, April 2009.
Appendix A. Migrating from DomainKeys Appendix A. Migrating from DomainKeys
As with any migration, the steps required will be determined by who As with any migration, the steps required will be determined by who
is doing the migration and their assessment of is doing the migration and their assessment of
o the users of what they are generating, or o the users of what they are generating, or
o the providers of what they are consuming. o the providers of what they are consuming.
A.1. Signers A.1. Signers
A signer that currently signs with DomainKeys (DK) will go through A signer that currently signs with DomainKeys (DK) will go through
various stages as they migrate to using DKIM, not all of which are various stages as it migrates to using DKIM, not all of which are
required for all signers. The real questions that a signer must ask required for all signers. The real questions that a signer must ask
are: are:
1. how many receivers or what types of receivers are *only* looking 1. how many receivers or what types of receivers are *only* looking
at the DK signatures and not the DKIM signatures, at the DK signatures and not the DKIM signatures, and
2. and how much does the signer care about those receivers? 2. how much does the signer care about those receivers?
If no one is looking at the DK signature any more, then it's no If no one is looking at the DK signature any more, then it's no
longer necessary to sign with DK. Or if there are no more "large longer necessary to sign with DK. Or if all "large players" are
players" looking only at the DK signatures, a signer may choose to looking at DKIM in addition to or instead of DK, a signer MAY choose
stop signing with DK. to stop signing with DK.
With respect to signing policies, a reasonable, initial approach is With respect to signing policies, a reasonable, initial approach is
to use DKIM signatures in the same way as DomainKeys signatures are to use DKIM signatures in the same way as DomainKeys signatures are
already being used. In particular, the same selectors and DNS Key already being used. In particular, the same selectors and DNS Key
Records may be used for both, after verifying that they are Records may be used for both, after verifying that they are
compatible as discussed below. compatible as discussed below.
Each secondary step in all of the following scenarios is to be Each secondary step in all of the following scenarios is to be
prefaced with the gating factor "test, then when comfortable with the prefaced with the gating factor "test, then when comfortable with the
previous step's results, continue". previous step's results, continue".
skipping to change at page 44, line 16 skipping to change at page 44, line 49
A.1.1. DNS Selector Key Records A.1.1. DNS Selector Key Records
The first step in some of the above scenarios is ensuring that the The first step in some of the above scenarios is ensuring that the
selector DNS key records are compatible for both DK and DKIM. The selector DNS key records are compatible for both DK and DKIM. The
format of the DNS key record was intentionally meant to be backwardly format of the DNS key record was intentionally meant to be backwardly
compatible between the two systems, but not necessarily upwardly compatible between the two systems, but not necessarily upwardly
compatible. DKIM has enhanced the DK DNS key record format by adding compatible. DKIM has enhanced the DK DNS key record format by adding
several optional parameters, which DK must ignore. However, there is several optional parameters, which DK must ignore. However, there is
one critical difference between DK and DKIM DNS key records: the one critical difference between DK and DKIM DNS key records: the
definitions of the g fields: definitions of the "g" fields:
g= granularity of the key In both DK and DKIM, this is an optional g= granularity of the key In both DK and DKIM, this is an optional
field that is used to constrain which sending address(es) can field that is used to constrain which sending address(es) can
legitimately use this selector. Unfortunately, the treatment of legitimately use this selector. Unfortunately, the treatment of
an empty field ("g=;") is different. DKIM allows wildcards where an empty field ("g=;") is different. DKIM allows wildcards where
DK does not. For DK, an empty field is the same as a missing DK does not. For DK, an empty field is the same as a missing
value, and is treated as allowing any sending address. For DKIM, value, and is treated as allowing any sending address. For DKIM,
an empty field only matches an empty local part. In DKIM, both a an empty field only matches an empty local part. In DKIM, both a
missing value and "g=*;" mean to allow any sending address. missing value and "g=*;" mean to allow any sending address.
If your DK DNS key record has an empty g= field in it ("g=;"), If your DK DNS key record has an empty "g" field in it ("g=;"),
your best course of action is to modify the record to remove the your best course of action is to modify the record to remove the
empty field. In that way, the DK semantics will remain the same, empty field. In that way, the DK semantics will remain the same,
and the DKIM semantics will match. and the DKIM semantics will match.
If your DNS key record does not have an empty g= field in it ("g=;"), If your DNS key record does not have an empty "g" field in it
it's probable that the record can be left alone. But your best ("g=;"), it's probable that the record can be left alone. But your
course of action would still be to make sure it has a v= field. When best course of action would still be to make sure it has a "v" field.
the decision is made to stop supporting DomainKeys and to only When the decision is made to stop supporting DomainKeys and to only
support DKIM, you MUST verify that the "g" field is compatible with support DKIM, you MUST verify that the "g" field is compatible with
DKIM, and it SHOULD have "v=DKIM1;" in it. It is highly RECOMMENDED DKIM, and it SHOULD have "v=DKIM1;" in it. It is highly RECOMMENDED
that if you want to use an empty g= field in your DKIM selector, you that if you want to use an empty "g" field in your DKIM selector, you
also include the v= field. also include the "v" field.
A.1.2. Removing DomainKeys Signatures A.1.2. Removing DomainKeys Signatures
The principal use of DomainKeys is at Boundary MTAs. Because no The principal use of DomainKeys is at Boundary MTAs. Because no
operational transition is ever instantaneous, it is advisable to operational transition is ever instantaneous, it is advisable to
continue performing DomainKeys signing until it is determined that continue performing DomainKeys signing until it is determined that
DomainKeys receive-side support is no longer used, or is sufficiently DomainKeys receive-side support is no longer used, or is sufficiently
reduced. That is, a signer SHOULD add a DKIM signature to a message reduced. That is, a signer SHOULD add a DKIM signature to a message
that also has a DomainKeys signature and keep it there until you that also has a DomainKeys signature and keep it there until you
decide it can go away. The signer may do its transitions in a decide it is deemed no longer useful. The signer may do its
straightforward manner, or more gradually. Note that because digital transitions in a straightforward manner, or more gradually. Note
signatures are not free, there is a cost to performing both signing that because digital signatures are not free, there is a cost to
algorithms, so you don't want to be signing with both algorithms for performing both signing algorithms, so signing with both algorithms
too long a period. should not be needlessly prolonged.
The tricky part is deciding when DK signatures are no longer The tricky part is deciding when DK signatures are no longer
necessary. The real questions are: how many DomainKeys verifiers are necessary. The real questions are: how many DomainKeys verifiers are
there that do *not* also do DKIM verification, which ones of them do there that do *not* also do DKIM verification, which of those are
you care about, and how can you track their usage? Most of the early important, and how can you track their usage? Most of the early
adopters of DK verification have added DKIM verification, but not all adopters of DK verification have added DKIM verification, but not all
yet. If a verifier finds a message with both DK and DKIM, it may yet. If a verifier finds a message with both DK and DKIM, it may
choose to verify both signatures, or just one or the other. choose to verify both signatures, or just one or the other.
Many DNS services offer tracking statistics so you can find out how Many DNS services offer tracking statistics so it can be determined
often a DNS record has been accessed. By using separate DNS selector how often a DNS record has been accessed. By using separate DNS
key records for your signatures, you can chart the usage of your selector key records for your signatures, you can chart the usage of
records over time, and watch the trends. An additional your records over time, and watch the trends. An additional
distinguishing factor to track would take into account the verifiers distinguishing factor to track would take into account the verifiers
that verify both the DK and DKIM signatures, and discount those from that verify both the DK and DKIM signatures, and discount those from
your counts of DK selector usage. When the number for DK selector counts of DK selector usage. When the number for DK selector access
access reaches a low-enough level, that's the time to consider reaches a low-enough level, that's the time to consider discontinuing
stopping your DK signing. signing with DK.
Note, this level of rigor is not required. It is perfectly Note, this level of rigor is not required. It is perfectly
reasonable for a DK signer to decide to follow the "flash cut" reasonable for a DK signer to decide to follow the "flash cut"
scenario described above. scenario described above.
A.2. Verifiers A.2. Verifiers
As a verifier, you are faced with several issues: As a verifier, several issues must be considered:
A.2.1. Do you verify DK signatures? A.2.1. Should DK signature verification be performed?
At the time of writing, there is still a significant number of sites At the time of writing, there is still a significant number of sites
that are only producing DK signatures. Over time, it is expected that are only producing DK signatures. Over time, it is expected
that this number will go to zero, but it may take several years. So that this number will go to zero, but it may take several years. So
it would be prudent for the foreseeable future for a verifier to look it would be prudent for the foreseeable future for a verifier to look
for and verify both DKIM and DK signatures. for and verify both DKIM and DK signatures.
A.2.2. Do you verify both DK and DKIM signatures within a single A.2.2. Should both DK and DKIM signatures be evaluated on a single
message? message?
For a period of time, there will be sites that sign with both DK and For a period of time, there will be sites that sign with both DK and
DKIM. A verifier receiving a message that has both types of DKIM. A verifier receiving a message that has both types of
signatures may verify both signatures, or just one. One disadvantage signatures may verify both signatures, or just one. One disadvantage
of verifying both signatures is that signers will have a more of verifying both signatures is that signers will have a more
difficult time deciding how many verifiers are still using their DK difficult time deciding how many verifiers are still using their DK
selectors. One transition strategy is to verify the DKIM signature, selectors. One transition strategy is to verify the DKIM signature,
then only verify the DK signature if the DKIM verification fails. then only verify the DK signature if the DKIM verification fails.
skipping to change at page 46, line 23 skipping to change at page 47, line 8
g= granularity of the key In both DK and DKIM, this is an optional g= granularity of the key In both DK and DKIM, this is an optional
field that is used to constrain which sending address(es) can field that is used to constrain which sending address(es) can
legitimately use this selector. Unfortunately, the treatment of legitimately use this selector. Unfortunately, the treatment of
an empty field ("g=;") is different. For DK, an empty field is an empty field ("g=;") is different. For DK, an empty field is
the same as a missing value, and is treated as allowing any the same as a missing value, and is treated as allowing any
sending address. For DKIM, an empty field only matches an empty sending address. For DKIM, an empty field only matches an empty
local part. local part.
v= version of the selector It is recommended that a DKIM selector v= version of the selector It is recommended that a DKIM selector
have v=DKIM1; at its beginning, but it is not required. have "v=DKIM1;" at its beginning, but it is not required.
If a DKIM verifier finds a selector record that has an empty g= field If a DKIM verifier finds a selector record that has an empty "g"
("g=;") and it does not have a v= field ("v=DKIM1;") at its field ("g=;") and it does not have a "v" field ("v=DKIM1;") at its
beginning, it is faced with deciding if this record was beginning, it is faced with deciding if this record was
1. from a DK signer that transitioned to supporting DKIM but forgot 1. from a DK signer that transitioned to supporting DKIM but forgot
to remove the g= field (so that it could be used by both DK and to remove the "g" field (so that it could be used by both DK and
DKIM verifiers), or DKIM verifiers), or
2. from a DKIM signer that truly meant to use the empty g= field but 2. from a DKIM signer that truly meant to use the empty "g" field
forgot to put in the v= field. It is RECOMMENDED that you treat but forgot to put in the "v" field. It is RECOMMENDED that you
such records using the first interpretation, and treat such treat such records using the first interpretation, and treat such
records as if the signer did not have a g= field in the record. records as if the signer did not have a "g" field in the record.
Appendix B. General Coding Criteria for Cryptographic Applications Appendix B. General Coding Criteria for Cryptographic Applications
NOTE: This section could possibly be changed into a reference to NOTE: This section could possibly be changed into a reference to
something else, such as another rfc. something else, such as another rfc.
Correct implementation of a cryptographic algorithm is a necessary Correct implementation of a cryptographic algorithm is a necessary
but not a sufficient condition for the coding of cryptographic but not a sufficient condition for the coding of cryptographic
applications. Coding of cryptographic libraries requires close applications. Coding of cryptographic libraries requires close
attention to security considerations that are unique to cryptographic attention to security considerations that are unique to cryptographic
 End of changes. 151 change blocks. 
388 lines changed or deleted 433 lines changed or added

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