Internet Engineering Task Force (IETF) D. Crocker, Ed.
Request for Comments: 6376 Brandenburg InternetWorking
Obsoletes: 4871, 5672 T. Hansen, Ed.
Category: Standards Track AT&T Laboratories
ISSN: 2070-1721 M. Kucherawy, Ed.
Cloudmark
September 2011
Internet Engineering Task Force (IETF) D. Crocker, Ed.
Request for Comments: 6376 Brandenburg InternetWorking
Obsoletes: 4871, 5672 T. Hansen, Ed.
Category: Standards Track AT&T Laboratories
ISSN: 2070-1721 M. Kucherawy, Ed.
Cloudmark
September 2011
DomainKeys Identified Mail (DKIM) Signatures
域密钥识别邮件（DKIM）签名
Abstract
摘要
DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature.
DomainKeys Identified Mail（DKIM）允许拥有签名域的个人、角色或组织通过将域与消息关联来声明对消息的某些责任。这可以是作者的组织、操作中继或其代理之一。DKIM将消息签名者的身份问题与消息作者的身份问题分开。通过加密签名和直接查询签名者的域以检索适当的公钥来验证责任声明。消息从作者到收件人的传输是通过中继进行的，中继通常不对消息内容进行实质性更改，从而保留DKIM签名。
This memo obsoletes RFC 4871 and RFC 5672.
本备忘录废除了RFC 4871和RFC 5672。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc6376.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6376.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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
1.1. DKIM Architecture Documents . . . . . . . . . . . . . . . 5
1.2. Signing Identity . . . . . . . . . . . . . . . . . . . . . 5
1.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Simple Key Management . . . . . . . . . . . . . . . . . . 6
1.5. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6
2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 7
2.6. Agent or User Identifier (AUID) . . . . . . . . . . . . . 7
2.7. Identity Assessor . . . . . . . . . . . . . . . . . . . . 7
2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 8
2.9. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 8
2.10. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 9
2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 9
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 12
3.3. Signing and Verification Algorithms . . . . . . . . . . . 13
3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 14
3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. DKIM Architecture Documents . . . . . . . . . . . . . . . 5
1.2. Signing Identity . . . . . . . . . . . . . . . . . . . . . 5
1.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Simple Key Management . . . . . . . . . . . . . . . . . . 6
1.5. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6
2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 7
2.6. Agent or User Identifier (AUID) . . . . . . . . . . . . . 7
2.7. Identity Assessor . . . . . . . . . . . . . . . . . . . . 7
2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 8
2.9. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 8
2.10. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 9
2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 9
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 12
3.3. Signing and Verification Algorithms . . . . . . . . . . . 13
3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 14
3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 18
3.6. Key Management and Representation . . . . . . . . . . . . 26
3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 29
3.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 32
3.9. Output Requirements . . . . . . . . . . . . . . . . . . . 32
3.10. Signing by Parent Domains . . . . . . . . . . . . . . . . 33
3.11. Relationship between SDID and AUID . . . . . . . . . . . . 33
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 34
4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 34
4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 35
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1. Determine Whether the Email Should Be Signed and by
Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2. Select a Private Key and Corresponding Selector
Information . . . . . . . . . . . . . . . . . . . . . . . 37
5.3. Normalize the Message to Prevent Transport Conversions . . 37
5.4. Determine the Header Fields to Sign . . . . . . . . . . . 38
5.5. Compute the Message Hash and Signature . . . . . . . . . . 43
5.6. Insert the DKIM-Signature Header Field . . . . . . . . . . 43
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 43
6.1. Extract Signatures from the Message . . . . . . . . . . . 44
6.2. Communicate Verification Results . . . . . . . . . . . . . 49
6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 50
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
7.1. Email Authentication Methods Registry . . . . . . . . . . 51
7.2. DKIM-Signature Tag Specifications . . . . . . . . . . . . 51
7.3. DKIM-Signature Query Method Registry . . . . . . . . . . . 52
7.4. DKIM-Signature Canonicalization Registry . . . . . . . . . 52
7.5. _domainkey DNS TXT Resource Record Tag Specifications . . 53
7.6. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 53
7.7. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 54
7.8. DKIM Service Types Registry . . . . . . . . . . . . . . . 54
7.9. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 55
7.10. DKIM-Signature Header Field . . . . . . . . . . . . . . . 55
8. Security Considerations . . . . . . . . . . . . . . . . . . . 55
8.1. ASCII Art Attacks . . . . . . . . . . . . . . . . . . . . 55
8.2. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 55
8.3. Misappropriated Private Key . . . . . . . . . . . . . . . 56
8.4. Key Server Denial-of-Service Attacks . . . . . . . . . . . 56
8.5. Attacks against the DNS . . . . . . . . . . . . . . . . . 57
8.6. Replay/Spam Attacks . . . . . . . . . . . . . . . . . . . 57
8.7. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 58
8.8. Intentionally Malformed Key Records . . . . . . . . . . . 58
8.9. Intentionally Malformed DKIM-Signature Header Fields . . . 58
8.10. Information Leakage . . . . . . . . . . . . . . . . . . . 58
8.11. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 59
8.12. Reordered Header Fields . . . . . . . . . . . . . . . . . 59
8.13. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 59
8.14. Inappropriate Signing by Parent Domains . . . . . . . . . 59
3.6. Key Management and Representation . . . . . . . . . . . . 26
3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 29
3.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 32
3.9. Output Requirements . . . . . . . . . . . . . . . . . . . 32
3.10. Signing by Parent Domains . . . . . . . . . . . . . . . . 33
3.11. Relationship between SDID and AUID . . . . . . . . . . . . 33
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 34
4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 34
4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 35
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1. Determine Whether the Email Should Be Signed and by
Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2. Select a Private Key and Corresponding Selector
Information . . . . . . . . . . . . . . . . . . . . . . . 37
5.3. Normalize the Message to Prevent Transport Conversions . . 37
5.4. Determine the Header Fields to Sign . . . . . . . . . . . 38
5.5. Compute the Message Hash and Signature . . . . . . . . . . 43
5.6. Insert the DKIM-Signature Header Field . . . . . . . . . . 43
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 43
6.1. Extract Signatures from the Message . . . . . . . . . . . 44
6.2. Communicate Verification Results . . . . . . . . . . . . . 49
6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 50
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
7.1. Email Authentication Methods Registry . . . . . . . . . . 51
7.2. DKIM-Signature Tag Specifications . . . . . . . . . . . . 51
7.3. DKIM-Signature Query Method Registry . . . . . . . . . . . 52
7.4. DKIM-Signature Canonicalization Registry . . . . . . . . . 52
7.5. _domainkey DNS TXT Resource Record Tag Specifications . . 53
7.6. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 53
7.7. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 54
7.8. DKIM Service Types Registry . . . . . . . . . . . . . . . 54
7.9. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 55
7.10. DKIM-Signature Header Field . . . . . . . . . . . . . . . 55
8. Security Considerations . . . . . . . . . . . . . . . . . . . 55
8.1. ASCII Art Attacks . . . . . . . . . . . . . . . . . . . . 55
8.2. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 55
8.3. Misappropriated Private Key . . . . . . . . . . . . . . . 56
8.4. Key Server Denial-of-Service Attacks . . . . . . . . . . . 56
8.5. Attacks against the DNS . . . . . . . . . . . . . . . . . 57
8.6. Replay/Spam Attacks . . . . . . . . . . . . . . . . . . . 57
8.7. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 58
8.8. Intentionally Malformed Key Records . . . . . . . . . . . 58
8.9. Intentionally Malformed DKIM-Signature Header Fields . . . 58
8.10. Information Leakage . . . . . . . . . . . . . . . . . . . 58
8.11. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 59
8.12. Reordered Header Fields . . . . . . . . . . . . . . . . . 59
8.13. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 59
8.14. Inappropriate Signing by Parent Domains . . . . . . . . . 59
8.15. Attacks Involving Extra Header Fields . . . . . . . . . . 60
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61
9.1. Normative References . . . . . . . . . . . . . . . . . . . 61
9.2. Informative References . . . . . . . . . . . . . . . . . . 62
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 64
A.1. The User Composes an Email . . . . . . . . . . . . . . . . 64
A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 65
A.3. The Email Signature is Verified . . . . . . . . . . . . . 66
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 67
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 67
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 69
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 71
C.1. Compatibility with DomainKeys Key Records . . . . . . . . 72
C.2. RFC 4871 Compatibility . . . . . . . . . . . . . . . . . . 73
Appendix D. MUA Considerations (INFORMATIVE) . . . . . . . . . . 73
Appendix E. Changes since RFC 4871 . . . . . . . . . . . . . . . 73
Appendix F. Acknowledgments . . . . . . . . . . . . . . . . . . . 75
8.15. Attacks Involving Extra Header Fields . . . . . . . . . . 60
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61
9.1. Normative References . . . . . . . . . . . . . . . . . . . 61
9.2. Informative References . . . . . . . . . . . . . . . . . . 62
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 64
A.1. The User Composes an Email . . . . . . . . . . . . . . . . 64
A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 65
A.3. The Email Signature is Verified . . . . . . . . . . . . . 66
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 67
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 67
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 69
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 71
C.1. Compatibility with DomainKeys Key Records . . . . . . . . 72
C.2. RFC 4871 Compatibility . . . . . . . . . . . . . . . . . . 73
Appendix D. MUA Considerations (INFORMATIVE) . . . . . . . . . . 73
Appendix E. Changes since RFC 4871 . . . . . . . . . . . . . . . 73
Appendix F. Acknowledgments . . . . . . . . . . . . . . . . . . . 75
DomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name [RFC1034] with the message [RFC5322], which they are authorized to use. This can be an author's organization, an operational relay, or one of their agents. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. A message can contain multiple signatures, from the same or different organizations involved with the message.
DomainKeys Identified Mail（DKIM）允许个人、角色或组织通过将域名[RFC1034]与消息[RFC5322]关联来声明对消息的某些责任，并授权其使用。这可以是作者的组织、操作中继或其代理之一。通过加密签名和直接查询签名者的域以检索适当的公钥来验证责任声明。消息从作者到收件人的传输是通过中继进行的，中继通常不对消息内容进行实质性更改，从而保留DKIM签名。一封邮件可以包含多个签名，这些签名来自与该邮件相关的相同或不同的组织。
The approach taken by DKIM differs from previous approaches to message signing (e.g., Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC5751], OpenPGP [RFC4880]) in that:
DKIM采用的方法与以前的消息签名方法（例如，安全/多用途Internet邮件扩展（S/MIME）[RFC5751]，OpenPGP[RFC4880]）不同，因为：
o the message signature is written as a message header field so that neither human recipients nor existing MUA (Mail User Agent) software is confused by signature-related content appearing in the message body;
o 消息签名作为消息头字段写入，因此，消息正文中出现的签名相关内容不会混淆人工收件人和现有MUA（邮件用户代理）软件；
o there is no dependency on public- and private-key pairs being issued by well-known, trusted certificate authorities;
o 不依赖于由知名的可信证书颁发机构颁发的公钥和私钥对；
o there is no dependency on the deployment of any new Internet protocols or services for public-key distribution or revocation;
o 不依赖于部署任何新的互联网协议或服务来分发或撤销公钥；
o signature verification failure does not force rejection of the message;
o 签名验证失败不会强制拒绝消息；
o no attempt is made to include encryption as part of the mechanism; and
o 未尝试将加密作为机制的一部分；和
o message archiving is not a design goal.
o 邮件归档不是设计目标。
DKIM:
DKIM：
o is compatible with the existing email infrastructure and transparent to the fullest extent possible;
o 与现有的电子邮件基础设施兼容，并尽可能透明；
o requires minimal new infrastructure;
o 需要最少的新基础设施；
o can be implemented independently of clients in order to reduce deployment time;
o 可以独立于客户端实现，以减少部署时间；
o can be deployed incrementally; and
o 可以增量部署；和
o allows delegation of signing to third parties.
o 允许将签名委托给第三方。
Readers are advised to be familiar with the material in [RFC4686], [RFC5585], and [RFC5863], which provide the background for the development of DKIM, an overview of the service, and deployment and operations guidance and advice, respectively.
建议读者熟悉[RFC4686]、[RFC5585]和[RFC5863]中的内容，分别提供DKIM开发的背景、服务概述以及部署和操作指导和建议。
DKIM separates the question of the identity of the Signer of the message from the purported author of the message. In particular, a signature includes the identity of the Signer. Verifiers can use the signing information to decide how they want to process the message. The signing identity is included as part of the signature header field.
DKIM将消息签名者的身份问题与消息作者的身份问题分开。特别是，签名包括签名人的身份。验证器可以使用签名信息来决定如何处理消息。签名标识包含在签名头字段中。
INFORMATIVE RATIONALE: The signing identity specified by a DKIM signature is not required to match an address in any particular header field because of the broad methods of interpretation by recipient mail systems, including MUAs.
资料性理由：DKIM签名指定的签名标识不需要与任何特定标头字段中的地址匹配，因为收件人邮件系统（包括MUA）有广泛的解释方法。
DKIM is designed to support the extreme scalability requirements that characterize the email identification problem. There are many millions of domains and a much larger number of individual addresses.
DKIM旨在支持电子邮件识别问题的极端可扩展性需求。有数以百万计的域和大量的单个地址。
DKIM seeks to preserve the positive aspects of the current email infrastructure, such as the ability for anyone to communicate with anyone else without introduction.
DKIM力求保留当前电子邮件基础设施的积极方面，例如任何人都可以不经介绍就与其他人交流。
DKIM differs from traditional hierarchical public-key systems in that no certificate authority infrastructure is required; the Verifier requests the public key from a repository in the domain of the claimed Signer directly rather than from a third party.
DKIM不同于传统的分层公钥系统，它不需要证书颁发机构基础设施；验证器直接从声明的签名者域中的存储库而不是从第三方请求公钥。
The DNS is proposed as the initial mechanism for the public keys. Thus, DKIM currently depends on DNS administration and the security of the DNS system. DKIM is designed to be extensible to other key fetching services as they become available.
DNS被提议作为公钥的初始机制。因此，DKIM目前依赖于DNS管理和DNS系统的安全性。DKIM被设计为在其他密钥获取服务可用时可扩展到这些服务。
A DKIM signature associates the "d=" name with the computed hash of some or all of the message (see Section 3.7) in order to prevent the reuse of the signature with different messages. Verifying the signature asserts that the hashed content has not changed since it was signed and asserts nothing else about "protecting" the end-to-end integrity of the message.
DKIM签名将“d=”名称与部分或全部消息的计算散列相关联（见第3.7节），以防止对不同消息重复使用签名。验证签名会断言哈希内容自签名后没有发生更改，并且不会断言其他任何关于“保护”消息端到端完整性的内容。
This section defines terms used in the rest of the document.
本节定义了文档其余部分中使用的术语。
DKIM is designed to operate within the Internet Mail service, as defined in [RFC5598]. Basic email terminology is taken from that specification.
DKIM设计用于在[RFC5598]中定义的互联网邮件服务中运行。基本电子邮件术语取自该规范。
Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
语法描述使用增广的BNF（ABNF）[RFC5234]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These words take their normative meanings only when they are presented in ALL UPPERCASE.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。这些词只有在全部大写时才具有规范意义。
Elements in the mail system that sign messages on behalf of a domain are referred to as Signers. These may be MUAs (Mail User Agents), MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other agents such as mailing list exploders. In general, any Signer will
邮件系统中代表域对邮件进行签名的元素称为签名者。这些代理可以是MUA（邮件用户代理）、MSA（邮件提交代理）、MTA（邮件传输代理）或其他代理，如邮件列表爆炸器。一般来说，任何签名者都会
be involved in the injection of a message into the message system in some way. The key issue is that a message must be signed before it leaves the administrative domain of the Signer.
以某种方式将消息注入消息系统。关键问题是，在消息离开签名者的管理域之前，必须对其进行签名。
Elements in the mail system that verify signatures are referred to as Verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. In most cases, it is expected that Verifiers will be close to an end user (reader) of the message or some consuming agent such as a mailing list exploder.
邮件系统中验证签名的元素称为验证器。这些可能是MTA、邮件传递代理（MDA）或MUA。在大多数情况下，预计验证者将接近消息的最终用户（读者）或某些消费代理，如邮件列表分解器。
A person, role, or organization. In the context of DKIM, examples include the author, the author's organization, an ISP along the handling path, an independent trust assessment service, and a mailing list operator.
个人、角色或组织。在DKIM的上下文中，示例包括作者、作者的组织、处理路径上的ISP、独立的信任评估服务和邮件列表操作员。
A label that refers to an identity.
指代身份的标签。
A single domain name that is the mandatory payload output of DKIM and that refers to the identity claiming some responsibility for the message by signing it. It is specified in Section 3.5.
一个域名，是DKIM的强制有效负载输出，它指的是通过签名声明对消息负有某种责任的身份。第3.5节对此进行了规定。
A single identifier that refers to the agent or user on behalf of whom the Signing Domain Identifier (SDID) has taken responsibility. The AUID comprises a domain name and an optional <local-part>. The domain name is the same as that used for the SDID or is a subdomain of it. For DKIM processing, the domain name portion of the AUID has only basic domain name semantics; any possible owner-specific semantics are outside the scope of DKIM. It is specified in Section 3.5.
指代签名域标识符（SDID）所代表的代理或用户的单个标识符。AUID包括域名和可选的<local part>。域名与SDID使用的域名相同，或者是SDID的子域。对于DKIM处理，AUID的域名部分只有基本的域名语义；任何可能的特定于所有者的语义都不在DKIM的范围之内。第3.5节对此进行了规定。
Note that acceptable values for the AUID may be constrained via a flag in the public-key record. (See Section 3.6.1.)
注意，AUID的可接受值可以通过公钥记录中的标志来约束。（见第3.6.1节。）
An element in the mail system that consumes DKIM's payload, which is the responsible Signing Domain Identifier (SDID). The Identity Assessor is dedicated to the assessment of the delivered identifier.
邮件系统中使用DKIM有效负载的元素，该有效负载是负责签名的域标识符（SDID）。身份评估员专门负责评估交付的标识符。
Other DKIM (and non-DKIM) values can also be used by the Identity Assessor (if they are available) to provide a more general message evaluation filtering engine. However, this additional activity is outside the scope of this specification.
身份评估器也可以使用其他DKIM（和非DKIM）值（如果可用），以提供更通用的消息评估过滤引擎。但是，此附加活动不在本规范的范围内。
There are three forms of whitespace:
空格有三种形式：
o WSP represents simple whitespace, i.e., a space or a tab character (formal definition in [RFC5234]).
o WSP表示简单的空白，即空格或制表符（在[RFC5234]中有正式定义）。
o LWSP is linear whitespace, defined as WSP plus CRLF (formal definition in [RFC5234]).
o LWSP是线性空白，定义为WSP加CRLF（在[RFC5234]中有正式定义）。
o FWS is folding whitespace. It allows multiple lines separated by CRLF followed by at least one whitespace, to be joined.
o FWS正在折叠空格。它允许将多行由CRLF分隔，后跟至少一个空格的行连接起来。
The formal ABNF for these are (WSP and LWSP are given for information only):
这些项目的正式ABNF为（WSP和LWSP仅供参考）：
WSP = SP / HTAB
LWSP = *(WSP / CRLF WSP)
FWS = [*WSP CRLF] 1*WSP
WSP = SP / HTAB
LWSP = *(WSP / CRLF WSP)
FWS = [*WSP CRLF] 1*WSP
The definition of FWS is identical to that in [RFC5322] except for the exclusion of obs-FWS.
除了排除obs FWS外，FWS的定义与[RFC5322]中的定义相同。
The following tokens are imported from other RFCs as noted. Those RFCs should be considered definitive.
如前所述，以下令牌是从其他RFC导入的。这些RFC应被视为确定的。
The following tokens are imported from [RFC5321]:
以下令牌从[RFC5321]导入：
o "local-part" (implementation warning: this permits quoted strings)
o “本地部分”（实现警告：这允许引用字符串）
o "sub-domain"
o “子域”
The following tokens are imported from [RFC5322]:
以下令牌从[RFC5322]导入：
o "field-name" (name of a header field)
o “字段名”（标题字段的名称）
o "dot-atom-text" (in the local-part of an email address)
o “点原子文本”（在电子邮件地址的本地部分）
The following tokens are imported from [RFC2045]:
以下令牌从[RFC2045]导入：
o "qp-section" (a single line of quoted-printable-encoded text)
o “qp部分”（引用的可打印编码文本的单行）
o "hex-octet" (a quoted-printable encoded octet)
o “十六进制八位字节”（引用的可打印编码八位字节）
INFORMATIVE NOTE: Be aware that the ABNF in [RFC2045] does not obey the rules of [RFC5234] and must be interpreted accordingly, particularly as regards case folding.
资料性说明：请注意，[RFC2045]中的ABNF不符合[RFC5234]的规则，必须进行相应的解释，尤其是在箱子折叠方面。
Other tokens not defined herein are imported from [RFC5234]. These are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, etc.
此处未定义的其他令牌从[RFC5234]导入。这些是直观的原语，如SP、HTAB、WSP、ALPHA、DIGIT、CRLF等。
The following ABNF tokens are used elsewhere in this document:
以下ABNF代币在本文件其他地方使用：
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ]
ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/")
base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS)
[ [FWS] "=" [ [FWS] "=" ] ]
hdr-name = field-name
qp-hdr-value = dkim-quoted-printable ; with "|" encoded
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ]
ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/")
base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS)
[ [FWS] "=" [ [FWS] "=" ] ]
hdr-name = field-name
qp-hdr-value = dkim-quoted-printable ; with "|" encoded
The DKIM-Quoted-Printable encoding syntax resembles that described in Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded as an "=" followed by two hexadecimal digits from the alphabet "0123456789ABCDEF" (no lowercase characters permitted) representing the hexadecimal-encoded integer value of that character. All control characters (those with values < %x20), 8-bit characters (values > %x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon (";", %x3B) MUST be encoded. Note that all whitespace, including SPACE, CR, and LF characters, MUST be encoded. After encoding, FWS MAY be added at arbitrary locations in order to avoid excessively long lines; such whitespace is NOT part of the value, and MUST be removed before decoding. Use of characters not listed as "mail-safe" in [RFC2049] is NOT RECOMMENDED.
DKIM Quoted Printable编码语法与Quoted Printable[RFC2045]第6.7节中所述类似：任何字符都可以编码为“=”后跟字母表“0123456789ABCDEF”中的两个十六进制数字（不允许使用小写字符），表示该字符的十六进制编码整数值。必须对所有控制字符（值<%x20的控制字符）、8位字符（值>%x7F）以及字符DEL（%x7F）、空格（%x20）和分号（“；”、%x3B）进行编码。请注意，所有空格，包括空格、CR和LF字符，都必须进行编码。编码后，可以在任意位置添加FWS，以避免过长的线；此类空白不是值的一部分，必须在解码之前删除。不建议使用[RFC2049]中未列为“邮件安全”的字符。
ABNF:
荷兰银行：
dkim-quoted-printable = *(FWS / hex-octet / dkim-safe-char)
; hex-octet is from RFC2045
dkim-safe-char = %x21-3A / %x3C / %x3E-7E
; '!' - ':', '<', '>' - '~'
dkim-quoted-printable = *(FWS / hex-octet / dkim-safe-char)
; hex-octet is from RFC2045
dkim-safe-char = %x21-3A / %x3C / %x3E-7E
; '!' - ':', '<', '>' - '~'
INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted-Printable as defined in [RFC2045] in several important ways:
资料性说明：DKIM引用可打印文件与[RFC2045]中定义的引用可打印文件在几个重要方面有所不同：
1. Whitespace in the input text, including CR and LF, must be encoded. [RFC2045] does not require such encoding, and does not permit encoding of CR or LF characters that are part of a CRLF line break.
1. 输入文本中的空白，包括CR和LF，必须进行编码。[RFC2045]不需要这种编码，也不允许对作为CRLF换行符一部分的CR或LF字符进行编码。
2. Whitespace in the encoded text is ignored. This is to allow tags encoded using DKIM-Quoted-Printable to be wrapped as needed. In particular, [RFC2045] requires that line breaks in the input be represented as physical line breaks; that is not the case here.
2. 编码文本中的空白将被忽略。这是为了允许根据需要包装使用DKIM Quoted Printable编码的标签。特别是，[RFC2045]要求将输入中的换行符表示为物理换行符；这里的情况并非如此。
3. The "soft line break" syntax ("=" as the last non-whitespace character on the line) does not apply.
3. “软换行符”语法（“=”作为行上最后一个非空白字符）不适用。
4. DKIM-Quoted-Printable does not require that encoded lines be no more than 76 characters long (although there may be other requirements depending on the context in which the encoded text is being used).
4. DKIM Quoted Printable不要求编码行长度不超过76个字符（尽管根据使用编码文本的上下文可能有其他要求）。
Protocol Elements are conceptual parts of the protocol that are not specific to either Signers or Verifiers. The protocol descriptions for Signers and Verifiers are described in later sections ("Signer Actions" (Section 5) and "Verifier Actions" (Section 6)). NOTE: This section must be read in the context of those sections.
协议元素是协议的概念部分，不特定于签名者或验证者。签名者和验证者的协议描述将在后面的章节（“签名者操作”（第5节）和“验证者操作”（第6节）中描述。注意：本节必须在这些章节的上下文中阅读。
To support multiple concurrent public keys per signing domain, the key namespace is subdivided using "selectors". For example, selectors might indicate the names of office locations (e.g., "sanfrancisco", "coolumbeach", and "reykjavik"), the signing date (e.g., "january2005", "february2005", etc.), or even an individual user.
为了支持每个签名域的多个并发公钥，使用“选择器”对密钥命名空间进行细分。例如，选择器可能指示办公地点的名称（例如，“旧金山”、“库伦巴奇”和“雷克雅未克”）、签署日期（例如“2005年1月2日”、“2005年2月”等），甚至是个人用户。
Selectors are needed to support some important use cases. For example:
选择器需要支持一些重要的用例。例如：
o Domains that want to delegate signing capability for a specific address for a given duration to a partner, such as an advertising provider or other outsourced function.
o 希望将特定地址的签名功能在给定期限内委托给合作伙伴的域，例如广告提供商或其他外包功能。
o Domains that want to allow frequent travelers to send messages locally without the need to connect with a particular MSA.
o 希望允许常客在本地发送消息而无需连接特定MSA的域。
o "Affinity" domains (e.g., college alumni associations) that provide forwarding of incoming mail, but that do not operate a mail submission agent for outgoing mail.
o “亲缘”域（例如，大学校友会），提供传入邮件的转发，但不操作传出邮件的邮件提交代理。
Periods are allowed in selectors and are component separators. When keys are retrieved from the DNS, periods in selectors define DNS label boundaries in a manner similar to the conventional use in domain names. Selector components might be used to combine dates with locations, for example, "march2005.reykjavik". In a DNS implementation, this can be used to allow delegation of a portion of the selector namespace.
句点在选择器中是允许的，并且是组件分隔符。当从DNS检索密钥时，选择器中的句点以类似于域名中常规使用的方式定义DNS标签边界。选择器组件可用于将日期与位置组合在一起，例如，“2005年3月2日。雷克雅未克”。在DNS实现中，这可用于允许对选择器命名空间的一部分进行委派。
ABNF:
荷兰银行：
selector = sub-domain *( "." sub-domain )
选择器=子域*（“”子域）
The number of public keys and corresponding selectors for each domain is determined by the domain owner. Many domain owners will be satisfied with just one selector, whereas administratively distributed organizations can choose to manage disparate selectors and key pairs in different regions or on different email servers.
每个域的公钥和相应选择器的数量由域所有者确定。许多域所有者只会对一个选择器感到满意，而管理分布式组织可以选择在不同的区域或不同的电子邮件服务器上管理不同的选择器和密钥对。
Beyond administrative convenience, selectors make it possible to seamlessly replace public keys on a routine basis. If a domain wishes to change from using a public key associated with selector "january2005" to a public key associated with selector "february2005", it merely makes sure that both public keys are advertised in the public-key repository concurrently for the transition period during which email may be in transit prior to verification. At the start of the transition period, the outbound email servers are configured to sign with the "february2005" private key. At the end of the transition period, the "january2005" public key is removed from the public-key repository.
除了方便管理之外，选择器还可以在日常基础上无缝替换公钥。如果域希望从使用与选择器“january2005”关联的公钥更改为与选择器“february2005”关联的公钥，则它仅确保在验证前电子邮件可能正在传输的过渡期间，在公钥存储库中同时公布这两个公钥。在过渡期开始时，出站电子邮件服务器配置为使用“february2005”私钥签名。在过渡期结束时，“2005年1月2日”公钥将从公钥存储库中删除。
INFORMATIVE NOTE: A key may also be revoked as described below. The distinction between revoking and removing a key selector record is subtle. When phasing out keys as described above, a signing domain would probably simply remove the key record after the transition period. However, a signing domain could elect to revoke the key (but maintain the key record) for a further period. There is no defined semantic difference between a revoked key and a removed key.
资料性说明：密钥也可以按如下所述撤销。撤销和删除键选择器记录之间的区别很微妙。当如上所述逐步淘汰密钥时，签名域可能只会在过渡期之后删除密钥记录。但是，签名域可以选择撤销密钥（但保留密钥记录）一段时间。撤销的密钥和删除的密钥之间没有定义的语义差异。
While some domains may wish to make selector values well-known, others will want to take care not to allocate selector names in a way that allows harvesting of data by outside parties. For example, if per-user keys are issued, the domain owner will need to decide
虽然一些域可能希望使选择器值众所周知，但其他域希望注意不要以允许外部方获取数据的方式分配选择器名称。例如，如果颁发了每个用户的密钥，则域所有者需要做出决定
whether to associate this selector directly with the name of a registered end user or make it some unassociated random value, such as a fingerprint of the public key.
是将此选择器直接与已注册最终用户的名称关联，还是将其设置为一些未关联的随机值，例如公钥的指纹。
INFORMATIVE OPERATIONS NOTE: Reusing a selector with a new key (for example, changing the key associated with a user's name) makes it impossible to tell the difference between a message that didn't verify because the key is no longer valid and a message that is actually forged. For this reason, Signers are ill-advised to reuse selectors for new keys. A better strategy is to assign new keys to new selectors.
信息性操作说明：使用新密钥重新使用选择器（例如，更改与用户名关联的密钥）将无法区分由于密钥不再有效而未验证的消息与实际伪造的消息之间的区别。出于这个原因，不建议签名者为新密钥重新使用选择器。更好的策略是将新键分配给新选择器。
DKIM uses a simple "tag=value" syntax in several contexts, including in messages and domain signature records.
DKIM在多个上下文中使用简单的“tag=value”语法，包括在消息和域签名记录中。
Values are a series of strings containing either plain text, "base64" text (as defined in [RFC2045], Section 6.8), "qp-section" (ibid, Section 6.7), or "dkim-quoted-printable" (as defined in Section 2.11). The name of the tag will determine the encoding of each value. Unencoded semicolon (";") characters MUST NOT occur in the tag value, since that separates tag-specs.
值是一系列字符串，包含纯文本、“base64”文本（定义见[RFC2045]第6.8节）、“qp节”（同上，第6.7节）或“dkim引用可打印”（定义见第2.11节）。标记的名称将决定每个值的编码。未编码的分号（；）字符不能出现在标记值中，因为这分隔了标记规范。
INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined below (as "tag-value") only includes 7-bit characters, an implementation that wished to anticipate future standards would be advised not to preclude the use of UTF-8-encoded ([RFC3629]) text in tag=value lists.
资料性实施说明：尽管下文定义的“纯文本”（作为“标记值”）仅包括7位字符，但建议希望预测未来标准的实施不要排除在标记=值列表中使用UTF-8编码（[RFC3629]）文本。
Formally, the ABNF syntax rules are as follows:
形式上，ABNF语法规则如下：
tag-list = tag-spec *( ";" tag-spec ) [ ";" ]
tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-name = ALPHA *ALNUMPUNC
tag-value = [ tval *( 1*(WSP / FWS) tval ) ]
; Prohibits WSP and FWS at beginning and end
tval = 1*VALCHAR
VALCHAR = %x21-3A / %x3C-7E
; EXCLAMATION to TILDE except SEMICOLON
ALNUMPUNC = ALPHA / DIGIT / "_"
tag-list = tag-spec *( ";" tag-spec ) [ ";" ]
tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-name = ALPHA *ALNUMPUNC
tag-value = [ tval *( 1*(WSP / FWS) tval ) ]
; Prohibits WSP and FWS at beginning and end
tval = 1*VALCHAR
VALCHAR = %x21-3A / %x3C-7E
; EXCLAMATION to TILDE except SEMICOLON
ALNUMPUNC = ALPHA / DIGIT / "_"
Note that WSP is allowed anywhere around tags. In particular, any WSP after the "=" and any WSP before the terminating ";" is not part of the value; however, WSP inside the value is significant.
请注意，标签周围的任何地方都允许WSP。特别是“=”之后的任何WSP和终止“；”之前的任何WSP不是该值的一部分；但是，WSP内的值是重要的。
Tags MUST be interpreted in a case-sensitive manner. Values MUST be processed as case sensitive unless the specific tag description of semantics specifies case insensitivity.
必须以区分大小写的方式解释标记。除非语义的特定标记描述指定不区分大小写，否则值必须作为区分大小写处理。
Tags with duplicate names MUST NOT occur within a single tag-list; if a tag name does occur more than once, the entire tag-list is invalid.
具有重复名称的标签不得出现在单个标签列表中；如果某个标记名出现多次，则整个标记列表无效。
Whitespace within a value MUST be retained unless explicitly excluded by the specific tag description.
除非特定标记说明明确排除，否则必须保留值中的空白。
Tag=value pairs that represent the default value MAY be included to aid legibility.
标记=表示默认值的值对可以包括在内，以帮助识别。
Unrecognized tags MUST be ignored.
必须忽略无法识别的标记。
Tags that have an empty value are not the same as omitted tags. An omitted tag is treated as having the default value; a tag with an empty value explicitly designates the empty string as the value.
具有空值的标记与省略的标记不同。省略的标记被视为具有默认值；带有空值的标记将空字符串显式指定为值。
DKIM supports multiple digital signature algorithms. Two algorithms are defined by this specification at this time: rsa-sha1 and rsa-sha256. Signers MUST implement and SHOULD sign using rsa-sha256. Verifiers MUST implement both rsa-sha1 and rsa-sha256.
DKIM支持多种数字签名算法。本规范目前定义了两种算法：rsa-sha1和rsa-sha256。签名者必须实现并应使用rsa-sha256签名。验证器必须同时实现rsa-sha1和rsa-sha256。
INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some senders might prefer to use rsa-sha1 when balancing security strength against performance, complexity, or other needs. In general, however, rsa-sha256 should always be used whenever possible.
资料性说明：尽管强烈建议使用rsa-sha256，但在平衡安全强度与性能、复杂性或其他需要时，某些发件人可能更喜欢使用rsa-sha1。但是，一般来说，只要可能，就应该始终使用rsa-sha256。
The rsa-sha1 Signing Algorithm computes a message hash as described in Section 3.7 using SHA-1 [FIPS-180-3-2008] as the hash-alg. That hash is then signed by the Signer using the RSA algorithm (defined in Public-Key Cryptography Standards (PKCS) #1 version 1.5 [RFC3447]) as the crypt-alg and the Signer's private key. The hash MUST NOT be truncated or converted into any form other than the native binary form before being signed. The signing algorithm SHOULD use a public exponent of 65537.
rsa-sha1签名算法使用SHA-1[FIPS-180-3-2008]作为哈希alg，按照第3.7节所述计算消息哈希。然后签名者使用RSA算法（在公钥加密标准（PKCS）第1版1.5[RFC3447]中定义）作为密码alg和签名者的私钥对该散列进行签名。在签名之前，哈希不能被截断或转换为本机二进制形式以外的任何形式。签名算法应使用65537的公共指数。
The rsa-sha256 Signing Algorithm computes a message hash as described in Section 3.7 using SHA-256 [FIPS-180-3-2008] as the hash-alg. That hash is then signed by the Signer using the RSA algorithm (defined in
rsa-sha256签名算法使用SHA-256[FIPS-180-3-2008]作为哈希alg，按照第3.7节所述计算消息哈希。然后签名者使用RSA算法（在中定义）对该散列进行签名
PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the Signer's private key. The hash MUST NOT be truncated or converted into any form other than the native binary form before being signed. The signing algorithm SHOULD use a public exponent of 65537.
PKCS#1 1.5版[RFC3447]）作为密码alg和签名者的私钥。在签名之前，哈希不能被截断或转换为本机二进制形式以外的任何形式。签名算法应使用65537的公共指数。
Selecting appropriate key sizes is a trade-off between cost, performance, and risk. Since short RSA keys more easily succumb to off-line attacks, Signers MUST use RSA keys of at least 1024 bits for long-lived keys. Verifiers MUST be able to validate signatures with keys ranging from 512 bits to 2048 bits, and they MAY be able to validate signatures with larger keys. Verifier policies may use the length of the signing key as one metric for determining whether a signature is acceptable.
选择合适的密钥大小是成本、性能和风险之间的权衡。由于短RSA密钥更容易受到离线攻击，签名者必须使用至少1024位的RSA密钥作为长密钥。验证器必须能够使用512位到2048位的密钥验证签名，并且可以使用更大的密钥验证签名。验证器策略可以使用签名密钥的长度作为确定签名是否可接受的一个度量。
Factors that should influence the key size choice include the following:
影响关键尺寸选择的因素包括：
o The practical constraint that large (e.g., 4096-bit) keys might not fit within a 512-byte DNS UDP response packet
o 大（例如，4096位）密钥可能不适合512字节DNS UDP响应数据包的实际约束
o The security constraint that keys smaller than 1024 bits are subject to off-line attacks
o 安全约束，即小于1024位的密钥会受到离线攻击
o Larger keys impose higher CPU costs to verify and sign email
o 密钥越大，验证和签署电子邮件的CPU成本就越高
o Keys can be replaced on a regular basis; thus, their lifetime can be relatively short
o 钥匙可以定期更换；因此，它们的寿命可能相对较短
o The security goals of this specification are modest compared to typical goals of other systems that employ digital signatures
o 与采用数字签名的其他系统的典型目标相比，本规范的安全目标是适度的
See [RFC3766] for further discussion on selecting key sizes.
有关选择键尺寸的进一步讨论，请参见[RFC3766]。
Other algorithms MAY be defined in the future. Verifiers MUST ignore any signatures using algorithms that they do not implement.
将来可能会定义其他算法。验证者必须忽略任何使用他们没有实现的算法的签名。
Some mail systems modify email in transit, potentially invalidating a signature. For most Signers, mild modification of email is immaterial to validation of the DKIM domain name's use. For such Signers, a canonicalization algorithm that survives modest in-transit modification is preferred.
一些邮件系统在传输过程中修改电子邮件，可能使签名无效。对于大多数签名者来说，对电子邮件的轻微修改对于验证DKIM域名的使用是无关紧要的。对于这样的签名者，最好使用一种能够在传输过程中进行适度修改的规范化算法。
Other Signers demand that any modification of the email, however minor, result in a signature verification failure. These Signers prefer a canonicalization algorithm that does not tolerate in-transit modification of the signed email.
其他签名者要求对电子邮件的任何修改，无论多么轻微，都会导致签名验证失败。这些签名者更喜欢规范化算法，该算法不允许在传输过程中修改已签名的电子邮件。
Some Signers may be willing to accept modifications to header fields that are within the bounds of email standards such as [RFC5322], but are unwilling to accept any modification to the body of messages.
一些签名者可能愿意接受对邮件标准（如[RFC5322]）范围内的标题字段的修改，但不愿意接受对邮件正文的任何修改。
To satisfy all requirements, two canonicalization algorithms are defined for each of the header and the body: a "simple" algorithm that tolerates almost no modification and a "relaxed" algorithm that tolerates common modifications such as whitespace replacement and header field line rewrapping. A Signer MAY specify either algorithm for header or body when signing an email. If no canonicalization algorithm is specified by the Signer, the "simple" algorithm defaults for both header and body. Verifiers MUST implement both canonicalization algorithms. Note that the header and body may use different canonicalization algorithms. Further canonicalization algorithms MAY be defined in the future; Verifiers MUST ignore any signatures that use unrecognized canonicalization algorithms.
为了满足所有要求，为每个标头和正文定义了两种规范化算法：一种“简单”算法，几乎不允许任何修改；另一种“宽松”算法，允许常见修改，例如空格替换和标头字段行重写。签名者在签署电子邮件时可以指定邮件头或邮件体的算法。如果签名者未指定规范化算法，则“简单”算法默认用于标头和正文。验证器必须实现两种规范化算法。请注意，头部和主体可能使用不同的规范化算法。将来可能会定义进一步的规范化算法；验证器必须忽略使用无法识别的规范化算法的任何签名。
Canonicalization simply prepares the email for presentation to the signing or verification algorithm. It MUST NOT change the transmitted data in any way. Canonicalization of header fields and body are described below.
规范化只是为向签名或验证算法演示电子邮件做准备。不得以任何方式更改传输的数据。标题字段和正文的规范化描述如下。
NOTE: This section assumes that the message is already in "network normal" format (text is ASCII encoded, lines are separated with CRLF characters, etc.). See also Section 5.3 for information about normalizing the message.
注：本节假设消息已采用“网络正常”格式（文本为ASCII编码，行之间用CRLF字符分隔，等等）。有关消息规范化的信息，请参见第5.3节。
The "simple" header canonicalization algorithm does not change header fields in any way. Header fields MUST be presented to the signing or verification algorithm exactly as they are in the message being signed or verified. In particular, header field names MUST NOT be case folded and whitespace MUST NOT be changed.
“简单”头规范化算法不会以任何方式更改头字段。标头字段必须与正在签名或验证的消息中的字段完全相同，呈现给签名或验证算法。特别是，标题字段名称不能大小写折叠，空格不能更改。
The "relaxed" header canonicalization algorithm MUST apply the following steps in order:
“松弛”标头规范化算法必须按顺序应用以下步骤：
o Convert all header field names (not the header field values) to lowercase. For example, convert "SUBJect: AbC" to "subject: AbC".
o 将所有标题字段名称（不是标题字段值）转换为小写。例如，将“主题：AbC”转换为“主题：AbC”。
o Unfold all header field continuation lines as described in [RFC5322]; in particular, lines with terminators embedded in continued header field values (that is, CRLF sequences followed by WSP) MUST be interpreted without the CRLF. Implementations MUST NOT remove the CRLF at the end of the header field value.
o 按照[RFC5322]中的说明展开所有标题字段续行；特别是，必须在不使用CRLF的情况下解释连续标头字段值（即CRLF序列后跟WSP）中嵌入终止符的行。实施不得删除标题字段值末尾的CRLF。
o Convert all sequences of one or more WSP characters to a single SP character. WSP characters here include those before and after a line folding boundary.
o 将一个或多个WSP字符的所有序列转换为单个SP字符。这里的WSP字符包括折线边界前后的字符。
o Delete all WSP characters at the end of each unfolded header field value.
o 删除每个展开的标题字段值末尾的所有WSP字符。
o Delete any WSP characters remaining before and after the colon separating the header field name from the header field value. The colon separator MUST be retained.
o 删除头字段名称与头字段值之间的冒号前后剩余的任何WSP字符。必须保留冒号分隔符。
The "simple" body canonicalization algorithm ignores all empty lines at the end of the message body. An empty line is a line of zero length after removal of the line terminator. If there is no body or no trailing CRLF on the message body, a CRLF is added. It makes no other changes to the message body. In more formal terms, the "simple" body canonicalization algorithm converts "*CRLF" at the end of the body to a single "CRLF".
“简单”正文规范化算法忽略消息正文末尾的所有空行。空行是指移除行终止符后长度为零的行。如果消息正文上没有正文或没有尾随CRLF，则添加一个CRLF。它不会对消息体进行其他更改。在更正式的术语中，“简单”正文规范化算法将正文末尾的“*CRLF”转换为单个“CRLF”。
Note that a completely empty or missing body is canonicalized as a single "CRLF"; that is, the canonicalized length will be 2 octets.
请注意，一个完全空的或缺失的主体被规范化为一个“CRLF”；也就是说，规范化长度将是2个八位字节。
The SHA-1 value (in base64) for an empty body (canonicalized to a "CRLF") is:
空主体（规范化为“CRLF”）的SHA-1值（在base64中）为：
uoq1oCgLlTqpdDX/iUbLy7J1Wic=
uoq1oCgLlTqpdDX/iUbLy7J1Wic=
The SHA-256 value is:
SHA-256值为：
frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=
frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=
The "relaxed" body canonicalization algorithm MUST apply the following steps (a) and (b) in order:
“放松”主体规范化算法必须按顺序应用以下步骤（a）和（b）：
a. Reduce whitespace:
a. 减少空白：
* Ignore all whitespace at the end of lines. Implementations MUST NOT remove the CRLF at the end of the line.
* 忽略行末尾的所有空白。实施不得移除生产线末端的CRLF。
* Reduce all sequences of WSP within a line to a single SP character.
* 将一行中的所有WSP序列减少为单个SP字符。
b. Ignore all empty lines at the end of the message body. "Empty line" is defined in Section 3.4.3. If the body is non-empty but does not end with a CRLF, a CRLF is added. (For email, this is only possible when using extensions to SMTP or non-SMTP transport mechanisms.)
b. 忽略消息正文末尾的所有空行。第3.4.3节定义了“空行”。如果主体非空但未以CRLF结尾，则添加CRLF。（对于电子邮件，这仅在使用SMTP或非SMTP传输机制的扩展时才可能。）
The SHA-1 value (in base64) for an empty body (canonicalized to a null input) is:
空正文（规范化为空输入）的SHA-1值（在base64中）为：
2jmj7l5rSw0yVb/vlWAYkK/YBwk=
2jmj7l5rSw0yVb/vlWAYkK/YBwk=
The SHA-256 value is:
SHA-256值为：
47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
In the following examples, actual whitespace is used only for clarity. The actual input and output text is designated using bracketed descriptors: "<SP>" for a space character, "<HTAB>" for a tab character, and "<CRLF>" for a carriage-return/line-feed sequence. For example, "X <SP> Y" and "X<SP>Y" represent the same three characters.
在下面的示例中，实际空白仅用于清晰。实际输入和输出文本使用括号内的描述符指定：“<SP>”表示空格字符，“<HTAB>”表示制表符字符，“<CRLF>”表示回车/换行序列。例如，“X<SP>Y”和“X<SP>Y”代表相同的三个字符。
Example 1: A message reading:
示例1：一条消息，内容如下：
A: <SP> X <CRLF>
B <SP> : <SP> Y <HTAB><CRLF>
<HTAB> Z <SP><SP><CRLF>
<CRLF>
<SP> C <SP><CRLF>
D <SP><HTAB><SP> E <CRLF>
<CRLF>
<CRLF>
A: <SP> X <CRLF>
B <SP> : <SP> Y <HTAB><CRLF>
<HTAB> Z <SP><SP><CRLF>
<CRLF>
<SP> C <SP><CRLF>
D <SP><HTAB><SP> E <CRLF>
<CRLF>
<CRLF>
when canonicalized using relaxed canonicalization for both header and body results in a header reading:
当对标头和正文使用宽松规范化进行规范化时，会导致标头读取：
a:X <CRLF>
b:Y <SP> Z <CRLF>
a:X <CRLF>
b:Y <SP> Z <CRLF>
and a body reading:
以及一篇正文：
<SP> C <CRLF>
D <SP> E <CRLF>
<SP> C <CRLF>
D <SP> E <CRLF>
Example 2: The same message canonicalized using simple canonicalization for both header and body results in a header reading:
示例2：使用头和正文的简单规范化对同一消息进行规范化会导致头读取：
A: <SP> X <CRLF>
B <SP> : <SP> Y <HTAB><CRLF>
<HTAB> Z <SP><SP><CRLF>
A: <SP> X <CRLF>
B <SP> : <SP> Y <HTAB><CRLF>
<HTAB> Z <SP><SP><CRLF>
and a body reading:
以及一篇正文：
<SP> C <SP><CRLF>
D <SP><HTAB><SP> E <CRLF>
<SP> C <SP><CRLF>
D <SP><HTAB><SP> E <CRLF>
Example 3: When processed using relaxed header canonicalization and simple body canonicalization, the canonicalized version has a header of:
示例3：当使用宽松标题规范化和简单正文规范化进行处理时，规范化版本的标题为：
a:X <CRLF>
b:Y <SP> Z <CRLF>
a:X <CRLF>
b:Y <SP> Z <CRLF>
and a body reading:
以及一篇正文：
<SP> C <SP><CRLF>
D <SP><HTAB><SP> E <CRLF>
<SP> C <SP><CRLF>
D <SP><HTAB><SP> E <CRLF>
The signature of the email is stored in the DKIM-Signature header field. This header field contains all of the signature and key-fetching data. The DKIM-Signature value is a tag-list as described in Section 3.2.
电子邮件的签名存储在DKIM签名头字段中。此标头字段包含所有签名和密钥获取数据。DKIM签名值是第3.2节所述的标签列表。
The DKIM-Signature header field SHOULD be treated as though it were a trace header field as defined in Section 3.6 of [RFC5322] and hence SHOULD NOT be reordered and SHOULD be prepended to the message.
DKIM签名头字段应视为[RFC5322]第3.6节中定义的跟踪头字段，因此不应重新排序，并应在消息前加上前缀。
The DKIM-Signature header field being created or verified is always included in the signature calculation, after the rest of the header fields being signed; however, when calculating or verifying the signature, the value of the "b=" tag (signature value) of that DKIM-Signature header field MUST be treated as though it were an empty string. Unknown tags in the DKIM-Signature header field MUST be included in the signature calculation but MUST be otherwise ignored by Verifiers. Other DKIM-Signature header fields that are included in the signature should be treated as normal header fields; in particular, the "b=" tag is not treated specially.
正在创建或验证的DKIM签名头字段始终包含在签名计算中，在对其余头字段进行签名之后；但是，在计算或验证签名时，必须将该DKIM签名头字段的“b=”标记（签名值）的值视为空字符串。DKIM签名头字段中的未知标记必须包含在签名计算中，但必须被验证器忽略。签名中包含的其他DKIM签名头字段应视为正常头字段；特别是，“b=”标签没有经过特殊处理。
The encodings for each field type are listed below. Tags described as qp-section are encoded as described in Section 6.7 of MIME Part One [RFC2045], with the additional conversion of semicolon characters to "=3B"; intuitively, this is one line of quoted-printable encoded text. The dkim-quoted-printable syntax is defined in Section 2.11.
下面列出了每种字段类型的编码。如MIME第一部分[RFC2045]第6.7节所述，对描述为qp部分的标记进行编码，并将分号字符额外转换为“=3B”；直观地说，这是一行引用的可打印编码文本。第2.11节定义了dkim引用的可打印语法。
Tags on the DKIM-Signature header field along with their type and requirement status are shown below. Unrecognized tags MUST be ignored.
DKIM签名标题字段上的标记及其类型和需求状态如下所示。必须忽略无法识别的标记。
v= Version (plain-text; REQUIRED). This tag defines the version of this specification that applies to the signature record. It MUST have the value "1" for implementations compliant with this version of DKIM.
v=版本（纯文本；必需）。此标记定义了适用于签名记录的本规范版本。对于符合此版本DKIM的实现，它必须具有值“1”。
ABNF:
荷兰银行：
sig-v-tag = %x76 [FWS] "=" [FWS] 1*DIGIT
sig-v-tag = %x76 [FWS] "=" [FWS] 1*DIGIT
INFORMATIVE NOTE: DKIM-Signature version numbers may increase arithmetically as new versions of this specification are released.
资料性说明：随着本规范新版本的发布，DKIM签名版本号可能会在算术上增加。
a= The algorithm used to generate the signature (plain-text;
REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256";
Signers SHOULD sign using "rsa-sha256". See Section 3.3 for a
description of the algorithms.
a= The algorithm used to generate the signature (plain-text;
REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256";
Signers SHOULD sign using "rsa-sha256". See Section 3.3 for a
description of the algorithms.
ABNF:
荷兰银行：
sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg
sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h
sig-a-tag-k = "rsa" / x-sig-a-tag-k
sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h
x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT)
; for later extension
x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT)
; for later extension
sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg
sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h
sig-a-tag-k = "rsa" / x-sig-a-tag-k
sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h
x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT)
; for later extension
x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT)
; for later extension
b= The signature data (base64; REQUIRED). Whitespace is ignored in this value and MUST be ignored when reassembling the original signature. In particular, the signing process can safely insert FWS in this value in arbitrary places to conform to line-length limits. See "Signer Actions" (Section 5) for how the signature is computed.
b=签名数据（base64；必需）。此值中忽略空白，重新组合原始签名时必须忽略空白。特别是，签名过程可以在任意位置安全地将FWS插入该值，以符合行长度限制。有关如何计算签名，请参见“签名者操作”（第5节）。
ABNF:
荷兰银行：
sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data
sig-b-tag-data = base64string
sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data
sig-b-tag-data = base64string
bh= The hash of the canonicalized body part of the message as limited by the "l=" tag (base64; REQUIRED). Whitespace is ignored in this value and MUST be ignored when reassembling the original signature. In particular, the signing process can safely insert FWS in this value in arbitrary places to conform to line-length limits. See Section 3.7 for how the body hash is computed.
bh=消息的规范化正文部分的散列，受“l=”标记（base64；必选）的限制。此值中忽略空白，重新组合原始签名时必须忽略空白。特别是，签名过程可以在任意位置安全地将FWS插入该值，以符合行长度限制。有关如何计算正文散列，请参见第3.7节。
ABNF:
荷兰银行：
sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data
sig-bh-tag-data = base64string
sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data
sig-bh-tag-data = base64string
c= Message canonicalization (plain-text; OPTIONAL, default is "simple/simple"). This tag informs the Verifier of the type of canonicalization used to prepare the message for signing. It consists of two names separated by a "slash" (%d47) character, corresponding to the header and body canonicalization algorithms, respectively. These algorithms are described in Section 3.4. If only one algorithm is named, that algorithm is used for the header and "simple" is used for the body. For example, "c=relaxed" is treated the same as "c=relaxed/simple".
c=消息规范化（纯文本；可选，默认为“简单/简单”）。此标记通知验证器用于准备签名消息的规范化类型。它由两个名称组成，两个名称之间用“斜杠”（%d47）字符分隔，分别对应于标头和正文规范化算法。第3.4节介绍了这些算法。如果只命名了一个算法，则该算法用于标题，而“simple”用于正文。例如，“c=released”被视为与“c=released/simple”相同。
ABNF:
荷兰银行：
sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg
["/" sig-c-tag-alg]
sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg
x-sig-c-tag-alg = hyphenated-word ; for later extension
sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg
["/" sig-c-tag-alg]
sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg
x-sig-c-tag-alg = hyphenated-word ; for later extension
d= The SDID claiming responsibility for an introduction of a message into the mail stream (plain-text; REQUIRED). Hence, the SDID value is used to form the query for the public key. The SDID MUST correspond to a valid DNS name under which the DKIM key record is published. The conventions and semantics used by a Signer to create and use a specific SDID are outside the scope of this specification, as is any use of those conventions and semantics. When presented with a signature that does not meet these requirements, Verifiers MUST consider the signature invalid.
d=声称负责将消息引入邮件流的SDID（纯文本；必填）。因此，SDID值用于形成公钥的查询。SDID必须对应于发布DKIM密钥记录时使用的有效DNS名称。签名者用于创建和使用特定SDID的约定和语义不在本规范的范围内，使用这些约定和语义也不在本规范的范围内。当提交的签名不符合这些要求时，验证者必须考虑签名无效。
Internationalized domain names MUST be encoded as A-labels, as described in Section 2.3 of [RFC5890].
如[RFC5890]第2.3节所述，国际化域名必须编码为A标签。
ABNF:
荷兰银行：
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain)
; from [RFC5321] Domain,
; excluding address-literal
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain)
; from [RFC5321] Domain,
; excluding address-literal
h= Signed header fields (plain-text, but see description; REQUIRED). A colon-separated list of header field names that identify the header fields presented to the signing algorithm. The field MUST contain the complete list of header fields in the order presented to the signing algorithm. The field MAY contain names of header fields that do not exist when signed; nonexistent header fields do not contribute to the signature computation (that is, they are treated as the null input, including the header field name, the separating colon, the header field value, and any CRLF terminator). The field MAY contain multiple instances of a header field name, meaning multiple occurrences of the corresponding header field are included in the header hash. The field MUST NOT include the DKIM-Signature header field that is being created or verified but may include others. Folding whitespace (FWS) MAY be included on either side of the colon separator. Header field names MUST be compared against actual header field names in a case-insensitive manner. This list MUST NOT be empty. See Section 5.4 for a discussion of choosing header fields to sign and Section 5.4.2 for requirements when signing multiple instances of a single field.
h=签名的标题字段（纯文本，但请参见说明；必填）。标题字段名称的冒号分隔列表，用于标识提交给签名算法的标题字段。该字段必须按照提交给签名算法的顺序包含标题字段的完整列表。该字段可能包含签名时不存在的标题字段的名称；不存在的头字段不参与签名计算（即，它们被视为空输入，包括头字段名称、分隔冒号、头字段值和任何CRLF终止符）。该字段可能包含标题字段名称的多个实例，这意味着相应标题字段的多个实例包含在标题散列中。该字段不得包括正在创建或验证的DKIM签名头字段，但可以包括其他字段。可折叠空格（FWS）可包含在冒号分隔符的任一侧。必须以不区分大小写的方式将标题字段名与实际标题字段名进行比较。此列表不能为空。有关选择要签名的标题字段的讨论，请参见第5.4节；有关签名单个字段的多个实例时的要求，请参见第5.4.2节。
ABNF:
荷兰银行：
sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name
*( [FWS] ":" [FWS] hdr-name )
sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name
*( [FWS] ":" [FWS] hdr-name )
INFORMATIVE EXPLANATION: By "signing" header fields that do not actually exist, a Signer can allow a Verifier to detect insertion of those header fields after signing. However, since a Signer cannot possibly know what header fields might be defined in the future, this mechanism cannot be used to prevent the addition of any possible unknown header fields.
信息性解释：通过“签名”实际上不存在的头字段，签名者可以允许验证器在签名后检测这些头字段的插入。但是，由于签名者不可能知道将来可能定义哪些标头字段，因此无法使用此机制来防止添加任何可能的未知标头字段。
INFORMATIVE NOTE: "Signing" fields that are not present at the time of signing not only prevents fields and values from being added but also prevents adding fields with no values.
资料性说明：签名时不存在的“签名”字段不仅可以防止添加字段和值，还可以防止添加没有值的字段。
i= The Agent or User Identifier (AUID) on behalf of which the SDID is taking responsibility (dkim-quoted-printable; OPTIONAL, default is an empty local-part followed by an "@" followed by the domain from the "d=" tag).
i=SDID负责的代理或用户标识符（AUID）（dkim quoted printable；可选，默认为空本地部分，后跟“@”，后跟“d=”标记中的域）。
The syntax is a standard email address where the local-part MAY be omitted. The domain part of the address MUST be the same as, or a subdomain of, the value of the "d=" tag.
语法是一个标准的电子邮件地址，可以省略本地部分。地址的域部分必须与“d=”标记的值相同或是其子域。
Internationalized domain names MUST be encoded as A-labels, as described in Section 2.3 of [RFC5890].
如[RFC5890]第2.3节所述，国际化域名必须编码为A标签。
ABNF:
荷兰银行：
sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ]
"@" domain-name
sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ]
"@" domain-name
The AUID is specified as having the same syntax as an email address but it need not have the same semantics. Notably, the domain name need not be registered in the DNS -- so it might not resolve in a query -- and the local-part MAY be drawn from a namespace unrelated to any mailbox. The details of the structure and semantics for the namespace are determined by the Signer. Any knowledge or use of those details by Verifiers or Assessors is outside the scope of this specification. The Signer MAY choose to use the same namespace for its AUIDs as its users' email addresses or MAY choose other means of representing its users. However, the Signer SHOULD use the same AUID for each message intended to be evaluated as being within the same sphere of responsibility, if it wishes to offer receivers the option of using the AUID as a stable identifier that is finer grained than the SDID.
AUID被指定为具有与电子邮件地址相同的语法，但不需要具有相同的语义。值得注意的是，域名不需要在DNS中注册——因此它可能不会在查询中解析——并且本地部分可能来自与任何邮箱无关的命名空间。命名空间的结构和语义细节由签名者确定。验证者或评估者对这些细节的任何了解或使用不在本规范的范围内。签名者可以选择对其AUID使用与其用户电子邮件地址相同的名称空间，也可以选择其他表示其用户的方式。然而，如果签名者希望为接收者提供将AUID用作比SDID粒度更细的稳定标识符的选项，则签名者应为拟评估为在相同责任范围内的每条消息使用相同的AUID。
INFORMATIVE NOTE: The local-part of the "i=" tag is optional because in some cases a Signer may not be able to establish a verified individual identity. In such cases, the Signer might wish to assert that although it is willing to go as far as signing for the domain, it is unable or unwilling to commit to an individual user name within the domain. It can do so by including the domain part but not the local-part of the identity.
资料性说明：“i=”标记的本地部分是可选的，因为在某些情况下，签名者可能无法建立经验证的个人身份。在这种情况下，签名者可能希望声明，尽管它愿意为域签名，但它不能或不愿意在域内提交单个用户名。它可以通过包含域部分而不是标识的本地部分来实现。
INFORMATIVE DISCUSSION: This specification does not require the value of the "i=" tag to match the identity in any message header fields. This is considered to be a Verifier policy issue. Constraints between the value of the "i=" tag and other identities in other header fields seek to apply basic authentication into the semantics of trust associated with a role such as content author. Trust is a broad and complex topic, and trust mechanisms are subject to highly creative attacks. The real-world efficacy of any but the most basic bindings between the "i=" value and other identities is not well established, nor is its vulnerability to subversion by an attacker. Hence, reliance on the use of these options should
信息性讨论：本规范不要求“i=”标记的值与任何消息头字段中的标识匹配。这被认为是一个验证者策略问题。“i=”标记的值与其他头字段中的其他标识之间的约束寻求将基本身份验证应用到与角色（如内容作者）关联的信任语义中。信任是一个广泛而复杂的话题，信任机制受到高度创造性的攻击。“i=”值与其他标识之间的任何绑定（但最基本的绑定除外）的真实效果尚未得到很好的证实，其易受攻击者破坏的漏洞也未得到很好的证实。因此，依赖于这些选项的使用应该
be strictly limited. In particular, it is not at all clear to what extent a typical end-user recipient can rely on any assurances that might be made by successful use of the "i=" options.
严格限制。特别是，一个典型的最终用户接收者在多大程度上依赖于成功使用“i=”选项可能做出的任何保证，这一点根本不清楚。
l= Body length count (plain-text unsigned decimal integer; OPTIONAL, default is entire body). This tag informs the Verifier of the number of octets in the body of the email after canonicalization included in the cryptographic hash, starting from 0 immediately following the CRLF preceding the body. This value MUST NOT be larger than the actual number of octets in the canonicalized message body. See further discussion in Section 8.2.
l=正文长度计数（纯文本无符号十进制整数；可选，默认为整个正文）。此标记通知验证者加密散列中包含的规范化后电子邮件正文中的八位字节数，从正文前CRLF后面的0开始。此值不得大于规范化消息正文中的实际八位字节数。见第8.2节的进一步讨论。
INFORMATIVE NOTE: The value of the "l=" tag is constrained to 76 decimal digits. This constraint is not intended to predict the size of future messages or to require implementations to use an integer representation large enough to represent the maximum possible value but is intended to remind the implementer to check the length of this and all other tags during verification and to test for integer overflow when decoding the value. Implementers may need to limit the actual value expressed to a value smaller than 10^76, e.g., to allow a message to fit within the available storage space.
资料性说明：“l=”标记的值限制为76位小数。此约束不是为了预测未来消息的大小，也不是为了要求实现使用足够大的整数表示来表示最大可能值，而是为了提醒实现者在验证期间检查此标记和所有其他标记的长度，并在解码消息时测试整数溢出价值实现者可能需要将表示的实际值限制为小于10^76的值，例如，允许消息适合于可用存储空间。
ABNF:
荷兰银行：
sig-l-tag = %x6c [FWS] "=" [FWS]
1*76DIGIT
sig-l-tag = %x6c [FWS] "=" [FWS]
1*76DIGIT
q= A colon-separated list of query methods used to retrieve the public key (plain-text; OPTIONAL, default is "dns/txt"). Each query method is of the form "type[/options]", where the syntax and semantics of the options depend on the type and specified options. If there are multiple query mechanisms listed, the choice of query mechanism MUST NOT change the interpretation of the signature. Implementations MUST use the recognized query mechanisms in the order presented. Unrecognized query mechanisms MUST be ignored.
q=用于检索公钥的以冒号分隔的查询方法列表（纯文本；可选，默认为“dns/txt”）。每个查询方法的形式为“type[/options]”，其中选项的语法和语义取决于类型和指定的选项。如果列出了多个查询机制，则查询机制的选择不得改变签名的解释。实现必须按照呈现的顺序使用已识别的查询机制。必须忽略无法识别的查询机制。
Currently, the only valid value is "dns/txt", which defines the DNS TXT resource record (RR) lookup algorithm described elsewhere in this document. The only option defined for the "dns" query type is "txt", which MUST be included. Verifiers and Signers MUST support "dns/txt".
目前，唯一有效的值是“dns/txt”，它定义了本文档其他地方描述的dns txt资源记录（RR）查找算法。为“dns”查询类型定义的唯一选项是“txt”，必须包括该选项。验证者和签名者必须支持“dns/txt”。
ABNF:
荷兰银行：
sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method
*([FWS] ":" [FWS] sig-q-tag-method)
sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method
*([FWS] ":" [FWS] sig-q-tag-method)
sig-q-tag-method = "dns/txt" / x-sig-q-tag-type
["/" x-sig-q-tag-args]
x-sig-q-tag-type = hyphenated-word ; for future extension
x-sig-q-tag-args = qp-hdr-value
sig-q-tag-method = "dns/txt" / x-sig-q-tag-type
["/" x-sig-q-tag-args]
x-sig-q-tag-type = hyphenated-word ; for future extension
x-sig-q-tag-args = qp-hdr-value
s= The selector subdividing the namespace for the "d=" (domain) tag (plain-text; REQUIRED).
s=为“d=”（域）标记（纯文本；必需）细分名称空间的选择器。
Internationalized selector names MUST be encoded as A-labels, as described in Section 2.3 of [RFC5890].
国际化选择器名称必须编码为A标签，如[RFC5890]第2.3节所述。
ABNF:
荷兰银行：
sig-s-tag = %x73 [FWS] "=" [FWS] selector
sig-s-tag = %x73 [FWS] "=" [FWS] selector
t= Signature Timestamp (plain-text unsigned decimal integer; RECOMMENDED, default is an unknown creation time). The time that this signature was created. The format is the number of seconds since 00:00:00 on January 1, 1970 in the UTC time zone. The value is expressed as an unsigned integer in decimal ASCII. This value is not constrained to fit into a 31- or 32-bit integer. Implementations SHOULD be prepared to handle values up to at least 10^12 (until approximately AD 200,000; this fits into 40 bits). To avoid denial-of-service attacks, implementations MAY consider any value longer than 12 digits to be infinite. Leap seconds are not counted. Implementations MAY ignore signatures that have a timestamp in the future.
t=签名时间戳（纯文本无符号十进制整数；建议使用，默认值为未知的创建时间）。创建此签名的时间。格式是UTC时区中自1970年1月1日00:00:00起的秒数。该值以十进制ASCII表示为无符号整数。此值不受限制以适合31位或32位整数。实现应该准备好处理至少10^12的值（直到大约AD 200000；这适合40位）。为了避免拒绝服务攻击，实现可以考虑大于12位数的任何值为无穷大。闰秒不计算在内。将来实现可能会忽略具有时间戳的签名。
ABNF:
荷兰银行：
sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT
sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT
x= Signature Expiration (plain-text unsigned decimal integer; RECOMMENDED, default is no expiration). The format is the same as in the "t=" tag, represented as an absolute date, not as a time delta from the signing timestamp. The value is expressed as an unsigned integer in decimal ASCII, with the same constraints on the value in the "t=" tag. Signatures MAY be considered invalid if the verification time at the Verifier is past the expiration date. The verification time should be the time that the message was first received at the administrative domain of the Verifier if that time is reliably available; otherwise, the current time should be used. The value of the "x=" tag MUST be greater than the value of the "t=" tag if both are present.
x=签名过期（纯文本无符号十进制整数；建议使用，默认为无过期）。格式与“t=”标记中的格式相同，表示为绝对日期，而不是签名时间戳的时间增量。该值以十进制ASCII表示为无符号整数，对“t=”标记中的值具有相同的约束。如果验证者的验证时间超过到期日期，则签名可能被视为无效。验证时间应为消息首次在验证器的管理域接收的时间（如果该时间可靠可用）；否则，应使用当前时间。“x=”标记的值必须大于“t=”标记的值（如果两者都存在）。
INFORMATIVE NOTE: The "x=" tag is not intended as an anti-replay defense.
资料性说明：“x=”标记不用于防重放。
INFORMATIVE NOTE: Due to clock drift, the receiver's notion of when to consider the signature expired may not exactly match what the sender is expecting. Receivers MAY add a 'fudge factor' to allow for such possible drift.
信息提示：由于时钟漂移，接收器何时考虑签名过期的概念可能与发送者期望的不完全匹配。接收机可能会添加一个“模糊因子”，以允许这种可能的漂移。
ABNF:
荷兰银行：
sig-x-tag = %x78 [FWS] "=" [FWS]
1*12DIGIT
sig-x-tag = %x78 [FWS] "=" [FWS]
1*12DIGIT
z= Copied header fields (dkim-quoted-printable, but see description; OPTIONAL, default is null). A vertical-bar-separated list of selected header fields present when the message was signed, including both the field name and value. It is not required to include all header fields present at the time of signing. This field need not contain the same header fields listed in the "h=" tag. The header field text itself must encode the vertical bar ("|", %x7C) character (i.e., vertical bars in the "z=" text are meta-characters, and any actual vertical bar characters in a copied header field must be encoded). Note that all whitespace must be encoded, including whitespace between the colon and the header field value. After encoding, FWS MAY be added at arbitrary locations in order to avoid excessively long lines; such whitespace is NOT part of the value of the header field and MUST be removed before decoding.
z=复制的标题字段（dkim可打印，但请参见说明；可选，默认为空）。签名消息时出现的选定标题字段的竖条分隔列表，包括字段名称和值。不需要包括签名时存在的所有标题字段。此字段不必包含“h=”标记中列出的相同标题字段。标题字段文本本身必须编码垂直条（“|”），%x7C）字符（即“z=”文本中的垂直条是元字符，复制的标题字段中的任何实际垂直条字符都必须编码）。请注意，必须对所有空格进行编码，包括冒号和标头字段值之间的空格。编码后，可以在任意位置添加FWS，以避免过长的线；此类空白不是标头字段值的一部分，必须在解码之前删除。
The header fields referenced by the "h=" tag refer to the fields in the [RFC5322] header of the message, not to any copied fields in the "z=" tag. Copied header field values are for diagnostic use.
“h=”标记引用的标题字段指的是消息的[RFC5322]标题中的字段，而不是“z=”标记中复制的任何字段。复制的标题字段值用于诊断。
ABNF:
荷兰银行：
sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy
*( "|" [FWS] sig-z-tag-copy )
sig-z-tag-copy = hdr-name [FWS] ":" qp-hdr-value
sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy
*( "|" [FWS] sig-z-tag-copy )
sig-z-tag-copy = hdr-name [FWS] ":" qp-hdr-value
INFORMATIVE EXAMPLE of a signature header field spread across multiple continuation lines:
横跨多个续行的签名头字段的信息示例：
DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;
c=simple; q=dns/txt; i=@eng.example.net;
t=1117574938; x=1118006938;
h=from:to:subject:date;
z=From:foo@eng.example.net|To:joe@example.com|
Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR
DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;
c=simple; q=dns/txt; i=@eng.example.net;
t=1117574938; x=1118006938;
h=from:to:subject:date;
z=From:foo@eng.example.net|To:joe@example.com|
Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR
Signature applications require some level of assurance that the verification public key is associated with the claimed Signer. Many applications achieve this by using public-key certificates issued by a trusted third party. However, DKIM can achieve a sufficient level of security, with significantly enhanced scalability, by simply having the Verifier query the purported Signer's DNS entry (or some security-equivalent) in order to retrieve the public key.
签名应用程序需要某种程度的保证，即验证公钥与声明的签名者相关联。许多应用程序通过使用可信第三方颁发的公钥证书来实现这一点。然而，DKIM可以通过简单地让验证者查询声称的签名者的DNS条目（或某些安全等效项）来检索公钥，从而实现足够的安全级别，并具有显著增强的可伸缩性。
DKIM keys can potentially be stored in multiple types of key servers and in multiple formats. The storage and format of keys are irrelevant to the remainder of the DKIM algorithm.
DKIM密钥可能以多种格式存储在多种类型的密钥服务器中。密钥的存储和格式与DKIM算法的其余部分无关。
Parameters to the key lookup algorithm are the type of the lookup (the "q=" tag), the domain of the Signer (the "d=" tag of the DKIM-Signature header field), and the selector (the "s=" tag).
密钥查找算法的参数包括查找类型（“q=”标记）、签名者的域（“DKIM签名头字段的“d=”标记）和选择器（“s=”标记）。
public_key = dkim_find_key(q_val, d_val, s_val)
public_key=dkim_find_key（q_val，d_val，s_val）
This document defines a single binding, using DNS TXT RRs to distribute the keys. Other bindings may be defined in the future.
本文档定义了单个绑定，使用DNS TXT RRs分发密钥。将来可能会定义其他绑定。
It is expected that many key servers will choose to present the keys in an otherwise unstructured text format (for example, an XML form would not be considered to be unstructured text for this purpose). The following definition MUST be used for any DKIM key represented in an otherwise unstructured textual form.
预计许多密钥服务器将选择以非结构化文本格式显示密钥（例如，出于此目的，XML表单不会被视为非结构化文本）。以下定义必须用于以非结构化文本形式表示的任何DKIM键。
The overall syntax is a tag-list as described in Section 3.2. The current valid tags are described below. Other tags MAY be present and MUST be ignored by any implementation that does not understand them.
总体语法是第3.2节所述的标记列表。下面介绍了当前的有效标记。其他标记可能存在，任何不理解它们的实现都必须忽略它们。
v= Version of the DKIM key record (plain-text; RECOMMENDED, default is "DKIM1"). If specified, this tag MUST be set to "DKIM1" (without the quotes). This tag MUST be the first tag in the record. Records beginning with a "v=" tag with any other value MUST be discarded. Note that Verifiers must do a string comparison on this value; for example, "DKIM1" is not the same as "DKIM1.0".
v=DKIM密钥记录的版本（纯文本；建议使用，默认值为“DKIM1”）。如果指定，此标记必须设置为“DKIM1”（不带引号）。此标记必须是记录中的第一个标记。必须丢弃以“v=”标记开头并带有任何其他值的记录。请注意，验证器必须对该值进行字符串比较；例如，“DKIM1”与“DKIM1.0”不同。
ABNF:
荷兰银行：
key-v-tag = %x76 [FWS] "=" [FWS] %x44.4B.49.4D.31
key-v-tag = %x76 [FWS] "=" [FWS] %x44.4B.49.4D.31
h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to allowing all algorithms). A colon-separated list of hash algorithms that might be used. Unrecognized algorithms MUST be ignored. Refer to Section 3.3 for a discussion of the hash algorithms implemented by Signers and Verifiers. The set of algorithms listed in this tag in each record is an operational choice made by the Signer.
h=可接受的哈希算法（纯文本；可选，默认为允许所有算法）。可能使用的哈希算法的冒号分隔列表。必须忽略无法识别的算法。有关签名者和验证者实现的哈希算法的讨论，请参阅第3.3节。每个记录中此标签中列出的一组算法是签名者做出的操作选择。
ABNF:
荷兰银行：
key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg
*( [FWS] ":" [FWS] key-h-tag-alg )
key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg
x-key-h-tag-alg = hyphenated-word ; for future extension
key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg
*( [FWS] ":" [FWS] key-h-tag-alg )
key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg
x-key-h-tag-alg = hyphenated-word ; for future extension
k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and Verifiers MUST support the "rsa" key type. The "rsa" key type indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey (see [RFC3447], Sections 3.1 and A.1.1) is being used in the "p=" tag. (Note: the "p=" tag further encodes the value using the base64 algorithm.) Unrecognized key types MUST be ignored.
k=密钥类型（纯文本；可选，默认为“rsa”）。签名者和验证者必须支持“rsa”密钥类型。“rsa”密钥类型表示ASN.1 DER编码的[ITU-X660-1997]RSAPublicKey（参见[RFC3447]，第3.1节和A.1.1节）正在“p=”标签中使用。（注意：“p=”标记使用base64算法对值进行进一步编码。）必须忽略无法识别的密钥类型。
ABNF:
荷兰银行：
key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type
key-k-tag-type = "rsa" / x-key-k-tag-type
x-key-k-tag-type = hyphenated-word ; for future extension
key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type
key-k-tag-type = "rsa" / x-key-k-tag-type
x-key-k-tag-type = hyphenated-word ; for future extension
n= Notes that might be of interest to a human (qp-section; OPTIONAL, default is empty). No interpretation is made by any program. This tag should be used sparingly in any key server mechanism that has space limitations (notably DNS). This is intended for use by administrators, not end users.
n=可能对人员感兴趣的注释（qp部分；可选，默认为空）。任何程序都不会进行解释。在任何具有空间限制（特别是DNS）的密钥服务器机制中，都应谨慎使用此标记。这是供管理员使用的，而不是供最终用户使用。
ABNF:
荷兰银行：
key-n-tag = %x6e [FWS] "=" [FWS] qp-section
key-n-tag = %x6e [FWS] "=" [FWS] qp-section
p= Public-key data (base64; REQUIRED). An empty value means that this public key has been revoked. The syntax and semantics of this tag value before being encoded in base64 are defined by the "k=" tag.
p=公钥数据（base64；必需）。空值表示此公钥已被吊销。在base64中编码之前，此标记值的语法和语义由“k=”标记定义。
INFORMATIVE RATIONALE: If a private key has been compromised or otherwise disabled (e.g., an outsourcing contract has been terminated), a Signer might want to explicitly state that it knows about the selector, but all messages using that selector
信息性理由：如果私钥已被泄露或以其他方式禁用（例如，外包合同已终止），签名者可能希望明确声明其知道选择器，但所有消息都使用该选择器
should fail verification. Verifiers SHOULD return an error code for any DKIM-Signature header field with a selector referencing a revoked key. (See Section 6.1.2 for details.)
如果验证失败。验证器应返回任何DKIM签名头字段的错误代码，该字段的选择器引用已撤销的密钥。（详见第6.1.2节。）
ABNF:
荷兰银行：
key-p-tag = %x70 [FWS] "=" [ [FWS] base64string]
key-p-tag = %x70 [FWS] "=" [ [FWS] base64string]
INFORMATIVE NOTE: A base64string is permitted to include whitespace (FWS) at arbitrary places; however, any CRLFs must be followed by at least one WSP character. Implementers and administrators are cautioned to ensure that selector TXT RRs conform to this specification.
资料性说明：Base64字符串允许在任意位置包含空格（FWS）；但是，任何CRLF后面必须至少有一个WSP字符。提醒实施者和管理员确保选择器TXT RRs符合本规范。
s= Service Type (plain-text; OPTIONAL; default is "*"). A colon-separated list of service types to which this record applies. Verifiers for a given service type MUST ignore this record if the appropriate type is not listed. Unrecognized service types MUST be ignored. Currently defined service types are as follows:
s=服务类型（纯文本；可选；默认值为“*”）。此记录应用于的以冒号分隔的服务类型列表。如果未列出适当的类型，则给定服务类型的验证器必须忽略此记录。必须忽略无法识别的服务类型。当前定义的服务类型如下：
* matches all service types
* 匹配所有服务类型
email electronic mail (not necessarily limited to SMTP)
电子邮件（不一定限于SMTP）
This tag is intended to constrain the use of keys for other purposes, should use of DKIM be defined by other services in the future.
如果将来其他服务定义DKIM的使用，则此标记旨在限制密钥用于其他目的。
ABNF:
荷兰银行：
key-s-tag = %x73 [FWS] "=" [FWS] key-s-tag-type
*( [FWS] ":" [FWS] key-s-tag-type )
key-s-tag-type = "email" / "*" / x-key-s-tag-type
x-key-s-tag-type = hyphenated-word ; for future extension
key-s-tag = %x73 [FWS] "=" [FWS] key-s-tag-type
*( [FWS] ":" [FWS] key-s-tag-type )
key-s-tag-type = "email" / "*" / x-key-s-tag-type
x-key-s-tag-type = hyphenated-word ; for future extension
t= Flags, represented as a colon-separated list of names (plain-text; OPTIONAL, default is no flags set). Unrecognized flags MUST be ignored. The defined flags are as follows:
t=标志，表示为冒号分隔的名称列表（纯文本；可选，默认为未设置标志）。必须忽略无法识别的标志。定义的标志如下所示：
y This domain is testing DKIM. Verifiers MUST NOT treat messages from Signers in testing mode differently from unsigned email, even should the signature fail to verify. Verifiers MAY wish to track testing mode results to assist the Signer.
y此域正在测试DKIM。即使签名无法验证，验证者也不能在测试模式下以与未签名电子邮件不同的方式处理来自签名者的消息。验证者可能希望跟踪测试模式结果以帮助签名者。
s Any DKIM-Signature header fields using the "i=" tag MUST have the same domain value on the right-hand side of the "@" in the "i=" tag and the value of the "d=" tag. That is, the "i=" domain MUST NOT be a subdomain of "d=". Use of this flag is RECOMMENDED unless subdomaining is required.
s使用“i=”标记的任何DKIM签名头字段必须在“i=”标记中“@”的右侧具有与“d=”标记相同的域值。也就是说，“i=”域不能是“d=”的子域。除非需要子域，否则建议使用此标志。
ABNF:
荷兰银行：
key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag
*( [FWS] ":" [FWS] key-t-tag-flag )
key-t-tag-flag = "y" / "s" / x-key-t-tag-flag
x-key-t-tag-flag = hyphenated-word ; for future extension
key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag
*( [FWS] ":" [FWS] key-t-tag-flag )
key-t-tag-flag = "y" / "s" / x-key-t-tag-flag
x-key-t-tag-flag = hyphenated-word ; for future extension
A binding using DNS TXT RRs as a key service is hereby defined. All implementations MUST support this binding.
在此定义使用DNS TXT RRs作为密钥服务的绑定。所有实现都必须支持此绑定。
All DKIM keys are stored in a subdomain named "_domainkey". Given a DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag of "foo.bar", the DNS query will be for "foo.bar._domainkey.example.com".
所有DKIM密钥都存储在名为“_domainkey”的子域中。给定带有“example.com”的“d=”标记和“foo.bar”的“s=”标记的DKIM签名字段，DNS查询将针对“foo.bar.\u domainkey.example.com”。
The DNS Resource Record type used is specified by an option to the query-type ("q=") tag. The only option defined in this base specification is "txt", indicating the use of a TXT RR. A later extension of this standard may define another RR type.
使用的DNS资源记录类型由查询类型（“q=）标记的选项指定。本基本规范中定义的唯一选项是“txt”，表示使用txt RR。本标准的后续扩展可能会定义另一种RR类型。
Strings in a TXT RR MUST be concatenated together before use with no intervening whitespace. TXT RRs MUST be unique for a particular selector name; that is, if there are multiple records in an RRset, the results are undefined.
TXT RR中的字符串在使用前必须连接在一起，并且没有中间空白。TXT RRs对于特定选择器名称必须是唯一的；也就是说，如果一个RRset中有多个记录，则结果是未定义的。
TXT RRs are encoded as described in Section 3.6.1.
TXT RRs的编码如第3.6.1节所述。
Both signing and verifying message signatures start with a step of computing two cryptographic hashes over the message. Signers will choose the parameters of the signature as described in "Signer Actions" (Section 5); Verifiers will use the parameters specified in the DKIM-Signature header field being verified. In the following discussion, the names of the tags in the DKIM-Signature header field that either exists (when verifying) or will be created (when signing)
签名和验证消息签名都从计算消息上的两个加密哈希开始。签名人将选择“签名人行动”（第5节）中所述的签名参数；验证器将使用正在验证的DKIM签名头字段中指定的参数。在下面的讨论中，DKIM签名头字段中已存在（验证时）或将创建（签名时）的标记名称
are used. Note that canonicalization (Section 3.4) is only used to prepare the email for signing or verifying; it does not affect the transmitted email in any way.
都用过了。请注意，规范化（第3.4节）仅用于准备用于签名或验证的电子邮件；它不会以任何方式影响发送的电子邮件。
The Signer/Verifier MUST compute two hashes: one over the body of the message and one over the selected header fields of the message.
签名者/验证者必须计算两个散列：一个在消息体上，另一个在消息的选定头字段上。
Signers MUST compute them in the order shown. Verifiers MAY compute them in any order convenient to the Verifier, provided that the result is semantically identical to the semantics that would be the case had they been computed in this order.
签名者必须按照显示的顺序计算它们。验证器可以按照验证器方便的任何顺序计算它们，前提是结果在语义上与按照该顺序计算的结果相同。
In hash step 1, the Signer/Verifier MUST hash the message body, canonicalized using the body canonicalization algorithm specified in the "c=" tag and then truncated to the length specified in the "l=" tag. That hash value is then converted to base64 form and inserted into (Signers) or compared to (Verifiers) the "bh=" tag of the DKIM-Signature header field.
在散列步骤1中，签名者/验证者必须散列消息正文，使用“c=”标记中指定的正文规范化算法进行规范化，然后截断为“l=”标记中指定的长度。然后将该散列值转换为base64格式，并插入（签名者）或与（验证者）DKIM签名头字段的“bh=”标记进行比较。
In hash step 2, the Signer/Verifier MUST pass the following to the hash algorithm in the indicated order.
在散列步骤2中，签名者/验证者必须按照指定的顺序将以下内容传递给散列算法。
1. The header fields specified by the "h=" tag, in the order specified in that tag, and canonicalized using the header canonicalization algorithm specified in the "c=" tag. Each header field MUST be terminated with a single CRLF.
1. “h=”标记指定的标题字段，按照该标记中指定的顺序，并使用“c=”标记中指定的标题规范化算法进行规范化。每个标题字段必须以单个CRLF终止。
2. The DKIM-Signature header field that exists (verifying) or will be inserted (signing) in the message, with the value of the "b=" tag (including all surrounding whitespace) deleted (i.e., treated as the empty string), canonicalized using the header canonicalization algorithm specified in the "c=" tag, and without a trailing CRLF.
2. 在消息中存在（验证）或将插入（签名）的DKIM签名头字段，删除“b=”标记（包括所有周围的空格）的值（即视为空字符串），使用“c=”标记中指定的头规范化算法进行规范化，且不带尾随CRLF。
All tags and their values in the DKIM-Signature header field are included in the cryptographic hash with the sole exception of the value portion of the "b=" (signature) tag, which MUST be treated as the null string. All tags MUST be included even if they might not be understood by the Verifier. The header field MUST be presented to the hash algorithm after the body of the message rather than with the rest of the header fields and MUST be canonicalized as specified in the "c=" (canonicalization) tag. The DKIM-Signature header field MUST NOT be included in its own "h=" tag, although other DKIM-Signature header fields MAY be signed (see Section 4).
DKIM Signature header字段中的所有标记及其值都包含在加密哈希中，唯一例外的是“b=（Signature）标记的值部分，它必须被视为空字符串。必须包括所有标签，即使验证者可能不理解这些标签。标头字段必须在消息正文之后呈现给哈希算法，而不是与其余标头字段一起呈现，并且必须按照“c=（canonicalization）标记中的规定进行规范化。DKIM签名头字段不得包含在其自己的“h=”标记中，尽管其他DKIM签名头字段也可以签名（参见第4节）。
When calculating the hash on messages that will be transmitted using base64 or quoted-printable encoding, Signers MUST compute the hash after the encoding. Likewise, the Verifier MUST incorporate the
在计算将使用base64或带引号的可打印编码传输的消息的散列时，签名者必须在编码后计算散列。同样，验证者必须将
values into the hash before decoding the base64 or quoted-printable text. However, the hash MUST be computed before transport-level encodings such as SMTP "dot-stuffing" (the modification of lines beginning with a "." to avoid confusion with the SMTP end-of-message marker, as specified in [RFC5321]).
在解码base64或带引号的可打印文本之前，将值写入哈希。但是，必须在传输级编码之前计算哈希，例如SMTP“点填充”（修改以“.”开头的行，以避免与[RFC5321]中指定的SMTP邮件结尾标记混淆）。
With the exception of the canonicalization procedure described in Section 3.4, the DKIM signing process treats the body of messages as simply a string of octets. DKIM messages MAY be either in plain-text or in MIME format; no special treatment is afforded to MIME content. Message attachments in MIME format MUST be included in the content that is signed.
除了第3.4节中描述的规范化过程外，DKIM签名过程将消息体视为简单的八进制字符串。DKIM消息可以是纯文本或MIME格式；默剧内容没有特殊处理。已签名的内容中必须包含MIME格式的邮件附件。
More formally, pseudo-code for the signature algorithm is:
更正式地说，签名算法的伪代码是：
body-hash = hash-alg (canon-body, l-param) data-hash = hash-alg (h-headers, D-SIG, body-hash) signature = sig-alg (d-domain, selector, data-hash)
正文哈希=哈希alg（佳能正文，l参数）数据哈希=哈希alg（h头，D-SIG，正文哈希）签名=SIG alg（D域，选择器，数据哈希）
where:
哪里：
body-hash: is the output from hashing the body, using hash-alg.
body hash：是使用hash alg对body进行散列的输出。
hash-alg: is the hashing algorithm specified in the "a" parameter.
hash alg：是在“a”参数中指定的哈希算法。
canon-body: is a canonicalized representation of the body, produced using the body algorithm specified in the "c" parameter, as defined in Section 3.4 and excluding the DKIM-Signature field.
canon body：是body的规范化表示，使用第3.4节定义的“c”参数中指定的body算法生成，不包括DKIM签名字段。
l-param: is the length-of-body value of the "l" parameter.
l-param：是“l”参数的主体值的长度。
data-hash: is the output from using the hash-alg algorithm, to hash the header including the DKIM-Signature header, and the body hash.
数据哈希：是使用哈希alg算法对头进行哈希的输出，包括DKIM签名头和正文哈希。
h-headers: is the list of headers to be signed, as specified in the "h" parameter.
h-headers：是要签名的标题列表，如“h”参数中所指定。
D-SIG: is the canonicalized DKIM-Signature field itself without the signature value portion of the parameter, that is, an empty parameter value.
D-SIG：规范化的DKIM签名字段本身没有参数的签名值部分，即空参数值。
signature: is the signature value produced by the signing algorithm.
签名：签名算法生成的签名值。
sig-alg: is the signature algorithm specified by the "a" parameter.
sig alg：是由“a”参数指定的签名算法。
d-domain: is the domain name specified in the "d" parameter.
d-domain：是在“d”参数中指定的域名。
selector: is the selector value specified in the "s" parameter.
选择器：是在“s”参数中指定的选择器值。
NOTE: Many digital signature APIs provide both hashing and application of the RSA private key using a single "sign()" primitive. When using such an API, the last two steps in the algorithm would probably be combined into a single call that would perform both the "a-hash-alg" and the "sig-alg".
注意：许多数字签名API使用单个“sign（）”原语提供RSA私钥的哈希和应用。当使用这样的API时，算法中的最后两个步骤可能会组合成一个调用，该调用将同时执行“a-hash-alg”和“sig-alg”。
A message that is not compliant with [RFC5322], [RFC2045], and [RFC2047] can be subject to attempts by intermediaries to correct or interpret such content. See Section 8 of [RFC4409] for examples of changes that are commonly made. Such "corrections" may invalidate DKIM signatures or have other undesirable effects, including some that involve changes to the way a message is presented to an end user.
不符合[RFC5322]、[RFC2045]和[RFC2047]的消息可能会受到中介机构纠正或解释此类内容的尝试的影响。参见[RFC4409]第8节，了解常见变更的示例。此类“更正”可能使DKIM签名无效或产生其他不良影响，包括一些涉及更改向最终用户呈现消息的方式的影响。
Accordingly, DKIM's design is predicated on valid input. Therefore, Signers and Verifiers SHOULD take reasonable steps to ensure that the messages they are processing are valid according to [RFC5322], [RFC2045], and any other relevant message format standards.
因此，DKIM的设计基于有效输入。因此，签名者和验证者应采取合理措施，确保他们处理的消息根据[RFC5322]、[RFC2045]和任何其他相关消息格式标准有效。
See Section 8.15 for additional discussion.
更多讨论见第8.15节。
The evaluation of each signature ends in one of three states, which this document refers to as follows:
对每个签名的评估以三种状态中的一种结束，本文件如下所述：
SUCCESS: a successful verification
成功：成功的验证
PERMFAIL: a permanent, non-recoverable error such as a signature verification failure
PERMFAIL：永久性的、不可恢复的错误，例如签名验证失败
TEMPFAIL: a temporary, recoverable error such as a DNS query timeout
TEMPFAIL：一个临时的、可恢复的错误，例如DNS查询超时
For each signature that verifies successfully or produces a TEMPFAIL result, output of the DKIM algorithm MUST include the set of:
对于成功验证或产生TEMPFAIL结果的每个签名，DKIM算法的输出必须包括以下内容：
o The domain name, taken from the "d=" signature tag; and
o 域名，取自“d=”签名标签；和
o The result of the verification attempt for that signature.
o 尝试验证该签名的结果。
The output MAY include other signature properties or result meta-data, including PERMFAILed or otherwise ignored signatures, for use by modules that consume those results.
输出可以包括其他签名属性或结果元数据，包括失败或被忽略的签名，供使用这些结果的模块使用。
See Section 6.1 for discussion of signature validation result codes.
有关签名验证结果代码的讨论，请参见第6.1节。
In some circumstances, it is desirable for a domain to apply a signature on behalf of any of its subdomains without the need to maintain separate selectors (key records) in each subdomain. By default, private keys corresponding to key records can be used to sign messages for any subdomain of the domain in which they reside; for example, a key record for the domain example.com can be used to verify messages where the AUID ("i=" tag of the signature) is sub.example.com, or even sub1.sub2.example.com. In order to limit the capability of such keys when this is not intended, the "s" flag MAY be set in the "t=" tag of the key record, to constrain the validity of the domain of the AUID. If the referenced key record contains the "s" flag as part of the "t=" tag, the domain of the AUID ("i=" flag) MUST be the same as that of the SDID (d=) domain. If this flag is absent, the domain of the AUID MUST be the same as, or a subdomain of, the SDID.
在某些情况下，域希望代表其任何子域应用签名，而无需在每个子域中维护单独的选择器（密钥记录）。默认情况下，与密钥记录对应的私钥可用于对其所在域的任何子域的消息进行签名；例如，域example.com的密钥记录可用于验证AUID（“i=”签名标记）为sub.example.com甚至sub1.sub2.example.com的消息。为了在非预期的情况下限制此类密钥的能力，可以在密钥记录的“t=”标记中设置“s”标志，以约束AUID域的有效性。如果引用的密钥记录包含作为“t=”标记一部分的“s”标志，则AUID（“i=”标志）的域必须与SDID（d=）域的域相同。如果没有此标志，AUID的域必须与SDID相同或是SDID的子域。
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).
DKIM的主要任务是从签名者向接收方身份评估员传递一个引用责任身份的单一签名域标识符（SDID）。DKIM可以选择性地提供单个责任代理或用户标识符（AUID）。
Hence, DKIM's mandatory output to a receive-side Identity Assessor is a single domain name. Within the scope of its use as DKIM output, the name has only basic domain name semantics; any possible owner-specific semantics are outside the scope of DKIM. That is, within its role as a DKIM identifier, additional semantics cannot be assumed by an Identity Assessor.
因此，DKIM必须向接收方身份评估器输出一个域名。在作为DKIM输出的使用范围内，该名称只有基本的域名语义；任何可能的特定于所有者的语义都不在DKIM的范围之内。也就是说，在其作为DKIM标识符的角色中，身份评估员不能承担额外的语义。
Upon successfully verifying the signature, a receive-side DKIM Verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the Agent or User Identifier (i=) if present.
成功验证签名后，接收端DKIM验证器必须将签名域标识符（d=）传送给消费身份评估器模块，并且可以传送代理或用户标识符（i=）。
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规范和语义的范围。
Hence, it is relegated to a higher-level service, such as a delivery-handling filter that integrates a variety of inputs and performs heuristic analysis of them.
因此，它被降级到更高级别的服务，例如集成各种输入并对其执行启发式分析的交付处理过滤器。
INFORMATIVE DISCUSSION: This document does not require the value of the SDID or AUID to match an identifier in any other message header field. This requirement is, instead, an Assessor policy issue. The purpose of such a linkage would be to authenticate the value in that other header field. This, in turn, is the basis for applying a trust assessment based on the identifier value. Trust is a broad and complex topic, and trust mechanisms are subject to highly creative attacks. The real-world efficacy of any but the most basic bindings between the SDID or AUID and other identities is not well established, nor is its vulnerability to subversion by an attacker. Hence, reliance on the use of such bindings should be strictly limited. In particular, it is not at all clear to what extent a typical end-user recipient can rely on any assurances that might be made by successful use of the SDID or AUID.
信息性讨论：本文档不要求SDID或AUID的值与任何其他消息头字段中的标识符匹配。相反，这一要求是一个评估员政策问题。这种链接的目的是验证另一个标头字段中的值。这又是基于标识符值应用信任评估的基础。信任是一个广泛而复杂的话题，信任机制受到高度创造性的攻击。SDID或AUID与其他身份之间的任何绑定（除了最基本的绑定外）的实际效果都没有得到很好的证实，其易受攻击者破坏的漏洞也没有得到很好的证实。因此，应严格限制对此类绑定使用的依赖。特别是，一个典型的最终用户接收者可以在多大程度上依赖成功使用SDID或AUID可能做出的任何保证，这一点根本不清楚。
There are many reasons why a message might have multiple signatures. For example, suppose SHA-256 is in the future found to be insufficiently strong, and DKIM usage transitions to SHA-1024. A Signer might immediately sign using the newer algorithm but also continue to sign using the older algorithm for interoperability with Verifiers that had not yet upgraded. The Signer would do this by adding two DKIM-Signature header fields, one using each algorithm. Older Verifiers that did not recognize SHA-1024 as an acceptable algorithm would skip that signature and use the older algorithm; newer Verifiers could use either signature at their option and, all other things being equal, might not even attempt to verify the other signature.
消息可能具有多个签名的原因有很多。例如，假设将来发现SHA-256不够强大，并且DKIM的使用转换为SHA-1024。签名者可以立即使用较新的算法进行签名，但也可以继续使用较旧的算法进行签名，以便与尚未升级的验证器进行互操作。签名者可以通过添加两个DKIM签名头字段来实现这一点，每个字段使用一种算法。没有将SHA-1024识别为可接受算法的旧验证器将跳过该签名并使用旧算法；较新的验证者可以选择使用其中一个签名，并且在所有其他条件相同的情况下，甚至可能不会尝试验证另一个签名。
Similarly, a Signer might sign a message including all header fields and no "l=" tag (to satisfy strict Verifiers) and a second time with a limited set of header fields and an "l=" tag (in anticipation of possible message modifications en route to other Verifiers). Verifiers could then choose which signature they prefer.
类似地，签名者可以对包含所有头字段和no“l=”标记的消息进行签名（以满足严格验证者的要求），并第二次使用有限的头字段集和“l=”标记进行签名（预期在发送到其他验证者的过程中可能会对消息进行修改）。然后验证者可以选择他们喜欢的签名。
Of course, a message might also have multiple signatures because it passed through multiple Signers. A common case is expected to be that of a signed message that passes through a mailing list that also
当然，消息也可能有多个签名，因为它通过了多个签名者。一种常见的情况是通过邮件列表传递的签名邮件，该邮件列表也
signs all messages. Assuming both of those signatures verify, a recipient might choose to accept the message if either of those signatures were known to come from trusted sources.
在所有消息上签名。假设这两个签名都经过验证，如果已知其中一个签名来自可信来源，则收件人可能会选择接受邮件。
In particular, recipients might choose to whitelist mailing lists to which they have subscribed and that have acceptable anti-abuse policies so as to accept messages sent to that list even from unknown authors. They might also subscribe to less trusted mailing lists (e.g., those without anti-abuse protection) and be willing to accept all messages from specific authors but insist on doing additional abuse scanning for other messages.
特别是，收件人可能会选择将其已订阅且具有可接受的反滥用策略的邮件列表列入白名单，以便接受发送到该列表的邮件，即使是来自未知作者的邮件。他们还可能订阅不太受信任的邮件列表（例如，那些没有反滥用保护的邮件），并愿意接受来自特定作者的所有邮件，但坚持对其他邮件进行额外的滥用扫描。
Another related example of multiple Signers might be forwarding services, such as those commonly associated with academic alumni sites. For example, a recipient might have an address at members.example.org, a site that has anti-abuse protection that is somewhat less effective than the recipient would prefer. Such a recipient might have specific authors whose messages would be trusted absolutely, but messages from unknown authors that had passed the forwarder's scrutiny would have only medium trust.
多个签名者的另一个相关示例可能是转发服务，例如通常与学术校友网站关联的服务。例如，收件人可能在members.example.org上有一个地址，该网站的反滥用保护效果比收件人希望的要差一些。这样的收件人可能有特定的作者，他们的邮件会被绝对信任，但来自通过转发器审查的未知作者的邮件将只有中等信任。
A Signer that is adding a signature to a message merely creates a new DKIM-Signature header, using the usual semantics of the "h=" option. A Signer MAY sign previously existing DKIM-Signature header fields using the method described in Section 5.4 to sign trace header fields.
向消息添加签名的签名者仅使用“h=”选项的常用语义创建一个新的DKIM签名头。签名者可以使用第5.4节中描述的方法对先前存在的DKIM签名头字段进行签名，以对跟踪头字段进行签名。
Note that Signers should be cognizant that signing DKIM-Signature header fields may result in signature failures with intermediaries that do not recognize that DKIM-Signature header fields are trace header fields and unwittingly reorder them, thus breaking such signatures. For this reason, signing existing DKIM-Signature header fields is unadvised, albeit legal.
请注意，签名者应认识到，对DKIM签名头字段进行签名可能会导致中介机构的签名失败，这些中介机构不认识到DKIM签名头字段是跟踪头字段，并无意中对其重新排序，从而破坏此类签名。因此，对现有DKIM签名头字段进行签名是不明智的，尽管是合法的。
INFORMATIVE NOTE: If a header field with multiple instances is signed, those header fields are always signed from the bottom up. Thus, it is not possible to sign only specific DKIM-Signature header fields. For example, if the message being signed already contains three DKIM-Signature header fields A, B, and C, it is possible to sign all of them, B and C only, or C only, but not A only, B only, A and B only, or A and C only.
资料性说明：如果对具有多个实例的标题字段进行签名，则这些标题字段始终从下至上进行签名。因此，不可能只对特定的DKIM签名头字段进行签名。例如，如果正在签名的消息已包含三个DKIM签名头字段A、B和C，则可以对所有字段进行签名，即仅对B和C进行签名，或仅对C进行签名，但不限于A、仅对B、仅对A和B进行签名，或仅对A和C进行签名。
A Signer MAY add more than one DKIM-Signature header field using different parameters. For example, during a transition period, a Signer might want to produce signatures using two different hash algorithms.
签名者可以使用不同的参数添加多个DKIM签名头字段。例如，在过渡期间，签名者可能希望使用两种不同的哈希算法生成签名。
Signers SHOULD NOT remove any DKIM-Signature header fields from messages they are signing, even if they know that the signatures cannot be verified.
签名者不应该从他们正在签名的消息中删除任何DKIM签名头字段，即使他们知道签名无法验证。
When evaluating a message with multiple signatures, a Verifier SHOULD evaluate signatures independently and on their own merits. For example, a Verifier that by policy chooses not to accept signatures with deprecated cryptographic algorithms would consider such signatures invalid. Verifiers MAY process signatures in any order of their choice; for example, some Verifiers might choose to process signatures corresponding to the From field in the message header before other signatures. See Section 6.1 for more information about signature choices.
当评估具有多个签名的消息时，验证器应独立评估签名并根据其自身的优点进行评估。例如，通过策略选择不接受带有弃权密码算法的签名的验证者会认为这些签名无效。验证者可按其选择的任何顺序处理签名；例如，一些验证器可能会选择先处理与消息头中的From字段相对应的签名，然后再处理其他签名。有关签名选择的更多信息，请参见第6.1节。
INFORMATIVE IMPLEMENTATION NOTE: Verifier attempts to correlate valid signatures with invalid signatures in an attempt to guess why a signature failed are ill-advised. In particular, there is no general way that a Verifier can determine that an invalid signature was ever valid.
信息性实现说明：验证器试图将有效签名与无效签名关联起来，试图猜测签名失败的原因是不明智的。特别是，验证器无法确定无效签名是否有效。
Verifiers SHOULD continue to check signatures until a signature successfully verifies to the satisfaction of the Verifier. To limit potential denial-of-service attacks, Verifiers MAY limit the total number of signatures they will attempt to verify.
验证者应继续检查签名，直到签名成功验证到验证者满意为止。为了限制潜在的拒绝服务攻击，验证者可以限制他们将尝试验证的签名总数。
If a Verifier module reports signatures whose evaluations produced PERMFAIL results, Identity Assessors SHOULD ignore those signatures (see Section 6.1), acting as though they were not present in the message.
如果验证器模块报告其评估结果不合格的签名，身份评估员应忽略这些签名（见第6.1节），就像它们不在消息中一样。
The following steps are performed in order by Signers.
签名者按顺序执行以下步骤。
A Signer can obviously only sign email for domains for which it has a private key and the necessary knowledge of the corresponding public key and selector information. However, there are a number of other reasons beyond the lack of a private key why a Signer could choose not to sign an email.
显然，签名者只能为其拥有私钥以及相应公钥和选择器信息的必要知识的域签署电子邮件。然而，除了缺少私钥之外，还有许多其他原因可以解释为什么签名者可以选择不签署电子邮件。
INFORMATIVE NOTE: A Signer can be implemented as part of any portion of the mail system as deemed appropriate, including an MUA, a SUBMISSION server, or an MTA. Wherever implemented, Signers should beware of signing (and thereby asserting responsibility for) messages that may be problematic. In particular, within a trusted enclave, the signing domain might be
资料性说明：签名者可以视情况作为邮件系统的任何部分实现，包括MUA、提交服务器或MTA。无论在何处实现，签名者都应该小心签名（从而声明对可能有问题的消息负责）。特别是，在受信任的enclave中，签名域可能是
derived from the header according to local policy; SUBMISSION servers might only sign messages from users that are properly authenticated and authorized.
根据本地策略从标头派生；提交服务器可能仅对来自经过正确身份验证和授权的用户的邮件进行签名。
INFORMATIVE IMPLEMENTER ADVICE: SUBMISSION servers should not sign Received header fields if the outgoing gateway MTA obfuscates Received header fields, for example, to hide the details of internal topology.
信息性实施者建议：如果传出网关MTA混淆了接收到的头字段（例如，为了隐藏内部拓扑的详细信息），则提交服务器不应对接收到的头字段进行签名。
If an email cannot be signed for some reason, it is a local policy decision as to what to do with that email.
如果由于某种原因无法对电子邮件进行签名，则应根据当地政策决定如何处理该电子邮件。
This specification does not define the basis by which a Signer should choose which private key and selector information to use. Currently, all selectors are equal as far as this specification is concerned, so the decision should largely be a matter of administrative convenience. Distribution and management of private keys is also outside the scope of this document.
本规范未定义签名者选择使用哪个私钥和选择器信息的依据。目前，就本规范而言，所有选择器都是平等的，因此决策在很大程度上应该是一个方便管理的问题。私钥的分发和管理也不在本文档的范围之内。
INFORMATIVE OPERATIONS ADVICE: A Signer should not sign with a private key when the selector containing the corresponding public key is expected to be revoked or removed before the Verifier has an opportunity to validate the signature. The Signer should anticipate that Verifiers can choose to defer validation, perhaps until the message is actually read by the final recipient. In particular, when rotating to a new key pair, signing should immediately commence with the new private key, and the old public key should be retained for a reasonable validation interval before being removed from the key server.
信息性操作建议：当包含相应公钥的选择器在验证器有机会验证签名之前被撤销或删除时，签名者不应使用私钥签名。签名者应该预期验证者可以选择推迟验证，也许直到最终接收者实际读取消息。特别是，当轮换到新密钥对时，签名应立即从新私钥开始，旧公钥应在从密钥服务器中删除之前保留一段合理的验证间隔。
Some messages, particularly those using 8-bit characters, are subject to modification during transit, notably conversion to 7-bit form. Such conversions will break DKIM signatures. In order to minimize the chances of such breakage, Signers SHOULD convert the message to a suitable MIME content-transfer encoding such as quoted-printable or base64 as described in [RFC2045] before signing. Such conversion is outside the scope of DKIM; the actual message SHOULD be converted to 7-bit MIME by an MUA or MSA prior to presentation to the DKIM algorithm.
一些消息，特别是使用8位字符的消息，在传输过程中会受到修改，特别是转换为7位格式。这种转换将破坏DKIM签名。为了尽量减少此类破坏的可能性，签名者应在签名之前将消息转换为合适的MIME内容传输编码，如[RFC2045]中所述的quoted printable或base64。此类转换不在DKIM的范围内；在呈现给DKIM算法之前，MUA或MSA应将实际消息转换为7位MIME。
If the message is submitted to the Signer with any local encoding that will be modified before transmission, that modification to canonical [RFC5322] form MUST be done before signing. In particular, bare CR or LF characters (used by some systems as a local line
如果消息以任何本地编码提交给签名者，并且在传输之前将对其进行修改，则必须在签名之前对规范[RFC5322]格式进行修改。特别是裸CR或LF字符（某些系统将其用作本地行）
separator convention) MUST be converted to the SMTP-standard CRLF sequence before the message is signed. Any conversion of this sort SHOULD be applied to the message actually sent to the recipient(s), not just to the version presented to the signing algorithm.
在签名邮件之前，必须将分隔符（约定）转换为SMTP标准CRLF序列。任何此类转换都应应用于实际发送给收件人的邮件，而不仅仅是提交给签名算法的版本。
More generally, the Signer MUST sign the message as it is expected to be received by the Verifier rather than in some local or internal form.
更一般地说，签名者必须按照预期由验证者接收的方式对消息进行签名，而不是以某种本地或内部形式进行签名。
A body length count MAY be specified to limit the signature calculation to an initial prefix of the body text, measured in octets. If the body length count is not specified, the entire message body is signed.
可以指定正文长度计数，以将签名计算限制为正文文本的初始前缀（以八位字节为单位）。如果未指定正文长度计数，则对整个消息正文进行签名。
INFORMATIVE RATIONALE: This capability is provided because it is very common for mailing lists to add trailers to messages (e.g., instructions on how to get off the list). Until those messages are also signed, the body length count is a useful tool for the Verifier since it can, as a matter of policy, accept messages having valid signatures with extraneous data.
信息性理由：之所以提供此功能，是因为邮件列表通常会在邮件中添加预告片（例如，关于如何从列表中删除的说明）。在这些消息也被签名之前，正文长度计数对于验证器来说是一个有用的工具，因为根据策略，它可以接受具有有效签名的消息和无关数据。
The length actually hashed should be inserted in the "l=" tag of the DKIM-Signature header field. (See Section 3.5.)
实际散列的长度应插入DKIM签名头字段的“l=”标记中。（见第3.5节。）
The body length count allows the Signer of a message to permit data to be appended to the end of the body of a signed message. The body length count MUST be calculated following the canonicalization algorithm; for example, any whitespace ignored by a canonicalization algorithm is not included as part of the body length count.
正文长度计数允许消息的签名者允许将数据附加到已签名消息正文的末尾。体长计数必须按照规范化算法计算；例如，规范化算法忽略的任何空白都不包括在正文长度计数中。
A body length count of zero means that the body is completely unsigned.
正文长度计数为零表示正文完全无符号。
Signers wishing to ensure that no modification of any sort can occur should specify the "simple" canonicalization algorithm for both header and body and omit the body length count.
希望确保不会发生任何类型的修改的签名者应为头和正文指定“简单”规范化算法，并忽略正文长度计数。
See Section 8.2 for further discussion.
进一步讨论见第8.2节。
The From header field MUST be signed (that is, included in the "h=" tag of the resulting DKIM-Signature header field). Signers SHOULD NOT sign an existing header field likely to be legitimately modified or removed in transit. In particular, [RFC5321] explicitly permits
必须对From标头字段进行签名（即，包含在生成的DKIM签名标头字段的“h=”标记中）。签名者不应对可能在传输过程中被合法修改或删除的现有标题字段进行签名。特别是，[RFC5321]明确允许
modification or removal of the Return-Path header field in transit. Signers MAY include any other header fields present at the time of signing at the discretion of the Signer.
在传输过程中修改或删除返回路径标题字段。签名人可自行决定在签名时包含任何其他标题字段。
INFORMATIVE OPERATIONS NOTE: The choice of which header fields to sign is non-obvious. One strategy is to sign all existing, non-repeatable header fields. An alternative strategy is to sign only header fields that are likely to be displayed to or otherwise be likely to affect the processing of the message at the receiver. A third strategy is to sign only "well-known" headers. Note that Verifiers may treat unsigned header fields with extreme skepticism, including refusing to display them to the end user or even ignoring the signature if it does not cover certain header fields. For this reason, signing fields present in the message such as Date, Subject, Reply-To, Sender, and all MIME header fields are highly advised.
信息性操作说明：选择要签名的标题字段并不明显。一种策略是对所有现有的、不可重复的头字段进行签名。另一种策略是仅对可能显示给接收者或可能影响接收者的消息处理的标题字段进行签名。第三种策略是只签署“知名”标题。请注意，验证器可能会对未签名的头字段持极端怀疑态度，包括拒绝向最终用户显示这些字段，甚至在签名不包含某些头字段时忽略签名。因此，强烈建议邮件中的签名字段，如日期、主题、回复、发件人和所有MIME头字段。
The DKIM-Signature header field is always implicitly signed and MUST NOT be included in the "h=" tag except to indicate that other preexisting signatures are also signed.
DKIM签名头字段始终是隐式签名的，不得包含在“h=”标记中，除非指示其他先前存在的签名也已签名。
Signers MAY claim to have signed header fields that do not exist (that is, Signers MAY include the header field name in the "h=" tag even if that header field does not exist in the message). When computing the signature, the nonexisting header field MUST be treated as the null string (including the header field name, header field value, all punctuation, and the trailing CRLF).
签名者可能声称其签名的标题字段不存在（即，签名者可能在“h=”标记中包含标题字段名称，即使该标题字段在消息中不存在）。计算签名时，不存在的头字段必须视为空字符串（包括头字段名称、头字段值、所有标点符号和尾随的CRLF）。
INFORMATIVE RATIONALE: This allows Signers to explicitly assert the absence of a header field; if that header field is added later, the signature will fail.
信息性理由：这允许签名者明确声明没有标题字段；如果稍后添加该标题字段，签名将失败。
INFORMATIVE NOTE: A header field name need only be listed once more than the actual number of that header field in a message at the time of signing in order to prevent any further additions. For example, if there is a single Comments header field at the time of signing, listing Comments twice in the "h=" tag is sufficient to prevent any number of Comments header fields from being appended; it is not necessary (but is legal) to list Comments three or more times in the "h=" tag.
资料性说明：在签名时，只需在消息中列出一个标题字段名称，该名称只需比该标题字段的实际编号多出一次，以防止进一步添加。例如，如果在签名时只有一个注释标题字段，则在“h=”标记中列出两次注释就足以防止附加任何数量的注释标题字段；在“h=”标签中列出评论三次或三次以上是不必要的（但合法的）。
Refer to Section 5.4.2 for a discussion of the procedure to be followed when canonicalizing a header with more than one instance of a particular header field name.
请参阅第5.4.2节，了解规范化具有多个特定标头字段名实例的标头时应遵循的过程的讨论。
Signers need to be careful of signing header fields that might have additional instances added later in the delivery process, since such header fields might be inserted after the signed instance or
签名者需要小心签名头字段，因为这些头字段可能会插入到已签名的实例之后，或者在交付过程中添加其他实例
otherwise reordered. Trace header fields (such as Received) and Resent-* blocks are the only fields prohibited by [RFC5322] from being reordered. In particular, since DKIM-Signature header fields may be reordered by some intermediate MTAs, signing existing DKIM-Signature header fields is error-prone.
否则重新排序。跟踪头字段（如Received）和Recent-*块是[RFC5322]禁止重新排序的唯一字段。特别是，由于某些中间MTA可能会对DKIM签名头字段重新排序，因此对现有DKIM签名头字段进行签名很容易出错。
INFORMATIVE ADMONITION: Despite the fact that [RFC5322] does not prohibit the reordering of header fields, reordering of signed header fields with multiple instances by intermediate MTAs will cause DKIM signatures to be broken; such antisocial behavior should be avoided.
信息性警告：尽管[RFC5322]不禁止对标头字段重新排序，但中间MTA对具有多个实例的签名标头字段重新排序将导致DKIM签名被破坏；应该避免这种反社会行为。
INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this specification, all end-user visible header fields should be signed to avoid possible "indirect spamming". For example, if the Subject header field is not signed, a spammer can resend a previously signed mail, replacing the legitimate subject with a one-line spam.
信息性实施者注意：尽管本规范不要求，但所有最终用户可见的标题字段都应签名，以避免可能的“间接垃圾邮件”。例如，如果主题标题字段未签名，则垃圾邮件发送者可以重新发送先前签名的邮件，将合法主题替换为单行垃圾邮件。
The purpose of the DKIM cryptographic algorithm is to affix an identifier to the message in a way that is both robust against normal transit-related changes and resistant to kinds of replay attacks. An essential aspect of satisfying these requirements is choosing what header fields to include in the hash and what fields to exclude.
DKIM加密算法的目的是以一种既能抵抗正常传输相关变化又能抵抗各种重放攻击的方式将标识符附加到消息上。满足这些要求的一个基本方面是选择要在哈希中包括哪些头字段以及要排除哪些字段。
The basic rule for choosing fields to include is to select those fields that constitute the "core" of the message content. Hence, any replay attack will have to include these in order to have the signature succeed; however, with these included, the core of the message is valid, even if sent on to new recipients.
选择要包含的字段的基本规则是选择构成消息内容“核心”的字段。因此，任何重放攻击都必须包括这些，才能使签名成功；但是，如果包含这些内容，则即使发送给新的收件人，邮件的核心也是有效的。
Common examples of fields with addresses and fields with textual content related to the body are:
包含地址的字段和包含正文相关文本内容的字段的常见示例如下：
o From (REQUIRED; see Section 5.4)
o 来自（必需；见第5.4节）
o Reply-To
o 答复
o Subject
o 主题
o Date
o 日期
o To, Cc
o 至，抄送
o Resent-Date, Resent-From, Resent-To, Resent-Cc
o 重新发送日期，重新发送自，重新发送至，重新发送抄送
o In-Reply-To, References
o 作为对参考文献的答复
o List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive
o 列表Id、列表帮助、列表取消订阅、列表订阅、列表发布、列表所有者、列表存档
If the "l=" signature tag is in use (see Section 3.5), the Content-Type field is also a candidate for being included as it could be replaced in a way that causes completely different content to be rendered to the receiving user.
如果正在使用“l=”签名标签（参见第3.5节），则内容类型字段也是一个候选字段，因为它可以被替换，从而导致向接收用户呈现完全不同的内容。
There are trade-offs in the decision of what constitutes the "core" of the message, which for some fields is a subjective concept. Including fields such as "Message-ID", for example, is useful if one considers a mechanism for being able to distinguish separate instances of the same message to be core content. Similarly, "In-Reply-To" and "References" might be desirable to include if one considers message threading to be a core part of the message.
在决定什么构成信息的“核心”时存在权衡，对于某些领域来说，这是一个主观概念。例如，如果考虑一种能够将同一消息的不同实例区分为核心内容的机制，则包括诸如“消息ID”之类的字段是有用的。类似地，如果认为消息线程是消息的核心部分，则可能需要包括“回复”和“引用”。
Another class of fields that may be of interest are those that convey security-related information about the message, such as Authentication-Results [RFC5451].
可能感兴趣的另一类字段是那些传递有关消息的安全相关信息的字段，例如身份验证结果[RFC5451]。
The basic rule for choosing fields to exclude is to select those fields for which there are multiple fields with the same name and fields that are modified in transit. Examples of these are:
选择要排除的字段的基本规则是选择有多个同名字段以及在传输过程中修改的字段的字段。例如：
o Return-Path
o 返回路径
o Received
o 收到
o Comments, Keywords
o 评论、关键词
Note that the DKIM-Signature field is also excluded from the header hash because its handling is specified separately.
注意，DKIM签名字段也被排除在头散列之外，因为它的处理是单独指定的。
Typically, it is better to exclude other optional fields because of the potential that additional fields of the same name will be legitimately added or reordered prior to verification. There are likely to be legitimate exceptions to this rule because of the wide variety of application-specific header fields that might be applied to a message, some of which are unlikely to be duplicated, modified, or reordered.
通常，最好排除其他可选字段，因为可能会在验证之前合法添加或重新排序同名的其他字段。此规则可能存在合法的例外情况，因为可能应用于消息的应用程序特定的报头字段种类繁多，其中一些字段不太可能被复制、修改或重新排序。
Signers SHOULD choose canonicalization algorithms based on the types of messages they process and their aversion to risk. For example, e-commerce sites sending primarily purchase receipts, which are not expected to be processed by mailing lists or other software likely to modify messages, will generally prefer "simple" canonicalization.
签名者应该根据他们处理的消息类型和他们对风险的厌恶程度来选择规范化算法。例如，主要发送采购收据的电子商务网站通常倾向于“简单”规范化，而这些收据预计不会被邮件列表或其他可能修改邮件的软件处理。
Sites sending primarily person-to-person email will likely prefer to be more resilient to modification during transport by using "relaxed" canonicalization.
主要发送人与人之间电子邮件的站点可能更倾向于通过使用“宽松”规范化，在传输过程中更容易修改。
Unless mail is processed through intermediaries, such as mailing lists that might add "unsubscribe" instructions to the bottom of the message body, the "l=" tag is likely to convey no additional benefit while providing an avenue for unauthorized addition of text to a message. The use of "l=0" takes this to the extreme, allowing complete alteration of the text of the message without invalidating the signature. Moreover, a Verifier would be within its rights to consider a partly signed message body as unacceptable. Judicious use is advised.
除非邮件是通过中间人处理的，例如邮件列表可能会在邮件正文底部添加“unsubscribe”指令，“l=”标记可能不会带来额外的好处，同时为未经授权向邮件添加文本提供了途径。“l=0”的使用将这一点发挥到了极致，允许在不使签名无效的情况下完全更改消息文本。此外，验证者将在其权限内考虑部分签名的消息主体是不可接受的。建议谨慎使用。
Signers choosing to sign an existing header field that occurs more than once in the message (such as Received) MUST sign the physically last instance of that header field in the header block. Signers wishing to sign multiple instances of such a header field MUST include the header field name multiple times in the "h=" tag of the DKIM-Signature header field and MUST sign such header fields in order from the bottom of the header field block to the top. The Signer MAY include more instances of a header field name in "h=" than there are actual corresponding header fields so that the signature will not verify if additional header fields of that name are added.
选择对消息中多次出现的现有标头字段（如Received）进行签名的签名者必须对标头块中该标头字段的最后一个实例进行物理签名。希望对此类标题字段的多个实例进行签名的签名者必须在DKIM签名标题字段的“h=”标记中多次包含标题字段名称，并且必须按照从标题字段块底部到顶部的顺序对此类标题字段进行签名。签名人可能在“h=”中包含的标题字段名称实例多于实际对应的标题字段，因此签名不会验证是否添加了该名称的其他标题字段。
INFORMATIVE EXAMPLE:
资料性示例：
If the Signer wishes to sign two existing Received header fields, and the existing header contains:
如果签名者希望对两个现有接收的标头字段进行签名，并且现有标头包含：
Received: <A>
Received: <B>
Received: <C>
Received: <A>
Received: <B>
Received: <C>
then the resulting DKIM-Signature header field should read:
然后，生成的DKIM签名头字段应为：
DKIM-Signature: ... h=Received : Received :...
DKIM签名：。。。h=已接收：已接收：。。。
and Received header fields <C> and <B> will be signed in that order.
接收到的头字段<C>和<B>将按该顺序签名。
The Signer MUST compute the message hash as described in Section 3.7 and then sign it using the selected public-key algorithm. This will result in a DKIM-Signature header field that will include the body hash and a signature of the header hash, where that header includes the DKIM-Signature header field itself.
签名者必须按照第3.7节所述计算消息散列，然后使用选定的公钥算法对其进行签名。这将产生一个DKIM签名头字段，该字段将包括正文散列和头散列的签名，其中该头包括DKIM签名头字段本身。
Entities such as mailing list managers that implement DKIM and that modify the message or a header field (for example, inserting unsubscribe information) before retransmitting the message SHOULD check any existing signature on input and MUST make such modifications before re-signing the message.
实现DKIM并在重新传输消息之前修改消息或标题字段（例如，插入取消订阅信息）的实体（如邮件列表管理器）应检查输入上的任何现有签名，并且必须在对消息重新签名之前进行此类修改。
Finally, the Signer MUST insert the DKIM-Signature header field created in the previous step prior to transmitting the email. The DKIM-Signature header field MUST be the same as used to compute the hash as described above, except that the value of the "b=" tag MUST be the appropriately signed hash computed in the previous step, signed using the algorithm specified in the "a=" tag of the DKIM-Signature header field and using the private key corresponding to the selector given in the "s=" tag of the DKIM-Signature header field, as chosen above in Section 5.2.
最后，签名者必须在发送电子邮件之前插入在上一步中创建的DKIM签名头字段。DKIM Signature header字段必须与用于如上所述计算哈希的字段相同，但“b=”标记的值必须是在上一步中计算的、使用“a=”中指定的算法进行签名的适当签名哈希标记DKIM签名头字段，并使用与DKIM签名头字段的“s=”标记中给出的选择器相对应的私钥，如上文第5.2节所述。
The DKIM-Signature header field MUST be inserted before any other DKIM-Signature fields in the header block.
DKIM签名头字段必须插入头块中任何其他DKIM签名字段之前。
INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this is to insert the DKIM-Signature header field at the beginning of the header block. In particular, it may be placed before any existing Received header fields. This is consistent with treating DKIM-Signature as a trace header field.
信息性实现说明：实现这一点的最简单方法是在头块的开头插入DKIM签名头字段。特别是，它可以放在任何现有的接收头字段之前。这与将DKIM签名视为跟踪头字段是一致的。
Since a Signer MAY remove or revoke a public key at any time, it is advised that verification occur in a timely manner. In many configurations, the most timely place is during acceptance by the border MTA or shortly thereafter. In particular, deferring verification until the message is accessed by the end user is discouraged.
由于签名者可以随时删除或撤销公钥，因此建议及时进行验证。在许多配置中，最及时的位置是边境MTA验收期间或之后不久。特别是，不鼓励在最终用户访问消息之前延迟验证。
A border or intermediate MTA MAY verify the message signature(s). An MTA who has performed verification MAY communicate the result of that verification by adding a verification header field to incoming messages. This simplifies things considerably for the user, who can
边框或中间MTA可能会验证邮件签名。已执行验证的MTA可以通过向传入消息添加验证标头字段来传达验证结果。这大大简化了用户的工作，用户可以
now use an existing mail user agent. Most MUAs have the ability to filter messages based on message header fields or content; these filters would be used to implement whatever policy the user wishes with respect to unsigned mail.
现在使用现有的邮件用户代理。大多数MUA能够根据消息头字段或内容过滤消息；这些过滤器将用于实现用户希望的有关未签名邮件的任何策略。
A verifying MTA MAY implement a policy with respect to unverifiable mail, regardless of whether or not it applies the verification header field to signed messages.
验证MTA可能会针对无法验证的邮件实施策略，无论其是否将验证标头字段应用于已签名邮件。
Verifiers MUST produce a result that is semantically equivalent to applying the steps listed in Sections 6.1, 6.1.1, and 6.1.2 in order. In practice, several of these steps can be performed in parallel in order to improve performance.
验证者必须产生语义上等同于按顺序应用第6.1节、第6.1.1节和第6.1.2节中列出的步骤的结果。实际上，为了提高性能，可以并行执行其中几个步骤。
The order in which Verifiers try DKIM-Signature header fields is not defined; Verifiers MAY try signatures in any order they like. For example, one implementation might try the signatures in textual order, whereas another might try signatures by identities that match the contents of the From header field before trying other signatures. Verifiers MUST NOT attribute ultimate meaning to the order of multiple DKIM-Signature header fields. In particular, there is reason to believe that some relays will reorder the header fields in potentially arbitrary ways.
未定义验证器尝试DKIM签名头字段的顺序；验证者可以按他们喜欢的任何顺序尝试签名。例如，一个实现可能会按文本顺序尝试签名，而另一个实现可能会在尝试其他签名之前，通过与From头字段内容匹配的标识尝试签名。验证者不得将最终含义归因于多个DKIM签名头字段的顺序。特别是，有理由相信某些中继将以潜在的任意方式对报头字段重新排序。
INFORMATIVE IMPLEMENTATION NOTE: Verifiers might use the order as a clue to signing order in the absence of any other information. However, other clues as to the semantics of multiple signatures (such as correlating the signing host with Received header fields) might also be considered.
信息性实现说明：在没有任何其他信息的情况下，验证者可能会使用订单作为签署订单的线索。但是，也可以考虑关于多个签名语义的其他线索（例如将签名主机与接收到的头字段相关联）。
Survivability of signatures after transit is not guaranteed, and signatures can fail to verify through no fault of the Signer. Therefore, a Verifier SHOULD NOT treat a message that has one or more bad signatures and no good signatures differently from a message with no signature at all.
传输后签名的生存性无法得到保证，签名可能无法验证，这与签名者的过错无关。因此，验证器不应将具有一个或多个坏签名且没有好签名的消息与完全没有签名的消息区别对待。
When a signature successfully verifies, a Verifier will either stop processing or attempt to verify any other signatures, at the discretion of the implementation. A Verifier MAY limit the number of signatures it tries, in order to avoid denial-of-service attacks (see Section 8.4 for further discussion).
当签名成功验证时，验证器将停止处理或尝试验证任何其他签名，由实现自行决定。验证器可以限制其尝试的签名数量，以避免拒绝服务攻击（有关进一步讨论，请参阅第8.4节）。
In the following description, text reading "return status (explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL") means that the Verifier MUST immediately cease processing that signature. The Verifier SHOULD proceed to the next signature, if one
在以下描述中，文本读取“返回状态（解释）”（其中“状态”是“PERMFAIL”或“TEMPFAIL”之一）意味着验证者必须立即停止处理该签名。验证人应继续进行下一个签名（如果有）
is present, and completely ignore the bad signature. If the status is "PERMFAIL", the signature failed and should not be reconsidered. If the status is "TEMPFAIL", the signature could not be verified at this time but may be tried again later. A Verifier MAY either arrange to defer the message for later processing or try another signature; if no good signature is found and any of the signatures resulted in a TEMPFAIL status, the Verifier MAY arrange to defer the message for later processing. The "(explanation)" is not normative text; it is provided solely for clarification.
存在，并完全忽略错误的签名。如果状态为“PERMFAIL”，则签名失败，不应重新考虑。如果状态为“TEMPFAIL”，此时无法验证签名，但可以稍后重试。验证者可以安排延迟消息以便稍后处理，或者尝试另一个签名；如果没有找到好的签名，并且任何签名导致TEMPFAIL状态，验证器可以安排延迟消息以供以后处理。“（解释）”不是规范性文本；本文件仅供澄清之用。
Verifiers that are prepared to validate multiple signature header fields SHOULD proceed to the next signature header field, if one exists. However, Verifiers MAY make note of the fact that an invalid signature was present for consideration at a later step.
准备验证多个签名头字段的验证器应转到下一个签名头字段（如果存在）。然而，验证者可能会注意到一个事实，即存在一个无效的签名供以后的步骤考虑。
INFORMATIVE NOTE: The rationale of this requirement is to permit messages that have invalid signatures but also a valid signature to work. For example, a mailing list exploder might opt to leave the original submitter signature in place even though the exploder knows that it is modifying the message in some way that will break that signature, and the exploder inserts its own signature. In this case, the message should succeed even in the presence of the known-broken signature.
资料性说明：此要求的基本原理是允许具有无效签名但也具有有效签名的消息工作。例如，邮件列表分解器可能会选择保留原始提交者签名，即使分解器知道它正在以某种方式修改消息，从而破坏该签名，并且分解器会插入自己的签名。在这种情况下，即使存在已知的损坏签名，消息也应该成功。
For each signature to be validated, the following steps should be performed in such a manner as to produce a result that is semantically equivalent to performing them in the indicated order.
对于要验证的每个签名，应以这样的方式执行以下步骤，以产生语义上等同于按指示顺序执行它们的结果。
Implementers MUST meticulously validate the format and values in the DKIM-Signature header field; any inconsistency or unexpected values MUST cause the header field to be completely ignored and the Verifier to return PERMFAIL (signature syntax error). Being "liberal in what you accept" is definitely a bad strategy in this security context. Note, however, that this does not include the existence of unknown tags in a DKIM-Signature header field, which are explicitly permitted. Verifiers MUST return PERMFAIL (incompatible version) when presented a DKIM-Signature header field with a "v=" tag that is inconsistent with this specification.
实施者必须仔细验证DKIM签名头字段中的格式和值；任何不一致或意外的值都必须导致标头字段被完全忽略，并且验证器返回PERMFAIL（签名语法错误）。在这种安全环境下，“在你接受的东西上自由”绝对是一种糟糕的策略。但是，请注意，这并不包括DKIM签名头字段中存在明确允许的未知标记。当DKIM签名头字段带有与本规范不一致的“v=”标记时，验证器必须返回PERMFAIL（不兼容版本）。
INFORMATIVE IMPLEMENTATION NOTE: An implementation may, of course, choose to also verify signatures generated by older versions of this specification.
信息性实现说明：当然，实现也可以选择验证本规范较旧版本生成的签名。
If any tag listed as "required" in Section 3.5 is omitted from the DKIM-Signature header field, the Verifier MUST ignore the DKIM-Signature header field and return PERMFAIL (signature missing required tag).
如果第3.5节中列为“必需”的任何标记从DKIM签名头字段中省略，验证者必须忽略DKIM签名头字段并返回PERMFAIL（签名缺少必需标记）。
INFORMATIVE NOTE: The tags listed as required in Section 3.5 are "v=", "a=", "b=", "bh=", "d=", "h=", and "s=". Should there be a conflict between this note and Section 3.5, Section 3.5 is normative.
资料性说明：第3.5节中列出的标签为“v=”、“a=”、“b=”、“bh=”、“d=”、“h=”和“s=”。如果本说明与第3.5节之间存在冲突，则第3.5节为规范性说明。
If the DKIM-Signature header field does not contain the "i=" tag, the Verifier MUST behave as though the value of that tag were "@d", where "d" is the value from the "d=" tag.
如果DKIM签名头字段不包含“i=”标记，则验证器的行为必须与该标记的值为“@d”一样，其中“d”是“d=”标记的值。
Verifiers MUST confirm that the domain specified in the "d=" tag is the same as or a parent domain of the domain part of the "i=" tag. If not, the DKIM-Signature header field MUST be ignored, and the Verifier should return PERMFAIL (domain mismatch).
验证者必须确认“d=”标记中指定的域与“i=”标记的域部分相同或是其父域。否则，必须忽略DKIM签名头字段，验证器应返回PERMFAIL（域不匹配）。
If the "h=" tag does not include the From header field, the Verifier MUST ignore the DKIM-Signature header field and return PERMFAIL (From field not signed).
如果“h=”标记不包括From标头字段，则验证器必须忽略DKIM签名标头字段并返回PERMFAIL（From字段未签名）。
Verifiers MAY ignore the DKIM-Signature header field and return PERMFAIL (signature expired) if it contains an "x=" tag and the signature has expired.
如果包含“x=”标记且签名已过期，验证者可以忽略DKIM签名头字段并返回PERMFAIL（签名已过期）。
Verifiers MAY ignore the DKIM-Signature header field if the domain used by the Signer in the "d=" tag is not associated with a valid signing entity. For example, signatures with "d=" values such as "com" and "co.uk" could be ignored. The list of unacceptable domains SHOULD be configurable.
如果签名者在“d=”标记中使用的域未与有效的签名实体关联，则验证者可以忽略DKIM签名头字段。例如，可以忽略带有“d=”值的签名，例如“com”和“co.uk”。不可接受域的列表应该是可配置的。
Verifiers MAY ignore the DKIM-Signature header field and return PERMFAIL (unacceptable signature header) for any other reason, for example, if the signature does not sign header fields that the Verifier views to be essential. As a case in point, if MIME header fields are not signed, certain attacks may be possible that the Verifier would prefer to avoid.
验证者可能会忽略DKIM签名头字段，并出于任何其他原因返回PERMFAIL（不可接受的签名头），例如，如果签名没有对验证者认为重要的头字段进行签名。举个例子，如果MIME头字段没有签名，验证器可能希望避免某些攻击。
The public key for a signature is needed to complete the verification process. The process of retrieving the public key depends on the query type as defined by the "q=" tag in the DKIM-Signature header field. Obviously, a public key need only be retrieved if the process of extracting the signature information is completely successful.
完成验证过程需要签名的公钥。检索公钥的过程取决于DKIM签名头字段中“q=”标记定义的查询类型。显然，只有在提取签名信息的过程完全成功的情况下，才需要检索公钥。
Details of key management and representation are described in Section 3.6. The Verifier MUST validate the key record and MUST ignore any public-key records that are malformed.
第3.6节描述了密钥管理和表示的详细信息。验证器必须验证密钥记录，并且必须忽略任何格式错误的公钥记录。
NOTE: The use of a wildcard TXT RR that covers a queried DKIM domain name will produce a response to a DKIM query that is unlikely to be a valid DKIM key record. This problem is not specific to DKIM and applies to many other types of queries. Client software that processes DNS responses needs to take this problem into account.
注意：使用覆盖查询的DKIM域名的通配符TXT RR将生成对DKIM查询的响应，该查询不太可能是有效的DKIM密钥记录。这个问题不是DKIM特有的，它适用于许多其他类型的查询。处理DNS响应的客户端软件需要考虑这个问题。
When validating a message, a Verifier MUST perform the following steps in a manner that is semantically the same as performing them in the order indicated; in some cases, the implementation may parallelize or reorder these steps, as long as the semantics remain unchanged:
验证消息时，验证器必须以语义上与按指示顺序执行相同的方式执行以下步骤；在某些情况下，只要语义保持不变，实现可以并行化或重新排序这些步骤：
1. The Verifier retrieves the public key as described in Section 3.6 using the algorithm in the "q=" tag, the domain from the "d=" tag, and the selector from the "s=" tag.
1. 验证器使用“q=”标记中的算法，从“d=”标记中检索域，从“s=”标记中检索选择器，如第3.6节所述检索公钥。
2. If the query for the public key fails to respond, the Verifier MAY seek a later verification attempt by returning TEMPFAIL (key unavailable).
2. 如果对公钥的查询没有响应，验证器可以通过返回TEMPFAIL（密钥不可用）来寻求以后的验证尝试。
3. If the query for the public key fails because the corresponding key record does not exist, the Verifier MUST immediately return PERMFAIL (no key for signature).
3. 如果由于相应的密钥记录不存在而导致公钥查询失败，验证器必须立即返回PERMFAIL（无签名密钥）。
4. If the query for the public key returns multiple key records, the Verifier can choose one of the key records or may cycle through the key records, performing the remainder of these steps on each record at the discretion of the implementer. The order of the key records is unspecified. If the Verifier chooses to cycle through the key records, then the "return ..." wording in the remainder of this section means "try the next key record, if any; if none, return to try another signature in the usual way".
4. 如果对公钥的查询返回多个密钥记录，那么验证者可以选择其中一个密钥记录，或者可以循环遍历密钥记录，由实现者自行决定对每个记录执行这些步骤的其余部分。未指定键记录的顺序。如果验证者选择循环检查密钥记录，则本节剩余部分中的“返回…”措辞意味着“尝试下一个密钥记录，如果有；如果没有，返回以通常的方式尝试另一个签名”。
5. If the result returned from the query does not adhere to the format defined in this specification, the Verifier MUST ignore the key record and return PERMFAIL (key syntax error). Verifiers are urged to validate the syntax of key records carefully to avoid attempted attacks. In particular, the Verifier MUST ignore keys with a version code ("v=" tag) that they do not implement.
5. 如果查询返回的结果不符合本规范中定义的格式，验证器必须忽略密钥记录并返回PERMFAIL（密钥语法错误）。敦促验证者仔细验证密钥记录的语法，以避免尝试攻击。特别是，验证器必须忽略带有版本代码（“v=”标记）的密钥，这些密钥没有实现。
6. If the "h=" tag exists in the public-key record and the hash algorithm implied by the "a=" tag in the DKIM-Signature header field is not included in the contents of the "h=" tag, the Verifier MUST ignore the key record and return PERMFAIL (inappropriate hash algorithm).
6. 如果公钥记录中存在“h=”标记，并且DKIM签名头字段中的“a=”标记隐含的哈希算法未包含在“h=”标记的内容中，则验证器必须忽略密钥记录并返回PERMFAIL（不适当的哈希算法）。
7. If the public-key data (the "p=" tag) is empty, then this key has been revoked and the Verifier MUST treat this as a failed signature check and return PERMFAIL (key revoked). There is no defined semantic difference between a key that has been revoked and a key record that has been removed.
7. 如果公钥数据（“p=”标记）为空，则该密钥已被撤销，验证器必须将其视为失败的签名检查并返回PERMFAIL（密钥撤销）。已撤销的密钥和已删除的密钥记录之间没有定义的语义差异。
8. If the public-key data is not suitable for use with the algorithm and key types defined by the "a=" and "k=" tags in the DKIM-Signature header field, the Verifier MUST immediately return PERMFAIL (inappropriate key algorithm).
8. 如果公钥数据不适合与DKIM签名头字段中“a=”和“k=”标记定义的算法和密钥类型一起使用，验证器必须立即返回PERMFAIL（不合适的密钥算法）。
Given a Signer and a public key, verifying a signature consists of actions semantically equivalent to the following steps.
在给定签名者和公钥的情况下，验证签名由语义上等同于以下步骤的操作组成。
1. Based on the algorithm defined in the "c=" tag, the body length specified in the "l=" tag, and the header field names in the "h=" tag, prepare a canonicalized version of the message as is described in Section 3.7 (note that this canonicalized version does not actually replace the original content). When matching header field names in the "h=" tag against the actual message header field, comparisons MUST be case-insensitive.
1. 根据“c=”标记中定义的算法、“l=”标记中指定的正文长度和“h=”标记中的标题字段名称，按照第3.7节中的说明准备消息的规范化版本（请注意，此规范化版本实际上并不替换原始内容）。将“h=”标记中的标题字段名称与实际消息标题字段进行匹配时，比较必须不区分大小写。
2. Based on the algorithm indicated in the "a=" tag, compute the message hashes from the canonical copy as described in Section 3.7.
2. 根据“a=”标记中指示的算法，根据第3.7节中所述的规范副本计算消息哈希。
3. Verify that the hash of the canonicalized message body computed in the previous step matches the hash value conveyed in the "bh=" tag. If the hash does not match, the Verifier SHOULD ignore the signature and return PERMFAIL (body hash did not verify).
3. 验证在上一步中计算的规范化消息体的哈希值是否与“bh=”标记中传递的哈希值匹配。如果散列不匹配，验证器应该忽略签名并返回PERMFAIL（body散列未验证）。
4. Using the signature conveyed in the "b=" tag, verify the signature against the header hash using the mechanism appropriate for the public-key algorithm described in the "a=" tag. If the signature does not validate, the Verifier SHOULD ignore the signature and return PERMFAIL (signature did not verify).
4. 使用“b=”标记中传递的签名，使用适用于“a=”标记中描述的公钥算法的机制，根据标头散列验证签名。如果签名未验证，验证者应忽略签名并返回PERMFAIL（签名未验证）。
5. Otherwise, the signature has correctly verified.
5. 否则，签名已正确验证。
INFORMATIVE IMPLEMENTER'S NOTE: Implementations might wish to initiate the public-key query in parallel with calculating the hash as the public key is not needed until the final decryption is calculated. Implementations may also verify the signature on the message header before validating that the message hash listed in the "bh=" tag in the DKIM-Signature header field matches that of the actual message body; however, if the body hash does not match, the entire signature must be considered to have failed.
信息性实现者注意：实现可能希望在计算哈希的同时启动公钥查询，因为在计算最终解密之前不需要公钥。在验证DKIM signature header字段中“bh=”标记中列出的消息哈希是否与实际消息体的哈希匹配之前，实现还可以验证消息头上的签名；但是，如果正文哈希不匹配，则必须将整个签名视为失败。
A body length specified in the "l=" tag of the signature limits the number of bytes of the body passed to the verification algorithm. All data beyond that limit is not validated by DKIM. Hence, Verifiers might treat a message that contains bytes beyond the indicated body length with suspicion and can choose to treat the signature as if it were invalid (e.g., by returning PERMFAIL (unsigned content)).
签名的“l=”标记中指定的正文长度限制了传递给验证算法的正文字节数。DKIM不会验证超过该限制的所有数据。因此，验证器可能会怀疑包含超出指定正文长度字节的消息，并可以选择将签名视为无效（例如，通过返回PERMFAIL（未签名内容））。
Should the algorithm reach this point, the verification has succeeded, and DKIM reports SUCCESS for this signature.
如果算法达到这一点，则验证已成功，DKIM报告此签名成功。
Verifiers wishing to communicate the results of verification to other parts of the mail system may do so in whatever manner they see fit. For example, implementations might choose to add an email header field to the message before passing it on. Any such header field SHOULD be inserted before any existing DKIM-Signature or preexisting authentication status header fields in the header field block. The Authentication-Results: header field ([RFC5451]) MAY be used for this purpose.
希望将验证结果传达给邮件系统其他部分的验证者可采用其认为合适的任何方式。例如，实现可能会选择在传递消息之前向消息添加电子邮件头字段。任何此类头字段都应插入头字段块中任何现有DKIM签名或先前存在的身份验证状态头字段之前。验证结果：头字段（[RFC5451]）可用于此目的。
INFORMATIVE ADVICE to MUA filter writers: Patterns intended to search for results header fields to visibly mark authenticated mail for end users should verify that such a header field was added by the appropriate verifying domain and that the verified identity matches the author identity that will be displayed by the MUA. In particular, MUA filters should not be influenced by bogus results header fields added by attackers. To circumvent this attack, Verifiers MAY wish to request deletion of existing results header fields after verification and before arranging to add a new header field.
向MUA筛选器编写者提供的信息性建议：用于搜索结果标题字段以便为最终用户可视地标记已验证邮件的模式应验证此类标题字段是否由适当的验证域添加，以及验证的身份是否与MUA将显示的作者身份匹配。特别是，MUA筛选器不应受到攻击者添加的虚假结果标题字段的影响。为了避免这种攻击，验证人员可能希望在验证之后和安排添加新的头字段之前请求删除现有的结果头字段。
It is beyond the scope of this specification to describe what actions an Identity Assessor can make, but mail carrying a validated SDID presents an opportunity to an Identity Assessor that unauthenticated email does not. Specifically, an authenticated email creates a predictable identifier by which other decisions can reliably be managed, such as trust and reputation. Conversely, unauthenticated email lacks a reliable identifier that can be used to assign trust and reputation. It is reasonable to treat unauthenticated email as lacking any trust and having no positive reputation.
描述身份评估员可以采取的行动超出了本规范的范围，但带有已验证SDID的邮件为身份评估员提供了未经验证的电子邮件无法提供的机会。具体来说，经过身份验证的电子邮件会创建一个可预测的标识符，通过该标识符可以可靠地管理其他决策，例如信任和声誉。相反，未经验证的电子邮件缺少可用于分配信任和声誉的可靠标识符。将未经验证的电子邮件视为缺乏信任和没有正面声誉是合理的。
In general, modules that consume DKIM verification output SHOULD NOT determine message acceptability based solely on a lack of any signature or on an unverifiable signature; such rejection would cause severe interoperability problems. If an MTA does wish to reject such messages during an SMTP session (for example, when communicating with a peer who, by prior agreement, agrees to only send signed messages), and a signature is missing or does not verify, the handling MTA SHOULD use a 550/5.7.x reply code.
通常，使用DKIM验证输出的模块不应仅基于缺少任何签名或无法验证的签名来确定消息的可接受性；这种拒绝将导致严重的互操作性问题。如果MTA确实希望在SMTP会话期间拒绝此类邮件（例如，与事先同意只发送签名邮件的对等方通信时），并且签名丢失或未验证，则处理MTA应使用550/5.7.x回复代码。
Where the Verifier is integrated within the MTA and it is not possible to fetch the public key, perhaps because the key server is not available, a temporary failure message MAY be generated using a 451/4.7.5 reply code, such as:
如果验证器集成在MTA中，并且可能因为密钥服务器不可用而无法获取公钥，则可以使用451/4.7.5回复代码生成临时失败消息，例如：
451 4.7.5 Unable to verify signature - key server unavailable
451 4.7.5无法验证签名-密钥服务器不可用
Temporary failures such as inability to access the key server or other external service are the only conditions that SHOULD use a 4xx SMTP reply code. In particular, cryptographic signature verification failures MUST NOT provoke 4xx SMTP replies.
临时故障（如无法访问密钥服务器或其他外部服务）是应使用4xx SMTP回复代码的唯一条件。特别是，加密签名验证失败不得引发4xx SMTP回复。
Once the signature has been verified, that information MUST be conveyed to the Identity Assessor (such as an explicit allow/ whitelist and reputation system) and/or to the end user. If the SDID is not the same as the address in the From: header field, the mail system SHOULD take pains to ensure that the actual SDID is clear to the reader.
签名验证后，必须将该信息传达给身份评估员（如明确的允许/白名单和声誉系统）和/或最终用户。如果SDID与From:header字段中的地址不同，邮件系统应尽力确保读者清楚实际的SDID。
While the symptoms of a failed verification are obvious -- the signature doesn't verify -- establishing the exact cause can be more difficult. If a selector cannot be found, is that because the selector has been removed, or was the value changed somehow in transit? If the signature line is missing, is that because it was never there, or was it removed by an overzealous filter? For diagnostic purposes, the exact reason why the verification fails SHOULD be made available and possibly recorded in the system logs.
虽然验证失败的症状很明显——签名无法验证——但确定确切原因可能更困难。如果找不到选择器，是因为选择器已被删除，还是在传输过程中该值发生了更改？如果签名行丢失，是因为它从未出现过，还是因为它被过度热心的过滤器删除了？出于诊断目的，应提供验证失败的确切原因，并可能记录在系统日志中。
If the email cannot be verified, then it SHOULD be treated the same as all unverified email, regardless of whether or not it looks like it was signed.
如果无法验证电子邮件，则应将其视为所有未经验证的电子邮件，无论其看起来是否已签名。
See Section 8.15 for additional discussion.
更多讨论见第8.15节。
DKIM has registered namespaces with IANA. In all cases, new values are assigned only for values that have been documented in a published RFC that has IETF Consensus [RFC5226].
DKIM已向IANA注册了名称空间。在所有情况下，新值仅分配给已发布且具有IETF共识[RFC5226]的RFC中记录的值。
This memo updates these registries as described below. Of note is the addition of a new "status" column. All registrations into these namespaces MUST include the name being registered, the document in which it was registered or updated, and an indication of its current status, which MUST be one of "active" (in current use) or "historic" (no longer in current use).
此备忘录更新了这些注册表，如下所述。值得注意的是增加了一个新的“状态”栏。这些名称空间中的所有注册必须包括正在注册的名称、注册或更新该名称的文档以及其当前状态的指示，该状态必须是“活动”（当前使用）或“历史”（不再当前使用）之一。
No new tags are defined in this specification compared to [RFC4871], but one has been designated as "historic".
与[RFC4871]相比，本规范中未定义任何新标签，但其中一个标签被指定为“历史标签”。
Also, the "Email Authentication Methods" registry is revised to refer to this update.
此外，“电子邮件验证方法”注册表也进行了修订，以引用此更新。
The "Email Authentication Methods" registry is updated to indicate that "dkim" is defined in this memo.
“电子邮件验证方法”注册表已更新，以表明本备忘录中定义了“dkim”。
A DKIM-Signature provides for a list of tag specifications. IANA has established the "DKIM-Signature Tag Specifications" registry for tag specifications that can be used in DKIM-Signature fields.
DKIM签名提供标签规范列表。IANA已经建立了“DKIM签名标签规范”注册表，用于可用于DKIM签名字段的标签规范。
+------+-----------------+--------+
| TYPE | REFERENCE | STATUS |
+------+-----------------+--------+
| v | (this document) | active |
| a | (this document) | active |
| b | (this document) | active |
| bh | (this document) | active |
| c | (this document) | active |
| d | (this document) | active |
| h | (this document) | active |
| i | (this document) | active |
| l | (this document) | active |
| q | (this document) | active |
| s | (this document) | active |
| t | (this document) | active |
| x | (this document) | active |
| z | (this document) | active |
+------+-----------------+--------+
+------+-----------------+--------+
| TYPE | REFERENCE | STATUS |
+------+-----------------+--------+
| v | (this document) | active |
| a | (this document) | active |
| b | (this document) | active |
| bh | (this document) | active |
| c | (this document) | active |
| d | (this document) | active |
| h | (this document) | active |
| i | (this document) | active |
| l | (this document) | active |
| q | (this document) | active |
| s | (this document) | active |
| t | (this document) | active |
| x | (this document) | active |
| z | (this document) | active |
+------+-----------------+--------+
Table 1: DKIM-Signature Tag Specifications Registry Updated Values
表1:DKIM签名标签规范注册表更新值
The "q=" tag-spec (specified in Section 3.5) provides for a list of query methods.
“q=”标签规范（在第3.5节中指定）提供了查询方法列表。
IANA has established the "DKIM-Signature Query Method" registry for mechanisms that can be used to retrieve the key that will permit validation processing of a message signed using DKIM.
IANA已经建立了“DKIM签名查询方法”注册表，用于检索允许对使用DKIM签名的消息进行验证处理的密钥。
+------+--------+-----------------+--------+
| TYPE | OPTION | REFERENCE | STATUS |
+------+--------+-----------------+--------+
| dns | txt | (this document) | active |
+------+--------+-----------------+--------+
+------+--------+-----------------+--------+
| TYPE | OPTION | REFERENCE | STATUS |
+------+--------+-----------------+--------+
| dns | txt | (this document) | active |
+------+--------+-----------------+--------+
Table 2: DKIM-Signature Query Method Registry Updated Values
表2:DKIM签名查询方法注册表更新值
The "c=" tag-spec (specified in Section 3.5) provides for a specifier for canonicalization algorithms for the header and body of the message.
“c=”标记规范（在第3.5节中指定）为消息头和消息体的规范化算法提供了说明符。
IANA has established the "DKIM-Signature Canonicalization Header" Registry for algorithms for converting a message into a canonical form before signing or verifying using DKIM.
IANA建立了“DKIM签名规范化头”注册表，用于在使用DKIM签名或验证之前将消息转换为规范形式的算法。
+---------+-----------------+--------+
| TYPE | REFERENCE | STATUS |
+---------+-----------------+--------+
| simple | (this document) | active |
| relaxed | (this document) | active |
+---------+-----------------+--------+
+---------+-----------------+--------+
| TYPE | REFERENCE | STATUS |
+---------+-----------------+--------+
| simple | (this document) | active |
| relaxed | (this document) | active |
+---------+-----------------+--------+
Table 3: DKIM-Signature Canonicalization Header Registry Updated Values
表3:DKIM签名规范化头注册表更新值
+---------+-----------------+--------+
| TYPE | REFERENCE | STATUS |
+---------+-----------------+--------+
| simple | (this document) | active |
| relaxed | (this document) | active |
+---------+-----------------+--------+
+---------+-----------------+--------+
| TYPE | REFERENCE | STATUS |
+---------+-----------------+--------+
| simple | (this document) | active |
| relaxed | (this document) | active |
+---------+-----------------+--------+
Table 4: DKIM-Signature Canonicalization Body Registry Updated Values
表4:DKIM签名规范化主体注册表更新值
A _domainkey DNS TXT RR provides for a list of tag specifications. IANA has established the DKIM "_domainkey DNS TXT Record Tag Specifications" registry for tag specifications that can be used in DNS TXT resource records.
A _domainkeydns TXT RR提供标记规范列表。IANA已为可用于DNS TXT资源记录的标记规范建立了DKIM“_DomainKeyDNS TXT记录标记规范”注册表。
+------+-----------------+----------+
| TYPE | REFERENCE | STATUS |
+------+-----------------+----------+
| v | (this document) | active |
| g | [RFC4871] | historic |
| h | (this document) | active |
| k | (this document) | active |
| n | (this document) | active |
| p | (this document) | active |
| s | (this document) | active |
| t | (this document) | active |
+------+-----------------+----------+
+------+-----------------+----------+
| TYPE | REFERENCE | STATUS |
+------+-----------------+----------+
| v | (this document) | active |
| g | [RFC4871] | historic |
| h | (this document) | active |
| k | (this document) | active |
| n | (this document) | active |
| p | (this document) | active |
| s | (this document) | active |
| t | (this document) | active |
+------+-----------------+----------+
Table 5: _domainkey DNS TXT Record Tag Specifications Registry Updated Values
表5:_DomainKeyDNS TXT记录标记规范注册表更新值
The "k=" <key-k-tag> (specified in Section 3.6.1) and the "a=" <sig-a-tag-k> (specified in Section 3.5) tags provide for a list of mechanisms that can be used to decode a DKIM signature.
“k=“<key-k-tag>（在第3.6.1节中指定）和“a=“<sig-a-tag-k>（在第3.5节中指定）标记提供了可用于解码DKIM签名的机制列表。
IANA has established the "DKIM Key Type" registry for such mechanisms.
IANA已为此类机制建立了“DKIM密钥类型”注册表。
+------+-----------+--------+
| TYPE | REFERENCE | STATUS |
+------+-----------+--------+
| rsa | [RFC3447] | active |
+------+-----------+--------+
+------+-----------+--------+
| TYPE | REFERENCE | STATUS |
+------+-----------+--------+
| rsa | [RFC3447] | active |
+------+-----------+--------+
Table 6: DKIM Key Type Registry Updated Values
表6:DKIM键类型注册表更新值
The "h=" <key-h-tag> (specified in Section 3.6.1) and the "a=" <sig-a-tag-h> (specified in Section 3.5) tags provide for a list of mechanisms that can be used to produce a digest of message data.
“h=“<key-h-tag>（在第3.6.1节中指定）和“a=“<sig-a-tag-h>（在第3.5节中指定）标记提供了可用于生成消息数据摘要的机制列表。
IANA has established the "DKIM Hash Algorithms" registry for such mechanisms.
IANA已为此类机制建立了“DKIM哈希算法”注册表。
+--------+-------------------+--------+
| TYPE | REFERENCE | STATUS |
+--------+-------------------+--------+
| sha1 | [FIPS-180-3-2008] | active |
| sha256 | [FIPS-180-3-2008] | active |
+--------+-------------------+--------+
+--------+-------------------+--------+
| TYPE | REFERENCE | STATUS |
+--------+-------------------+--------+
| sha1 | [FIPS-180-3-2008] | active |
| sha256 | [FIPS-180-3-2008] | active |
+--------+-------------------+--------+
Table 7: DKIM Hash Algorithms Registry Updated Values
表7:DKIM哈希算法注册表更新值
The "s=" <key-s-tag> tag (specified in Section 3.6.1) provides for a list of service types to which this selector may apply.
“s=“<key-s-tag>标签（在第3.6.1节中指定）提供了该选择器可能适用的服务类型列表。
IANA has established the "DKIM Service Types" registry for service types.
IANA已经为服务类型建立了“DKIM服务类型”注册表。
+-------+-----------------+--------+
| TYPE | REFERENCE | STATUS |
+-------+-----------------+--------+
| email | (this document) | active |
| * | (this document) | active |
+-------+-----------------+--------+
+-------+-----------------+--------+
| TYPE | REFERENCE | STATUS |
+-------+-----------------+--------+
| email | (this document) | active |
| * | (this document) | active |
+-------+-----------------+--------+
Table 8: DKIM Service Types Registry Updated Values
表8:DKIM服务类型注册表更新值
The "t=" <key-t-tag> tag (specified in Section 3.6.1) provides for a list of flags to modify interpretation of the selector.
“t=“<key-t-tag>标签（在第3.6.1节中指定）提供了一个用于修改选择器解释的标志列表。
IANA has established the "DKIM Selector Flags" registry for additional flags.
IANA已经为其他标志建立了“DKIM选择器标志”注册表。
+------+-----------------+--------+
| TYPE | REFERENCE | STATUS |
+------+-----------------+--------+
| y | (this document) | active |
| s | (this document) | active |
+------+-----------------+--------+
+------+-----------------+--------+
| TYPE | REFERENCE | STATUS |
+------+-----------------+--------+
| y | (this document) | active |
| s | (this document) | active |
+------+-----------------+--------+
Table 9: DKIM Selector Flags Registry Updated Values
表9:DKIM选择器标志注册表更新值
IANA has added DKIM-Signature to the "Permanent Message Header Field Names" registry (see [RFC3864]) for the "mail" protocol, using this document as the reference.
IANA已将DKIM签名添加到“邮件”协议的“永久消息头字段名”注册表（请参见[RFC3864]），使用本文档作为参考。
It has been observed that any introduced mechanism that attempts to stem the flow of spam is subject to intensive attack. DKIM needs to be carefully scrutinized to identify potential attack vectors and the vulnerability to each. See also [RFC4686].
据观察，任何引入的试图阻止垃圾邮件流动的机制都会受到密集攻击。需要仔细检查DKIM，以确定潜在的攻击向量以及每个攻击向量的漏洞。另见[RFC4686]。
The relaxed body canonicalization algorithm may enable certain types of extremely crude "ASCII Art" attacks where a message may be conveyed by adjusting the spacing between words. If this is a concern, the "simple" body canonicalization algorithm should be used instead.
放松正文规范化算法可能会启用某些类型的极其粗糙的“ASCII Art”攻击，其中可以通过调整单词之间的间距来传递消息。如果这是一个问题，那么应该使用“简单”体规范化算法。
Use of the "l=" tag might allow display of fraudulent content without appropriate warning to end users. The "l=" tag is intended for increasing signature robustness when sending to mailing lists that both modify their content and do not sign their modified messages. However, using the "l=" tag enables attacks in which an intermediary with malicious intent can modify a message to include content that solely benefits the attacker. It is possible for the appended
使用“l=”标记可能会允许在不向最终用户发出适当警告的情况下显示欺诈内容。“l=”标记用于在发送到修改其内容但未对修改后的邮件签名的邮件列表时增强签名的稳健性。但是，使用“l=”标记会启用攻击，在这种攻击中，具有恶意意图的中介可以修改消息以包含仅对攻击者有利的内容。这是可能的
content to completely replace the original content in the end recipient's eyes and to defeat duplicate message detection algorithms.
内容完全替换最终收件人眼中的原始内容，并击败重复消息检测算法。
An example of such an attack includes altering the MIME structure, exploiting lax HTML parsing in the MUA, and defeating duplicate message detection algorithms.
此类攻击的一个例子包括改变MIME结构、利用MUA中松散的HTML解析以及挫败重复消息检测算法。
To avoid this attack, Signers should be extremely wary of using this tag, and Assessors might wish to ignore signatures that use the tag.
为了避免这种攻击，签名者应该非常小心使用该标记，评估员可能希望忽略使用该标记的签名。
As with any other security application that uses private- or public-key pairs, DKIM requires caution around the handling and protection of keys. A compromised private key or access to one means an intruder or malware can send mail signed by the domain that advertises the matching public key.
与使用私钥或公钥对的任何其他安全应用程序一样，DKIM在处理和保护密钥时需要谨慎。泄露的私钥或对私钥的访问意味着入侵者或恶意软件可以发送由公布匹配公钥的域签名的邮件。
Thus, private keys issued to users, rather than one used by an ADministrative Management Domain (ADMD) itself, create the usual problem of securing data stored on personal resources that can affect the ADMD.
因此，颁发给用户的私钥，而不是由管理管理域（ADMD）本身使用的私钥，通常会造成保护存储在个人资源上的数据的问题，这可能会影响ADMD。
A more secure architecture involves sending messages through an outgoing MTA that can authenticate the submitter using existing techniques (e.g., SMTP Authentication), possibly validate the message itself (e.g., verify that the header is legitimate and that the content passes a spam content check), and sign the message using a key appropriate for the submitter address. Such an MTA can also apply controls on the volume of outgoing mail each user is permitted to originate in order to further limit the ability of malware to generate bulk email.
更安全的体系结构包括通过传出MTA发送邮件，该MTA可以使用现有技术（例如SMTP身份验证）对提交者进行身份验证，可能会验证邮件本身（例如，验证邮件头是否合法以及内容是否通过垃圾邮件内容检查），并使用适合提交者地址的密钥对消息进行签名。这样的MTA还可以对每个用户允许发送的邮件量进行控制，以进一步限制恶意软件生成批量电子邮件的能力。
Since the key servers are distributed (potentially separate for each domain), the number of servers that would need to be attacked to defeat this mechanism on an Internet-wide basis is very large. Nevertheless, key servers for individual domains could be attacked, impeding the verification of messages from that domain. This is not significantly different from the ability of an attacker to deny service to the mail exchangers for a given domain, although it affects outgoing, not incoming, mail.
由于关键服务器是分布式的（每个域可能是独立的），因此需要攻击的服务器数量非常多，以便在Internet范围内击败此机制。然而，单个域的关键服务器可能会受到攻击，从而妨碍对来自该域的消息的验证。这与攻击者拒绝为给定域的邮件交换器提供服务的能力没有明显区别，尽管这会影响传出邮件，而不是传入邮件。
A variation on this attack involves a very large amount of mail being sent using spoofed signatures from a given domain: the key servers for that domain could be overwhelmed with requests in a denial-of-
此攻击的一种变体是使用来自给定域的伪造签名发送大量邮件：该域的关键服务器可能会因拒绝服务而被请求淹没-
service attack (see [RFC4732]). However, given the low overhead of verification compared with handling of the email message itself, such an attack would be difficult to mount.
服务攻击（参见[RFC4732]）。但是，与处理电子邮件本身相比，验证开销较低，因此很难发起此类攻击。
Since the DNS is a required binding for key services, specific attacks against the DNS must be considered.
由于DNS是关键服务的必需绑定，因此必须考虑针对DNS的特定攻击。
While the DNS is currently insecure [RFC3833], these security problems are the motivation behind DNS Security (DNSSEC) [RFC4033], and all users of the DNS will reap the benefit of that work.
虽然DNS目前不安全[RFC3833]，但这些安全问题是DNS安全（DNSSEC）[RFC4033]背后的动机，DNS的所有用户都将从这项工作中获益。
DKIM is only intended as a "sufficient" method of proving authenticity. It is not intended to provide strong cryptographic proof about authorship or contents. Other technologies such as OpenPGP [RFC4880] and S/MIME [RFC5751] address those requirements.
DKIM仅用于证明真实性的“充分”方法。它不打算提供关于作者身份或内容的强有力的加密证明。其他技术，如OpenPGP[RFC4880]和S/MIME[RFC5751]解决了这些需求。
A second security issue related to the DNS revolves around the increased DNS traffic as a consequence of fetching selector-based data as well as fetching signing domain policy. Widespread deployment of DKIM will result in a significant increase in DNS queries to the claimed signing domain. In the case of forgeries on a large scale, DNS servers could see a substantial increase in queries.
与DNS相关的第二个安全问题是，由于获取基于选择器的数据以及获取签名域策略，DNS流量增加。DKIM的广泛部署将导致对声明的签名域的DNS查询显著增加。在大规模伪造的情况下，DNS服务器可以看到查询量的大幅增加。
A specific DNS security issue that should be considered by DKIM Verifiers is the name chaining attack described in Section 2.3 of [RFC3833]. A DKIM Verifier, while verifying a DKIM-Signature header field, could be prompted to retrieve a key record of an attacker's choosing. This threat can be minimized by ensuring that name servers, including recursive name servers, used by the Verifier enforce strict checking of "glue" and other additional information in DNS responses and are therefore not vulnerable to this attack.
DKIM验证者应考虑的一个特定DNS安全问题是[RFC3833]第2.3节中描述的名称链攻击。DKIM验证器在验证DKIM签名头字段时，可能会被提示检索攻击者选择的密钥记录。通过确保验证器使用的名称服务器（包括递归名称服务器）对DNS响应中的“胶水”和其他附加信息进行严格检查，从而不易受到此攻击，可以将此威胁降至最低。
In this attack, a spammer sends a piece of spam through an MTA that signs it, banking on the reputation of the signing domain (e.g., a large popular mailbox provider) rather than its own, and then re-sends that message to a large number of intended recipients. The recipients observe the valid signature from the well-known domain, elevating their trust in the message and increasing the likelihood of delivery and presentation to the user.
在此攻击中，垃圾邮件发送者通过MTA发送垃圾邮件，并对其进行签名，依靠签名域（例如，大型流行邮箱提供商）的信誉而不是自己的信誉，然后将该邮件重新发送给大量预期收件人。接收者观察来自已知域的有效签名，提高了他们对消息的信任，并增加了向用户传递和呈现消息的可能性。
Partial solutions to this problem involve the use of reputation services to convey the fact that the specific email address is being used for spam and that messages from that Signer are likely to be spam. This requires a real-time detection mechanism in order to
这个问题的部分解决方案包括使用信誉服务来传达这样一个事实，即特定的电子邮件地址正被用于垃圾邮件，并且来自该签名者的邮件可能是垃圾邮件。这需要一个实时检测机制，以便
react quickly enough. However, such measures might be prone to abuse, if, for example, an attacker re-sent a large number of messages received from a victim in order to make the victim appear to be a spammer.
反应足够快。但是，如果攻击者重新发送从受害者收到的大量消息，以使受害者看起来是垃圾邮件发送者，则此类措施可能会被滥用。
Large Verifiers might be able to detect unusually large volumes of mails with the same signature in a short time period. Smaller Verifiers can get substantially the same volume of information via existing collaborative systems.
大型验证器可能能够在短时间内检测到具有相同签名的异常大量邮件。较小的验证者可以通过现有的协作系统获得大致相同的信息量。
When a large domain detects undesirable behavior on the part of one of its users, it might wish to revoke the key used to sign that user's messages in order to disavow responsibility for messages that have not yet been verified or that are the subject of a replay attack. However, the ability of the domain to do so can be limited if the same key, for scalability reasons, is used to sign messages for many other users. Mechanisms for explicitly revoking keys on a per-address basis have been proposed but require further study as to their utility and the DNS load they represent.
当大型域检测到其某个用户的不良行为时，它可能希望撤销用于对该用户的消息进行签名的密钥，以否认对尚未验证的消息或受到重播攻击的消息的责任。但是，如果出于可伸缩性原因，使用同一密钥为许多其他用户的消息签名，则域执行此操作的能力可能会受到限制。已经提出了基于每个地址显式撤销密钥的机制，但需要进一步研究它们的实用性和它们所代表的DNS负载。
It is possible for an attacker to publish key records in DNS that are intentionally malformed, with the intent of causing a denial-of-service attack on a non-robust Verifier implementation. The attacker could then cause a Verifier to read the malformed key record by sending a message to one of its users referencing the malformed record in a (not necessarily valid) signature. Verifiers MUST thoroughly verify all key records retrieved from the DNS and be robust against intentionally as well as unintentionally malformed key records.
攻击者可能会在DNS中发布故意格式错误的密钥记录，目的是对非健壮验证器实现造成拒绝服务攻击。然后，攻击者可以通过向其用户之一发送一条消息，引用签名（不一定有效）中的格式错误的记录，从而使验证器读取格式错误的密钥记录。验证器必须彻底验证从DNS检索到的所有密钥记录，并对有意或无意的错误密钥记录具有鲁棒性。
Verifiers MUST be prepared to receive messages with malformed DKIM-Signature header fields and thoroughly verify the header field before depending on any of its contents.
验证器必须准备好接收带有格式错误的DKIM签名头字段的消息，并在根据其任何内容之前彻底验证头字段。
An attacker could determine when a particular signature was verified by using a per-message selector and then monitoring their DNS traffic for the key lookup. This would act as the equivalent of a "web bug" for verification time rather than the time the message was read.
攻击者可以通过使用每消息选择器，然后监控其DNS流量以进行密钥查找，来确定特定签名的验证时间。这相当于验证时间的“web bug”，而不是消息的读取时间。
In some cases, it may be possible to extract private keys using a remote timing attack [BONEH03]. Implementations should consider obfuscating the timing to prevent such attacks.
在某些情况下，可能使用远程定时攻击提取私钥[BONEH03]。实现应该考虑混淆时序以防止此类攻击。
Existing standards allow intermediate MTAs to reorder header fields. If a Signer signs two or more header fields of the same name, this can cause spurious verification errors on otherwise legitimate messages. In particular, Signers that sign any existing DKIM-Signature fields run the risk of having messages incorrectly fail to verify.
现有标准允许中间MTA对标题字段重新排序。如果签名者对两个或多个同名标头字段进行签名，这可能会在其他合法消息上导致虚假验证错误。特别是，对任何现有DKIM签名字段进行签名的签名者都有可能使消息无法正确验证。
An attacker could create a large RSA signing key with a small exponent, thus requiring that the verification key have a large exponent. This will force Verifiers to use considerable computing resources to verify the signature. Verifiers might avoid this attack by refusing to verify signatures that reference selectors with public keys having unreasonable exponents.
攻击者可以创建具有小指数的大型RSA签名密钥，从而要求验证密钥具有大指数。这将迫使验证者使用大量的计算资源来验证签名。验证器可以通过拒绝验证引用具有不合理指数的公钥选择器的签名来避免这种攻击。
In general, an attacker might try to overwhelm a Verifier by flooding it with messages requiring verification. This is similar to other MTA denial-of-service attacks and should be dealt with in a similar fashion.
通常，攻击者可能会试图通过向验证器发送需要验证的消息来压倒验证器。这与其他MTA拒绝服务攻击类似，应以类似方式处理。
The trust relationship described in Section 3.10 could conceivably be used by a parent domain to sign messages with identities in a subdomain not administratively related to the parent. For example, the ".com" registry could create messages with signatures using an "i=" value in the example.com domain. There is no general solution to this problem, since the administrative cut could occur anywhere in the domain name. For example, in the domain "example.podunk.ca.us", there are three administrative cuts (podunk.ca.us, ca.us, and us), any of which could create messages with an identity in the full domain.
可以想象，第3.10节中描述的信任关系可被父域用于使用与父域在管理上不相关的子域中的身份对消息进行签名。例如，.com注册表可以使用example.com域中的“i=”值创建带有签名的消息。这个问题没有通用的解决方案，因为行政削减可能发生在域名的任何地方。例如，在域“example.podunk.ca.us”中，有三个管理裁减（podunk.ca.us、ca.us和us），其中任何一个都可以在整个域中创建具有标识的消息。
INFORMATIVE NOTE: This is considered an acceptable risk for the same reason that it is acceptable for domain delegation. For example, in the case above, any of the domains could potentially simply delegate "example.podunk.ca.us" to a server of their choice
资料性说明：这被认为是一种可接受的风险，其原因与域委派是可接受的相同。例如，在上面的例子中，任何域都可以简单地将“example.podunk.ca.us”委托给他们选择的服务器
and completely replace all DNS-served information. Note that a Verifier MAY ignore signatures that come from an unlikely domain such as ".com", as discussed in Section 6.1.1.
并完全替换所有DNS服务的信息。请注意，如第6.1.1节所述，验证者可能会忽略来自不太可能的域（如“.com”）的签名。
Many email components, including MTAs, MSAs, MUAs, and filtering modules, implement message format checks only loosely. This is done out of years of industry pressure to be liberal in what is accepted into the mail stream for the sake of reducing support costs; improperly formed messages are often silently fixed in transit, delivered unrepaired, or displayed inappropriately (e.g., by showing only the first of multiple From: fields).
许多电子邮件组件，包括MTA、MSA、MUA和过滤模块，只是松散地执行消息格式检查。这是出于多年来行业压力，为了降低支持成本，在邮件流中接受的内容要自由；格式不正确的消息通常在传输过程中被默默地修复、未经修复地传递或不适当地显示（例如，仅显示多个From:字段中的第一个字段）。
Agents that evaluate or apply DKIM output need to be aware that a DKIM Signer can sign messages that are malformed (e.g., violate [RFC5322], such as by having multiple instances of a field that is only permitted once), that become malformed in transit, or that contain header or body content that is not true or valid. Use of DKIM on such messages might constitute an attack against a receiver, especially where additional credence is given to a signed message without adequate evaluation of the Signer.
评估或应用DKIM输出的代理需要知道，DKIM签名者可以对格式错误的消息（例如，违反[RFC5322]，例如，一个字段的多个实例只允许一次）、在传输过程中格式错误的消息、或包含不正确或无效的标头或正文内容的消息进行签名。在此类消息上使用DKIM可能构成对接收者的攻击，特别是在没有对签名者进行充分评估的情况下对签名消息给予额外信任的情况下。
These can represent serious attacks, but they have nothing to do with DKIM; they are attacks on the recipient or on the wrongly identified author.
这些可能代表严重的攻击，但与DKIM无关；它们是对收件人或错误识别的作者的攻击。
Moreover, an agent would be incorrect to infer that all instances of a header field are signed just because one is.
此外，代理推断头字段的所有实例都已签名是不正确的，因为其中一个实例已签名。
A genuine signature from the domain under attack can be obtained by legitimate means, but extra header fields can then be added, either by interception or by replay. In this scenario, DKIM can aid in detecting addition of specific fields in transit. This is done by having the Signer list the field name(s) in the "h=" tag an extra time (e.g., "h=from:from:..." for a message with one From field), so that addition of an instance of that field downstream will render the signature unable to be verified. (See Section 3.5 for details.) This, in essence, is an explicit indication that the Signer repudiates responsibility for such a malformed message.
可以通过合法手段获得受攻击域的真实签名，但可以通过拦截或重播添加额外的头字段。在这种情况下，DKIM可以帮助检测传输过程中添加的特定字段。这是通过让签名者在“h=”标记中额外列出字段名来完成的（例如，“h=from:from:…”用于带有一个from字段的消息），这样添加该字段下游的实例将使签名无法验证。（详情请参见第3.5节。）这本质上是一个明确的迹象，表明签名人否认对这种格式错误的消息负责。
DKIM signs and validates the data it is told to and works correctly. So in this case, DKIM has done its job of delivering a validated domain (the "d=" value) and, given the semantics of a DKIM signature, essentially the Signer has taken some responsibility for a problematic message. It is up to the Identity Assessor or some other
DKIM对其接收到的数据进行签名和验证，并正常工作。因此，在本例中，DKIM已经完成了交付验证域（“d=”值）的工作，并且，鉴于DKIM签名的语义，签名者基本上已经对有问题的消息承担了一些责任。这取决于身份评估员或其他人
subsequent agent to act on such messages as needed, such as degrading the trust of the message (or, indeed, of the Signer), warning the recipient, or even refusing delivery.
后续代理根据需要对此类邮件采取行动，例如降低邮件（或签名者）的信任、警告收件人，甚至拒绝交付。
All components of the mail system that perform loose enforcement of other mail standards will need to revisit that posture when incorporating DKIM, especially when considering matters of potential attacks such as those described.
在合并DKIM时，执行其他邮件标准松散执行的邮件系统的所有组件都需要重新审视这种态势，特别是在考虑潜在攻击（如所述）时。
[FIPS-180-3-2008] U.S. Department of Commerce, "Secure Hash Standard", FIPS PUB 180-3, October 2008.
[FIPS-180-3-2008]美国商务部，“安全哈希标准”，FIPS PUB 180-3，2008年10月。
[ITU-X660-1997] "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", 1997.
[ITU-X660-1997]“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，1997年。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[RFC2049]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第五部分：一致性标准和示例”，RFC 2049，1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[RFC5598]Crocker，D.，“互联网邮件体系结构”，RFC5598，2009年7月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
[BONEH03] "Remote Timing Attacks are Practical", Proceedings 12th USENIX Security Symposium, 2003.
[BONEH03]“远程定时攻击是切实可行的”，第12届USENIX安全研讨会论文集，2003年。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，2004年4月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833]Atkins，D.和R.Austein，“域名系统（DNS）的威胁分析”，RFC 38332004年8月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[RFC4409]Gellens，R.和J.Klensin，“邮件邮件提交”，RFC 4409，2006年4月。
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006.
[RFC4686]Fenton，J.，“驱动域密钥识别邮件（DKIM）的威胁分析”，RFC4686，2006年9月。
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]Handley，M.，Rescorla，E.，和IAB，“互联网拒绝服务注意事项”，RFC 4732，2006年12月。
[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月。
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[RFC4871]Allman，E.，Callas，J.，Delany，M.，Libbey，M.，Fenton，J.，和M.Thomas，“域密钥识别邮件（DKIM）签名”，RFC 48712007年5月。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC4880]Callas，J.，Donnerhacke，L.，Finney，H.，Shaw，D.，和R.Thayer，“OpenPGP消息格式”，RFC 48802007年11月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[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月。
[RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update", RFC 5672, August 2009.
[RFC5672]Crocker，D.，“RFC 4871域密钥识别邮件（DKIM）签名——更新”，RFC 56722009年8月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations", RFC 5863, May 2010.
[RFC5863]Hansen，T.，Siegel，E.，Hallam Baker，P.，和D.Crocker，“域密钥识别邮件（DKIM）开发、部署和操作”，RFC 58632010年5月。
[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and Mailing Lists", RFC 6377, September 2011.
[RFC6377]Kucherawy，M.，“域密钥识别邮件（DKIM）和邮件列表”，RFC 6377，2011年9月。
Appendix A. Example of Use (INFORMATIVE)
附录A.使用示例（资料性）
This section shows the complete flow of an email from submission to final delivery, demonstrating how the various components fit together. The key used in this example is shown in Appendix C.
本节展示了电子邮件从提交到最终交付的完整流程，演示了各种组件如何组合在一起。本示例中使用的键如附录C所示。
From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>
From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>
Hi.
你好
We lost the game. Are you hungry yet?
我们输了比赛。你饿了吗？
Joe.
乔。
Figure 1: The User Composes an Email
图1：用户编写一封电子邮件
This email is signed by the example.com outbound email server and now looks like this:
此电子邮件由example.com出站电子邮件服务器签名，现在看起来如下所示：
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
c=simple/simple; q=dns/txt; i=joe@football.example.com;
h=Received : From : To : Subject : Date : Message-ID;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
4bmp/YzhwvcubU4=;
Received: from client1.football.example.com [192.0.2.1]
by submitserver.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
c=simple/simple; q=dns/txt; i=joe@football.example.com;
h=Received : From : To : Subject : Date : Message-ID;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
4bmp/YzhwvcubU4=;
Received: from client1.football.example.com [192.0.2.1]
by submitserver.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>
Hi.
你好
We lost the game. Are you hungry yet?
我们输了比赛。你饿了吗？
Joe.
乔。
Figure 2: The Email is Signed
图2：电子邮件已签名
The signing email server requires access to the private key associated with the "brisbane" selector to generate this signature.
签名电子邮件服务器需要访问与“brisbane”选择器关联的私钥才能生成此签名。
The signature is normally verified by an inbound SMTP server or possibly the final delivery agent. However, intervening MTAs can also perform this verification if they choose to do so. The verification process uses the domain "example.com" extracted from the "d=" tag and the selector "brisbane" from the "s=" tag in the DKIM-Signature header field to form the DNS DKIM query for: brisbane._domainkey.example.com
签名通常由入站SMTP服务器或最终传递代理进行验证。但是，如果介入MTA选择执行此验证，则它们也可以执行此验证。验证过程使用从“d=”标记中提取的域“example.com”和从DKIM签名头字段中的“s=”标记中提取的选择器“brisbane”来形成DNS DKIM查询：brisbane.\u domainkey.example.com
Signature verification starts with the physically last Received header field, the From header field, and so forth, in the order listed in the "h=" tag. Verification follows with a single CRLF followed by the body (starting with "Hi."). The email is canonically prepared for verifying with the "simple" method. The result of the query and subsequent verification of the signature is stored (in this example) in the X-Authentication-Results header field line. After successful verification, the email looks like this:
签名验证以“h=”标记中列出的顺序从物理上最后收到的标题字段、发件人标题字段等开始。验证之后是单个CRLF，然后是主体（以“Hi”开头）。这封电子邮件是为使用“简单”方法进行验证而准备的。查询结果和签名的后续验证（在本例中）存储在X-Authentication-Results标头字段行中。成功验证后，电子邮件如下所示：
X-Authentication-Results: shopping.example.net
header.from=joe@football.example.com; dkim=pass
Received: from mout23.football.example.com (192.168.1.1)
by shopping.example.net with SMTP;
Fri, 11 Jul 2003 21:01:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
c=simple/simple; q=dns/txt; i=joe@football.example.com;
h=Received : From : To : Subject : Date : Message-ID;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
4bmp/YzhwvcubU4=;
Received: from client1.football.example.com [192.0.2.1]
by submitserver.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>
X-Authentication-Results: shopping.example.net
header.from=joe@football.example.com; dkim=pass
Received: from mout23.football.example.com (192.168.1.1)
by shopping.example.net with SMTP;
Fri, 11 Jul 2003 21:01:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
c=simple/simple; q=dns/txt; i=joe@football.example.com;
h=Received : From : To : Subject : Date : Message-ID;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
4bmp/YzhwvcubU4=;
Received: from client1.football.example.com [192.0.2.1]
by submitserver.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack <joe@football.example.com>
To: Suzie Q <suzie@shopping.example.net>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5F8J@football.example.com>
Hi.
你好
We lost the game. Are you hungry yet?
我们输了比赛。你饿了吗？
Joe.
乔。
Figure 3: Successful Verification
图3：成功验证
Appendix B. Usage Examples (INFORMATIVE)
附录B.使用示例（资料性）
DKIM signing and validating can be used in different ways, for different operational scenarios. This Appendix discusses some common examples.
针对不同的操作场景，可以以不同的方式使用DKIM签名和验证。本附录讨论了一些常见示例。
NOTE: Descriptions in this Appendix are for informational purposes only. They describe various ways that DKIM can be used, given particular constraints and needs. In no case are these examples intended to be taken as providing explanation or guidance concerning DKIM specification details when creating an implementation.
注：本附录中的说明仅供参考。它们描述了在给定特定约束和需求的情况下使用DKIM的各种方式。在任何情况下，这些示例都不打算在创建实现时提供有关DKIM规范细节的解释或指导。
In the most simple scenario, a user's MUA, MSA, and Internet (boundary) MTA are all within the same administrative environment, using the same domain name. Therefore, all of the components involved in submission and initial transfer are related. However, it is common for two or more of the components to be under independent administrative control. This creates challenges for choosing and administering the domain name to use for signing and for its relationship to common email identity header fields.
在最简单的场景中，用户的MUA、MSA和Internet（边界）MTA都位于相同的管理环境中，使用相同的域名。因此，提交和初始传输涉及的所有组件都是相关的。但是，两个或多个组件受独立的管理控制是很常见的。这给选择和管理用于签名的域名及其与常见电子邮件标识头字段的关系带来了挑战。
Some organizations assign specific business functions to discrete groups, inside or outside the organization. The goal, then, is to authorize that group to sign some mail but to constrain what signatures they can generate. DKIM selectors (the "s=" signature tag) facilitate this kind of restricted authorization. Examples of these outsourced business functions are legitimate email marketing providers and corporate benefits providers.
一些组织将特定的业务职能分配给组织内部或外部的离散组。因此，目标是授权该组对某些邮件进行签名，但限制它们可以生成的签名。DKIM选择器（“s=”签名标签）促进了这种受限授权。这些外包业务功能的例子包括合法的电子邮件营销提供商和公司利益提供商。
Here, the delegated group needs to be able to send messages that are signed, using the email domain of the client company. At the same time, the client often is reluctant to register a key for the provider that grants the ability to send messages for arbitrary addresses in the domain.
在这里，委托组需要能够使用客户公司的电子邮件域发送已签名的邮件。同时，客户机通常不愿意为提供程序注册一个密钥，该密钥允许为域中的任意地址发送消息。
There are multiple ways to administer these usage scenarios. In one case, the client organization provides all of the public query service (for example, DNS) administration, and in another, it uses DNS delegation to enable all ongoing administration of the DKIM key record by the delegated group.
有多种方法可以管理这些使用场景。在一种情况下，客户机组织提供所有公共查询服务（例如，DNS）管理，在另一种情况下，它使用DNS委派来启用委派组对DKIM密钥记录的所有正在进行的管理。
If the client organization retains responsibility for all of the DNS administration, the outsourcing company can generate a key pair, supplying the public key to the client company, which then registers it in the query service using a unique selector. The client company retains control over the use of the delegated key because it retains the ability to revoke the key at any time.
如果客户组织保留对所有DNS管理的责任，则外包公司可以生成密钥对，向客户公司提供公钥，然后客户公司使用唯一选择器在查询服务中注册公钥。客户公司保留对委托密钥使用的控制权，因为它保留随时撤销密钥的能力。
If the client wants the delegated group to do the DNS administration, it can have the domain name that is specified with the selector point to the provider's DNS server. The provider then creates and maintains all of the DKIM signature information for that selector. Hence, the client cannot provide constraints on the local-part of addresses that get signed, but it can revoke the provider's signing rights by removing the DNS delegation record.
如果客户端希望委派组执行DNS管理，则可以使用指向提供商DNS服务器的选择器点指定的域名。然后，提供者创建并维护该选择器的所有DKIM签名信息。因此，客户端无法对已签名地址的本地部分提供约束，但它可以通过删除DNS委派记录来撤销提供程序的签名权限。
PDAs demonstrate the need for using multiple keys per domain. Suppose that John Doe wants to be able to send messages using his corporate email address, jdoe@example.com, and his email device does not have the ability to make a Virtual Private Network (VPN) connection to the corporate network, either because the device is limited or because there are restrictions enforced by his Internet access provider. If the device is equipped with a private key registered for jdoe@example.com by the administrator of the example.com domain and appropriate software to sign messages, John could sign the message on the device itself before transmission through the outgoing network of the access service provider.
PDA演示了在每个域中使用多个密钥的需要。假设John Doe希望能够使用其公司电子邮件地址发送消息，jdoe@example.com，并且他的电子邮件设备无法与公司网络建立虚拟专用网络（VPN）连接，这可能是因为该设备受到限制，或者是因为他的互联网访问提供商实施了限制。如果设备配备了注册为的私钥jdoe@example.com由example.com域的管理员和适当的软件对消息进行签名，John可以在通过访问服务提供商的传出网络传输之前在设备本身上对消息进行签名。
Roaming users often find themselves in circumstances where it is convenient or necessary to use an SMTP server other than their home server; examples are conferences and many hotels. In such circumstances, a signature that is added by the submission service will use an identity that is different from the user's home system.
漫游用户经常发现自己处于方便或有必要使用其家庭服务器以外的SMTP服务器的环境中；例如会议和许多酒店。在这种情况下，提交服务添加的签名将使用不同于用户家庭系统的身份。
Ideally, roaming users would connect back to their home server using either a VPN or a SUBMISSION server running with SMTP AUTHentication on port 587. If the signing can be performed on the roaming user's laptop, then they can sign before submission, although the risk of further modification is high. If neither of these are possible, these roaming users will not be able to send mail signed using their own domain key.
理想情况下，漫游用户将使用VPN或在端口587上运行SMTP身份验证的提交服务器连接回其家庭服务器。如果可以在漫游用户的笔记本电脑上执行签名，则他们可以在提交之前签名，尽管进一步修改的风险很高。如果两者都不可能，这些漫游用户将无法发送使用自己的域密钥签名的邮件。
Stand-alone services, such as walk-up kiosks and web-based information services, have no enduring email service relationship with the user, but users occasionally request that mail be sent on their behalf. For example, a website providing news often allows the reader to forward a copy of the article to a friend. This is typically done using the reader's own email address, to indicate who the author is. This is sometimes referred to as the "Evite" problem, named after the website of the same name that allows a user to send invitations to friends.
独立服务，如步行信息亭和基于网络的信息服务，与用户没有持久的电子邮件服务关系，但用户偶尔会要求代表他们发送邮件。例如，提供新闻的网站通常允许读者将文章的副本转发给朋友。这通常使用读者自己的电子邮件地址来表示作者。这有时被称为“Evite”问题，以允许用户向朋友发送邀请的同名网站命名。
A common way this is handled is to continue to put the reader's email address in the From header field of the message but put an address owned by the email posting site into the Sender header field. The posting site can then sign the message, using the domain that is in the Sender field. This provides useful information to the receiving email site, which is able to correlate the signing domain with the initial submission email role.
处理此问题的常见方法是继续将读者的电子邮件地址放在邮件的“发件人”标题字段中，但将电子邮件发布站点拥有的地址放在“发件人”标题字段中。然后，发帖站点可以使用发件人字段中的域对邮件进行签名。这为接收电子邮件的站点提供了有用的信息，该站点能够将签名域与初始提交电子邮件角色关联起来。
Receiving sites often wish to provide their end users with information about mail that is mediated in this fashion. Although the real efficacy of different approaches is a subject for human factors usability research, one technique that is used is for the verifying system to rewrite the From header field to indicate the address that was verified, for example: From: John Doe via news@news-site.example <jdoe@example.com>. (Note that such rewriting will break a signature, unless it is done after the verification pass is complete.)
接收站点通常希望以这种方式向其最终用户提供有关邮件的信息。尽管不同方法的真正有效性是人为因素可用性研究的主题，但验证系统使用的一种技术是重写“发件人”标题字段，以指示已验证的地址，例如：发件人：John Doe vianews@news-site.example<jdoe@example.com>. （请注意，这种重写将破坏签名，除非它是在验证通过后完成的。）
Email is often received at a mailbox that has an address different from the one used during initial submission. In these cases, an intermediary mechanism operates at the address originally used, and it then passes the message on to the final destination. This mediation process presents some challenges for DKIM signatures.
收到电子邮件的邮箱地址通常与初次提交时使用的邮箱地址不同。在这些情况下，中介机制在最初使用的地址上运行，然后将消息传递到最终目的地。此调解过程对DKIM签名提出了一些挑战。
"Affinity addresses" allow a user to have an email address that remains stable, even as the user moves among different email providers. They are typically associated with college alumni associations, professional organizations, and recreational organizations with which they expect to have a long-term relationship. These domains usually provide forwarding of incoming email, and they often have an associated Web application that authenticates the user and allows the forwarding address to be
“关联地址”允许用户拥有保持稳定的电子邮件地址，即使用户在不同的电子邮件提供商之间移动。他们通常与大学校友会、专业组织和娱乐组织有联系，他们希望与这些组织建立长期关系。这些域通常提供传入电子邮件的转发，并且它们通常有一个关联的Web应用程序来验证用户，并允许发送地址
changed. However, these services usually depend on users sending outgoing messages through their own service provider's MTAs. Hence, mail that is signed with the domain of the affinity address is not signed by an entity that is administered by the organization owning that domain.
改变。但是，这些服务通常依赖于用户通过自己的服务提供商MTA发送传出消息。因此，使用关联地址的域签名的邮件不会由拥有该域的组织管理的实体签名。
With DKIM, affinity domains could use the Web application to allow users to register per-user keys to be used to sign messages on behalf of their affinity address. The user would take away the secret half of the key pair for signing, and the affinity domain would publish the public half in DNS for access by Verifiers.
通过DKIM，关联域可以使用Web应用程序允许用户注册每个用户的密钥，用于代表其关联地址对消息进行签名。用户将拿走密钥对的机密部分进行签名，亲和域将在DNS中发布公共部分以供验证者访问。
This is another application that takes advantage of user-level keying, and domains used for affinity addresses would typically have a very large number of user-level keys. Alternatively, the affinity domain could handle outgoing mail, operating a mail submission agent that authenticates users before accepting and signing messages for them. This is, of course, dependent on the user's service provider not blocking the relevant TCP ports used for mail submission.
这是另一个利用用户级键控的应用程序，用于关联地址的域通常具有大量用户级键。或者，关联域可以处理传出邮件，操作邮件提交代理，在接受和签署用户的邮件之前对用户进行身份验证。当然，这取决于用户的服务提供商是否阻止用于邮件提交的相关TCP端口。
In some cases, a recipient is allowed to configure an email address to cause automatic redirection of email messages from the original address to another, such as through the use of a Unix .forward file. In this case, messages are typically redirected by the mail handling service of the recipient's domain, without modification, except for the addition of a Received header field to the message and a change in the envelope recipient address. In this case, the recipient at the final address' mailbox is likely to be able to verify the original signature since the signed content has not changed, and DKIM is able to validate the message signature.
在某些情况下，允许收件人配置电子邮件地址，使电子邮件自动从原始地址重定向到另一个地址，例如通过使用Unix.forward文件。在这种情况下，邮件通常由收件人域的邮件处理服务重定向，而不进行修改，除了向邮件添加接收头字段和更改信封收件人地址之外。在这种情况下，最终地址邮箱的收件人可能能够验证原始签名，因为签名内容没有更改，DKIM能够验证邮件签名。
There is a wide range of behaviors in services that take delivery of a message and then resubmit it. A primary example is with mailing lists (collectively called "forwarders" below), ranging from those that make no modification to the message itself, other than to add a Received header field and change the envelope information, to those that add header fields, change the Subject header field, add content to the body (typically at the end), or reformat the body in some manner. The simple ones produce messages that are quite similar to the automated alias services. More elaborate systems essentially create a new message.
在服务中有许多行为，它们接收消息并重新提交。一个主要的例子是邮件列表（下文统称为“转发器”），从那些不修改邮件本身的列表（除了添加收到的标题字段和更改信封信息），到那些添加标题字段、更改主题标题字段、向正文添加内容的列表（通常在末尾），或者以某种方式重新格式化身体。简单的别名服务生成的消息与自动别名服务非常相似。更复杂的系统本质上创造了一个新的信息。
A Forwarder that does not modify the body or signed header fields of a message is likely to maintain the validity of the existing signature. It also could choose to add its own signature to the message.
不修改邮件的正文或签名头字段的转发器可能会保持现有签名的有效性。它还可以选择在消息中添加自己的签名。
Forwarders that modify a message in a way that could make an existing signature invalid are particularly good candidates for adding their own signatures (e.g., mailing-list-name@example.net). Since (re-)signing is taking responsibility for the content of the message, these signing forwarders are likely to be selective and forward or re-sign a message only if it is received with a valid signature or if they have some other basis for knowing that the message is not spoofed.
以可能使现有签名无效的方式修改邮件的转发器尤其适合添加自己的签名（例如，邮件列表）-name@example.net). 由于（重新）签名是对消息内容负责，因此这些签名转发器可能是选择性的，只有在接收到带有有效签名的消息时，或者如果他们有一些其他基础知道消息不是伪造的，才会转发或重新签名消息。
A common practice among systems that are primarily redistributors of mail is to add a Sender header field to the message to identify the address being used to sign the message. This practice will remove any preexisting Sender header field as required by [RFC5322]. The forwarder applies a new DKIM-Signature header field with the signature, public key, and related information of the forwarder.
在主要是邮件重新分发者的系统中，一种常见做法是向邮件添加发件人标头字段，以标识用于对邮件签名的地址。按照[RFC5322]的要求，此做法将删除任何先前存在的发送方标头字段。转发器应用新的DKIM签名头字段，其中包含转发器的签名、公钥和相关信息。
See [RFC6377] for additional related topics and discussion.
有关其他相关主题和讨论，请参见[RFC6377]。
Appendix C. Creating a Public Key (INFORMATIVE)
附录C.创建公钥（信息性）
The default signature is an RSA-signed SHA-256 digest of the complete email. For ease of explanation, the openssl command is used to describe the mechanism by which keys and signatures are managed. One way to generate a 1024-bit, unencrypted private key suitable for DKIM is to use openssl like this:
默认签名是完整电子邮件的RSA签名SHA-256摘要。为了便于解释，openssl命令用于描述密钥和签名的管理机制。生成适合DKIM的1024位未加密私钥的一种方法是使用openssl，如下所示：
$ openssl genrsa -out rsa.private 1024
$ openssl genrsa-out rsa.private 1024
For increased security, the "-passin" parameter can also be added to encrypt the private key. Use of this parameter will require entering a password for several of the following steps. Servers may prefer to use hardware cryptographic support.
为了提高安全性，还可以添加“-passin”参数来加密私钥。使用此参数需要为以下几个步骤输入密码。服务器可能更喜欢使用硬件加密支持。
The "genrsa" step results in the file rsa.private containing the key information similar to this:
“genrsa”步骤将生成文件rsa.private，其中包含类似以下内容的密钥信息：
-----BEGIN RSA PRIVATE KEY-----
MIICXwIBAAKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFC
jxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gb
to/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB
AoGBALmn+XwWk7akvkUlqb+dOxyLB9i5VBVfje89Teolwc9YJT36BGN/l4e0l6QX
/1//6DWUTB3KI6wFcm7TWJcxbS0tcKZX7FsJvUz1SbQnkS54DJck1EZO/BLa5ckJ
gAYIaqlA9C0ZwM6i58lLlPadX/rtHb7pWzeNcZHjKrjM461ZAkEA+itss2nRlmyO
n1/5yDyCluST4dQfO8kAB3toSEVc7DeFeDhnC1mZdjASZNvdHS4gbLIA1hUGEF9m
3hKsGUMMPwJBAPW5v/U+AWTADFCS22t72NUurgzeAbzb1HWMqO4y4+9Hpjk5wvL/
eVYizyuce3/fGke7aRYw/ADKygMJdW8H/OcCQQDz5OQb4j2QDpPZc0Nc4QlbvMsj
7p7otWRO5xRa6SzXqqV3+F0VpqvDmshEBkoCydaYwc2o6WQ5EBmExeV8124XAkEA
qZzGsIxVP+sEVRWZmW6KNFSdVUpk3qzK0Tz/WjQMe5z0UunY9Ax9/4PVhp/j61bf
eAYXunajbBSOLlx4D+TunwJBANkPI5S9iylsbLs6NkaMHV6k5ioHBBmgCak95JGX
GMot/L2x0IYyMLAz6oLWh2hm7zwtb0CgOrPo1ke44hFYnfc=
-----END RSA PRIVATE KEY-----
-----BEGIN RSA PRIVATE KEY-----
MIICXwIBAAKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFC
jxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gb
to/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB
AoGBALmn+XwWk7akvkUlqb+dOxyLB9i5VBVfje89Teolwc9YJT36BGN/l4e0l6QX
/1//6DWUTB3KI6wFcm7TWJcxbS0tcKZX7FsJvUz1SbQnkS54DJck1EZO/BLa5ckJ
gAYIaqlA9C0ZwM6i58lLlPadX/rtHb7pWzeNcZHjKrjM461ZAkEA+itss2nRlmyO
n1/5yDyCluST4dQfO8kAB3toSEVc7DeFeDhnC1mZdjASZNvdHS4gbLIA1hUGEF9m
3hKsGUMMPwJBAPW5v/U+AWTADFCS22t72NUurgzeAbzb1HWMqO4y4+9Hpjk5wvL/
eVYizyuce3/fGke7aRYw/ADKygMJdW8H/OcCQQDz5OQb4j2QDpPZc0Nc4QlbvMsj
7p7otWRO5xRa6SzXqqV3+F0VpqvDmshEBkoCydaYwc2o6WQ5EBmExeV8124XAkEA
qZzGsIxVP+sEVRWZmW6KNFSdVUpk3qzK0Tz/WjQMe5z0UunY9Ax9/4PVhp/j61bf
eAYXunajbBSOLlx4D+TunwJBANkPI5S9iylsbLs6NkaMHV6k5ioHBBmgCak95JGX
GMot/L2x0IYyMLAz6oLWh2hm7zwtb0CgOrPo1ke44hFYnfc=
-----END RSA PRIVATE KEY-----
To extract the public-key component from the private key, use openssl like this:
要从私钥中提取公钥组件，请使用openssl，如下所示：
$ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM
$ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM
This results in the file rsa.public containing the key information similar to this:
这将导致文件rsa.public包含类似以下内容的密钥信息：
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM
oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R
tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI
MmPSPDdQPNUYckcQ2QIDAQAB
-----END PUBLIC KEY-----
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM
oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R
tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI
MmPSPDdQPNUYckcQ2QIDAQAB
-----END PUBLIC KEY-----
This public-key data (without the BEGIN and END tags) is placed in the DNS:
此公钥数据（不带开始和结束标记）放置在DNS中：
$ORIGIN _domainkey.example.org.
brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ"
"KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt"
"IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v"
"/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi"
"tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB")
$ORIGIN _domainkey.example.org.
brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ"
"KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt"
"IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v"
"/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi"
"tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB")
DKIM key records were designed to be backward compatible in many cases with key records used by DomainKeys [RFC4870] (sometimes referred to as "selector records" in the DomainKeys context). One area of incompatibility warrants particular attention. The "g=" tag value may be used in DomainKeys and [RFC4871] key records to provide
DKIM密钥记录设计为在许多情况下与DomainKeys[RFC4870]使用的密钥记录向后兼容（在DomainKeys上下文中有时称为“选择器记录”）。有一个不兼容的领域值得特别注意。“g=”标记值可用于域密钥和[RFC4871]密钥记录，以提供
finer granularity of the validity of the key record to a specific local-part. A null "g=" value in DomainKeys is valid for all addresses in the domain. This differs from the usage in the original DKIM specification ([RFC4871]), where a null "g=" value is not valid for any address. In particular, see the example public-key record in Section 3.2.3 of [RFC4870].
密钥记录对特定本地部分的有效性粒度更细。DomainKeys中的null“g=”值对域中的所有地址都有效。这不同于原始DKIM规范（[RFC4871]）中的用法，其中null“g=”值对任何地址都无效。具体请参见[RFC4870]第3.2.3节中的公钥记录示例。
Although the "g=" tag has been deprecated in this version of the DKIM specification (and thus MUST now be ignored), Signers are advised not to include the "g=" tag in key records because some [RFC4871]- compliant Verifiers will be in use for a considerable period to come.
尽管“g=”标签在本版本的DKIM规范中已被弃用（因此现在必须忽略），但建议签名者不要将“g=”标签包含在密钥记录中，因为一些符合[RFC4871]的验证器将在相当长的一段时间内使用。
Appendix D. MUA Considerations (INFORMATIVE)
附录D.MUA注意事项（资料性）
When a DKIM signature is verified, the processing system sometimes makes the result available to the recipient user's MUA. How to present this information to users in a way that helps them is a matter of continuing human factors usability research. The tendency is to have the MUA highlight the SDID, in an attempt to show the user the identity that is claiming responsibility for the message. An MUA might do this with visual cues such as graphics, might include the address in an alternate view, or might even rewrite the original From address using the verified information. Some MUAs might indicate which header fields were protected by the validated DKIM signature. This could be done with a positive indication on the signed header fields, with a negative indication on the unsigned header fields, by visually hiding the unsigned header fields, or some combination of these. If an MUA uses visual indications for signed header fields, the MUA probably needs to be careful not to display unsigned header fields in a way that might be construed by the end user as having been signed. If the message has an "l=" tag whose value does not extend to the end of the message, the MUA might also hide or mark the portion of the message body that was not signed.
当验证DKIM签名时，处理系统有时会将结果提供给接收方用户的MUA。如何以一种有助于用户的方式向用户呈现这些信息是一个持续的人为因素可用性研究的问题。趋势是让MUA突出显示SDID，试图向用户显示声称对消息负责的身份。MUA可能会通过图形等视觉提示来实现这一点，可能会在另一个视图中包含地址，甚至可能会使用已验证的信息重写原始发件人地址。某些MUA可能会指示哪些标头字段受已验证的DKIM签名保护。这可以通过在有符号头字段上显示正指示，在无符号头字段上显示负指示，通过直观地隐藏无符号头字段或这些字段的某种组合来实现。如果MUA对签名头字段使用可视指示，则MUA可能需要小心，不要以最终用户可能认为已签名的方式显示未签名头字段。如果消息有一个“l=”标记，其值不延伸到消息的末尾，MUA还可能隐藏或标记消息正文中未签名的部分。
The aforementioned information is not intended to be exhaustive. The MUA can choose to highlight, accentuate, hide, or otherwise display any other information that may, in the opinion of the MUA author, be deemed important to the end user.
上述信息并非详尽无遗。MUA可以选择突出显示、强调、隐藏或以其他方式显示MUA作者认为对最终用户重要的任何其他信息。
o Abstract and introduction refined based on accumulated experience.
o 摘要和引言是在积累经验的基础上提炼出来的。
o Various references updated.
o 更新了各种参考资料。
o Several errata resolved (see http://www.rfc-editor.org/):
o 解决了几个勘误表（参见http://www.rfc-editor.org/):
* 1376 applied
* 1376份申请
* 1377 applied
* 1377适用
* 1378 applied
* 1378适用
* 1379 applied
* 1379适用
* 1380 applied
* 应用1380
* 1381 applied
* 1381份申请
* 1382 applied
* 应用1382
* 1383 discarded (no longer applies)
* 1383已放弃（不再适用）
* 1384 applied
* 应用1384
* 1386 applied
* 应用1386
* 1461 applied
* 1461份申请
* 1487 applied
* 1487适用
* 1532 applied
* 1532适用
* 1596 applied
* 1596应用
o Introductory section enumerating relevant architectural documents added.
o 介绍部分列举了添加的相关体系结构文档。
o Introductory section briefly discussing the matter of data integrity added.
o 介绍部分简要讨论了添加的数据完整性问题。
o Allowed tolerance of some clock drift.
o 允许一些时钟漂移的公差。
o Dropped "g=" tag from key records. The implementation report indicates that it is not in use.
o 从关键记录中删除了“g=”标记。实施报告表明它未被使用。
o Removed errant note about wildcards in the DNS.
o 删除了有关DNS中通配符的错误说明。
o Removed SMTP-specific advice in most places.
o 在大多数地方删除了SMTP特定的通知。
o Reduced (non-normative) recommended signature content list, and reworked the text in that section.
o 减少（非规范性）建议的签名内容列表，并修改该部分的文本。
o Clarified signature generation algorithm by rewriting its pseudo-code.
o 通过重写其伪代码来阐明签名生成算法。
o Numerous terminology subsections added, imported from [RFC5672]. Also, began using these terms throughout the document (e.g., SDID, AUID).
o 添加了许多术语小节，从[RFC5672]导入。此外，开始在整个文档中使用这些术语（例如，SDID、AUID）。
o Sections added that specify input and output requirements. Input requirements address a security concern raised by the working group (see also new sections in Security Considerations). Output requirements are imported from [RFC5672].
o 添加了指定输入和输出要求的部分。输入要求解决了工作组提出的一个安全问题（另请参见安全注意事项中的新章节）。输出要求从[RFC5672]导入。
o Appendix subsection added discussing compatibility with DomainKeys ([RFC4870]) records.
o 添加了附录小节，讨论了与域密钥（[RFC4870]）记录的兼容性。
o Referred to [RFC5451] as an example method of communicating the results of DKIM verification.
o 参考[RFC5451]作为传递DKIM验证结果的示例方法。
o Removed advice about possible uses of the "l=" signature tag.
o 删除了关于“l=”签名标签可能使用的建议。
o IANA registry updated.
o IANA注册表已更新。
o Added two new Security Considerations sections talking about malformed message attacks.
o 添加了两个新的安全注意事项部分，讨论格式错误的消息攻击。
o Various copy editing.
o 各种拷贝编辑。
The previous IETF version of DKIM [RFC4871] was edited by Eric Allman, Jon Callas, Mark Delany, Miles Libbey, Jim Fenton, and Michael Thomas.
DKIM的上一个IETF版本[RFC4871]由Eric Allman、Jon Callas、Mark Delany、Miles Libbey、Jim Fenton和Michael Thomas编辑。
That specification was the result of an extended collaborative effort, including participation by Russ Allbery, Edwin Aoki, Claus Assmann, Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve Bellovin, Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis Dayman, Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark Fanto, Stephen Farrell, Duncan Findlay, Elliot Gillum, Olafur Gudmundsson, Phillip Hallam-Baker, Tony Hansen, Sam Hartman, Arvel Hathcock, Amir Herzberg, Paul Hoffman, Russ Housley, Craig Hughes, Cullen Jennings, Don Johnsen, Harry Katz, Murray S. Kucherawy, Barry Leiba, John Levine, Charles Lindsey, Simon Longsdale, David Margrave, Justin Mason, David Mayne, Thierry Moreau, Steve Murphy, Russell Nelson, Dave Oran, Doug Otis, Shamim Pirzada, Juan Altmayer Pizzorno, Sanjay Pol, Blake Ramsdell, Christian Renaud, Scott Renfro, Neil
该规范是长期合作的结果，包括Russ Allbery、Edwin Aoki、Claus Assmann、Steve Atkins、Rob Austein、Fred Baker、Mark Baugher、Steve Bellovin、Nathaniel Borenstein、Dave Crocker、Michael Cudahy、Dennis Dayman、Jutta Degener、Frank Ellerman、Patrik Faeltstroem、Mark Fanto、，斯蒂芬·法雷尔、邓肯·芬德利、埃利奥特·吉勒姆、奥拉弗尔·古德蒙德森、菲利普·哈拉姆·贝克、托尼·汉森、山姆·哈特曼、阿维尔·哈特科克、阿米尔·赫茨伯格、保罗·霍夫曼、罗斯·霍斯利、克雷格·休斯、卡伦·詹宁斯、唐·约翰森、哈利·卡茨、默里·库切拉维、巴里·莱巴、约翰·莱文、查尔斯·林赛、西蒙·朗斯代尔、大卫·马格雷夫、贾斯汀·梅森、，大卫·梅恩、蒂埃里·莫罗、史蒂夫·墨菲、拉塞尔·纳尔逊、戴夫·奥兰、道格·奥蒂斯、沙米姆·皮尔扎达、胡安·阿尔特迈耶·皮佐诺、桑杰·波尔、布莱克·拉姆斯代尔、克里斯蒂安·雷诺、斯科特·伦弗罗、尼尔
Rerup, Eric Rescorla, Dave Rossetti, Hector Santos, Jim Schaad, the Spamhaus.org team, Malte S. Stretz, Robert Sanders, Rand Wacker, Sam Weiler, and Dan Wing.
Rerrup、Eric Rescorla、Dave Rossetti、Hector Santos、Jim Schaad、Spamhaus.org团队、Malte S.Stratez、Robert Sanders、Rand Wacker、Sam Weiler和Dan Wing。
The earlier DomainKeys was a primary source from which DKIM was derived. Further information about DomainKeys is at [RFC4870].
早期的域密钥是DKIM的主要来源。有关域密钥的更多信息，请访问[RFC4870]。
This revision received contributions from Steve Atkins, Mark Delany, J.D. Falk, Jim Fenton, Michael Hammer, Barry Leiba, John Levine, Charles Lindsey, Jeff Macdonald, Franck Martin, Brett McDowell, Doug Otis, Bill Oxley, Hector Santos, Rolf Sonneveld, Michael Thomas, and Alessandro Vesely.
本次修订收到了史蒂夫·阿特金斯、马克·德拉尼、J.D.福尔克、吉姆·芬顿、迈克尔·哈默、巴里·莱巴、约翰·莱文、查尔斯·林赛、杰夫·麦克唐纳、弗兰克·马丁、布雷特·麦克道尔、道格·奥蒂斯、比尔·奥克斯利、赫克托·桑托斯、罗尔夫·桑内维尔德、迈克尔·托马斯和亚历山德罗·维斯利的贡献。
Authors' Addresses
作者地址
Dave Crocker (editor) Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 USA
Dave Crocker（编辑）美国加利福尼亚州桑尼维尔市布兰登堡互联675 Spruce Dr.Sunnyvale 94086
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
URI: http://bbiw.net
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
URI: http://bbiw.net
Tony Hansen (editor) AT&T Laboratories 200 Laurel Ave. South Middletown, NJ 07748 USA
托尼·汉森（编辑）美国电话电报公司实验室美国新泽西州南米德尔顿劳雷尔大道200号，邮编07748
EMail: tony+dkimsig@maillennium.att.com
EMail: tony+dkimsig@maillennium.att.com
Murray S. Kucherawy (editor) Cloudmark 128 King St., 2nd Floor San Francisco, CA 94107 USA
Murray S. Kucherawy（编辑）CuldMax 128国王圣，第二楼旧金山，CA 94107美国
EMail: msk@cloudmark.com
EMail: msk@cloudmark.com