Internet Engineering Task Force (IETF) T. Hansen
Request for Comments: 5863 AT&T Laboratories
Category: Informational E. Siegel
ISSN: 2070-1721 Consultant
P. Hallam-Baker
Default Deny Security, Inc.
D. Crocker
Brandenburg InternetWorking
May 2010
Internet Engineering Task Force (IETF) T. Hansen
Request for Comments: 5863 AT&T Laboratories
Category: Informational E. Siegel
ISSN: 2070-1721 Consultant
P. Hallam-Baker
Default Deny Security, Inc.
D. Crocker
Brandenburg InternetWorking
May 2010
DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations
域密钥识别邮件（DKIM）开发、部署和操作
Abstract
摘要
DomainKeys Identified Mail (DKIM) allows an organization to claim 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 and using the domain name service as its key server technology. This permits verification of a responsible organization, as well as the integrity of the message content. 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". This document provides implementation, deployment, operational, and migration considerations for DKIM.
DomainKeys Identified Mail（DKIM）允许组织以可由收件人验证的方式声明传输消息的责任。组织可以是作者、原始发送站点、中间人或其代理人之一。一封邮件可以包含多个签名，这些签名来自与该邮件相关的相同或不同的组织。DKIM为电子邮件定义了一个域级数字签名身份验证框架，使用公钥加密技术，并使用域名服务作为其密钥服务器技术。这允许验证责任组织以及消息内容的完整性。DKIM还将提供一种机制，允许潜在的电子邮件签名者发布有关其电子邮件签名实践的信息；这将允许电子邮件接收者对邮件进行额外的评估。DKIM的电子邮件身份验证可以帮助全球控制“垃圾邮件”和“网络钓鱼”。本文档提供了DKIM的实现、部署、操作和迁移注意事项。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5863.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5863.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
2. Using DKIM as Part of Trust Assessment ..........................4
2.1. A Systems View of Email Trust Assessment ...................4
2.2. Choosing a DKIM Tag for the Assessment Identifier ..........6
2.3. Choosing the Signing Domain Name ...........................8
2.4. Recipient-Based Assessments ...............................10
2.5. Filtering .................................................12
3. DKIM Key Generation, Storage, and Management ...................15
3.1. Private Key Management: Deployment and Ongoing
Operations ................................................16
3.2. Storing Public Keys: DNS Server Software Considerations ...17
3.3. Per-User Signing Key Management Issues ....................18
3.4. Third-Party Signer Key Management and Selector
Administration ............................................19
3.5. Key Pair / Selector Life Cycle Management .................19
1. Introduction ....................................................4
2. Using DKIM as Part of Trust Assessment ..........................4
2.1. A Systems View of Email Trust Assessment ...................4
2.2. Choosing a DKIM Tag for the Assessment Identifier ..........6
2.3. Choosing the Signing Domain Name ...........................8
2.4. Recipient-Based Assessments ...............................10
2.5. Filtering .................................................12
3. DKIM Key Generation, Storage, and Management ...................15
3.1. Private Key Management: Deployment and Ongoing
Operations ................................................16
3.2. Storing Public Keys: DNS Server Software Considerations ...17
3.3. Per-User Signing Key Management Issues ....................18
3.4. Third-Party Signer Key Management and Selector
Administration ............................................19
3.5. Key Pair / Selector Life Cycle Management .................19
4. Signing ........................................................21
4.1. DNS Records ...............................................21
4.2. Signing Module ............................................21
4.3. Signing Policies and Practices ............................22
5. Verifying ......................................................23
5.1. Intended Scope of Use .....................................23
5.2. Signature Scope ...........................................23
5.3. Design Scope of Use .......................................24
5.4. Inbound Mail Filtering ....................................24
5.5. Messages Sent through Mailing Lists and Other
Intermediaries ............................................25
5.6. Generation, Transmission, and Use of Results Headers ......25
6. Taxonomy of Signatures .........................................26
6.1. Single Domain Signature ...................................26
6.2. Parent Domain Signature ...................................27
6.3. Third-Party Signature .....................................27
6.4. Using Trusted Third-Party Senders .........................29
6.5. Multiple Signatures .......................................30
7. Example Usage Scenarios ........................................31
7.1. Author's Organization - Simple ............................32
7.2. Author's Organization - Differentiated Types of Mail ......32
7.3. Author Domain Signing Practices ...........................32
7.4. Delegated Signing .........................................34
7.5. Independent Third-Party Service Providers .................35
7.6. Mail Streams Based on Behavioral Assessment ...............35
7.7. Agent or Mediator Signatures ..............................36
8. Usage Considerations ...........................................36
8.1. Non-Standard Submission and Delivery Scenarios ............36
8.2. Protection of Internal Mail ...............................37
8.3. Signature Granularity .....................................38
8.4. Email Infrastructure Agents ...............................39
8.5. Mail User Agent ...........................................40
9. Security Considerations ........................................41
10. Acknowledgements ..............................................41
11. References ....................................................42
11.1. Normative References .....................................42
11.2. Informative References ...................................42
Appendix A. Migration Strategies .................................43
A.1. Migrating from DomainKeys .................................43
A.2. Migrating Hash Algorithms .................................48
A.3. Migrating Signing Algorithms ..............................49
Appendix B. General Coding Criteria for Cryptographic
Applications .........................................50
4. Signing ........................................................21
4.1. DNS Records ...............................................21
4.2. Signing Module ............................................21
4.3. Signing Policies and Practices ............................22
5. Verifying ......................................................23
5.1. Intended Scope of Use .....................................23
5.2. Signature Scope ...........................................23
5.3. Design Scope of Use .......................................24
5.4. Inbound Mail Filtering ....................................24
5.5. Messages Sent through Mailing Lists and Other
Intermediaries ............................................25
5.6. Generation, Transmission, and Use of Results Headers ......25
6. Taxonomy of Signatures .........................................26
6.1. Single Domain Signature ...................................26
6.2. Parent Domain Signature ...................................27
6.3. Third-Party Signature .....................................27
6.4. Using Trusted Third-Party Senders .........................29
6.5. Multiple Signatures .......................................30
7. Example Usage Scenarios ........................................31
7.1. Author's Organization - Simple ............................32
7.2. Author's Organization - Differentiated Types of Mail ......32
7.3. Author Domain Signing Practices ...........................32
7.4. Delegated Signing .........................................34
7.5. Independent Third-Party Service Providers .................35
7.6. Mail Streams Based on Behavioral Assessment ...............35
7.7. Agent or Mediator Signatures ..............................36
8. Usage Considerations ...........................................36
8.1. Non-Standard Submission and Delivery Scenarios ............36
8.2. Protection of Internal Mail ...............................37
8.3. Signature Granularity .....................................38
8.4. Email Infrastructure Agents ...............................39
8.5. Mail User Agent ...........................................40
9. Security Considerations ........................................41
10. Acknowledgements ..............................................41
11. References ....................................................42
11.1. Normative References .....................................42
11.2. Informative References ...................................42
Appendix A. Migration Strategies .................................43
A.1. Migrating from DomainKeys .................................43
A.2. Migrating Hash Algorithms .................................48
A.3. Migrating Signing Algorithms ..............................49
Appendix B. General Coding Criteria for Cryptographic
Applications .........................................50
DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. This document provides practical tips for those who are developing DKIM software, mailing list managers, filtering strategies based on the output from DKIM verification, and DNS servers; those who are deploying DKIM software, keys, mailing list software, and migrating from DomainKeys [RFC4870]; and those who are responsible for the ongoing operations of an email infrastructure that has deployed DKIM.
DomainKeys Identified Mail（DKIM）允许组织以可由收件人验证的方式声明传输消息的责任。本文档为开发DKIM软件、邮件列表管理器、基于DKIM验证输出的过滤策略以及DNS服务器的人员提供了实用技巧；部署DKIM软件、密钥、邮件列表软件以及从域密钥[RFC4870]迁移的人员；以及负责部署了DKIM的电子邮件基础设施的日常运营的人员。
The reader is encouraged to read the DKIM Service Overview document [RFC5585] before this document. More detailed guidance about DKIM and Author Domain Signing Practices (ADSP) can also be found in the protocol specifications [RFC4871], [RFC5617], and [RFC5672].
鼓励读者在阅读本文档之前阅读DKIM服务概述文档[RFC5585]。关于DKIM和作者域签名实践（ADSP）的更详细指南也可以在协议规范[RFC4871]、[RFC5617]和[RFC5672]中找到。
The document is organized around the key concepts related to DKIM. Within each section, additional considerations specific to development, deployment, or ongoing operations are highlighted where appropriate. The possibility of the use of DKIM results as input to a local reputation database is also discussed.
本文件围绕与DKIM相关的关键概念进行组织。在每个部分中，都会在适当的情况下强调特定于开发、部署或正在进行的操作的其他注意事项。还讨论了使用DKIM结果作为本地声誉数据库输入的可能性。
DKIM participates in a trust-oriented enhancement to the Internet's email service, to facilitate message handling decisions, such as for delivery and for content display. Trust-oriented message handling has substantial differences from the more established approaches that consider messages in terms of risk and abuse. With trust, there is a collaborative exchange between a willing participant along the sending path and a willing participant at a recipient site. In contrast, the risk model entails independent, unilateral action by the recipient site, in the face of a potentially unknown, hostile, and deceptive sender. This translates into a very basic technical difference: in the face of unilateral action by the recipient and even antagonistic efforts by the sender, risk-oriented mechanisms are based on heuristics, that is, on guessing. Guessing produces statistical results with some false negatives and some false positives. For trust-based exchanges, the goal is the deterministic exchange of information. For DKIM, that information is the one identifier that represents a stream of mail for which an independent assessment is sought (by the signer).
DKIM参与了对Internet电子邮件服务的信任增强，以促进邮件处理决策，如发送和内容显示。面向信任的消息处理与考虑消息和风险的更为成熟的方法有很大的差异。有了信任，发送路径上的自愿参与者和接收方站点上的自愿参与者之间就可以进行协作交换。相反，风险模型要求接收方站点在面对潜在未知、敌对和欺骗性发件人时采取独立、单方面的行动。这就转化为一个非常基本的技术差异：面对接受者的单方面行动，甚至是发送者的对抗性努力，面向风险的机制是基于启发式的，即猜测。猜测会产生一些假阴性和假阳性的统计结果。对于基于信任的交换，目标是确定的信息交换。对于DKIM，该信息是表示（签名者）寻求独立评估的邮件流的唯一标识符。
A trust-based service is built upon a validated Responsible Identifier that labels a stream of mail and is controlled by an identity (role, person, or organization). The identity is acknowledging some degree of responsibility for the message stream. Given a basis for believing that an identifier is being used in an authorized manner, the recipient site can make and use an assessment of the associated identity. An identity can use different identifiers, on the assumption that the different streams might produce different assessments. For example, even the best-run marketing campaigns will tend to produce some complaints that can affect the reputation of the associated identifier, whereas a stream of transactional messages is likely to have a more pristine reputation.
基于信任的服务建立在已验证的责任标识符之上，该标识符标记邮件流，并由身份（角色、人员或组织）控制。标识确认了对消息流的某种程度的责任。给定一个相信标识符正在以授权方式使用的基础，接收方站点可以对相关身份进行评估。身份可以使用不同的标识符，前提是不同的流可能产生不同的评估。例如，即使是运行最好的营销活动也会产生一些投诉，这些投诉可能会影响相关标识符的声誉，而事务性消息流可能具有更原始的声誉。
Determining that the identifier's use is valid is quite different from determining that the content of a message is valid. The former means only that the identifier for the responsible role, person, or organization has been legitimately associated with a message. The latter means that the content of the message can be believed and, typically, that the claimed author of the content is correct. DKIM validates only the presence of the identifier used to sign the message. Even when this identifier is validated, DKIM carries no implication that any of the message content, including the RFC5322.From field [RFC5322], is valid. Surprisingly, this limit to the semantics of a DKIM signature applies even when the validated signing identifier is the same domain name as is used in the RFC5322.From field! DKIM's only claim about message content is that the content cited in the DKIM-Signature: field's h= tag has been delivered without modification. That is, it asserts message content integrity -- between signing and verifying -- not message content validity.
确定标识符的使用是否有效与确定消息的内容是否有效完全不同。前者仅意味着负责角色、人员或组织的标识符已合法地与消息关联。后者意味着可以相信消息的内容，并且通常意味着声称的内容作者是正确的。DKIM仅验证用于签名消息的标识符的存在。即使验证了该标识符，DKIM也不会暗示任何消息内容（包括RFC5322.From字段[RFC5322]）有效。令人惊讶的是，即使验证的签名标识符与RFC5322.From字段中使用的域名相同，对DKIM签名语义的这种限制也适用！DKIM关于消息内容的唯一声明是，DKIM签名：字段的h=标记中引用的内容未经修改就已交付。也就是说，它断言消息内容的完整性——在签名和验证之间——而不是消息内容的有效性。
As shown in Figure 1, this enhancement is a communication between a responsible role, person, or organization that signs the message and a recipient organization that assesses its trust in the signer. The recipient then makes handling decisions based on a collection of assessments, of which the DKIM mechanism is only a part. In this model, as shown in Figure 1, validation is an intermediary step, having the sole task of passing a validated Responsible Identifier to the Identity Assessor. The communication is of a single Responsible Identifier that the Responsible Identity wishes to have used by the Identity Assessor. The Identifier is the sole, formal input and output value of DKIM signing. The Identity Assessor uses this single, provided Identifier for consulting whatever assessment databases are deemed appropriate by the assessing entity. In turn, output from the Identity Assessor is fed into a Handling Filter
如图1所示，此增强是负责对消息进行签名的角色、人员或组织与评估其对签名者信任的接收方组织之间的通信。然后，接收者根据一系列评估做出处理决策，DKIM机制只是其中的一部分。在这个模型中，如图1所示，验证是一个中间步骤，其唯一任务是将经过验证的责任标识符传递给身份评估员。该通信是一个单一的责任标识符，责任标识符希望被身份评估员使用。标识符是DKIM签名的唯一正式输入和输出值。身份评估员使用该单一的、提供的标识符来咨询评估实体认为合适的任何评估数据库。反过来，来自身份评估器的输出被送入处理过滤器
engine that considers a range of factors, along with this single output value. The range of factors can include ancillary information from the DKIM validation.
考虑了一系列因素以及该单一输出值的发动机。因素范围可包括来自DKIM验证的辅助信息。
Identity Assessment covers a range of possible functions. It can be as simple as determining whether the identifier is a member of some list, such as authorized operators or participants in a group that might be of interest for recipient assessment. Equally, it can indicate a degree of trust (reputation) that is to be afforded the actor using that identifier. The extent to which the assessment affects the handling of the message is, of course, determined later, by the Handling Filter.
身份评估包括一系列可能的功能。它可以简单到确定标识符是否是某个列表的成员，例如可能对接收者评估感兴趣的授权操作员或组中的参与者。同样，它可以表示使用该标识符的参与者将获得的信任程度（声誉）。当然，评估对消息处理的影响程度稍后由处理过滤器确定。
+------+------+ +------+------+
| Author | | Recipient |
+------+------+ +------+------+
| ^
| |
| +------+------+
| -->| Handling |<--
| -->| Filter |<--
| +-------------+
| ^
V Responsible |
+-------------+ Identifier +------+------+
| Responsible |. . . . . . . . . . .>| Identity |
| Identity | . . | Assessor |
+------+------+ . . +-------------+
| V . ^ ^
V . . | |
+------------------.-------.--------------------+ | |
| +------+------+ . . . > . +-------------+ | | | +-----------+
| | Identifier | | Identifier +--|--+ +--+ Assessment|
| | Signer +------------->| Validator | | | Databases |
| +-------------+ +-------------+ | +-----------+
| DKIM Service |
+-----------------------------------------------+
+------+------+ +------+------+
| Author | | Recipient |
+------+------+ +------+------+
| ^
| |
| +------+------+
| -->| Handling |<--
| -->| Filter |<--
| +-------------+
| ^
V Responsible |
+-------------+ Identifier +------+------+
| Responsible |. . . . . . . . . . .>| Identity |
| Identity | . . | Assessor |
+------+------+ . . +-------------+
| V . ^ ^
V . . | |
+------------------.-------.--------------------+ | |
| +------+------+ . . . > . +-------------+ | | | +-----------+
| | Identifier | | Identifier +--|--+ +--+ Assessment|
| | Signer +------------->| Validator | | | Databases |
| +-------------+ +-------------+ | +-----------+
| DKIM Service |
+-----------------------------------------------+
Figure 1: Actors in a Trust Sequence Using DKIM
图1：使用DKIM的信任序列中的参与者
The signer of a message needs to be able to provide precise data and know what that data will mean upon delivery to the Assessor. If there is ambiguity in the choice that will be made on the recipient side, then the sender cannot know what basis for assessment will be used. DKIM has three values that specify identification information and it is easy to confuse their use, although only one defines the
消息的签名者需要能够提供准确的数据，并知道在交付给评估员时这些数据意味着什么。如果接收方做出的选择存在歧义，则发送方无法知道将使用何种评估依据。DKIM有三个值指定标识信息，很容易混淆它们的用法，尽管只有一个值定义
formal input and output of DKIM, with the other two being used for internal protocol functioning and adjunct purposes, such as auditing and debugging.
DKIM的正式输入和输出，另外两个用于内部协议功能和附加目的，如审计和调试。
The salient values include the s=, d= and i= parameters in the DKIM-Signature: header field. In order to achieve the end-to-end determinism needed for this collaborative exchange from the signer to the assessor, the core model needs to specify what the signer is required to provide to the assessor. The update to RFC 4871 [RFC5672] specifies:
显著值包括DKIM Signature:header字段中的s=、d=和i=参数。为了实现从签名者到评估者的这种协作交换所需的端到端的确定性，核心模型需要指定签名者需要向评估者提供什么。RFC 4871[RFC5672]的更新规定：
DKIM's primary task is to communicate from the Signer to a
recipient-side Identity Assessor a single Signing Domain
Identifier (SDID) that refers to a responsible identity. DKIM MAY
optionally provide a single responsible Agent or User Identifier
(AUID)... A receive-side DKIM verifier MUST communicate the
Signing Domain Identifier (d=) to a consuming Identity Assessor
module and MAY communicate the User Agent Identifier (i=) if
present.... To the extent that a receiver attempts to intuit any
structured semantics for either of the identifiers, this is a
heuristic function that is outside the scope of DKIM's
specification and semantics.
DKIM's primary task is to communicate from the Signer to a
recipient-side Identity Assessor a single Signing Domain
Identifier (SDID) that refers to a responsible identity. DKIM MAY
optionally provide a single responsible Agent or User Identifier
(AUID)... A receive-side DKIM verifier MUST communicate the
Signing Domain Identifier (d=) to a consuming Identity Assessor
module and MAY communicate the User Agent Identifier (i=) if
present.... To the extent that a receiver attempts to intuit any
structured semantics for either of the identifiers, this is a
heuristic function that is outside the scope of DKIM's
specification and semantics.
The single, mandatory value that DKIM supplies as its output is:
DKIM作为其输出提供的单个强制值为：
d= This specifies the "domain of the signing entity". It is a domain name and is combined with the selector to form a DNS query. A receive-side DKIM verifier needs to communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and can also communicate the User Agent Identifier (i=) if present.
d=指定“签名实体的域”。它是一个域名，与选择器结合形成DNS查询。接收端DKIM验证器需要将签名域标识符（d=）传递给消费身份评估器模块，并且如果存在，还可以传递用户代理标识符（i=）。
The adjunct values are:
附加值为：
s= This tag specifies the selector. It is used to discriminate among different keys that can be used for the same d= domain name. As discussed in Section 4.3 of [RFC5585], "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". Consequently, the selector is not appropriate for use as part or all of the identifier used to make assessments.
s=此标记指定选择器。它用于区分可用于相同d=域名的不同密钥。如[RFC5585]第4.3节所述，“如果验证者将选择器用作评估机制的一部分，则将没有剩余的机制用于从旧的或受损的密钥过渡到新的密钥”。因此，选择器不适合作为用于进行评估的标识符的一部分或全部使用。
i= This tag is optional and provides the "[t]he Agent or User Identifier (AUID) on behalf of which the SDID is taking responsibility" [RFC5672]. The identity can be in the syntax
i=此标签是可选的，并提供“SDID代表其负责的代理或用户标识符（AUID）”[RFC5672]。标识可以在语法中
of an entire email address or only a domain name. The domain name can be the same as for d= or it can be a sub-name of the d= name.
一个完整的电子邮件地址或只有一个域名。域名可以与d=相同，也可以是d=名称的子名称。
NOTE: Although the i= identity has the syntax of an email address, it is not required to have those semantics. That is, "the identity of the user" need not be the same as the user's mailbox. For example, the signer might wish to use i= to encode user-related audit information, such as how they were accessing the service at the time of message posting. Therefore, it is not possible to conclude anything from the i= string's (dis)similarity to email addresses elsewhere in the header.
注意：尽管i=identity具有电子邮件地址的语法，但不需要具有这些语义。也就是说，“用户的身份”不必与用户的邮箱相同。例如，签名者可能希望使用i=编码与用户相关的审核信息，例如他们在发布消息时如何访问服务。因此，无法从i=string（dis）与头中其他位置的电子邮件地址的相似性得出任何结论。
So, i= can have any of these properties:
因此，i=可以具有以下任何属性：
* Be a valid domain when it is the same as d=
* 如果与d相同，则为有效域=
* Appear to be a subdomain of d= but might not even exist
* 似乎是d=的子域，但可能不存在
* Look like a mailbox address but might have different semantics and therefore not function as a valid email address
* 看起来像邮箱地址，但可能具有不同的语义，因此不能用作有效的电子邮件地址
* Be unique for each message, such as indicating access details of the user for the specific posting
* 对于每条消息都必须是唯一的，例如指明特定帖子的用户访问详细信息
This underscores why the tag needs to be treated as being opaque, since it can represent any semantics, known only to the signer.
这强调了为什么标记需要被视为不透明的，因为它可以表示只有签名者才知道的任何语义。
Hence, i= serves well as a token that is usable like a Web cookie, for return to the signing Administrative Management Domain (ADMD) -- such as for auditing and debugging. Of course in some scenarios the i= string might provide a useful adjunct value for additional (heuristic) processing by the Handling Filter.
因此，i=很好地充当了一个令牌，它可以像Web cookie一样使用，以返回到签名管理域（ADMD）——例如用于审核和调试。当然，在某些情况下，i=字符串可能会为处理过滤器的附加（启发式）处理提供有用的附加值。
A DKIM signing entity can serve different roles, such as being the author of content, the operator of the mail service, or the operator of a reputation service that also provides signing services on behalf of its customers. In these different roles, the basis for distinguishing among portions of email traffic can vary. For an entity creating DKIM signatures, it is likely that different portions of its mail will warrant different levels of trust. For example:
DKIM签名实体可以扮演不同的角色，例如内容作者、邮件服务运营商或同时代表其客户提供签名服务的声誉服务运营商。在这些不同的角色中，区分电子邮件流量部分的基础可能会有所不同。对于创建DKIM签名的实体，其邮件的不同部分可能保证不同级别的信任。例如：
* Mail is sent for different purposes, such as marketing versus transactional, and recipients demonstrate different patterns of acceptance between these.
* 邮件发送的目的不同，比如营销和交易，收件人表现出不同的接受模式。
* For an operator of an email service, there often are distinct sub-populations of users warranting different levels of trust or privilege, such as paid versus free users, or users engaged in direct correspondence versus users sending bulk mail.
* 对于电子邮件服务的运营商来说，通常会有不同的子用户群，他们保证不同级别的信任或特权，例如付费用户与免费用户，或者直接通信用户与发送批量邮件的用户。
* Mail originating outside an operator's system, such as when it is redistributed by a mailing-list service run by the operator, will warrant a different reputation from mail submitted by users authenticated with the operator.
* 来自运营商系统之外的邮件，例如，当由运营商运行的邮件列表服务重新分发时，将保证与经运营商认证的用户提交的邮件不同的信誉。
It is therefore likely to be useful for a signer to use different d= subdomain names, for different message traffic streams, so that receivers can make differential assessments. However, too much differentiation -- that is, too fine a granularity of signing domains -- makes it difficult for the receiver to discern a sufficiently stable pattern of traffic for developing an accurate and reliable assessment. So the differentiation needs to achieve a balance. Generally, in a trust system, legitimate signers have an incentive to pick a small stable set of identities, so that recipients and others can attribute reputations to them. The set of these identities a receiver trusts is likely to be quite a bit smaller than the set it views as risky.
因此，对于不同的消息流量流，签名者使用不同的d=子域名可能是有用的，以便接收者可以进行差异评估。然而，太多的差异（即签名域的粒度太细）使得接收者难以识别足够稳定的流量模式，以开发准确可靠的评估。因此，差异化需要实现平衡。一般来说，在信任系统中，合法签名者有动机选择一小部分稳定的身份，以便接收者和其他人能够将声誉归于他们。接收者信任的这些身份的集合可能比它认为有风险的集合要小得多。
The challenge in using additional layers of subdomains is whether the extra granularity will be useful for the Assessor. In fact, excessive levels invite ambiguity: if the Assessor does not take advantage of the added granularity in the entire domain name that is provided, they might unilaterally decide to use only some rightmost part of the identifier. The signer cannot know what portion will be used. That ambiguity would move the use of DKIM back to the realm of heuristics, rather than the deterministic processing that is its goal.
使用附加子域层的挑战在于额外的粒度是否对评估员有用。事实上，过高的级别会引起歧义：如果评估员没有利用提供的整个域名中增加的粒度，他们可能会单方面决定只使用标识符最右边的部分。签名者无法知道将使用哪一部分。这种模糊性将使DKIM的使用回到启发式领域，而不是其目标的确定性处理。
Hence, the challenge is to determine a useful scheme for labeling different traffic streams. The most obvious choices are among different types of content and/or different types of authors. Although stability is essential, it is likely that the choices will change, over time, so the scheme needs to be flexible.
因此，挑战在于确定一个有用的方案来标记不同的业务流。最明显的选择是在不同类型的内容和/或不同类型的作者之间。虽然稳定性至关重要，但随着时间的推移，选择可能会发生变化，因此该计划需要灵活。
For those originating message content, the most likely choice of subdomain naming scheme will by based upon type of content, which can use content-oriented labels or service-oriented labels. For example:
对于那些原始消息内容，最可能的子域命名方案选择将基于内容类型，内容类型可以使用面向内容的标签或面向服务的标签。例如：
transaction.example.com newsletter.example.com bugreport.example.com support.example.com sales.example.com marketing.example.com
transaction.example.com newsletter.example.com bugreport.example.com support.example.com sales.example.com marketing.example.com
where the choices are best dictated by whether they provide the Identity Assessor with the ability to discriminate usefully among streams of mail that demonstrate significantly different degrees of recipient acceptance or safety. Again, the danger in providing too fine a granularity is that related message streams that are labeled separately will not benefit from an aggregate reputation.
其中，最佳选择取决于它们是否为身份评估员提供了有效区分不同邮件流的能力，这些邮件流显示了收件人接受程度或安全性的显著差异。同样，提供过于精细的粒度的危险在于，单独标记的相关消息流不会从聚合信誉中获益。
For those operating messaging services on behalf of a variety of customers, an obvious scheme to use has a different subdomain label for each customer. For example:
对于那些代表各种客户操作消息传递服务的人，一个显而易见的方案是为每个客户使用不同的子域标签。例如：
widgetco.example.net moviestudio.example.net bigbank.example.net
widgetco.example.net moviestudio.example.net bigbank.example.net
However, it can also be appropriate to label by the class of service or class of customer, such as:
但是，也可以按服务类别或客户类别进行标记，例如：
premier.example.net free.example.net certified.example.net
premier.example.net free.example.net certified.example.net
Prior to using domain names for distinguishing among sources of data, IP Addresses have been the basis for distinction. Service operators typically have done this by dedicating specific outbound IP Addresses to specific mail streams -- typically to specific customers. For example, a university might want to distinguish mail from the administration, versus mail from the student dorms. In order to make the adoption of a DKIM-based service easier, it can be reasonable to translate the same partitioning of traffic, using domain names in place of the different IP Addresses.
在使用域名区分数据源之前，IP地址是区分的基础。服务运营商通常通过将特定的出站IP地址专用于特定的邮件流（通常是特定的客户）来实现这一点。例如，一所大学可能想要区分邮件与行政部门，而不是学生宿舍的邮件。为了更容易采用基于DKIM的服务，可以合理地转换相同的流量分区，使用域名代替不同的IP地址。
DKIM gives the recipient site's Identity Assessor a verifiable identifier to use for analysis. Although the mechanism does not make claims that the signer is a Good Actor or a Bad Actor, it does make
DKIM为接收方站点的身份评估员提供一个可验证的标识符，用于分析。尽管该机制并没有声称签名者是一个好的参与者还是一个坏的参与者，但它确实让人信服
it possible to know that use of the identifier is valid. This is in marked contrast with schemes that do not have authentication. Without verification, it is not possible to know whether the identifier -- whether taken from the RFC5322.From field, the RFC5321.MailFrom command, or the like -- is being used by an authorized agent. DKIM solves this problem. Hence, with DKIM, the Assessor can know that two messages with the same DKIM d= identifier are, in fact, signed by the same person or organization. This permits a far more stable and accurate assessment of mail traffic using that identifier.
可以知道标识符的使用是有效的。这与没有身份验证的方案形成鲜明对比。未经验证，无法知道授权代理是否正在使用该标识符（无论是从RFC5322.from字段、RFC5321.MailFrom命令等获取的）。DKIM解决了这个问题。因此，使用DKIM，评估员可以知道具有相同DKIM d=标识符的两条消息实际上是由同一个人或组织签署的。这允许使用该标识符对邮件流量进行更加稳定和准确的评估。
DKIM is distinctive, in that it provides an identifier that is not necessarily related to any other identifier in the message. Hence, the signer might be the author's ADMD, one of the operators along the transit path, or a reputation service being used by one of those handling services. In fact, a message can have multiple signatures, possibly by any number of these actors.
DKIM与众不同，因为它提供的标识符不一定与消息中的任何其他标识符相关。因此，签名者可能是作者的ADMD、沿途的运营商之一，或者这些处理服务之一使用的信誉服务。事实上，一条消息可以有多个签名，可能由任意数量的参与者签名。
As discussed above, the choice of identifiers needs to be based on differences that the signer thinks will be useful for the recipient Assessor. Over time, industry practices establish norms for these choices.
如上所述，标识符的选择需要基于签名人认为对接收人评估员有用的差异。随着时间的推移，行业实践为这些选择建立了规范。
Absent such norms, it is best for signers to distinguish among streams that have significant differences, while consuming the smallest number of identifiers possible. This will limit the burden on recipient Assessors.
如果没有这样的规范，签名者最好区分具有显著差异的流，同时使用尽可能少的标识符。这将限制接受评估人员的负担。
A common view about a DKIM signature is that it carries a degree of assurance about some or all of the message contents, and in particular, that the RFC5322.From field is likely to be valid. In fact, DKIM makes assurances only about the integrity of the data and not about its validity. Still, presumptions of the RFC5322.From field validity remain a concern. Hence, a signer using a domain name that is unrelated to the domain name in the RFC5322.From field can reasonably expect that the disparity will warrant some curiosity, at least until signing by independent operators has produced some established practice among recipient Assessors.
关于DKIM签名的一个常见观点是，它对部分或全部消息内容有一定程度的保证，特别是RFC5322.From字段可能有效。事实上，DKIM只保证数据的完整性，而不保证数据的有效性。尽管如此，RFC5322的推定仍然是一个值得关注的问题。因此，使用与RFC5322.From域中的域名无关的域名的签名人可以合理地预期，这种差异会引起一些好奇，至少在独立运营商的签名在接收人评估员中产生一些既定惯例之前是如此。
With the identifier(s) supplied by DKIM, the Assessor can consult an independent assessment service about the entity associated with the identifier(s). Another possibility is that the Assessor can develop its own reputation rating for the identifier(s). That is, over time, the Assessor can observe the stream of messages associated with the identifier(s) developing a reaction to associated content. For example, if there is a high percentage of user complaints regarding
通过DKIM提供的标识符，评估员可以咨询独立评估服务机构，了解与标识符相关的实体。另一种可能性是，评估员可以为识别者制定自己的声誉评级。也就是说，随着时间的推移，评估员可以观察与标识符相关联的消息流，从而对相关联的内容做出反应。例如，如果用户对
signed mail with a d= value of "widgetco.example.net", the Assessor might include that fact in the vector of data it provides to the Handling Filter. This is also discussed briefly in Section 5.4.
d=值为“widgetco.example.net”的签名邮件，评估员可能会将该事实包含在提供给处理过滤器的数据向量中。第5.4节也简要讨论了这一点。
The assessment of the signing identifier is given to a Handling Filter that is defined by local policies, according to a potentially wide range of different factors and weightings. This section discusses some of the kinds of choices and weightings that are plausible and the differential actions that might be performed. Because authenticated domain names represent a collaborative sequence between signer and Assessor, actions can sometimes reasonably include contacting the signer.
签名标识符的评估将根据可能广泛的不同因素和权重，提供给由本地策略定义的处理筛选器。本节讨论一些看似合理的选择和权重，以及可能执行的不同操作。由于经过身份验证的域名代表了签名人和评估人之间的协作顺序，因此有时可以合理地包括联系签名人。
The discussion focuses on variations in Organizational Trust versus Message Stream Risk, that is, the degree of positive assessment of a DKIM-signing organization, and the potential danger present in the message stream signed by that organization. While it might seem that higher trust automatically means lower risk, the experience with real-world operations provides examples of every combination of the two factors, as shown in Figure 2. For each axis, only three levels of granularity are listed, in order to keep discussion manageable. In real-world filtering engines, finer-grained distinctions are typically needed, and there typically are more axes. For example, there are different types of risk, so that an engine might distinguish between spam risk versus virus risk and take different actions based on which type of problematic content is present. For spam, the potential damage from a false negative is small, whereas the damage from a false positive is high. For a virus, the potential danger from a false negative is extremely high, while the likelihood of a false positive when using modern detection tools is extremely low. However, for the discussion here, "risk" is taken as a single construct.
讨论的重点是组织信任与消息流风险的差异，即对DKIM签名组织的积极评估程度，以及该组织签名的消息流中存在的潜在危险。虽然看起来更高的信任自动意味着更低的风险，但实际操作的经验提供了这两个因素组合的示例，如图2所示。对于每个轴，只列出了三个粒度级别，以保持讨论的可管理性。在现实世界的过滤引擎中，通常需要更细粒度的区分，并且通常有更多的轴。例如，存在不同类型的风险，因此引擎可能会区分垃圾邮件风险和病毒风险，并根据存在的问题内容类型采取不同的措施。对于垃圾邮件，假阴性的潜在损害很小，而假阳性的损害很高。对于病毒而言，假阴性的潜在危险极高，而使用现代检测工具时假阳性的可能性极低。然而，在这里的讨论中，“风险”被视为一个单独的结构。
The DKIM d= identifier is independent of any other identifier in a message and can be a subdomain of the name owned by the signer. This permits the use of fine-grained and stable distinctions between different types of message streams, such as between transactional messages and marketing messages from the same organization. Hence, the use of DKIM might permit a richer filtering model than has typically been possible for mail-receiving engines.
DKIM d=标识符独立于消息中的任何其他标识符，可以是签名者拥有的名称的子域。这允许在不同类型的消息流之间使用细粒度和稳定的区别，例如来自同一组织的事务消息和营销消息之间的区别。因此，与邮件接收引擎相比，DKIM的使用可能允许更丰富的过滤模型。
Note that the realities of today's public Internet Mail environment necessitate having a baseline handling model that is quite suspicious. Hence, "strong" filtering rules really are the starting point, as indicated for the UNKNOWN cell.
请注意，当今公共互联网邮件环境的现实需要有一个非常可疑的基线处理模型。因此，“强”过滤规则实际上是一个起点，如未知单元格所示。
The table indicates differential handling for each combination, such as how aggressive or broad-based the filtering could be. Aggressiveness affects the types of incorrect assessments that are likely. So, the table distinguishes various characteristics, including: 1) whether an organization is unknown, known to be good actors, or known to be bad actors; and 2) the assessment of messages. It includes advice about the degree of filtering that might be done, and other message disposition. Perhaps unexpectedly, it also lists a case in which the receiving site might wish to deliver problematic mail, rather than redirecting or deleting it. The site might also wish to contact the signing organization and seek resolution of the problem.
该表显示了每种组合的不同处理方式，例如过滤的积极性或广泛性。攻击性会影响可能出现的错误评估类型。因此，该表区分了各种特征，包括：1）一个组织是未知的、已知是好的参与者还是已知是坏的参与者；2）信息评估。它包括关于可能进行的过滤程度的建议，以及其他消息处理。可能出乎意料的是，它还列出了接收站点可能希望发送有问题的邮件，而不是重定向或删除邮件的情况。网站可能还希望与签署组织联系，寻求问题的解决方案。
+-------------+-----------------------------------------------+
| S T R E A M * O R G A N I Z A T I O N A L T R U S T |
| R I S K * Low Medium High |
| +***************+***************+***************+
| Low * BENIGN: | DILIGENT: | PRISTINE |
| * Moderate | Mild | Accept |
| * filter | filter | |
| +---------------+---------------+---------------+
| Medium * UNKNOWN: | TYPICAL: | PROTECTED: |
| * Strong | Targeted | Accept & |
| * filter | filter | Contact |
| +---------------+---------------+---------------+
| High * MALICIOUS: | NEGLIGENT: | COMPROMISED: |
| * Block & | Block | Block & |
| * Counter | | Contact |
+-------------+---------------+---------------+---------------+
+-------------+-----------------------------------------------+
| S T R E A M * O R G A N I Z A T I O N A L T R U S T |
| R I S K * Low Medium High |
| +***************+***************+***************+
| Low * BENIGN: | DILIGENT: | PRISTINE |
| * Moderate | Mild | Accept |
| * filter | filter | |
| +---------------+---------------+---------------+
| Medium * UNKNOWN: | TYPICAL: | PROTECTED: |
| * Strong | Targeted | Accept & |
| * filter | filter | Contact |
| +---------------+---------------+---------------+
| High * MALICIOUS: | NEGLIGENT: | COMPROMISED: |
| * Block & | Block | Block & |
| * Counter | | Contact |
+-------------+---------------+---------------+---------------+
Figure 2: Trust versus Risk Handling Tradeoffs Example
图2：信任与风险处理权衡示例
[LEGEND]
[图例]
AXES
斧头
Stream Risk: This is a measure of the recent history of a message stream and the severity of problems it has presented.
流风险：这是对消息流的最近历史以及它所呈现问题的严重性的度量。
Organizational Trust: This combines longer-term history about possible stream problems from that organization, and its responsiveness to problem handling.
组织信任：这结合了该组织可能出现的流问题的长期历史，以及它对问题处理的响应能力。
CELLS (indicating reasonable responses)
单元格（表示合理的响应）
Labels for the cells are meant as a general assessment of an organization producing that type of mail stream under that circumstance.
单元格的标签意味着对在这种情况下生成该类型邮件流的组织的一般评估。
Benign: There is some history of sending good messages, with very few harmful messages having been received. This stream warrants filtering that does not search for problems very aggressively, in order to reduce the likelihood of false positives.
良性：有一些发送好消息的历史，很少收到有害消息。该流保证了过滤不会非常积极地搜索问题，以降低误报的可能性。
Diligent: The stream has had a limited degree of problems and the organization is consistently successful at controlling their abuse issues and in a timely manner.
勤奋：该流存在一定程度的问题，该组织始终成功地及时控制其滥用问题。
Pristine: There is a history of a clean message stream with no problems, from an organization with an excellent reputation. So, the filter primarily needs to ensure that messages are delivered; catching stray problem messages is a lesser concern. In other words, the paramount concern, here, is false positives.
质朴的：有一个干净的消息流的历史，没有任何问题，来自一个拥有良好声誉的组织。因此，过滤器主要需要确保传递消息；捕获错误的问题消息是一个次要的问题。换句话说，这里最重要的关注点是误报。
-----
-----
Unknown: There is no history with the organization. Apply an aggressive level of "naive" filtering, given the nature of the public email environment.
未知：该组织没有历史记录。考虑到公共电子邮件环境的性质，应用积极的“幼稚”过滤级别。
Typical: The stream suffers significant abuse issues and the organization has demonstrated a record of having difficulties resolving them in a timely manner, in spite of legitimate efforts. Unfortunately, this is the typical case for service providers with an easy and open subscription policy.
典型：该流存在严重的滥用问题，该组织有记录表明，尽管做出了合理的努力，但仍难以及时解决这些问题。不幸的是，这是具有简单开放订阅策略的服务提供商的典型情况。
Protected: An organization with a good history and/or providing an important message stream for the receiving site is subject to a local policy that messages are not allowed to be blocked, but the stream is producing a problematic stream. The receiver delivers messages, but works quickly with the organization to resolve the matter.
受保护：具有良好历史记录和/或为接收站点提供重要消息流的组织受本地策略的约束，即不允许阻止消息，但该消息流产生问题流。接收者传递消息，但迅速与组织合作解决问题。
-----
-----
Malicious: A persistently problematic message stream is coming from an organization that appears to contribute to the problem. The stream will be blocked, but the organization's role is sufficiently troubling to warrant following up with others in the anti-abuse or legal communities, to constrain or end their impact.
恶意：持续出现问题的消息流来自似乎是问题原因的组织。该流将被阻断，但该组织的角色足够麻烦，需要与反虐待或法律界的其他人跟进，以限制或结束其影响。
Negligent: A persistently problematic message stream is coming from an organization that does not appear to be contributing to the problem, but also does not appear to be working to eliminate it. At the least, the stream needs to be blocked.
疏忽：一个持续存在问题的消息流来自一个组织，该组织似乎没有造成问题，但似乎也没有努力消除问题。至少，流需要被阻塞。
Compromised: An organization with a good history has a stream that changes and becomes too problematic to be delivered. The receiver blocks the stream and works quickly with the organization to resolve the matter.
妥协：一个拥有良好历史的组织有一个不断变化的流程，并且变得太麻烦而无法交付。接收者阻塞流，并与组织快速合作解决问题。
By itself, verification of a digital signature only allows the verifier to conclude with a very high degree of certainty that the signature was created by a party with access to the corresponding private signing key. It follows that a verifier requires means to (1) obtain the public key for the purpose of verification and (2) infer useful attributes of the key holder.
就其本身而言，数字签名的验证仅允许验证者以非常高的确定度得出结论，即签名是由能够访问相应的私人签名密钥的一方创建的。因此，验证者需要（1）为了验证的目的获取公钥和（2）推断密钥持有者的有用属性的方法。
In a traditional Public Key Infrastructure (PKI), the functions of key distribution and key accreditation are separated. In DKIM [RFC4871], these functions are both performed through the DNS.
在传统的公钥基础设施（PKI）中，密钥分发和密钥认证的功能是分离的。在DKIM[RFC4871]中，这些功能都是通过DNS执行的。
In either case, the ability to infer semantics from a digital signature depends on the assumption that the corresponding private key is only accessible to a party with a particular set of attributes. In a traditional PKI, a Trusted Third Party (TTP) vouches that the key holder has been validated with respect to a specified set of attributes. The range of attributes that can be attested in such a scheme is thus limited only to the type of attributes that a TTP can establish effective processes for validating. In DKIM, TTPs are not employed and the functions of key distribution and accreditation are combined.
在这两种情况下，从数字签名推断语义的能力取决于这样一种假设，即相应的私钥只能由具有特定属性集的一方访问。在传统的PKI中，受信任的第三方（TTP）保证密钥持有者已经根据指定的属性集进行了验证。因此，在这种方案中可以证明的属性范围仅限于TTP可以建立有效的验证过程的属性类型。在DKIM中，不使用TTP，而是将密钥分发和认证功能结合起来。
Consequently, there are only two types of inference that a signer can make from a key published in a DKIM key record:
因此，签名者只能从DKIM密钥记录中发布的密钥进行两种类型的推断：
1. That a party with the ability to control DNS records within a DNS zone intends to claim responsibility for messages signed using the corresponding private signature key.
1. 有能力控制DNS区域内DNS记录的一方打算声明对使用相应私有签名密钥签名的消息负责。
2. That use of a specific key is restricted to the particular subset of messages identified by the selector.
2. 特定键的使用仅限于选择器标识的消息的特定子集。
The ability to draw any useful conclusion from verification of a digital signature relies on the assumption that the corresponding private key is only accessible to a party with a particular set of
从数字签名的验证中得出任何有用结论的能力取决于这样一种假设，即相应的私钥仅可由具有特定密钥集的一方访问
attributes. In the case of DKIM, this means that the party that created the corresponding DKIM key record in the specific zone intended to claim responsibility for the signed message.
属性。在DKIM的情况下，这意味着在特定区域中创建相应DKIM密钥记录的一方打算声明对已签名消息的责任。
Ideally, we would like to draw a stronger conclusion, that if we obtain a DKIM key record from the DNS zone example.com, that the legitimate holder of the DNS zone example.com claims responsibility for the signed message. In order for this conclusion to be drawn, it is necessary for the verifier to assume that the operational security of the DNS zone and corresponding private key are adequate.
理想情况下，我们希望得出一个更有力的结论，即如果我们从DNS zone example.com获得DKIM密钥记录，则DNS zone example.com的合法持有人声称对签名消息负责。为了得出这一结论，验证者必须假设DNS区域的操作安全性和相应的私钥是足够的。
Access to signing keys needs to be carefully managed to prevent use by unauthorized parties and to minimize the consequences if a compromise were to occur.
需要仔细管理对签名密钥的访问，以防止未经授权的各方使用，并在发生泄露时将后果降至最低。
While a DKIM signing key is used to sign messages on behalf of many mail users, the signing key itself needs to be under direct control of as few key holders as possible. If a key holder were to leave the organization, all signing keys held by that key holder need to be withdrawn from service and, if appropriate, replaced.
虽然DKIM签名密钥用于代表许多邮件用户对邮件进行签名，但签名密钥本身需要由尽可能少的密钥持有者直接控制。如果密钥持有人要离开组织，则该密钥持有人持有的所有签名密钥都需要退出服务，并在适当情况下予以更换。
If key management hardware support is available, it needs to be used. If keys are stored in software, appropriate file control protections need to be employed, and any location in which the private key is stored in plaintext form needs to be excluded from regular backup processes and is best not accessible through any form of network including private local area networks. Auditing software needs to be used periodically to verify that the permissions on the private key files remain secure.
如果密钥管理硬件支持可用，则需要使用它。如果密钥存储在软件中，则需要采用适当的文件控制保护，并且需要将以明文形式存储私钥的任何位置排除在常规备份过程之外，并且最好不要通过任何形式的网络（包括专用局域网）进行访问。需要定期使用审核软件来验证私钥文件的权限是否保持安全。
Wherever possible, a signature key needs to exist in exactly one location and be erased when no longer used. Ideally, a signature key pair needs to be generated as close to the signing point as possible, and only the public key component transferred to another party. If this is not possible, the private key needs to be transported in an encrypted format that protects the confidentiality of the signing key. A shared directory on a local file system does not provide adequate security for distribution of signing keys in plaintext form.
在可能的情况下，签名密钥需要恰好存在于一个位置，并且在不再使用时被擦除。理想情况下，需要在尽可能靠近签名点的位置生成签名密钥对，并且仅将公钥组件传输给另一方。如果不可能，则需要以加密格式传输私钥，以保护签名密钥的机密性。本地文件系统上的共享目录不能为以明文形式分发签名密钥提供足够的安全性。
Key escrow schemes are not necessary and are best not used. In the unlikely event of a signing key becoming lost, a new signature key pair can be generated as easily as recovery from a key escrow scheme.
密钥托管方案不是必需的，最好不要使用。在签名密钥丢失的不太可能的情况下，可以像从密钥托管方案中恢复一样轻松地生成新的签名密钥对。
To enable accountability and auditing:
为了实现问责制和审计：
o Responsibility for the security of a signing key needs to ultimately vest in a single named individual.
o 签名密钥的安全责任最终需要归属于一个指定的个人。
o Where multiple parties are authorized to sign messages, each signer needs to use a different key to enable accountability and auditing.
o 如果授权多方对消息进行签名，则每个签名者需要使用不同的密钥来启用责任和审核。
Best practices for management of cryptographic keying material require keying material to be refreshed at regular intervals, particularly where key management is achieved through software. While this practice is highly desirable, it is of considerably less importance than the requirement to maintain the secrecy of the corresponding private key. An operational practice in which the private key is stored in tamper-proof hardware and changed once a year is considerably more desirable than one in which the signature key is changed on an hourly basis but maintained in software.
管理加密密钥材料的最佳实践要求定期刷新密钥材料，特别是在通过软件实现密钥管理的情况下。虽然这种做法非常可取，但其重要性远远低于保持相应私钥的保密性的要求。将私钥存储在防篡改硬件中并每年更改一次的操作实践比每小时更改签名密钥但在软件中维护的操作实践更可取。
In order to use DKIM, a DNS domain holder requires (1) the ability to create the necessary DKIM DNS records and (2) sufficient operational security controls to prevent insertion of spurious DNS records by an attacker.
为了使用DKIM，DNS域持有者需要（1）能够创建必要的DKIM DNS记录，以及（2）足够的操作安全控制，以防止攻击者插入虚假DNS记录。
DNS record management is often operated by an administrative staff that is different from those who operate an organization's email service. In order to ensure that DKIM DNS records are accurate, this imposes a requirement for careful coordination between the two operations groups. If the best practices for private key management described above are observed, such deployment is not a one-time event; DNS DKIM selectors will be changed over time as signing keys are terminated and replaced.
DNS记录管理通常由不同于运营组织电子邮件服务的管理人员进行。为了确保DKIM DNS记录准确，这就要求两个操作组之间进行仔细协调。如果遵守上述私钥管理的最佳实践，则此类部署不是一次性事件；随着签名密钥的终止和替换，DNS DKIM选择器将随着时间的推移而更改。
At a minimum, a DNS server that handles queries for DKIM key records needs to allow the server administrators to add free-form TXT records. It would be better if the DKIM records could be entered using a structured form, supporting the DKIM-specific fields.
至少，处理DKIM密钥记录查询的DNS服务器需要允许服务器管理员添加自由格式的TXT记录。最好使用结构化表单输入DKIM记录，支持DKIM特定字段。
Ideally, DNS Security (DNSSEC) [RFC4034] needs to be employed in a configuration that provides protection against record insertion attacks and zone enumeration. In the case that NextSECure version 3 (NSEC3) [RFC5155] records are employed to prevent insertion attack, the OPT-OUT flag needs to be clear. (See [RFC5155] section 6 for details.)
理想情况下，DNS安全性（DNSSEC）[RFC4034]需要在提供记录插入攻击和区域枚举保护的配置中使用。如果使用NextSECure版本3（NSEC3）[RFC5155]记录来防止插入攻击，则需要清除选择退出标志。（详见[RFC5155]第6节。）
Selectors are assigned according to the administrative needs of the signing domain, such as for rolling over to a new key or for the delegation of the right to authenticate a portion of the namespace to a TTP. Examples include:
选择器是根据签名域的管理需要分配的，例如用于滚动到新密钥或用于将命名空间的一部分进行身份验证的权利委托给TTP。例子包括：
jun2005.eng._domainkey.example.com
2005年6月。eng.\u domainkey.example.com
widget.promotion._domainkey.example.com
widget.promotion.\u domainkey.example.com
It is intended that assessments of DKIM identities be based on the domain name, and not include the selector. While past practice of a signer can permit a verifier to infer additional properties of particular messages from the structure DKIM key selector, unannounced administrative changes such as a change of signing software can cause such heuristics to fail at any time.
DKIM身份评估的目的是基于域名，而不包括选择器。虽然签名者的过去实践可允许验证者从结构DKIM密钥选择器推断特定消息的附加属性，但未经宣布的管理更改（例如签名软件的更改）可导致此类启发式在任何时候失败。
While a signer can establish business rules, such as the issue of individual signature keys for each end-user, DKIM makes no provision for communicating these to other parties. Out-of-band distribution of such business rules is outside the scope of DKIM. Consequently, there is no means by which external parties can make use of such keys to attribute messages with any greater granularity than a DNS domain.
虽然签名者可以建立业务规则，例如为每个最终用户颁发个人签名密钥，但DKIM没有规定将这些规则传达给其他方。此类业务规则的带外分发不在DKIM的范围内。因此，外部方无法使用这些密钥来对消息进行比DNS域更大粒度的属性化。
If per-user signing keys are assigned for internal purposes (e.g., authenticating messages sent to an MTA (Mail Transfer Agent) for distribution), the following issues need to be considered before using such signatures as an alternative to traditional edge signing at the outbound MTA:
如果为内部目的（例如，验证发送到MTA（邮件传输代理）进行分发的邮件）分配了每用户签名密钥，则在使用此类签名作为出站MTA传统边缘签名的替代方案之前，需要考虑以下问题：
External verifiers will be unable to make use of the additional signature granularity without access to additional information passed out of band with respect to [RFC4871].
外部验证器将无法使用额外的签名粒度，而无法访问关于[RFC4871]的带外传递的额外信息。
If the number of user keys is large, the efficiency of local caching of key records by verifiers will be lower.
如果用户密钥的数量较大，则验证器本地缓存密钥记录的效率将较低。
A large number of end users is be less likely to do an adequate job of managing private key data securely on their personal computers than is an administrator running an edge MTA.
与运行edge MTA的管理员相比，大量最终用户不太可能在其个人计算机上安全地管理私钥数据。
A DKIM key record only asserts that the holder of the corresponding domain name makes a claim of responsibility for messages signed under the corresponding key. In some applications, such as bulk mail delivery, it is desirable to delegate use of the key. That is, to allow a third party to sign on behalf of the domain holder. The trust relationship is still established between the domain holder and the verifier, but the private signature key is held by a third party.
DKIM密钥记录仅声明相应域名的持有人对在相应密钥下签名的消息提出责任声明。在某些应用程序中，如批量邮件传递，需要委托密钥的使用。也就是说，允许第三方代表域持有人签名。域持有者和验证者之间仍然建立信任关系，但私有签名密钥由第三方持有。
Signature keys used by a third-party signer need to be kept entirely separate from those used by the domain holder and other third-party signers. To limit potential exposure of the private key, the signature key pair needs to be generated by the third-party signer and the public component of the key transmitted to the domain holder, rather than have the domain holder generate the key pair and transmit the private component to the third-party signer.
第三方签名者使用的签名密钥需要与域持有人和其他第三方签名者使用的签名密钥完全分开。为了限制私钥的潜在公开，签名密钥对需要由第三方签名者和传输给域持有人的密钥的公共组件生成，而不是由域持有人生成密钥对并将私钥组件传输给第三方签名者。
Domain holders needs to adopt a least-privilege approach and grant third-party signers the minimum access necessary to perform the desired function. Limiting the access granted to third-party signers serves to protect the interests of both parties. The domain holder minimizes its security risk and the TTP signer avoids unnecessary liability.
域持有者需要采用最小特权方法，并授予第三方签名者执行所需功能所需的最小访问权限。限制授予第三方签名者的访问权有助于保护双方的利益。域持有人将其安全风险降至最低，TTP签名人避免不必要的责任。
In the most restrictive case, domain holders maintain full control over the creation of key records. They can employ appropriate key record restrictions to enforce limits on the messages for which the third-party signer is able to sign. If such restrictions are impractical, the domain holder needs to delegate a DNS subzone for publishing key records to the third-party signer. It is best that the domain holder NOT allow a third-party signer unrestricted access to its DNS service for the purpose of publishing key records.
在最严格的情况下，域持有者对关键记录的创建保持完全控制。他们可以使用适当的密钥记录限制来强制第三方签名者能够签名的消息的限制。如果此类限制不切实际，域持有人需要将发布密钥记录的DNS子区域委托给第三方签名者。域持有者最好不允许第三方签名者出于发布密钥记录的目的不受限制地访问其DNS服务。
Deployments need to establish, document, and observe processes for managing the entire life cycle of an asymmetric key pair.
部署需要建立、记录和观察管理非对称密钥对整个生命周期的过程。
When it is determined that a new key pair is required:
当确定需要新的密钥对时：
1. A Key Pair is generated by the signing device.
1. 签名设备生成密钥对。
2. A proposed key selector record is generated and transmitted to the DNS administration infrastructure.
2. 生成建议的密钥选择器记录并将其传输到DNS管理基础设施。
3. The DNS administration infrastructure verifies the authenticity of the key selector registration request. If accepted:
3. DNS管理基础结构验证密钥选择器注册请求的真实性。如果接受：
1. A key selector is assigned.
1. 将指定一个键选择器。
2. The corresponding key record is published in the DNS.
2. 相应的密钥记录在DNS中发布。
3. Wait for DNS updates to propagate (if necessary).
3. 等待DNS更新传播（如有必要）。
4. Report assigned key selector to signing device.
4. 将分配的密钥选择器报告给签名设备。
4. The signer verifies correct registration of the key record.
4. 签名者验证密钥记录的正确注册。
5. The signer begins generating signatures using the new key pair.
5. 签名者开始使用新密钥对生成签名。
6. The signer terminates any private keys that are no longer required due to issue of replacement.
6. 签名者终止由于替换问题而不再需要的任何私钥。
When it is determined that a private signature key is no longer required:
当确定不再需要私人签名密钥时：
1. The signer stops using the private key for signature operations.
1. 签名者停止使用私钥进行签名操作。
2. The signer deletes all records of the private key, including in-memory copies at the signing device.
2. 签名者删除私钥的所有记录，包括签名设备上的内存副本。
3. The signer notifies the DNS administration infrastructure that the signing key is withdrawn from service and that the corresponding key records can be withdrawn from service at a specified future date.
3. 签名者通知DNS管理基础结构签名密钥已从服务中撤回，并且相应的密钥记录可在指定的未来日期从服务中撤回。
4. The DNS administration infrastructure verifies the authenticity of the key selector termination request. If accepted,
4. DNS管理基础结构验证密钥选择器终止请求的真实性。如果接受，
1. The key selector is scheduled for deletion at a future time determined by site policy.
1. 密钥选择器计划在站点策略确定的未来时间删除。
2. Wait for deletion time to arrive.
2. 等待删除时间到达。
3. The signer either publishes a revocation key selector with an empty public-key data (p=) field, or deletes the key selector record entirely.
3. 签名者发布带有空公钥数据（p=）字段的吊销密钥选择器，或者完全删除密钥选择器记录。
5. As far as the verifier is concerned, there is no functional difference between verifying against a key selector with an empty p= field, and verifying against a missing key selector: both
5. 就验证器而言，针对具有空p=字段的键选择器进行验证与针对缺少的键选择器进行验证之间没有功能上的区别：两者都有
result in a failed signature and the signature needs to be treated as if it had not been there. However, there is a minor semantic difference: with the empty p= field, the signer is explicitly stating that the key has been revoked. The empty p= record provides a gravestone for an old selector, making it less likely that the selector might be accidentally reused with a different public key.
导致签名失败，需要将签名视为不存在。但是，有一个小小的语义差异：对于空的p=字段，签名者显式声明密钥已被撤销。空的p=记录为旧的选择器提供了墓碑，从而减少了使用其他公钥意外重用选择器的可能性。
Creating messages that have one or more DKIM signatures requires support in only two outbound email service components:
创建具有一个或多个DKIM签名的邮件只需要两个出站电子邮件服务组件的支持：
o A DNS Administrative interface that can create and maintain the relevant DNS names -- including names with underscores -- and resource records (RR).
o 可以创建和维护相关DNS名称（包括带下划线的名称）和资源记录（RR）的DNS管理接口。
o A trusted module, called the signing module, which is within the organization's outbound email handling service and which creates and adds the DKIM-Signature: header field(s) to the message.
o 一个受信任的模块，称为签名模块，位于组织的出站电子邮件处理服务中，创建DKIM签名：头字段并将其添加到邮件中。
If the module creates more than one signature, there needs to be the appropriate means of telling it which one(s) to use. If a large number of names are used for signing, it will help to have the administrative tool support a batch-processing mode.
如果模块创建了多个签名，则需要有适当的方法告诉模块使用哪个签名。如果大量名称用于签名，那么让管理工具支持批处理模式将有所帮助。
A receiver attempting to verify a DKIM signature obtains the public key that is associated with the signature for that message. The DKIM-Signature: header in the message contains the d= tag with the basic domain name doing the signing and serving as output to the Identity Assessor and the s= tag with the selector that is added to the name, for finding the specific public key. Hence, the relevant <selector>._domainkey.<domain-name> DNS record needs to contain a DKIM-related RR that provides the public key information.
试图验证DKIM签名的接收方获得与该消息的签名相关联的公钥。消息中的DKIM Signature:header包含进行签名并作为身份评估器输出的基本域名的d=标记和添加到名称中的选择器的s=标记，用于查找特定公钥。因此，相关的<selector>\u domainkey.<domain name>DNS记录需要包含提供公钥信息的DKIM相关RR。
The administrator of the zone containing the relevant domain name adds this information. Initial DKIM DNS information is contained within TXT RRs. DNS administrative software varies considerably in its abilities to support DKIM names, such as with underscores, and to add new types of DNS information.
包含相关域名的区域的管理员将添加此信息。初始DKIM DNS信息包含在TXT RRs中。DNS管理软件在支持DKIM名称（如带下划线）和添加新类型DNS信息的能力方面差异很大。
The module doing signing can be placed anywhere within an organization's trusted Administrative Management Domain (ADMD); obvious choices include department-level posting agents, as well as
进行签名的模块可以放置在组织的受信任管理域（ADMD）中的任何位置；明显的选择包括部门级的发布代理，以及
outbound boundary MTAs to the open Internet. However, any other module, including the author's MUA (Mail User Agent), is potentially acceptable, as long as the signature survives any remaining handling within the ADMD. Hence, the choice among the modules depends upon software development, administrative overhead, security exposures, and transit-handling tradeoffs. One perspective that helps to resolve this choice is the difference between the increased flexibility, from placement at (or close to) the MUA, versus the streamlined administration and operation that is more easily obtained by implementing the mechanism "deeper" into the organization's email infrastructure, such as at its boundary MTA.
到开放Internet的出站边界MTA。但是，任何其他模块，包括作者的MUA（邮件用户代理），只要签名在ADMD中的任何剩余处理中仍然存在，都可能是可以接受的。因此，模块之间的选择取决于软件开发、管理开销、安全风险和运输处理权衡。有助于解决这一选择的一个角度是，在MUA（或靠近MUA）的位置增加灵活性，与通过在组织的电子邮件基础设施（如其边界MTA）中“深入”实施机制更容易获得的简化管理和操作之间的差异。
Note the discussion in Section 2.2 concerning the use of the i= tag.
注意第2.2节中关于i=标签使用的讨论。
The signing module uses the appropriate private key to create one or more signatures. (See Section 6.5 for a discussion of multiple signatures.) The means by which the signing module obtains the private key(s) is not specified by DKIM. Given that DKIM is intended for use during email transit, rather than for long-term storage, it is expected that keys will be changed regularly. For administrative convenience, it is best not to hard-code key information into software.
签名模块使用适当的私钥创建一个或多个签名。（有关多重签名的讨论，请参见第6.5节。）DKIM未指定签名模块获取私钥的方式。鉴于DKIM是在电子邮件传输过程中使用的，而不是用于长期存储，因此预计密钥将定期更换。为了便于管理，最好不要将关键信息硬编码到软件中。
Every organization (ADMD) will have its own policies and practices for deciding when to sign messages (message stream) and with what domain name, selector, and key. Examples of particular message streams include all mail sent from the ADMD versus mail from particular types of user accounts versus mail having particular types of content. Given this variability, and the likelihood that signing practices will change over time, it will be useful to have these decisions represented through run-time configuration information, rather than being hard-coded into the signing software.
每个组织（ADMD）都有自己的策略和实践来决定何时对消息（消息流）进行签名以及使用什么域名、选择器和密钥。特定消息流的示例包括从ADMD发送的所有邮件、来自特定类型用户帐户的邮件和具有特定类型内容的邮件。考虑到这种可变性以及签名实践随时间变化的可能性，通过运行时配置信息来表示这些决策将非常有用，而不是硬编码到签名软件中。
As noted in Section 2.3, the choice of signing name granularity requires balancing administrative convenience and utility for recipients. Too much granularity is higher administrative overhead and might well attempt to impose more differential analysis on the recipient than they wish to support. In such cases, they are likely to use only a super-name -- right-hand substring -- of the signing name. When this occurs, the signer will not know what portion is being used; this then moves DKIM back to the non-deterministic world of heuristics, rather than the mechanistic world of signer/recipient collaboration that DKIM seeks.
如第2.3节所述，签名名称粒度的选择需要平衡收件人的管理便利性和实用性。太多的粒度会带来更高的管理开销，很可能会试图对接收者施加比他们希望支持的更多的差异分析。在这种情况下，它们很可能只使用签名名的超级名称——右侧子字符串。当这种情况发生时，签名者将不知道正在使用哪一部分；这将使DKIM回到非确定性的启发式世界，而不是DKIM寻求的签名者/接收者协作的机械世界。
A message recipient can verify a DKIM signature to determine if a claim of responsibility has been made for the message by a trusted domain.
邮件收件人可以验证DKIM签名，以确定受信任域是否对邮件提出了责任声明。
Access control requires two components: authentication and authorization. By design, verification of a DKIM signature only provides the authentication component of an access control decision and needs to be combined with additional sources of information such as reputation data to arrive at an access control decision.
访问控制需要两个组件：身份验证和授权。通过设计，DKIM签名的验证仅提供访问控制决策的认证组件，并且需要与其他信息源（例如信誉数据）结合以达成访问控制决策。
DKIM requires that a message with a signature that is found to be invalid is to be treated as if the message had not been signed at all.
DKIM要求将签名无效的消息视为根本没有签名的消息。
If a DKIM signature fails to verify, it is entirely possible that the message is valid and that either there is a configuration error in the signer's system (e.g., a missing key record) or that the message was inadvertently modified in transit. It is thus undesirable for mail infrastructure to treat messages with invalid signatures less favorably than those with no signatures whatsoever. Contrariwise, creation of an invalid signature requires a trivial amount of effort on the part of an attacker. If messages with invalid signatures were to be treated preferentially to messages with no signatures whatsoever, attackers will simply add invalid signature blocks to gain the preferential treatment. It follows that messages with invalid signatures need to be treated no better and no worse than those with no signature at all.
如果DKIM签名无法验证，则完全有可能消息是有效的，并且签名者的系统中存在配置错误（例如，缺少密钥记录），或者消息在传输过程中被意外修改。因此，邮件基础设施不希望将带有无效签名的邮件与没有签名的邮件进行比较。相反，创建无效签名需要攻击者付出微不足道的努力。如果具有无效签名的消息优先于没有任何签名的消息，攻击者只需添加无效签名块即可获得优先处理。因此，具有无效签名的消息不需要比没有签名的消息更好也不需要更差。
As with any other digital signature scheme, verifiers need to consider only the part of the message that is inside the scope of the message as being authenticated by the signature.
与任何其他数字签名方案一样，验证者只需要考虑消息的范围内的消息的部分，即由签名进行身份验证。
For example, if the l= option is employed to specify a content length for the scope of the signature, only the part of the message that is within the scope of the content signature would be considered authentic.
例如，如果使用l=选项为签名范围指定内容长度，则只有在内容签名范围内的消息部分才被视为可信。
Public key cryptography provides an exceptionally high degree of assurance, bordering on absolute certainty, that the party that created a valid digital signature had access to the private key corresponding to the public key indicated in the signature.
公钥密码学提供了极高程度的保证，近乎绝对确定，即创建有效数字签名的一方可以访问与签名中所示公钥对应的私钥。
In order to make useful conclusions from the verification of a valid digital signature, the verifier is obliged to make assumptions that fall far short of absolute certainty. Consequently, mere validation of a DKIM signature does not represent proof positive that a valid claim of responsibility was made for it by the indicated party, that the message is authentic, or that the message is not abusive. In particular:
为了从有效数字签名的验证中得出有用的结论，验证者必须做出远低于绝对确定性的假设。因此，仅对DKIM签名进行验证并不能证明被指示方对该签名提出了有效的责任声明、该消息是真实的或该消息不是滥用的。特别地：
o The legitimate private key holder might have lost control of its private key.
o 合法私钥持有人可能已失去对其私钥的控制。
o The legitimate domain holder might have lost control of the DNS server for the zone from which the key record was retrieved.
o 合法域持有者可能已失去对从中检索密钥记录的区域的DNS服务器的控制。
o The key record might not have been delivered from the legitimate DNS server for the zone from which the key record was retrieved.
o 对于从中检索密钥记录的区域，密钥记录可能未从合法DNS服务器传递。
o Ownership of the DNS zone might have changed.
o DNS区域的所有权可能已更改。
In practice, these limitations have little or no impact on the field of use for which DKIM is designed, but they can have a bearing if use is made of the DKIM message signature format or key retrieval mechanism in other specifications.
实际上，这些限制对设计DKIM的使用领域几乎没有影响，但如果在其他规范中使用DKIM消息签名格式或密钥检索机制，这些限制可能会产生影响。
In particular, the DKIM key retrieval mechanism is designed for ease of use and deployment rather than to provide a high assurance Public Key Infrastructure suitable for purposes that require robust non-repudiation such as establishing legally binding contracts. Developers seeking to extend DKIM beyond its design application need to consider replacing or supplementing the DNS key retrieval mechanism with one that is designed to meet the intended purposes.
特别是，DKIM密钥检索机制的设计是为了易于使用和部署，而不是为了提供高保证的公钥基础设施，适用于需要强健的不可否认性的目的，例如建立具有法律约束力的合同。寻求将DKIM扩展到其设计应用程序之外的开发人员需要考虑替换或补充DNS密钥检索机制，该机制旨在满足预期的目的。
DKIM is frequently employed in a mail filtering strategy to avoid performing content analysis on email originating from trusted sources. Messages that carry a valid DKIM signature from a trusted source can be whitelisted, avoiding the need to perform computation and hence energy-intensive content analysis to determine the disposition of the message.
DKIM经常用于邮件过滤策略，以避免对来自可信来源的电子邮件执行内容分析。携带来自可信来源的有效DKIM签名的消息可以被列入白名单，从而避免了执行计算和能量密集型内容分析以确定消息的处置的需要。
Mail sources can be determined to be trusted by means of previously observed behavior and/or reference to external reputation or accreditation services. The precise means by which this is accomplished is outside the scope of DKIM.
通过先前观察到的行为和/或参考外部声誉或认证服务，可以确定邮件来源是可信的。实现这一点的精确方法不在DKIM的范围之内。
Adaptive (or learning) spam filtering mechanisms that are not capable of verifying DKIM signatures need to, at minimum, be configured to ignore DKIM header data entirely.
无法验证DKIM签名的自适应（或学习）垃圾邮件过滤机制至少需要配置为完全忽略DKIM头数据。
Intermediaries, such as mailing lists, pose a particular challenge for DKIM implementations, as the message processing steps performed by the intermediary can cause the message content to change in ways that prevent the signature passing verification.
邮件列表等中介体对DKIM实现提出了特殊的挑战，因为中介体执行的消息处理步骤可能导致消息内容发生变化，从而阻止签名通过验证。
Such intermediaries are strongly encouraged to deploy DKIM signing so that a verifiable claim of responsibility remains available to parties attempting to verify the modified message.
强烈鼓励此类中介机构部署DKIM签名，以便尝试验证修改后的消息的各方仍然可以使用可验证的责任声明。
In many deployments, it is desirable to separate signature verification from the application relying on the verification. A system can choose to relay information indicating the results of its message authentication efforts using various means; adding a "results header" to the message is one such mechanism [RFC5451]. For example, consider the cases where:
在许多部署中，希望将签名验证与依赖验证的应用程序分开。系统可以选择使用各种方式中继指示其消息认证工作结果的信息；向消息添加“结果头”就是这样一种机制[RFC5451]。例如，考虑以下情况：
o The application relying on DKIM signature verification is not capable of performing the verification.
o 依赖DKIM签名验证的应用程序无法执行验证。
o The message can be modified after the signature verification is performed.
o 执行签名验证后，可以修改消息。
o The signature key cannot be available by the time that the message is read.
o 在读取邮件时，签名密钥无法使用。
In such cases, it is important that the communication link between the signature verifier and the relying application be sufficiently secure to prevent insertion of a message that carries a bogus results header.
在这种情况下，签名验证器和依赖应用程序之间的通信链路必须足够安全，以防止插入携带虚假结果报头的消息。
An intermediary that generates results headers need to ensure that relying applications are able to distinguish valid results headers issued by the intermediary from those introduced by an attacker. For
生成结果头的中介体需要确保依赖的应用程序能够区分中介体发布的有效结果头和攻击者引入的结果头。对于
example, this can be accomplished by signing the results header. At a minimum, results headers on incoming messages need to be removed if they purport to have been issued by the intermediary but cannot be verified as authentic.
例如，这可以通过对结果标题进行签名来实现。至少，如果传入消息的结果头声称是由中介发布的，但无法验证其真实性，则需要删除这些消息的结果头。
Further discussion on trusting the results as relayed from a verifier to something downstream can be found in [RFC5451].
关于信任从验证器转发到下游某物的结果的进一步讨论，请参见[RFC5451]。
As described in Section 2.1, a DKIM signature tells the signature verifier that the owner of a particular domain name accepts some responsibility for the message. It does not, in and of itself, provide any information about the trustworthiness or behavior of that identity. What it does provide is a verified identity to which such behavioral information can be associated, so that those who collect and use such information can be assured that it truly pertains to the identity in question.
如第2.1节所述，DKIM签名告诉签名验证者特定域名的所有者对消息承担一定责任。它本身并没有提供关于该身份的可信度或行为的任何信息。它提供的是一个经过验证的身份，这些行为信息可以与之关联，这样收集和使用这些信息的人就可以确信这些信息确实与所讨论的身份有关。
This section lays out a taxonomy of some of the different identities, or combinations of identities, that might usefully be represented by a DKIM signature.
本节列出了一些不同身份或身份组合的分类，这些身份可能有用地由DKIM签名表示。
Perhaps the simplest case is when an organization signs its own outbound email using its own domain in the SDID [RFC5672] of the signature. For example, Company A would sign the outbound mail from its employees with d=companyA.example.
也许最简单的情况是当一个组织在签名的SDID[RFC5672]中使用自己的域对自己的出站电子邮件进行签名时。例如，A公司将用d=companyA.example对其员工的出站邮件进行签名。
In the most straightforward configuration, the addresses in the RFC5322.From field would also be in the companyA.example domain, but that direct correlation is not required.
在最简单的配置中，RFC5322.From字段中的地址也将位于companyA.example域中，但不需要直接关联。
A special case of the single domain signature is an author signature as defined by the Author Domain Signing Practices specification [RFC5617]. Author signatures are signatures from an author's organization that have an SDID value that matches that of an RFC5322.From address of the signed message.
单域签名的一个特例是作者签名，由作者域签名实践规范[RFC5617]定义。作者签名是来自作者组织的签名，其SDID值与RFC5322的SDID值相匹配。来自签名邮件的地址。
Although an author signature might, in some cases, be proof against spoofing the domain name of the RFC5322.From address, it is important to note that the DKIM and ADSP validation apply only to the exact address string and not to look-alike addresses or to the human-friendly "display-name" or names and addresses used within the body of the message. That is, it only protects against the misuse of a precise address string within the RFC5322.From field and nothing else. For example, a message from bob@domain.example with a valid
尽管在某些情况下，作者签名可能是防止欺骗RFC5322.From地址域名的证据，但需要注意的是，DKIM和ADSP验证仅适用于确切的地址字符串，而不适用于看起来相似的地址或人性化的“显示名”或邮件正文中使用的名称和地址。也就是说，它只保护RFC5322.From字段中的精确地址字符串不被误用，而不保护其他内容。例如，来自bob@domain.example用有效的
signature where d=d0main.example would fail an ADSP check because the signature domain, however similar, is distinct; however, a message from bob@d0main.example with a valid signature where d=d0main.example would pass an ADSP check, even though to a human it might be obvious that d0main.example is likely a malicious attempt to spoof the domain domain.example. This example highlights that ADSP, like DKIM, is only able to validate a signing identifier: it still requires some external process to attach a meaningful reputation to that identifier.
签名，其中d=d0main.example将使ADSP检查失败，因为签名域无论多么相似，都是不同的；然而，来自bob@d0main.example使用有效签名，其中d=d0main.example将通过ADSP检查，即使对于人来说，d0main.example很可能是恶意欺骗domain.example的尝试。这个例子强调了ADSP和DKIM一样，只能验证签名标识符：它仍然需要一些外部过程来将有意义的信誉附加到该标识符上。
Another approach that might be taken by an organization with multiple active subdomains is to apply the same (single) signature domain to mail from all subdomains. In this case, the signature chosen would usually be the signature of a parent domain common to all subdomains. For example, mail from marketing.domain.example, sales.domain.example, and engineering.domain.example might all use a signature where d=domain.example.
具有多个活动子域的组织可能采取的另一种方法是对来自所有子域的邮件应用相同（单个）签名域。在这种情况下，选择的签名通常是所有子域共用的父域的签名。例如，来自marketing.domain.example、sales.domain.example和engineering.domain.example的邮件都可能使用签名，其中d=domain.example。
This approach has the virtue of simplicity, but it is important to consider the implications of such a choice. As discussed in Section 2.3, if the type of mail sent from the different subdomains is significantly different or if there is reason to believe that the reputation of the subdomains would differ, then it can be a good idea to acknowledge this and provide distinct signatures for each of the subdomains (d=marketing.domain.example, sales.domain.example, etc.). However, if the mail and reputations are likely to be similar, then the simpler approach of using a single common parent domain in the signature can work well.
这种方法具有简单性的优点，但重要的是要考虑这样的选择的含义。如第2.3节所述，如果从不同子域发送的邮件类型明显不同，或者如果有理由相信子域的信誉会有所不同，那么最好承认这一点，并为每个子域提供不同的签名（d=marketing.domain.example、sales.domain.example等）。但是，如果邮件和声誉可能相似，那么在签名中使用单个公共父域的更简单方法可以很好地工作。
Another approach to distinguishing the streams using a single DKIM key would be to leverage the AUID [RFC5672] (i= tag) in the DKIM signature to differentiate the mail streams. For example, marketing email would be signed with i=@marketing.domain.example and d=domain.example.
使用单个DKIM密钥区分流的另一种方法是利用DKIM签名中的AUID[RFC5672]（i=tag）来区分邮件流。例如，营销电子邮件将使用i=@marketing.domain.example和d=domain.example进行签名。
It's important to remember, however, that under core DKIM semantics, the AUID is opaque to receivers. That means that it will only be an effective differentiator if there is an out-of-band agreement about the i= semantics.
然而，重要的是要记住，在核心DKIM语义下，AUID对接收者是不透明的。这意味着，只有在i=语义方面存在带外协议时，它才是一个有效的区别。
A signature whose domain does not match the domain of the RFC5322.From address is sometimes referred to as a third-party signature. In certain cases, even the parent domain signature
域与RFC5322的域不匹配的签名。发件人地址有时称为第三方签名。在某些情况下，甚至父域签名
described above would be considered a third-party signature because it would not be an exact match for the domain in the RFC5322.From address.
上述内容将被视为第三方签名，因为它与RFC5322.From地址中的域不完全匹配。
Although there is often heated debate about the value of third party signatures, it is important to note that the DKIM specification attaches no particular significance to the identity in a DKIM signature ([RFC4871], [RFC5672]). The identity specified within the signature is the identity that is taking responsibility for the message, and it is only the interpretation of a given receiver that gives one identity more or less significance than another. In particular, most independent reputation services assign trust based on the specific identifier string, not its "role": in general they make no distinction between, for example, an author signature and a third-party signature.
尽管关于第三方签名的价值经常存在激烈的争论，但需要注意的是，DKIM规范对DKIM签名中的身份没有特别的意义（[RFC4871]，[RFC5672]）。签名中指定的身份是对消息负责的身份，只有对给定接收者的解释才能使一个身份比另一个身份具有或多或少的重要性。特别是，大多数独立的信誉服务基于特定的标识符字符串而不是其“角色”分配信任：通常，它们不区分作者签名和第三方签名。
For some, a signature unrelated to the author domain (the domain in the RFC5322.From address) is less valuable because there is an assumption that the presence of an author signature guarantees that the use of the address in the RFC5322.From header is authorized.
对于某些人来说，与作者域（RFC5322.From地址中的域）无关的签名价值较低，因为存在作者签名可以保证RFC5322.From头中地址的使用得到授权。
For others, that relevance is tied strictly to the recorded behavioral data assigned to the identity in question, i.e., its trust assessment or reputation. The reasoning here is that an identity with a good reputation is unlikely to maintain that good reputation if it is in the habit of vouching for messages that are unwanted or abusive; in fact, doing so will rapidly degrade its reputation so that future messages will no longer benefit from it. It is therefore low risk to facilitate the delivery of messages that contain a valid signature of a domain with a strong positive reputation, independent of whether or not that domain is associated with the address in the RFC5322.From header field of the message.
对于其他人来说，这种相关性严格地与指定给相关身份的记录行为数据相关联，即其信任评估或声誉。这里的理由是，如果一个具有良好声誉的身份习惯于为不需要的或滥用的信息提供担保，那么它就不可能保持良好的声誉；事实上，这样做将迅速降低其声誉，使未来的消息不再从中受益。因此，无论域是否与消息的RFC5322.From标头字段中的地址关联，促进包含具有强正向声誉的域的有效签名的消息的传递的风险较低。
Third-party signatures encompass a wide range of identities. Some of the more common are:
第三方签名包含广泛的身份。更常见的有：
Service Provider: In cases where email is outsourced to an Email Service Provider (ESP), Internet Service Provider (ISP), or other type of service provider, that service provider can choose to DKIM-sign outbound mail with either its own identifier -- relying on its own, aggregate reputation -- or with a subdomain of the provider that is unique to the message author but still part of the provider's aggregate reputation. Such service providers can also encompass delegated business functions such as benefit management, although these will more often be treated as trusted third-party senders (see below).
服务提供商：如果电子邮件外包给电子邮件服务提供商（ESP）、互联网服务提供商（ISP）或其他类型的服务提供商，则该服务提供商可以选择使用自己的标识符（依靠自己的标识符）签署出站邮件，聚合信誉——或与提供程序的子域一起使用，该子域对于消息作者是唯一的，但仍然是提供程序聚合信誉的一部分。此类服务提供商还可以包含委托的业务职能，如福利管理，尽管这些职能通常被视为受信任的第三方发件人（见下文）。
Parent Domain: As discussed above, organizations choosing to apply a parent-domain signature to mail originating from subdomains can have their signatures treated as third party by some verifiers, depending on whether or not the "t=s" tag is used to constrain the parent signature to apply only to its own specific domain. The default is to consider a parent-domain signature valid for its subdomains.
父域：如上所述，选择将父域签名应用于源于子域的邮件的组织可以由一些验证器将其签名视为第三方，这取决于是否使用“t=s”标记来约束父签名仅应用于其自己的特定域。默认值是考虑父域签名对其子域有效。
Reputation Provider: Another possible category of third-party signature would be the identity of a third-party reputation provider. Such a signature would indicate to receivers that the message was being vouched for by that third party.
声誉提供者：第三方签名的另一个可能类别是第三方声誉提供者的身份。这种签名将向接收者表明，该电文是由该第三方担保的。
For most of the cases described so far, there has been an assumption that the signing agent was responsible for creating and maintaining its own DKIM signing infrastructure, including its own keys, and signing with its own identity.
对于迄今为止描述的大多数情况，假设签名代理负责创建和维护自己的DKIM签名基础设施，包括自己的密钥，并使用自己的身份进行签名。
A different model arises when an organization uses a trusted third-party sender for certain key business functions, but still wants that email to benefit from the organization's own identity and reputation. In other words, the mail would come out of the trusted third party's mail servers, but the signature applied would be that of the controlling organization.
当组织使用可信的第三方发件人执行某些关键业务功能，但仍希望该电子邮件受益于组织自身的身份和声誉时，就会出现另一种模式。换句话说，邮件将来自受信任的第三方的邮件服务器，但应用的签名将是控制组织的签名。
This can be done by having the third party generate a key pair that is designated uniquely for use by that trusted third party and publishing the public key in the controlling organization's DNS domain, thus enabling the third party to sign mail using the signature of the controlling organization. For example, if Company A outsources its employee benefits to a third party, it can use a special key pair that enables the benefits company to sign mail as "companyA.example". Because the key pair is unique to that trusted third party, it is easy for Company A to revoke the authorization if necessary by simply removing the public key from the companyA.example DNS.
这可以通过让第三方生成唯一指定供该可信第三方使用的密钥对，并在控制组织的DNS域中发布公钥来实现，从而使第三方能够使用控制组织的签名对邮件进行签名。例如，如果A公司将其员工福利外包给第三方，它可以使用一个特殊的密钥对，使福利公司能够将邮件签名为“companyA.example”。由于密钥对是受信任的第三方所独有的，因此公司A很容易在必要时通过从companyA.example DNS中删除公钥来撤销授权。
A more cautious approach would be to create a dedicated subdomain (e.g., benefits.companyA.example) to segment the outsourced mail stream, and to publish the public key there; the signature would then use d=benefits.companyA.example.
更为谨慎的方法是创建一个专用子域（例如，benefits.companyA.example）来分割外包邮件流，并在其中发布公钥；然后签名将使用d=benefits.companyA.example。
Another possibility for configuring trusted third-party access, as discussed in Section 3.4, is to have Company A use DNS delegation and have the designated subdomain managed directly by the trusted third party. In this case, Company A would create a subdomain benefits.companya.example, and delegate the DNS management of that subdomain to the benefits company so it could maintain its own key records. When revocation becomes necessary, Company A could simply remove the DNS delegation record.
如第3.4节所述，配置受信任的第三方访问的另一种可能性是让A公司使用DNS授权，并让受信任的第三方直接管理指定的子域。在这种情况下，公司A将创建一个子域benefits.companya.example，并将该子域的DNS管理委托给该福利公司，以便它可以维护自己的密钥记录。当需要撤销时，公司A可以简单地删除DNS委派记录。
A simple configuration for DKIM-signed mail is to have a single signature on a given message. This works well for domains that manage and send all of their own email from single sources, or for cases where multiple email streams exist but each has its own unique key pair. It also represents the case in which only one of the participants in an email sequence is able to sign, no matter whether it represents the author or one of the operators.
DKIM签名邮件的一个简单配置是在给定消息上有一个签名。这适用于管理和发送来自单一来源的所有电子邮件的域，或者适用于存在多个电子邮件流但每个流都有自己的唯一密钥对的情况。它还表示电子邮件序列中只有一个参与者能够签名的情况，无论它代表的是作者还是操作员。
The examples thus far have considered the implications of using different identities in DKIM signatures, but have used only one such identity for any given message. In some cases, it can make sense to have more than one identity claiming responsibility for the same message.
到目前为止，这些示例已经考虑了在DKIM签名中使用不同标识的含义，但是对于任何给定的消息只使用了一个这样的标识。在某些情况下，有多个身份声称对同一消息负责是有道理的。
There are a number of situations where applying more than one DKIM signature to the same message might make sense. A few examples are:
在许多情况下，对同一消息应用多个DKIM签名可能是有意义的。例如：
Companies with multiple subdomain identities: A company that has multiple subdomains sending distinct categories of mail might choose to sign with distinct subdomain identities to enable each subdomain to manage its own identity. However, it might also want to provide a common identity that cuts across all of the distinct subdomains. For example, Company A can sign mail for its sales department with a signature where d=sales.companya.example and a second signature where d=companya.example
具有多个子域标识的公司：具有多个子域并发送不同类别邮件的公司可能会选择使用不同的子域标识进行签名，以使每个子域能够管理自己的标识。然而，它可能还希望提供一个跨越所有不同子域的通用标识。例如，公司A可以在其销售部门的邮件上签名，其中d=sales.companya.example，第二个签名为d=companya.example
Service Providers: A service provider can, as described above, choose to sign outbound messages with either its own identity or an identity unique to each of its clients (possibly delegated). However, it can also do both: sign each outbound message with its own identity as well as with the identity of each individual client. For example, ESP A might sign mail for its client Company B with its service provider signature d=espa.example, and a second client-specific signature where d= either companyb.example or companyb.espa.example. The existence of the service provider
服务提供者：如上所述，服务提供者可以选择使用自己的身份或每个客户端（可能是委托的）唯一的身份对出站消息进行签名。但是，它也可以同时完成这两项工作：使用自己的身份以及每个客户端的身份对每个出站消息进行签名。例如，ESP A可以使用其服务提供商签名d=espa.example为其客户公司B的邮件签名，以及第二个特定于客户的签名，其中d=companyb.example或companyb.espa.example。服务提供者的存在
signature could, for example, help cover a new client while it establishes its own reputation, or help a very small volume client who might never reach a volume threshold sufficient to establish an individual reputation.
例如，签名可以帮助覆盖新客户，同时建立自己的声誉，或者帮助可能永远无法达到足以建立个人声誉的数量阈值的非常小的客户。
Forwarders: Forwarded mail poses a number of challenges to email authentication. DKIM is relatively robust in the presence of forwarders as long as the signature is designed to avoid message parts that are likely to be modified; however, some forwarders do make modifications that can invalidate a DKIM signature.
转发器：转发邮件对电子邮件身份验证提出了许多挑战。DKIM在有转发器的情况下是相对健壮的，只要签名设计为避免可能被修改的消息部分；然而，一些转发器确实会做出可能使DKIM签名无效的修改。
Some forwarders such as mailing lists or "forward article to a friend" services might choose to add their own signatures to outbound messages to vouch for them having legitimately originated from the designated service. In this case, the signature would be added even in the presence of a preexisting signature, and both signatures would be relevant to the verifier.
一些转发器（如邮件列表或“将文章转发给朋友”服务）可能会选择将自己的签名添加到出站邮件中，以证明它们合法地来自指定的服务。在这种情况下，即使存在预先存在的签名，也会添加签名，并且两个签名都与验证者相关。
Any forwarder that modifies messages in ways that will break preexisting DKIM signatures needs to sign its forwarded messages.
任何转发器修改消息的方式将破坏先前存在的DKIM签名，需要对其转发的消息进行签名。
Reputation Providers: Although third-party reputation providers today use a variety of protocols to communicate their information to receivers, it is possible that they, or other organizations willing to put their "seal of approval" on an email stream, might choose to use a DKIM signature to do it. In nearly all cases, this "reputation" signature would be in addition to the author or originator signature.
声誉提供者：尽管第三方声誉提供者如今使用各种协议将其信息传达给接收者，但他们或其他愿意在电子邮件流上加盖“批准章”的组织可能会选择使用DKIM签名来实现。在几乎所有情况下，此“声誉”签名都是作者或发起人签名之外的签名。
One important caveat to the use of multiple signatures is that there is currently no clear consensus among receivers on how they plan to handle them. The opinions range from ignoring all but one signature (and the specification of which of them is verified differs from receiver to receiver), to verifying all signatures present and applying a weighted blend of the trust assessments for those identifiers, to verifying all signatures present and simply using the identifier that represents the most positive trust assessment. It is likely that the industry will evolve to accept multiple signatures using either the second or third of these, but it can take some time before one approach becomes pervasive.
使用多重签名的一个重要警告是，目前接收者之间对于如何处理这些签名没有明确的共识。意见的范围从忽略除一个签名外的所有签名（验证哪一个签名的规格因接收人而异），到验证所有签名并对这些标识符应用加权的信任评估组合，验证存在的所有签名，并仅使用表示最积极信任评估的标识符。该行业很可能会演变为使用第二个或第三个签名来接受多个签名，但一种方法普及可能需要一段时间。
Signatures are created by different types of email actors, based on different criteria, such as where the actor operates in the sequence from author to recipient, whether they want different messages to be evaluated under the same reputation or a different one, and so on.
签名是由不同类型的电子邮件参与者根据不同的标准创建的，例如参与者按照从作者到收件人的顺序操作的位置，他们是否希望在相同的信誉或不同的信誉下评估不同的邮件，等等。
This section provides some examples of usage scenarios for DKIM deployments; the selection is not intended to be exhaustive but to illustrate a set of key deployment considerations.
本节提供了DKIM部署的一些使用场景示例；选择的目的不是详尽无遗，而是说明一组关键的部署注意事项。
The simplest DKIM configuration is to have some mail from a given organization (Company A) be signed with the same d= value (e.g., d=companya.example). If there is a desire to associate additional information, the AUID [RFC5672] value can become uniqueID@companya.example, or @uniqueID.companya.example.
最简单的DKIM配置是使用相同的d=值（例如，d=companya.example）对来自给定组织（公司a）的一些邮件进行签名。如果希望关联其他信息，则AUID[RFC5672]值可以变为uniqueID@companya.example，或@uniqueID.companya.example。
In this scenario, Company A need only generate a single signing key and publish it under their top-level domain (companya.example); the signing module would then tailor the AUID value as needed at signing time.
在这个场景中，公司A只需要生成一个签名密钥并将其发布到其顶级域（companya.example）下；然后，签名模块将在签名时根据需要定制AUID值。
A slight variation of the one signature case is where Company A signs some of its mail, but it wants to differentiate among categories of its outbound mail by using different identifiers. For example, it might choose to distinguish marketing, billing or transactional, and individual corporate email into marketing.companya.example, billing.companya.example, and companya.example, respectively, where each category is assigned a unique subdomain and unique signing keys.
一个签名案例的一个微小变化是A公司对其部分邮件进行签名，但它希望通过使用不同的标识符来区分出站邮件的类别。例如，它可能会选择将营销、计费或交易以及单个公司电子邮件分别区分为marketing.companya.example、billing.companya.example和companya.example，其中每个类别都分配了唯一的子域和唯一的签名密钥。
Some domains might decide to sign all of their outgoing mail. If all of the legitimate mail for a domain is signed, recipients can be more aggressive in their filtering of mail that uses the domain but does not have a valid signature from the domain; in such a configuration, the absence of a signature would be more significant than for the general case. It might be desirable for such domains to be able to advertise their intent to other receivers: this is the topic of Author Domain Signing Practices (ADSP).
某些域可能决定对其所有传出邮件进行签名。如果某个域的所有合法邮件都已签名，则收件人在过滤使用该域但没有来自该域的有效签名的邮件时会更加积极；在这种配置中，没有签名比一般情况下更重要。这类域可能希望能够向其他接收者宣传其意图：这是作者域签名实践（ADSP）的主题。
Note that ADSP is not for everyone. Sending domains that do not control all legitimate outbound mail purporting to be from their domain (i.e., with an RFC5322.From address in their domain) are likely to experience delivery problems with some percentage of that mail. Administrators evaluating ADSP for their domains needs to carefully weigh the risk of phishing attacks against the likelihood of undelivered mail.
请注意，ADSP并非适用于所有人。发送不控制声称来自其域的所有合法出站邮件的域（即，使用其域中的RFC5322.from地址）可能会遇到部分邮件的传递问题。管理员在评估其域的ADSP时，需要仔细权衡网络钓鱼攻击的风险和未送达邮件的可能性。
This section covers some examples of ADSP usage. For the complete specification, see [RFC5617].
本节介绍ADSP使用的一些示例。有关完整规范，请参阅[RFC5617]。
In the ADSP specification, an address in the RFC5322.From header field of a message is defined as an "Author Address", and an "Author Domain" is defined as anything to the right of the '@' in an author address.
在ADSP规范中，消息RFC5322.From报头字段中的地址定义为“作者地址”，“作者域”定义为作者地址中“@”右边的任何内容。
An "Author Signature" is thus any valid signature where the value of the SDID matches an author domain in the message.
因此，“作者签名”是SDID的值与消息中的作者域匹配的任何有效签名。
It is important to note that unlike the DKIM specification, which makes no correlation between the signature domain and any message headers, the ADSP specification applies only to the author domain. In essence, under ADSP, any non-author signatures are ignored (treated as if they are not present).
需要注意的是，与DKIM规范不同（DKIM规范在签名域和任何消息头之间没有关联），ADSP规范仅适用于作者域。本质上，在ADSP下，任何非作者签名都会被忽略（视为不存在）。
Signers wishing to publish an Author Domain Signing Practices (ADSP) [RFC5617] record describing their signing practices will thus want to include an author signature on their outbound mail to avoid ADSP verification failures.
因此，希望发布描述其签名实践的作者域签名实践（ADSP）[RFC5617]记录的签名者希望在其出站邮件中包含作者签名，以避免ADSP验证失败。
An organization (Company A) can specify its signing practices by publishing an ADSP record with "dkim=all" or "dkim=discardable". In order to avoid misdelivery of its mail at receivers that are validating ADSP, Company A needs to first have done an exhaustive analysis to determine all sources of outbound mail from its domain (companyA.example) and ensure that they all have valid author signatures from that domain.
组织（公司A）可以通过发布带有“dkim=all”或“dkim=discardable”的ADSP记录来指定其签名做法。为了避免在验证ADSP的接收者处误发邮件，A公司需要首先进行详尽的分析，以确定来自其域（companyA.example）的出站邮件的所有来源，并确保它们都具有来自该域的有效作者签名。
For example, email with an RFC5322.From address of bob@ companyA.example needs to have an author signature where the SDID value is "companyA.example" or it will fail an ADSP validation.
例如，带有RFC5322.From地址bob@companyA.example的电子邮件需要有作者签名，其中SDID值为“companyA.example”，否则将无法通过ADSP验证。
Note that once an organization publishes an ADSP record using dkim=all or dkim=discardable, any email with an RFC5322.From address that uses the domain where the ADSP record is published that does not have a valid author signature is at risk of being misdelivered or discarded. For example, if a message with an RFC5322.From address of newsletter@companyA.example has a signature with d=marketing.companyA.example, that message will fail the ADSP check because the signature would not be considered a valid author signature.
请注意，一旦组织使用dkim=all或dkim=discardable发布ADSP记录，则任何使用发布ADSP记录的域的RFC5322.From地址且没有有效作者签名的电子邮件都有被误发或丢弃的风险。例如，如果带有RFC5322.From地址的消息newsletter@companyA.example具有签名d=marketing.companyA.example，该消息将无法通过ADSP检查，因为该签名将不被视为有效的作者签名。
Because the semantics of an ADSP author signature are more constrained than the semantics of a "pure" DKIM signature, it is important to make sure the nuances are well understood before deploying an ADSP record. The ADSP specification [RFC5617] provides some fairly extensive lookup examples (in Appendix A) and usage examples (in Appendix B).
由于ADSP作者签名的语义比“纯”DKIM签名的语义更受约束，因此在部署ADSP记录之前，确保充分理解细微差别非常重要。ADSP规范[RFC5617]提供了一些相当广泛的查找示例（见附录A）和使用示例（见附录B）。
In particular, in order to prevent mail from being negatively impacted or even discarded at the receiver, it is essential to perform a thorough survey of outbound mail from a domain before publishing an ADSP policy of anything stronger than "unknown". This includes mail that might be sent from external sources that might not be authorized to use the domain signature, as well as mail that risks modification in transit that might invalidate an otherwise valid author signature (e.g., mailing lists, courtesy forwarders, and other paths that could add or modify headers or modify the message body).
特别是，为了防止邮件在收件人处受到负面影响甚至被丢弃，在发布比“未知”更强的ADSP策略之前，必须对来自域的出站邮件进行彻底调查。这包括可能从未经授权使用域签名的外部来源发送的邮件，以及可能在传输过程中发生修改的邮件，这些修改可能会使其他有效的作者签名无效（例如，邮件列表、礼貌转发器和可能添加或修改标题或修改邮件正文的其他路径）。
An organization might choose to outsource certain key services to an independent company. For example, Company A might outsource its benefits management, or Organization B might outsource its marketing email.
组织可能会选择将某些关键服务外包给独立的公司。例如，A公司可能将其福利管理外包，或者B组织可能将其营销电子邮件外包。
If Company A wants to ensure that all of the mail sent on its behalf through the benefits providers email servers shares the Company A reputation, as discussed in Section 6.4, it can either publish keys designated for the use of the benefits provider under companyA.example (preferably under a designated subdomain of companyA.example), or it can delegate a subdomain (e.g., benefits.companyA.example) to the provider and enable the provider to generate the keys and manage the DNS for the designated subdomain.
如第6.4节所述，如果公司A希望确保通过福利提供商电子邮件服务器代表其发送的所有邮件共享公司的声誉，则其可以在companyA.example下（最好在companyA.example的指定子域下）发布为福利提供商使用而指定的密钥，或者，它可以将子域（例如，benefits.companyA.example）委托给提供商，使提供商能够生成密钥并管理指定子域的DNS。
In both of these cases, mail would be physically going out of the benefit provider's mail servers with a signature of, e.g., d=benefits.companya.example. Note that the RFC5322.From address is not constrained: it could be affiliated with either the benefits company (e.g., benefits-admin@benefitprovider.example, or benefits-provider@benefits.companya.example) or the companyA domain.
在这两种情况下，邮件将以签名（例如，d=benefits.companya.example）从福利提供者的邮件服务器中实际发送出去。请注意，RFC5322.From地址不受限制：它可以与福利公司（例如，福利公司）关联-admin@benefitprovider.example，或利益-provider@benefits.companya.example)或者公司域名。
Note that in both of the above scenarios, as discussed in Section 3.4, security concerns dictate that the keys be generated by the organization that plans to do the signing so that there is no need to transfer the private key. In other words, the benefits provider would generate keys for both of the above scenarios.
请注意，在上述两种情况下，如第3.4节所述，出于安全考虑，密钥由计划进行签名的组织生成，因此无需传输私钥。换句话说，利益提供者将为上述两种情况生成密钥。
Another way to manage the service provider configuration would be to have the service provider sign the outgoing mail on behalf of its client, Company A, with its own (provider) identifier. For example, an Email Service Provider (ESP A) might want to share its own mailing reputation with its clients, and might sign all outgoing mail from its clients with its own d= domain (e.g., d=espa.example).
管理服务提供商配置的另一种方法是让服务提供商代表其客户A公司使用自己的（提供商）标识符在发送邮件上签名。例如，电子邮件服务提供商（espa）可能希望与其客户共享其自己的邮件声誉，并可能使用其自己的d=域（例如，d=espa.example）对其客户发送的所有邮件进行签名。
When the ESP wants to distinguish among its clients, it has two options:
当ESP想要区分其客户机时，它有两个选项：
o Share the SDID domain and use the AUID value to distinguish among the clients, e.g., a signature on behalf of client A would have d=espa.example and i=@clienta.espa.example (or i=clienta@espa.example).
o 共享SDID域并使用AUID值区分客户端，例如，代表客户端a的签名将具有d=espa.example和i=@clienta.espa.example（或i=clienta@espa.example).
o Extend the SDID domain, so there is a unique value (and subdomain) for each client, e.g., a signature on behalf of client A would have d=clienta.espa.example.
o 扩展SDID域，使每个客户端都有一个唯一的值（和子域），例如，代表客户端a的签名将具有d=clienta.espa.example。
Note that this scenario and the delegation scenario are not mutually exclusive. In some cases, it can be desirable to sign the same message with both the ESP and the ESP client identities.
请注意，此场景和委派场景并不相互排斥。在某些情况下，可能需要同时使用ESP和ESP客户端身份对同一消息进行签名。
An ISP (ISP A) might want to assign signatures to outbound mail from its users according to each user's past sending behavior (reputation). In other words, the ISP would segment its outbound traffic according to its own assessment of message quality, to aid recipients in differentiating among these different streams. Since the semantics of behavioral assessments are not valid AUID values, ISP A (ispa.example) can configure subdomains corresponding to the assessment categories (e.g., good.ispa.example, neutral.ispa.example, bad.ispa.example), and use these subdomains in the d= value of the signature.
ISP（ISP A）可能希望根据每个用户过去的发送行为（信誉）为其用户的出站邮件分配签名。换句话说，ISP将根据自己对消息质量的评估对其出站流量进行分段，以帮助收件人区分这些不同的流。由于行为评估的语义不是有效的AUID值，ISP A（ispa.example）可以配置与评估类别相对应的子域（例如good.ispa.example、neutral.ispa.example、bad.ispa.example），并在签名的d=值中使用这些子域。
The signing module can also set the AUID value to have a unique user ID (distinct from the local-part of the user's email address), for example, user3456@neutral.domain.example. Using a user ID that is distinct from a given email alias is useful in environments where a single user might register multiple email aliases.
签名模块还可以将AUID值设置为具有唯一的用户ID（不同于用户电子邮件地址的本地部分），例如，user3456@neutral.domain.example. 在单个用户可能注册多个电子邮件别名的环境中，使用不同于给定电子邮件别名的用户ID非常有用。
Note that in this case, the AUID values are only partially stable. They are stable in the sense that a given i= value will always represent the same identity, but they are unstable in the sense that
注意，在这种情况下，AUID值仅部分稳定。它们是稳定的，因为给定的i=值将始终表示相同的身份，但它们是不稳定的，因为
a given user can migrate among the assessment subdomains depending on their sending behavior (i.e., the same user might have multiple AUID values over the lifetime of a single account).
给定用户可以根据其发送行为在评估子域之间迁移（即，同一用户可能在单个帐户的生命周期内具有多个AUID值）。
In this scenario, ISP A can generate as many keys as there are assessment subdomains (SDID values), so that each assessment subdomain has its own key. The signing module would then choose its signing key based on the assessment of the user whose mail was being signed, and if desired, include the user ID in the AUID of the signature. As discussed earlier, the per-user granularity of the AUID can be ignored by verifiers; so organizations choosing to use it ought not rely on its use for receiver side filtering results. However, some organizations might also find the information useful for their own purposes in processing bounces or abuse reports.
在这种情况下，ISPA可以生成与评估子域（SDID值）数量相同的密钥，以便每个评估子域都有自己的密钥。然后，签名模块将基于对其邮件被签名的用户的评估来选择其签名密钥，并且如果需要，将用户ID包括在签名的AUID中。如前所述，验证器可以忽略AUID的每用户粒度；因此，选择使用它的组织不应该依赖于它对接收方过滤结果的使用。然而，一些组织可能会发现这些信息在处理弹跳或滥用报告时对他们自己的目的很有用。
Another scenario is that of an agent, usually a re-mailer of some kind, that signs on behalf of the service or organization that it represents. Some examples of agents might be a mailing list manager, or the "forward article to a friend" service that many online publications offer. In most of these cases, the signature is asserting that the message originated with, or was relayed by, the service asserting responsibility. In general, if the service is configured in such a way that its forwarding would break existing DKIM signatures, it needs to always add its own signature.
另一种情况是代理，通常是某种类型的转发者，代表它所代表的服务或组织进行签名。代理的一些示例可能是邮件列表管理器，或许多在线出版物提供的“将文章转发给朋友”服务。在大多数情况下，签名断言消息是由断言责任的服务发起的或由该服务转发的。通常，如果服务配置为其转发将破坏现有DKIM签名，则它需要始终添加自己的签名。
The robustness of DKIM's verification mechanism is based on the fact that only authorized signing modules have access to the designated private key. This has the side effect that email submission and delivery scenarios that originate or relay messages from outside the domain of the authorized signing module will not have access to that protected private key, and thus will be unable to attach the expected domain signature to those messages. Such scenarios include mailing lists, courtesy forwarders, MTAs at hotels, hotspot networks used by traveling users, and other paths that could add or modify headers, or modify the message body.
DKIM验证机制的健壮性基于这样一个事实，即只有授权签名模块才能访问指定的私钥。这有一个副作用，即从授权签名模块的域外发起或中继消息的电子邮件提交和传递方案将无法访问该受保护的私钥，因此将无法将预期的域签名附加到这些消息。这些场景包括邮件列表、礼节转发器、酒店MTA、旅行用户使用的热点网络，以及其他可以添加或修改邮件头或修改邮件正文的路径。
For example, assume Joe works for Company A and has an email address joe@companya.example. Joe also has an ISP-1 account joe@isp1.example.com, and he uses ISP-1's multiple address feature to attach his work email address, joe@companya.example, to email from his ISP-1 account. When Joe sends email from his ISP-1 account and uses joe@companya.example as his designated RFC5322.From address,
例如，假设Joe为A公司工作，并且有一个电子邮件地址joe@companya.example. 乔也有一个ISP-1帐户joe@isp1.example.com，他使用ISP-1的多地址功能附加他的工作电子邮件地址，joe@companya.example，通过他的ISP-1帐户发送电子邮件。当Joe从他的ISP-1帐户发送电子邮件并使用joe@companya.example作为其指定的RFC5322.发件人地址，
that email cannot have a signature with d=companya.example because the ISP-1 servers have no access to Company A's private key. In ISP-1's case, it will have an ISP-1 signature, but for some other mail clients offering the same multiple address feature there might be no signature at all on the message.
该电子邮件不能具有d=companya的签名。例如，因为ISP-1服务器无法访问a公司的私钥。在ISP-1的情况下，它将具有ISP-1签名，但对于提供相同多地址功能的其他一些邮件客户端，消息上可能根本没有签名。
Another example might be the use of a forward article to a friend service. Most instances of these services today allow someone to send an article with their email address in the RFC5322.From to their designated recipient. If Joe used either of his two addresses (joe@companya.example or joe@isp1.example.com), the forwarder would be equally unable to sign with a corresponding domain. As in the mail client case, the forwarder can either sign as its own domain or put no signature on the message.
另一个例子可能是使用转发文章到朋友服务。如今，这些服务的大多数实例都允许用户使用RFC5322.From中的电子邮件地址将文章发送给指定的收件人。如果Joe使用了他的两个地址中的任何一个(joe@companya.example或joe@isp1.example.com)，则转发器将同样无法与相应的域进行签名。与邮件客户端一样，转发器可以作为自己的域进行签名，也可以不在邮件上签名。
A third example is the use of privately configured forwarding. Assume that Joe has another account at ISP-2, joe@isp-2.example.com, but he'd prefer to read his ISP-2 mail from his ISP-1 account. He sets up his ISP-2 account to forward all incoming mail to joe@isp1.example.com. Assume alice@companyb.example sends joe@isp-2.example.com an email. Depending on how companyb.example configured its signature, and depending on whether or not ISP-2 modifies messages that it forwards, it is possible that when Alice's message is received in Joe's ISP-1 account, the original signature will fail verification.
第三个例子是使用私有配置的转发。假设Joe在ISP-2有另一个帐户，joe@isp-2.example.com，但他更喜欢从他的ISP-1帐户读取他的ISP-2邮件。他设置他的ISP-2帐户，将所有收到的邮件转发给joe@isp1.example.com. 假定alice@companyb.example发送joe@isp-2.example.com电子邮件。根据companyb.example如何配置其签名，以及ISP-2是否修改其转发的消息，当Alice的消息在Joe的ISP-1帐户中收到时，原始签名可能无法验证。
One identity is particularly amenable to easy and accurate assessment: the organization's own identity. Members of an organization tend to trust messages that purport to be from within that organization. However, Internet Mail does not provide a straightforward means of determining whether such mail is, in fact, from within the organization. DKIM can be used to remedy this exposure. If the organization signs all of its mail, then its boundary MTAs can look for mail purporting to be from the organization that does not contain a verifiable signature.
一个身份特别容易接受简单而准确的评估：组织自身的身份。组织的成员倾向于信任声称来自该组织内部的消息。然而，因特网邮件并没有提供一种直接的方法来确定这种邮件实际上是否来自组织内部。DKIM可用于补救这种暴露。如果该组织对其所有邮件进行签名，则其边界MTA可以查找声称来自不包含可验证签名的组织的邮件。
Such mail can, in most cases, be presumed to be spurious. However, domain managers are advised to consider the ways that mail processing can modify messages in ways that will invalidate an existing DKIM signature: mailing lists, courtesy forwarders, and other paths that could add or modify headers or modify the message body (e.g., MTAs at hotels, hotspot networks used by traveling users, and other scenarios described in the previous section). Such breakage is particularly relevant in the presence of Author Domain Signing Practices.
在大多数情况下，这类邮件可能被认为是伪造的。但是，域管理者建议考虑邮件处理可以以无效的方式修改现有的DKIM签名的方式：邮件列表、礼貌转发器和其他可以添加或修改标头或修改消息体的路径。（例如，酒店的MTA、旅行用户使用的热点网络以及上一节中描述的其他场景）。这种破坏在存在作者域签名实践的情况下尤其相关。
Although DKIM's use of domain names is optimized for a scope of organization-level signing, it is possible to administer subdomains or otherwise adjust signatures in a way that supports per-user identification. This user-level granularity can be specified in two ways: either by sharing the signing identity and specifying an extension to the i= value that has a per-user granularity or by creating and signing with unique per-user keys.
虽然DKIM对域名的使用针对组织级签名的范围进行了优化，但可以管理子域或以支持每个用户标识的方式调整签名。可以通过两种方式指定此用户级粒度：共享签名标识并指定具有每用户粒度的i=值的扩展，或者使用唯一的每用户密钥创建和签名。
A subdomain or local part in the i= tag needs to be treated as an opaque identifier and thus need not correspond directly to a DNS subdomain or be a specific user address.
i=标记中的子域或本地部分需要被视为不透明标识符，因此不需要直接对应于DNS子域或特定的用户地址。
The primary way to sign with per-user keys requires each user to have a distinct DNS (sub)domain, where each distinct d= value has a key published. (It is possible, although not advised, to publish the same key in more than one distinct domain.)
使用每个用户密钥进行签名的主要方法要求每个用户都有一个不同的DNS（子）域，其中每个不同的d=值都有一个已发布的密钥。（虽然不建议，但也可以在多个不同的域中发布相同的密钥。）
It is technically possible to publish per-user keys within a single domain or subdomain by utilizing different selector values. This is not advised and is unlikely to be treated uniquely by Assessors: the primary purpose of selectors is to facilitate key management, and the DKIM specification recommends against using them in determining or assessing identities.
从技术上讲，通过使用不同的选择器值，可以在单个域或子域中发布每个用户的密钥。这是不建议的，也不太可能被评估人员单独对待：选择器的主要目的是促进密钥管理，DKIM规范建议在确定或评估身份时不要使用它们。
In most cases, it would be impractical to sign email on a per-user granularity. Such an approach would be
在大多数情况下，在每个用户粒度上签署电子邮件是不切实际的。这样一种做法是不可取的
likely to be ignored: In most cases today, if receivers are verifying DKIM signatures, they are in general taking the simplest possible approach. In many cases, maintaining reputation information at a per-user granularity is not interesting to them, in large part because the per-user volume is too small to be useful or interesting. So even if senders take on the complexity necessary to support per-user signatures, receivers are unlikely to retain anything more than the base domain reputation.
可能会被忽略：在今天的大多数情况下，如果接收者正在验证DKIM签名，他们通常会采取最简单的方法。在许多情况下，以每个用户的粒度维护信誉信息对他们来说并不有趣，这在很大程度上是因为每个用户的容量太小，不可能有用或有趣。因此，即使发送方承担了支持每用户签名所需的复杂性，接收方也不太可能保留基本域信誉以外的任何东西。
difficult to manage: Any scheme that involves maintenance of a significant number of public keys might require infrastructure enhancements or extensive administrative expertise. For domains of any size, maintaining a valid per-user keypair, knowing when keys need to be revoked or added due to user attrition or onboarding, and the overhead of having the signing engine constantly swapping keys can create significant and often unnecessary management complexity. It is also important to note
难以管理：任何涉及维护大量公钥的方案都可能需要基础架构增强或广泛的管理专业知识。对于任何大小的域，维护有效的每用户密钥对、知道何时由于用户磨损或登录而需要撤销或添加密钥，以及让签名引擎不断交换密钥的开销，都会造成显著且通常不必要的管理复杂性。注意这一点也很重要
that there is no way within the scope of the DKIM specification for a receiver to infer that a sender intends a per-user granularity.
在DKIM规范的范围内，接收方无法推断发送方打算采用每用户粒度。
As mentioned before, what might make sense, however, is to use the infrastructure that enables finer granularity in signatures to identify segments smaller than a domain but much larger than a per-user segmentation. For example, a university might want to segment student, staff, and faculty mail into three distinct streams with differing reputations. This can be done by creating separate subdomains for the desired segments, and either specifying the subdomains in the i= tag of the DKIM Signature or by adding subdomains to the d= tag and assigning and signing with different keys for each subdomain.
但是，如前所述，有意义的是使用能够使签名具有更精细粒度的基础设施来识别比域小但比每用户分段大得多的分段。例如，一所大学可能希望将学生、教职员工和教员的邮件分为三个具有不同声誉的不同邮件流。这可以通过为所需的段创建单独的子域，或者在DKIM签名的i=标记中指定子域，或者通过向d=标记添加子域，并为每个子域分配和签名不同的密钥来实现。
For those who choose to represent user-level granularity in signatures, the performance and management considerations above suggest that it would be more effective to do so by specifying a local part or subdomain extension in the i= tag rather than by extending the d= domain and publishing individual keys.
对于那些选择在签名中表示用户级粒度的人，上面的性能和管理考虑表明，通过在i=标记中指定本地部分或子域扩展，而不是扩展d=域并发布单个密钥，这样做会更有效。
It is expected that the most common venue for a DKIM implementation will be within the infrastructure of an organization's email service, such as a department or a boundary MTA. What follows are some general recommendations for the Email Infrastructure.
预计DKIM实施的最常见场所将位于组织电子邮件服务的基础设施内，如部门或边界MTA。下面是对电子邮件基础架构的一些一般建议。
Outbound: An MSA (Mail Submission Agent) or an outbound MTA used for mail submission needs to ensure that the message sent is in compliance with the advertised email sending policy. It needs to also be able to generate an operator alert if it determines that the email messages do not comply with the published DKIM sending policy.
出站：用于邮件提交的MSA（邮件提交代理）或出站MTA需要确保发送的邮件符合公布的电子邮件发送策略。如果确定电子邮件不符合已发布的DKIM发送策略，它还需要能够生成操作员警报。
An MSA needs to be aware that some MUAs might add their own signatures. If the MSA needs to perform operations on a message to make it comply with its email sending policy, if at all possible, it needs to do so in a way that would not break those signatures.
MSA需要知道某些MUA可能会添加自己的签名。如果MSA需要对邮件执行操作以使其符合其电子邮件发送策略，则如果可能，MSA需要以不会破坏这些签名的方式执行操作。
MUAs equipped with the ability to sign ought not to be encouraged. In terms of security, MUAs are generally not under the direct control of those in responsible roles within an organization and are thus more vulnerable to attack and compromise, which would expose private signing keys to intruders and thus jeopardize the integrity and reputation of the organization.
不应鼓励具备签名能力的MUA。就安全性而言，MUA通常不受组织内负责人的直接控制，因此更容易受到攻击和泄露，这将向入侵者公开私人签名密钥，从而危害组织的完整性和声誉。
Inbound: When an organization deploys DKIM, it needs to make sure that its email infrastructure components that do not have primary roles in DKIM handling do not modify message in ways that prevent subsequent verification.
Inbound：当组织部署DKIM时，需要确保其电子邮件基础结构组件（在DKIM处理中没有主要角色）不会以阻止后续验证的方式修改邮件。
An inbound MTA or an MDA can incorporate an indication of the verification results into the message, such as using an Authentication-Results header field [RFC5451].
入站MTA或MDA可以将验证结果的指示合并到消息中，例如使用身份验证结果标头字段[RFC5451]。
Intermediaries: An email intermediary is both an inbound and outbound MTA. Each of the requirements outlined in the sections relating to MTAs apply. If the intermediary modifies a message in a way that breaks the signature, the intermediary.
中间人：电子邮件中间人是入站和出站MTA。MTA相关章节中概述的每项要求均适用。如果中间层修改消息的方式破坏了签名，则中间层。
+ needs to deploy abuse filtering measures on the inbound mail, and
+ 需要在入站邮件上部署滥用筛选措施，以及
+ probably also needs to remove all signatures that will be broken.
+ 可能还需要删除所有将被破坏的签名。
In addition, the intermediary can:
此外，中介机构可以：
+ verify the message signature prior to modification.
+ 在修改之前验证消息签名。
+ incorporate an indication of the verification results into the message, such as using an Authentication-Results header field [RFC5451].
+ 将验证结果的指示合并到消息中，例如使用验证结果标头字段[RFC5451]。
+ sign the modified message including the verification results (e.g., the Authentication-Results header field).
+ 签署修改后的消息，包括验证结果（例如，身份验证结果标题字段）。
The DKIM specification is expected to be used primarily between Boundary MTAs, or other infrastructure components of the originating and receiving ADMDs. However, there is nothing in DKIM that is specific to those venues. In particular, MUAs can also support DKIM signing and verifying directly.
DKIM规范预计主要用于边界MTA或发起和接收ADMD的其他基础设施组件之间。但是，DKIM中没有任何特定于这些场馆的内容。特别是，MUAs还可以直接支持DKIM签名和验证。
Outbound: An MUA can support signing even if mail is to be relayed through an outbound MSA. In this case, the signature applied by the MUA will be in addition to any signature added by the MSA. However, the warnings in the previous section need to be taken into consideration.
出站：即使邮件要通过出站MSA中继，MUA也可以支持签名。在这种情况下，MUA应用的签名将是MSA添加的任何签名的补充。但是，需要考虑上一节中的警告。
Some user software goes beyond simple user functionality and also performs MSA and MTA functions. When this is employed for sending directly to a receiving ADMD, the user software needs to be considered an outbound MTA.
一些用户软件超越了简单的用户功能，还执行MSA和MTA功能。当使用此选项直接发送到接收ADMD时，需要将用户软件视为出站MTA。
Inbound: An MUA can rely on a report of a DKIM signature verification that took place at some point in the inbound MTA/ MDA path (e.g., an Authentication-Results header field), or an MUA can perform DKIM signature verification directly. A verifying MUA needs to allow for the case where mail has been modified in the inbound MTA path; if a signature fails, the message is to be treated the same as a message that does not have a signature.
入站：MUA可以依赖于在入站MTA/MDA路径的某个点（例如，身份验证结果标头字段）发生的DKIM签名验证报告，或者MUA可以直接执行DKIM签名验证。验证MUA需要考虑邮件在入站MTA路径中被修改的情况；如果签名失败，消息将被视为与没有签名的消息相同。
An MUA that looks for an Authentication-Results header field needs to be configurable to choose which Authentication-Results header fields are considered trustable. The MUA developer is encouraged to re-read the Security Considerations of [RFC5451].
查找身份验证结果头字段的MUA需要可配置，以选择哪些身份验证结果头字段被认为是可信任的。鼓励MUA开发人员重新阅读[RFC5451]的安全注意事项。
DKIM requires that all verifiers treat messages with signatures that do not verify as if they are unsigned.
DKIM要求所有验证器都将带有未验证签名的消息视为未签名。
If verification in the client is to be acceptable to users, it is essential that successful verification of a signature not result in a less than satisfactory user experience compared to leaving the message unsigned. The mere presence of a verified DKIM signature cannot be used by itself by an MUA to indicate that a message is to be treated better than a message without a verified DKIM signature. However, the fact that a DKIM signature was verified can be used as input into a reputation system (i.e., a whitelist of domains and users) for presentation of such indicators.
如果用户可以接受客户机中的验证，则与未签名的消息相比，成功验证签名不会导致不令人满意的用户体验，这一点至关重要。MUA不能仅使用已验证DKIM签名的存在来表示消息要比没有已验证DKIM签名的消息得到更好的处理。然而，DKIM签名经过验证这一事实可作为声誉系统（即域和用户白名单）的输入，用于显示此类指标。
It is common for components of an ADMD's email infrastructure to do violence to a message, such that a DKIM signature might be rendered invalid. Hence, users of MUAs that support DKIM signing and/or verifying need a basis for knowing that their associated email infrastructure will not break a signature.
ADMD电子邮件基础结构的组件对邮件进行暴力处理是很常见的，因此DKIM签名可能会被视为无效。因此，支持DKIM签名和/或验证的MUA用户需要知道其相关电子邮件基础设施不会破坏签名。
The security considerations of the DKIM protocol are described in the DKIM base specification [RFC4871].
DKIM基本规范[RFC4871]中描述了DKIM协议的安全注意事项。
The effort of the DKIM Working Group is gratefully acknowledged.
感谢DKIM工作组的努力。
[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月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
[RFC5451]Kucherawy，M.，“用于指示消息身份验证状态的消息头字段”，RFC 5451，2009年4月。
[RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Identified Mail (DKIM) Service Overview", RFC 5585, July 2009.
[RFC5585]Hansen，T.，Crocker，D.，和P.Hallam Baker，“域密钥识别邮件（DKIM）服务概述”，RFC 55852009年7月。
[RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009.
[RFC5617]Allman，E.，Fenton，J.，Delany，M.，和J.Levine，“域密钥识别邮件（DKIM）作者域签名实践（ADSP）”，RFC 56172009年8月。
[RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update", RFC 5672, August 2009.
[RFC5672]Crocker，D.，“RFC 4871域密钥识别邮件（DKIM）签名——更新”，RFC 56722009年8月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[RFC4870] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, May 2007.
[RFC4870]Delany，M.，“使用DNS中公布的公钥进行基于域的电子邮件身份验证（域密钥）”，RFC 4870，2007年5月。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
[RFC5155]Laurie，B.，Sisson，G.，Arends，R.，和D.Blacka，“DNS安全（DNSSEC）哈希认证拒绝存在”，RFC 51552008年3月。
There are three migration occasions worth noting in particular for DKIM:
对于DKIM，有三种迁移情况值得特别注意：
1. Migrating from DomainKeys to DKIM.
1. 从域密钥迁移到DKIM。
2. Migrating from a current hash algorithm to a new standardized hash algorithm.
2. 从当前哈希算法迁移到新的标准化哈希算法。
3. Migrating from a current signing algorithm to a new standardized signing algorithm.
3. 从当前签名算法迁移到新的标准化签名算法。
The case of deploying a new key selector record is described elsewhere (Section 3.5).
其他地方（第3.5节）描述了部署新键选择器记录的情况。
As with any migration, the steps required will be determined by who is doing the migration and their assessment of:
与任何迁移一样，所需的步骤将由进行迁移的人员及其对以下各项的评估来确定：
o the users of what they are generating, or
o 用户正在生成的内容，或
o the providers of what they are consuming.
o 他们消费的东西的提供者。
Signers and verifiers have different considerations.
签名者和验证者有不同的考虑。
DKIM replaces the earlier DomainKeys (DK) specification. Selector files are mostly compatible between the two specifications.
DKIM取代了早期的域密钥（DK）规范。选择器文件在这两种规范之间基本上是兼容的。
A signer that currently signs with DK will go through various stages as it migrates to using DKIM, not all of which are required for all signers. The real questions that a signer needs to ask are:
当前使用DK签名的签名者在迁移到使用DKIM时将经历不同的阶段，并非所有签名者都需要这些阶段。签名人需要问的真正问题是：
1. how many receivers or what types of receivers are *only* looking at the DK signatures and not the DKIM signatures, and
1. 有多少个接收者或什么类型的接收者*仅*查看DK签名而不是DKIM签名，以及
2. how much does the signer care about those receivers?
2. 签名者对这些接收者有多关心？
If no one is looking at the DK signature any more, then it's no longer necessary to sign with DK. Or if all "large players" are looking at DKIM in addition to or instead of DK, a signer can choose to stop signing with DK.
如果没有人再看DK的签名，那么就没有必要再和DK签名了。或者，如果所有的“大玩家”都在关注DKIM，而不是DK，那么签名者可以选择停止与DK的签名。
With respect to signing policies, a reasonable, initial approach is to use DKIM signatures in the same way that DomainKeys signatures are already being used. In particular, the same selectors and DNS key records can be used for both, after verifying that they are compatible as discussed below.
关于签名策略，一种合理的初始方法是使用DKIM签名，其方式与已使用的DomainKeys签名相同。特别是，在验证选择器和DNS密钥记录是否兼容后，可以对两者使用相同的选择器和DNS密钥记录，如下所述。
Each secondary step in all of the following scenarios is to be prefaced with the gating factor "test, then when comfortable with the previous step's results, continue".
以下所有场景中的每个次要步骤都将以“测试，然后在对上一步的结果感到满意时，继续”的选通因子作为开头。
One migration strategy is to:
一种迁移策略是：
o ensure that the current selector DNS key record is compatible with both DK and DKIM
o 确保当前选择器DNS密钥记录与DK和DKIM兼容
o sign messages with both DK and DKIM signatures
o 使用DK和DKIM签名对消息进行签名
o when it's decided that DK signatures are no longer necessary, stop signing with DK
o 当决定不再需要DK签名时，停止与DK签名
Another migration strategy is to:
另一种迁移策略是：
o add a new selector DNS key record only for DKIM signatures
o 仅为DKIM签名添加新的选择器DNS密钥记录
o sign messages with both DK (using the old DNS key record) and DKIM signatures (using the new DNS key record)
o 使用DK（使用旧DNS密钥记录）和DKIM签名（使用新DNS密钥记录）对消息进行签名
o when it's decided that DK signatures are no longer necessary, stop signing with DK
o 当决定不再需要DK签名时，停止与DK签名
o eventually remove the old DK selector DNS record
o 最终删除旧的DK选择器DNS记录
A combined migration strategy is to:
组合迁移策略是：
o ensure that the current selector DNS key record is compatible with both DK and DKIM
o 确保当前选择器DNS密钥记录与DK和DKIM兼容
o start signing messages with both DK and DKIM signatures
o 开始使用DK和DKIM签名对邮件进行签名
o add a new selector DNS key record for DKIM signatures
o 为DKIM签名添加新的选择器DNS密钥记录
o switch the DKIM signatures to use the new selector
o 切换DKIM签名以使用新选择器
o when it's decided that DK signatures are no longer necessary, stop signing with DK
o 当决定不再需要DK签名时，停止与DK签名
o eventually remove the old DK selector DNS record
o 最终删除旧的DK选择器DNS记录
Another migration strategy is to:
另一种迁移策略是：
o add a new selector DNS key record for DKIM signatures
o 为DKIM签名添加新的选择器DNS密钥记录
o do a flash cut and replace the DK signatures with DKIM signatures
o 进行闪光切割，并用DKIM签名替换DK签名
o eventually remove the old DK selector DNS record
o 最终删除旧的DK选择器DNS记录
Another migration strategy is to:
另一种迁移策略是：
o ensure that the current selector DNS key record is compatible with both DK and DKIM
o 确保当前选择器DNS密钥记录与DK和DKIM兼容
o do a flash cut and replace the DK signatures with DKIM signatures
o 进行闪光切割，并用DKIM签名替换DK签名
Note that when you have separate key records for DK and DKIM, you can use the same public key for both.
请注意，当您对DK和DKIM有单独的密钥记录时，您可以对两者使用相同的公钥。
The first step in some of the above scenarios is ensuring that the selector DNS key records are compatible for both DK and DKIM. The format of the DNS key record was intentionally meant to be backwardly compatible between the two systems, but not necessarily upwardly compatible. DKIM has enhanced the DK DNS key record format by adding several optional parameters, which DK needs to ignore. However, there is one critical difference between DK and DKIM DNS key records. The definitions of the "g" fields:
上述一些场景中的第一步是确保选择器DNS密钥记录与DK和DKIM兼容。DNS密钥记录的格式有意在两个系统之间向后兼容，但不一定向上兼容。DKIM通过添加几个可选参数增强了DK DNS密钥记录格式，DK需要忽略这些参数。但是，DK和DKIM DNS密钥记录之间有一个关键区别。“g”字段的定义：
g= granularity of the key: In both DK and DKIM, this is an optional field that is used to constrain which sending address(es) can legitimately use this selector. Unfortunately, the treatment of an empty field ("g=;") is different. DKIM allows wildcards where DK does not. For DK, an empty field is the same as a missing value, and is treated as allowing any sending address. For DKIM, an empty field only matches an empty local part. In DKIM, both a missing value and "g=*;" mean to allow any sending address.
g=键的粒度：在DK和DKIM中，这是一个可选字段，用于约束哪个发送地址可以合法使用此选择器。不幸的是，对空字段（“g=；”）的处理是不同的。DKIM允许在DK不允许的情况下使用通配符。对于DK，空字段与缺少的值相同，并且被视为允许任何发送地址。对于DKIM，空字段仅匹配空的本地部分。在DKIM中，缺少的值和“g=*；”都表示允许任何发送地址。
Also, in DomainKeys, the "g" field is required to match the address in "From:"/"Sender:", while in DKIM, it is required to match i=. This might or might not affect transition.
此外，在DomainKeys中，“g”字段需要与“发件人：/”发件人：”中的地址匹配，而在DKIM中，它需要与i=匹配。这可能会也可能不会影响转换。
If your DK DNS key record has an empty "g" field in it ("g=;"), your best course of action is to modify the record to remove the empty field. In that way, the DK semantics will remain the same, and the DKIM semantics will match.
如果您的DK DNS密钥记录中有一个空的“g”字段（“g=；”），那么最好的做法是修改该记录以删除该空字段。这样，DK语义将保持不变，DKIM语义将匹配。
If your DNS key record does not have an empty "g" field in it ("g=;"), it's probable that the record can be left alone. But the best course of action would still be to make sure that it has a "v" field. When the decision is made to stop supporting DomainKeys and to only support DKIM, it is important to verify that the "g" field is compatible with DKIM, and typically having "v=DKIM1;" in it. It is strongly encouraged that if use of an empty "g" field in the DKIM selector, include the "v" field.
如果您的DNS密钥记录中没有空的“g”字段（“g=；”），则该记录可能会被单独保留。但最好的做法仍然是确保它有一个“v”字段。当决定停止支持域密钥并仅支持DKIM时，验证“g”字段是否与DKIM兼容并通常在其中包含“v=DKIM1；”是很重要的。强烈建议在DKIM选择器中使用空的“g”字段时，包括“v”字段。
The principal use of DomainKeys is at boundary MTAs. Because no operational transition is ever instantaneous, it is advisable to continue performing DomainKeys signing until it is determined that DomainKeys receive-side support is no longer used, or is sufficiently reduced. That is, a signer needs to add a DKIM signature to a message that also has a DomainKeys signature and keep it there until they decide it is deemed no longer useful. The signer can do its transitions in a straightforward manner, or more gradually. Note that because digital signatures are not free, there is a cost to performing both signing algorithms, so signing with both algorithms ought not be needlessly prolonged.
域密钥的主要用途是边界MTA。因为任何操作转换都不是瞬时的，所以建议继续执行域密钥签名，直到确定不再使用域密钥接收端支持，或者域密钥接收端支持已充分减少。也就是说，签名者需要将DKIM签名添加到同样具有DomainKeys签名的消息中，并将其保留在该消息中，直到他们认为它不再有用为止。签名者可以以直接的方式或更渐进的方式进行转换。请注意，因为数字签名不是免费的，所以执行这两种签名算法都要付出代价，因此使用这两种算法进行签名不应该无谓地延长时间。
The tricky part is deciding when DK signatures are no longer necessary. The real questions are: how many DomainKeys verifiers are there that do *not* also do DKIM verification, which of those are important, and how can you track their usage? Most of the early adopters of DK verification have added DKIM verification, but not all yet. If a verifier finds a message with both DK and DKIM, it can choose to verify both signatures, or just one or the other.
棘手的部分是决定何时不再需要DK签名。真正的问题是：有多少域密钥验证器*不*也做DKIM验证，其中哪些是重要的，以及如何跟踪它们的使用情况？DK验证的大多数早期采用者都添加了DKIM验证，但还不是全部。如果验证器发现同时具有DK和DKIM的消息，它可以选择同时验证这两个签名，或者只验证其中一个签名。
Many DNS services offer tracking statistics so it can be determined how often a DNS record has been accessed. By using separate DNS selector key records for your signatures, you can chart the use of your records over time, and watch the trends. An additional distinguishing factor to track would take into account the verifiers that verify both the DK and DKIM signatures, and discount those from counts of DK selector usage. When the number for DK selector access reaches a low-enough level, that's the time to consider discontinuing signing with DK.
许多DNS服务提供跟踪统计信息，因此可以确定访问DNS记录的频率。通过为签名使用单独的DNS选择器键记录，您可以绘制一段时间内记录的使用情况图表，并观察趋势。跟踪的另一个区别因素将考虑验证DK和DKIM签名的验证者，并从DK选择器使用计数中扣除这些验证者。当DK选择器访问的数量达到足够低的水平时，是考虑停止与DK签署的时间。
Note, this level of rigor is not required. It is perfectly reasonable for a DK signer to decide to follow the "flash cut" scenario described above.
注意，不需要这种严格程度。DK签名者完全有理由决定遵循上述“闪电切割”场景。
As a verifier, several issues need to be considered:
作为验证者，需要考虑以下几个问题：
At the time of writing, there is still a significant number of sites that are only producing DK signatures. Over time, it is expected that this number will go to zero, but it might take several years. So it would be prudent for the foreseeable future for a verifier to look for and verify both DKIM and DK signatures.
在撰写本文时，仍有相当数量的网站只生成DK签名。随着时间的推移，预计这一数字将降至零，但可能需要几年时间。因此，在可预见的未来，验证者寻找并验证DKIM和DK签名是谨慎的。
A.1.2.2. Ought both DK and DKIM signatures be evaluated on a single message?
A.1.2.2. DK和DKIM签名是否应该在单个消息上进行评估？
For a period of time, there will be sites that sign with both DK and DKIM. A verifier receiving a message that has both types of signatures can verify both signatures, or just one. One disadvantage of verifying both signatures is that signers will have a more difficult time deciding how many verifiers are still using their DK selectors. One transition strategy is to verify the DKIM signature, then only verify the DK signature if the DKIM verification fails.
在一段时间内，将有与DK和DKIM签署的网站。接收具有两种签名类型的消息的验证器可以同时验证两个签名，或者只验证一个签名。验证两个签名的一个缺点是，签名者很难确定有多少验证者仍在使用他们的DK选择器。一种转换策略是验证DKIM签名，然后仅在DKIM验证失败时验证DK签名。
The format of the DNS key record was intentionally meant to be backwardly compatible between DK and DKIM, but not necessarily upwardly compatible. DKIM has enhanced the DK DNS key record format by adding several optional parameters, which DK needs to ignore. However, there is one key difference between DK and DKIM DNS key records. The definitions of the g fields:
DNS密钥记录的格式有意在DK和DKIM之间向后兼容，但不一定向上兼容。DKIM通过添加几个可选参数增强了DK DNS密钥记录格式，DK需要忽略这些参数。但是，DK和DKIM DNS密钥记录之间有一个关键区别。g字段的定义：
g= granularity of the key: In both DK and DKIM, this is an optional field that is used to constrain which sending address(es) can legitimately use this selector. Unfortunately, the treatment of an empty field ("g=;") is different. For DK, an empty field is the same as a missing value, and is treated as allowing any sending address. For DKIM, an empty field only matches an empty local part.
g=键的粒度：在DK和DKIM中，这是一个可选字段，用于约束哪个发送地址可以合法使用此选择器。不幸的是，对空字段（“g=；”）的处理是不同的。对于DK，空字段与缺少的值相同，并且被视为允许任何发送地址。对于DKIM，空字段仅匹配空的本地部分。
v= version of the selector It is advised that a DKIM selector have "v=DKIM1;" at its beginning, but it is not required.
v=选择器的版本建议DKIM选择器在其开头有“v=DKIM1；”，但这不是必需的。
If a DKIM verifier finds a selector record that has an empty "g" field ("g=;") and it does not have a "v" field ("v=DKIM1;") at its beginning, it is faced with deciding if this record was:
如果DKIM验证器发现选择器记录的开头有一个空的“g”字段（“g=；”），但没有“v”字段（“v=DKIM1；”），那么它将面临确定该记录是否为：
1. from a DK signer that transitioned to supporting DKIM but forgot to remove the "g" field (so that it could be used by both DK and DKIM verifiers); or
1. 来自一个DK签名者，该签名者转换为支持DKIM，但忘记删除“g”字段（以便DK和DKIM验证器都可以使用该字段）；或
2. from a DKIM signer that truly meant to use the empty "g" field but forgot to put in the "v" field. It is advised that you treat such records using the first interpretation, and treat such records as if the signer did not have a "g" field in the record.
2. 来自一个DKIM签名者，他真的想使用空的“g”字段，但忘了输入“v”字段。建议您使用第一种解释来处理此类记录，并将此类记录视为签名人在记录中没有“g”字段。
[RFC4871] defines the use of two hash algorithms: SHA-1 and SHA-256. The security of all hash algorithms is constantly under attack, and SHA-1 has already shown weaknesses as of this writing. Migrating from SHA-1 to SHA-256 is not an issue, because all verifiers are already required to support SHA-256. But when it becomes necessary to replace SHA-256 with a more secure algorithm, there will be a migratory period. In the following, "NEWHASH" is used to represent a new hash algorithm. Section 4.1 of [RFC4871] briefly discusses this scenario.
[RFC4871]定义了两种哈希算法的使用：SHA-1和SHA-256。所有散列算法的安全性都不断受到攻击，截至本文撰写之时，SHA-1已经显示出弱点。从SHA-1迁移到SHA-256不是问题，因为已经需要所有验证器来支持SHA-256。但当有必要用更安全的算法取代SHA-256时，将有一个迁移期。在下文中，“NEWHASH”用于表示新的哈希算法。[RFC4871]第4.1节简要讨论了这种情况。
As with migrating from DK to DKIM, migrating hash algorithms is dependent on the signer's best guess as to the utility of continuing to sign with the older algorithms and the expected support for the newer algorithm by verifiers. The utility of continuing to sign with the older algorithms is also based on how broken the existing hash algorithms are considered and how important that is to the signers.
与从DK迁移到DKIM一样，迁移哈希算法取决于签名者对继续使用旧算法签名的效用的最佳猜测，以及验证者对新算法的预期支持。继续使用旧算法签名的效用还取决于现有散列算法的破坏程度以及对签名者的重要性。
One strategy is to wait until it's determined that there is a large enough base of verifiers available that support NEWHASH, and then flash cut to the new algorithm.
一种策略是等待确定有足够多的验证器支持NEWHASH，然后快速切换到新算法。
Another strategy is to sign with both the old and new hash algorithms for a period of time. This is particularly useful for testing the new code to support the new hash algorithm, as verifiers will continue to accept the signature for the older hash algorithm and ought to ignore any signature that fails because the code is slightly wrong. Once the signer has determined that the new code is correct AND it's determined that there is a large enough base of verifiers available that support NEWHASH, the signer can flash cut to the new algorithm.
另一种策略是在一段时间内使用新旧哈希算法进行签名。这对于测试新代码以支持新的哈希算法特别有用，因为验证器将继续接受旧哈希算法的签名，并且应该忽略任何由于代码稍有错误而失败的签名。一旦签名者确定新代码是正确的，并且确定有足够多的验证器支持NEWHASH，签名者就可以快速切换到新算法。
One advantage migrating hash algorithms has is that the selector can be completely compatible for all hash algorithms. The key selector has an optional "h=" field that can be used to list the hash algorithms being used; it also is used to limit the algorithms that a
迁移哈希算法的一个优点是选择器可以完全兼容所有哈希算法。键选择器有一个可选的“h=”字段，可用于列出正在使用的哈希算法；它还用于限制
verifier will accept. If the signer is not currently using the key selector "h=" field, no change is required. If the signer is currently using the key selector "h=" field, NEWHASH will need to be added to the list, as in "h=sha256:NEWHASH;". (When the signer is no longer using SHA-256, it can be removed from the "h=" list.)
验证者将接受。如果签名人当前未使用密钥选择器“h=”字段，则无需更改。如果签名者当前正在使用密钥选择器“h=”字段，则需要将NEWHASH添加到列表中，如“h=sha256:NEWHASH；”。（当签名人不再使用SHA-256时，可以将其从“h=”列表中删除。）
When a new hash algorithm becomes standardized, it is best for a verifier to start supporting it as quickly as possible.
当一个新的哈希算法变得标准化时，验证器最好尽快开始支持它。
[RFC4871] defines the use of the RSA signing algorithm. Similar to hashes, signing algorithms are constantly under attack, and when it becomes necessary to replace RSA with a newer signing algorithm, there will be a migratory period. In the following, "NEWALG" is used to represent a new signing algorithm.
[RFC4871]定义了RSA签名算法的使用。与哈希算法类似，签名算法经常受到攻击，当需要用新的签名算法替换RSA时，将有一个迁移期。在下文中，“NEWALG”用于表示一种新的签名算法。
As with the other migration issues discussed above, migrating signing algorithms is dependent on the signer's best guess as to the utility of continuing to sign with the older algorithms and the expected support for the newer algorithm by verifiers. The utility of continuing to sign with the older algorithms is also based on how broken the existing signing algorithms are considered and how important that is to the signers.
与上面讨论的其他迁移问题一样，迁移签名算法取决于签名者对继续使用旧算法签名的效用的最佳猜测，以及验证者对新算法的预期支持。继续使用旧算法签名的效用还取决于现有签名算法的破坏程度以及对签名者的重要性。
As before, the two basic strategies are to 1) wait until there is sufficient base of verifiers available that support NEWALG and then do a flash cut to NEWALG, and 2) use a phased approach by signing with both the old and new algorithms before removing support for the old algorithm.
如前所述，两种基本策略是：1）等到有足够的验证器支持NEWALG，然后对NEWALG进行快速剪切；2）在取消对旧算法的支持之前，通过使用新旧算法进行签名，使用分阶段方法。
It is unlikely that a new algorithm would be able to use the same public key as "rsa", so using the same selector DNS record for both algorithms' keys is ruled out. Therefore, in order to use the new algorithm, a new DNS selector record would need to be deployed in parallel with the existing DNS selector record for the existing algorithm. The new DNS selector record would specify a different "k=" value to reflect the use of NEWALG.
新算法不太可能使用与“rsa”相同的公钥，因此不可能对两种算法的密钥使用相同的选择器DNS记录。因此，为了使用新算法，需要将新的DNS选择器记录与现有算法的现有DNS选择器记录并行部署。新的DNS选择器记录将指定一个不同的“k=”值以反映NEWALG的使用。
When a new hash algorithm becomes standardized, it is best for a verifier to start supporting it as quickly as possible.
当一个新的哈希算法变得标准化时，验证器最好尽快开始支持它。
NOTE: This section could possibly be changed into a reference to something else, such as another RFC.
注意：本节可能会更改为对其他内容的引用，例如另一个RFC。
Correct implementation of a cryptographic algorithm is a necessary but not a sufficient condition for the coding of cryptographic applications. Coding of cryptographic libraries requires close attention to security considerations that are unique to cryptographic applications.
密码算法的正确实现是加密应用程序编码的必要条件，但不是充分条件。加密库的编码需要密切关注加密应用程序特有的安全注意事项。
In addition to the usual security coding considerations, such as avoiding buffer or integer overflow and underflow, implementers need to pay close attention to management of cryptographic private keys and session keys, ensuring that these are correctly initialized and disposed of.
除了通常的安全编码注意事项（如避免缓冲区或整数溢出和下溢）外，实现人员还需要密切注意加密私钥和会话密钥的管理，确保这些密钥正确初始化和处置。
Operating system mechanisms that permit the confidentiality of private keys to be protected against other processes ought to be used when available. In particular, great care needs to be taken when releasing memory pages to the operating system to ensure that private key information is not disclosed to other processes.
在可用的情况下，应使用允许私钥的机密性免受其他进程保护的操作系统机制。特别是，在向操作系统释放内存页时，需要非常小心，以确保私钥信息不会泄露给其他进程。
Certain implementations of public key algorithms such as RSA can be vulnerable to a timing analysis attack.
公钥算法（如RSA）的某些实现可能容易受到定时分析攻击。
Support for cryptographic hardware providing key management capabilities is strongly encouraged. In addition to offering performance benefits, many cryptographic hardware devices provide robust and verifiable management of private keys.
强烈鼓励支持提供密钥管理功能的加密硬件。除了提供性能优势外，许多加密硬件设备还提供了对私钥的健壮且可验证的管理。
Fortunately, appropriately designed and coded cryptographic libraries are available for most operating system platforms under license terms compatible with commercial, open source and free software license terms. Use of standard cryptographic libraries is strongly encouraged. These have been extensively tested, reduce development time and support a wide range of cryptographic hardware.
幸运的是，在与商业、开源和自由软件许可条款兼容的许可条款下，大多数操作系统平台都可以使用经过适当设计和编码的加密库。强烈鼓励使用标准加密库。这些都经过了广泛的测试，减少了开发时间，并支持广泛的加密硬件。
Authors' Addresses
作者地址
Tony Hansen AT&T Laboratories 200 Laurel Ave. South Middletown, NJ 07748 USA
美国新泽西州南米德尔顿劳雷尔大道200号托尼·汉森AT&T实验室，邮编：07748
EMail: tony+dkimov@maillennium.att.com
EMail: tony+dkimov@maillennium.att.com
Ellen Siegel Consultant
艾伦·西格尔顾问
EMail: dkim@esiegel.net
EMail: dkim@esiegel.net
Phillip Hallam-Baker Default Deny Security, Inc.
Phillip Hallam Baker默认拒绝安全公司。
EMail: phillip@hallambaker.com
EMail: phillip@hallambaker.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