Network Working Group T. Hansen
Request for Comments: 5585 AT&T Laboratories
Category: Informational D. Crocker
Brandenburg InternetWorking
P. Hallam-Baker
Default Deny Security, Inc.
July 2009
Network Working Group T. Hansen
Request for Comments: 5585 AT&T Laboratories
Category: Informational D. Crocker
Brandenburg InternetWorking
P. Hallam-Baker
Default Deny Security, Inc.
July 2009
DomainKeys Identified Mail (DKIM) Service Overview
域密钥识别邮件（DKIM）服务概述
Abstract
摘要
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 verified 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, with the domain name service as its key server technology (RFC 4871). This permits verification of a responsible organization, as well as the integrity of the message contents. DKIM also enables 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".
本文档概述了DomainKeys Identified Mail（DKIM）服务，并描述了如何将其应用于消息传递服务。它还描述了DKIM与其他IETF消息签名技术的关系。它面向采用、开发或部署DKIM的用户。DKIM允许组织以收件人可以验证的方式负责传输消息。组织可以是作者、原始发送站点、中间人或其代理人之一。一封邮件可以包含来自与该邮件相关的相同或不同组织的多个签名。DKIM使用公钥加密技术为电子邮件定义了一个域级数字签名身份验证框架，并将域名服务作为其密钥服务器技术（RFC 4871）。这允许验证责任组织以及消息内容的完整性。DKIM还支持一种机制，允许潜在的电子邮件签名者发布有关其电子邮件签名实践的信息；这将允许电子邮件接收者对邮件进行额外的评估。DKIM的电子邮件身份验证可以帮助全球控制“垃圾邮件”和“网络钓鱼”。
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
1.1. DKIM's Scope ...............................................4
1.2. Prior Work .................................................5
1.3. Internet Mail Background ...................................6
2. The DKIM Value Proposition ......................................6
2.1. Identity Verification ......................................7
2.2. Enabling Trust Assessments .................................7
2.3. Establishing Message Validity ..............................8
3. DKIM Goals ......................................................8
3.1. Functional Goals ...........................................9
3.2. Operational Goals .........................................10
4. DKIM Function ..................................................12
4.1. Basic Signing .............................................12
4.2. Characteristics of a DKIM Signature .......................12
4.3. The Selector Construct ....................................13
4.4. Verification ..............................................13
4.5. Sub-Domain Assessment .....................................13
5. Service Architecture ...........................................14
5.1. Administration and Maintenance ............................15
5.2. Signing ...................................................16
5.3. Verifying .................................................16
5.4. Unverified or Unsigned Mail ...............................16
5.5. Assessing .................................................17
5.6. DKIM Processing within an ADMD ............................17
6. Considerations .................................................17
6.1. Security Considerations ...................................17
6.2. Acknowledgements ..........................................17
7. Informative References .........................................18
Appendix A. Internet Mail Background .............................20
A.1. Core Model ................................................20
A.2. Trust Boundaries ..........................................20
Index .............................................................22
1. Introduction ....................................................3
1.1. DKIM's Scope ...............................................4
1.2. Prior Work .................................................5
1.3. Internet Mail Background ...................................6
2. The DKIM Value Proposition ......................................6
2.1. Identity Verification ......................................7
2.2. Enabling Trust Assessments .................................7
2.3. Establishing Message Validity ..............................8
3. DKIM Goals ......................................................8
3.1. Functional Goals ...........................................9
3.2. Operational Goals .........................................10
4. DKIM Function ..................................................12
4.1. Basic Signing .............................................12
4.2. Characteristics of a DKIM Signature .......................12
4.3. The Selector Construct ....................................13
4.4. Verification ..............................................13
4.5. Sub-Domain Assessment .....................................13
5. Service Architecture ...........................................14
5.1. Administration and Maintenance ............................15
5.2. Signing ...................................................16
5.3. Verifying .................................................16
5.4. Unverified or Unsigned Mail ...............................16
5.5. Assessing .................................................17
5.6. DKIM Processing within an ADMD ............................17
6. Considerations .................................................17
6.1. Security Considerations ...................................17
6.2. Acknowledgements ..........................................17
7. Informative References .........................................18
Appendix A. Internet Mail Background .............................20
A.1. Core Model ................................................20
A.2. Trust Boundaries ..........................................20
Index .............................................................22
This document provides a description of the architecture and 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 also be helpful for those who are considering extending DKIM, either into other areas of use or to support additional features. This overview does not provide information on threats to DKIM or email or details on the protocol specifics, which can be found in [RFC4686] and [RFC4871], respectively. Because the scope of this overview is 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 those 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.
本文档描述了DomainKeys Identified Mail（DKIM）的体系结构和功能，DKIM是签名和验证消息的核心机制。它面向采用、开发或部署DKIM的用户。对于那些正在考虑将DKIM扩展到其他使用领域或支持其他功能的人来说，这也会有所帮助。本概述未提供对DKIM或电子邮件的威胁信息或协议细节的详细信息，可分别在[RFC4686]和[RFC4871]中找到。由于本概述的范围仅限于使用DKIM进行签名和验证的技术细节，因此本概述不探讨操作问题、DKIM使用的服务的细节或反过来使用DKIM的服务的细节。它也没有讨论基于DKIM的服务，以执行政策或评估。本文档假定具备基本电子邮件和网络安全技术及服务的背景。
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 direct handler of the message, such as the author's, the originating sending site's, or an intermediary's along the transit path. However, it can also be an indirect handler, such as an independent service that is providing assistance to a direct 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".
DKIM允许组织以收件人可以验证的方式对邮件负责。组织可以是消息的直接处理者，例如作者、原始发送站点或传输路径上的中间人。但是，它也可以是间接处理程序，例如向直接处理程序提供帮助的独立服务。DKIM通过使用公钥加密和使用域名服务作为其密钥服务器技术，为电子邮件定义了域级数字签名认证框架[RFC4871]。它允许验证消息的签名者及其内容的完整性。DKIM还将提供一种机制，允许潜在的电子邮件签名者发布有关其电子邮件签名实践的信息；这将允许电子邮件接收者对未签名邮件进行额外评估。DKIM的电子邮件身份验证可以帮助全球控制“垃圾邮件”和“网络钓鱼”。
Neither this document nor DKIM attempts to provide solutions to the world's problems with spam, phishing, viruses, worms, joe jobs, etc. DKIM provides one basic tool, in what needs to be a large arsenal, for improving basic trust in the Internet mail service. However, by itself, DKIM is not sufficient to that task and this overview does not pursue the issues of integrating DKIM into these larger efforts, beyond a simple reference within a system diagram. Rather, it is a basic introduction to the technology and its use.
本文档和DKIM均未试图为垃圾邮件、网络钓鱼、病毒、蠕虫、joe jobs等世界性问题提供解决方案。DKIM提供了一个基本工具，可以提高对互联网邮件服务的基本信任，这是一个庞大的武库。然而，DKIM本身并不足以完成这项任务，本概述没有探讨将DKIM集成到这些更大的工作中的问题，只是在系统图中提供了一个简单的参考。相反，它是对该技术及其使用的基本介绍。
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 responsible person or organization. In DKIM, this identifier is called the Signing Domain IDentifier (SDID) and is contained in the DKIM-Signature header fields "d=" tag. Note that the same identity can have multiple identifiers.
一个人或一个组织有一个“身份”——也就是说，区别于任何其他身份的一系列特征。与此抽象相关联的标签可以用作引用或“标识符”。这是事物和事物名称之间的区别。DKIM使用域名作为标识符，表示负责人或组织的身份。在DKIM中，该标识符称为签名域标识符（SDID），包含在DKIM签名头字段“d=”标记中。请注意，同一标识可以有多个标识符。
A DKIM signature can be created by a direct handler of a message, such as the message's author or by 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 SDID 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 SDID is declaring that they accept responsibility for the message and can thus be held accountable for it.
DKIM签名可以由消息的直接处理程序（如消息的作者）或中介创建。签名也可以由向消息处理程序提供帮助的独立服务创建。签字人选择SDID作为以后评估的基础。因此，与该域名相关联的信誉可能是评估是否信任该消息进行传递的另一个基础。SDID的所有者声明他们接受该消息的责任，因此可以对此负责。
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 stricter handling of messages that are not signed. However, early benefits do not require this and probably do not warrant this.
DKIM旨在作为电子邮件的增值功能。未经DKIM签名的邮件的处理方式与定义DKIM之前相同。消息将通过已建立的分析和过滤技术进行评估。（签名策略可以为分析和过滤提供额外信息。）随着时间的推移，DKIM的广泛采用可能会允许对未签名的消息进行更严格的处理。然而，早期福利并不需要这一点，也可能不保证这一点。
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.
DKIM的范围很窄。它是一种使能技术，旨在用于确定消息合法性的更大背景下。这个更大的上下文是复杂的，因此很容易假设像DKIM这样的组件实际上只提供有限的服务，而满足更广泛的需求集。
By itself, a DKIM signature:
DKIM签名本身：
o Does not authenticate or verify the contents of the message header or body, such as the author From field, beyond certifying data integrity between the time of signing and the time of verifying.
o 除了在签名和验证时间之间验证数据完整性之外，不验证或验证消息头或消息体的内容，例如来自字段的作者。
o Does not offer any assertions about the behaviors of the signer.
o 不提供关于签名者行为的任何断言。
o Does not prescribe any specific actions for receivers to take upon successful signature verification.
o 未规定接收人在签名验证成功后应采取的任何具体行动。
o Does not provide protection after signature verification.
o 签名验证后不提供保护。
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.
o 不防止重新发送（重播）已验证签名的邮件；因此，中转中间人或收件人可以重新发布消息（即作为新消息发布），原始签名保持可验证，即使新收件人可能不同于作者最初指定的收件人。
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. For example, see [RFC4408], [RFC4406], and [RFC4407] for some current uses of the sending system's IP Address. 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 can satisfy this need.
历史上，直接发送消息的系统的IP地址（即前一封电子邮件“hop”）被视为进行评估时使用的身份。例如，请参阅[RFC4408]、[RFC4406]和[RFC4407]了解发送系统IP地址的一些当前用途。IP地址是通过底层的互联网信息机制获得的，因此被认为是准确的。除了存在一些已知的安全弱点外，地址的使用还存在一些功能和操作问题。因此，人们普遍希望使用与组织边界更好对应的标识符。域名可以满足这一需求。
There have been four previous IETF Internet Mail signature standards. Their goals have differed from those of DKIM. PEM and MOSS are only of historical interest.
此前已有四个IETF互联网邮件签名标准。他们的目标与DKIM不同。佩姆和莫斯只具有历史意义。
o Privacy Enhanced Mail (PEM) was first published in 1987 [RFC0989].
o 隐私增强邮件（PEM）于1987年首次发布[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 Pretty Good Privacy（PGP）由Phil Zimmermann开发，于1991年首次发布。更高版本被标准化为OpenPGP[RFC1991][RFC2440][RFC3156][RFC4880]。
o PEM eventually transformed into MIME Object Security Services (MOSS) in 1995 [RFC1848].
o PEM最终于1995年转变为MIME对象安全服务（MOSS）[RFC1848]。
o RSA Security independently developed Secure MIME (S/MIME) to transport a Public Key Cryptographic System (PKCS) #7 data object. It was standardized as [RFC3851].
o RSA Security独立开发了安全MIME（S/MIME），用于传输公钥密码系统（PKCS）#7数据对象。标准化为[RFC3851]。
Development of both S/MIME and OpenPGP has continued. While each has achieved a significant user base, neither one has achieved ubiquity in deployment or use.
S/MIME和OpenPGP的开发仍在继续。虽然每一个都实现了重要的用户基础，但都没有实现部署或使用的普遍性。
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 repurposing any of those would be more problematic than creating
在某种程度上，其他消息签名服务可能已经进行了调整，以完成DKIM设计要执行的任务，人们认为，重新调整这些服务的用途将比创建新服务更成问题
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.
单独的服务。也就是说，DKIM只使用历史悠久的加密组件，包括在其他一些消息传递安全服务中使用。
DKIM is differentiated by its reliance on an identifier that is specific to DKIM use.
DKIM的区别在于它依赖于特定于DKIM使用的标识符。
DKIM also has a distinctive approach for distributing and vouching for keys. It uses a key-centric, public-key management scheme, rather than the more typical approaches based on a certificate in the styles of Kohnfelder (X.509) [Kohnfelder] or Zimmermann (web of trust) [WebofTrust]. For DKIM, the owner of the SDID 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.
DKIM还有一种独特的方法来分发和担保密钥。它使用以密钥为中心的公钥管理方案，而不是基于Kohnfeld（X.509）[Kohnfeld]或Zimmermann（web of trust）[WebofTrust]样式的证书的更典型的方法。对于DKIM，SDID的所有者断言密钥的有效性，而不是由可信的第三方证明密钥的有效性，通常包括其他断言，例如密钥所有者的质量评估。DKIM将质量评估视为一项独立的增值服务，而不仅仅是部署签名验证服务的初始工作。
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.
此外，DKIM的密钥管理是通过向现有域名系统（DNS）[RFC1034]添加信息记录来实现的，而不需要部署新的查询基础设施。这种方法具有显著的操作优势。首先，它避免了建立新的全球基础设施的巨大障碍；因此，它利用了管理经验和高度可靠的分布式操作的全球基础。其次，DNS的技术方面已经被认为是高效的。任何新服务都必须经历一段逐渐成熟的时期，早期行为可能存在问题。通过（重新）使用DNS，DKIM避免了这些成长的烦恼。
The basic Internet email service has evolved extensively over its several decades of continuous operation. Its modern architecture comprises a number of specialized components. A discussion about Mail User Agents (MUAs), Mail Handling Services (MHSs), Mail Transfer Agents (MTAs), Mail Submission Agents (MSAs), Mail Delivery Agents (MDAs), Mail Service Providers (MSPs), Administrative Management Domains (ADMDs), Mediators, and their relationships can be found in Appendix A.
基本的互联网电子邮件服务在其几十年的持续运营中得到了广泛的发展。它的现代建筑由许多专业组件组成。有关邮件用户代理（MUA）、邮件处理服务（MHS）、邮件传输代理（MTA）、邮件提交代理（MSA）、邮件传递代理（MDA）、邮件服务提供商（MSP）、管理管理域（ADMD）、中介及其关系的讨论，请参见附录A。
The nature and origins of a message often are falsely stated. Such misrepresentations may be employed for legitimate or nefarious reasons. DKIM provides a foundation for distinguishing legitimate mail, and thus a means of associating a verifiable identifier with a
信息的性质和来源经常被错误地陈述。此类虚假陈述可能出于合法或邪恶的原因。DKIM为区分合法邮件提供了基础，因此将可验证标识符与
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.
消息给定该标识符的存在，接收机可以基于对与该标识符相关联的标识的评估来作出关于进一步处理该消息的决定。
Receivers who successfully verify a signature can use information about the signer as part of a program to limit spam, spoofing, phishing, or other undesirable behaviors. DKIM does not, itself, prescribe any specific actions by the recipient; rather, it is an enabling technology for services that do.
成功验证签名的接收者可以将签名者的信息用作程序的一部分，以限制垃圾邮件、欺骗、网络钓鱼或其他不良行为。DKIM本身没有规定接收方的任何具体行动；相反，它是一种支持服务的技术。
These services will typically:
这些服务通常将：
1. Determine a verified identity as taking responsibility for the message, if possible.
1. 如有可能，确定一个已验证的身份对该消息负责。
2. Evaluate the trustworthiness of this/these identities.
2. 评估此/这些身份的可信度。
The role of DKIM is to perform the first of these; DKIM is an enabler for the second.
DKIM的角色是执行其中的第一项；DKIM是第二个的启用码。
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 using either a legitimate domain name, one without authorization, or 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 a domain (SDID) used by a known organization and a domain 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.
考虑对组织或针对组织的顾客进行的攻击。组织名称链接到特定的Internet域名（标识符）。攻击者可以使用合法域名（未经授权）或与合法域名类似但不受目标组织控制的“表亲”名称进行攻击。使用DKIM的评估服务可以区分已知组织使用的域（SDID）和其他组织使用的域。因此，DKIM执行识别与可验证身份相关联的消息的积极步骤，而不是识别身份使用有问题的消息的消极步骤。验证的身份是属于一个好的行为人还是一个坏的行为人是评估的后续阶段的问题。
Email receiving services are faced with a basic decision: whether to accept and 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.
电子邮件接收服务面临一个基本决策：是否接受新到达的邮件并将其发送给指定的收件人？也就是说，接收服务是否信任消息足够“安全”以供查看？对于现代互联网来说，大多数接收服务都有一个精心设计的引擎来制定这种质量评估。这些引擎将各种信息作为决策的输入，例如来自声誉列表和认证服务的信息。当引擎处理信息时，它会提高或降低对消息的信任评估。
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 verification is needed, since it is not supplied independently by the infrastructure.
为了形成信誉信息，需要一个准确、稳定的标识符。否则，信息可能与已确定的组织自身的行动无关。当使用IP地址时，准确度基于以下信念：基础Internet基础设施提供准确的地址。当使用基于域的信誉数据时，需要某种其他形式的验证，因为它不是由基础设施独立提供的。
DKIM satisfies this requirement by declaring a valid "responsible" identity -- referenced through the SDID -- 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.
DKIM通过声明一个有效的“负责”标识（通过SDID引用）来满足这一要求，引擎可以对该标识进行质量评估，并通过使用数字签名来确保该标识的使用得到授权。然而，有效的DKIM签名本身既不会降低也不会提高与消息相关联的信任级别，但它允许使用其他机制来实现这一点。
An organization might build upon its use of DKIM by publishing information about its Signing Practices (SP). This could permit detecting some messages that purport to be associated with a domain, but which are not. As such, an SP can cause the trust assessment to be reduced, or leave it unchanged.
组织可以通过发布有关其签名实践（SP）的信息来利用DKIM。这可能允许检测一些声称与域关联但不与域关联的消息。因此，SP可能会导致信任评估减少或保持不变。
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 between the time of signing and the time of verifying. If it has been changed in any way, then the message will not be verified successfully with DKIM.
虽然中间人攻击在电子邮件中历来罕见，但从理论上讲，在传输过程中修改邮件是可能的。DKIM使用的加密方法的一个有趣的副作用是，可以确定签名消息（或者，如果使用l=则消息的签名部分）在签名时间和验证时间之间没有被修改。如果以任何方式更改了该消息，则无法使用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.
如上所述，此有效性既不会降低也不会提高与消息相关联的信任级别。如果最初发送时是不可信的消息，那么验证者可以确定，在收到消息并成功验证后，消息同样不可信。
DKIM adds an end-to-end authentication capability to the existing email transfer infrastructure. That is, there can be multiple email relaying hops between signing and verifying. Hence, it defines a mechanism that only needs to be supported by the signer and the
DKIM将端到端身份验证功能添加到现有的电子邮件传输基础架构中。也就是说，在签名和验证之间可以有多个电子邮件中继跃点。因此，它定义了一种只需要签名者和
verifier, 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.
验证器，而不是处理路径上的任何功能组件。这激发了有关身份验证本身的功能目标以及有关其与Internet电子邮件服务其余部分集成的操作目标。
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 a Domain Name as the SDID. Further benefits of using domain names include simplifying key management, enabling signing by the infrastructure as opposed to the MUA, and reducing privacy concerns.
DKIM在组织或部门的粗粒度上提供责任。启用此粒度的现有构造是域名[RFC1034]。DKIM将签名密钥记录绑定到域名作为SDID。使用域名的其他好处包括简化密钥管理、支持基础设施（而不是MUA）签名以及减少隐私问题。
Contrast this with OpenPGP and S/MIME, which associate verification with individual authors, using their full email addresses.
与之相比，OpenPGP和S/MIME使用完整的电子邮件地址将验证与个人作者联系起来。
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.
任何一方，在运输路径上的任何地方，都可以实施DKIM签名。它的使用并不局限于特定的系统，例如作者的MUA或入站边界MTA，并且每条消息可以有多个签名。
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 for which the provider is prepared to vouch.
在电子邮件交换过程中，不同的当事人扮演着不同的角色。有些是终端用户容易看到的，而另一些则主要是服务运营商可以看到的。DKIM旨在支持这些不同方的签名，并允许他们使用他们认为合适的任何域名（并且他们持有授权的签名密钥）进行签名。例如，创建电子邮件内容的组织通常将其处理或传输的一部分委托给外包团队。DKIM以最终用户通常看不到的方式支持这种活动模式。类似地，信誉提供者可以为提供者控制的域委派签名密钥，供提供者准备为其提供担保的组织使用。
3.1.4. Distinguish the Core Authentication Mechanism from Its Derivative Uses
3.1.4. 区分核心身份验证机制及其派生用途
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将基本身份验证与评估分离。语言所固有的唯一语义
DKIM signature are that the signer is asserting some kind of responsibility for the message. Any interpretation of this kind of responsibility is the job of services building on DKIM, but the details are beyond the scope of that core. One such mechanism might assert a relationship between the SDID and the author, as specified in the rfc5322.From: header field's domain identity. Another might specify how to treat an unsigned message with that rfc5322.From: field domain.
DKIM签名是指签名者声明对消息负有某种责任。对这种责任的任何解释都是建立在DKIM上的服务的工作，但细节超出了核心的范围。一种这样的机制可以断言SDID和作者之间的关系，如rfc5322.From:header字段的域标识中所指定的。另一个可能指定如何使用rfc5322.From:字段域处理未签名消息。
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 needs to be retained. DKIM is compatible with this goal since it permits authentication of the email system operator, rather than the content author. If it is possible to obtain effectively anonymous accounts at example.com, knowing that a message definitely came from example.com does not threaten the anonymity of the user who authored it.
发送不确定作者的邮件的能力被认为是当前电子邮件服务的一个有价值的质量，需要保留。DKIM与此目标兼容，因为它允许对电子邮件系统操作员而不是内容作者进行身份验证。如果可以在example.com上获得有效的匿名帐户，那么知道消息肯定来自example.com不会威胁到编写该消息的用户的匿名性。
3.2.1. Make Presence of Signature Transparent to Non-Supporting Recipients
3.2.1. 使签名对非支持收件人透明
In order to facilitate incremental adoption, DKIM is designed to be transparent to recipients that do not support it. A DKIM signature does not "get in the way" for such recipients.
为了促进增量采用，DKIM被设计为对不支持它的接收者透明。DKIM签名不会“妨碍”此类收件人。
Contrast this with S/MIME and OpenPGP, which modify the message body. Hence, their presence is potentially visible to email recipients, whose user software needs to process the associated constructs.
与之相比，S/MIME和OpenPGP修改了消息体。因此，电子邮件收件人可能会看到它们的存在，他们的用户软件需要处理相关的结构。
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.
DKIM还必须对现有评估机制透明。因此，DKIM签名验证器会将签名失败的消息视为未签名的消息。因此，消息将通过接收方现有的过滤机制恢复到正常处理。因此，DKIM规定，评估站点不会接收签名已损坏的消息，并且不会以与签名不存在时不同的方式对待该消息。
Contrast this with OpenPGP and S/MIME, which were designed for strong cryptographic protection. This included treating verification failure as message failure.
这与OpenPGP和S/MIME形成对比，后者是为强大的加密保护而设计的。这包括将验证失败视为消息失败。
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. 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.
DKIM可由任何两个交换电子邮件和实施DKIM的组织使用；它不需要在开放互联网的电子邮件基础设施中采用。按照通常的“网络效应”方式，DKIM的好处随着采用率的增加而增加。虽然这一机制可以与独立评估服务结合使用，但这些服务对于获得初步利益来说并不是必不可少的。例如，DKIM允许（可能很大）成对的电子邮件提供商和垃圾邮件过滤公司区分与已知组织相关的邮件，而不是可能虚假地声称与该组织有关联的邮件。这反过来又允许开发“白名单”方案，从而允许来自已知来源且信誉良好的经过身份验证的邮件绕过一些反滥用过滤器。
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.
实际上，电子邮件接收者可以使用他们的一组已知关系来生成他们自己的声誉数据。这对于大型发送提供商和大型接收提供商之间的通信尤其有效。然而，它也适用于任何运营商，无论是公共还是私人，其邮件流量主要由一组稳定的组织之间的交换所控制。
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 encourage senders (who might subsequently complain that their email is not being delivered) to use DKIM signatures.
电子邮件传递问题的管理目前是电子邮件管理员在邮件传输路径上的每个点上的一个重要痛点。部署了DKIM验证的管理员会鼓励发件人（他们可能随后会抱怨他们的电子邮件未送达）使用DKIM签名。
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.
为了让早期采用者获得早期利益，DKIM不对核心Internet邮件服务进行任何更改，而是可以为交换邮件的任何一对签名者和验证者提供有用的利益。类似地，DKIM对域名系统的依赖大大减少了整个开放互联网所需的新管理基础设施的数量。
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.
DKIM可以部署在组织电子邮件服务中的多个位置。这为谁管理其使用以及哪些流量携带DKIM签名提供了灵活性。例如，在出站边界MTA使用DKIM将意味着该MTA由组织的中央it部门管理，并且内部消息未签名。
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, a DKIM SP will permit the domain name of the author to be used for obtaining information about their signing practices.
DKIM的功能非常有限，主要针对从作者传输到收件人的电子邮件。它将可验证信息与消息相关联，尤其是负责的身份。当邮件没有与作者关联的有效签名时，DKIM SP将允许使用作者的域名来获取有关其签名实践的信息。
With the DKIM signature mechanism, a signer chooses an SDID, 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.
通过DKIM签名机制，签名者选择SDID，对消息执行数字签名，并使用DKIM头字段添加签名信息。验证器从DKIM头字段获取域名和“选择器”，获取与该名称关联的公钥，并验证签名。
DKIM permits any domain name to be used as the SDID, and supports extensible choices for various algorithms. As is typical for Internet standards, there is a core set of algorithms that all implementations are required to support, in order to guarantee basic interoperability.
DKIM允许任何域名用作SDID，并支持各种算法的可扩展选择。与互联网标准一样，为了保证基本的互操作性，所有实现都需要支持一组核心算法。
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.
DKIM允许将签名密钥的使用限制为对特定类型服务的消息进行签名，例如仅对单个电子邮件源进行签名。这有助于将签署权限委托给特定部门或第三方外包服务。
With DKIM, the signer explicitly lists the headers that are signed, such as From:, Date:, and Subject:. By choosing the minimal set of headers needed, the signature is likely to be considerably more robust against the handling vagaries of intermediary MTAs.
使用DKIM，签名者会显式列出已签名的标头，例如From:、Date:、Subject:。通过选择所需的最小标头集，签名可能会对中间MTA的异常处理更加健壮。
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 [RFC5322] message header field.
DKIM签名应用于消息正文和选定的标头字段。签名者计算所选标题字段的散列和正文的另一个散列。然后，签名者使用私钥对该信息以及其他签名参数进行加密编码。签名信息放入DKIM签名：，这是一个新的[RFC5322]消息头字段。
The key for a signature is associated with an SDID. 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.
签名的密钥与SDID相关联。该域名提供了用于评估签名者的完整身份。（DKIM规范没有对如何进行评估提供任何指导。）但是，此名称不足以进行DNS查询以获取验证签名所需的密钥。
A single SDID can have multiple signing keys and/or multiple potential signers. To support this, DKIM identifies a particular signature as using a combination of the SDID and an added field, called the "selector", specified in a separate DKIM-Signature: header field parameter.
单个SDID可以有多个签名密钥和/或多个潜在签名者。为了支持这一点，DKIM使用SDID和附加字段（称为“选择器”）的组合标识特定签名，该字段在单独的DKIM signature:header字段参数中指定。
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.
注意：选择器（如果有）的语义严格保留给签名者，其他各方将其视为不透明字符串。如果验证者使用选择器作为评估机制的一部分，那么就不会有剩余的机制来从旧的或被破坏的密钥过渡到新的密钥。
After a message has been signed, any agent in the message transit path can verify the signature to determine that the owner of the SDID 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 by a party in possession of the private key for the SDID. Typically, verification will be done by an agent in the Administrative Management Domain (ADMD) of the message recipient.
消息签名后，消息传输路径中的任何代理都可以验证签名，以确定SDID的所有者对消息负责。消息接收方可以通过直接查询签名者域的DNS来验证签名，以检索适当的公钥，从而确认消息是由拥有SDID私钥的一方签名的。通常，验证将由邮件收件人的管理管理域（ADMD）中的代理完成。
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 as the SDID tag, such as "transaction.example.com" versus "newsletter.example.com", or "productA.example.com" versus "productB.example.com". These can be entirely separate from the rfc5322.From header field domain.
签名者通常需要支持对其组织的多种评估，例如区分一种类型的消息和另一种类型的消息，或者区分组织的一部分和另一部分。为了允许独立的评估，一种方法是组织使用不同的子域作为SDID标记，例如“transaction.example.com”与“newsletter.example.com”或“productA.example.com”与“productB.example.com”。这些字段可以完全独立于rfc5322.from标头字段域。
DKIM uses external service components, such as for key retrieval and
relaying email. This specification defines an initial set, using DNS
and SMTP, for basic interoperability.
|
|- RFC5322 Message
V
+--------+ +--------------------------------+
| Private| | ORIGINATING OR RELAYING ADMD |
| Key +...>| Sign Message with SDID |
| 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 |
+-------------+ +-----------+ +------------+
DKIM uses external service components, such as for key retrieval and
relaying email. This specification defines an initial set, using DNS
and SMTP, for basic interoperability.
|
|- RFC5322 Message
V
+--------+ +--------------------------------+
| Private| | ORIGINATING OR RELAYING ADMD |
| Key +...>| Sign Message with SDID |
| 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 |
+-------------+ +-----------+ +------------+
Figure 1: DKIM Service Architecture
图1:DKIM服务架构
As shown in Figure 1, basic message processing is divided between a signing Administrative Management Domain (ADMD) and a verifying ADMD. At its simplest, this is between the originating ADMD and the delivering ADMD, but can involve other ADMDs in the handling path.
如图1所示，基本消息处理分为签名管理域（ADMD）和验证ADMD。最简单的情况是，这介于发起ADMD和传递ADMD之间，但可能会在处理路径中涉及其他ADMD。
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.
签名：签名由签名ADMD中的授权模块执行，并使用密钥存储中的私有信息，如下所述。在原始ADMD中，这可能由MUA、MSA或MTA执行。
verifying: verifying is performed by an authorized module within the verifying ADMD. Within a delivering ADMD, verifying 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 assess 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.
验证：验证由验证ADMD中的授权模块执行。在交付ADMD中，验证可能由MTA、MDA或MUA执行。该模块验证签名或确定是否需要特定签名。验证签名使用密钥存储中的公共信息。如果签名通过，信誉信息将用于评估签名者，并将该信息传递给消息过滤系统。如果签名失败或没有使用作者域的签名，则可以远程和/或本地检索与作者相关的签名实践信息，并将该信息传递给消息过滤系统。
If a 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.
如果消息具有多个有效签名，则DKIM规范不会定义签名者的评估顺序以及评估之间的交互。
A number of tables and services are used to provide external information. Each of these introduces administration and maintenance requirements.
许多表和服务用于提供外部信息。每一项都介绍了管理和维护要求。
Key Store: DKIM uses public-/private-key (asymmetric) cryptography. The signer users a private key and the verifier uses the corresponding public key. The current DKIM Signing specification provides for querying the Domain Names Service (DNS), to permit a verifier to obtain the public key. The signing organization therefore needs to have a means of adding a key to the DNS, for every selector/SDID combination. Further, the signing organization needs policies for distributing and revising keys.
密钥存储：DKIM使用公钥/私钥（非对称）加密。签名者使用私钥，验证者使用相应的公钥。当前的DKIM签名规范规定查询域名服务（DNS），以允许验证器获取公钥。因此，对于每个选择器/SDID组合，签名组织需要有一种向DNS添加密钥的方法。此外，签名组织需要分发和修改密钥的策略。
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. Its relevance to them is to provide a verified domain name, upon which assessments can be made.
与域名关联，有多种形式，来源多种。DKIM没有定义评估服务。其相关性在于提供一个经过验证的域名，并据此进行评估。
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 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 rfc5322.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 are performed, is optional to the evaluating site and is strictly a matter of local policy.
签名实践（SP）：除了确定签名的有效性，以及评估与签名身份相关的组织的声誉之外，还有机会确定与域名相关的任何组织实践。实践范围很广。它们可以由域的所有者发布，也可以由评估站点维护。它们可能与域名的使用有关，例如它是否用于对邮件进行签名，是否对作者rfc5322.From:标头字段中具有该域名的所有邮件进行签名，甚至是域名所有者是否建议在没有适当签名的情况下丢弃邮件。实践陈述是在域名级别进行的，与针对特定消息进行的评估不同，如在消息过滤引擎中进行的评估。这种实践评估可以为消息过滤引擎确定消息处理提供有用的输入。当实践被定义时，每个域名所有者需要考虑要发布什么信息。检查实践的性质和程度（如有）是评估现场的可选内容，并严格取决于当地政策。
Signing can be performed by a component of the ADMD that creates the message, and/or within any ADMD along the relay path. The signer uses the appropriate private key that is associated with the SDID.
签名可以由创建消息的ADMD组件执行，和/或在中继路径上的任何ADMD内执行。签名者使用与SDID关联的适当私钥。
Verification can be performed by any functional component along the relay and delivery path. Verifiers retrieve the public key based upon the parameters stored in the message.
验证可由继电器和交付路径上的任何功能部件执行。验证器根据消息中存储的参数检索公钥。
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.
缺少有效作者签名的邮件（与邮件作者相关联的签名，而不是与中间人相关联的签名）可能会提示查询任何已发布的“签名实践”信息，以帮助确定是否未经授权使用了作者信息。
Figure 1 shows the verified identity as being used to assess an associated reputation, but it could be applied to other tasks, such as management tracking of mail. Local policy guidelines may cause signing practices to be checked or the message may be sent directly to the message Filtering Engine.
图1显示了用于评估相关声誉的已验证身份，但它可以应用于其他任务，例如邮件的管理跟踪。本地策略指导原则可能会导致检查签名实践，或者可能会将消息直接发送到消息筛选引擎。
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 verified 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.
声誉信息的一种流行用途是作为过滤引擎的输入，过滤引擎决定是否传递消息，也可能决定是否特别标记消息。过滤引擎已经变得复杂和精密。它们的详细信息不在DKIM的范围内，除了DKIM生成的已验证身份可以积累自己的声誉，并将添加到引擎使用的各种规则中。这些规则可以涵盖已签名的消息，并且可以处理来自某个域的未签名消息，前提是该域已经发布了有关其实践的信息。
It is expected that the most common venue for a DKIM implementation will be within the infrastructures of the authoring organization's outbound service and the receiving organization's inbound service, 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 typical, since it has higher administration and support costs.
预计DKIM实施的最常见场所将位于创作组织的出站服务和接收组织的入站服务（如部门或边界MTA）的基础设施内。DKIM可以在作者或接收者的MUA中实现，但由于其具有较高的管理和支持成本，因此预计这种情况不太典型。
A Mediator is an MUA that receives a message and can repost 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.
中介是一种MUA，它接收消息并可以将修改后的消息重新发布到邮件列表中。DKIM签名可以通过此过程经受某些类型的修改。此外，中介可以添加自己的签名。这可以由中介软件本身或中介ADMD中的任何出站组件添加。
The security considerations of the DKIM protocol are described in the DKIM base specification [RFC4871], with [RFC4686] as their basis.
DKIM基本规范[RFC4871]中描述了DKIM协议的安全注意事项，并以[RFC4686]为基础。
Many people contributed to the development of the DomainKeys Identified Mail and the effort of the DKIM Working Group is gratefully acknowledged. In particular, we would like to thank Jim Fenton for his extensive feedback diligently provided on every version of this document.
许多人为域名识别邮件的开发做出了贡献，DKIM工作组的努力得到了感谢。特别是，我们要感谢Jim Fenton对本文件的每一个版本所提供的广泛反馈。
[Kohnfelder] Kohnfelder, L., "Towards a Practical Public-key Cryptosystem", May 1978.
[Kohnfeld]Kohnfeld，L.“走向实用的公钥密码系统”，1978年5月。
[RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures", RFC 989, February 1987.
[RFC0989]Linn，J.和IAB隐私工作组，“互联网电子邮件的隐私增强：第一部分：信息加密和认证程序”，RFC 989，1987年2月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1113] Linn, J., "Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures", RFC 1113, August 1989.
[RFC1113]Linn，J.，“互联网电子邮件的隐私增强：第一部分-信息加密和认证程序”，RFC 11131989年8月。
[RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME Object Security Services", RFC 1848, October 1995.
[RFC1848]Crocker，S.，Galvin，J.，Murphy，S.，和N.Freed，“MIME对象安全服务”，RFC 18481995年10月。
[RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, August 1996.
[RFC1991]Atkins，D.，Stallings，W.，和P.Zimmermann，“PGP消息交换格式”，RFC 1991，1996年8月。
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[RFC2440]Callas，J.，Donnerhacke，L.，Finney，H.，和R.Thayer，“OpenPGP消息格式”，RFC 24401998年11月。
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3156]Elkins，M.，Del Torto，D.，Levien，R.，和T.Roessler，“OpenPGP的MIME安全性”，RFC 3156，2001年8月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851]Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 38512004年7月。
[RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006.
[RFC4406]Lyon，J.和M.Wong，“发件人ID：验证电子邮件”，RFC 4406，2006年4月。
[RFC4407] Lyon, J., "Purported Responsible Address in E-Mail Messages", RFC 4407, April 2006.
[RFC4407]Lyon，J.，“电子邮件中声称的责任地址”，RFC 4407，2006年4月。
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.
[RFC4408]Wong，M.和W.Schlitt，“授权在电子邮件中使用域的发件人策略框架（SPF），第1版”，RFC 4408，2006年4月。
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006.
[RFC4686]Fenton，J.，“驱动域密钥识别邮件（DKIM）的威胁分析”，RFC4686，2006年9月。
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[RFC4871]Allman，E.，Callas，J.，Delany，M.，Libbey，M.，Fenton，J.，和M.Thomas，“域密钥识别邮件（DKIM）签名”，RFC 48712007年5月。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC4880]Callas，J.，Donnerhacke，L.，Finney，H.，Shaw，D.，和R.Thayer，“OpenPGP消息格式”，RFC 48802007年11月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[WebofTrust] Network Associates, Inc. and its Affiliated Companies, "How PGP works, in Introduction to Cryptography", 1999, <http://www.pgpi.org/doc/pgpintro/>.
[WebofTrust]Network Associates，Inc.及其附属公司，“PGP的工作原理，密码术导论”，1999年<http://www.pgpi.org/doc/pgpintro/>.
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).
Internet邮件在用户世界（以邮件用户代理（MUA）的形式）和传输世界（以邮件传输代理（MTA）组成的邮件处理服务（MHS）的形式）之间进行分割。MHS负责接收来自一个用户（作者）的消息，并将其传递给一个或多个其他用户（收件人）。这将创建一个虚拟的MUA到MUA交换环境。MHS的第一个组件称为邮件提交代理（MSA），最后一个组件称为邮件传递代理（MDA）。
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 reposts it for further distribution. Typically, the new message will retain the original rfc5322.From: header field. A mailing list is a common example of a Mediator.
电子邮件中介是入站MDA和出站MSA。它接收消息的传递，对其服务进行适当的更改，然后重新发布以供进一步分发。通常，新消息将保留原始rfc5322.From:头字段。邮件列表是一个常见的中介示例。
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.
现代互联网邮件服务的特点是有许多独立的运营商、为用户提供服务的许多不同组件以及执行消息传输的许多其他组件。因此，有必要区分围绕功能组件集的行政边界，这些组件受一致的操作政策的约束。
As elaborated on below, every MSA is a candidate for signing using DKIM, and every MDA is a candidate for doing DKIM verification.
如下所述，每个MSA都是使用DKIM进行签名的候选，每个MDA都是进行DKIM验证的候选。
Operation of Internet Mail services is apportioned to different providers (or operators). Each can be composed of an independent ADministrative Management Domain (ADMD). An ADMD operates with an independent set of policies and interacts with other ADMDs according to differing types and amounts of trust. Examples include an end user operating a desktop client that connects to an independent email service, a department operating a submission agent or a local Relay, an organization's IT group that operates enterprise Relays, and an ISP operating a public shared email service.
互联网邮件服务的运营分配给不同的提供商（或运营商）。每个域都可以由独立的管理域（ADMD）组成。ADMD使用一组独立的策略进行操作，并根据不同的信任类型和信任程度与其他ADMD进行交互。例如，终端用户操作连接到独立电子邮件服务的桌面客户端，部门操作提交代理或本地中继，组织的IT组操作企业中继，ISP操作公共共享电子邮件服务。
Each of these can be configured into many combinations of administrative and operational relationships, with each ADMD potentially having a complex arrangement of functional components. Figure 2 depicts the relationships among ADMDs. Perhaps the most salient aspect of an ADMD is the differential trust that determines its policies for activities within the ADMD, versus those involving interactions with other ADMDs.
其中每一个都可以配置为管理和操作关系的许多组合，每个ADMD可能具有复杂的功能组件安排。图2描述了ADMD之间的关系。也许ADMD最突出的方面是差异信任，它决定了ADMD内活动的策略，而不是涉及与其他ADMD交互的策略。
Basic types of ADMDs include:
ADMD的基本类型包括：
Edge: Independent transfer services, in networks at the edge of the Internet Mail service.
边缘：独立的传输服务，在网络边缘的互联网邮件服务。
User: End-user services. These might be subsumed under an Edge service, such as is common for web-based email access.
用户：最终用户服务。这些可能包含在边缘服务下，例如基于web的电子邮件访问。
Transit: These are Mail Service Providers (MSP) offering value-added capabilities for Edge ADMDs, such as aggregation and filtering.
传输：这些是邮件服务提供商（MSP），为边缘ADMD提供增值功能，如聚合和过滤。
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之间进行。
+--------+ +--------+ +--------+
| ADMD#1 | | ADMD#3 | | ADMD#4 |
| ------ | | ------ | | ------ |
| | +----------------------->| | | |
| User | | |--Edge--+--->|--User |
| | | | +--->| | | |
| V | | | +--------+ +--------+
| Edge---+---+ |
| | | +----------+ |
+--------+ | | ADMD#2 | |
| | ------ | |
| | | |
+--->|-Transit--+---+
| |
+----------+
+--------+ +--------+ +--------+
| ADMD#1 | | ADMD#3 | | ADMD#4 |
| ------ | | ------ | | ------ |
| | +----------------------->| | | |
| User | | |--Edge--+--->|--User |
| | | | +--->| | | |
| V | | | +--------+ +--------+
| Edge---+---+ |
| | | +----------+ |
+--------+ | | ADMD#2 | |
| | ------ | |
| | | |
+--->|-Transit--+---+
| |
+----------+
Figure 2: ADministrative Management Domains (ADMD) Example
图2：管理管理域（ADMD）示例
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 verification.
在图2中，ADMD编号1和2是进行DKIM签名的候选，ADMD编号2、3和4是进行DKIM验证的候选。
The distinction between Transit network and Edge network transfer services is primarily significant because it highlights the need for
公交网络和边缘网络传输服务之间的区别主要是重要的，因为它强调了
concern over interaction and protection between independent administrations. The interactions between functional components within a single ADMD are subject to the policies of that domain. Although any pair of ADMDs can arrange for whatever policies they wish, Internet Mail is designed to permit inter-operation without prior arrangement.
关注独立行政机构之间的互动和保护。单个ADMD中功能组件之间的交互受该域策略的约束。尽管任何一对ADMD都可以根据自己的意愿安排任何策略，但Internet Mail的设计允许在没有事先安排的情况下进行交互操作。
Common ADMD examples are:
常见的ADMD示例有：
Enterprise Service Providers:
企业服务提供商：
Operators of an organization's internal data and/or mail services.
组织内部数据和/或邮件服务的操作员。
Internet Service Providers:
互联网服务供应商：
Operators of underlying data communication services that, in turn, are used by one or more Relays and Users. It is not necessarily their job to perform email functions, but they can, instead, provide an environment in which those functions can be performed.
由一个或多个继电器和用户使用的底层数据通信服务的运营商。执行电子邮件功能不一定是他们的工作，但他们可以提供一个执行这些功能的环境。
Mail Service Providers:
邮件服务供应商：
Operators of email services, such as for end users, or mailing lists.
电子邮件服务的运营商，如终端用户或邮件列表。
Index
指数
A ADMD 6 Administrative Management Domain 6 assessment 7
ADMD 6行政管理领域6评估7
D DKIM-Signature 12-13 DNS 6, 13-15
D DKIM签名12-13 DNS 6，13-15
I identifier 4-8 identity 3-7, 9, 12 infrastructure 5-6, 8-11, 17
I标识符4-8标识3-7、9、12基础设施5-6、8-11、17
M Mail Delivery Agent 6 Mail Handling Service 6 Mail Service Provider 6 Mail Submission Agent 6
M邮件递送代理6邮件处理服务6邮件服务提供商6邮件提交代理6
Mail Transfer Agent 6 Mail User Agent 6 MDA 6 MHS 6 MIME Object Security Services 5 MOSS 5 MSA 6 MSP 6 MTA 6 MUA 6
邮件传输代理6邮件用户代理6 MDA 6 MHS 6 MIME对象安全服务5 MOSS 5 MSA 6 MSP 6 MTA 6 MUA 6
O OpenPGP 5
O OpenPGP 5
P PEM 5 PGP 5 Pretty Good Privacy 5 Privacy Enhanced Mail 5
P PEM 5 PGP 5相当好的隐私5隐私增强邮件5
S S/MIME 5
S/S/5
T trust 3, 7-8, 20
T信托3,7-8,20
V verification 4, 7-8, 10-11, 13, 16, 20-21
验证4,7-8,10-11,13,16,20-21
W Web of Trust 6
W信任网6
X X.509 6
X X.509 6
Authors' Addresses
作者地址
Tony Hansen AT&T Laboratories 200 Laurel Ave. Middletown, NJ 07748 USA
美国新泽西州米德尔顿劳雷尔大道200号托尼·汉森AT&T实验室，邮编：07748
EMail: tony+dkimov@maillennium.att.com
EMail: tony+dkimov@maillennium.att.com
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 USA
Dave Crocker Brandenburg互联网675 Spruce Dr.Sunnyvale，加利福尼亚州，美国94086
EMail: dcrocker@bbiw.net
EMail: dcrocker@bbiw.net
Phillip Hallam-Baker Default Deny Security, Inc.
Phillip Hallam Baker默认拒绝安全公司。
EMail: phillip@hallambaker.com
EMail: phillip@hallambaker.com