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