Network Working Group E. Allman
Request for Comments: 4871 Sendmail, Inc.
Obsoletes: 4870 J. Callas
Category: Standards Track PGP Corporation
M. Delany
M. Libbey
Yahoo! Inc
J. Fenton
M. Thomas
Cisco Systems, Inc.
May 2007
Network Working Group E. Allman
Request for Comments: 4871 Sendmail, Inc.
Obsoletes: 4870 J. Callas
Category: Standards Track PGP Corporation
M. Delany
M. Libbey
Yahoo! Inc
J. Fenton
M. Thomas
Cisco Systems, Inc.
May 2007
DomainKeys Identified Mail (DKIM) Signatures
域密钥识别邮件（DKIM）签名
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Protection of email identity may assist in the global control of "spam" and "phishing".
DomainKeys Identified Mail（DKIM）使用公钥加密和密钥服务器技术为电子邮件定义域级身份验证框架，以允许邮件传输代理（MTA）或邮件用户代理（MUA）验证邮件的来源和内容。此框架的最终目标是允许签名域声明对消息的责任，从而保护消息签名者身份及其所传递消息的完整性，同时保留当前已知的Internet电子邮件功能。保护电子邮件身份可能有助于全球控制“垃圾邮件”和“网络钓鱼”。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 5
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 5
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5
2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 6
2.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 7
2.6. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 7
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 10
3.3. Signing and Verification Algorithms . . . . . . . . . . . 11
3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 13
3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 17
3.6. Key Management and Representation . . . . . . . . . . . . 25
3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 29
3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 31
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 32
4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 32
4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 33
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1. Determine Whether the Email Should Be Signed and by
Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2. Select a Private Key and Corresponding Selector
Information . . . . . . . . . . . . . . . . . . . . . . . 35
5.3. Normalize the Message to Prevent Transport Conversions . . 35
5.4. Determine the Header Fields to Sign . . . . . . . . . . . 36
5.5. Recommended Signature Content . . . . . . . . . . . . . . 38
5.6. Compute the Message Hash and Signature . . . . . . . . . . 39
5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 40
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 40
6.1. Extract Signatures from the Message . . . . . . . . . . . 41
6.2. Communicate Verification Results . . . . . . . . . . . . . 46
6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 47
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 48
7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 49
7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 49
7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 50
7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 50
7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 51
7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 51
7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 52
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 5
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 5
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5
2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 6
2.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 7
2.6. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 7
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 10
3.3. Signing and Verification Algorithms . . . . . . . . . . . 11
3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 13
3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 17
3.6. Key Management and Representation . . . . . . . . . . . . 25
3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 29
3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 31
4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 32
4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 32
4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 33
5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1. Determine Whether the Email Should Be Signed and by
Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2. Select a Private Key and Corresponding Selector
Information . . . . . . . . . . . . . . . . . . . . . . . 35
5.3. Normalize the Message to Prevent Transport Conversions . . 35
5.4. Determine the Header Fields to Sign . . . . . . . . . . . 36
5.5. Recommended Signature Content . . . . . . . . . . . . . . 38
5.6. Compute the Message Hash and Signature . . . . . . . . . . 39
5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 40
6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 40
6.1. Extract Signatures from the Message . . . . . . . . . . . 41
6.2. Communicate Verification Results . . . . . . . . . . . . . 46
6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 47
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 48
7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 49
7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 49
7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 50
7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 50
7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 51
7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 51
7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 52
7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 52
8. Security Considerations . . . . . . . . . . . . . . . . . . . 52
8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 52
8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 53
8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 54
8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 54
8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 55
8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 55
8.7. Intentionally Malformed Key Records . . . . . . . . . . . 56
8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 56
8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 56
8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 56
8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 56
8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 56
8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 57
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
9.1. Normative References . . . . . . . . . . . . . . . . . . . 57
9.2. Informative References . . . . . . . . . . . . . . . . . . 58
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 60
A.1. The user composes an email . . . . . . . . . . . . . . . . 60
A.2. The email is signed . . . . . . . . . . . . . . . . . . . 61
A.3. The email signature is verified . . . . . . . . . . . . . 61
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 62
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 63
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 65
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 67
Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 68
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 69
7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 52
8. Security Considerations . . . . . . . . . . . . . . . . . . . 52
8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 52
8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 53
8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 54
8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 54
8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 55
8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 55
8.7. Intentionally Malformed Key Records . . . . . . . . . . . 56
8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 56
8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 56
8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 56
8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 56
8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 56
8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 57
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
9.1. Normative References . . . . . . . . . . . . . . . . . . . 57
9.2. Informative References . . . . . . . . . . . . . . . . . . 58
Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 60
A.1. The user composes an email . . . . . . . . . . . . . . . . 60
A.2. The email is signed . . . . . . . . . . . . . . . . . . . 61
A.3. The email signature is verified . . . . . . . . . . . . . 61
Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 62
B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 63
B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 65
Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 67
Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 68
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 69
DomainKeys Identified Mail (DKIM) defines a mechanism by which email messages can be cryptographically signed, permitting a signing domain to claim responsibility for the introduction of a message into the mail stream. Message recipients can verify the signature by querying the signer's domain directly to retrieve the appropriate public key, and thereby confirm that the message was attested to by a party in possession of the private key for the signing domain.
DomainKeys Identified Mail（DKIM）定义了一种机制，通过该机制可以对电子邮件进行加密签名，从而允许签名域声明将消息引入邮件流的责任。消息接收者可以通过直接查询签名者的域以检索适当的公钥来验证签名，从而确认消息已由拥有签名域私钥的一方证明。
The approach taken by DKIM differs from previous approaches to message signing (e.g., Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC1847], OpenPGP [RFC2440]) in that:
DKIM采用的方法与以前的消息签名方法（例如，安全/多用途Internet邮件扩展（S/MIME）[RFC1847]，OpenPGP[RFC2440]）不同，因为：
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;
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;
o 可以增量部署；
o allows delegation of signing to third parties.
o 允许将签名委托给第三方。
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 currently over 70 million domains and a much larger number of individual addresses. 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旨在支持电子邮件识别问题的极端可扩展性需求。目前有超过7000万个域名和更多的个人地址。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被设计为在其他密钥获取服务可用时可扩展到这些服务。
This section defines terms used in the rest of the document. Syntax descriptions use the form described in Augmented BNF for Syntax Specifications [RFC4234].
本节定义了文档其余部分中使用的术语。语法描述使用增广BNF中描述的形式作为语法规范[RFC4234]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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 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.
邮件系统中代表域对邮件进行签名的元素称为签名者。这些代理可以是MUA（邮件用户代理）、MSA（邮件提交代理）、MTA（邮件传输代理）或其他代理，如邮件列表爆炸器。通常，任何签名者都会以某种方式参与将消息注入消息系统。关键问题是，在消息离开签名者的管理域之前，必须对其进行签名。
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。在大多数情况下，预计验证者将接近消息的最终用户（读者）或某些消费代理，如邮件列表爆炸器。
There are three forms of whitespace:
空格有三种形式：
o WSP represents simple whitespace, i.e., a space or a tab character (formal definition in [RFC4234]).
o WSP表示简单的空白，即空格或制表符（在[RFC4234]中有正式定义）。
o LWSP is linear whitespace, defined as WSP plus CRLF (formal definition in [RFC4234]).
o LWSP是线性空白，定义为WSP加CRLF（在[RFC4234]中有正式定义）。
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 [RFC2822] except for the exclusion of obs-FWS.
FWS的定义与[RFC2822]中的定义相同，但不包括obs FWS。
The following ABNF tokens are used elsewhere in this document:
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ]
base64string = 1*(ALPHA / DIGIT / "+" / "/" / [FWS])
[ "=" [FWS] [ "=" [FWS] ] ]
The following ABNF tokens are used elsewhere in this document:
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ]
base64string = 1*(ALPHA / DIGIT / "+" / "/" / [FWS])
[ "=" [FWS] [ "=" [FWS] ] ]
The following tokens are imported from other RFCs as noted. Those RFCs should be considered definitive.
如前所述，以下令牌是从其他RFC导入的。这些RFC应被视为确定的。
The following tokens are imported from [RFC2821]:
以下令牌从[RFC2821]导入：
o "Local-part" (implementation warning: this permits quoted strings)
o “本地部分”（实现警告：这允许引用字符串）
o "sub-domain"
o “子域”
The following tokens are imported from [RFC2822]:
以下令牌从[RFC2822]导入：
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 RFC 2045 does not obey the rules of RFC 4234 and must be interpreted accordingly, particularly as regards case folding.
资料性说明：请注意，RFC 2045中的ABNF不符合RFC 4234的规则，必须进行相应的解释，尤其是在箱子折叠方面。
Other tokens not defined herein are imported from [RFC4234]. These are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, etc.
此处未定义的其他令牌从[RFC4234]导入。这些是直观的原语，如SP、HTAB、WSP、ALPHA、DIGIT、CRLF等。
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.
DKIM Quoted Printable编码语法与Quoted Printable[RFC2045]第6.7节中所述类似：任何字符都可以编码为“=”后跟字母表“0123456789ABCDEF”中的两个十六进制数字（不允许使用小写字符），表示该字符的十六进制编码整数值。必须对所有控制字符（值<%x20的控制字符）、8位字符（值>%x7F）以及字符DEL（%x7F）、空格（%x20）和分号（“；”、%x3B）进行编码。请注意，所有空格，包括空格、CR和LF字符，都必须进行编码。编码后，可以在任意位置添加FWS，以避免过长的线；此类空白不是值的一部分，必须在解码之前删除。
ABNF:
荷兰银行：
dkim-quoted-printable =
*(FWS / hex-octet / dkim-safe-char)
; hex-octet is from RFC 2045
dkim-safe-char = %x21-3A / %x3C / %x3E-7E
; '!' - ':', '<', '>' - '~'
; Characters not listed as "mail-safe" in
; RFC 2049 are also not recommended.
dkim-quoted-printable =
*(FWS / hex-octet / dkim-safe-char)
; hex-octet is from RFC 2045
dkim-safe-char = %x21-3A / %x3C / %x3E-7E
; '!' - ':', '<', '>' - '~'
; Characters not listed as "mail-safe" in
; RFC 2049 are also not recommended.
INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted-Printable as defined in RFC 2045 in several important ways:
资料性说明：DKIM引用可打印文件与RFC 2045中定义的引用可打印文件在几个重要方面有所不同：
1. Whitespace in the input text, including CR and LF, must be encoded. RFC 2045 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，必须进行编码。RFC 2045不需要这种编码，也不允许对作为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, RFC 2045 requires that line breaks in the input be represented as physical line breaks; that is not the case here.
2. 编码文本中的空白将被忽略。这是为了允许根据需要包装使用DKIM Quoted Printable编码的标签。具体而言，RFC 2045要求输入中的换行符表示为物理换行符；这里的情况并非如此。
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 the 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 may 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 make the decision as to whether to associate this selector directly with the user name, 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 versus 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.6). 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.6节）。标记的名称将决定每个值的编码。未编码的分号（；）字符不能出现在标记值中，因为这分隔了标记规范。
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 UTF8-encoded text in tag=value lists.
资料性实施说明：尽管下文定义的“纯文本”（即“标记值”）仅包括7位字符，但建议希望预测未来标准的实施不要排除在标记=值列表中使用UTF8编码文本。
Formally, the syntax rules are as follows:
形式上，语法规则如下所示：
tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ]
tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-name = ALPHA 0*ALNUMPUNC
tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ]
; WSP and FWS prohibited at beginning and end
tval = 1*VALCHAR
VALCHAR = %x21-3A / %x3C-7E
; EXCLAMATION to TILDE except SEMICOLON
ALNUMPUNC = ALPHA / DIGIT / "_"
tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ]
tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-name = ALPHA 0*ALNUMPUNC
tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ]
; WSP and FWS prohibited 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. For example, "g=" does not mean "g=*", even though "g=*" is the default for that tag.
具有空值的标记与省略的标记不同。省略的标记被视为具有默认值；带有空值的标记将空字符串显式指定为值。例如，“g=”并不表示“g=*”，即使“g=*”是该标记的默认值。
DKIM supports multiple digital signature algorithms. Two algorithms are defined by this specification at this time: rsa-sha1 and rsa-sha256. The rsa-sha256 algorithm is the default if no algorithm is specified. Verifiers MUST implement both rsa-sha1 and rsa-sha256. Signers MUST implement and SHOULD sign using rsa-sha256.
DKIM支持多种数字签名算法。本规范目前定义了两种算法：rsa-sha1和rsa-sha256。如果未指定任何算法，则默认使用rsa-sha256算法。验证器必须同时实现rsa-sha1和rsa-sha256。签名者必须实现并应使用rsa-sha256签名。
INFORMATIVE NOTE: Although sha256 is strongly encouraged, some senders of low-security messages (such as routine newsletters) may prefer to use sha1 because of reduced CPU requirements to compute a sha1 hash. In general, sha256 should always be used whenever possible.
资料性说明：尽管强烈鼓励使用sha256，但一些低安全性消息（如例行新闻稿）的发件人可能更喜欢使用sha1，因为计算sha1哈希的CPU需求减少。通常，只要可能，就应该始终使用sha256。
The rsa-sha1 Signing Algorithm computes a message hash as described in Section 3.7 below using SHA-1 [FIPS.180-2.2002] as the hash-alg. That hash is then signed by the signer using the RSA algorithm (defined in 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-2.2002]作为哈希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 below using SHA-256 [FIPS.180-2.2002] as the hash-alg. That hash is then signed by the signer using the RSA algorithm (defined in 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.
rsa-sha256签名算法使用SHA-256[FIPS.180-2.2002]作为哈希alg，按照下面第3.7节所述计算消息哈希。然后，签名者使用RSA算法（在PKCS#1 1.5版[RFC3447]中定义）作为密码alg和签名者的私钥对该散列进行签名。在签名之前，哈希不能被截断或转换为本机二进制形式以外的任何形式。
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 may 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.
将来可能会定义其他算法。验证者必须忽略任何使用他们没有实现的算法的签名。
Empirical evidence demonstrates that some mail servers and relay systems modify email in transit, potentially invalidating a signature. There are two competing perspectives on such modifications. For most signers, mild modification of email is immaterial to the authentication status of the email. For such signers, a canonicalization algorithm that survives modest in-transit modification is preferred.
经验证据表明，一些邮件服务器和中继系统在传输过程中修改电子邮件，可能使签名无效。对这种修改有两种相互矛盾的观点。对于大多数签名者来说，对电子邮件的轻微修改对电子邮件的身份验证状态无关紧要。对于这样的签名者，最好使用一种能够在传输过程中进行适度修改的规范化算法。
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 [RFC2822], but are unwilling to accept any modification to the body of messages.
一些签名者可能愿意接受对邮件标准（如[RFC2822]）范围内标题字段的修改，但不愿意接受对邮件正文的任何修改。
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 [RFC2822]; 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 按照[RFC2822]中的说明展开所有标题字段续行；特别是，必须在不使用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
“简单”正文规范化算法忽略消息正文末尾的所有空行。空行是指移除行终止符后长度为零的行。如果消息正文上没有正文或没有尾随CRLF，则添加一个CRLF。没有关系
other changes to the message body. In more formal terms, the "simple" body canonicalization algorithm converts "0*CRLF" at the end of the body to a single "CRLF".
对消息正文的其他更改。在更正式的术语中，“简单”正文规范化算法将正文末尾的“0*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 "relaxed" body canonicalization algorithm:
“松弛”体规范化算法：
o Ignores all whitespace at the end of lines. Implementations MUST NOT remove the CRLF at the end of the line.
o 忽略行末尾的所有空白。实施不得移除生产线末端的CRLF。
o Reduces all sequences of WSP within a line to a single SP character.
o 将一行中的所有WSP序列减少为单个SP字符。
o Ignores all empty lines at the end of the message body. "Empty line" is defined in Section 3.4.3.
o 忽略消息正文末尾的所有空行。第3.4.3节定义了“空行”。
INFORMATIVE NOTE: It should be noted that 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”攻击，其中可以通过调整单词之间的间距来传递消息。如果这是一个问题，那么应该使用“简单”体规范化算法。
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 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 may as a matter of policy accept messages having valid signatures with extraneous data.
信息性理由：之所以提供此功能，是因为邮件列表通常会在邮件中添加预告片（例如，如何从列表中删除的说明）。在这些消息也被签名之前，正文长度计数对于验证器来说是一个有用的工具，因为它可以作为一个策略接受具有有效签名的消息和无关数据。
INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables an attack in which an attacker modifies a message to include content that solely benefits the attacker. It is possible for the appended content to completely replace the original content in the end recipient's eyes and to defeat duplicate message detection algorithms. To avoid this attack, signers should be wary of using
信息性实施说明：使用正文长度限制会导致攻击者修改消息以包含仅对攻击者有利的内容的攻击。附加的内容可以完全替换最终接收者眼中的原始内容，并击败重复消息检测算法。为了避免这种攻击，签名者应该小心使用
this tag, and verifiers might wish to ignore the tag or remove text that appears after the specified content length, perhaps based on other criteria.
验证程序可能希望忽略该标记或删除指定内容长度之后出现的文本，可能基于其他条件。
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. Signers of MIME messages that include a body length count SHOULD be sure that the length extends to the closing MIME boundary string.
正文长度计数允许消息的签名者允许将数据附加到已签名消息正文的末尾。体长计数必须按照规范化算法计算；例如，规范化算法忽略的任何空白都不包括在正文长度计数中。包含正文长度计数的MIME消息的签名者应确保长度扩展到结束MIME边界字符串。
INFORMATIVE IMPLEMENTATION NOTE: A signer wishing to ensure that the only acceptable modifications are to add to the MIME postlude would use a body length count encompassing the entire final MIME boundary string, including the final "--CRLF". A signer wishing to allow additional MIME parts but not modification of existing parts would use a body length count extending through the final MIME boundary string, omitting the final "--CRLF". Note that this only works for some MIME types, e.g., multipart/mixed but not multipart/signed.
信息性实现说明：希望确保唯一可接受的修改是添加到MIME postlude的签名者将使用包含整个最终MIME边界字符串的正文长度计数，包括最终的“-CRLF”。希望允许附加MIME部分但不允许修改现有部分的签名者将使用延伸至最终MIME边界字符串的正文长度计数，忽略最终“-CRLF”。请注意，这仅适用于某些MIME类型，例如多部分/混合，但不适用于多部分/签名。
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.
希望确保不会发生任何类型的修改的签名者应为头和正文指定“简单”规范化算法，并忽略正文长度计数。
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 [RFC2822], and hence SHOULD NOT be reordered and SHOULD be prepended to the message.
DKIM签名头字段应视为[RFC2822]第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.6.
下面列出了每种字段类型的编码。如MIME第一部分[RFC2045]第6.7节所述，对描述为qp部分的标记进行编码，并将分号字符额外转换为“=3B”；直观地说，这是一行引用的可打印编码文本。第2.6节定义了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 (MUST be included). This tag defines the version of this specification that applies to the signature record. It MUST have the value "1". Note that verifiers must do a string comparison on this value; for example, "1" is not the same as "1.0".
v=版本（必须包括在内）。此标记定义了适用于签名记录的本规范版本。它必须具有值“1”。请注意，验证器必须对该值进行字符串比较；例如，“1”与“1.0”不同。
ABNF:
荷兰银行：
sig-v-tag = %x76 [FWS] "=" [FWS] "1"
sig-v-tag = %x76 [FWS] "=" [FWS] "1"
INFORMATIVE NOTE: DKIM-Signature version numbers are expected to 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 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 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 domain of the signing entity (plain-text; REQUIRED). This is the domain that will be queried for the public key. This domain MUST be the same as or a parent domain of the "i=" tag (the signing identity, as described below), or it MUST meet the requirements for parent domain signing described in Section 3.8. When presented with a signature that does not meet these requirement, verifiers MUST consider the signature invalid.
d=签名实体的域（纯文本；必填）。这是将查询公钥的域。此域必须与“i=”标记（签名标识，如下所述）相同或是其父域，或者必须满足第3.8节中所述的父域签名要求。当提交的签名不符合这些要求时，验证者必须考虑签名无效。
Internationalized domain names MUST be encoded as described in [RFC3490].
国际化域名必须按照[RFC3490]中所述进行编码。
ABNF:
荷兰银行：
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain)
; from RFC 2821 Domain, but excluding address-literal
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain)
; from RFC 2821 Domain, but 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 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.
h=签名的标题字段（纯文本，但请参见说明；必填）。标题字段名称的冒号分隔列表，用于标识提交给签名算法的标题字段。该字段必须按照提交给签名算法的顺序包含标题字段的完整列表。该字段可能包含签名时不存在的标题字段的名称；不存在的头字段不参与签名计算（即，它们被视为空输入，包括头字段名称、分隔冒号、头字段值和任何CRLF终止符）。该字段不得包括正在创建或验证的DKIM签名头字段，但可以包括其他字段。可折叠空格（FWS）可包含在冒号分隔符的任一侧。必须以不区分大小写的方式将标题字段名与实际标题字段名进行比较。此列表不能为空。有关选择要签名的标题字段的讨论，请参见第5.4节。
ABNF:
荷兰银行：
sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name
0*( *FWS ":" *FWS hdr-name )
hdr-name = field-name
sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name
0*( *FWS ":" *FWS hdr-name )
hdr-name = field-name
INFORMATIVE EXPLANATION: By "signing" header fields that do not actually exist, a signer can prevent insertion of those header fields before verification. However, since a signer cannot possibly know what header fields might be created in the future, and that some MUAs might present header fields that are embedded inside a message (e.g., as a message/rfc822 content type), the security of this solution is not total.
信息性说明：通过“签名”实际上不存在的标题字段，签名者可以在验证之前阻止插入这些标题字段。但是，由于签名者不可能知道将来可能会创建哪些标头字段，并且某些MUA可能会显示嵌入消息中的标头字段（例如，作为消息/rfc822内容类型），因此此解决方案的安全性并不全面。
INFORMATIVE EXPLANATION: The exclusion of the header field name and colon as well as the header field value for non-existent header fields prevents an attacker from inserting an actual header field with a null value.
信息性说明：不存在的标题字段排除标题字段名称和冒号以及标题字段值，可防止攻击者插入具有空值的实际标题字段。
i= Identity of the user or agent (e.g., a mailing list manager) on behalf of which this message is signed (dkim-quoted-printable; OPTIONAL, default is an empty Local-part followed by an "@" followed by the domain from the "d=" tag). 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.
i=代表其签署此邮件的用户或代理（例如，邮件列表管理员）的身份（dkim quoted printable；可选，默认为空本地部分，后跟“@”，后跟“d=”标记中的域）。语法是一个标准的电子邮件地址，可以省略本地部分。地址的域部分必须与“d=”标记的值相同或是其子域。
Internationalized domain names MUST be converted using the steps listed in Section 4 of [RFC3490] using the "ToASCII" function.
必须使用[RFC3490]第4节中列出的步骤，使用“ToASCII”功能转换国际化域名。
ABNF:
荷兰银行：
sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name
sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name
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 may 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 their domain. It can do so by including the domain part but not the Local-part of the identity.
资料性说明：“i=”标记的本地部分是可选的，因为在某些情况下，签名者可能无法建立经验证的个人身份。在这种情况下，签名者可能希望声明，尽管它愿意为域签名，但它不能或不愿意在其域内提交个人用户名。它可以通过包含域部分而不是标识的本地部分来实现。
INFORMATIVE DISCUSSION: This document 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 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=”标记的值与任何消息头字段中的标识匹配。这被认为是一个验证者策略问题。“i=”标记的值与其他头字段中的其他标识之间的约束寻求将基本身份验证应用到与角色（如内容作者）关联的信任语义中。信任是一个广泛而复杂的话题，信任机制受到高度创造性的攻击。“i=”值与其他标识之间的任何绑定（但最基本的绑定除外）的真实效果尚未得到很好的证实，其易受攻击者破坏的漏洞也未得到很好的证实。因此，应严格限制对这些选项使用的依赖。特别是，一个典型的最终用户接收者在多大程度上依赖于成功使用“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.
l=正文长度计数（纯文本无符号十进制整数；可选，默认为整个正文）。此标记通知验证者加密散列中包含的规范化后电子邮件正文中的八位字节数，从正文前CRLF后面的0开始。此值不得大于规范化消息正文中的实际八位字节数。
INFORMATIVE IMPLEMENTATION WARNING: 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 messages. However, using the "l=" tag enables attacks in which an intermediary with malicious intent modifies a message to include content that solely benefits the attacker. It is possible for the appended content to completely replace the original content in the end recipient's eyes and to defeat duplicate message detection algorithms. Examples are described in Security Considerations (Section 8). To avoid this attack, signers should be extremely wary of using this tag, and verifiers might wish to ignore the tag or remove text that appears after the specified content length.
信息性实施警告：使用“l=”标记可能允许在不向最终用户发出适当警告的情况下显示欺诈内容。“l=”标记用于在发送到修改其内容但不签署其邮件的邮件列表时增强签名的稳健性。但是，使用“l=”标记可启用具有恶意意图的中介修改消息以包含仅对攻击者有利的内容的攻击。附加的内容可以完全替换最终接收者眼中的原始内容，并击败重复消息检测算法。安全注意事项（第8节）中描述了示例。为了避免这种攻击，签名者应该非常小心使用此标记，验证者可能希望忽略该标记或删除指定内容长度之后出现的文本。
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.
q=用于检索公钥的以冒号分隔的查询方法列表（纯文本；可选，默认为“dns/txt”）。每个查询方法的形式为“type[/options]”，其中选项的语法和语义取决于类型和指定的选项。如果列出了多个查询机制，则查询机制的选择不得改变签名的解释。实现必须按照呈现的顺序使用已识别的查询机制。
Currently, the only valid value is "dns/txt", which defines the DNS TXT record 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记录查找算法。为“dns”查询类型定义的唯一选项是“txt”，必须包括该选项。验证者和签名者必须支持“dns/txt”。
ABNF:
荷兰银行：
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 = %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
s= The selector subdividing the namespace for the "d=" (domain) tag (plain-text; REQUIRED).
s=为“d=”（域）标记（纯文本；必需）细分名称空间的选择器。
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=”标记不用于防重放。
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
metacharacters, 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= 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
metacharacters, 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.
The header fields referenced by the "h=" tag refer to the fields in the RFC 2822 header of the message, not to any copied fields in the "z=" tag. Copied header field values are for diagnostic use.
“h=”标记引用的标题字段指的是消息RFC 2822标题中的字段，而不是“z=”标记中复制的任何字段。复制的标题字段值用于诊断。
Header fields with characters requiring conversion (perhaps from legacy MTAs that are not [RFC2822] compliant) SHOULD be converted as described in MIME Part Three [RFC2047].
需要转换字符（可能来自[RFC2822]不兼容的传统MTA）的标题字段应按照MIME第三部分[RFC2047]中的说明进行转换。
ABNF:
sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy
*( [FWS] "|" sig-z-tag-copy )
sig-z-tag-copy = hdr-name ":" qp-hdr-value
qp-hdr-value = dkim-quoted-printable ; with "|" encoded
ABNF:
sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy
*( [FWS] "|" sig-z-tag-copy )
sig-z-tag-copy = hdr-name ":" qp-hdr-value
qp-hdr-value = dkim-quoted-printable ; with "|" encoded
INFORMATIVE EXAMPLE of a signature header field spread across multiple continuation lines:
横跨多个续行的签名头字段的信息示例：
DKIM-Signature: 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+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR
DKIM-Signature: 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+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR
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 records to distribute the keys. Other bindings may be defined in the future.
本文档定义了单个绑定，使用DNS TXT记录分发密钥。将来可能会定义其他绑定。
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] "DKIM1"
key-v-tag = %x76 [FWS] "=" [FWS] "DKIM1"
g= Granularity of the key (plain-text; OPTIONAL, default is "*"). This value MUST match the Local-part of the "i=" tag of the DKIM-Signature header field (or its default value of the empty string if "i=" is not specified), with a single, optional "*" character matching a sequence of zero or more arbitrary characters ("wildcarding"). An email with a signing address that does not match the value of this tag constitutes a failed verification. The intent of this tag is to constrain which signing address can legitimately use this selector, for example, when delegating a key to a third party that should only be used for special purposes. Wildcarding allows matching for addresses such as "user+*" or "*-offer". An empty "g=" value never matches any addresses.
g=键的粒度（纯文本；可选，默认值为“*”）。该值必须与DKIM签名头字段的“i=”标记的本地部分（或其空字符串的默认值，如果“i=”未指定）相匹配，并使用单个可选“*”字符匹配零个或多个任意字符的序列（“通配符”）。签名地址与此标记的值不匹配的电子邮件构成验证失败。此标记的目的是限制哪个签名地址可以合法地使用此选择器，例如，当将密钥委托给仅应用于特殊目的的第三方时。通配符允许匹配地址，如“用户+*”或“*-offer”。空的“g=”值与任何地址都不匹配。
ABNF:
荷兰银行：
key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart
key-g-tag-lpart = [dot-atom-text] ["*" [dot-atom-text] ]
key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart
key-g-tag-lpart = [dot-atom-text] ["*" [dot-atom-text] ]
h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to allowing all algorithms). A colon-separated list of hash algorithms that might be used. Signers and Verifiers MUST support the "sha256" hash algorithm. Verifiers MUST also support the "sha1" hash algorithm.
h=可接受的哈希算法（纯文本；可选，默认为允许所有算法）。可能使用的哈希算法的冒号分隔列表。签名者和验证者必须支持“sha256”哈希算法。验证器还必须支持“sha1”哈希算法。
ABNF:
荷兰银行：
key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg
0*( [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
0*( [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 [RFC3447] (see 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.)
k=密钥类型（纯文本；可选，默认为“rsa”）。签名者和验证者必须支持“rsa”密钥类型。“rsa”密钥类型表示“p=”标签中正在使用ASN.1 DER编码的[ITU.X660.1997]RSAPublicKey[RFC3447]（参见第3.1节和A.1.1节）。（注意：“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 ignore any DKIM-Signature header fields with a selector referencing a revoked key.
信息性理由：如果私钥已被泄露或以其他方式禁用（例如，外包合同已终止），签名者可能希望明确声明其了解选择器，但使用该选择器的所有消息都应无法验证。验证器应忽略任何带有选择器的DKIM签名头字段，该选择器引用已撤销的密钥。
ABNF:
荷兰银行：
key-p-tag = %x70 [FWS] "=" [ [FWS] base64string ]
key-p-tag = %x70 [FWS] "=" [ [FWS] base64string ]
INFORMATIVE NOTE: A base64string is permitted to include white space (FWS) at arbitrary places; however, any CRLFs must be followed by at least one WSP character. Implementors and administrators are cautioned to ensure that selector TXT records conform to this specification.
资料性说明：Base64字符串允许在任意位置包含空白（FWS）；但是，任何CRLF后面必须至少有一个WSP字符。提醒实施者和管理员确保选择器TXT记录符合本规范。
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. 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
0*( [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
0*( [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). 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
0*( [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
0*( [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
Unrecognized flags MUST be ignored.
必须忽略无法识别的标志。
A binding using DNS TXT records as a key service is hereby defined. All implementations MUST support this binding.
在此定义使用DNS TXT记录作为密钥服务的绑定。所有实现都必须支持此绑定。
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”。
INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records (e.g., *.bar._domainkey.example.com) do not make sense in this context and should not be used. Note also that wildcards within domains (e.g., s._domainkey.*.example.com) are not supported by the DNS.
信息性操作说明：通配符DNS记录（例如，*.bar._domainkey.example.com）在此上下文中没有意义，不应使用。还请注意，DNS不支持域内的通配符（例如，s._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 Resource Record (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) 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.
签名和验证消息签名都从计算消息上的两个加密哈希开始。签名人将选择签名人行动（第5节）中所述的签名参数；验证器将使用正在验证的DKIM签名头字段中指定的参数。在下面的讨论中，将使用DKIM签名头字段中已存在（验证时）或将创建（签名时）的标记名称。请注意，规范化（第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 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 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 [RFC2821]).
在计算将使用base64或带引号的可打印编码传输的消息的散列时，签名者必须在编码后计算散列。同样，验证器必须在解码base64或带引号的可打印文本之前将这些值合并到哈希中。但是，必须在传输级编码之前计算哈希，例如SMTP“点填充”（修改以“.”开头的行，以避免与[RFC2821]中指定的SMTP消息结尾标记混淆）。
With the exception of the canonicalization procedure described in Section 3.4, the DKIM signing process treats the body of messages as
除第3.4节中描述的规范化过程外，DKIM签名过程将消息体视为
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.
只是一串八位字节。DKIM消息可以是纯文本或MIME格式；默剧内容没有特殊处理。已签名的内容中必须包含MIME格式的邮件附件。
More formally, the algorithm for the signature is as follows:
body-hash = hash-alg(canon_body)
header-hash = hash-alg(canon_header || DKIM-SIG)
signature = sig-alg(header-hash, key)
More formally, the algorithm for the signature is as follows:
body-hash = hash-alg(canon_body)
header-hash = hash-alg(canon_header || DKIM-SIG)
signature = sig-alg(header-hash, key)
where "sig-alg" is the signature algorithm specified by the "a=" tag, "hash-alg" is the hash algorithm specified by the "a=" tag, "canon_header" and "canon_body" are the canonicalized message header and body (respectively) as defined in Section 3.4 (excluding the DKIM-Signature header field), and "DKIM-SIG" is the canonicalized DKIM-Signature header field sans the signature value itself, but with "body-hash" included as the "bh=" tag.
其中，“sig alg”是由“a=”标记指定的签名算法，“hash alg”是由“a=”标记指定的哈希算法，“canon_头”和“canon_体”分别是第3.4节（不包括DKIM签名头字段）和“DKIM-sig”中定义的规范化消息头和正文是规范化的DKIM签名头字段，不包含签名值本身，但包含“body hash”作为“bh=”标记。
INFORMATIVE IMPLEMENTERS' 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 "hash-alg" and the "sig-alg".
信息性实现者注意：许多数字签名API使用单个“sign（）”原语提供RSA私钥的哈希和应用。当使用这样的API时，算法中的最后两个步骤可能会组合成一个调用，该调用将同时执行“hash-alg”和“sig-alg”。
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; e.g., a key record for the domain example.com can be used to verify messages where the signing identity ("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 record to exactly the domain of the signing identity. If the referenced key record contains the "s" flag as part of the "t=" tag, the domain of the signing identity ("i=" flag) MUST be the same as that of the d= domain. If this flag is absent, the domain of the signing identity MUST be the same as, or a subdomain of, the d= domain. Key records that are not intended for use with subdomains SHOULD specify the "s" flag in the "t=" tag.
在某些情况下，域希望代表其任何子域应用签名，而无需在每个子域中维护单独的选择器（密钥记录）。默认情况下，与密钥记录对应的私钥可用于对其所在域的任何子域的消息进行签名；e、 例如，域example.com的密钥记录可用于验证签名标识（“i=”签名标签）为sub.example.com甚至sub1.sub2.example.com的消息。为了在非预期的情况下限制此类密钥的能力，可以在密钥记录的“t=”标记中设置“s”标志，以将记录的有效性严格限制在签名标识的域内。如果引用的密钥记录包含作为“t=”标记一部分的“s”标志，则签名标识的域（“i=”标志）必须与d=域的域相同。如果没有此标志，则签名标识的域必须与d=域相同或是其子域。不用于子域的密钥记录应在“t=”标记中指定“s”标志。
There are many reasons why a message might have multiple signatures. For example, a given signer might sign multiple times, perhaps with different hashing or signing algorithms during a transition phase.
消息可能具有多个签名的原因有很多。例如，给定的签名者可能多次签名，可能在转换阶段使用不同的哈希或签名算法。
INFORMATIVE 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 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 headers and no "l=" tag (to satisfy strict verifiers) and a second time with a limited set of headers and an "l=" tag (in anticipation of possible message modifications in route to other verifiers). Verifiers could then choose which signature they preferred.
类似地，签名者可能会对包含所有头和no“l=”标记的消息进行签名（以满足严格的验证者的要求），第二次则会对有限的头和“l=”标记进行签名（预计可能会对发送到其他验证者的消息进行修改）。然后验证者可以选择他们喜欢的签名。
INFORMATIVE EXAMPLE: A verifier might receive a message with two signatures, one covering more of the message than the other. If the signature covering more of the message verified, then the verifier could make one set of policy decisions; if that signature failed but the signature covering less of the message verified, the verifier might make a different set of policy decisions.
信息性示例：验证器可能接收到具有两个签名的消息，一个签名覆盖的消息比另一个签名多。如果签名覆盖了更多的消息，那么验证者可以做出一组策略决定；如果该签名失败，但签名覆盖的消息较少，那么验证者可能会做出一组不同的策略决策。
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.
当然，消息也可能有多个签名，因为它通过了多个签名者。一种常见的情况是，经过签名的邮件通过一个邮件列表，该邮件列表也对所有邮件进行签名。假设这两个签名都经过验证，如果已知其中一个签名来自可信来源，则收件人可能会选择接受邮件。
INFORMATIVE EXAMPLE: 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.
多个签名者的另一个相关示例可能是转发服务，例如通常与学术校友网站关联的服务。
INFORMATIVE 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签名头字段进行签名，以对跟踪头字段进行签名。
INFORMATIVE NOTE: 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 ignore failed signatures as though they were not present in the message. 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.
验证程序应该忽略失败的签名，就像它们不在消息中一样。验证者应继续检查签名，直到签名成功验证到验证者满意为止。为了限制潜在的拒绝服务攻击，验证者可以限制他们将尝试验证的签名总数。
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: Signing modules may be incorporated into 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 address might be derived from the header according to local policy; SUBMISSION servers might only sign messages from users that are properly authenticated and authorized.
资料性说明：签名模块可根据需要并入邮件系统的任何部分，包括MUA、提交服务器或MTA。无论在何处实现，签名者都应该小心签名（从而声明对可能有问题的消息负责）。特别地，在受信任的飞地内，签名地址可以根据本地策略从报头派生；提交服务器可能仅对来自经过正确身份验证和授权的用户的邮件进行签名。
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 may 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 MIME Part One [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内容传输编码，如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 [RFC2822] form MUST be done before signing. In particular, bare CR or LF characters (used by some systems as a local line 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.
如果消息以任何本地编码提交给签名者，并且在传输之前将对其进行修改，则必须在签名之前对规范[RFC2822]格式进行修改。特别是，在邮件签名之前，必须将裸CR或LF字符（某些系统将其用作本地行分隔符约定）转换为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.
更一般地说，签名者必须按照预期由验证者接收的方式对消息进行签名，而不是以某种本地或内部形式进行签名。
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, [RFC2821] explicitly permits 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.
必须对From标头字段进行签名（即，包含在生成的DKIM签名标头字段的“h=”标记中）。签名者不应对可能在传输过程中被合法修改或删除的现有标题字段进行签名。特别是，[RFC2821]明确允许在传输过程中修改或删除返回路径头字段。签名人可自行决定在签名时包含任何其他标题字段。
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 non-existing 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=”标签中列出评论三次或三次以上是不必要的（但合法的）。
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 to indicate that additional header fields of that name SHOULD NOT be 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>将按该顺序签名。
Signers should 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 [RFC2822] 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-*块是[RFC2822]禁止重新排序的唯一字段。特别是，由于某些中间MTA可能会对DKIM签名头字段重新排序，因此对现有DKIM签名头字段进行签名很容易出错。
INFORMATIVE ADMONITION: Despite the fact that [RFC2822] permits header fields to be reordered (with the exception of Received header fields), reordering of signed header fields with multiple instances by intermediate MTAs will cause DKIM signatures to be broken; such anti-social behavior should be avoided.
信息性警告：尽管[RFC2822]允许对标题字段进行重新排序（接收到的标题字段除外），但中间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.
信息性实施者注意：尽管本规范不要求，但所有最终用户可见的标题字段都应签名，以避免可能的“间接垃圾邮件”。例如，如果主题标题字段未签名，则垃圾邮件发送者可以重新发送先前签名的邮件，将合法主题替换为单行垃圾邮件。
In order to maximize compatibility with a variety of verifiers, it is recommended that signers follow the practices outlined in this section when signing a message. However, these are generic recommendations applying to the general case; specific senders may wish to modify these guidelines as required by their unique situations. Verifiers MUST be capable of verifying signatures even if one or more of the recommended header fields is not signed (with the exception of From, which must always be signed) or if one or more of the disrecommended header fields is signed. Note that verifiers do have the option of ignoring signatures that do not cover a sufficient portion of the header or body, just as they may ignore signatures from an identity they do not trust.
为了最大限度地提高与各种验证器的兼容性，建议签名者在签名消息时遵循本节中概述的实践。然而，这些是适用于一般情况的一般性建议；特定发件人可能希望根据其特殊情况修改这些指南。即使一个或多个建议的标题字段未签名（From除外，From必须始终签名），或者一个或多个未建议的标题字段已签名，验证器也必须能够验证签名。请注意，验证器确实可以选择忽略未覆盖足够部分的头或正文的签名，就像他们可以忽略来自他们不信任的身份的签名一样。
The following header fields SHOULD be included in the signature, if they are present in the message being signed:
如果签名邮件中存在以下标题字段，则签名中应包含这些字段：
o From (REQUIRED in all signatures)
o 发件人（所有签名均需填写）
o Sender, Reply-To
o 发信人，回复
o Subject
o 主题
o Date, Message-ID
o 日期，消息ID
o To, Cc
o 至，抄送
o MIME-Version
o MIME版本
o Content-Type, Content-Transfer-Encoding, Content-ID, Content-Description
o 内容类型、内容传输编码、内容ID、内容描述
o Resent-Date, Resent-From, Resent-Sender, Resent-To, Resent-Cc, Resent-Message-ID
o 重新发送日期、重新发送发件人、重新发送发件人、重新发送收件人、重新发送抄送、重新发送邮件ID
o In-Reply-To, References
o 作为对参考文献的答复
o List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive
o 列表Id、列表帮助、列表取消订阅、列表订阅、列表发布、列表所有者、列表存档
The following header fields SHOULD NOT be included in the signature:
签名中不应包含以下标题字段：
o Return-Path
o 返回路径
o Received
o 收到
o Comments, Keywords
o 评论、关键词
o Bcc, Resent-Bcc
o 密件抄送，重发密件抄送
o DKIM-Signature
o DKIM签名
Optional header fields (those not mentioned above) normally SHOULD NOT be included in the signature, because of the potential for additional header fields of the same name to 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 may 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.
签名者应该根据他们处理的消息类型和他们对风险的厌恶程度来选择规范化算法。例如，主要发送采购收据的电子商务网站通常倾向于“简单”规范化，而这些收据预计不会被邮件列表或其他可能修改邮件的软件处理。主要发送人与人之间电子邮件的站点可能更倾向于通过使用“宽松”规范化，在传输过程中更容易修改。
Signers SHOULD NOT use "l=" unless they intend to accommodate intermediate mail processors that append text to a message. For example, many mailing list processors append "unsubscribe" information to message bodies. If signers use "l=", they SHOULD include the entire message body existing at the time of signing in computing the count. In particular, signers SHOULD NOT specify a body length of 0 since this may be interpreted as a meaningless signature by some verifiers.
签名者不应使用“l=”，除非他们打算容纳将文本附加到邮件中的中间邮件处理者。例如，许多邮件列表处理者将“取消订阅”信息附加到邮件正文中。如果签名者使用“l=”，他们应该包括在计算计数时签名时存在的整个消息体。特别是，签名者不应指定正文长度为0，因为某些验证者可能会将其解释为无意义的签名。
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并在重新传输消息之前修改消息或标题字段（例如，插入取消订阅信息）的实体（如邮件列表管理器）应检查输入上的任何现有签名，并且必须在对消息重新签名之前进行此类修改。
The signer MAY elect to limit the number of bytes of the body that will be included in the hash and hence signed. The length actually hashed should be inserted in the "l=" tag of the DKIM-Signature header field.
签名者可以选择限制将包含在散列中并因此进行签名的正文字节数。实际散列的长度应插入DKIM签名头字段的“l=”标记中。
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 recommended 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 considerably simplifies things for the user, who can 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.
边框或中间MTA可能会验证邮件签名。已执行验证的MTA可以通过向传入消息添加验证标头字段来传达验证结果。这大大简化了用户的工作，用户现在可以使用现有的邮件用户代理。大多数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 following steps in the order listed. In practice, several of these steps can be performed in parallel in order to improve performance.
验证器必须生成一个结果，该结果在语义上等同于按列出的顺序应用以下步骤。实际上，为了提高性能，可以并行执行其中几个步骤。
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) may also be considered.
信息性实现说明：在没有任何其他信息的情况下，验证者可能会使用订单作为签署订单的线索。然而，也可以考虑关于多个签名的语义的其他线索（例如将签名主机与接收到的报头字段相关联）。
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; such treatment is a matter of local policy and is beyond the scope of this document.
验证器不应将具有一个或多个坏签名且没有好签名的消息与完全没有签名的消息区别对待；此类处理是当地政策的问题，超出了本文件的范围。
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 to avoid denial-of-service attacks.
当签名成功验证时，验证器将停止处理或尝试验证任何其他签名，由实现自行决定。验证器可以限制其试图避免拒绝服务攻击的签名数量。
INFORMATIVE NOTE: An attacker could send messages with large numbers of faulty signatures, each of which would require a DNS lookup and corresponding CPU time to verify the message. This could be an attack on the domain that receives the message, by slowing down the verifier by requiring it to do a large number of DNS lookups and/or signature verifications. It could also be an attack against the domains listed in the signatures, essentially by enlisting innocent verifiers in launching an attack against the DNS servers of the actual victim.
信息提示：攻击者可以发送带有大量错误签名的消息，每个签名都需要DNS查找和相应的CPU时间来验证消息。这可能是对接收消息的域的攻击，通过要求验证器执行大量DNS查找和/或签名验证来降低验证器的速度。这也可能是对签名中列出的域的攻击，主要是通过招募无辜的验证者对实际受害者的DNS服务器发起攻击。
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 any 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 defer the message for later processing, perhaps by queueing it locally or issuing a 451/4.7.5 SMTP reply, or try another signature; if no good
在以下描述中，文本读取“返回状态（解释）”（其中“状态”是“PERMFAIL”或“TEMPFAIL”之一）意味着验证者必须立即停止处理该签名。验证者应该继续下一个签名（如果有），并且完全忽略坏的签名。如果状态为“PERMFAIL”，则签名失败，不应重新考虑。如果状态为“TEMPFAIL”，此时无法验证签名，但可以稍后重试。验证器可以延迟消息以便稍后处理，可能是通过在本地排队或发出451/4.7.5 SMTP回复，或者尝试另一个签名；如果不好
signature is found and any of the signatures resulted in a TEMPFAIL status, the verifier MAY save the message for later processing. The "(explanation)" is not normative text; it is provided solely for clarification.
如果发现签名，并且任何签名导致TEMPFAIL状态，验证器可以保存消息以供以后处理。“（解释）”不是规范性文本；本文件仅供澄清之用。
Verifiers SHOULD ignore any DKIM-Signature header fields where the signature does not validate. Verifiers that are prepared to validate multiple signature header fields SHOULD proceed to the next signature header field, should it exist. However, verifiers MAY make note of the fact that an invalid signature was present for consideration at a later step.
验证器应忽略签名未验证的任何DKIM签名头字段。准备验证多个签名头字段的验证器应转到下一个签名头字段（如果存在）。然而，验证者可能会注意到一个事实，即存在一个无效的签名供以后的步骤考虑。
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.
实施者必须仔细验证DKIM签名头字段中的格式和值；任何不一致或意外的值都必须导致标头字段被完全忽略，并且验证器返回PERMFAIL（签名语法错误）。在这种安全环境下，“在你接受的东西上自由”绝对是一种糟糕的策略。但是，请注意，这并不包括DKIM签名头字段中存在明确允许的未知标记。
Verifiers MUST ignore DKIM-Signature header fields with a "v=" tag that is inconsistent with this specification and return PERMFAIL (incompatible version).
验证器必须忽略带有与本规范不一致的“v=”标记的DKIM签名头字段，并返回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（签名缺少必需标记）。
INFORMATIONAL 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" may 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. 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.
完成验证过程需要签名的公钥。检索公钥的过程取决于DKIM签名头字段中“q=”标记定义的查询类型。显然，只有在提取签名信息的过程完全成功的情况下，才需要检索公钥。第3.6节描述了密钥管理和表示的详细信息。验证器必须验证密钥记录，并且必须忽略任何格式错误的公钥记录。
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. Retrieve 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 defer acceptance of this email and return TEMPFAIL (key unavailable). If verification is occurring during the incoming SMTP session, this MAY be achieved with a 451/4.7.5 SMTP reply code. Alternatively, the verifier MAY store the message in the local queue for later trial or ignore the signature. Note that storing a message in the local queue is subject to denial-of-service attacks.
2. 如果对公钥的查询没有响应，验证人可能会推迟接受此电子邮件并返回TEMPFAIL（密钥不可用）。如果在传入SMTP会话期间进行验证，则可以使用451/4.7.5 SMTP回复代码来实现。或者，验证器可以将消息存储在本地队列中以供稍后试用，或者忽略签名。请注意，在本地队列中存储消息会受到拒绝服务攻击。
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 may 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 "g=" tag in the public key does not match the Local-part of the "i=" tag in the message signature header field, the verifier MUST ignore the key record and return PERMFAIL (inapplicable key). If the Local-part of the "i=" tag on the message signature is not present, the "g=" tag must be "*" (valid for all addresses in the domain) or the entire g= tag must be omitted (which defaults to "g=*"), otherwise the verifier MUST ignore the key record and return PERMFAIL (inapplicable key). Other than this test, verifiers SHOULD NOT treat a message signed with a key record having a "g=" tag any differently than one without; in particular, verifiers SHOULD NOT prefer messages that
6. 如果公钥中的“g=”标记与消息签名头字段中“i=”标记的本地部分不匹配，验证器必须忽略密钥记录并返回PERMFAIL（不适用密钥）。如果消息签名上的“i=”标记的本地部分不存在，则“g=”标记必须“*”（对域中的所有地址有效）或必须省略整个g=标记（默认为“g=*”），否则验证器必须忽略密钥记录并返回PERMFAIL（不适用密钥）。除此测试外，验证者不应将使用带有“g=”标记的密钥记录签名的消息与不带“g=”标记的密钥记录签名的消息区别对待；特别是，验证器不应该偏爱
seem to have an individual signature by virtue of a "g=" tag versus a domain signature.
通过“g=”标记和域签名，似乎有一个单独的签名。
7. 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).
7. 如果公钥记录中存在“h=”标记，并且DKIM签名头字段中的a=标记所隐含的哈希算法未包含在“h=”标记的内容中，则验证器必须忽略密钥记录并返回PERMFAIL（不适当的哈希算法）。
8. 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.
8. 如果公钥数据（“p=”标记）为空，则该密钥已被撤销，验证器必须将其视为失败的签名检查并返回PERMFAIL（密钥撤销）。已撤销的密钥和已删除的密钥记录之间没有定义的语义差异。
9. 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).
9. 如果公钥数据不适合与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 version does not actually need to be instantiated). 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, such as by truncating the message at the indicated body length, declaring the signature invalid (e.g., by returning PERMFAIL (unsigned content)), or conveying the partial verification to the policy module.
签名的“l=”标记中指定的正文长度限制了传递给验证算法的正文字节数。DKIM不会验证超过该限制的所有数据。因此，验证器可能会怀疑包含超出指示正文长度字节的消息，例如通过在指示正文长度处截断消息、宣布签名无效（例如，通过返回PERMFAIL（未签名内容））或将部分验证传递给策略模块。
INFORMATIVE IMPLEMENTATION NOTE: Verifiers that truncate the body at the indicated body length might pass on a malformed MIME message if the signer used the "N-4" trick (omitting the final "--CRLF") described in the informative note in Section 3.4.5. Such verifiers may wish to check for this case and include a trailing "--CRLF" to avoid breaking the MIME structure. A simple way to achieve this might be to append "--CRLF" to any "multipart" message with a body length; if the MIME structure is already correctly formed, this will appear in the postlude and will not be displayed to the end user.
信息性实施说明：如果签名者使用第3.4.5节信息性说明中所述的“N-4”技巧（省略最后一个“-CRLF”），则以指定的正文长度截断正文的验证器可能会传递格式错误的MIME消息。这种验证器可能希望检查这种情况，并包括一个尾随“-CRLF”，以避免破坏MIME结构。实现这一点的一个简单方法可能是将“-CRLF”附加到任何具有正文长度的“多部分”消息中；如果MIME结构已经正确形成，它将出现在postlude中，并且不会显示给最终用户。
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.
希望将验证结果传达给邮件系统其他部分的验证者可采用其认为合适的任何方式。例如，实现可能会选择在传递消息之前向消息添加电子邮件头字段。任何此类头字段都应插入头字段块中任何现有DKIM签名或先前存在的身份验证状态头字段之前。
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 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
给MUA过滤器编写者的信息性建议：用于搜索结果标题字段以明显标记最终用户的已验证邮件的模式应验证此类标题字段是否由适当的验证域添加，以及验证的身份是否与MUA将显示的作者身份匹配。特别是，MUA过滤器不应受到虚假结果的影响
header fields added by attackers. To circumvent this attack, verifiers may wish to delete existing results header fields after verification and before adding a new header field.
攻击者添加的标题字段。为了避免这种攻击，验证者可能希望在验证之后和添加新的头字段之前删除现有的结果头字段。
It is beyond the scope of this specification to describe what actions a verifier system should make, but an authenticated email presents an opportunity to a receiving system that unauthenticated email cannot. 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.
描述验证器系统应采取的行动超出了本规范的范围，但经过身份验证的电子邮件为接收系统提供了未经身份验证的电子邮件无法提供的机会。具体来说，经过身份验证的电子邮件会创建一个可预测的标识符，通过该标识符可以可靠地管理其他决策，例如信任和声誉。相反，未经验证的电子邮件缺少可用于分配信任和声誉的可靠标识符。将未经验证的电子邮件视为缺乏信任和没有正面声誉是合理的。
In general, verifiers SHOULD NOT reject messages solely on the basis of a lack of signature or an unverifiable signature; such rejection would cause severe interoperability problems. However, if the verifier does opt to reject such messages (for example, when communicating with a peer who, by prior agreement, agrees to only send signed messages), and the verifier runs synchronously with the SMTP session and a signature is missing or does not verify, the MTA SHOULD use a 550/5.7.x reply code.
一般来说，验证者不应仅以缺少签名或无法验证签名为由拒绝电文；这种拒绝将导致严重的互操作性问题。但是，如果验证器确实选择拒绝此类邮件（例如，与事先同意只发送签名邮件的对等方通信时），并且验证器与SMTP会话同步运行，并且签名丢失或未验证，MTA应使用550/5.7.x回复代码。
If 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:
如果无法获取公钥，可能是因为密钥服务器不可用，则可以使用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 return 4xx SMTP replies.
临时故障（如无法访问密钥服务器或其他外部服务）是应使用4xx SMTP回复代码的唯一条件。特别是，加密签名验证失败不能返回4xx个SMTP回复。
Once the signature has been verified, that information MUST be conveyed to higher-level systems (such as explicit allow/whitelists and reputation systems) and/or to the end user. If the message is signed on behalf of any address other than that in the From: header field, the mail system SHOULD take pains to ensure that the actual signing identity is clear to the reader.
一旦签名得到验证，该信息必须传达给更高级别的系统（如明确的允许/白名单和信誉系统）和/或最终用户。如果邮件是代表除From:header字段之外的任何地址签名的，则邮件系统应尽力确保读者清楚实际签名标识。
The verifier MAY treat unsigned header fields with extreme skepticism, including marking them as untrusted or even deleting them before display to the end user.
验证器可能会极端怀疑地对待未签名的头字段，包括将其标记为不可信，甚至在显示给最终用户之前删除它们。
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 to the policy module and possibly recorded in the system logs. If the email cannot be verified, then it SHOULD be rendered the same as all unverified email regardless of whether or not it looks like it was signed.
虽然验证失败的症状很明显——签名无法验证——但确定确切原因可能更困难。如果找不到选择器，是因为选择器已被删除，还是在传输过程中该值发生了更改？如果签名行丢失，是因为它从未出现过，还是因为它被过度热心的过滤器删除了？出于诊断目的，应向策略模块提供验证失败的确切原因，并可能记录在系统日志中。如果无法验证电子邮件，则应将其呈现为与所有未经验证的电子邮件相同的内容，无论其看起来是否已签名。
DKIM introduces some new namespaces that have been registered with IANA. In all cases, new values are assigned only for values that have been documented in a published RFC that has IETF Consensus [RFC2434].
DKIM引入了一些已在IANA注册的新名称空间。在所有情况下，新值仅分配给已发布且具有IETF共识[RFC2434]的RFC中记录的值。
A DKIM-Signature provides for a list of tag specifications. IANA has established the DKIM-Signature Tag Specification Registry for tag specifications that can be used in DKIM-Signature fields.
DKIM签名提供标签规范列表。IANA已经为可用于DKIM签名字段的标记规范建立了DKIM签名标记规范注册中心。
The initial entries in the registry comprise:
登记册中的初始条目包括：
+------+-----------------+
| TYPE | REFERENCE |
+------+-----------------+
| v | (this document) |
| a | (this document) |
| b | (this document) |
| bh | (this document) |
| c | (this document) |
| d | (this document) |
| h | (this document) |
| i | (this document) |
| l | (this document) |
| q | (this document) |
| s | (this document) |
| t | (this document) |
| x | (this document) |
| z | (this document) |
+------+-----------------+
+------+-----------------+
| TYPE | REFERENCE |
+------+-----------------+
| v | (this document) |
| a | (this document) |
| b | (this document) |
| bh | (this document) |
| c | (this document) |
| d | (this document) |
| h | (this document) |
| i | (this document) |
| l | (this document) |
| q | (this document) |
| s | (this document) |
| t | (this document) |
| x | (this document) |
| z | (this document) |
+------+-----------------+
DKIM-Signature Tag Specification Registry Initial Values
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签名的消息进行验证处理的密钥。
The initial entry in the registry comprises:
登记册中的初始条目包括：
+------+--------+-----------------+
| TYPE | OPTION | REFERENCE |
+------+--------+-----------------+
| dns | txt | (this document) |
+------+--------+-----------------+
+------+--------+-----------------+
| TYPE | OPTION | REFERENCE |
+------+--------+-----------------+
| dns | txt | (this document) |
+------+--------+-----------------+
DKIM-Signature Query Method Registry Initial Values
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 Algorithm Registry for algorithms for converting a message into a canonical form before signing or verifying using DKIM.
IANA建立了DKIM签名规范化算法注册表，用于在使用DKIM签名或验证之前将消息转换为规范形式的算法。
The initial entries in the header registry comprise:
标头注册表中的初始项包括：
+---------+-----------------+
| TYPE | REFERENCE |
+---------+-----------------+
| simple | (this document) |
| relaxed | (this document) |
+---------+-----------------+
+---------+-----------------+
| TYPE | REFERENCE |
+---------+-----------------+
| simple | (this document) |
| relaxed | (this document) |
+---------+-----------------+
DKIM-Signature Header Canonicalization Algorithm Registry Initial Values
DKIM签名头规范化算法注册表初始值
The initial entries in the body registry comprise:
正文注册表中的初始条目包括：
+---------+-----------------+
| TYPE | REFERENCE |
+---------+-----------------+
| simple | (this document) |
| relaxed | (this document) |
+---------+-----------------+
+---------+-----------------+
| TYPE | REFERENCE |
+---------+-----------------+
| simple | (this document) |
| relaxed | (this document) |
+---------+-----------------+
DKIM-Signature Body Canonicalization Algorithm Registry Initial Values
DKIM签名体规范化算法注册表初始值
A _domainkey DNS TXT record provides for a list of tag specifications. IANA has established the DKIM _domainkey DNS TXT Tag Specification Registry for tag specifications that can be used in DNS TXT Records.
_domainkey DNS TXT记录提供标记规范列表。IANA已经为可用于DNS TXT记录的标记规范建立了DKIM _DomainKeyDNS TXT标记规范注册表。
The initial entries in the registry comprise:
登记册中的初始条目包括：
+------+-----------------+
| TYPE | REFERENCE |
+------+-----------------+
| v | (this document) |
| g | (this document) |
| h | (this document) |
| k | (this document) |
| n | (this document) |
| p | (this document) |
| s | (this document) |
| t | (this document) |
+------+-----------------+
+------+-----------------+
| TYPE | REFERENCE |
+------+-----------------+
| v | (this document) |
| g | (this document) |
| h | (this document) |
| k | (this document) |
| n | (this document) |
| p | (this document) |
| s | (this document) |
| t | (this document) |
+------+-----------------+
DKIM _domainkey DNS TXT Record Tag Specification Registry Initial Values
DKIM_domainkey DNS 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密钥类型注册表。
The initial entry in the registry comprises:
登记册中的初始条目包括：
+------+-----------+
| TYPE | REFERENCE |
+------+-----------+
| rsa | [RFC3447] |
+------+-----------+
+------+-----------+
| TYPE | REFERENCE |
+------+-----------+
| rsa | [RFC3447] |
+------+-----------+
DKIM Key Type Initial Values
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哈希算法注册表。
The initial entries in the registry comprise:
登记册中的初始条目包括：
+--------+-------------------+
| TYPE | REFERENCE |
+--------+-------------------+
| sha1 | [FIPS.180-2.2002] |
| sha256 | [FIPS.180-2.2002] |
+--------+-------------------+
+--------+-------------------+
| TYPE | REFERENCE |
+--------+-------------------+
| sha1 | [FIPS.180-2.2002] |
| sha256 | [FIPS.180-2.2002] |
+--------+-------------------+
DKIM Hash Algorithms Initial Values
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服务类型注册表。
The initial entries in the registry comprise:
登记册中的初始条目包括：
+-------+-----------------+
| TYPE | REFERENCE |
+-------+-----------------+
| email | (this document) |
| * | (this document) |
+-------+-----------------+
+-------+-----------------+
| TYPE | REFERENCE |
+-------+-----------------+
| email | (this document) |
| * | (this document) |
+-------+-----------------+
DKIM Service Types Registry Initial Values
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选择器标志注册表。
The initial entries in the registry comprise:
登记册中的初始条目包括：
+------+-----------------+
| TYPE | REFERENCE |
+------+-----------------+
| y | (this document) |
| s | (this document) |
+------+-----------------+
+------+-----------------+
| TYPE | REFERENCE |
+------+-----------------+
| y | (this document) |
| s | (this document) |
+------+-----------------+
DKIM Selector Flags Registry Initial Values
DKIM选择器标记注册表初始值
IANA has added DKIM-Signature to the "Permanent Message Header Fields" registry (see [RFC3864]) for the "mail" protocol, using this document as the reference.
IANA已将DKIM签名添加到“邮件”协议的“永久消息头字段”注册表（请参见[RFC3864]），使用本文档作为参考。
It has been observed that any mechanism that is introduced 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]。
Body length limits (in the form of the "l=" tag) are subject to several potential attacks.
身体长度限制（以“l=”标签的形式）可能会受到几次攻击。
If the body length limit does not cover a closing MIME multipart section (including the trailing "--CRLF" portion), then it is possible for an attacker to intercept a properly signed multipart message and add a new body part. Depending on the details of the MIME type and the implementation of the verifying MTA and the receiving MUA, this could allow an attacker to change the information displayed to an end user from an apparently trusted source.
如果正文长度限制不包括结束MIME多部分部分（包括尾随的“-CRLF”部分），则攻击者有可能截获正确签名的多部分消息并添加新的正文部分。根据MIME类型的详细信息以及验证MTA和接收MUA的实现情况，这可能会允许攻击者更改显示给最终用户的信息，这些信息的来源显然是可信的。
For example, if attackers can append information to a "text/html" body part, they may be able to exploit a bug in some MUAs that continue to read after a "</html>" marker, and thus display HTML text on top of already displayed text. If a message has a "multipart/alternative" body part, they might be able to add a new body part that is preferred by the displaying MUA.
例如，如果攻击者可以将信息附加到“text/html”主体部分，他们可能会利用某些MUA中的漏洞，这些MUA在“</html>”标记后继续读取，从而在已显示的文本上显示html文本。如果消息具有“多部分/备选”正文部分，则它们可能能够添加显示MUA首选的新正文部分。
Several receiving MUA implementations do not cease display after a ""</html>"" tag. In particular, this allows attacks involving overlaying images on top of existing text.
一些接收MUA实现不会在“</html>”标记后停止显示。特别是，这允许在现有文本上覆盖图像的攻击。
INFORMATIVE EXAMPLE: Appending the following text to an existing,
properly closed message will in many MUAs result in inappropriate
data being rendered on top of existing, correct data:
<div style="position: relative; bottom: 350px; z-index: 2;">
<img src="http://www.ietf.org/images/ietflogo2e.gif"
width=578 height=370>
</div>
INFORMATIVE EXAMPLE: Appending the following text to an existing,
properly closed message will in many MUAs result in inappropriate
data being rendered on top of existing, correct data:
<div style="position: relative; bottom: 350px; z-index: 2;">
<img src="http://www.ietf.org/images/ietflogo2e.gif"
width=578 height=370>
</div>
If the private key for a user is resident on their computer and is not protected by an appropriately secure mechanism, it is possible for malware to send mail as that user and any other user sharing the same private key. The malware would not, however, be able to generate signed spoofs of other signers' addresses, which would aid in identification of the infected user and would limit the possibilities for certain types of attacks involving socially engineered messages. This threat applies mainly to MUA-based implementations; protection of private keys on servers can be easily achieved through the use of specialized cryptographic hardware.
如果用户的私钥驻留在其计算机上，并且没有受到适当安全机制的保护，则恶意软件可能会以该用户和共享相同私钥的任何其他用户的身份发送邮件。然而，该恶意软件无法生成其他签名者地址的签名欺骗，这将有助于识别受感染的用户，并限制涉及社会工程消息的某些类型攻击的可能性。这种威胁主要适用于基于MUA的实现；通过使用专门的加密硬件，可以轻松实现对服务器上私钥的保护。
A larger problem occurs if malware on many users' computers obtains the private keys for those users and transmits them via a covert channel to a site where they can be shared. The compromised users would likely not know of the misappropriation until they receive "bounce" messages from messages they are purported to have sent. Many users might not understand the significance of these bounce messages and would not take action.
如果许多用户计算机上的恶意软件获取这些用户的私钥，并通过隐蔽通道将其传输到可以共享这些私钥的站点，则会出现更大的问题。在收到据称已发送的消息中的“反弹”消息之前，受损用户可能不知道盗用行为。许多用户可能不理解这些反弹消息的意义，不会采取行动。
One countermeasure is to use a user-entered passphrase to encrypt the private key, although users tend to choose weak passphrases and often reuse them for different purposes, possibly allowing an attack against DKIM to be extended into other domains. Nevertheless, the decoded private key might be briefly available to compromise by malware when it is entered, or might be discovered via keystroke
一种对策是使用用户输入的密码短语来加密私钥，尽管用户倾向于选择弱密码短语并经常将其用于不同的目的，这可能会使针对DKIM的攻击扩展到其他域。然而，解码的私钥在输入时可能会短暂地被恶意软件泄露，或者可能通过击键被发现
logging. The added complexity of entering a passphrase each time one sends a message would also tend to discourage the use of a secure passphrase.
登录中。每次发送消息时输入密码短语所增加的复杂性也会阻碍使用安全密码短语。
A somewhat more effective countermeasure is to send 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 is that if a very large amount of mail were to be sent using spoofed addresses from a given domain, the key servers for that domain could be overwhelmed with requests. However, given the low overhead of verification compared with handling of the email message itself, such an attack would be difficult to mount.
这种攻击的一种变体是，如果使用来自给定域的伪造地址发送大量邮件，该域的关键服务器可能会被请求淹没。但是，与处理电子邮件本身相比，验证开销较低，因此很难发起此类攻击。
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 [RFC2440] and S/MIME [RFC3851] address those requirements.
DKIM仅用于证明真实性的“充分”方法。它不打算提供关于作者身份或内容的强有力的加密证明。其他技术，如OpenPGP[RFC2440]和S/MIME[RFC3851]解决了这些需求。
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
与DNS相关的第二个安全问题是，由于获取基于选择器的数据以及获取签名域策略，DNS流量增加。普遍的
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.
部署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 the DNS Threat Analysis [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安全问题是DNS威胁分析[RFC3833]第2.3节中描述的名称链攻击。DKIM验证器在验证DKIM签名头字段时，可能会被提示检索攻击者选择的密钥记录。通过确保验证器使用的名称服务器（包括递归名称服务器）对DNS响应中的“胶水”和其他附加信息进行严格检查，从而不易受到此攻击，可以将此威胁降至最低。
In this attack, a spammer sends a message to be spammed to an accomplice, which results in the message being signed by the originating MTA. The accomplice resends the message, including the original signature, to a large number of recipients, possibly by sending the message to many compromised machines that act as MTAs. The messages, not having been modified by the accomplice, have valid signatures.
在此攻击中，垃圾邮件发送者向同谋发送一条要进行垃圾邮件处理的消息，从而导致该消息由发起MTA签名。共犯可能通过将邮件发送到许多充当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 resent a large number of messages received from a victim in order to make them 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 when 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.8 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.8节中描述的信任关系可被父域用于使用与父域在管理上不相关的子域中的身份对消息进行签名。例如，.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 example above any of the domains could potentially simply delegate "example.podunk.ca.us" to a server of their choice 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.
资料性说明：这被认为是一种可接受的风险，其原因与域委派是可接受的相同。例如，在上面的示例中，任何域都可能简单地将“example.podunk.ca.us”委托给他们选择的服务器，并完全替换所有DNS服务的信息。请注意，如第6.1.1节所述，验证者可能会忽略来自不太可能的域（如“.com”）的签名。
[FIPS.180-2.2002] U.S. Department of Commerce, "Secure Hash Standard", FIPS PUB 180-2, August 2002.
[FIPS.180-2.2002]美国商务部，“安全哈希标准”，FIPS PUB 180-22002年8月。
[ITU.X660.1997] "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.660, 1997.
[ITU.X660.1997]“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）的规范”，ITU-T建议X.660，1997年。
[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月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message header field Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]Moore，K.，“MIME（多用途Internet邮件扩展）第三部分：非ASCII文本的消息头字段扩展”，RFC 2047，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月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[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月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[BONEH03] Proc. 12th USENIX Security Symposium, "Remote Timing Attacks are Practical", 2003.
[BONEH03]程序。第12届USENIX安全研讨会，“远程定时攻击实用”，2003年。
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[RFC1847]Galvin，J.，Murphy，S.，Crocker，S.，和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年10月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[RFC2440]Callas，J.，Donnerhacke，L.，Finney，H.，和R.Thayer，“OpenPGP消息格式”，RFC 24401998年11月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths for Public Keys Used For Exchanging Symmetric Keys", RFC 3766, April 2004.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，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月。
[RFC3851] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 3851, June 1999.
[RFC3851]Ramsdell，B.，“S/MIME版本3消息规范”，RFC3851，1999年6月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, September 2004.
[RFC3864]Klyne，G.，Nottingham，M.，和J.Mogul，“消息头字段的注册程序”，BCP 902004年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月。
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006.
[RFC4686]Fenton，J.，“驱动域密钥识别邮件（DKIM）的威胁分析”，RFC4686，2006年9月。
[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月。
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.
乔。
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.
乔。
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:
签名通常由入站SMTP服务器或最终传递代理进行验证。但是，如果介入MTA选择执行此验证，则它们也可以执行此验证。验证过程使用从“d=”标记中提取的域“example.com”和从DKIM签名头字段中的“s=”标记中提取的选择器“brisbane”来形成DNS DKIM查询：
brisbane._domainkey.example.com
布里斯班._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
签名验证以“h=”标记中列出的顺序从物理上最后收到的标题字段、发件人标题字段等开始。验证之后是单个CRLF，然后是主体（以“Hi”开头）。这封电子邮件是为使用“简单”方法进行验证而准备的。签名的查询和后续验证结果存储在
example) in the X-Authentication-Results header field line. After successful verification, the email looks like this:
示例）在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.
乔。
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) and granularity (the "g=" key tag) facilitate this kind of restricted authorization. Examples of these outsourced business functions are legitimate email marketing providers and corporate benefits providers.
一些组织将特定的业务职能分配给组织内部或外部的离散组。因此，目标是授权该组对某些邮件进行签名，但限制它们可以生成哪些签名。DKIM选择器（“s=”签名标记）和粒度（“g=”密钥标记）促进了这种受限授权。这些外包业务功能的例子包括合法的电子邮件营销提供商和公司利益提供商。
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 that authorizes a specific From header field Local-part. For example, a client with the domain "example.com" could have the selector record specify "g=winter-promotions" so that this signature is only valid for mail with a From address of "winter-promotions@example.com". This would enable the provider to send messages using that specific address and have them verify properly. The client company retains control over the email address because it retains the ability to revoke the key at any time.
如果客户组织保留对所有DNS管理的责任，则外包公司可以生成密钥对，向客户公司提供公钥，然后客户公司使用唯一选择器将其注册到查询服务中，该选择器授权特定的“发件人”字段本地部分。例如，域为“example.com”的客户端可以让选择器记录指定“g=winter promotions”，这样该签名仅对发件人地址为“winter”的邮件有效-promotions@example.com". 这将使提供者能够使用该特定地址发送消息，并让它们正确验证。客户公司保留对电子邮件地址的控制权，因为它保留随时撤销密钥的能力。
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 wanted to be able to send messages using his corporate email address, jdoe@example.com, and his email device did 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 was 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",
独立服务，如步行信息亭和基于网络的信息服务，与用户没有持久的电子邮件服务关系，但用户偶尔会要求代表他们发送邮件。例如，提供新闻的网站通常允许读者将文章的副本转发给朋友。这通常使用读者自己的电子邮件地址来表示作者。这有时被称为“Evite问题”，
named after the website of the same name that allows a user to send invitations to friends.
以允许用户向朋友发送邀请的同名网站命名。
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.com <jdoe@example.com>. (Note that such rewriting will break a signature, unless it is done after the verification pass is complete.)
接收站点通常希望以这种方式向其最终用户提供有关邮件的信息。虽然不同方法的真正有效性是人为因素可用性研究的主题，但验证系统使用的一种技术是重写From头字段，以指示验证的地址。例如：发件人：John Doe vianews@news-site.com<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 changed. However, these services usually depend on users sending outgoing messages through their own service providers' 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.
“关联地址”允许用户拥有保持稳定的电子邮件地址，即使用户在不同的电子邮件提供商之间移动。他们通常与大学校友会、专业组织和娱乐组织有联系，他们希望与这些组织建立长期关系。这些域通常提供传入电子邮件的转发，并且它们通常有一个关联的Web应用程序来验证用户并允许更改转发地址。但是，这些服务通常依赖于用户通过自己的服务提供商的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
通过DKIM，关联域可以使用Web应用程序允许用户注册每个用户的密钥，用于代表其关联地址对消息进行签名。用户会拿走秘密的一半
of the key pair for signing, and the affinity domain would publish the public half in DNS for access by verifiers.
用于签名的密钥对，并且关联域将在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 which 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
以可能使现有签名无效的方式修改邮件的转发器尤其适合添加自己的签名（例如，邮件列表）-name@example.net). 由于（重新）签名负责消息的内容，因此这些签名转发器可能是选择性的，并且只有在接收到具有有效签名的消息时才转发或重新签名消息
signature or if they have some other basis for knowing that the message is not spoofed.
签名，或者如果他们有其他一些基础知道消息不是伪造的。
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 [RFC2822]. The forwarder applies a new DKIM-Signature header field with the signature, public key, and related information of the forwarder.
在主要是邮件重新分发者的系统中，一种常见做法是在邮件中添加发件人标头字段，以标识用于对邮件签名的地址。按照[RFC2822]的要求，此做法将删除任何先前存在的发送方标头字段。转发器应用新的DKIM签名头字段，其中包含转发器的签名、公钥和相关信息。
Appendix C. Creating a Public Key (INFORMATIVE)
附录C.创建公钥（信息性）
The default signature is an RSA signed SHA256 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签名SHA256摘要。为了便于解释，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中：
brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ"
"KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt"
"IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v"
"/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi"
"tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB")
brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ"
"KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt"
"IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v"
"/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi"
"tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB")
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 the user in a way that helps them is a matter of continuing human factors usability research. The tendency is to have the MUA highlight the address associated with this signing identity in some way, in an attempt to show the user the address from which the mail was sent. An MUA might do this with visual cues such as graphics, or it might include the address in an alternate view, or it 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以某种方式突出显示与此签名身份相关的地址，以尝试向用户显示邮件发送的地址。MUA可以通过图形等视觉提示来实现这一点，也可以在另一个视图中包含地址，甚至可以使用已验证的信息重写原始发件人地址。某些MUA可能会指示哪些标头字段受已验证的DKIM签名保护。这可以通过在有符号头字段上显示正指示，在无符号头字段上显示负指示，通过直观地隐藏无符号头字段或这些字段的某种组合来实现。如果MUA对签名头字段使用可视指示，则MUA可能需要小心，不要以最终用户可能认为已签名的方式显示未签名头字段。如果消息有一个l=标记，其值不延伸到消息末尾，MUA还可能隐藏或标记消息正文中未签名的部分。
The aforementioned information is not intended to be exhaustive. The MUA may 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作者认为对最终用户重要的任何其他信息。
The authors wish to thank 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 Gu[eth]mundsson, 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 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 for their valuable suggestions and constructive criticism.
作者希望感谢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 Gu[eth]mundsson、，菲利普·哈拉姆·贝克、托尼·汉森、山姆·哈特曼、阿维尔·哈特科克、阿米尔·赫茨伯格、保罗·霍夫曼、罗斯·霍斯利、克雷格·休斯、卡伦·詹宁斯、唐·约翰森、哈利·卡茨、默里·库奇拉维、巴里·莱巴、约翰·莱文、查尔斯·林赛、西蒙·朗斯代尔、大卫·马格雷夫、贾斯汀·梅森、大卫·梅恩、蒂埃里·莫罗、史蒂夫·墨菲、拉塞尔·纳尔逊、戴夫·奥兰、，道格·奥蒂斯、沙米姆·皮尔扎达、胡安·阿尔特迈耶·皮佐诺、桑杰·波尔、布莱克·拉姆斯代尔、克里斯蒂安·雷诺、斯科特·伦弗罗、尼尔·雷鲁普、埃里克·雷索拉、戴夫·罗塞蒂、赫克托·桑托斯、吉姆·沙德、Spamhaus.org团队、马尔特·S·斯特拉茨、罗伯特·桑德斯、兰德·瓦克、萨姆·韦勒和丹·温感谢他们的宝贵建议和建设性批评。
The DomainKeys specification was a primary source from which this specification has been derived. Further information about DomainKeys is at [RFC4870].
DomainKeys规范是该规范的主要来源。有关域密钥的更多信息，请访问[RFC4870]。
Authors' Addresses
作者地址
Eric Allman Sendmail, Inc. 6425 Christie Ave, Suite 400 Emeryville, CA 94608 USA
Eric Allman Sendmail，Inc.美国加利福尼亚州埃默里维尔克里斯蒂大道6425号400室，邮编94608
Phone: +1 510 594 5501 EMail: eric+dkim@sendmail.org URI:
电话：+15105945501电子邮件：eric+dkim@sendmail.orgURI:
Jon Callas PGP Corporation 3460 West Bayshore Palo Alto, CA 94303 USA
美国加利福尼亚州帕洛阿尔托西海岸3460号乔恩卡拉斯PGP公司，邮编94303
Phone: +1 650 319 9016
EMail: jon@pgp.com
Phone: +1 650 319 9016
EMail: jon@pgp.com
Mark Delany Yahoo! Inc 701 First Avenue Sunnyvale, CA 95087 USA
马克·德拉尼雅虎！美国加利福尼亚州桑尼维尔第一大道701号公司，邮编95087
Phone: +1 408 349 6831 EMail: markd+dkim@yahoo-inc.com URI:
电话：+1408 349 6831电子邮件：markd+dkim@yahoo-inc.com URI：
Miles Libbey Yahoo! Inc 701 First Avenue Sunnyvale, CA 95087 USA
迈尔斯·利比雅虎！美国加利福尼亚州桑尼维尔第一大道701号公司，邮编95087
EMail: mlibbeymail-mailsig@yahoo.com
URI:
EMail: mlibbeymail-mailsig@yahoo.com
URI:
Jim Fenton Cisco Systems, Inc. MS SJ-9/2 170 W. Tasman Drive San Jose, CA 95134-1706 USA
Jim Fenton Cisco Systems，Inc.美国加利福尼亚州圣何塞塔斯曼大道西侧SJ-9/2 170号，邮编95134-1706
Phone: +1 408 526 5914 EMail: fenton@cisco.com URI:
电话：+1408 526 5914电子邮件：fenton@cisco.comURI:
Michael Thomas Cisco Systems, Inc. MS SJ-9/2 170 W. Tasman Drive San Jose, CA 95134-1706
Michael Thomas Cisco Systems，Inc.位于加利福尼亚州圣何塞塔斯曼大道西侧170号SJ-9/2，邮编95134-1706
Phone: +1 408 525 5386
EMail: mat@cisco.com
Phone: +1 408 525 5386
EMail: mat@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。