draft-ietf-dkim-overview-11.txt   draft-ietf-dkim-overview-12.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: October 22, 2009 Brandenburg InternetWorking Expires: November 30, 2009 Brandenburg InternetWorking
P. Hallam-Baker P. Hallam-Baker
VeriSign Inc. May 29, 2009
April 20, 2009
DomainKeys Identified Mail (DKIM) Service Overview DomainKeys Identified Mail (DKIM) Service Overview
draft-ietf-dkim-overview-11 draft-ietf-dkim-overview-12
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
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 October 22, 2009. This Internet-Draft will expire on November 30, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 15 skipping to change at page 3, line 15
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 . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . 9 2.2. Enabling Trust Assessments . . . . . . . . . . . . . . . . 9
2.3. Establishing Message Validity . . . . . . . . . . . . . . 9 2.3. Establishing Message Validity . . . . . . . . . . . . . . 10
3. DKIM Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . 15 4.5. Sub-Domain Assessment . . . . . . . . . . . . . . . . . . 15
5. Service Architecture . . . . . . . . . . . . . . . . . . . . . 15 5. Service Architecture . . . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 3, line 37 skipping to change at page 3, line 37
5.2. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 18 5.3. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4. Unverified or Unsigned Mail . . . . . . . . . . . . . . . 18 5.4. Unverified or Unsigned Mail . . . . . . . . . . . . . . . 18
5.5. Assessing . . . . . . . . . . . . . . . . . . . . . . . . 18 5.5. Assessing . . . . . . . . . . . . . . . . . . . . . . . . 18
5.6. DKIM Processing within an ADMD . . . . . . . . . . . . . . 19 5.6. DKIM Processing within an ADMD . . . . . . . . . . . . . . 19
6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Security Considerations . . . . . . . . . . . . . . . . . 19 6.1. Security Considerations . . . . . . . . . . . . . . . . . 19
6.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 19 6.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 19
6.3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 19 6.3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 19
7. Informative References . . . . . . . . . . . . . . . . . . . . 20 7. Informative References . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Internet Mail Background . . . . . . . . . . 21 Appendix A. Internet Mail Background . . . . . . . . . . . . . . 21
A.1. Core Model . . . . . . . . . . . . . . . . . . . . . . . . 21 A.1. Core Model . . . . . . . . . . . . . . . . . . . . . . . . 21
A.2. Trust Boundaries . . . . . . . . . . . . . . . . . . . . . 21 A.2. Trust Boundaries . . . . . . . . . . . . . . . . . . . . . 21
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
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), that is, the
core mechanism for signing and verifying messages. 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. Because the scope of this Overview is
basic email and network security technology and services. restricted to the technical details of signing and verifying using
DKIM, it does not explore operational issues, the details of services
that DKIM uses or that, in turn, use DKIM. Nor does it discuss
services that build upon DKIM for enforcement of policies or
assessments. The document assumes a background in 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 verified by a recipient. The organization can be a a way that can be verified by a recipient. The organization can be a
direct handler of the message, such as the author's, the originating direct handler of the message, such as the author's, the originating
sending site's or an intermediary's along the transit path. However sending site's or an intermediary's along the transit path. However
it can also be and indirect handler, such as an independent service it can also be and indirect handler, such as an independent service
that is providing assistance to a direct handler. DKIM defines a that is providing assistance to a direct handler. DKIM defines a
domain-level digital signature authentication framework for email domain-level digital signature authentication framework for email
through the use of public-key cryptography and using the domain name through the use of public-key cryptography and using the domain name
service as its key server technology. [RFC4871] It permits service as its key server technology. [RFC4871] It permits
skipping to change at page 6, line 20 skipping to change at page 6, line 24
[RFC4408], [RFC4406] and [RFC4407] for some current uses of the [RFC4408], [RFC4406] and [RFC4407] for some current uses of the
sending system's IP address. The IP Address is obtained via sending system's IP address. The IP Address is obtained via
underlying Internet information mechanisms and is therefore trusted underlying Internet information mechanisms and is therefore trusted
to be accurate. Besides having some known security weaknesses, the to be accurate. Besides having some known security weaknesses, the
use of addresses presents a number of functional and operational use of addresses presents a number of functional and operational
problems. Consequently there is a widespread desire to use an problems. Consequently there is a widespread desire to use an
identifier that has better correspondence to organizational identifier that has better correspondence to organizational
boundaries. Domain names 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. PEM and MOSS are only
of historical interest. of historical interest.
o Pretty Good Privacy (PGP) was developed by Phil Zimmermann and
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 Pretty Good Privacy (PGP) was developed by Phil Zimmermann and
first released in 1991. A later version was standardized as
OpenPGP. [RFC1991] [RFC2440] [RFC3156] [RFC4880]
o PEM eventually transformed into MIME Object Security Services o PEM eventually transformed into MIME Object Security Services
(MOSS) in 1995. [RFC1848] [RFC1991] (MOSS) in 1995. [RFC1848]
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
skipping to change at page 9, line 24 skipping to change at page 9, line 34
information as input to the decision, such as from reputation lists information as input to the decision, such as from reputation lists
and accreditation services. As the engine processes information, it and accreditation services. As the engine processes information, it
raises or lowers 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 verification is needed, since it reputation data, some other form of verification is needed, since it
is 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 -- referenced through the SDID -- about which the engine can identity -- referenced through the SDID -- about which the engine can
make quality assessments and by using a digital signature to ensure make quality assessments and by using a digital signature to ensure
that use of the identifier is authorized. However by itself, a valid that use of the identifier is authorized. However by itself, a valid
DKIM signature neither lowers nor raises the level of trust DKIM signature neither lowers nor raises the level of trust
associated with the message, but it enables other mechanisms to be associated with the message, but it enables other mechanisms to be
used for doing so. 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
skipping to change at page 10, line 33 skipping to change at page 10, line 46
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 a Domain Name, as the SDID. Further benefits signing key record to a Domain Name, as the SDID. Further benefits
of using domain names include simplifying key management, enabling of using domain names include simplifying key management, enabling
signing by the infrastructure as opposed to the MUA, and reducing signing by the infrastructure as opposed to the MUA, and reducing
privacy concerns. privacy concerns.
Contrast this with OpenPGP and S/MIME, which associate verification Contrast this with OpenPGP and S/MIME, which associate verification
with individual authors, using their using full email addresses. with individual authors, using their 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 16 skipping to change at page 11, line 28
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 kind of DKIM signature are that the signer is asserting some kind of
responsibility for the message. Any interpretation of this kind of responsibility for the message. Any interpretation of this kind of
responsibility is the job of services building on DKIM, but the responsibility is the job of services building on DKIM, but the
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 SDID and the author, as specified assert a relationship between the SDID and the author, as specified
in the From: header field's domain identity.[RFC5322] Another might in the rfc5322.From: header field's domain identity. Another might
specify how to treat an unsigned message with that From: field specify how to treat an unsigned message with that rfc5322.From:
domain. 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
skipping to change at page 16, line 33 skipping to change at page 16, line 33
. +-------------+ | . . +-------------+ | .
+.......>| Verify +--------+ | . +.......>| Verify +--------+ | .
| Signature | | | . | Signature | | | .
+------+------+ | | . +------+------+ | | .
pass| fail| | . pass| fail| | .
V | | . V | | .
+-------------+ | | . +-------------+ | | .
| | | | . | | | | .
+.......>| Assessments | | | . +.......>| Assessments | | | .
. | | V V . . | | V V .
. +------+------+ +-------+ . . +-----+--+----+ +-------+ .
. | / Check \<............+ . | | / Check \<............+
. +---------->/ Signing \ . | +-------->/ Signing \
. | / Practices \<..........+ . | / Practices \<..........+
. | +-------+-------+ . . | +-------+-------+ .
. | | . . | | .
. | 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 verifying ADMD. signing Administrative Management Domain (ADMD) and a verifying 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.
skipping to change at page 18, line 13 skipping to change at page 18, line 13
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 rfc5322.From: header
signed, or even whether the domain owner recommends discarding field is signed, or even whether the domain owner recommends
messages in the absence of an appropriate signature. The discarding messages in the absence of an appropriate signature.
statements of practice are made at the level of a domain name, and The statements of practice are made at the level of a domain name,
are distinct from assessments made about particular messages, as and are distinct from assessments made about particular messages,
occur in a Message Filtering Engine. Such assessments of as occur in a Message Filtering Engine. Such assessments of
practices can provide useful input for the Message Filtering practices can provide useful input for the Message Filtering
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
skipping to change at page 18, line 50 skipping to change at page 18, line 50
Messages lacking a valid author signature (a signature associated Messages lacking a valid author signature (a signature associated
with the author of the message as opposed to a signature associated with the author of the message as opposed to a signature associated
with an intermediary) can prompt a query for any published "signing with an intermediary) can prompt a query for any published "signing
practices" information, as an aid in determining whether the author practices" information, as an aid in determining whether the author
information has been used without authorization. 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. Local policy guidelines may cause
information is as input to a filtering engine that decides whether to signing practices to be checked or the message may be sent directly
deliver -- and possibly whether to specially mark -- a message. to the message filtering engine.
Filtering engines have become complex and sophisticated. Their A popular use of reputation information is as input to a filtering
details are outside of the scope of DKIM, other than the expectation engine that decides whether to deliver -- and possibly whether to
that the verified identity produced by DKIM can accumulate its own specially mark -- a message. Filtering engines have become complex
reputation, and will be added to the varied soup of rules used by the and sophisticated. Their details are outside of the scope of DKIM,
engines. The rules can cover signed messages and can deal with other than the expectation that the verified identity produced by
unsigned messages from a domain, if the domain has published DKIM can accumulate its own reputation, and will be added to the
information about its practices. varied soup of rules used by the engines. The rules can cover signed
messages and can deal with unsigned messages from a domain, if the
domain has published 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's 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.
skipping to change at page 21, line 29 skipping to change at page 21, line 29
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, makes changes appropriate to its service, and delivery of a message, makes changes appropriate to its service, and
then re-posts it for further distribution. Typically the new message then re-posts it for further distribution. Typically the new message
will retain the original From: header field. A mailing list is a will retain the original rfc5322.From: header field. A mailing list
common example of a Mediator. is a 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.
skipping to change at page 22, line 46 skipping to change at page 22, line 46
| V | | | +--------+ +--------+ | V | | | +--------+ +--------+
| Edge---+---+ | | Edge---+---+ |
| | | +----------+ | | | | +----------+ |
+--------+ | | ADMD#2 | | +--------+ | | ADMD#2 | |
| | ------ | | | | ------ | |
| | | | | | | |
+--->|-Transit--+---+ +--->|-Transit--+---+
| | | |
+----------+ +----------+
Figure 2: ADministrative Management Domains (ADMD) Figure 2: ADministrative Management Domains (ADMD) Example
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 45 skipping to change at page 23, line 44
Index Index
A A
ADMD 7 ADMD 7
Administrative Management Domain 7 Administrative Management Domain 7
assessment 9 assessment 9
D D
DKIM-Signature 14 DKIM-Signature 14
DNS 7, 14, 16-17 DNS 7, 14-17
I I
identifier 5-6, 8 identifier 5-6, 8
identity 4-6, 8-9, 11, 13-14 identity 4-6, 8-9, 11, 13-14
infrastructure 6-7, 9-10, 12-13, 19 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
skipping to change at page 24, line 36 skipping to change at page 24, line 35
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, 9, 21 trust 4, 9-10, 21
V V
verification 5, 8-9, 12, 14, 18, 21-22 verification 5, 8, 10, 12, 15, 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 24 skipping to change at page 25, line 24
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.
Email: pbaker@verisign.com Email: phillip@hallambaker.com
 End of changes. 31 change blocks. 
63 lines changed or deleted 59 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/