Network Working Group M. Delany
Request for Comments: 4870 Yahoo! Inc
Obsoleted By: 4871 May 2007
Category: Historic
Network Working Group M. Delany
Request for Comments: 4870 Yahoo! Inc
Obsoleted By: 4871 May 2007
Category: Historic
Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)
使用DNS中公布的公钥进行基于域的电子邮件身份验证（域密钥）
Status of This Memo
关于下段备忘
This memo defines a Historic Document for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
此备忘录定义了互联网社区的历史文档。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
"DomainKeys" creates a domain-level authentication framework for email by using public key technology and the DNS to prove the provenance and contents of an email.
“域密钥”通过使用公钥技术和DNS来证明电子邮件的来源和内容，为电子邮件创建了域级身份验证框架。
This document defines a framework for digitally signing email on a per-domain basis. The ultimate goal of this framework is to unequivocally prove and protect identity while retaining the semantics of Internet email as it is known today.
本文档定义了一个基于每个域的电子邮件数字签名框架。该框架的最终目标是明确地证明和保护身份，同时保留当今已知的互联网电子邮件的语义。
Proof and protection of email identity may assist in the global control of "spam" and "phishing".
证明和保护电子邮件身份可能有助于全球控制“垃圾邮件”和“网络钓鱼”。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Lack of Authentication Is Damaging Internet Email ..........3
1.2. Digitally Signing Email Creates Credible Domain
Authentication .............................................4
1.3. Public Keys in the DNS .....................................4
1.4. Initial Deployment Is Likely at the Border MTA .............5
1.5. Conveying Verification Results to MUAs .....................5
1.6. Technical Minutiae Are Not Completely Covered ..............5
1.7. Motivation .................................................6
1.8. Benefits of DomainKeys .....................................6
1.9. Definitions ................................................7
1.10. Requirements Notation .....................................8
2. DomainKeys Overview .............................................8
3. DomainKeys Detailed View ........................................8
3.1. Determining the Sending Address of an Email ................9
3.2. Retrieving the Public Key Given the Sending Domain ........10
3.2.1. Introducing "selectors" ............................10
3.2.2. Public Key Signing and Verification Algorithm ......11
3.2.3. Public key Representation in the DNS ...............13
3.2.4. Key Sizes ..........................................14
3.3. Storing the Signature in the Email Header .................15
3.4. Preparation of Email for Transit and Signing ..............17
3.4.1. Preparation for Transit ............................18
3.4.2. Canonicalization for Signing .......................18
3.4.2.1. The "simple" Canonicalization Algorithm ...19
3.4.2.2. The "nofws" Canonicalization Algorithm ....19
3.5. The Signing Process .......................................20
3.5.1. Identifying the Sending Domain .....................20
3.5.2. Determining Whether an Email Should Be Signed ......21
3.5.3. Selecting a Private Key and Corresponding
Selector Information ...............................21
3.5.4. Calculating the Signature Value ....................21
3.5.5. Prepending the "DomainKey-Signature:" Header .......21
3.6. Policy Statement of Sending Domain ........................22
3.7. The Verification Process ..................................23
3.7.1. Presumption that Headers Are Not Reordered .........24
3.7.2. Verification Should Render a Binary Result .........24
3.7.3. Selecting the Most Appropriate
"DomainKey-Signature:" Header ......................24
3.7.4. Retrieve the Public Key Based on the
Signature Information ..............................26
3.7.5. Verify the Signature ...............................27
3.7.6. Retrieving Sending Domain Policy ...................27
3.7.7. Applying Local Policy ..............................27
3.8. Conveying Verification Results to MUAs ....................27
1. Introduction ....................................................3
1.1. Lack of Authentication Is Damaging Internet Email ..........3
1.2. Digitally Signing Email Creates Credible Domain
Authentication .............................................4
1.3. Public Keys in the DNS .....................................4
1.4. Initial Deployment Is Likely at the Border MTA .............5
1.5. Conveying Verification Results to MUAs .....................5
1.6. Technical Minutiae Are Not Completely Covered ..............5
1.7. Motivation .................................................6
1.8. Benefits of DomainKeys .....................................6
1.9. Definitions ................................................7
1.10. Requirements Notation .....................................8
2. DomainKeys Overview .............................................8
3. DomainKeys Detailed View ........................................8
3.1. Determining the Sending Address of an Email ................9
3.2. Retrieving the Public Key Given the Sending Domain ........10
3.2.1. Introducing "selectors" ............................10
3.2.2. Public Key Signing and Verification Algorithm ......11
3.2.3. Public key Representation in the DNS ...............13
3.2.4. Key Sizes ..........................................14
3.3. Storing the Signature in the Email Header .................15
3.4. Preparation of Email for Transit and Signing ..............17
3.4.1. Preparation for Transit ............................18
3.4.2. Canonicalization for Signing .......................18
3.4.2.1. The "simple" Canonicalization Algorithm ...19
3.4.2.2. The "nofws" Canonicalization Algorithm ....19
3.5. The Signing Process .......................................20
3.5.1. Identifying the Sending Domain .....................20
3.5.2. Determining Whether an Email Should Be Signed ......21
3.5.3. Selecting a Private Key and Corresponding
Selector Information ...............................21
3.5.4. Calculating the Signature Value ....................21
3.5.5. Prepending the "DomainKey-Signature:" Header .......21
3.6. Policy Statement of Sending Domain ........................22
3.7. The Verification Process ..................................23
3.7.1. Presumption that Headers Are Not Reordered .........24
3.7.2. Verification Should Render a Binary Result .........24
3.7.3. Selecting the Most Appropriate
"DomainKey-Signature:" Header ......................24
3.7.4. Retrieve the Public Key Based on the
Signature Information ..............................26
3.7.5. Verify the Signature ...............................27
3.7.6. Retrieving Sending Domain Policy ...................27
3.7.7. Applying Local Policy ..............................27
3.8. Conveying Verification Results to MUAs ....................27
4. Example of Use .................................................29
4.1. The User Composes an Email ................................29
4.2. The Email Is Signed .......................................29
4.3. The Email Signature Is Verified ...........................30
5. Association with a Certificate Authority .......................31
5.1. The "DomainKey-X509:" Header ..............................31
6. Topics for Discussion ..........................................32
6.1. The Benefits of Selectors .................................32
6.2. Canonicalization of Email .................................33
6.3. Mailing Lists .............................................33
6.4. Roving Users ..............................................33
7. Security Considerations ........................................34
7.1. DNS .......................................................34
7.1.1. The DNS Is Not Currently Secure ....................34
7.1.2. DomainKeys Creates Additional DNS Load .............35
7.2. Key Management ............................................35
7.3. Implementation Risks ......................................35
7.4. Privacy Assumptions with Forwarding Addresses .............35
7.5. Cryptographic Processing Is Computationally Intensive .....36
8. The Trial ......................................................36
8.1. Goals .....................................................36
8.2. Results of Trial ..........................................37
9. Note to Implementors Regarding TXT Records .....................37
10. References ....................................................37
10.1. Normative References .....................................37
10.2. Informative References ...................................38
Appendix A - Syntax Rules for the Tag=Value Format .............39
Acknowledgments ................................................40
4. Example of Use .................................................29
4.1. The User Composes an Email ................................29
4.2. The Email Is Signed .......................................29
4.3. The Email Signature Is Verified ...........................30
5. Association with a Certificate Authority .......................31
5.1. The "DomainKey-X509:" Header ..............................31
6. Topics for Discussion ..........................................32
6.1. The Benefits of Selectors .................................32
6.2. Canonicalization of Email .................................33
6.3. Mailing Lists .............................................33
6.4. Roving Users ..............................................33
7. Security Considerations ........................................34
7.1. DNS .......................................................34
7.1.1. The DNS Is Not Currently Secure ....................34
7.1.2. DomainKeys Creates Additional DNS Load .............35
7.2. Key Management ............................................35
7.3. Implementation Risks ......................................35
7.4. Privacy Assumptions with Forwarding Addresses .............35
7.5. Cryptographic Processing Is Computationally Intensive .....36
8. The Trial ......................................................36
8.1. Goals .....................................................36
8.2. Results of Trial ..........................................37
9. Note to Implementors Regarding TXT Records .....................37
10. References ....................................................37
10.1. Normative References .....................................37
10.2. Informative References ...................................38
Appendix A - Syntax Rules for the Tag=Value Format .............39
Acknowledgments ................................................40
This document proposes an authentication framework for email that stores public keys in the DNS and digitally signs email on a domain basis. Separate documents discuss how this framework can be extended to validate the delivery path of email as well as facilitate per-user authentication.
本文档提出了一个电子邮件身份验证框架，该框架在DNS中存储公钥，并在域基础上对电子邮件进行数字签名。单独的文档讨论了如何扩展此框架，以验证电子邮件的传递路径，并促进每个用户的身份验证。
The DomainKeys specification was a primary source from which the DomainKeys Identified Mail [DKIM] specification has been derived. The purpose in submitting this document is as an historical reference for deployed implementations written prior to the DKIM specification.
DomainKeys规范是DomainKeys Identified Mail[DKIM]规范的主要来源。提交本文档的目的是作为在DKIM规范之前编写的已部署实现的历史参考。
Authentication of email is not currently widespread. Not only is it difficult to prove your own identity, it is impossible to prevent others from abusing your identity.
电子邮件的身份验证目前并不普遍。不仅很难证明自己的身份，也无法防止他人滥用你的身份。
While most email exchanges do not intrinsically need authentication beyond context, it is the rampant abuse of identity by "spammers", "phishers", and their criminal ilk that makes proof necessary. In other words, authentication is as much about protection as proof.
虽然大多数电子邮件交换本质上不需要上下文之外的身份验证，但正是“垃圾邮件发送者”、“钓鱼者”及其犯罪同类猖獗地滥用身份证明才是必要的。换言之，身份验证与证明同样重要。
Importantly, the inability to authenticate email effectively delegates much of the control of the disposition of inbound email to the sender, since senders can trivially assume any email address. Creating email authentication is the first step to returning dispositional control of email to the recipient.
重要的是，无法对电子邮件进行身份验证有效地将入站电子邮件处置的大部分控制权委托给了发件人，因为发件人可以轻松地假定任何电子邮件地址。创建电子邮件身份验证是将电子邮件处置控制权返还给收件人的第一步。
For the purposes of this document, authentication is seen from a user perspective, and is intended to answer the question "who sent this email?" where "who" is the email address the recipient sees and "this email" is the content that the recipient sees.
在本文档中，身份验证是从用户的角度来看的，旨在回答“谁发送了此电子邮件？”的问题，其中“谁”是收件人看到的电子邮件地址，“此电子邮件”是收件人看到的内容。
DomainKeys combines public key cryptography and the DNS to provide credible domain-level authentication for email.
DomainKeys将公钥加密和DNS结合起来，为电子邮件提供可靠的域级身份验证。
When an email claims to originate from a certain domain, DomainKeys provides a mechanism by which the recipient system can credibly determine that the email did in fact originate from a person or system authorized to send email for that domain.
当电子邮件声称来自某个域时，DomainKeys提供了一种机制，通过该机制，收件人系统可以可靠地确定电子邮件确实来自授权为该域发送电子邮件的人员或系统。
The authentication provided by DomainKeys works in a number of scenarios in which other authentication systems fail or create complex operational requirements. These include the following:
DomainKeys提供的身份验证适用于许多其他身份验证系统失败或创建复杂操作需求的场景。这些措施包括：
o forwarded email
o 转发的电子邮件
o distributed sending systems
o 分布式发送系统
o authorized third-party sending
o 授权第三方发送
This base definition of DomainKeys is intended to primarily enable domain-level authenticity. Whether a given message is really sent by the purported user within the domain is outside the scope of the base definition. Having said that, this specification includes the possibility that some domains may wish to delegate fine-grained authentication to individual users.
域密钥的这个基本定义主要用于实现域级别的真实性。给定的消息是否真的由域内声称的用户发送超出了基本定义的范围。话虽如此，该规范包括一些域可能希望将细粒度身份验证委托给单个用户的可能性。
DomainKeys differs from traditional hierarchical public key systems in that it leverages the DNS for public key management, placing complete and direct control of key generation and management with the
DomainKeys不同于传统的分层公钥系统，它利用DNS进行公钥管理，通过
owner of the domain. That is, if you have control over the DNS for a given domain, you have control over your DomainKeys for that domain.
域的所有者。也就是说，如果您对给定域的DNS具有控制权，则您可以控制该域的域密钥。
The DNS is proposed as the initial mechanism for publishing public keys. DomainKeys is specifically designed to be extensible to other key-fetching services as they become available.
DNS被提议作为发布公钥的初始机制。DomainKeys经过专门设计，可以在其他密钥获取服务可用时扩展到这些服务。
For practical reasons, it is expected that initial implementations of DomainKeys will be deployed on Mail Transfer Agents (MTAs) that accept or relay email across administrative or organizational boundaries. There are numerous advantages to deployment at the border MTA, including:
出于实际原因，预计域密钥的初始实现将部署在邮件传输代理（MTA）上，这些代理可以跨管理或组织边界接收或转发电子邮件。在边境MTA部署有许多优势，包括：
o a reduction in the number of MTAs that have to be changed to support an implementation of DomainKeys
o 减少必须更改以支持域密钥实现的MTA数量
o a reduction in the number of MTAs involved in transmitting the email between a signing system and a verifying system, thus reducing the number of places that can make accidental changes to the contents
o 减少在签名系统和验证系统之间传输电子邮件所涉及的MTA数量，从而减少可能对内容进行意外更改的位置数量
o removing the need to implement DomainKeys within an internal email network.
o 不再需要在内部电子邮件网络中实现域密钥。
However, there is no necessity to deploy DomainKeys at the border as signing and verifying can effectively occur anywhere from the border MTA right back to the Mail User Agent (MUA). In particular, the best place to sign an email for many domains is likely to be at the point of SUBMISSION where the sender is often authenticated through SMTP AUTH or other identifying mechanisms.
但是，没有必要在边界部署域密钥，因为签名和验证可以有效地发生在从边界MTA到邮件用户代理（MUA）的任何位置。特别是，对于许多域，签署电子邮件的最佳位置可能是在提交时，发件人通常通过SMTP身份验证或其他识别机制进行身份验证。
It follows that testing the authenticity of an email results in some action based on the results of the test. Oftentimes, the action is to notify the MUA in some way -- typically via a header line.
因此，测试电子邮件的真实性会导致基于测试结果的某些操作。通常，操作是以某种方式通知MUA——通常是通过标题行。
The "Domainkey-Status:" header is defined in this specification for recording authentication results in the email.
“Domainkey Status:”标头在本规范中定义，用于在电子邮件中记录身份验证结果。
The intent of this specification is to communicate the fundamental characteristics of DomainKeys for an implementor. However, some aspects are derived from the functionality of the openssl command [OPENSSL] and, rather than duplicate that documentation, implementors
本规范的目的是向实现者传达域密钥的基本特征。但是，有些方面是从openssl命令[openssl]的功能派生出来的，而不是复制该文档，而是由实现者派生出来的
are expected to understand the mechanics of the openssl command, sufficient to complete the implementation.
希望能够理解openssl命令的机制，足以完成实现。
The motivation for DomainKeys is to define a simple, cheap, and "sufficiently effective" mechanism by which domain owners can control who has authority to send email using their domain. To this end, the designers of DomainKeys set out to build a framework that:
DomainKeys的动机是定义一种简单、廉价且“足够有效”的机制，通过该机制，域所有者可以控制谁有权使用其域发送电子邮件。为此，DomainKeys的设计者着手构建一个框架，该框架：
o is transparent and compatible with the existing email infrastructure
o 透明且与现有电子邮件基础架构兼容
o requires no new infrastructure
o 不需要新的基础设施
o can be implemented independently of clients in order to reduce deployment time
o 可以独立于客户端实现，以减少部署时间
o does not require the use of a central certificate authority that might impose fees for certificates or introduce delays to deployment
o 不需要使用可能对证书收取费用或导致部署延迟的中央证书颁发机构
o can be deployed incrementally
o 可以增量部署
While we believe that DomainKeys meets these criteria, it is by no means a perfect solution. The current Internet imposes considerable compromises on any similar scheme, and readers should be careful not to misinterpret the information provided in this document to imply that DomainKeys makes stronger credibility statements than it is able to do.
虽然我们相信DomainKeys满足这些标准，但它决不是一个完美的解决方案。当前的互联网对任何类似的方案都有相当大的妥协，读者应小心不要误解本文档中提供的信息，以为DomainKeys的可信度比它所能做到的更高。
As the reader will discover, DomainKeys is solely an authentication system. It is not a magic bullet for spam, nor is it an authorization system, a reputation system, a certification system, or a trust system.
读者会发现，域密钥仅仅是一个身份验证系统。它不是垃圾邮件的灵丹妙药，也不是授权系统、声誉系统、认证系统或信任系统。
However, a strong authentication system such as DomainKeys creates an unimpeachable framework within which comprehensive authorization systems, reputations systems, and their ilk can be developed.
然而，一个强大的身份验证系统（如域密钥）创建了一个无可挑剔的框架，在这个框架内可以开发综合授权系统、声誉系统及其同类产品。
With reference to the following sample email:
请参考以下电子邮件示例：
Line Data
Number Bytes Content
---- --- --------------------------------------------
01 46 From: "Joe SixPack" <joe@football.example.com>
02 40 To: "Suzie Q" <suzie@shopping.example.net>
03 25 Subject: Is dinner ready?
04 43 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
05 40 Comment: This comment has a continuation
06 51 because this line begins with folding white space
07 60 Message-ID: <20030712040037.46341@football.example.com>
08 00
09 03 Hi.
10 00
11 37 We lost the game. Are you hungry yet?
12 00
13 04 Joe.
14 00
15 00
Line Data
Number Bytes Content
---- --- --------------------------------------------
01 46 From: "Joe SixPack" <joe@football.example.com>
02 40 To: "Suzie Q" <suzie@shopping.example.net>
03 25 Subject: Is dinner ready?
04 43 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
05 40 Comment: This comment has a continuation
06 51 because this line begins with folding white space
07 60 Message-ID: <20030712040037.46341@football.example.com>
08 00
09 03 Hi.
10 00
11 37 We lost the game. Are you hungry yet?
12 00
13 04 Joe.
14 00
15 00
Line 01 is the first line of the email and the first line of the headers.
第01行是电子邮件的第一行和标题的第一行。
Lines 05 and 06 constitute the "Comment:" header.
第05行和第06行构成“注释：”标题。
Line 06 is a continuation header line.
第06行是延续标题行。
Line 07 is the last line of the headers.
第07行是标题的最后一行。
Line 08 is the empty line that separates the header from the body.
第08行是将收割台与车斗分开的空行。
Line 09 is the first line of the body.
第09行是正文的第一行。
Lines 10, 12, 14, and 15 are empty lines.
第10、12、14和15行是空行。
Line 13 is the last non-empty line of the email.
第13行是电子邮件的最后一个非空行。
Line 15 is the last line of the body and the last line of the email.
第15行是正文的最后一行，也是电子邮件的最后一行。
Lines 01 to 15 constitute the complete email.
第01行至第15行构成完整的电子邮件。
Line 01 is earlier than line 02, and line 02 is later than line 01.
第01行早于第02行，第02行晚于第01行。
This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in [RFC2119].
本文档偶尔使用大写字母表示的术语。当术语“必须”、“应该”、“建议”、“不得”、“不应该”和“可能”出现大写时，它们用于表示本规范的特殊要求。[RFC2119]中对这些术语的含义进行了讨论。
Under DomainKeys, a domain owner generates one or more private/public key pairs that will be used to sign messages originating from that domain. The domain owner places the public key in his domain namespace (i.e., in a DNS record associated with that domain), and makes the private key available to the outbound email system. When an email is submitted by an authorized user of that domain, the email system uses the private key to digitally sign the email associated with the sending domain. The signature is added as a header to the email, and the message is transferred to its recipients in the usual way.
在DomainKeys下，域所有者生成一个或多个私钥/公钥对，用于对来自该域的消息进行签名。域所有者将公钥放置在其域命名空间中（即，在与该域关联的DNS记录中），并使私钥可用于出站电子邮件系统。当该域的授权用户提交电子邮件时，电子邮件系统使用私钥对与发送域关联的电子邮件进行数字签名。签名作为邮件的标题添加到电子邮件中，并以通常的方式将邮件传输给收件人。
When a message is received with a DomainKey signature header, the receiving system can verify the signature as follows:
当接收到带有DomainKey签名头的消息时，接收系统可以按如下方式验证签名：
1. Extract the signature and claimed sending domain from the email.
1. 从声明的域发送签名并提取签名。
2. Fetch the public key from the claimed sending domain namespace.
2. 从声明的发送域命名空间获取公钥。
3. Use public key to determine whether the signature of the email has been generated with the corresponding private key, and thus whether the email was sent with the authority of the claimed sending domain.
3. 使用公钥来确定电子邮件的签名是否已使用相应的私钥生成，从而确定电子邮件是否已使用声明的发送域的权限发送。
In the event that an email arrives without a signature or when the signature verification fails, the receiving system retrieves the policy of the claimed sending domain to ascertain the preferred disposition of such email.
如果电子邮件到达时没有签名，或者签名验证失败，接收系统将检索声称的发送域的策略，以确定此类电子邮件的首选处置方式。
Armed with this information, the recipient system can apply local policy based on the results of the signature test.
有了这些信息，接收方系统可以根据签名测试的结果应用本地策略。
This section discusses the specifics of DomainKeys that are needed to create interoperable implementations. This section answers the following questions:
本节讨论创建可互操作实现所需的域密钥的细节。本节回答以下问题：
Given an email, how is the sending domain determined?
给定一封电子邮件，如何确定发送域？
How is the public key retrieved for a sending domain?
如何检索发送域的公钥？
As email transits the email system, it can potentially go through a number of changes. Which parts of the email are included in the signature and how are they protected from such transformations?
当电子邮件在电子邮件系统中传输时，它可能会经历许多变化。签名中包含电子邮件的哪些部分，以及如何保护它们不受此类转换的影响？
How is the signature represented in the email?
如何在电子邮件中表示签名？
If a signature is not present, or a verification fails, how does the recipient determine the policy intent of the sending domain?
如果签名不存在，或验证失败，收件人如何确定发送域的策略意图？
Finally, on verifying the authenticity of an email, how is that result conveyed to participating MUAs?
最后，在验证电子邮件的真实性时，如何将结果传达给参与的MUA？
While there are many alternative design choices, most lead to comparable functionality. The overriding selection criteria used to choose among the alternatives are as follows:
虽然有许多可供选择的设计方案，但大多数都会带来类似的功能。用于在备选方案中进行选择的主要选择标准如下：
o use deployed technology whenever possible
o 尽可能使用已部署的技术
o prefer ease of implementation
o 更喜欢易于实现
o avoid trading risk for excessive flexibility or interoperability
o 避免过度灵活性或互操作性带来的交易风险
o include basic flexibility
o 包括基本的灵活性
Adherence to these criteria implies that some existing email implementations will require changes to participate in DomainKeys. Ultimately, some hard choices need to be made regarding which requirements are more important.
遵守这些标准意味着一些现有的电子邮件实现将需要更改才能参与域密钥。最终，对于哪些需求更重要，需要做出一些艰难的选择。
The goal of DomainKeys is to give the recipient confidence that the email originated from the claimed sender. As with much of Internet email, agreement over what constitutes the "sender" is no easy matter. Forwarding systems and mailing lists add serious complications to an overtly simple question. From the point of view of the recipient, the authenticity claim should be directed at the domain most visible to the recipient.
DomainKeys的目标是让收件人相信电子邮件来自声称的发件人。与许多互联网电子邮件一样，就“发件人”的构成达成一致并非易事。转发系统和邮件列表给一个非常简单的问题增加了严重的复杂性。从接收者的角度来看，真实性声明应针对接收者最可见的域。
In the first instance, the most visible address is clearly the RFC 2822 "From:" address [RFC2822]. Therefore, a conforming email MUST contain a single "From:" header from which an email address with a domain name can be extracted.
在第一种情况下，最明显的地址显然是RFC 2822“From:”地址[RFC2822]。因此，一封符合要求的电子邮件必须包含一个“发件人：”标题，从中可以提取带有域名的电子邮件地址。
A conforming email MAY contain a single RFC 2822 "Sender:" header from which an email address with a domain name can be extracted.
一致性电子邮件可能包含一个RFC 2822“发件人：”标题，可以从中提取带有域名的电子邮件地址。
If the email has a valid "From:" and a valid "Sender:" header, then the signer MUST use the sending address in the "Sender:" header.
如果电子邮件有一个有效的“发件人：”和一个有效的“发件人：”标题，那么签名者必须使用“发件人：”标题中的发送地址。
If the email has a valid "From:" and no "Sender:" header, then the signer MUST use the first sending address in the "From:" header.
如果电子邮件具有有效的“发件人：”和“发件人：”标题，则签名人必须使用“发件人：”标题中的第一个发送地址。
In all other cases, a signer MUST NOT sign the email. Implementors should note that an email with a "Sender:" header and no "From:" header MUST NOT be signed.
在所有其他情况下，签名者不得在电子邮件上签名。实施者应该注意，带有“发件人：”标题和“发件人：”标题的电子邮件不得签名。
The domain name in the sending address constitutes the "sending domain".
发送地址中的域名构成“发送域”。
To avoid namespace conflicts, it is proposed that the DNS namespace "_domainkey." be reserved within the sending domain for storing public keys, e.g., if the sending domain is example.net, then the public keys for that domain are stored in the _domainkey.example.net namespace.
为了避免名称空间冲突，建议在发送域中保留DNS名称空间“_domainkey.”以存储公钥，例如，如果发送域是example.net，则该域的公钥存储在_domainkey.example.net名称空间中。
To support multiple concurrent public keys per sending domain, the DNS namespace is further subdivided with "selectors". Selectors are arbitrary names below the "_domainkey." namespace. A selector value and length MUST be legal in the DNS namespace and in email headers with the additional provision that they cannot contain a semicolon.
为了支持每个发送域的多个并发公钥，DNS名称空间进一步细分为“选择器”。选择器是“_domainkey.”命名空间下的任意名称。选择器值和长度在DNS命名空间和电子邮件头中必须是合法的，并附加规定它们不能包含分号。
Examples of namespaces using selectors are as follows:
使用选择器的名称空间示例如下：
"coolumbeach._domainkey.example.net" "sebastopol._domainkey.example.net" "reykjavik._domainkey.example.net" "default._domainkey.example.net"
“Coolumber.\u domainkey.example.net”“sebastopol.\u domainkey.example.net”“雷克雅未克.\u domainkey.example.net”“默认值.\u domainkey.example.net”
and
和
"2005.pao._domainkey.example.net" "2005.sql._domainkey.example.net" "2005.rhv._domainkey.example.net"
“2005.pao._domainkey.example.net”“2005.sql._domainkey.example.net”“2005.rhv._domainkey.example.net”
Periods are allowed in selectors and are to be treated as component separators. In the case of DNS queries, that means the period defines subdomain boundaries.
选择器中允许使用句点，并将其视为组件分隔符。在DNS查询的情况下，这意味着周期定义了子域边界。
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 "2005" to a public key associated with selector "2006", it merely makes sure that both public keys are advertised in the DNS 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 "2006" private key. At the end of the transition period, the "2005" public key is removed from the DNS.
除了方便管理之外，选择器还可以在日常基础上无缝替换公钥。如果域希望从使用与选择器“2005”关联的公钥更改为与选择器“2006”关联的公钥，则它仅确保在验证前电子邮件可能正在传输的过渡期内，在DNS中同时公布这两个公钥。在过渡期开始时，出站电子邮件服务器配置为使用“2006”私钥签名。在过渡期结束时，将从DNS中删除“2005”公钥。
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 make this selector associated directly with the user name or make it some unassociated random value, such as the fingerprint of the public key.
虽然一些域可能希望让选择器值广为人知，但其他域希望注意不要以允许外部方获取数据的方式分配选择器名称。例如，如果颁发了每个用户的密钥，则域所有者将需要决定是使此选择器直接与用户名关联，还是使其成为一些未关联的随机值，例如公钥的指纹。
The default signature is an RSA signed SHA1 digest of the complete email.
默认签名是完整电子邮件的RSA签名SHA1摘要。
For ease of explanation, the openssl command is used throughout this document to describe the mechanism by which keys and signatures are managed.
为了便于解释，本文档中使用了openssl命令来描述密钥和签名的管理机制。
One way to generate a 768-bit private key suitable for DomainKeys is to use openssl like this:
生成适用于域密钥的768位私钥的一种方法是使用openssl，如下所示：
$ openssl genrsa -out rsa.private 768
$ openssl genrsa-out rsa.private 768
which results in the file rsa.private containing the key information similar to this:
这将导致文件rsa.private包含与以下类似的密钥信息：
-----BEGIN RSA PRIVATE KEY-----
MIIByQIBAAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6lMIgulclWjZwP56LRqdg5
ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7EXzVc+nRLWT1kwTvFNGIo
AUsFUq+J6+OprwIDAQABAmBOX0UaLdWWusYzNol++nNZ0RLAtr1/LKMX3tk1MkLH
+Ug13EzB2RZjjDOWlUOY98yxW9/hX05Uc9V5MPo+q2Lzg8wBtyRLqlORd7pfxYCn
Kapi2RPMcR1CxEJdXOkLCFECMQDTO0fzuShRvL8q0m5sitIHlLA/L+0+r9KaSRM/
3WQrmUpV+fAC3C31XGjhHv2EuAkCMQDE5U2nP2ZWVlSbxOKBqX724amoL7rrkUew
ti9TEjfaBndGKF2yYF7/+g53ZowRkfcCME/xOJr58VN17pejSl1T8Icj88wGNHCs
FDWGAH4EKNwDSMnfLMG4WMBqd9rzYpkvGQIwLhAHDq2CX4hq2tZAt1zT2yYH7tTb
weiHAQxeHe0RK+x/UuZ2pRhuoSv63mwbMLEZAjAP2vy6Yn+f9SKw2mKuj1zLjEhG
6ppw+nKD50ncnPoP322UMxVNG4Eah0GYJ4DLP0U=
-----END RSA PRIVATE KEY-----
-----BEGIN RSA PRIVATE KEY-----
MIIByQIBAAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6lMIgulclWjZwP56LRqdg5
ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7EXzVc+nRLWT1kwTvFNGIo
AUsFUq+J6+OprwIDAQABAmBOX0UaLdWWusYzNol++nNZ0RLAtr1/LKMX3tk1MkLH
+Ug13EzB2RZjjDOWlUOY98yxW9/hX05Uc9V5MPo+q2Lzg8wBtyRLqlORd7pfxYCn
Kapi2RPMcR1CxEJdXOkLCFECMQDTO0fzuShRvL8q0m5sitIHlLA/L+0+r9KaSRM/
3WQrmUpV+fAC3C31XGjhHv2EuAkCMQDE5U2nP2ZWVlSbxOKBqX724amoL7rrkUew
ti9TEjfaBndGKF2yYF7/+g53ZowRkfcCME/xOJr58VN17pejSl1T8Icj88wGNHCs
FDWGAH4EKNwDSMnfLMG4WMBqd9rzYpkvGQIwLhAHDq2CX4hq2tZAt1zT2yYH7tTb
weiHAQxeHe0RK+x/UuZ2pRhuoSv63mwbMLEZAjAP2vy6Yn+f9SKw2mKuj1zLjEhG
6ppw+nKD50ncnPoP322UMxVNG4Eah0GYJ4DLP0U=
-----END RSA PRIVATE KEY-----
Once a private key has been generated, the openssl command can be used to sign an appropriately prepared email, like this:
生成私钥后，可以使用openssl命令对适当准备的电子邮件进行签名，如下所示：
$ openssl dgst -sign rsa.private -sha1 <input.file
$ openssl dgst -sign rsa.private -sha1 <input.file
which results in signature data similar to this when represented in Base64 [BASE64] format:
当以Base64[Base64]格式表示时，会产生与此类似的签名数据：
aoiDeX42BB/gP4ScqTdIQJcpAObYr+54yvctqc4rSEFYby9+omKD3pJ/TVxATeTz
msybuW3WZiamb+mvn7f3rhmnozHJ0yORQbnn4qJQhPbbPbWEQKW09AMJbyz/0lsl
aoiDeX42BB/gP4ScqTdIQJcpAObYr+54yvctqc4rSEFYby9+omKD3pJ/TVxATeTz
msybuW3WZiamb+mvn7f3rhmnozHJ0yORQbnn4qJQhPbbPbWEQKW09AMJbyz/0lsl
How this signature is added to the email is discussed later in this document.
本文档后面将讨论如何将此签名添加到电子邮件中。
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
which results in the file rsa.public containing the key information similar to this:
这将导致文件rsa.public包含与以下类似的密钥信息：
-----BEGIN PUBLIC KEY-----
MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6l
MIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7E
XzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB
-----END PUBLIC KEY-----
-----BEGIN PUBLIC KEY-----
MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6l
MIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7E
XzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB
-----END PUBLIC KEY-----
This public key data is placed in the DNS.
此公钥数据放置在DNS中。
With the signature, canonical email contents and public key, a verifying system can test the validity of the signature. The openssl invocation to verify a signature looks like this:
通过签名、规范的电子邮件内容和公钥，验证系统可以测试签名的有效性。验证签名的openssl调用如下所示：
$ openssl dgst -verify rsa.public -sha1 -signature sig.file <input.file
$ openssl dgst -verify rsa.public -sha1 -signature sig.file <input.file
There is currently no standard method defined for storing public keys in the DNS. As an interim measure, the public key is stored as a TXT record derived from a Privacy-Enhanced Mail (PEM) format [PEM], that is, as a Base64 representation of a DER encoded key. Here is an example of a 768-bit RSA key in PEM form:
目前没有定义用于在DNS中存储公钥的标准方法。作为一项临时措施，公钥存储为从隐私增强邮件（PEM）格式[PEM]派生的TXT记录，即，作为DER编码密钥的Base64表示。以下是PEM形式的768位RSA密钥示例：
-----BEGIN PUBLIC KEY-----
MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6l
MIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7E
XzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB
-----END PUBLIC KEY-----
-----BEGIN PUBLIC KEY-----
MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6l
MIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7E
XzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB
-----END PUBLIC KEY-----
To save scarce DNS packet space and aid extensibility, the PEM wrapping MUST be removed and the remaining public key data along with other attributes relevant to DomainKeys functionality are stored as tag=value pairs separated by semicolons, for example, as in the following:
为了节省稀缺的DNS数据包空间并帮助扩展，必须删除PEM包装，剩余的公钥数据以及与DomainKeys功能相关的其他属性存储为标记=值对，用分号分隔，例如，如下所示：
brisbane._domainkey IN TXT "g=; k=rsa; p=MHww ... IDAQAB"
brisbane._domainkey IN TXT "g=; k=rsa; p=MHww ... IDAQAB"
Verifiers MUST support key sizes of 512, 768, 1024, 1536 and 2048 bits. Signers MUST support at least one of the verifier supported key sizes.
验证器必须支持512、768、1024、1536和2048位的密钥大小。签名者必须至少支持一个验证器支持的密钥大小。
The current valid tags are as follows:
当前的有效标记如下所示：
g = granularity of the key. If present with a non-zero length value, this value MUST exactly match the local part of the sending address. This tag is optional.
g=密钥的粒度。如果存在非零长度值，则该值必须与发送地址的本地部分完全匹配。此标记是可选的。
The intent of this tag is to constrain which sending address can legitimately use this selector. An email with a sending address that does not match the value of this tag constitutes a failed verification.
此标记的目的是限制哪个发送地址可以合法使用此选择器。发送地址与此标记的值不匹配的电子邮件构成验证失败。
k = key type (rsa is the default). Signers and verifiers MUST support the 'rsa' key type. This tag is optional.
k=密钥类型（默认为rsa）。签名者和验证者必须支持“rsa”密钥类型。此标记是可选的。
n = Notes that may be of interest to a human. No interpretation is made by any program. This tag is optional.
n=可能对人类感兴趣的注释。任何程序都不会进行解释。此标记是可选的。
p = public key data, encoded as a Base64 string. An empty value means that this public key has been revoked. This tag MUST be present.
p=公钥数据，编码为Base64字符串。空值表示此公钥已被吊销。此标签必须存在。
t = a set of flags that define boolean attributes. Valid attributes are as follows:
t=定义布尔属性的一组标志。有效属性如下所示：
y = testing mode. This domain is testing DomainKeys and unverified email MUST NOT be treated differently from verified email. Recipient systems MAY wish to track testing mode results to assist the sender.
y=测试模式。此域正在测试域密钥，未经验证的电子邮件不得与已验证的电子邮件区别对待。接收方系统可能希望跟踪测试模式结果以帮助发送方。
This tag is optional.
此标记是可选的。
(Syntax rules for the tag=value format are discussed in Appendix A.)
（标签=值格式的语法规则见附录A。）
Keeping the size of the TXT record to a minimum is important as some implementations of content and caching DNS servers are reported to have problems supporting large TXT records. In the example above, the encoding generates a 182-byte TXT record. That this encoding is less than 512 bytes is of particular significance as it fits within a single UDP response packet. With careful selection of query values, a TXT record can accommodate a 2048 bit key.
将TXT记录的大小保持在最小值非常重要，因为据报告，某些内容和缓存DNS服务器的实现在支持大型TXT记录方面存在问题。在上面的示例中，编码生成182字节的TXT记录。此编码小于512字节具有特殊意义，因为它适合于单个UDP响应数据包。通过仔细选择查询值，TXT记录可以容纳2048位键。
For the same size restriction reason, the "n" tag SHOULD be used sparingly. The most likely use of this tag is to convey a reason why a public key might have been revoked. In this case, set the "n" tag to the explanation and remove the public key value from the "p" tag.
出于相同的大小限制原因，“n”标记应谨慎使用。此标记最有可能用于说明公钥可能已被吊销的原因。在这种情况下，将“n”标记设置为解释，并从“p”标记中删除公钥值。
Selecting appropriate key sizes is a trade-off between cost, performance, and risk. This specification does not define either minimum or maximum key sizes -- that decision is a matter for each domain owner.
选择合适的密钥大小是成本、性能和风险之间的权衡。该规范既没有定义最小密钥大小，也没有定义最大密钥大小——这一决定取决于每个域所有者。
Factors that should influence this decision include the following:
影响这一决定的因素包括：
o the practical constraint that a 2048-bit key is the largest key that fits within a 512-byte DNS UDP response packet
o 2048位密钥是适合512字节DNS UDP响应数据包的最大密钥的实际约束
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 public key systems
o 与公钥系统的典型目标相比，本规范的安全目标是适度的
In general, it is expected that most domain owners will use keys that are no larger than 1024 bits.
一般来说，大多数域所有者将使用不大于1024位的密钥。
The signature of the email is stored in the "DomainKey-Signature:" header. This header contains all of the signature and key-fetching data.
电子邮件的签名存储在“DomainKey签名：”标题中。此标头包含所有签名和密钥获取数据。
When generating the signed email, the "DomainKey-Signature:" header MUST precede the original email headers presented to the signature algorithm.
生成签名电子邮件时，“DomainKey Signature:”标头必须位于提交给签名算法的原始电子邮件标头之前。
The "DomainKey-Signature:" header is not included in the signature calculation.
签名计算中不包括“DomainKey Signature:”标头。
For extensibility, the "DomainKey-Signature:" header contains tag=value pairs separated by semicolons, for example, as in the following:
为了扩展性，“DomainKey Signature:”标头包含由分号分隔的标记=值对，例如，如下所示：
DomainKey-Signature: a=rsa-sha1; s=brisbane; d=example.net;
q=dns; c=simple
DomainKey-Signature: a=rsa-sha1; s=brisbane; d=example.net;
q=dns; c=simple
The current valid tags are as follows:
当前的有效标记如下所示：
a = The algorithm used to generate the signature. The default is "rsa-sha1", an RSA signed SHA1 digest. Signers and verifiers MUST support "rsa-sha1".
a=用于生成签名的算法。默认值为“rsa-sha1”，这是一个rsa签名的sha1摘要。签名者和验证者必须支持“rsa-sha1”。
b = The signature data, encoded as a Base64 string. This tag MUST be present.
b=签名数据，编码为Base64字符串。此标签必须存在。
Whitespace is ignored in this value and MUST be removed when reassembling the original signature. This is another way of saying that the signing process can safely insert folding whitespace in this value to conform to line-length limits.
此值中忽略空白，重新组合原始签名时必须删除空白。这是表示签名过程可以安全地在此值中插入折叠空格以符合行长度限制的另一种方式。
c = Canonicalization algorithm. The method by which the headers and content are prepared for presentation to the signing algorithm. This tag MUST be present. Verifiers MUST support "simple" and "nofws". Signers MUST support at least one of the verifier-supported algorithms.
c=规范化算法。准备标头和内容以呈现给签名算法的方法。此标签必须存在。验证器必须支持“简单”和“nofws”。签名者必须至少支持一种验证者支持的算法。
d = The domain name of the signing domain. This tag MUST be present. In conjunction with the selector tag, this domain forms the basis of the public key query. The value in this tag MUST match the domain of the sending email address or MUST be one of the parent domains of the sending email address. Domain name comparison is case insensitive.
d=签名域的域名。此标签必须存在。该域与选择器标记一起构成公钥查询的基础。此标记中的值必须与发送电子邮件地址的域匹配，或者必须是发送电子邮件地址的父域之一。域名比较不区分大小写。
The matching process for this tag is called subdomain matching, as the sending email address must be the domain or subdomain of the value.
此标记的匹配过程称为子域匹配，因为发送电子邮件地址必须是值的域或子域。
h = A colon-separated list of header field names that identify the headers presented to the signing algorithm. If present, the value MUST contain the complete list of headers in the order presented to the signing algorithm.
h=以冒号分隔的标题字段名列表，用于标识提交给签名算法的标题。如果存在，则该值必须按照提交给签名算法的顺序包含标题的完整列表。
If present, this tag MUST include the header that was used to identify the sending domain, i.e., the "From:" or "Sender:" header; thus, this tag can never contain an empty value.
如果存在，此标记必须包括用于标识发送域的标头，即“发件人：”或“发件人：”标头；因此，此标记不能包含空值。
If this tag is not present, all headers subsequent to the signature header are included in the order found in the email.
如果此标记不存在，则签名标头之后的所有标头都将包含在电子邮件中的顺序中。
A verifier MUST support this tag. A signer MAY support this tag. If a signer generates this tag, it MUST include all email headers in the original email, as a verifier MAY remove or render suspicious, lines that are not included in the signature.
验证器必须支持此标记。签名者可以支持此标记。如果签名人生成此标记，则必须在原始电子邮件中包含所有电子邮件标题，因为验证者可能会删除或显示签名中未包含的可疑行。
In the presence of duplicate headers, a signer may include duplicate entries in the list of headers in this tag. If a header is included in this list, a verifier must include all occurrences of that header, subsequent to the "DomainKey-Signature:" header in the verification.
如果存在重复的标题，签名者可能会在该标记的标题列表中包含重复的条目。如果此列表中包含一个标头，则验证器必须在验证中包含“DomainKey Signature:”标头之后包含该标头的所有出现。
If a header identified in this list is not found after the "DomainKey-Signature:" header in the verification process, a verifier may "look" for a matching header prior to the "DomainKey-Signature:" header; however, signers should not rely on this as early experience suggests that most verifiers do not try to "look" back before the "DomainKey-Signature:" header.
如果在验证过程中，在“DomainKey Signature:”标头之后未找到此列表中标识的标头，则验证器可以在“DomainKey Signature:”标头之前“查找”匹配标头；然而，签名者不应该依赖于此，因为早期的经验表明，大多数验证者不会试图在“DomainKey签名：”头之前“回头看”。
Whitespace is ignored in this value and header comparisons are case insensitive.
此值中忽略空格，并且标头比较不区分大小写。
q = The query method used to retrieve the public key. This tag MUST be present. Currently, the only valid value is "dns", which defines the DNS lookup algorithm described in this document. Verifiers and signers MUST support "dns".
q=用于检索公钥的查询方法。此标签必须存在。目前，唯一有效的值是“dns”，它定义了本文档中描述的dns查找算法。验证者和签名者必须支持“dns”。
s = The selector used to form the query for the public key. This tag MUST be present. In the DNS query type, this value is prepended to the "_domainkey." namespace of the sending domain.
s=用于形成公钥查询的选择器。此标签必须存在。在DNS查询类型中，此值在发送域的“\u domainkey.”命名空间之前。
(Syntax rules for the tag=value format are discussed in Appendix A.)
（标签=值格式的语法规则见附录A。）
Here is an example of a signature header spread across multiple continuation lines:
以下是横跨多个续行的签名头的示例：
DomainKey-Signature: a=rsa-sha1; s=brisbane; d=example.net;
c=simple; q=dns;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR;
DomainKey-Signature: a=rsa-sha1; s=brisbane; d=example.net;
c=simple; q=dns;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR;
Extreme care must be taken to ensure that any new tags added to this header are defined and used solely for the purpose of fetching and verifying the signature. Any semantics beyond verification cannot be trusted, as this header is not protected by the signature.
必须非常小心，以确保添加到此标头的任何新标记都被定义并仅用于获取和验证签名。任何超出验证范围的语义都是不可信的，因为此头不受签名保护。
If additional semantics not pertaining directly to signature verification are required, they must only be added as subsequent headers protected by the signature. Semantic additions might include audit information describing the initial submission.
如果需要与签名验证不直接相关的附加语义，则它们只能作为受签名保护的后续头添加。语义添加可能包括描述初始提交的审核信息。
The fundamental purpose of a cryptographic signature is to ensure that the signed content matches the contents presented for verification. However, unlike just about every other Internet protocol, the email content is routinely modified as it enters and transits the email system.
加密签名的基本目的是确保签名内容与用于验证的内容相匹配。然而，与几乎所有其他互联网协议不同的是，电子邮件内容在进入和传输电子邮件系统时通常会被修改。
Fortunately most of the modifications typically made to email can be predicted and consequently accounted for when signing and verifying.
幸运的是，通常对电子邮件所做的大多数修改都是可以预测的，因此在签名和验证时可以考虑这些修改。
To maximize the chance of a successful verification, submitted email should be prepared for transport prior to signing, and the data presented to the signing algorithm is canonicalized to exclude the most common and minor changes made to email.
为了最大限度地提高验证成功的机会，提交的电子邮件应在签名之前准备好传输，并将提交给签名算法的数据规范化，以排除对电子邮件所做的最常见和次要更改。
The SMTP protocol defines a number of potential limitations to email transport, particularly pertaining to line lengths and 8-bit content.
SMTP协议定义了电子邮件传输的一些潜在限制，特别是与行长度和8位内容有关的限制。
While the editor has observed that most modern SMTP implementations accept 8-bit email and long lines, some implementations still do not. Consequently, a DomainKeys implementation SHOULD prepare an email to be suitable for the lowest common denominator of SMTP prior to presenting the email for signing.
虽然编辑器观察到大多数现代SMTP实现都接受8位电子邮件和长行，但有些实现仍然不接受。因此，域密钥实现应该在提交电子邮件进行签名之前准备一封电子邮件，使其适合SMTP的最低公分母。
DomainKeys is initially expected to be deployed at, or close to, the email borders of an organization rather than in MUAs or SUBMISSION servers. In other words, the signing and verifying algorithms normally apply after an email has been packaged, transmogrified, and generally prepared for transmission across the Internet via SMTP and, thus the likelihood of the email being subsequently modified is reduced.
域密钥最初预计部署在组织的电子邮件边界或其附近，而不是部署在MUA或提交服务器中。换言之，签名和验证算法通常在电子邮件经过打包、转换并准备好通过SMTP在互联网上传输后应用，因此电子邮件随后被修改的可能性降低。
Nonetheless, empirical evidence suggests 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 senders, mild modification of email is immaterial to the authentication status of the email. For such senders, a canonicalization algorithm that survives modest in-transit modification is preferred.
对这种修改有两种相互矛盾的观点。对于大多数发件人，对电子邮件的轻微修改对电子邮件的身份验证状态无关紧要。对于这样的发送者，最好使用一种能够在传输过程中进行适度修改的规范化算法。
For other senders however, any modification of the email - however minor -- results in a desire for the authentication to fail. In other words, such senders do not want a modified email to be seen as being authorized by them. These senders prefer a canonicalization algorithm that does not tolerate in-transit modification of the signed email.
然而，对于其他发件人，对电子邮件的任何修改——无论多么微小——都会导致认证失败。换句话说，这类发件人不希望修改后的电子邮件被视为是他们授权的。这些发件人更喜欢规范化算法，该算法不允许在传输过程中修改已签名的电子邮件。
To satisfy both requirements, two canonicalization algorithms are defined. A "simple" algorithm that tolerates almost no modification and a "nofws" algorithm that tolerates common modifications as whitespace replacement and header line rewrapping.
为了满足这两个要求，定义了两种规范化算法。一种“简单”算法，几乎不允许任何修改；一种“nofws”算法，允许常见的修改，如空格替换和标题行重写。
A sender may choose either algorithm when signing an email. A verifier MUST be able to process email using either algorithm.
发件人在签署电子邮件时可以选择其中一种算法。验证器必须能够使用任一算法处理电子邮件。
Either algorithm can be used in conjunction with the "h" tag in the "DomainKey-Signature:" header.
这两种算法都可以与“DomainKey Signature:”标头中的“h”标记结合使用。
Canonicalization simply prepares the email for the signing or verification algorithm. It does not change the transmitted data in any way.
规范化只是为签名或验证算法准备电子邮件。它不会以任何方式改变传输的数据。
o Each line of the email is presented to the signing algorithm in the order it occurs in the complete email, from the first line of the headers to the last line of the body.
o 电子邮件的每一行都按照其在完整电子邮件中出现的顺序呈现给签名算法，从标题的第一行到正文的最后一行。
o If the "h" tag is used, only those header lines (and their continuation lines if any) added to the "h" tag list are included.
o 如果使用“h”标记，则仅包括添加到“h”标记列表中的标题行（及其续行，如果有）。
o The "h" tag only constrains header lines. It has no bearing on body lines, which are always included.
o “h”标记仅约束标题行。它与车身线条无关，车身线条始终包含在内。
o Remove any local line terminator.
o 移除任何本地线路终端。
o Append CRLF to the resulting line.
o 将CRLF追加到结果行。
o All trailing empty lines are ignored. An empty line is a line of zero length after removal of the local line terminator.
o 将忽略所有尾随的空行。空行是移除本地行终止符后长度为零的行。
If the body consists entirely of empty lines, then the header/body line is similarly ignored.
如果正文完全由空行组成，则标题/正文行同样被忽略。
The "No Folding Whitespace" algorithm (nofws) is more complicated than the "simple" algorithm for two reasons; folding whitespace is removed from all lines and header continuation lines are unwrapped.
由于两个原因，“无折叠空白”算法（nofws）比“简单”算法更复杂；从所有行中删除折叠空白，并展开页眉延续行。
o Each line of the email is presented to the signing algorithm in the order it occurs in the complete email, from the first line of the headers to the last line of the body.
o 电子邮件的每一行都按照其在完整电子邮件中出现的顺序呈现给签名算法，从标题的第一行到正文的最后一行。
o Header continuation lines are unwrapped so that header lines are processed as a single line.
o 标题连续行被展开，以便标题行作为一行处理。
o If the "h" tag is used, only those header lines (and their continuation lines if any) added to the "h" tag list are included.
o 如果使用“h”标记，则仅包括添加到“h”标记列表中的标题行（及其续行，如果有）。
o The "h" tag only constrains header lines. It has no bearing on body lines, which are always included.
o “h”标记仅约束标题行。它与车身线条无关，车身线条始终包含在内。
o For each line in the email, remove all folding whitespace characters. Folding whitespace is defined in RFC 2822 as being the decimal ASCII values 9 (HTAB), 10 (NL), 13 (CR), and 32 (SP).
o 对于电子邮件中的每一行，删除所有折叠空白字符。RFC 2822将折叠空格定义为十进制ASCII值9（HTAB）、10（NL）、13（CR）和32（SP）。
o Append CRLF to the resulting line.
o 将CRLF追加到结果行。
o Trailing empty lines are ignored. An empty line is a line of zero length after removal of the local line terminator. Note that the test for an empty line occurs after removing all folding whitespace characters.
o 将忽略尾随的空行。空行是移除本地行终止符后长度为零的行。请注意，空行测试是在删除所有折叠空白字符后进行的。
If the body consists entirely of empty lines, then the header/body line is similarly ignored.
如果正文完全由空行组成，则标题/正文行同样被忽略。
The previous sections defined the various components and mechanisms needed to sign an email. This section brings those together to define the complete process of signing an email.
前几节定义了签署电子邮件所需的各种组件和机制。本节将这些内容结合在一起，以定义签署电子邮件的完整过程。
A signer MUST only sign email from submissions that are authorized to use the sending address.
签名者必须仅对授权使用发送地址的提交的电子邮件进行签名。
Once authorization of the submission has been determined, the signing process consists of the following steps:
确定提交授权后，签名过程包括以下步骤：
o identifying the sending domain
o 识别发送域
o determining if an email should be signed
o 确定是否应签署电子邮件
o selecting a private key and corresponding selector information
o 选择私钥和相应的选择器信息
o calculating the signature value
o 计算签名值
o prepending the "DomainKey-Signature:" header
o 在“域密钥签名：”头之前
If an email cannot be signed for some reason, it is a local policy decision as to what to do with that email.
如果由于某种原因无法对电子邮件进行签名，则应根据当地政策决定如何处理该电子邮件。
The sending domain is determined by finding the email address in the "Sender:" header, or, if the "Sender:" header is not present, the first email address of the "From:" header is used to determine the sending domain.
通过在“发件人：”标题中查找电子邮件地址来确定发送域，或者，如果“发件人：”标题不存在，则使用“发件人：”标题的第一个电子邮件地址来确定发送域。
If the email has an invalid "From:" or an invalid "Sender:" header, it MUST NOT be signed.
如果电子邮件包含无效的“发件人：”或无效的“发件人：”标题，则不得对其进行签名。
If the signer adds the "h" tag to the "DomainKey-Signature:" header, that tag MUST include the header that was used to determine the sending domain.
如果签名者将“h”标记添加到“DomainKey Signature:”标头，则该标记必须包括用于确定发送域的标头。
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 why a signer may choose not to sign an email.
显然，签名者只能为其拥有私钥以及相应公钥和选择器信息的必要知识的域签名电子邮件，但是签名者可能选择不签名电子邮件还有许多其他原因。
A signer MUST NOT sign an email if the email submission is not authorized to use the sending domain.
如果电子邮件提交未被授权使用发送域，则签名者不得对电子邮件进行签名。
A signer MUST NOT sign an email that already contains a "DomainKey-Signature:" header unless a "Sender:" header has been added that was not included in the original signature. The most obvious case where this occurs is with mailing lists.
签名者不得对已包含“域密钥签名：”标题的电子邮件进行签名，除非添加了原始签名中未包含的“发件人：”标题。最明显的情况是邮件列表。
A signer SHOULD NOT remove an existing "DomainKey-Signature:" header.
签名者不应删除现有的“DomainKey签名：”头。
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.
本规范未定义签名者选择使用哪个私钥和选择器信息的依据。目前，就本规范而言，所有选择器都是平等的，因此决策在很大程度上应该是一个方便管理的问题。
The signer MUST use one of the defined canonicalization algorithms to present the email to the signing algorithm. Canonicalization is only used to prepare the email for signing. It does not affect the transmitted email in any way.
签名者必须使用其中一种已定义的规范化算法将电子邮件呈现给签名算法。规范化仅用于准备用于签名的电子邮件。它不会以任何方式影响发送的电子邮件。
To avoid possible ambiguity, a signing server may choose to remove any pre-existing "DomainKey-Status:" headers from the email prior to preparation for signing and transmission.
为了避免可能的歧义，签名服务器可以选择在准备签名和传输之前从电子邮件中删除任何预先存在的“DomainKey Status:”标题。
The final step in the signing process is that the signer MUST prepend the "DomainKey-Signature:" header prior to continuing with the process of transmitting the email.
签名过程的最后一步是，在继续发送电子邮件之前，签名者必须预先添加“DomainKey Signature:”标题。
While the disposition of inbound email is ultimately a matter for the receiving system, the introduction of authentication in email creates a need for the sender domain to indicate their signing policy and preferred disposition of unsigned email, in particular, whether a domain is participating in DomainKeys, whether it is testing, and whether it signs all outbound email.
虽然入站电子邮件的处置最终是接收系统的一个问题，但电子邮件中引入的身份验证要求发件人域指示其签名策略和未签名电子邮件的首选处置，特别是域是否参与域密钥，是否正在测试，以及是否对所有出站电子邮件进行签名。
The sending domain policy is very simple and is expressed in the _domainkey TXT record in the DNS of the sending domain. For example, in the example.com domain, the record is called _domainkey.example.com.
发送域策略非常简单，在发送域的DNS中的_DomainKeyTXT记录中表示。例如，在example.com域中，记录名为_domainkey.example.com。
The contents of this TXT record are stored as tag=value pairs separated by semicolons, for example, as in the following:
此TXT记录的内容存储为以分号分隔的标记=值对，例如，如下所示：
_domainkey IN TXT "t=y; o=-; n=notes; r=emailAddress"
_domainkey IN TXT "t=y; o=-; n=notes; r=emailAddress"
All tags are optional. The current valid tags are as follows:
所有标签都是可选的。当前的有效标记如下所示：
n = Notes that may be of interest to a human. No interpretation is made by any program.
n=可能对人类感兴趣的注释。任何程序都不会进行解释。
o = Outbound Signing policy ("-" means that this domain signs all email; "~" is the default and means that this domain may sign some email with DomainKeys).
o =出站签名策略（“-”表示此域对所有电子邮件进行签名；“~”是默认值，表示此域可以使用域密钥对某些电子邮件进行签名）。
r = A reporting email address. If present, this defines the email address where invalid verification results are reported. This tag is primarily intended for early implementers -- the content and frequency of the reports will be defined in a separate document.
r=报告电子邮件地址。如果存在，则定义报告无效验证结果的电子邮件地址。这个标签主要用于早期的实现者——报告的内容和频率将在单独的文档中定义。
t = a set of flags that define boolean attributes. Valid attributes are as follows:
t=定义布尔属性的一组标志。有效属性如下所示：
y = testing mode. This domain is testing DomainKeys, and unverified email MUST NOT be treated differently from verified email. Recipient systems MAY wish to track testing mode results to assist the sender).
y=测试模式。此域正在测试域密钥，未经验证的电子邮件不得与已验证的电子邮件区别对待。收件人系统可能希望跟踪测试模式结果以帮助发件人）。
Note that testing mode cannot be turned off by this tag; thus, policy cannot revert the testing mode setting of a Selector.
请注意，此标签不能关闭测试模式；因此，策略无法还原选择器的测试模式设置。
This tag is optional.
此标记是可选的。
(Syntax rules for the tag=value format are discussed in Appendix A.)
（标签=值格式的语法规则见附录A。）
Recipient systems SHOULD only retrieve this policy TXT record to determine policy when an email fails to verify or does not include a signature. Recipient systems SHOULD not retrieve this policy TXT record for email that successfully verifies. Note that "testing mode" SHOULD also be in the Selector TXT record if the domain owner is running a DomainKeys test.
收件人系统应仅在电子邮件无法验证或未包含签名时检索此策略TXT记录以确定策略。收件人系统不应为成功验证的电子邮件检索此策略TXT记录。请注意，如果域所有者正在运行DomainKeys测试，“测试模式”也应该在选择器TXT记录中。
If the policy TXT record does not exist, recipient systems MUST assume the default values.
如果策略TXT记录不存在，则收件人系统必须采用默认值。
There is an important implication when a domain states that it signs all email with the "o=-" setting, namely that the sending domain prefers that the recipient system treat unsigned mail with a great deal of suspicion. Such suspicion could reasonably extend to rejecting such email. A verifying system MAY reject unverified email if a domain policy indicates that it signs all email.
当一个域声明它使用“o=-”设置对所有电子邮件进行签名时，有一个重要的含义，即发送域更希望收件人系统以极大的怀疑态度对待未签名的邮件。这种怀疑可以合理地延伸到拒绝此类电子邮件。如果域策略指示验证系统对所有电子邮件进行签名，则验证系统可能会拒绝未经验证的电子邮件。
Of course, nothing compels a recipient MTA to abide by the policy of the sender. In fact, during the trial, a sending domain would want to be very certain about setting this policy, as processing by recipient MTAs may be unpredictable. Nonetheless, a domain that states that it signs all email MUST expect that unverified email may be rejected by some receiving MTAs.
当然，没有什么能强迫收件人MTA遵守发件人的政策。事实上，在试用期间，发送域希望非常确定设置此策略，因为收件人MTA的处理可能不可预测。尽管如此，声明对所有电子邮件进行签名的域必须预期未经验证的电子邮件可能会被某些接收MTA拒绝。
There is no defined or recommended limit on the lifetime of a selector and corresponding public key; however, it is recommended that verification occur in a timely manner with the most timely place being during acceptance or local delivery by the MTA.
选择器和相应公钥的生命周期没有定义或建议的限制；但是，建议及时进行验证，最及时的地点是MTA验收或本地交付期间。
Verifying a signature consists of the following three steps:
验证签名包括以下三个步骤：
o extract signature information from the headers
o 从标题中提取签名信息
o retrieve the public key based on the signature information
o 根据签名信息检索公钥
o check that the signature verifies against the contents
o 检查签名是否与内容相符
In the event that any of these steps fails, the sending domain policy is ascertained to assist in applying local policy.
如果这些步骤中的任何一个失败，将确定发送域策略以帮助应用本地策略。
Indications from deployment of previous versions of this specification suggest that the canonicalization algorithms in conjunction with the "h" tag in the "DomainKey-Signature:" header allows most email to cryptographically survive intact between signing and verifying.
本规范先前版本的部署表明，规范化算法与“DomainKey Signature:”标题中的“h”标记结合使用，允许大多数电子邮件在签名和验证之间以加密方式完好无损地保存。
The one assumption that most of the early deployments make is that the headers included in the signature are not reordered prior to verification.
大多数早期部署的一个假设是，签名中包含的头在验证之前不会重新排序。
While nothing in this specification precludes a verifier from "looking" for a header that may have been reordered, including being moved to a position prior to the "DomainKey-Signature:" header, such reordered email is unlikely to be successfully verified by most implementations.
虽然本规范中没有任何内容阻止验证器“查找”可能已重新排序的邮件头，包括移动到“DomainKey Signature:”邮件头之前的位置，但大多数实现不可能成功验证这种重新排序的电子邮件。
A second consequence of this assumption -- particularly in the presence of multiple "DomainKey-Signature:" headers -- is that the first "DomainKey-Signature:" header in the email was the last signature added to the email and thus is the one to be verified.
这种假设的第二个结果——特别是在存在多个“域密钥签名：”头的情况下——是电子邮件中的第一个“域密钥签名：”头是添加到电子邮件中的最后一个签名，因此是要验证的签名。
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 recorded; however, in terms of presentation to the end user, the result SHOULD be presented as a simple binary result: either the email is verified or it is not. 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.
出于诊断目的，应记录验证失败的确切原因；但是，就向最终用户的演示而言，结果应以简单的二进制结果呈现：要么电子邮件已验证，要么未验证。如果无法验证电子邮件，则应将其呈现为与所有未经验证的电子邮件相同的内容，无论其看起来是否已签名。
In most cases, a signed email is expected to have just one signature -- that is, one "DomainKey-Signature:" header. However, it is entirely possible that an email can contain multiple signatures. In such cases, a verifier MUST find the most appropriate signature to use and SHOULD ignore all other signatures.
在大多数情况下，一封签名的电子邮件应该只有一个签名——即一个“DomainKey签名：”头。但是，一封电子邮件完全可能包含多个签名。在这种情况下，验证者必须找到最适合使用的签名，并且应该忽略所有其他签名。
The process of finding the most appropriate signature consists of the following "best match" rules. The rules are to be evaluated in order.
寻找最合适签名的过程包括以下“最佳匹配”规则。规则将按顺序进行评估。
1. Selecting the sending domain
1. 选择发送域
If the email contains a "Sender:" header, the sending domain is extracted from the "Sender:" address. If this extraction fails, the email SHALL fail verification.
如果电子邮件包含“发件人：”标题，则发送域将从“发件人：”地址中提取。如果提取失败，电子邮件将无法验证。
If no "Sender:" header is present, the sending domain is extracted from the first address of the "From:" header. If this extraction fails, the email SHALL fail verification.
如果不存在“发件人：”标头，则从“发件人：”标头的第一个地址提取发送域。如果提取失败，电子邮件将无法验证。
2. Domain matching
2. 域匹配
A signature can only match if the sending domain matches the "d" tag domain -- according to the "d" tag subdomain matching rules.
签名只能在发送域与“d”标记域匹配时匹配——根据“d”标记子域匹配规则。
3. "h" tag matching
3. “h”标记匹配
If the signature contains the "h" tag list of headers, that list must include the header used to extract the sending domain in rule 1, above.
如果签名包含标题的“h”标记列表，则该列表必须包括用于提取上述规则1中发送域的标题。
4. Most secure signing algorithm
4. 最安全的签名算法
While it is not yet the case, in the event that additional algorithms are added to this specification, a verifier MUST use the signature that contains the most secure algorithm as defined by the future specification. For current implementations, that means verifiers MUST ignore signatures that are coded with an unrecognized signing algorithm.
虽然还不是这样，但如果在本规范中添加了其他算法，验证者必须使用包含未来规范定义的最安全算法的签名。对于当前的实现，这意味着验证器必须忽略使用无法识别的签名算法编码的签名。
5. Earlier signatures are preferred
5. 优先选择较早的签名
If multiple signatures are equal as far as these rules apply, the signature from the earlier header MUST be used in preference to later signature headers.
如果根据这些规则，多个签名是相等的，则必须优先使用前一个签名头中的签名，而不是后一个签名头。
Implementors MUST meticulously validate the format and values in the "DomainKey-Signature:" header; any inconsistency or unexpected values MUST result in ignoring that header. Being "liberal in what you accept" is definitely a bad strategy in this security context.
实现者必须仔细验证“DomainKey签名：”头中的格式和值；任何不一致或意外的值都必须导致忽略该标头。在这种安全环境下，“在你接受的东西上自由”绝对是一种糟糕的策略。
In all cases, if a verification fails, the "DomainKey-Status:" header SHOULD be generated and include a message to help explain the reason for failure.
在所有情况下，如果验证失败，则应生成“DomainKey Status:”标头，并包含一条消息以帮助解释失败的原因。
The public key 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 "DomainKey-Signature:" header line. Obviously, a public key should only be retrieved if the process of extracting the signature information is completely successful.
完成验证过程需要公钥。检索公钥的过程取决于“DomainKey Signature:”标题行中“q”标记定义的查询类型。显然，只有在提取签名信息的过程完全成功的情况下，才应该检索公钥。
Currently, the only valid query type is "dns". The public key retrieval process for this type is as follows:
目前，唯一有效的查询类型是“dns”。此类型的公钥检索过程如下所示：
1. Using the selector name defined by the "s" tag, the "_domainkey" namespace and the domain name defined by the "d" tag, construct and issue the DNS TXT record query string.
1. 使用“s”标记定义的选择器名称、“\u domainkey”命名空间和“d”标记定义的域名，构造并发出DNS TXT记录查询字符串。
For example, if s=brisbane and d=example.net, the query string is "brisbane._domainkey.example.net".
例如，如果s=brisbane和d=example.net，则查询字符串为“brisbane.\u domainkey.example.net”。
2. If the query for the public key fails to respond, the verifier SHOULD defer acceptance of this email (normally this will be achieved with a 4XX SMTP response code).
2. 如果对公钥的查询没有响应，验证者应该推迟接受此电子邮件（通常通过4XX SMTP响应代码实现）。
3. If the query for the public key fails because the corresponding data does not exist, the verifier MUST treat the email as unverified.
3. 如果公钥查询失败，因为相应的数据不存在，验证器必须将电子邮件视为未验证。
4. If the result returned from the query does not adhere to the format defined in this specification, the verifier MUST treat the email as unverified.
4. 如果查询返回的结果不符合本规范中定义的格式，验证人必须将电子邮件视为未验证。
5. If the public key data is not suitable for use with the algorithm type defined by the "a" tag in the "DomainKey-Signature:" header, the verifier MUST treat the email as unverified.
5. 如果公钥数据不适合与“DomainKey Signature:”标题中的“a”标记定义的算法类型一起使用，则验证者必须将电子邮件视为未验证。
Implementors MUST meticulously validate the format and values returned by the public key query. Any inconsistency or unexpected values MUST result in an unverified email. Being "liberal in what you accept" is definitely a bad strategy in this security context.
实现者必须仔细验证公钥查询返回的格式和值。任何不一致或意外值都必须导致未经验证的电子邮件。在这种安全环境下，“在你接受的东西上自由”绝对是一种糟糕的策略。
Latency critical implementations may wish to initiate the public key query in parallel with calculating the SHA-1 hash, as the public key is not needed until the final RSA is calculated.
延迟关键型实现可能希望在计算SHA-1哈希的同时启动公钥查询，因为在计算最终RSA之前不需要公钥。
Armed with the signature information from the "DomainKey-Signature:" header and the public key information returned by the query, the signature of the email can now be verified.
通过使用“DomainKey signature:”标题中的签名信息和查询返回的公钥信息，现在可以验证电子邮件的签名。
The canonicalization algorithm defined by the "c" tag in the "DomainKey-Signature:" header defines how the data is prepared for the verification algorithm, and the "a" tag in the same header defines which verification algorithm to use.
“DomainKey Signature:”标头中的“c”标记定义的规范化算法定义了如何为验证算法准备数据，同一标头中的“a”标记定义了要使用的验证算法。
In the event that an email fails to verify, the policy of the sending domain MUST be consulted. For now, that means consulting the _domainkey TXT record in the DNS of the domain in the sending domain as defined in Section 3.5.1. For example, if example.net is the sending domain the TXT query is:
如果电子邮件无法验证，则必须咨询发送域的策略。目前，这意味着在第3.5.1节中定义的发送域的域的DNS中查询_domainkeytxt记录。例如，如果example.net是发送域，则TXT查询为：
_domainkey.example.net
_domainkey.example.net
A verifier SHOULD consider the sending domain policy statement and act accordingly. The range of possibilities is up to the receiver, but it MAY include rejecting the email.
验证者应考虑发送域策略语句并相应地采取行动。可能的范围取决于接收者，但可能包括拒绝电子邮件。
After all verification processes are complete, the recipient system has authentication information that can help it decide what to do with the email.
在所有验证过程完成后，收件人系统具有身份验证信息，可以帮助其决定如何处理电子邮件。
It is beyond the scope of this specification to describe what actions a recipient system should take, 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 not unreasonable to treat unauthenticated email as lacking any trust and having no positive reputation.
相反，未经验证的电子邮件缺少可用于分配信任和声誉的可靠标识符。将未经验证的电子邮件视为缺乏信任和没有正面声誉并非不合理。
Apart from the application of automated policy, the result of a signature verification should be conveyed to the user reading the email.
除了应用自动策略外，还应将签名验证的结果传达给阅读电子邮件的用户。
Most email clients can be configured to recognize specific headers and apply simple rules, e.g., filing into a particular folder. Since DomainKey signatures are expected to be initially verified at the border MTA, the results of the verification need to be conveyed to the email client. This is done with the "DomainKey-Status:" header line prepended to the email.
大多数电子邮件客户端可以配置为识别特定的标题并应用简单的规则，例如，归档到特定的文件夹中。由于域密钥签名最初需要在边界MTA进行验证，因此需要将验证结果传送到电子邮件客户端。这是通过电子邮件前面的“DomainKey Status:”标题行完成的。
The "DomainKey-Status:" header starts with a string that indicate the result of the verification. Valid values are as follows:
“DomainKey Status:”标头以一个字符串开头，该字符串指示验证结果。有效值如下所示：
"good" - the signature was verified at the time of testing "bad" - the signature failed the verification "no key" - the public key query failed as the key does not exist "revoked" - the public key query failed as the key has been revoked "no signature" - this email has no "DomainKey-Signature:" header "bad format" - the signature or the public key contains unexpected data "non-participant" - this sending domain has indicated that it does not participate in DomainKeys
“好”-在测试“坏”时验证了签名-签名未通过验证“无密钥”-公钥查询失败，因为密钥不存在“已撤销”-公钥查询失败，因为密钥已撤销“无签名”-此电子邮件没有“域密钥签名：”标题“坏格式”-签名或公钥包含意外数据“非参与者”-此发送域已指示它不参与域密钥
Verifiers may append additional data that expands on the reason for the particular status value.
验证器可以附加附加附加数据，扩展特定状态值的原因。
A client SHOULD just look for "good" and assume that all other values imply that the verification could not be performed for some reason. Policy action as a consequence of this header is entirely a local matter.
客户应该只寻找“好”，并假设所有其他值都意味着由于某种原因无法执行验证。此标题导致的政策行动完全是本地事务。
Here are some examples:
以下是一些例子：
DomainKey-Status: good DomainKey-Status: bad format
域密钥状态：良好域密钥状态：格式错误
Although it is expected that MTAs will be DomainKey aware before MUAs, it is nonetheless possible that a DomainKey-aware MUA can be fooled by a spoofed "DomainKey-Status:" header that passes through a non-DomainKey-aware MTA.
虽然预计MTA在MUA之前会具有域密钥意识，但有可能会被通过非域密钥意识MTA的伪造“域密钥状态：”头愚弄。
If this is perceived to be a serious problem, then it may make sense to preclude the "good" value and only have values that effectively demote the email as far as the UA is concerned. That way successful spoofing attempts can only serve to demote themselves.
如果这被认为是一个严重的问题，那么排除“良好”价值是有意义的，并且就UA而言，只有有效降低电子邮件级别的价值。这样，成功的欺骗尝试只能使自己降级。
This section shows the complete flow of an email from submission to final delivery, demonstrating how the various components fit together.
本节展示了电子邮件从提交到最终交付的完整流程，演示了各种组件如何组合在一起。
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 football.example.com outbound email server and now looks like this:
此电子邮件由football.example.com出站电子邮件服务器签名，现在看起来如下：
DomainKey-Signature: a=rsa-sha1; s=brisbane; d=football.example.com;
c=simple; q=dns;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR;
Received: from dsl-10.2.3.4.football.example.com [10.2.3.4]
by submitserver.football.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>
DomainKey-Signature: a=rsa-sha1; s=brisbane; d=football.example.com;
c=simple; q=dns;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR;
Received: from dsl-10.2.3.4.football.example.com [10.2.3.4]
by submitserver.football.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. Distribution and management of private keys are outside the scope of this document.
签名电子邮件服务器需要访问与“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.
签名通常由入站SMTP服务器或最终传递代理进行验证。但是，如果介入MTA选择执行此验证，则它们也可以执行此验证。
The verification process uses the domain "football.example.com" extracted from the "From:" header and the selector "brisbane" from the "DomainKey-Signature:" header to form the DNS TXT query for:
验证过程使用从“from:”标头中提取的域“football.example.com”和从“DomainKey Signature:”标头中提取的选择器“brisbane”来形成DNS TXT查询：
brisbane._domainkey.football.example.com
布里斯班。_domainkey.football.example.com
Since there is no "h" tag in the "DomainKey-Signature:" header, signature verification starts with the line following the "DomainKey-Signature:" line. The email is canonically prepared for verifying with the "simple" method.
由于“DomainKey Signature:”标头中没有“h”标记，因此签名验证从“DomainKey Signature:”行后面的行开始。这封电子邮件是为使用“简单”方法进行验证而准备的。
The result of the query and subsequent verification of the signature is stored in the "DomainKey-Status:" header line. After successful verification, the email looks like this:
查询和随后签名验证的结果存储在“DomainKey Status:”标题行中。成功验证后，电子邮件如下所示：
DomainKey-Status: good
from=joe@football.example.com; domainkeys=pass
Received: from mout23.brisbane.football.example.com (192.168.1.1)
by shopping.example.net with SMTP;
Fri, 11 Jul 2003 21:01:59 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; s=brisbane; d=football.example.com;
c=simple; q=dns;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR;
Received: from dsl-10.2.3.4.network.example.com [10.2.3.4]
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>
DomainKey-Status: good
from=joe@football.example.com; domainkeys=pass
Received: from mout23.brisbane.football.example.com (192.168.1.1)
by shopping.example.net with SMTP;
Fri, 11 Jul 2003 21:01:59 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; s=brisbane; d=football.example.com;
c=simple; q=dns;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR;
Received: from dsl-10.2.3.4.network.example.com [10.2.3.4]
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.
乔。
A fundamental aspect of DomainKeys is that public keys are generated and advertised by each domain at no additional cost. This accessibility markedly differs from traditional Public Key Infrastructures where there is typically a Certificate Authority (CA) who validates an applicant and issues a signed certificate -- containing their public key -- often for a recurring fee.
DomainKeys的一个基本方面是，每个域生成并公布公钥，而不需要额外的成本。这种可访问性明显不同于传统的公钥基础设施，传统的公钥基础设施通常由证书颁发机构（CA）验证申请人，并颁发一个签名证书（包含其公钥），通常收取定期费用。
While CAs do impose costs, they also have the potential to provide additional value as part of their certification process. Consider financial institutions, public utilities, law enforcement agencies, and the like. In many cases, such entities justifiably need to discriminate themselves above and beyond the authentication that DomainKeys offers.
虽然核证机关会增加成本，但它们也有可能在核证过程中提供额外价值。考虑金融机构、公用事业、执法机构等。在许多情况下，这样的实体有理由在域密钥提供的身份验证之外对自己进行区分。
Creating a link between DomainKeys and CA-issued certificates has the potential to access additional authentication mechanisms that are more authoritative than domain-owner-issued authentication. It is well beyond the scope of this specification to describe such authorities apart from defining how the linkage could be achieved with the "DomainKey-X509:" header.
在域密钥和CA颁发的证书之间创建链接有可能访问比域所有者颁发的认证更权威的其他认证机制。除了定义如何使用“DomainKey-X509：”标头实现链接外，描述此类权限远远超出了本规范的范围。
The "DomainKey-X509:" header provides a link between the public key used to sign the email and the certificate issued by a CA.
“DomainKey-X509:”标头提供用于签署电子邮件的公钥与CA颁发的证书之间的链接。
The exact content, syntax, and semantics of this header are yet to be resolved. One possibility is that this header contains an encoding of the certificate issued by a CA. Another possibility is that this header contains a URL that points to a certificate issued by a CA.
此标题的确切内容、语法和语义尚待解决。一种可能是此标头包含CA颁发的证书的编码。另一种可能是此标头包含指向CA颁发的证书的URL。
In either case, this header can only be consulted if the signature verifies and MUST be part of the content signed by the corresponding "DomainKey-Signature:" header. Furthermore, it is likely that MUAs rather than MTAs will confirm that the link to the CA-issued certificate is valid. In part, this is because many MUAs already have built-in capabilities as a consequence of Secure/Multipurpose Internet Mail Extensions (S/MIME) [SMIME] and Secure Socket Layer (SSL) [SSL] support.
在任何一种情况下，只有签名经过验证并且必须是由相应的“DomainKey签名：”标头签名的内容的一部分时，才能查阅此标头。此外，MUA而不是MTA可能会确认指向CA颁发的证书的链接是有效的。部分原因是，由于安全/多用途Internet邮件扩展（S/MIME）[SMIME]和安全套接字层（SSL）[SSL]支持，许多MUA已经具有内置功能。
The proof of linkage is made by testing that the public key in the certificate matches the public key used to sign the email.
通过测试证书中的公钥是否与用于签署电子邮件的公钥相匹配来证明链接。
An example of an email containing the "DomainKey-X509:" header is:
包含“DomainKey-X509：”标题的电子邮件示例如下：
DomainKey-Signature: a=rsa-sha1; s=statements;
d=largebank.example.com; c=simple; q=dns;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR;
DomainKey-X509: https://ca.example.net/largebank.example.com
From: "Large Bank" <statements@largebank.example.com>
To: "Suzie Q" <suzie@shopping.example.net>
Subject: Statement for Account: 1234-5678
...
DomainKey-Signature: a=rsa-sha1; s=statements;
d=largebank.example.com; c=simple; q=dns;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR;
DomainKey-X509: https://ca.example.net/largebank.example.com
From: "Large Bank" <statements@largebank.example.com>
To: "Suzie Q" <suzie@shopping.example.net>
Subject: Statement for Account: 1234-5678
...
The format of the retrieved value from the URL is not yet defined, nor is the determination of valid CAs.
从URL检索的值的格式尚未定义，有效CA的确定也尚未定义。
The whole matter of linkage to CA-issued certificates is one aspect of DomainKeys that needs to be resolved with relevant CA's and certificate-issuing entities. The primary point is that a link is possible to a higher authority.
与CA颁发的证书的链接是域密钥的一个方面，需要与相关CA和证书颁发实体一起解决。主要的一点是，链接到更高的权限是可能的。
Selectors are at the heart of the flexibility of DomainKeys. A domain administrator is free to use a single DomainKey for all outbound mail. Alternatively, the domain administrator may use many DomainKeys differentiated by selector and assign each key to different servers.
选择器是域键灵活性的核心。域管理员可以对所有出站邮件自由使用单个域密钥。或者，每个域管理员可以使用不同的域密钥选择器为每个域服务器分配不同的域密钥。
For example, a large outbound email farm might have a unique DomainKey for each server, and thus their DNS will advertise potentially hundreds of keys via their unique selectors.
例如，一个大型出站电子邮件场可能会为每台服务器提供一个唯一的域密钥，因此其DNS将通过其唯一的选择器播发数百个密钥。
Another example is a corporate email administrator who might generate a separate DomainKey for each regional office email server.
另一个例子是公司电子邮件管理员，他可能会为每个地区办公室电子邮件服务器生成单独的域密钥。
In essence, selectors allow a domain owner to distribute authority to send on behalf of that domain. Combined with the ability to revoke by removal or Time to Live (TTL) expiration, a domain owner has coarse-grained control over the duration of the distributed authority.
本质上，选择器允许域所有者分配代表该域发送的权限。结合通过删除或生存时间（TTL）过期进行撤销的能力，域所有者可以粗粒度地控制分布式权限的持续时间。
Selectors are particularly useful for domain owners who want to contract a third-party mailing system to send a particular set of mail. The domain owner can generate a special key pair and selector just for this mail-out. The domain owner has to provide the private key and selector to the third party for the life of the mail-out.
选择器对于希望与第三方邮件系统签约以发送特定邮件集的域所有者特别有用。域所有者可以仅为此邮件输出生成一个特殊的密钥对和选择器。域所有者必须在邮件发送的整个过程中向第三方提供私钥和选择器。
However, as soon as the mail-out is completely delivered, the domain owner can revoke the public key by the simple expedient of removing the entry from the DNS.
但是，一旦邮件发送完成，域所有者就可以通过从DNS中删除条目的简单方法来撤销公钥。
It is an unfortunate fact that some email software routinely (and often unnecessarily) transforms email as it transits through the network. Such transformations conflict with the fundamental purpose of cryptographic signatures - to detect modifications.
不幸的是，一些电子邮件软件在电子邮件通过网络传输的过程中经常（而且常常是不必要的）转换电子邮件。这种转换与加密签名的基本目的——检测修改——相冲突。
While two canonicalization algorithms are defined in this specification, the primary goal of "nofws" is to provide a transition path to "simple". With a mixture of "simple" and "nofws" email, a receiver can determine which systems are modifying email in ways that cause the signature to fail and thus provide feedback to the modifying system.
虽然本规范中定义了两种规范化算法，“nofws”的主要目标是提供到“simple”的过渡路径。通过混合使用“简单”和“nofws”电子邮件，接收者可以确定哪些系统正在以导致签名失败的方式修改电子邮件，从而向修改系统提供反馈。
Integrating existing Mailing List Managers (MLMs) into the DomainKeys authentication system is a complicated area, as the behavior of MLMs is highly variable. Essentially, there are two types of MLMs under consideration: those that modify email to such an extent that verification of the original content is not possible, and those that make minimal or no modifications to an email.
将现有邮件列表管理器（MLM）集成到域密钥身份验证系统是一个复杂的领域，因为MLM的行为是高度可变的。基本上，有两种类型的传销正在考虑之中：一种是修改电子邮件，以至于无法验证原始内容的传销，另一种是对电子邮件进行最小修改或不修改的传销。
MLMs that modify email in a way that causes verification to fail MUST prepend a "Sender:" header and SHOULD prepend a "List-ID:" header prior to signing for distribution to list recipients.
以导致验证失败的方式修改电子邮件的传销商必须在签名分发给列表收件人之前，预先添加“发件人：”标题，并应在签名前添加“列表ID:”标题。
A participating SUBMISSION server can deduce the need to re-sign such an email by the presence of a "Sender:" or "List-ID:" header from an authorized submission.
参与提交的服务器可以从授权提交的“发件人：”或“列表ID:”标题中推断出重新签署此类电子邮件的需要。
MLMs that do not modify email in a way that causes verification to fail MAY perform the same actions as a modifying MLM.
未以导致验证失败的方式修改电子邮件的传销可能会执行与修改传销相同的操作。
One scenario that presents a particular problem with any form of email authentication, including DomainKeys, is the roving user: a user who is obliged to use a third-party SUBMISSION service when unable to connect to the user's own SUBMISSION service. The classic example cited is a traveling salesperson being redirected to a hotel email server to send email.
任何形式的电子邮件身份验证（包括域密钥）都存在一个特殊问题的场景是漫游用户：当无法连接到用户自己的提交服务时，必须使用第三方提交服务的用户。引用的经典示例是一名旅行推销员被重定向到酒店电子邮件服务器发送电子邮件。
As far as DomainKeys is concerned, email of this nature clearly originates from an email server that does not have authority to send on behalf of the domain of the salesperson and is therefore indistinguishable from a forgery. While DomainKeys does not prescribe any specific action for such email, it is likely that over time, such email will be treated as second-class email.
就DomainKeys而言，这种性质的电子邮件显然来源于电子邮件服务器，该服务器无权代表销售人员的域发送，因此无法与伪造邮件区分开来。虽然DomainKeys没有规定此类电子邮件的任何具体操作，但随着时间的推移，此类电子邮件可能会被视为二级电子邮件。
The typical solution offered to roving users is to submit email via an authorized server for their domain -- perhaps via a Virtual Private Network (VPN) or a web interface or even SMTP AUTH back to a SUBMISSION server.
为流动用户提供的典型解决方案是通过其域的授权服务器提交电子邮件——可能通过虚拟专用网络（VPN）或web界面，甚至SMTP身份验证返回到提交服务器。
While these are perfectly acceptable solutions for many, they are not necessarily solutions that are available or possible for all such users.
虽然这些解决方案对许多人来说是完全可以接受的，但它们不一定对所有此类用户都可用或可能。
One possible way to address the needs of this contingent of potentially disenfranchised users is for the domain to issue per-user DomainKeys. Per-user DomainKeys are identified by a non-empty "g" tag value in the corresponding DNS record.
解决这一潜在被剥夺权利的用户的需求的一种可能的方法是域为每个用户颁发域密钥。每个用户域密钥由相应DNS记录中的非空“g”标记值标识。
DomainKeys is primarily a security mechanism. Its core purpose is to make claims about email authentication in a credible way. However, DomainKeys, like virtually all Internet applications, relies on the DNS, which has well-known security flaws [RFC3833].
域密钥主要是一种安全机制。它的核心目的是以可信的方式提出有关电子邮件身份验证的主张。然而，与几乎所有的互联网应用程序一样，域密钥依赖于DNS，DNS存在众所周知的安全缺陷[RFC3833]。
While the DNS is currently insecure, it is expected that the security problems should and will be solved by DNS Security (DNSSEC) [DNSSEC], and all users of the DNS will reap the benefit of that work.
虽然DNS目前不安全，但预计安全问题应该也将由DNS安全（DNSSEC）[DNSSEC]解决，DNS的所有用户都将从这项工作中获益。
Secondly, the types of DNS attacks relevant to DomainKeys are very costly and are far less rewarding than DNS attacks on other Internet applications.
其次，与域密钥相关的DNS攻击类型成本非常高，并且远不如对其他互联网应用程序的DNS攻击有益。
To systematically thwart the intent of DomainKeys, an attacker must conduct a very costly and very extensive attack on many parts of the DNS over an extended period. No one knows for sure how attackers will respond; however, the cost/benefit of conducting prolonged DNS attacks of this nature is expected to be uneconomical.
为了系统性地挫败域密钥的意图，攻击者必须在较长的时间内对DNS的许多部分进行代价高昂且范围广泛的攻击。没有人确切知道攻击者会如何反应；然而，进行这种性质的长期DNS攻击的成本/收益预计是不经济的。
Finally, DomainKeys is only intended as a "sufficient" method of proving authenticity. It is not intended to provide strong
最后，DomainKeys仅用于证明真实性的“充分”方法。其目的不是提供强大的
cryptographic proof about authorship or contents. Other technologies such as GnuPG and S/MIME address those requirements.
关于作者或内容的加密证明。其他技术，如GnuPG和S/MIME，可以满足这些需求。
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 sending domain policy. Widespread deployment of DomainKeys will result in a significant increase in DNS queries to the claimed sending domain. In the case of forgeries on a large scale, DNS servers could see a substantial increase in queries.
与DNS相关的第二个安全问题是，由于获取基于选择器的数据以及获取发送域策略，导致DNS流量增加。域密钥的广泛部署将导致对声称的发送域的DNS查询显著增加。在大规模伪造的情况下，DNS服务器可以看到查询量的大幅增加。
All public key systems require management of key pairs. Private keys in particular need to be securely distributed to each signing mail server and protected on those servers. For those familiar with SSL, the key management issues are similar to those of managing SSL certificates. Poor key management may result in unauthorized access to private keys, which in essence gives unauthorized access to your identity.
所有公钥系统都需要对密钥对进行管理。私钥尤其需要安全地分发到每个签名邮件服务器，并在这些服务器上受到保护。对于熟悉SSL的人来说，密钥管理问题与管理SSL证书的问题类似。糟糕的密钥管理可能会导致未经授权访问私钥，这实际上会导致未经授权访问您的身份。
It is well recognized in cryptographic circles that many security failures are caused by poor implementations rather than poor algorithms. For example, early SSL implementations were vulnerable because the implementors used predictable "random numbers".
密码学界公认，许多安全性故障是由糟糕的实现而不是糟糕的算法造成的。例如，早期的SSL实现容易受到攻击，因为实现者使用可预测的“随机数”。
While some MTA software already supports various cryptographic techniques, such as TLS, many do not. This proposal introduces cryptographic requirements into MTA software that implies a much higher duty of care to manage the increased risk.
虽然一些MTA软件已经支持各种加密技术，如TLS，但许多MTA软件并不支持。该提案在MTA软件中引入了加密要求，这意味着管理增加的风险的更高的注意义务。
There are numerous articles, books, courses, and consultants that help programming security applications. Potential implementors are strongly encouraged to avail themselves of all possible resources to ensure secure implementations.
有许多文章、书籍、课程和顾问帮助编写安全应用程序。强烈鼓励潜在的实施者利用所有可能的资源来确保安全实施。
Some people believe that they can achieve anonymity by using an email forwarding service. While this has never been particularly true, as bounces, over-quota messages, vacation messages, and web bugs all conspire to expose IP addresses and domain names associated with the delivery path, the DNS queries that are required to verify DomainKeys signature can provide additional information to the sender.
有些人相信，他们可以通过使用电子邮件转发服务实现匿名。虽然这从来都不是特别正确的，因为反弹、超配额消息、假期消息和web bug都合谋公开与传递路径相关的IP地址和域名，但验证域密钥签名所需的DNS查询可以向发送方提供额外的信息。
In particular, as mail is forwarded through the mail network, the DNS queries for the selector will typically identify the DNS cache used by the forwarding and delivery MTAs.
特别是，当邮件通过邮件网络转发时，选择器的DNS查询通常会标识转发和传递MTA使用的DNS缓存。
Verifying a signature is computationally significant. Early indications are that a typical mail server can expect to increase CPU demands by 8-15 percent. While this increased demand is modest compared to other common mail processing costs -- such as Bayesian filtering -- any increase in resource requirements can make a denial-of-service attack more effective against a mail system.
验证签名在计算上具有重要意义。早期迹象表明，一个典型的邮件服务器可能会增加8-15%的CPU需求。虽然与其他常见的邮件处理成本（如贝叶斯过滤）相比，这种需求的增加是适度的，但资源需求的任何增加都可以使拒绝服务攻击对邮件系统更有效。
A constraining factor of such attacks is that the net computational cost of verifying is bounded by the maximum key size allowed by this specification and is essentially linear to the rate at which mail is accepted by the verifying system. Consequently, the additional computational cost may augment a denial-of-service attack, but it does not add a non-linear component to such attacks.
此类攻击的一个限制因素是，验证的净计算成本受本规范允许的最大密钥大小限制，并且基本上与验证系统接受邮件的速率成线性关系。因此，额外的计算成本可能会增加拒绝服务攻击，但不会为此类攻击添加非线性组件。
The DomainKeys protocol was deployed as a trial to better understand the implications of deploying wide-scale cryptographic email authentication.
DomainKeys协议是作为一项试验部署的，以更好地理解部署大规模加密电子邮件身份验证的含义。
Open Source implementations were made available at various places, particularly Source Forge [SOURCEFORGE], which includes links to numerous implementations, both Open Source and commercial.
开源实现在不同的地方都可以使用，特别是SOURCEFORGE[SOURCEFORGE]，它包括许多开源和商业实现的链接。
The primary goals of the trial were to:
试验的主要目标是：
o understand the operational implications of running a DNS-based public key system for email
o 了解运行基于DNS的电子邮件公钥系统的操作含义
o measure the effectiveness of the canonicalization algorithms
o 衡量规范化算法的有效性
o experiment with possible per-user key deployment models
o 尝试可能的每用户密钥部署模型
o fully define the semantics of the "DomainKey-X509:" header
o 完全定义“DomainKey-X509:”标头的语义
The DomainKeys trial ran for approximately 2 years, in which time numerous large ISPs and many thousands of smaller domains participated in signing or verifying with DomainKeys. The low order numbers are that at least one billion DomainKey signed emails transit the Internet each day between some 12,000 participating domains.
DomainKeys试验运行了大约2年，其间有许多大型ISP和数千个较小的域参与了DomainKeys的签名或验证。排名靠后的数字是，每天至少有10亿封域密钥签名电子邮件在约12000个参与域之间通过互联网传输。
The operational and development experience of that trial was applied to DKIM.
该试验的运行和开发经验应用于DKIM。
The DNS is very flexible in that it is possible to have multiple TXT records for a single name and for those TXT records to contain multiple strings.
DNS非常灵活，一个名称可以有多个TXT记录，这些TXT记录可以包含多个字符串。
In all cases, implementors of DomainKeys should expect a single TXT record for any particular name. If multiple TXT records are returned, the implementation is free to pick any single TXT record as the authoritative data. In other words, if a name server returns different TXT records for the same name, it can expect unpredictable results.
在所有情况下，DomainKeys的实现者都应该期望任何特定名称都有一个TXT记录。如果返回多个TXT记录，则实现可以自由选择任何单个TXT记录作为权威数据。换句话说，如果名称服务器为同一名称返回不同的TXT记录，则可能会出现不可预测的结果。
Within a single TXT record, implementors should concatenate multiple strings in the order presented and ignore string boundaries. Note that a number of popular DNS command-line tools render multiple strings as separately quoted strings, which can be misleading to a novice implementor.
在单个TXT记录中，实现者应该按照显示的顺序连接多个字符串，并忽略字符串边界。请注意，许多流行的DNS命令行工具将多个字符串呈现为单独引用的字符串，这可能会误导新手实现。
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[BASE64]Josefsson，S.，“Base16、Base32和BASE64数据编码”，RFC4648，2006年10月。
[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月。
[PEM] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421 February, 1993.
[PEM]Linn，J.，“互联网电子邮件的隐私增强：第一部分：信息加密和认证程序”，RFC 1421，1993年2月。
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[DKIM]Allman，E.，Callas，J.，Delany，M.，Libbey，M.，Fenton，J.，和M.Thomas，“域密钥识别邮件（DKIM）签名”，RFC 48712007年5月。
[DNSSEC] http://www.ietf.org/html.charters/dnsext-charter.html
[DNSSEC] http://www.ietf.org/html.charters/dnsext-charter.html
[OPENSSL] http://www.openssl.org
[OPENSSL] http://www.openssl.org
[RFC2822] Resnick, P., Editor, "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，编辑，“互联网信息格式”，RFC 2822，2001年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月。
[SMIME] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[SMIME]Ramsdell，B.，Ed.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 38512004年7月。
[SOURCEFORGE] http://domainkeys.sourceforge.net
[SOURCEFORGE] http://domainkeys.sourceforge.net
[SSL] http://wp.netscape.com/security/techbriefs/ssl.html
[SSL] http://wp.netscape.com/security/techbriefs/ssl.html
Appendix A - Syntax Rules for the Tag=Value Format
附录A-标记=值格式的语法规则
A simple tag=value syntax is used to encode data in the response values for DNS queries as well as headers embedded in emails. This section summarized the syntactic rules for this encoding:
简单的tag=value语法用于对DNS查询响应值中的数据以及电子邮件中嵌入的头进行编码。本节总结了此编码的语法规则：
o A tag=value pair consists of three tokens, a "tag", the "=" character, and the "value"
o 标记=值对由三个标记组成，一个“标记”、“=”字符和“值”
o A tag MUST be one character long and MUST be a lowercase alphabetic character
o 标记的长度必须为一个字符，并且必须是小写字母
o Duplicate tags are not allowed
o 不允许重复标记
o A value MUST only consist of characters that are valid in RFC 2822 headers and DNS TXT records and are within the ASCII range of characters from SPACE (0x20) to TILDE (0x7E) inclusive. Values MUST NOT contain a semicolon but they may contain "=" characters.
o 值必须仅包含在RFC 2822头和DNS TXT记录中有效的字符，并且在从空格（0x20）到波浪号（0x7E）的ASCII字符范围内。值不能包含分号，但可以包含“=”字符。
o A tag=value pair MUST be terminated by a semicolon or the end of the data
o 标记=值对必须以分号或数据结尾终止
o Values MUST be processed as case sensitive unless the specific tag description of semantics imply case insensitivity.
o 值必须作为区分大小写的处理，除非语义的特定标记描述暗示不区分大小写。
o Values MAY be zero bytes long
o 值的长度可能为零字节
o Whitespace MAY surround any of the tokens; however, whitespace within a value MUST be retained unless explicitly excluded by the specific tag description. Currently, the only tags that specifically ignore embedded whitespace are the "b" and "h" tags in the "DomainKey-Signature:" header.
o 空格可以围绕任何标记；但是，值中的空格必须保留，除非特定标记描述明确排除。目前，唯一专门忽略嵌入空格的标记是“DomainKey Signature:”标题中的“b”和“h”标记。
o Tag=value pairs that represent the default value MAY be included to aid legibility.
o 标记=表示默认值的值对可以包括在内，以帮助识别。
o Unrecognized tags MUST be ignored
o 必须忽略无法识别的标记
Acknowledgments
致谢
The editor wishes to thank Russ Allbery, Eric Allman, Edwin Aoki, Claus Asmann, Steve Atkins, Jon Callas, Dave Crocker, Michael Cudahy, Jutta Degener, Timothy Der, Jim Fenton, Duncan Findlay, Phillip Hallam-Baker, Murray S. Kucherawy, John Levine, Miles Libbey, David Margrave, Justin Mason, David Mayne, Russell Nelson, Juan Altmayer Pizzorno, Blake Ramsdell, Scott Renfro, the Spamhaus.org team, Malte S. Stretz, Robert Sanders, Bradley Taylor, and Rand Wacker for their valuable suggestions and constructive criticism.
编辑要感谢罗斯·奥尔贝里、埃里克·奥尔曼、埃德温·青木、克劳斯·阿斯曼、史蒂夫·阿特金斯、乔恩·卡拉斯、戴夫·克罗克、迈克尔·库达希、尤塔·德詹、蒂莫西·德、吉姆·芬顿、邓肯·芬德利、菲利普·哈拉姆·贝克、默里·库奇拉维、约翰·莱文、迈尔斯·利比、大卫·马格雷夫、贾斯汀·梅森、大卫·梅恩、拉塞尔·纳尔逊、胡安·阿尔特迈耶·皮佐诺、，Blake Ramsdell、Scott Renfro、Spamhaus.org团队、Malte S.Stratez、Robert Sanders、Bradley Taylor和Rand Wacker，感谢他们的宝贵建议和建设性批评。
Author's Address
作者地址
Mark Delany Yahoo! Inc 701 First Avenue Sunnyvale, CA 95087 USA
马克·德拉尼雅虎！美国加利福尼亚州桑尼维尔第一大道701号公司，邮编95087
EMail: markd+domainkeys@yahoo-inc.com
EMail: markd+domainkeys@yahoo-inc.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编辑功能的资金目前由互联网协会提供。