< draft-ietf-dkim-overview-09.txt   draft-ietf-dkim-overview-10.txt >
DomainKeys Identified Mail T. Hansen DomainKeys Identified Mail T. Hansen
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Intended status: Informational D. Crocker Intended status: Informational D. Crocker
Expires: August 28, 2008 Brandenburg InternetWorking Expires: January 12, 2009 Brandenburg InternetWorking
P. Hallam-Baker P. Hallam-Baker
VeriSign Inc. VeriSign Inc.
February 25, 2008 July 11, 2008
DomainKeys Identified Mail (DKIM) Service Overview DomainKeys Identified Mail (DKIM) Service Overview
draft-ietf-dkim-overview-09 draft-ietf-dkim-overview-10
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
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 August 28, 2008. This Internet-Draft will expire on January 12, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document provides an overview of the DomainKeys Identified Mail This document provides an overview of the DomainKeys Identified Mail
(DKIM) service and describes how it can fit into a messaging service. (DKIM) service and describes how it can fit into a messaging service.
It also describes how DKIM relates to other IETF message signature It also describes how DKIM relates to other IETF message signature
technologies. It is intended for those who are adopting, developing, technologies. It is intended for those who are adopting, developing,
or deploying DKIM. DKIM allows an organization to take or deploying DKIM. DKIM allows an organization to take
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. The organization can be the author's, the validated by a recipient. The organization can be the author's, the
originating sending site, an intermediary, or one of their agents. originating sending site, an intermediary, or one of their agents. A
An organization may use one or more domain names to accomplish this. message can contain multiple signatures, from the same or different
DKIM defines a domain-level digital signature authentication organizations involved with the message. DKIM defines a domain-level
framework for email, using public-key cryptography and key server digital signature authentication framework for email, using public-
technology [RFC4871]. This permits verification of a message source, key cryptography, using the domain name service as its key server
an intermediary, or one of their agents, as well as the integrity of technology [RFC4871]. This permits verification of a responsible
its contents. DKIM will also provide a mechanism that permits organization, as well as the integrity of the message contents. DKIM
potential email signers to publish information about their email will also provide a mechanism that permits potential email signers to
signing practices; this will permit email receivers to make publish information about their email signing practices; this will
additional assessments about messages. Such protection of email permit email receivers to make additional assessments about messages.
identity can assist in the global control of "spam" and "phishing". DKIM's authentication of email identity can assist in the global
control of "spam" and "phishing.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. DKIM's Scope . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. DKIM's Scope . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Internet Mail Background . . . . . . . . . . . . . . . . . 6 1.3. Internet Mail Background . . . . . . . . . . . . . . . . . 7
1.4. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 6 1.4. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 7
2. The DKIM Value Proposition . . . . . . . . . . . . . . . . . . 6 2. The DKIM Value Proposition . . . . . . . . . . . . . . . . . . 8
2.1. Identity Verification . . . . . . . . . . . . . . . . . . 7 2.1. Identity Verification . . . . . . . . . . . . . . . . . . 8
2.2. Enabling Trust Assessments . . . . . . . . . . . . . . . . 7 2.2. Enabling Trust Assessments . . . . . . . . . . . . . . . . 8
3. DKIM Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Establishing Message Validity . . . . . . . . . . . . . . 9
3.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 8 3. DKIM Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Operational Goals . . . . . . . . . . . . . . . . . . . . 9 3.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 10
4. DKIM Function . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Operational Goals . . . . . . . . . . . . . . . . . . . . 11
4.1. The Basic Signing Service . . . . . . . . . . . . . . . . 11 4. DKIM Function . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Characteristics of a DKIM signature . . . . . . . . . . . 11 4.1. Basic Signing . . . . . . . . . . . . . . . . . . . . . . 13
4.3. The Selector construct . . . . . . . . . . . . . . . . . . 11 4.2. Characteristics of a DKIM Signature . . . . . . . . . . . 13
4.4. Verification . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. The Selector Construct . . . . . . . . . . . . . . . . . . 14
5. Service Architecture . . . . . . . . . . . . . . . . . . . . . 13 4.4. Verification . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Administration and Maintenance . . . . . . . . . . . . . . 15 4.5. Sub-Domain Assessment . . . . . . . . . . . . . . . . . . 14
5.2. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Service Architecture . . . . . . . . . . . . . . . . . . . . . 15
5.3. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Administration and Maintenance . . . . . . . . . . . . . . 16
5.4. Unverified or Unsigned Mail . . . . . . . . . . . . . . . 16 5.2. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.5. Assessing . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 17
5.6. DKIM Placement within an ADMD . . . . . . . . . . . . . . 17 5.4. Unverified or Unsigned Mail . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5.5. Assessing . . . . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5.6. DKIM Processing within an ADMD . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Informative References . . . . . . . . . . . . . . . . . . . . 17 6.1. Security Considerations . . . . . . . . . . . . . . . . . 18
Appendix A. Internet Mail Background . . . . . . . . . . . . . . 19 6.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 18
A.1. Administrative Management Domain (ADMD) . . . . . . . . . 19 6.3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Informative References . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 23 Appendix A. Internet Mail Background . . . . . . . . . . . . . . 20
A.1. Core Model . . . . . . . . . . . . . . . . . . . . . . . . 20
A.2. Trust Boundaries . . . . . . . . . . . . . . . . . . . . . 21
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
1. Introduction 1. Introduction
This document provides a description of the architecture and This document provides a description of the architecture and
functionality for DomainKeys Identified Mail (DKIM). It is intended functionality for DomainKeys Identified Mail (DKIM). It is intended
for those who are adopting, developing, or deploying DKIM. It will for those who are adopting, developing, or deploying DKIM. It will
also be helpful for those who are considering extending DKIM, either also be helpful for those who are considering extending DKIM, either
into other areas of use or to support additional features. This into other areas of use or to support additional features. This
overview does not provide information on threats to DKIM or email, or overview does not provide information on threats to DKIM or email, or
details on the protocol specifics, which can be found in [RFC4686] details on the protocol specifics, which can be found in [RFC4686]
and [RFC4871], respectively. The document assumes a background in and [RFC4871], respectively. The document assumes a background in
basic email and network security technology and services. basic email and network security technology and services.
DKIM allows an organization to take responsibility for a message, in DKIM allows an organization to take responsibility for a message, in
a way that can be validated by a recipient. The organization can be a way that can be validated by a recipient. The organization can be
the author's, the originating sending site, an intermediary, or one handling the message directly, such as the author's, the originating
of their agents. DKIM defines a domain-level digital signature sending site or an intermediary. It also can also be created by an
authentication framework for email through the use of public-key independent service that is providing assistance to a handler. DKIM
cryptography and key server technology. [RFC4871] It permits defines a domain-level digital signature authentication framework for
email through the use of public-key cryptography and using the domain
name service as its key server technology. [RFC4871] It permits
verification of the signer of a message, as well as the integrity of verification of the signer of a message, as well as the integrity of
its contents. DKIM will also provide a mechanism that permits its contents. DKIM will also provide a mechanism that permits
potential email signers to publish information about their email potential email signers to publish information about their email
signing practices; this will permit email receivers to make signing practices; this will permit email receivers to make
additional assessments of unsigned messages. Such protection of additional assessments of unsigned messages. DKIM's authentication
email identity can assist in the global control of "spam" and of email identity can assist in the global control of "spam" and
"phishing". "phishing.
Neither this document nor DKIM attempts to provide solutions to the Neither this document nor DKIM attempts to provide solutions to the
world's problems with spam, phishing, virii, worms, joe jobs, etc. world's problems with spam, phishing, virii, worms, joe jobs, etc.
DKIM provides one basic tool, in what needs to be a large arsenal, DKIM provides one basic tool, in what needs to be a large arsenal,
for improving basic trust in the Internet mail service. However by for improving basic trust in the Internet mail service. However by
itself, DKIM is not sufficient to that task and this overview does itself, DKIM is not sufficient to that task and this overview does
not pursue the issues of integrating DKIM into these larger efforts, not pursue the issues of integrating DKIM into these larger efforts,
beyond a simple reference within a system diagram. Rather, it is a beyond a simple reference within a system diagram. Rather, it is a
basic introduction to the technology and its use. basic introduction to the technology and its use.
1.1. DKIM's Scope 1.1. DKIM's Scope
DKIM signatures can be created by a direct handler of a message, A person or organization has an "identity" -- that is, a
either as its author or as an intermediary. It can also be created constellation of characteristics that distinguish them from any other
by an independent service that is providing assistance to a handler identity. Associated with this abstraction can be a label used as a
of the message. Whoever does the signing chooses the domain name to reference, or "identifier". (This is the distinction between a thing
be used as the basis for later assessments. Hence, the reputation and the name of the thing.) DKIM uses a domain name as an
associated with that domain name is an additional basis for identifier, to refer to the identity of a person or organization.
evaluating whether to trust the message for delivery. The owner of Note that the same identity can have multiple identifiers.
the domain name being used for a DKIM signature is declaring that
they accept responsibility for the message and may thus be held A DKIM signature can be created by a direct handler of a message,
accountable for it. such as the message's author or an intermediary. A signature also
can be created by an independent service that is providing assistance
to a handler of the message. Whoever does the signing chooses the
domain name to be used as the basis for later assessments. Hence,
the reputation associated with that domain name might be an
additional basis for evaluating whether to trust the message for
delivery. The owner of the domain name being used for a DKIM
signature is declaring that they accept responsibility for the
message and can thus be held accountable for it.
DKIM is intended as a value-added feature for email. Mail that is DKIM is intended as a value-added feature for email. Mail that is
not signed by DKIM is handled in the same way as it was before DKIM not signed by DKIM is handled in the same way as it was before DKIM
was defined. The message will be evaluated by established analysis was defined. The message will be evaluated by established analysis
and filtering techniques. (A signing policy may provide additional and filtering techniques. (A signing policy can provide additional
information for that analysis and filtering.) Over time, widespread information for that analysis and filtering.) Over time, widespread
DKIM adoption could permit more strict handling of messages that are DKIM adoption could permit more strict handling of messages that are
not signed. However early benefits do not require this and probably not signed. However early benefits do not require this and probably
do not warrant this. do not warrant this.
DKIM's capabilities have a narrow scope. It is an enabling DKIM has a narrow scope. It is an enabling technology, intended for
technology, intended for use in the larger context of determining use in the larger context of determining message legitimacy. This
message legitimacy. This larger context is complex, so it is easy to larger context is complex, so it is easy to assume that a component
assume that a component like DKIM, which actually provides only a like DKIM, which actually provides only a limited service, instead
limited service, instead satisfies the broader set of requirements. satisfies the broader set of requirements.
By itself, a DKIM signature: By itself, a DKIM signature:
o Does not offer any assertions about the behaviors of the identity o Does not offer any assertions about the behaviors of the signer.
doing the signing.
o Does not prescribe any specific actions for receivers to take upon o Does not prescribe any specific actions for receivers to take upon
successful signature verification. successful signature verification.
o Does not provide protection after signature verification. o Does not provide protection after signature verification.
o Does not protect against re-sending (replay of) a message that o Does not protect against re-sending (replay of) a message that
already has a verified signature; therefore a transit intermediary already has a verified signature; therefore a transit intermediary
or a recipient can re-post the message in such a way that the or a recipient can re-post the message -- that is, post it as a
signature would remain verifiable, although the new recipient(s) new message -- with the original signature remaining verifiable,
would not have been specified by the author. even though the new recipient(s) might be different from those who
were originally specified by the author.
1.2. Prior Work 1.2. Prior Work
Historically, email delivery assessment decisions have been based on Historically, the IP Address of the system that directly sent the
an identity that used the IP Address of the system that directly sent message -- that is, the previous email "hop" -- has been treated as
the message (that is, the previous email "hop"), [RFC4408] or on the an identity to use for making assessments.[RFC4408], [RFC4406] and
message content (e.g. [RFC4406] and [RFC4407]). The IP Address is [RFC4407] The IP Address is obtained via underlying Internet
obtained via underlying Internet information mechanisms and is information mechanisms and is therefore trusted to be accurate.
therefore trusted to be accurate. Besides having some known security
weaknesses, the use of addresses presents a number of functional and
operational problems. Consequently there is a widespread desire to
use an identifier that has better correspondence to organizational
boundaries. Domain names are viewed as often satisfying this need.
There have been four previous IETF efforts at standardizing an Besides having some known security weaknesses, the use of addresses
Internet email signature scheme. Their goals have differed from presents a number of functional and operational problems.
those of DKIM. Consequently there is a widespread desire to use an identifier that
has better correspondence to organizational boundaries. Domain names
can satisfy this need.
There have been four previous IETF Internet Mail signature standards.
Their goals have differed from those of DKIM. The first two are only
of historical interest.
Pretty Good Privacy (PGP) was developed by Phil Zimmermann and first
released in 1991.
o Privacy Enhanced Mail (PEM) was first published in 1987. o Privacy Enhanced Mail (PEM) was first published in 1987.
[RFC0989] [RFC0989]
o PEM eventually transformed into MIME Object Security Services o PEM eventually transformed into MIME Object Security Services
(MOSS) in 1995. [RFC1848] Today, these two are only of historical (MOSS) in 1995. [RFC1848] [RFC1991] A later version was
interest.
o Pretty Good Privacy (PGP) was developed by Phil Zimmermann and
first released in 1991. [RFC1991] A later version was
standardized as OpenPGP. [RFC2440] [RFC3156] [RFC4880] standardized as OpenPGP. [RFC2440] [RFC3156] [RFC4880]
o RSA Security independently developed Secure MIME (S/MIME) to o RSA Security independently developed Secure MIME (S/MIME) to
transport a PKCS #7 data object. [RFC3851] transport a PKCS #7 data object. It was standardized as [RFC3851]
Development of both S/MIME and OpenPGP has continued. While each has Development of both S/MIME and OpenPGP has continued. While each has
achieved a significant user base, neither one has achieved ubiquity achieved a significant user base, neither one has achieved ubiquity
in deployment or use. in deployment or use.
To the extent that other message-signing services might have been To the extent that other message-signing services might have been
adapted to do the job that DKIM is designed to perform, it was felt adapted to do the job that DKIM is designed to perform, it was felt
that re-purposing any of those would be more problematic than that re-purposing any of those would be more problematic than
creating a separate service. That said, DKIM uses security algorithm creating a separate service. That said, DKIM only uses cryptographic
components that have a long history, including use within some of components that have a long history, including use within some of
those other messaging security services. those other messaging security services.
DKIM has a distinctive approach for distributing and vouching for DKIM has a distinctive approach for distributing and vouching for
keys. It uses a key-centric Public Key Infrastructure (PKI) rather keys. It uses a key-centric public key management scheme, rather
than the more typical approaches based on a certificate in the styles than the more typical approaches based on a certificate in the styles
of Kohnfelder (X.509) [Kohnfelder] or Zimmermann (web of trust). For of Kohnfelder (X.509) [Kohnfelder] or Zimmermann (web of trust)
DKIM, the owner of a domain name asserts the validity of a key, [WebofTrust]. For DKIM, the owner of a domain name asserts the
rather than relying on the key having a broader semantic implication validity of a key, rather than having the validity of the key
of the assertion, such as a quality assessment of the key's owner. attested to by a trusted third party, often including other
DKIM treats quality assessment as an independent, value-added assertions, such as a quality assessment of the key's owner. DKIM
service, beyond the initial work of deploying a verifying signature treats quality assessment as an independent, value-added service,
beyond the initial work of deploying a signature verification
service. service.
Further, DKIM's PKI is provided by adding information records to the Further, DKIM's key management is provided by adding information
existing Domain Name System (DNS) [RFC1034], rather than requiring records to the existing Domain Name System (DNS) [RFC1034], rather
deployment of a new query infrastructure. This approach has than requiring deployment of a new query infrastructure. This
significant operational advantages. First, it avoids the approach has significant operational advantages. First, it avoids
considerable barrier of creating a new global infrastructure; hence the considerable barrier of creating a new global infrastructure;
it leverages a global base of administrative experience and highly hence it leverages a global base of administrative experience and
reliable distributed operation. Second, the technical aspect of the highly reliable distributed operation. Second, the technical aspect
DNS is already known to be efficient. Any new service would have to of the DNS is already known to be efficient. Any new service would
undergo a period of gradual maturation, with potentially problematic have to undergo a period of gradual maturation, with potentially
early-stage behaviors. By (re-)using the DNS, DKIM avoids these problematic early-stage behaviors. By (re-)using the DNS, DKIM
growing pains. avoids these growing pains.
1.3. Internet Mail Background 1.3. Internet Mail Background
The basic Internet Email service has evolved extensively over its The basic Internet Email service has evolved extensively over its
several decades of continuous operation. Its modern architecture several decades of continuous operation. Its modern architecture
comprises a number of specialized components. A discussion about comprises a number of specialized components. A discussion about
Mail User Agents (MUA), Mail Handling Services (MHS), Mail Transfer Mail User Agents (MUA), Mail Handling Services (MHS), Mail Transfer
Agents (MTA), Mail Submission Agents (MSA), Mail Delivery Agents Agents (MTA), Mail Submission Agents (MSA), Mail Delivery Agents
(MDA), Mail Service Providers (MSP), Administrative Management (MDA), Mail Service Providers (MSP), Administrative Management
Domains (ADMDs), and their relationships can be found in Appendix A. Domains (ADMDs), and their relationships can be found in Appendix A.
1.4. Discussion Venue 1.4. Discussion Venue
NOTE TO RFC EDITOR: This "Discussion Venue" section is to be NOTE TO RFC EDITOR: This "Discussion Venue" section is to be
removed prior to publication. removed prior to publication.
This document is being discussed on the DKIM mailing list, This document is being discussed on the DKIM mailing list,
ietf-dkim@mipassoc.org. ietf-dkim@mipassoc.org.
1.4.1. Changes to document
In addition to simple wordsmithing, the following substantive changes
were made:
Service Arch figure and text: (per Allman) Existing figure and text
carries vestigial references to role of MSA and MDA. New text
switches focus to ADMD more completely and merely cites possible
functional modules within them.
Identity vs. Identifier: Added text in Scope to define terms and
their relationship.
Message Validity: Added section discussing restricted implication
of this.
2. The DKIM Value Proposition 2. The DKIM Value Proposition
The nature and origins of a message are often falsely stated. Such The nature and origins of a message often are falsely stated. Such
misrepresentations may (but not necessarily) be employed in order to misrepresentations may be employed for legitimate reasons or for
perpetrate abuse. DKIM provides a foundation for distinguishing nefarious reasons. DKIM provides a foundation for distinguishing
legitimate mail, and thus a means of associating a verifiable legitimate mail, and thus a means of associating a verifiable
identifier with a message. Given the presence of that identifier, a identifier with a message. Given the presence of that identifier, a
receiver can make decisions about further handling of the message, receiver can make decisions about further handling of the message,
based upon assessments of the identity that is associated with the based upon assessments of the identity that is associated with the
identifier. identifier.
Receivers who successfully verify a signature can use information Receivers who successfully verify a signature can use information
about the signer as part of a program to limit spam, spoofing, about the signer as part of a program to limit spam, spoofing,
phishing, or other undesirable behavior. DKIM does not, itself, phishing, or other undesirable behavior. DKIM does not, itself,
prescribe any specific actions by the recipient; rather it is an prescribe any specific actions by the recipient; rather it is an
enabling technology for services that do. enabling technology for services that do.
These services will typically: These services will typically:
1. Determine a verified identity, if possible. 1. Determine a verified identity as taking responsibility for the
message, if possible.
2. Determine whether a known identity is trusted. 2. Evaluate the trustworthiness of this/these identities.
The role of DKIM is to perform the first of these; DKIM is an enabler The role of DKIM is to perform the first of these; DKIM is an enabler
for the second. for the second.
2.1. Identity Verification 2.1. Identity Verification
Consider an attack made against an organization or against customers Consider an attack made against an organization or against customers
of an organization. The name of the organization is linked to of an organization. The name of the organization is linked to
particular Internet domain names (identifiers). One point of particular Internet domain names (identifiers). Attackers can
leverage for attackers is either to use a legitimate domain name, leverage either using a legitimate domain name, without
without authorization, or to use a "cousin" name that is similar to authorization, or using a "cousin" name that is similar to one that
one that is legitimate, but is not controlled by the target is legitimate, but is not controlled by the target organization. An
organization. An assessment service that uses DKIM can differentiate assessment service that uses DKIM can differentiate between domains
between domains used by known organizations and domains used by used by known organizations and domains used by others. As such,
others. As such, DKIM performs the positive step of identifying DKIM performs the positive step of identifying messages associated
messages associated with verifiable identities, rather than the with verifiable identities, rather than the negative step of
negative step of identifying messages with problematic use of identifying messages with problematic use of identities. Whether a
identities. Whether a verified identity belongs to a Good Actor or a verified identity belongs to a Good Actor or a Bad Actor is a
Bad Actor becomes a later step of assessment. question for later stages of assessment.
2.2. Enabling Trust Assessments 2.2. Enabling Trust Assessments
Email receiving services are faced with a basic decision: Should they Email receiving services are faced with a basic decision: Whether to
deliver a newly-arrived message to the indicated recipient? That is, deliver a newly-arrived message to the indicated recipient? That is,
does the receiving service trust that the message is sufficiently does the receiving service trust that the message is sufficiently
"safe" to be viewed? For the modern Internet, most receiving "safe" to be viewed? For the modern Internet, most receiving
services have an elaborate engine that formulates this quality services have an elaborate engine that formulates this quality
assessment. These engines take a variety of information as input to assessment. These engines take a variety of information as input to
the decision, such as from reputation lists and accreditation the decision, such as from reputation lists and accreditation
services. As the engine processes information, it raises or lowers services. As the engine processes information, it raises or lowers
its trust assessment for the message. its trust assessment for the message.
DKIM provides additional information to this process by declaring a In order to formulate reputation information, an accurate, stable
valid "responsible" identity about which the engine can make quality identifier is needed. Otherwise, the information might not pertain
assessments. By itself, a valid DKIM signature neither lowers nor to the identified organization's own actions. When using an IP
raises the level of trust associated with the message, but it enables Address, accuracy is based on the belief that the underlying Internet
other mechanisms to be used for doing so. infrastructure supplies an accurate address. When using domain based
reputation data, some other form of validation is needed, since it is
not supplied independently by the infrastructure
DKIM satisfies this requirement by declaring a valid "responsible"
identity about which the engine can make quality assessments and by
using a digital signature to ensure that use of the identifier is
authorized. However by itself, a valid DKIM signature neither lowers
nor raises the level of trust associated with the message, but it
enables other mechanisms to be used for doing so.
An organization might build upon its use of DKIM by publishing An organization might build upon its use of DKIM by publishing
information about its Signing Practices (SP). This could permit information about its Signing Practices (SP). This could permit
detecting some messages that purport to be associated with a domain, detecting some messages that purport to be associated with a domain,
but which are not. As such, an SP can cause the trust assessment to but which are not. As such, an SP can cause the trust assessment to
be reduced, or leave it unchanged. be reduced, or leave it unchanged.
2.3. Establishing Message Validity
Though man-in-the-middle attacks are historically rare in email, it
is nevertheless theoretically possible for a message to be modified
during transit. An interesting side effect of the cryptographic
method used by DKIM is that it is possible to be certain that a
signed message (or, if l= is used, the signed portion of a message)
has not been modified. If it has been changed in any way, then the
message will not be verified successfully with DKIM.
As described above, this validity neither lowers nor raises the level
of trust associated with the message. If it was an untrustworthy
message when initially sent, the verifier can be certain that the
message will be equally untrustworthy upon receipt and successful
verification.
3. DKIM Goals 3. DKIM Goals
DKIM adds an end-to-end authentication mechanism to the existing DKIM adds an end-to-end authentication capability to the existing
email transfer infrastructure. This motivates functional goals about email transfer infrastructure. It defines a mechanism that only
the authentication itself and operational goals about its integration needs to be supported by the signer and the validator, rather than
with the rest of the Internet email service. any of the functional components along the handling path. This
motivates functional goals about the authentication itself and
operational goals about its integration with the rest of the Internet
email service.
3.1. Functional Goals 3.1. Functional Goals
3.1.1. Use Domain-level granularity for assurance 3.1.1. Use Domain-level granularity for assurance
DKIM seeks accountability at the coarse granularity of an DKIM provides accountability at the coarse granularity of an
organization or, perhaps, a department. An existing Internet service organization or, perhaps, a department. An existing construct that
construct that enables this granularity is the Domain Name [RFC1034]. enables this granularity is the Domain Name [RFC1034]. DKIM binds a
DKIM binds the signing key record to the Domain Name. Further signing key record to the Domain Name. Further benefits of using
benefits of using domain names include simplifying key management, domain names include simplifying key management, enabling signing by
enabling signing by the infrastructure as opposed to the MUA, and the infrastructure as opposed to the MUA, and reducing privacy
potential privacy issues. concerns.
Contrast this with OpenPGP and S/MIME, which provide end-to-end Contrast this with OpenPGP and S/MIME, which associate validation
validation in terms of individual authors, notably using full email with individual authors, using their using full email addresses.
addresses.
3.1.2. Implementation Locality 3.1.2. Implementation Locality
Any party, anywhere along the transit path can implement DKIM Any party, anywhere along the transit path can implement DKIM
signing. Its use is not confined to the end systems or only in a signing. Its use is not confined to particular systems, such as the
boundary MTA. author's MUA or the inbound boundary MTA, and there can be more than
one signature per message.
3.1.3. Allow delegation of signing to independent parties 3.1.3. Allow delegation of signing to independent parties
Different parties have different roles in the process of email Different parties have different roles in the process of email
exchange. Some are easily visible to end users and others are exchange. Some are easily visible to end users and others are
primarily visible to operators of the service. DKIM was designed to primarily visible to operators of the service. DKIM was designed to
support signing by any of these different parties and to permit them support signing by any of these different parties and to permit them
to sign with any domain name that they deem appropriate (and for to sign with any domain name that they deem appropriate (and for
which they hold authorized signing keys.) As an example an which they hold authorized signing keys.) As an example an
organization that creates email content often delegates portions of organization that creates email content often delegates portions of
its processing or transmission to an outsourced group. DKIM supports its processing or transmission to an outsourced group. DKIM supports
this mode of activity, in a manner that is not normally visible to this mode of activity, in a manner that is not normally visible to
end users. end users. Similarly, a reputation provider can delegate a signing
key for a domain under the control of the provider, to be used by an
organization the provider is prepared to vouch for.
3.1.4. Distinguish the core authentication mechanism from its 3.1.4. Distinguish the core authentication mechanism from its
derivative uses derivative uses
An authenticated identity can be subject to a variety of processing An authenticated identity can be subject to a variety of assessment
policies, either ad hoc or standardized. The only semantics inherent policies, either ad hoc or standardized. DKIM separates basic
to a DKIM signature is that the signer is asserting (some) authentication from assessment. The only semantics inherent to a
responsibility for the message. All other mechanisms and meanings DKIM signature is that the signer is asserting (some) responsibility
are built on this core service. One such mechanism might assert a for the message. Hence, a DKIM signature only means that the signer
relationship between the signing identity and the author, as is asserting (some) responsibility for the message, and nothing more.
specified in the From: header field's domain identity[RFC2822]. Other services can build upon this core association, but their
details are beyond the scope of that core. One such mechanism might
assert a relationship between the signing identity and the author, as
specified in the From: header field's domain identity.[RFC2822]
Another might specify how to treat an unsigned message with that Another might specify how to treat an unsigned message with that
From: field domain. From: field domain.
3.1.5. Retain ability to have anonymous email 3.1.5. Retain ability to have anonymous email
The ability to send a message that does not identify its author is The ability to send a message that does not identify its author is
considered to be a valuable quality of the current email service that considered to be a valuable quality of the current email service that
needs to be retained. DKIM is compatible with this goal since it needs to be retained. DKIM is compatible with this goal since it
permits authentication of the email system operator, rather than the permits authentication of the email system operator, rather than the
content author. If it is possible to obtain effectively anonymous content author. If it is possible to obtain effectively anonymous
accounts at example.com, knowing that a message definitely came from accounts at example.com, knowing that a message definitely came from
example.com does not threaten the anonymity of the user who authored example.com does not threaten the anonymity of the user who authored
it. it.
3.2. Operational Goals 3.2. Operational Goals
3.2.1. Treat verification failure the same as no signature present 3.2.1. Make presence of signature transparent to non-supporting
recipients
As a sub-goal to the requirement for transparency, a DKIM signature
verifier is to treat messages with signatures that fail as if they
were unsigned. Hence the message will revert to normal handling,
through the receiver's existing filtering mechanisms. Thus, DKIM
specifies that an assessing site is not to take a message that has a
broken signature and treat it any differently than if the signature
weren't there.
Contrast this with OpenPGP and S/MIME, which were designed for strong
cryptographic protection. This included treating verification
failure as message failure.
3.2.2. Make signatures transparent to non-supporting recipients
In order to facilitate incremental adoption, DKIM is designed to be In order to facilitate incremental adoption, DKIM is designed to be
transparent to recipients that do not support it. A DKIM signature transparent to recipients that do not support it. A DKIM signature
does not "get in the way" for such recipients. does not "get in the way" for such recipients.
Contrast this with S/MIME and OpenPGP, which modify the message body. Contrast this with S/MIME and OpenPGP, which modify the message body.
Hence, their presence is potentially visible to email recipients, Hence, their presence is potentially visible to email recipients,
whose user software needs to process the associated constructs. whose user software needs to process the associated constructs.
3.2.2. Treat verification failure the same as no signature present
DKIM must also be transparent to existing assessment mechanisms.
Consequently, a DKIM signature verifier is to treat messages with
signatures that fail as if they were unsigned. Hence the message
will revert to normal handling, through the receiver's existing
filtering mechanisms. Thus, DKIM specifies that an assessing site is
not to take a message that has a broken signature and treat it any
differently than if the signature weren't there.
Contrast this with OpenPGP and S/MIME, which were designed for strong
cryptographic protection. This included treating verification
failure as message failure.
3.2.3. Permit incremental adoption for incremental benefit 3.2.3. Permit incremental adoption for incremental benefit
DKIM can immediately provide benefits between any two organizations DKIM can be used by any two organizations that exchange email and
that exchange email and implement DKIM. In the usual manner of implement DKIM; it does not require adoption within the open
"network effects", the benefits of DKIM increase dramatically as its Internet's email infrastructure. In the usual manner of "network
adoption increases. effects", the benefits of DKIM increase as its adoption increases.
Although it is envisioned that this mechanism will call upon Although this mechanism can be used in association with independent
independent services to aid in the assessment of DKIM results, they assessment services, such services are not essential in order to
are not essential in order to obtain initial benefit. For example obtain initial benefit. For example DKIM allows (possibly large)
DKIM allows (possibly large) pair-wise sets of email providers and pairwise sets of email providers and spam filtering companies to
spam filtering companies to distinguish mail that is associated with distinguish mail that is associated with a known organization, versus
a known organization from mail that might deceptively purport to have mail that might deceptively purport to have the affiliation. This in
the affiliation. This in turn allows the development of "whitelist" turn allows the development of "whitelist" schemes whereby
schemes whereby authenticated mail from a known source with good authenticated mail from a known source with good reputation is
reputation is allowed to bypass some anti-abuse filters. allowed to bypass some anti-abuse filters.
In effect the email receiver is using their set of known In effect the email receiver can use their set of known relationships
relationships to generate their own reputation data. This works to generate their own reputation data. This works particularly well
particularly well for traffic between large sending providers and for traffic between large sending providers and large receiving
large receiving providers. However it also works well for any providers. However it also works well for any operator, public or
operator, public or private, that has mail traffic dominated by private, that has mail traffic dominated by exchanges among a stable
exchanges among a stable set of organizations. set of organizations.
Management of email deliverability problems currently represents a Management of email delivery problems currently represents a
significant pain point for email administrators at every point on the significant pain point for email administrators at every point on the
mail transit path. Administrators who have deployed DKIM mail transit path. Administrators who have deployed DKIM
verification have an incentive to evangelize the use of DKIM verification have an incentive to evangelize the use of DKIM
signatures to senders who may subsequently complain that their email signatures to senders who might subsequently complain that their
is not being delivered. email is not being delivered.
3.2.4. Minimize the amount of required infrastructure 3.2.4. Minimize the amount of required infrastructure
A new service, or an enhancement to an existing service, requires In order to allow early adopters to gain early benefit, DKIM makes no
adoption in a critical mass of system components, before it can be changes to the core Internet Mail service and, instead, can provide a
useful. The greater the number of required adopters, the higher the useful benefit for any individual pair of signers and verifiers who
adoption barrier. This becomes particularly serious when adoption is are exchanging mail. Similarly, DKIM's reliance on the Domain Name
required by independent, intermediary -- that is, infrastructure -- System greatly reduces the amount of new administrative
service providers. In order to allow early adopters to gain early infrastructure that is needed across the open Internet.
benefit, DKIM makes no changes to the core Internet Mail service and,
instead, can provide a useful benefit for any individual pair of
signers and verifiers who are exchanging mail. Similarly, DKIM's
reliance on the Domain Name System greatly reduces the amount of new
administrative infrastructure that is needed across the open
Internet.
3.2.5. Permit wide range of deployment choices 3.2.5. Permit a wide range of deployment choices
DKIM can be deployed at a variety of places within an organization's DKIM can be deployed at a variety of places within an organization's
email service. This permits the organization to choose how much or email service. This affords flexibility in terms of who administers
how little they want DKIM to be part of their service, rather than its use, as well as what traffic carries a DKIM signature. For
part of a more localized operation. example, employing DKIM at an outbound boundary MTA will mean that it
is administered by the organization's central IT department and that
internal messages are not signed.
4. DKIM Function 4. DKIM Function
DKIM has a very constrained set of capabilities, primarily targeting DKIM has a very constrained set of capabilities, primarily targeting
email while it is in transit from an author to a set of recipients. email while it is in transit from an author to a set of recipients.
It creates the ability to associate verifiable information with a It associates verifiable information with a message, especially a
message, especially a responsible identity. When a message does not responsible identity. When a message does not have a valid signature
have a valid signature associated with the author, DKIM SP will associated with the author, DKIM SP will permit the domain name of
permit the domain name of the author to be used for obtaining the author to be used for obtaining information about their signing
information about their signing practices. practices.
4.1. The Basic Signing Service 4.1. Basic Signing
With the DKIM signature mechanism, a signer chooses a signing With the DKIM signature mechanism, a signer chooses a signing
identity based on their domain name, performs digital signing on the identity based on their domain name, performs digital signing on the
message, and records signature information in a DKIM header field. A message, and adds the signature information using a DKIM header
verifier obtains the domain name and the "selector" from the DKIM field. A verifier obtains the domain name and the "selector" from
header field, queries for a public key associated with the name, and the DKIM header field, obtains the public key associated with the
verifies the signature. name, and verifies the signature.
DKIM permits any domain name to be used for signing, and supports DKIM permits any domain name to be used for signing, and supports
extensible choices for various algorithms. As is typical for extensible choices for various algorithms. As is typical for
Internet standards, there is a core set of algorithms that all Internet standards, there is a core set of algorithms that all
implementations are required to support, in order to guarantee basic implementations are required to support, in order to guarantee basic
interoperability. interoperability.
DKIM permits restricting the use of a signature key (by using s=) to DKIM permits restricting the use of a signature key to signing
signing messages for particular types of services, such as only for messages for particular types of services, such as only for a single
email. This is intended to be helpful when delegating signing source of email. This is intended to be helpful when delegating
authority, such as to a particular department or to a third-party signing authority, such as to a particular department or to a third-
outsourcing service. party outsourcing service.
With DKIM the signer explicitly lists the headers that are signed, With DKIM the signer explicitly lists the headers that are signed,
such as From:, Date: and Subject:. By choosing the minimal set of such as From:, Date: and Subject:. By choosing the minimal set of
headers needed, the signature is likely to be considerably more headers needed, the signature is likely to be considerably more
robust against the handling vagaries of intermediary MTAs. robust against the handling vagaries of intermediary MTAs.
4.2. Characteristics of a DKIM signature 4.2. Characteristics of a DKIM Signature
A DKIM signature covers the message body and selected header fields. A DKIM signature applies to the message body and selected header
The signer computes a hash of the selected header fields and another fields. The signer computes a hash of the selected header fields and
hash of the body. The signer then uses a private key to another hash of the body. The signer then uses a private key to
cryptographically encode this information, along with other signing cryptographically encode this information, along with other signing
parameters. Signature information is placed into the DKIM-Signature parameters. Signature information is placed into DKIM-Signature:, a
header field, a new [RFC2822] header field of the message. new [RFC2822] message header field.
4.3. The Selector construct 4.3. The Selector Construct
The key for a signature is associated with a domain name, as The key for a signature is associated with a domain name. That
specified in the d= parameter of the DKIM-Signature header. That domain name provides the complete identity used for making
domain name, or the domain name or address in the i= parameter, assessments about the signer. (The DKIM specification does not give
provide the complete identity used for making assessments about the any guidance on how to do an assessment.) However this name is not
signer. (The DKIM specification does not give any guidance on how to sufficient for making a DNS query to obtain the key needed to verify
do an assessment.) However this name is not sufficient for making a the signature.
DNS query to obtain the key needed to verify the signature.
A single domain can use multiple signing keys and/or multiple A single domain can use multiple signing keys and/or multiple
potential signers. To support this, DKIM identifies a particular potential signers. To support this, DKIM identifies a particular
signature as a combination of the domain name and an added field, signature as using a combination of the domain name and an added
called the "selector", specified in separate DKIM-Signature header field, called the "selector", specified in a separate DKIM-Signature:
field parameters. header field parameter.
NOTE: The semantics of the selector (if any) are strictly reserved NOTE: The semantics of the selector (if any) are strictly reserved
to the signer and should be treated as an opaque string by all to the signer and is to be treated as an opaque string by all
other parties. If verifiers were to employ the selector as part other parties. If verifiers were to employ the selector as part
of a name assessment mechanism, then there would be no remaining of an assessment mechanism, then there would be no remaining
mechanism for making a transition from an old, or compromised, key mechanism for making a transition from an old, or compromised, key
to a new one. to a new one.
Signers often need to support multiple assessments about their
organization, such as to distinguish one type of message from
another, or one portion of the organization from another. To permit
assessments that are independent, one method is for an organization
to use different sub-domains in the "d=" parameter, such as
"transaction.example.com" versus "newsletter.example.com", or
"productA.example.com" versus "productB.example.com".
4.4. Verification 4.4. Verification
After a message has been signed, any agent in the message transit After a message has been signed, any agent in the message transit
path can verify the signature to determine that the signing identity path can verify the signature to determine that the signing identity
took responsibility for the message. Message recipients can verify took responsibility for the message. Message recipients can verify
the signature by querying the DNS for the signer's domain directly, the signature by querying the DNS for the signer's domain directly,
to retrieve the appropriate public key, and thereby confirm that the to retrieve the appropriate public key, and thereby confirm that the
message was attested to by a party in possession of the private key message was signed to by a party in possession of the private key for
for the signing domain. Typically, verification will be done by an the signing domain. Typically, verification will be done by an agent
agent in the Administrative Management Domain (ADMD) of the message in the Administrative Management Domain (ADMD) of the message
recipient. recipient.
5. Service Architecture 4.5. Sub-Domain Assessment
The DKIM service is divided into components that are performed using Signers often need to support multiple assessments about their
different, external services, such as for key retrieval and relaying organization, such as to distinguish one type of message from
email. The basic DKIM signing specification defines an initial set another, or one portion of the organization from another. To permit
of these services (using DNS and SMTP), in order to ensure a basic assessments that are independent, one method is for an organization
level of interoperability. to use different sub-domains in the "d=" parameter, such as
"transaction.example.com" versus "newsletter.example.com", or
"productA.example.com" versus "productB.example.com". These can be
entirely separate from the rfc2822.From header field domain.
| 5. Service Architecture
|- RFC2822 Message
V DKIM use external service components, such as for key retrieval and
+--------+ +------------------------------------+ relaying email. This specification defines an initial set, using DNS
| Private| | ORIGINATING OR RELAYING ADMD (MSA) | and SMTP, for basic interoperability.
| Key |.>| Sign Message | |
| Store | +--------------+---------------------+ |- RFC2822 Message
+--------+ | V
(paired) | +--------+ +--------------------------------+
+--------+ | +-----------+ | Private| | ORIGINATING OR RELAYING ADMD |
| Public | | | Remote | | Key +...>| Sign Message |
| Key | [Internet] | Sender | | Store | +---------------+----------------+
| Store | | | Practices | +--------+ |
+----+---+ | +-----+-----+ (paired) [Internet]
. V . +--------+ | +-----------+
. +-----------------------------------+ . | Public | +--------------------------------+ | Remote |
. | RELAYING OR DELIVERING ADMD (MDA) | . | Key | | RELAYING OR DELIVERING ADMD | | Sender |
. | Message Signed? | . | Store | | Message Signed? | | Practices |
. +--------+---------------+----------+ . +----+---+ +-----+--------------------+-----+ +-----+-----+
. |yes |no . . |yes |no .
. V | . . V | .
. +------------+ | . . +-------------+ | .
+.....>| Verify +----+ | . +.......>| Verify +--------+ | .
| Signatures | | | . | Signature | | | .
+-----+------+ | | . +------+------+ | | .
pass| fail| | . pass| fail| | .
V | | . V | | .
+--------+ | | . +-------------+ | | .
+.......>| Assess | | | . | | | | .
. | Signer | V V . +.......>| Assessments | | | .
. +---+----+ +-------+ . . | | V V .
. | / Check \<............+ . +------+------+ +-------+ .
. +------>/ Signing \ . | / Check \<............+
. | / Practices \<..........+ . +---------->/ Signing \
. | +-------+-------+ . . | / Practices \<..........+
. | | . . | +-------+-------+ .
. | V . . | | .
+---+---------+ | +-----------+ +------+-----+ . | V .
|Reputation/ | | | Message | | Local Info | +----+--------+ | +-----------+ +------+-----+
|Accreditation| +------>| Filtering | | on Sender | |Reputation/ | | | Message | | Local Info |
|Info | | Engine | | Practices | |Accreditation| +---------->| Filtering | | on Sender |
+-------------+ +-----------+ +------------+ |Info | | Engine | | Practices |
+-------------+ +-----------+ +------------+
Figure 1: DKIM Service Architecture Figure 1: DKIM Service Architecture
As shown in Figure 1, basic message processing is divided between the As shown in Figure 1, basic message processing is divided between a
MSA and the MDA. signing Administrative Management Domain (ADMD) and a validating
ADMD. At its simplest, this is between the Originating ADMD and the
delivering ADMD, but can involve other ADMDs in the handling path.
The MSA The MSA signs the message, using private information from Signing: Signing is performed by an authorized module within the
the Key Store. signing ADMD and uses private information from the Key Store, as
discussed below. Within the originating ADMD, this might be
performed by the MUA, MSA or an MTA.
The MDA The MDA verifies the signature or determines whether a Validating: Validating is performed by an authorized module within
signature was required. Verifying the signature uses public the validating ADMD. Within a delivering ADMD, validating might
information from the Key Store. If the signature passes, be performed by an MTA, MDA or MUA. The module verifies the
reputation information is used to asses the signer and that signature or determines whether a particular signature was
information is passed to the message filtering system. If the required. Verifying the signature uses public information from
signature fails or there is no signature, information about the the Key Store. If the signature passes, reputation information is
related signing practices is retrieved remotely and/or locally, used to asses the signer and that information is passed to the
and that information is passed to the message filtering system. message filtering system. If the signature fails or there is no
signature using the author's domain, information about signing
practices related to the author can be retrieved remotely and/or
locally, and that information is passed to the message filtering
system.
Note: Figure 1 does not show the effects on the message handling If message has more than one valid signature, the order in which the
when multiple signatures or non-author signatures are present. signers are assessed and the interactions among the assessments are
not defined by the DKIM specification.
5.1. Administration and Maintenance 5.1. Administration and Maintenance
A number of tables and services are used to provide external A number of tables and services are used to provide external
information. Each of these introduces administration and maintenance information. Each of these introduces administration and maintenance
requirements. requirements.
Key Store DKIM uses public/private (asymmetric) key cryptography. Key Store: DKIM uses public/private (asymmetric) key cryptography.
The signer users a private key and the validator uses the The signer users a private key and the validator uses the
corresponding public key. The current DKIM signing specification corresponding public key. The current DKIM signing specification
provides for querying the Domain Names Service (DNS), to permit a provides for querying the Domain Names Service (DNS), to permit a
validator to obtain the public key. The signing organization validator to obtain the public key. The signing organization
therefore must have a means of adding a key to the DNS, for every therefore needs to have a means of adding a key to the DNS, for
selector/domain-name combination. Further, the signing every selector/domain-name combination. Further, the signing
organization needs policies for distributing and revising keys. organization needs policies for distributing and revising keys.
Reputation/Accreditation If a message contains a valid signature, Reputation/Accreditation: If a message contains a valid signature,
then the verifier can evaluate the associated domain name's then the verifier can evaluate the associated domain name's
reputation. Quality-assessment information, which is associated reputation, in order to determine appropriate delivery or display
with a domain name, comes in many forms and from many sources. options for that message. Quality-assessment information, which
DKIM does not define assessment services. It's relevance to them is associated with a domain name, comes in many forms and from
is to provide a validated domain name, upon which assessments can many sources. DKIM does not define assessment services. It's
be made. relevance to them is to provide a validated domain name, upon
which assessments can be made.
Signing Practices (SP) Separate from determining the validity of a Signing Practices (SP): Separate from determining the validity of a
signature, and separate from assessing the reputation of the signature, and separate from assessing the reputation of the
organization that is associated with the signed identity, there is organization that is associated with the signed identity, there is
an the opportunity to determine any organizational practices an the opportunity to determine any organizational practices
concerning a domain name. Practices can range widely. They can concerning a domain name. Practices can range widely. They can
be published by the owner of the domain or they can be maintained be published by the owner of the domain or they can be maintained
by the evaluating site. They can pertain to the use of the domain by the evaluating site. They can pertain to the use of the domain
name, such as whether it is used for signing messages, whether all name, such as whether it is used for signing messages, whether all
mail having that domain name in the author From: header field is mail having that domain name in the author From: header field is
signed, or whether such mail is to be discarded in the absence of signed, or even whether the domain owner recommends discarding
an appropriate signature. The statements of practice are made at messages in the absence of an appropriate signature. The
the level of a domain name, and are distinct from assessments made statements of practice are made at the level of a domain name, and
about particular messages, as occur in a Message Filtering Engine. are distinct from assessments made about particular messages, as
Such assessments of practices can provide useful input for the occur in a Message Filtering Engine. Such assessments of
Message Filtering Engine's determination of message handling. As practices can provide useful input for the Message Filtering
practices are defined, each domain name owner needs to consider Engine's determination of message handling. As practices are
what information to publish. The nature and degree of checking defined, each domain name owner needs to consider what information
practices, if any is performed, is optional to the evaluating site to publish. The nature and degree of checking practices, if any
and is strictly a matter of local policy. is performed, is optional to the evaluating site and is strictly a
matter of local policy.
5.2. Signing 5.2. Signing
Signing can be performed by a component of the ADMD that creates the Signing can be performed by a component of the ADMD that creates the
message, and/or within any ADMD along the relay path. The signer message, and/or within any ADMD along the relay path. The signer
uses the appropriate private key. uses the appropriate private key.
5.3. Verifying 5.3. Verifying
Verification can be performed by any functional component along the Verification can be performed by any functional component along the
relay and delivery path. Verifiers retrieve the public key based relay and delivery path. Verifiers retrieve the public key based
upon the parameters stored in the message. upon the parameters stored in the message.
5.4. Unverified or Unsigned Mail 5.4. Unverified or Unsigned Mail
Note that a failed signature causes the message to be treated in the Messages lacking a valid author signature (a signature associated
same manner as one that is unsigned. Messages lacking a valid author with the author of the message as opposed to a signature associated
signature (a signature associated with the author of the message as with an intermediary) can prompt a query for any published "signing
opposed to a signature associated with an intermediary) can prompt a practices" information, as an aid in determining whether the author
query for any published "signing practices" information, as an aid in information has been used without authorization.
determining whether the author information has been used without
authorization.
5.5. Assessing 5.5. Assessing
Figure 1 shows the verified identity as being used to assess an Figure 1 shows the verified identity as being used to assess an
associated reputation, but it could be applied for other tasks, such associated reputation, but it could be applied for other tasks, such
as management tracking of mail. A popular use of reputation as management tracking of mail. A popular use of reputation
information is as input to a filtering engine that decides whether to information is as input to a filtering engine that decides whether to
deliver -- and possibly whether to specially mark -- a message. deliver -- and possibly whether to specially mark -- a message.
Filtering engines have become complex and sophisticated. Their Filtering engines have become complex and sophisticated. Their
details are outside of the scope of DKIM, other than the expectation details are outside of the scope of DKIM, other than the expectation
that the validated identity produced by DKIM will be added to the that the validated identity produced by DKIM can accumulate its own
varied soup of rules used by the engines. The rules can cover signed reputation, and will be added to the varied soup of rules used by the
messages and can deal with unsigned messages from a domain, if the engines. The rules can cover signed messages and can deal with
domain has published information about its practices. unsigned messages from a domain, if the domain has published
information about its practices.
5.6. DKIM Placement within an ADMD 5.6. DKIM Processing within an ADMD
It is expected that the most common venue for a DKIM implementation It is expected that the most common venue for a DKIM implementation
will be within the infrastructures of the authoring organization's will be within the infrastructures of the authoring organization's
outbound service and the receiving organization's inbound service, outbound service and the receiving organization's inbound service,
such as a department or a boundary MTA. DKIM can be implemented in such as a department or a boundary MTA. DKIM can be implemented in
an author's or recipient MUA, but this is expected to be less an author's or recipient MUA, but this is expected to be less
typical, since it has higher administration and support costs. typical, since it has higher administration and support costs.
A Mediator, such as a mailing list, often can re-post a message A Mediator is an MUA that receives a message and can re-post a
without breaking the DKIM signature. Furthermore it can add its own modified version of it, such as to a mailing list. A DKIM signature
signature. This can be added by the Mediator software itself, or by can survive some types of modifications through this process.
any outbound component in the Mediator's ADMD. Furthermore the Mediator can add its own signature. This can be
added by the Mediator software itself, or by any outbound component
in the Mediator's ADMD.
6. Security Considerations 6. Considerations
6.1. Security Considerations
The security considerations of the DKIM protocol are described in the The security considerations of the DKIM protocol are described in the
DKIM base specification [RFC4871]. DKIM base specification [RFC4871].
7. IANA Considerations 6.2. IANA Considerations
There are no actions for IANA. There are no actions for IANA.
NOTE TO RFC EDITOR: This section may be removed prior to NOTE TO RFC EDITOR: This section is to be removed prior to
publication. publication.
8. Acknowledgements 6.3. Acknowledgements
Many people contributed to the development of the DomainKeys Many people contributed to the development of the DomainKeys
Identified Mail and the efforts of the DKIM Working Group is Identified Mail and the efforts of the DKIM Working Group is
gratefully acknowledged. In particular, we would like to thank Jim gratefully acknowledged. In particular, we would like to thank Jim
Fenton for his extensive feedback diligently provided on every Fenton for his extensive feedback diligently provided on every
version of this document. version of this document.
9. Informative References 7. Informative References
[I-D.kucherawy-sender-auth-header] [I-D.kucherawy-sender-auth-header]
Kucherawy, M., "Message Header Field for Indicating Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", Message Authentication Status",
draft-kucherawy-sender-auth-header-11 (work in progress), draft-kucherawy-sender-auth-header-15 (work in progress),
February 2008. July 2008.
[Kohnfelder] [Kohnfelder]
Kohnfelder, L., "Towards a Practical Public-key Kohnfelder, L., "Towards a Practical Public-key
Cryptosystem", May 1978. Cryptosystem", May 1978.
[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",
skipping to change at page 19, line 14 skipping to change at page 20, line 24
Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
May 2007. May 2007.
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM) J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007. Signatures", RFC 4871, May 2007.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[WebofTrust]
Wikipedia, "Web of Trust",
URL http://en.wikipedia.org/wiki/Web_of_trust,
<http://en.wikipedia.org/wiki/Web_of_trust>.
Appendix A. Internet Mail Background Appendix A. Internet Mail Background
A.1. Core Model
Internet Mail is split between the user world, in the form of Mail Internet Mail is split between the user world, in the form of Mail
User Agents (MUA), and the transmission world, in the form of the User Agents (MUA), and the transmission world, in the form of the
Mail Handling Service (MHS) composed of Mail Transfer Agents (MTA). Mail Handling Service (MHS) composed of Mail Transfer Agents (MTA).
The MHS is responsible for accepting a message from one user, the The MHS is responsible for accepting a message from one user, the
author, and delivering it to one or more other users, the recipients. author, and delivering it to one or more other users, the recipients.
This creates a virtual MUA-to-MUA exchange environment. The first This creates a virtual MUA-to-MUA exchange environment. The first
component of the MHS is called the Mail Submission Agent (MSA) and component of the MHS is called the Mail Submission Agent (MSA) and
the last is called the Mail Delivery Agent (MDA). the last is called the Mail Delivery Agent (MDA).
An email Mediator is both an inbound MDA and outbound MSA. It takes An email Mediator is both an inbound MDA and outbound MSA. It takes
delivery of a message and re-posts it for further distribution, delivery of a message, makes changes appropriate to its service, and
retaining the original From: header field. A mailing list is a then re-posts it for further distribution. Typically the new message
will retain the original From: header field. A mailing list is a
common example of a Mediator. common example of a Mediator.
The modern Internet Mail service is marked by many independent The modern Internet Mail service is marked by many independent
operators, many different components for providing users with service operators, many different components for providing users with service
and many other components for performing message transfer. and many other components for performing message transfer.
Consequently, it is necessary to distinguish administrative Consequently, it is necessary to distinguish administrative
boundaries that surround sets of functional components, which are boundaries that surround sets of functional components, which are
subject to coherent operational policies. subject to coherent operational policies.
As elaborated on below, every MSA is a candidate for signing using As elaborated on below, every MSA is a candidate for signing using
DKIM, and every MDA is a candidate for doing DKIM verification. DKIM, and every MDA is a candidate for doing DKIM verification.
A.1. Administrative Management Domain (ADMD) A.2. Trust Boundaries
Operation of Internet Mail services is apportioned to different Operation of Internet Mail services is apportioned to different
providers (or operators). Each can be composed of an independent providers (or operators). Each can be composed of an independent
ADministrative Management Domain (ADMD). An ADMD operates with an ADministrative Management Domain (ADMD). An ADMD operates with an
independent set of policies and interacts with other ADMDs according independent set of policies and interacts with other ADMDs according
to differing types and amounts of trust. Examples include: an end- to differing types and amounts of trust. Examples include: an end-
user operating their desktop client that connects to an independent user operating their desktop client that connects to an independent
email service, a department operating a submission agent or a local email service, a department operating a submission agent or a local
Relay, an organization's IT group that operates enterprise Relays, Relay, an organization's IT group that operates enterprise Relays,
and an ISP operating a public shared email service. and an ISP operating a public shared email service.
skipping to change at page 20, line 28 skipping to change at page 22, line 8
User: End-user services. These might be subsumed under an Edge User: End-user services. These might be subsumed under an Edge
service, such as is common for web-based email access. service, such as is common for web-based email access.
Transit: These are Mail Service Providers (MSP) offering value- Transit: These are Mail Service Providers (MSP) offering value-
added capabilities for Edge ADMDs, such as aggregation and added capabilities for Edge ADMDs, such as aggregation and
filtering. filtering.
Note that Transit services are quite different from packet-level Note that Transit services are quite different from packet-level
transit operation. Whereas end-to-end packet transfers usually go transit operation. Whereas end-to-end packet transfers usually go
through intermediate routers, email exchange across the open Internet through intermediate routers, email exchange across the open Internet
is often directly between the Edge ADMDs, at the email level. often is directly between the Edge ADMDs, at the email level.
+--------+ +--------+ +--------+
+--------+ +--------+ +--------+ | ADMD#1 | | ADMD#3 | | ADMD#4 |
| ADMD#1 | | ADMD#3 | | ADMD#4 | | ------ | | ------ | | ------ |
| ------ | | ------ | | ------ | | | +----------------------->| | | |
| | +----------------------->| | | | | User | | |--Edge--+--->|--User |
| User | | |--Edge--+--->|--User | | | | | +--->| | | |
| | | | +--->| | | | | V | | | +--------+ +--------+
| V | | | +--------+ +--------+ | Edge---+---+ |
| Edge---+---+ | | | | +----------+ |
| | | +----------+ | +--------+ | | ADMD#2 | |
+--------+ | | ADMD#2 | | | | ------ | |
| | ------ | | | | | |
| | | | +--->|-Transit--+---+
+--->|-Transit--+---+ | |
| | +----------+
+----------+
Figure 2: ADministrative Management Domains (ADMD) Example Figure 2: ADministrative Management Domains (ADMD) Example
In Figure 2, ADMD numbers 1 and 2 are candidates for doing DKIM In Figure 2, ADMD numbers 1 and 2 are candidates for doing DKIM
signing, and ADMD numbers 2, 3 and 4 are candidates for doing DKIM signing, and ADMD numbers 2, 3 and 4 are candidates for doing DKIM
verification. verification.
The distinction between Transit network and Edge network transfer The distinction between Transit network and Edge network transfer
services is primarily significant because it highlights the need for services is primarily significant because it highlights the need for
concern over interaction and protection between independent concern over interaction and protection between independent
skipping to change at page 21, line 34 skipping to change at page 23, line 13
turn, are used by one or more Relays and Users. It is not turn, are used by one or more Relays and Users. It is not
necessarily their job to perform email functions, but they necessarily their job to perform email functions, but they
can, instead, provide an environment in which those can, instead, provide an environment in which those
functions can be performed. functions can be performed.
Mail Service Providers: Mail Service Providers:
Operators of email services, such as for end-users, or Operators of email services, such as for end-users, or
mailing lists. mailing lists.
Index
A
ADMD 7
Administrative Management Domain 7
assessment 8
D
DKIM-Signature 13-14
DNS 6, 14-16
I
identifier 4-5, 8
identity 4-5, 8-10, 13-14
infrastructure 6-7, 9-10, 12, 18
M
Mail Delivery Agent 7
Mail Handling Service 7
Mail Service Provider 7
Mail Submission Agent 7
Mail Transfer Agent 7
Mail User Agent 7
MDA 7
MHS 7
MIME Object Security Services 6
MOSS 6
MSA 7
MSP 7
MTA 7
MUA 7
O
OpenPGP 6
P
PEM 6
PGP 6
Pretty Good Privacy 6
Privacy Enhanced Mail 6
S
S/MIME 6
T
trust 4, 8-9, 21
V
verification 5, 8-9, 11-12, 14, 17, 21-22
W
Web of Trust 6
X
X.509 6
Authors' Addresses Authors' Addresses
Tony Hansen Tony Hansen
AT&T Laboratories AT&T Laboratories
200 Laurel Ave. 200 Laurel Ave.
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Email: tony+dkimov@maillennium.att.com Email: tony+dkimov@maillennium.att.com
Dave Crocker Dave Crocker
Brandenburg InternetWorking Brandenburg InternetWorking
675 Spruce Dr. 675 Spruce Dr.
Sunnyvale, CA 94086 Sunnyvale, CA 94086
USA USA
Email: dcrocker@bbiw.net Email: dcrocker@bbiw.net
Phillip Hallam-Baker Phillip Hallam-Baker
VeriSign Inc. VeriSign Inc.
skipping to change at page 23, line 44 skipping to change at line 1120
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 92 change blocks. 
385 lines changed or deleted 520 lines changed or added

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