draft-ietf-dkim-overview-10.txt   draft-ietf-dkim-overview-11.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: January 12, 2009 Brandenburg InternetWorking Expires: October 22, 2009 Brandenburg InternetWorking
P. Hallam-Baker P. Hallam-Baker
VeriSign Inc. VeriSign Inc.
July 11, 2008 April 20, 2009
DomainKeys Identified Mail (DKIM) Service Overview DomainKeys Identified Mail (DKIM) Service Overview
draft-ietf-dkim-overview-10 draft-ietf-dkim-overview-11
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 January 12, 2009. This Internet-Draft will expire on October 22, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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 verified by a recipient. The organization can be the author's, the
originating sending site, an intermediary, or one of their agents. A originating sending site, an intermediary, or one of their agents. A
message can contain multiple signatures, from the same or different message can contain multiple signatures, from the same or different
organizations involved with the message. DKIM defines a domain-level organizations involved with the message. DKIM defines a domain-level
digital signature authentication framework for email, using public- digital signature authentication framework for email, using public-
key cryptography, using the domain name service as its key server key cryptography, with the domain name service as its key server
technology [RFC4871]. This permits verification of a responsible technology [RFC4871]. This permits verification of a responsible
organization, as well as the integrity of the message contents. DKIM organization, as well as the integrity of the message contents. DKIM
will also provide a mechanism that permits potential email signers to also enables a mechanism that permits potential email signers to
publish information about their email signing practices; this will publish information about their email signing practices; this will
permit email receivers to make additional assessments about messages. permit email receivers to make additional assessments about messages.
DKIM's authentication of email identity can assist in the global DKIM's authentication of email identity can assist in the global
control of "spam" and "phishing. control of "spam" and "phishing".
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. DKIM's Scope . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. DKIM's Scope . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Internet Mail Background . . . . . . . . . . . . . . . . . 7 1.3. Internet Mail Background . . . . . . . . . . . . . . . . . 7
1.4. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 7 1.4. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 7
2. The DKIM Value Proposition . . . . . . . . . . . . . . . . . . 8 2. The DKIM Value Proposition . . . . . . . . . . . . . . . . . . 8
2.1. Identity Verification . . . . . . . . . . . . . . . . . . 8 2.1. Identity Verification . . . . . . . . . . . . . . . . . . 8
2.2. Enabling Trust Assessments . . . . . . . . . . . . . . . . 8 2.2. Enabling Trust Assessments . . . . . . . . . . . . . . . . 9
2.3. Establishing Message Validity . . . . . . . . . . . . . . 9 2.3. Establishing Message Validity . . . . . . . . . . . . . . 9
3. DKIM Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. DKIM Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 10 3.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 10
3.2. Operational Goals . . . . . . . . . . . . . . . . . . . . 11 3.2. Operational Goals . . . . . . . . . . . . . . . . . . . . 11
4. DKIM Function . . . . . . . . . . . . . . . . . . . . . . . . 13 4. DKIM Function . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Basic Signing . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Basic Signing . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Characteristics of a DKIM Signature . . . . . . . . . . . 13 4.2. Characteristics of a DKIM Signature . . . . . . . . . . . 14
4.3. The Selector Construct . . . . . . . . . . . . . . . . . . 14 4.3. The Selector Construct . . . . . . . . . . . . . . . . . . 14
4.4. Verification . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Verification . . . . . . . . . . . . . . . . . . . . . . . 14
4.5. Sub-Domain Assessment . . . . . . . . . . . . . . . . . . 14 4.5. Sub-Domain Assessment . . . . . . . . . . . . . . . . . . 15
5. Service Architecture . . . . . . . . . . . . . . . . . . . . . 15 5. Service Architecture . . . . . . . . . . . . . . . . . . . . . 15
5.1. Administration and Maintenance . . . . . . . . . . . . . . 16 5.1. Administration and Maintenance . . . . . . . . . . . . . . 17
5.2. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4. Unverified or Unsigned Mail . . . . . . . . . . . . . . . 17 5.4. Unverified or Unsigned Mail . . . . . . . . . . . . . . . 18
5.5. Assessing . . . . . . . . . . . . . . . . . . . . . . . . 17 5.5. Assessing . . . . . . . . . . . . . . . . . . . . . . . . 18
5.6. DKIM Processing within an ADMD . . . . . . . . . . . . . . 18 5.6. DKIM Processing within an ADMD . . . . . . . . . . . . . . 19
6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Security Considerations . . . . . . . . . . . . . . . . . 18 6.1. Security Considerations . . . . . . . . . . . . . . . . . 19
6.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 18 6.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 19
6.3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 18 6.3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 19
7. Informative References . . . . . . . . . . . . . . . . . . . . 19 7. Informative References . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Internet Mail Background . . . . . . . . . . . . . . 20 Appendix A. Internet Mail Background . . . . . . . . . . 21
A.1. Core Model . . . . . . . . . . . . . . . . . . . . . . . . 20 A.1. Core Model . . . . . . . . . . . . . . . . . . . . . . . . 21
A.2. Trust Boundaries . . . . . . . . . . . . . . . . . . . . . 21 A.2. Trust Boundaries . . . . . . . . . . . . . . . . . . . . . 21
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
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 verified by a recipient. The organization can be a
handling the message directly, such as the author's, the originating direct handler of the message, such as the author's, the originating
sending site or an intermediary. It also can also be created by an sending site's or an intermediary's along the transit path. However
independent service that is providing assistance to a handler. DKIM it can also be and indirect handler, such as an independent service
defines a domain-level digital signature authentication framework for that is providing assistance to a direct handler. DKIM defines a
email through the use of public-key cryptography and using the domain domain-level digital signature authentication framework for email
name service as its key server technology. [RFC4871] It permits 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. DKIM's authentication additional assessments of unsigned messages. DKIM's authentication
of 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, viruses, 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
A person or organization has an "identity" -- that is, a A person or organization has an "identity" -- that is, a
constellation of characteristics that distinguish them from any other constellation of characteristics that distinguish them from any other
identity. Associated with this abstraction can be a label used as a identity. Associated with this abstraction can be a label used as a
reference, or "identifier". (This is the distinction between a thing reference, or "identifier". This is the distinction between a thing
and the name of the thing.) DKIM uses a domain name as an and the name of the thing. DKIM uses a domain name as an identifier,
identifier, to refer to the identity of a person or organization. to refer to the identity of a responsible person or organization. In
Note that the same identity can have multiple identifiers. DKIM, this identifier is called the Signing Domain IDentifier (SDID)
and is contained in the DKIM-Signature header fields "d=" tag. Note
that the same identity can have multiple identifiers.
A DKIM signature can be created by a direct handler of a message, A DKIM signature can be created by a direct handler of a message,
such as the message's author or an intermediary. A signature also such as the message's author or an intermediary. A signature also
can be created by an independent service that is providing assistance can be created by an independent service that is providing assistance
to a handler of the message. Whoever does the signing chooses the to a handler of the message. Whoever does the signing chooses the
domain name to be used as the basis for later assessments. Hence, SDID to be used as the basis for later assessments. Hence, the
the reputation associated with that domain name might be an reputation associated with that domain name might be an additional
additional basis for evaluating whether to trust the message for basis for evaluating whether to trust the message for delivery. The
delivery. The owner of the domain name being used for a DKIM owner of the SDID is declaring that they accept responsibility for
signature is declaring that they accept responsibility for the the message and can thus be held accountable for it.
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 can 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 has a narrow scope. It is an enabling technology, intended for DKIM has a narrow scope. It is an enabling technology, intended for
use in the larger context of determining message legitimacy. This use in the larger context of determining message legitimacy. This
larger context is complex, so it is easy to assume that a component larger context is complex, so it is easy to assume that a component
like DKIM, which actually provides only a limited service, instead like DKIM, which actually provides only a 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 authenticate or verify the contents of the message header
or body, such as the author From field, beyond certifying data
integrity between the time of signing and the time of verifying.
o Does not offer any assertions about the behaviors of the signer. o Does not offer any assertions about the behaviors of the signer.
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 -- that is, post it as a or a recipient can re-post the message -- that is, post it as a
new message -- with the original signature remaining verifiable, new message -- with the original signature remaining verifiable,
even though the new recipient(s) might be different from those who even though the new recipient(s) might be different from those who
were originally specified by the author. were originally specified by the author.
1.2. Prior Work 1.2. Prior Work
Historically, the IP Address of the system that directly sent the Historically, the IP Address of the system that directly sent the
message -- that is, the previous email "hop" -- has been treated as message -- that is, the previous email "hop" -- has been treated as
an identity to use for making assessments.[RFC4408], [RFC4406] and an identity to use for making assessments. For example, see
[RFC4407] The IP Address is obtained via underlying Internet [RFC4408], [RFC4406] and [RFC4407] for some current uses of the
information mechanisms and is therefore trusted to be accurate. sending system's IP address. The IP Address is obtained via
underlying Internet information mechanisms and is therefore trusted
Besides having some known security weaknesses, the use of addresses to be accurate. Besides having some known security weaknesses, the
presents a number of functional and operational problems. use of addresses presents a number of functional and operational
Consequently there is a widespread desire to use an identifier that problems. Consequently there is a widespread desire to use an
has better correspondence to organizational boundaries. Domain names identifier that has better correspondence to organizational
can satisfy this need. boundaries. Domain names can satisfy this need.
There have been four previous IETF Internet Mail signature standards. There have been four previous IETF Internet Mail signature standards.
Their goals have differed from those of DKIM. The first two are only Their goals have differed from those of DKIM. The first two are only
of historical interest. of historical interest.
Pretty Good Privacy (PGP) was developed by Phil Zimmermann and first o Pretty Good Privacy (PGP) was developed by Phil Zimmermann and
released in 1991. first released in 1991. A later version was standardized as
OpenPGP. [RFC2440] [RFC3156] [RFC4880]
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] [RFC1991] A later version was (MOSS) in 1995. [RFC1848] [RFC1991]
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. It was standardized as [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 only uses cryptographic 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 is differentiated by its reliance on an identifier that is
keys. It uses a key-centric public key management scheme, rather specific to DKIM use.
DKIM also has a distinctive approach for distributing and vouching
for 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) of Kohnfelder (X.509) [Kohnfelder] or Zimmermann (web of trust)
[WebofTrust]. For DKIM, the owner of a domain name asserts the [WebofTrust]. For DKIM, the owner of the SDID asserts the validity
validity of a key, rather than having the validity of the key of a key, rather than having the validity of the key attested to by a
attested to by a trusted third party, often including other trusted third party, often including other assertions, such as a
assertions, such as a quality assessment of the key's owner. DKIM quality assessment of the key's owner. DKIM treats quality
treats quality assessment as an independent, value-added service, assessment as an independent, value-added service, beyond the initial
beyond the initial work of deploying a signature verification work of deploying a signature verification service.
service.
Further, DKIM's key management is provided by adding information Further, DKIM's key management is provided by adding information
records to the existing Domain Name System (DNS) [RFC1034], rather records to the existing Domain Name System (DNS) [RFC1034], rather
than requiring deployment of a new query infrastructure. This than requiring deployment of a new query infrastructure. This
approach has significant operational advantages. First, it avoids approach has significant operational advantages. First, it avoids
the considerable barrier of creating a new global infrastructure; the considerable barrier of creating a new global infrastructure;
hence it leverages a global base of administrative experience and hence it leverages a global base of administrative experience and
highly reliable distributed operation. Second, the technical aspect highly reliable distributed operation. Second, the technical aspect
of the DNS is already known to be efficient. Any new service would of the DNS is already known to be efficient. Any new service would
have to undergo a period of gradual maturation, with potentially have to undergo a period of gradual maturation, with potentially
skipping to change at page 7, line 22 skipping to change at page 7, line 32
avoids these 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), Mediators, 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 1.4.1. Changes to document
skipping to change at page 8, line 35 skipping to change at page 8, line 41
message, if possible. message, if possible.
2. Evaluate the trustworthiness of this/these identities. 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 a
particular Internet domain names (identifiers). Attackers can particular Internet domain names (identifiers). Attackers can
leverage either using a legitimate domain name, without leverage either using a legitimate domain name, without
authorization, or using a "cousin" name that is similar to one that authorization, or a "cousin" name that is similar to one that is
is legitimate, but is not controlled by the target organization. An legitimate, but is not controlled by the target organization. An
assessment service that uses DKIM can differentiate between domains assessment service that uses DKIM can differentiate between a domain
used by known organizations and domains used by others. As such, (SDID) used by a known organization and a domain used by others. As
DKIM performs the positive step of identifying messages associated such, DKIM performs the positive step of identifying messages
with verifiable identities, rather than the negative step of associated with verifiable identities, rather than the negative step
identifying messages with problematic use of identities. Whether a of identifying messages with problematic use of identities. Whether
verified identity belongs to a Good Actor or a Bad Actor is a a verified identity belongs to a Good Actor or a Bad Actor is a
question for later stages 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: Whether to Email receiving services are faced with a basic decision: Whether to
deliver a newly-arrived message to the indicated recipient? That is, accept and deliver a newly-arrived message to the indicated
does the receiving service trust that the message is sufficiently recipient? That is, does the receiving service trust that the
"safe" to be viewed? For the modern Internet, most receiving message is sufficiently "safe" to be viewed? For the modern
services have an elaborate engine that formulates this quality Internet, most receiving services have an elaborate engine that
assessment. These engines take a variety of information as input to formulates this quality assessment. These engines take a variety of
the decision, such as from reputation lists and accreditation information as input to the decision, such as from reputation lists
services. As the engine processes information, it raises or lowers and accreditation services. As the engine processes information, it
its trust assessment for the message. raises or lowers its trust assessment for the message.
In order to formulate reputation information, an accurate, stable In order to formulate reputation information, an accurate, stable
identifier is needed. Otherwise, the information might not pertain identifier is needed. Otherwise, the information might not pertain
to the identified organization's own actions. When using an IP to the identified organization's own actions. When using an IP
Address, accuracy is based on the belief that the underlying Internet Address, accuracy is based on the belief that the underlying Internet
infrastructure supplies an accurate address. When using domain based infrastructure supplies an accurate address. When using domain based
reputation data, some other form of validation is needed, since it is reputation data, some other form of verification is needed, since it
not supplied independently by the infrastructure is not supplied independently by the infrastructure
DKIM satisfies this requirement by declaring a valid "responsible" DKIM satisfies this requirement by declaring a valid "responsible"
identity about which the engine can make quality assessments and by identity -- referenced through the SDID -- about which the engine can
using a digital signature to ensure that use of the identifier is make quality assessments and by using a digital signature to ensure
authorized. However by itself, a valid DKIM signature neither lowers that use of the identifier is authorized. However by itself, a valid
nor raises the level of trust associated with the message, but it DKIM signature neither lowers nor raises the level of trust
enables other mechanisms to be used for doing so. 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 2.3. Establishing Message Validity
Though man-in-the-middle attacks are historically rare in email, it Though man-in-the-middle attacks are historically rare in email, it
is nevertheless theoretically possible for a message to be modified is nevertheless theoretically possible for a message to be modified
during transit. An interesting side effect of the cryptographic during transit. An interesting side effect of the cryptographic
method used by DKIM is that it is possible to be certain that a 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) 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 has not been modified between the time of signing and the time of
message will not be verified successfully with DKIM. verifying. 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 As described above, this validity neither lowers nor raises the level
of trust associated with the message. If it was an untrustworthy of trust associated with the message. If it was an untrustworthy
message when initially sent, the verifier can be certain that the message when initially sent, the verifier can be certain that the
message will be equally untrustworthy upon receipt and successful message will be equally untrustworthy upon receipt and successful
verification. verification.
3. DKIM Goals 3. DKIM Goals
DKIM adds an end-to-end authentication capability to the existing DKIM adds an end-to-end authentication capability to the existing
email transfer infrastructure. It defines a mechanism that only email transfer infrastructure. That is, there can be multiple email
needs to be supported by the signer and the validator, rather than relaying hops between signing and verifying. Hence, it defines a
any of the functional components along the handling path. This mechanism that only needs to be supported by the signer and the
motivates functional goals about the authentication itself and verifier, rather than any of the functional components along the
operational goals about its integration with the rest of the Internet handling path. This motivates functional goals about the
email service. 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 provides accountability at the coarse granularity of an DKIM provides accountability at the coarse granularity of an
organization or, perhaps, a department. An existing construct that organization or, perhaps, a department. An existing construct that
enables this granularity is the Domain Name [RFC1034]. DKIM binds a enables this granularity is the Domain Name [RFC1034]. DKIM binds a
signing key record to the Domain Name. Further benefits of using signing key record to a Domain Name, as the SDID. Further benefits
domain names include simplifying key management, enabling signing by of using domain names include simplifying key management, enabling
the infrastructure as opposed to the MUA, and reducing privacy signing by the infrastructure as opposed to the MUA, and reducing
concerns. privacy concerns.
Contrast this with OpenPGP and S/MIME, which associate validation Contrast this with OpenPGP and S/MIME, which associate verification
with individual authors, using their using full email addresses. with individual authors, using their using full email 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 particular systems, such as the signing. Its use is not confined to particular systems, such as the
author's MUA or the inbound boundary MTA, and there can be more than author's MUA or the inbound boundary MTA, and there can be more than
one signature per message. one signature per message.
3.1.3. Allow delegation of signing to independent parties 3.1.3. Allow delegation of signing to independent parties
skipping to change at page 11, line 6 skipping to change at page 11, line 16
end users. Similarly, a reputation provider can delegate a signing 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 key for a domain under the control of the provider, to be used by an
organization the provider is prepared to vouch for. 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 assessment An authenticated identity can be subject to a variety of assessment
policies, either ad hoc or standardized. DKIM separates basic policies, either ad hoc or standardized. DKIM separates basic
authentication from assessment. The only semantics inherent to a authentication from assessment. The only semantics inherent to a
DKIM signature is that the signer is asserting (some) responsibility DKIM signature is that the signer is asserting some kind of
for the message. Hence, a DKIM signature only means that the signer responsibility for the message. Any interpretation of this kind of
is asserting (some) responsibility for the message, and nothing more. responsibility is the job of services building on DKIM, but the
Other services can build upon this core association, but their
details are beyond the scope of that core. One such mechanism might details are beyond the scope of that core. One such mechanism might
assert a relationship between the signing identity and the author, as assert a relationship between the SDID and the author, as specified
specified in the From: header field's domain identity.[RFC2822] in the From: header field's domain identity.[RFC5322] Another might
Another might specify how to treat an unsigned message with that specify how to treat an unsigned message with that From: field
From: field domain. 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
skipping to change at page 12, line 33 skipping to change at page 12, line 46
In effect the email receiver can use their set of known relationships In effect the email receiver can use their set of known relationships
to generate their own reputation data. This works particularly well to generate their own reputation data. This works particularly well
for traffic between large sending providers and large receiving for traffic between large sending providers and large receiving
providers. However it also works well for any operator, public or providers. However it also works well for any operator, public or
private, that has mail traffic dominated by exchanges among a stable private, that has mail traffic dominated by exchanges among a stable
set of organizations. set of organizations.
Management of email delivery 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 encourage senders (who might
signatures to senders who might subsequently complain that their subsequently complain that their email is not being delivered) to use
email is not being delivered. DKIM signatures.
3.2.4. Minimize the amount of required infrastructure 3.2.4. Minimize the amount of required infrastructure
In order to allow early adopters to gain early benefit, DKIM makes no In order to allow early adopters to gain early benefit, DKIM makes no
changes to the core Internet Mail service and, instead, can provide a changes to the core Internet Mail service and, instead, can provide a
useful benefit for any individual pair of signers and verifiers who useful benefit for any individual pair of signers and verifiers who
are exchanging mail. Similarly, DKIM's reliance on the Domain Name are exchanging mail. Similarly, DKIM's reliance on the Domain Name
System greatly reduces the amount of new administrative System greatly reduces the amount of new administrative
infrastructure that is needed across the open Internet. infrastructure that is needed across the open Internet.
skipping to change at page 13, line 13 skipping to change at page 13, line 29
example, employing DKIM at an outbound boundary MTA will mean that it example, employing DKIM at an outbound boundary MTA will mean that it
is administered by the organization's central IT department and that is administered by the organization's central IT department and that
internal messages are not signed. 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 associates verifiable information with a message, especially a It associates verifiable information with a message, especially a
responsible identity. When a message does not have a valid signature responsible identity. When a message does not have a valid signature
associated with the author, DKIM SP will permit the domain name of associated with the author, a DKIM SP will permit the domain name of
the author to be used for obtaining information about their signing the author to be used for obtaining information about their signing
practices. practices.
4.1. Basic Signing 4.1. Basic Signing
With the DKIM signature mechanism, a signer chooses a signing With the DKIM signature mechanism, a signer chooses a SDID, performs
identity based on their domain name, performs digital signing on the digital signing on the message, and adds the signature information
message, and adds the signature information using a DKIM header using a DKIM header field. A verifier obtains the domain name and
field. A verifier obtains the domain name and the "selector" from the "selector" from the DKIM header field, obtains the public key
the DKIM header field, obtains the public key associated with the associated with the name, and 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 as the SDID, 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 to signing DKIM permits restricting the use of a signature key to signing
messages for particular types of services, such as only for a single messages for particular types of services, such as only for a single
source of email. This is intended to be helpful when delegating source of email. This is intended to be helpful when delegating
signing authority, such as to a particular department or to a third- signing authority, such as to a particular department or to a third-
party outsourcing service. party outsourcing service.
skipping to change at page 13, line 50 skipping to change at page 14, line 17
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 applies to the message body and selected header A DKIM signature applies to the message body and selected header
fields. The signer computes a hash of the selected header fields and fields. The signer computes a hash of the selected header fields and
another 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 DKIM-Signature:, a parameters. Signature information is placed into DKIM-Signature:, a
new [RFC2822] message header field. new [RFC5322] message header field.
4.3. The Selector Construct 4.3. The Selector Construct
The key for a signature is associated with a domain name. That The key for a signature is associated with an SDID. That domain name
domain name provides the complete identity used for making provides the complete identity used for making assessments about the
assessments about the signer. (The DKIM specification does not give signer. (The DKIM specification does not give any guidance on how to
any guidance on how to do an assessment.) However this name is not do an assessment.) However this name is not sufficient for making a
sufficient for making a DNS query to obtain the key needed to verify DNS query to obtain the key needed to verify the signature.
the signature.
A single domain can use multiple signing keys and/or multiple A single SDID can have 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 using a combination of the domain name and an added signature as using a combination of the SDID and an added field,
field, called the "selector", specified in a separate DKIM-Signature: called the "selector", specified in a separate DKIM-Signature: header
header field parameter. 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 is to 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 an 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.
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 owner of the SDID
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 signed to by a party in possession of the private key for message was signed to by a party in possession of the private key for
the signing domain. Typically, verification will be done by an agent the SDID. Typically, verification will be done by an agent in the
in the Administrative Management Domain (ADMD) of the message Administrative Management Domain (ADMD) of the message recipient.
recipient.
4.5. Sub-Domain Assessment 4.5. Sub-Domain Assessment
Signers often need to support multiple assessments about their Signers often need to support multiple assessments about their
organization, such as to distinguish one type of message from organization, such as to distinguish one type of message from
another, or one portion of the organization from another. To permit another, or one portion of the organization from another. To permit
assessments that are independent, one method is for an organization assessments that are independent, one method is for an organization
to use different sub-domains in the "d=" parameter, such as to use different sub-domains as the SDID tag, such as
"transaction.example.com" versus "newsletter.example.com", or "transaction.example.com" versus "newsletter.example.com", or
"productA.example.com" versus "productB.example.com". These can be "productA.example.com" versus "productB.example.com". These can be
entirely separate from the rfc2822.From header field domain. entirely separate from the rfc5322.From header field domain.
5. Service Architecture 5. Service Architecture
DKIM uses external service components, such as for key retrieval and
DKIM use external service components, such as for key retrieval and
relaying email. This specification defines an initial set, using DNS relaying email. This specification defines an initial set, using DNS
and SMTP, for basic interoperability. and SMTP, for basic interoperability.
| |
|- RFC2822 Message |- RFC5322 Message
V V
+--------+ +--------------------------------+ +--------+ +--------------------------------+
| Private| | ORIGINATING OR RELAYING ADMD | | Private| | ORIGINATING OR RELAYING ADMD |
| Key +...>| Sign Message | | Key +...>| Sign Message with SDID |
| Store | +---------------+----------------+ | Store | +---------------+----------------+
+--------+ | +--------+ |
(paired) [Internet] (paired) [Internet]
+--------+ | +-----------+ +--------+ | +-----------+
| Public | +--------------------------------+ | Remote | | Public | +--------------------------------+ | Remote |
| Key | | RELAYING OR DELIVERING ADMD | | Sender | | Key | | RELAYING OR DELIVERING ADMD | | Sender |
| Store | | Message Signed? | | Practices | | Store | | Message Signed? | | Practices |
+----+---+ +-----+--------------------+-----+ +-----+-----+ +----+---+ +-----+--------------------+-----+ +-----+-----+
. |yes |no . . |yes |no .
. V | . . V | .
skipping to change at page 15, line 52 skipping to change at page 16, line 49
. | V . . | V .
+----+--------+ | +-----------+ +------+-----+ +----+--------+ | +-----------+ +------+-----+
|Reputation/ | | | Message | | Local Info | |Reputation/ | | | Message | | Local Info |
|Accreditation| +---------->| Filtering | | on Sender | |Accreditation| +---------->| Filtering | | on Sender |
|Info | | Engine | | Practices | |Info | | Engine | | Practices |
+-------------+ +-----------+ +------------+ +-------------+ +-----------+ +------------+
Figure 1: DKIM Service Architecture Figure 1: DKIM Service Architecture
As shown in Figure 1, basic message processing is divided between a As shown in Figure 1, basic message processing is divided between a
signing Administrative Management Domain (ADMD) and a validating signing Administrative Management Domain (ADMD) and a verifying ADMD.
ADMD. At its simplest, this is between the Originating ADMD and the At its simplest, this is between the Originating ADMD and the
delivering ADMD, but can involve other ADMDs in the handling path. delivering ADMD, but can involve other ADMDs in the handling path.
Signing: Signing is performed by an authorized module within the Signing: Signing is performed by an authorized module within the
signing ADMD and uses private information from the Key Store, as signing ADMD and uses private information from the Key Store, as
discussed below. Within the originating ADMD, this might be discussed below. Within the originating ADMD, this might be
performed by the MUA, MSA or an MTA. performed by the MUA, MSA or an MTA.
Validating: Validating is performed by an authorized module within verifying: verifying is performed by an authorized module within
the validating ADMD. Within a delivering ADMD, validating might the verifying ADMD. Within a delivering ADMD, verifying might be
be performed by an MTA, MDA or MUA. The module verifies the performed by an MTA, MDA or MUA. The module verifies the
signature or determines whether a particular signature was signature or determines whether a particular signature was
required. Verifying the signature uses public information from required. Verifying the signature uses public information from
the Key Store. If the signature passes, reputation information is the Key Store. If the signature passes, reputation information is
used to asses the signer and that information is passed to the used to assess the signer and that information is passed to the
message filtering system. If the signature fails or there is no message filtering system. If the signature fails or there is no
signature using the author's domain, information about signing signature using the author's domain, information about signing
practices related to the author can be retrieved remotely and/or practices related to the author can be retrieved remotely and/or
locally, and that information is passed to the message filtering locally, and that information is passed to the message filtering
system. system.
If message has more than one valid signature, the order in which the If message has more than one valid signature, the order in which the
signers are assessed and the interactions among the assessments are signers are assessed and the interactions among the assessments are
not defined by the DKIM specification. 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 verifier 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 verifier to obtain the public key. The signing organization
therefore needs to have a means of adding a key to the DNS, for therefore needs to have a means of adding a key to the DNS, for
every selector/domain-name combination. Further, the signing every selector/SDID 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, in order to determine appropriate delivery or display reputation, in order to determine appropriate delivery or display
options for that message. Quality-assessment information, which options for that message. Quality assessment information, which
is associated with a domain name, comes in many forms and from is associated with a domain name, comes in many forms and from
many sources. DKIM does not define assessment services. It's many sources. DKIM does not define assessment services. Its
relevance to them is to provide a validated domain name, upon relevance to them is to provide a verified domain name, upon which
which assessments can be made. 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
skipping to change at page 17, line 30 skipping to change at page 18, line 30
Engine's determination of message handling. As practices are Engine's determination of message handling. As practices are
defined, each domain name owner needs to consider what information defined, each domain name owner needs to consider what information
to publish. The nature and degree of checking practices, if any to publish. The nature and degree of checking practices, if any
is performed, is optional to the evaluating site and is strictly a is performed, is optional to the evaluating site and is strictly a
matter of local policy. 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 that is associated with the SDID.
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
Messages lacking a valid author signature (a signature associated Messages lacking a valid author signature (a signature associated
skipping to change at page 18, line 7 skipping to change at page 19, line 7
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 can accumulate its own that the verified identity produced by DKIM can accumulate its own
reputation, and will be added to the varied soup of rules used by the reputation, and will be added to the varied soup of rules used by the
engines. The rules can cover signed messages and can deal with engines. The rules can cover signed messages and can deal with
unsigned messages from a domain, if the domain has published unsigned messages from a domain, if the domain has published
information about its practices. information about its practices.
5.6. DKIM Processing 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's 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 is an MUA that receives a message and can re-post a A Mediator is an MUA that receives a message and can re-post a
modified version of it, such as to a mailing list. A DKIM signature modified version of it, such as to a mailing list. A DKIM signature
can survive some types of modifications through this process. can survive some types of modifications through this process.
Furthermore the Mediator can add its own signature. This can be Furthermore the Mediator can add its own signature. This can be
added by the Mediator software itself, or by any outbound component added by the Mediator software itself, or by any outbound component
in the Mediator's ADMD. in the Mediator's ADMD.
6. Considerations 6. Considerations
6.1. Security 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], with [RFC4686] as their basis.
6.2. IANA Considerations 6.2. IANA Considerations
There are no actions for IANA. There are no actions for IANA.
NOTE TO RFC EDITOR: This section is to be removed prior to NOTE TO RFC EDITOR: This section is to be removed prior to
publication. publication.
6.3. 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 effort 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.
7. Informative References 7. Informative References
[I-D.kucherawy-sender-auth-header]
Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status",
draft-kucherawy-sender-auth-header-15 (work in progress),
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",
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.
[RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
Exchange Formats", RFC 1991, August 1996. Exchange Formats", RFC 1991, August 1996.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998. "OpenPGP Message Format", RFC 2440, November 1998.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156, August 2001. "MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
August 2001.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004. RFC 3851, July 2004.
[RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", [RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
RFC 4406, April 2006. RFC 4406, April 2006.
[RFC4407] Lyon, J., "Purported Responsible Address in E-Mail [RFC4407] Lyon, J., "Purported Responsible Address in E-Mail
Messages", RFC 4407, April 2006. Messages", RFC 4407, April 2006.
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1", for Authorizing Use of Domains in E-Mail, Version 1",
RFC 4408, April 2006. RFC 4408, April 2006.
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, September 2006. Identified Mail (DKIM)", RFC 4686, September 2006.
[RFC4870] Delany, M., "Domain-Based Email Authentication Using
Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
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.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[WebofTrust] [WebofTrust]
Wikipedia, "Web of Trust", Wikipedia, "Web of Trust",
URL http://en.wikipedia.org/wiki/Web_of_trust, URL http://en.wikipedia.org/wiki/Web_of_trust,
<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 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
skipping to change at page 21, line 18 skipping to change at page 21, line 48
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.2. Trust Boundaries 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 a desktop client that connects to an independent email
email service, a department operating a submission agent or a local service, a department operating a submission agent or a local Relay,
Relay, an organization's IT group that operates enterprise Relays, an organization's IT group that operates enterprise Relays, and an
and an ISP operating a public shared email service. ISP operating a public shared email service.
Each of these can be configured into many combinations of Each of these can be configured into many combinations of
administrative and operational relationships, with each ADMD administrative and operational relationships, with each ADMD
potentially having a complex arrangement of functional components. potentially having a complex arrangement of functional components.
Figure 2 depicts the relationships among ADMDs. Perhaps the most Figure 2 depicts the relationships among ADMDs. Perhaps the most
salient aspect of an ADMD is the differential trust that determines salient aspect of an ADMD is the differential trust that determines
its policies for activities within the ADMD, versus those involving its policies for activities within the ADMD, versus those involving
interactions with other ADMDs. interactions with other ADMDs.
Basic types of ADMDs include: Basic types of ADMDs include:
skipping to change at page 22, line 25 skipping to change at page 22, line 46
| 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
administrations. The interactions between functional components administrations. The interactions between functional components
within a single ADMD are subject to the policies of that domain. within a single ADMD are subject to the policies of that domain.
skipping to change at page 23, line 18 skipping to change at page 23, line 41
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 Index
A A
ADMD 7 ADMD 7
Administrative Management Domain 7 Administrative Management Domain 7
assessment 8 assessment 9
D D
DKIM-Signature 13-14 DKIM-Signature 14
DNS 6, 14-16 DNS 7, 14, 16-17
I I
identifier 4-5, 8 identifier 5-6, 8
identity 4-5, 8-10, 13-14 identity 4-6, 8-9, 11, 13-14
infrastructure 6-7, 9-10, 12, 18 infrastructure 6-7, 9-10, 12-13, 19
M M
Mail Delivery Agent 7 Mail Delivery Agent 7
Mail Handling Service 7 Mail Handling Service 7
Mail Service Provider 7 Mail Service Provider 7
Mail Submission Agent 7 Mail Submission Agent 7
Mail Transfer Agent 7 Mail Transfer Agent 7
Mail User Agent 7 Mail User Agent 7
MDA 7 MDA 7
MHS 7 MHS 7
skipping to change at page 24, line 11 skipping to change at page 24, line 36
P P
PEM 6 PEM 6
PGP 6 PGP 6
Pretty Good Privacy 6 Pretty Good Privacy 6
Privacy Enhanced Mail 6 Privacy Enhanced Mail 6
S S
S/MIME 6 S/MIME 6
T T
trust 4, 8-9, 21 trust 4, 9, 21
V V
verification 5, 8-9, 11-12, 14, 17, 21-22 verification 5, 8-9, 12, 14, 18, 21-22
W W
Web of Trust 6 Web of Trust 6
X X
X.509 6 X.509 6
Authors' Addresses Authors' Addresses
Tony Hansen Tony Hansen
skipping to change at page 25, line 4 skipping to change at line 1089
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.
Email: pbaker@verisign.com Email: pbaker@verisign.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 80 change blocks. 
203 lines changed or deleted 213 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/