Network Working Group D. Crocker, Ed.
Request for Comments: 5672 Brandenburg InternetWorking
Updates: 4871 August 2009
Category: Standards Track
Network Working Group D. Crocker, Ed.
Request for Comments: 5672 Brandenburg InternetWorking
Updates: 4871 August 2009
Category: Standards Track
RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update
RFC 4871域密钥识别邮件（DKIM）签名--更新
Abstract
摘要
This document updates RFC 4871, "DomainKeys Identified Mail (DKIM) Signatures". Specifically, the document clarifies the nature, roles, and relationship of the two DKIM identifier tag values that are candidates for payload delivery to a receiving processing module. The Update is in the style of an Errata entry, albeit a rather long one.
本文档更新了RFC 4871，“域密钥识别邮件（DKIM）签名”。具体地说，该文档澄清了两个DKIM标识符标签值的性质、角色和关系，这两个DKIM标识符标签值是有效负载交付到接收处理模块的候选值。更新采用勘误表条目的样式，尽管它相当长。
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. RFC 4871, Abstract . . . . . . . . . . . . . . . . . . . . . . 4
3. RFC 4871, Section 1, Introduction . . . . . . . . . . . . . . 4
4. RFC 4871, Section 2.7, Identity . . . . . . . . . . . . . . . 4
5. RFC 4871, Section 2.8, Identifier . . . . . . . . . . . . . . 5
6. RFC 4871, Section 2.9, Signing Domain Identifier (SDID) . . . 5
7. RFC 4871, Section 2.10, Agent or User Identifier (AUID) . . . 5
8. RFC 4871, Section 2.11, Identity Assessor . . . . . . . . . . 6
9. RFC 4871, Section 3.5, The DKIM-Signature Header Field . . . . 6
10. RFC 4871, Section 3.5, The DKIM-Signature Header Field . . . . 7
11. RFC 4871, Section 3.8, Signing by Parent Domains . . . . . . . 9
12. RFC 4871, Section 3.9, Relationship between SDID and AUID . . 10
13. RFC 4871, Section 6.3, Interpret Results/Apply Local Policy . 11
14. RFC 4871, Section 6.3, Interpret Results/Apply Local Policy . 11
15. RFC 4871, Appendix D, MUA Considerations . . . . . . . . . . . 12
16. Security Considerations . . . . . . . . . . . . . . . . . . . 12
17. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. ABNF Fragments . . . . . . . . . . . . . . . . . . . 13
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. RFC 4871, Abstract . . . . . . . . . . . . . . . . . . . . . . 4
3. RFC 4871, Section 1, Introduction . . . . . . . . . . . . . . 4
4. RFC 4871, Section 2.7, Identity . . . . . . . . . . . . . . . 4
5. RFC 4871, Section 2.8, Identifier . . . . . . . . . . . . . . 5
6. RFC 4871, Section 2.9, Signing Domain Identifier (SDID) . . . 5
7. RFC 4871, Section 2.10, Agent or User Identifier (AUID) . . . 5
8. RFC 4871, Section 2.11, Identity Assessor . . . . . . . . . . 6
9. RFC 4871, Section 3.5, The DKIM-Signature Header Field . . . . 6
10. RFC 4871, Section 3.5, The DKIM-Signature Header Field . . . . 7
11. RFC 4871, Section 3.8, Signing by Parent Domains . . . . . . . 9
12. RFC 4871, Section 3.9, Relationship between SDID and AUID . . 10
13. RFC 4871, Section 6.3, Interpret Results/Apply Local Policy . 11
14. RFC 4871, Section 6.3, Interpret Results/Apply Local Policy . 11
15. RFC 4871, Appendix D, MUA Considerations . . . . . . . . . . . 12
16. Security Considerations . . . . . . . . . . . . . . . . . . . 12
17. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. ABNF Fragments . . . . . . . . . . . . . . . . . . . 13
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14
About the purpose for DKIM, [RFC4871] states:
关于DKIM的目的，[RFC4871]指出：
The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity...
该框架的最终目标是允许签名域声明对消息的责任，从而保护消息签名者身份。。。
Hence, DKIM has a signer that produces a signed message, a verifier that confirms the signature, and an assessor that consumes the validated signing domain. So, the simple purpose of DKIM is to communicate an identifier to a receive-side assessor module. The identifier is in the form of a domain name that refers to a responsible identity. For DKIM to be interoperable and useful, the signer and assessor must share the same understanding of the details about the identifier.
因此，DKIM有一个生成已签名消息的签名者、一个确认签名的验证者和一个使用已验证签名域的评估者。因此，DKIM的简单目的是将标识符传递给接收端评估器模块。该标识符以域名的形式表示，该域名表示责任身份。为了使DKIM具有互操作性和实用性，签名人和评估人必须对标识符的详细信息有相同的理解。
However, the RFC 4871 specification defines two, potentially different, identifiers that are carried in the DKIM-Signature: header field, d= and i=. Either might be delivered to a receiving processing module that consumes validated payload. The DKIM specification fails to clearly define which is the "payload" to be delivered to a consuming module, versus what is internal and merely in support of achieving payload delivery.
然而，RFC4871规范定义了在DKIM签名中携带的两个可能不同的标识符：header字段，d=和i=。任何一个都可能被交付到使用已验证有效负载的接收处理模块。DKIM规范未能明确定义哪些是要交付给消费模块的“有效载荷”，而哪些是内部的，仅用于支持实现有效载荷交付。
This currently leaves signers and assessors with the potential for making different interpretations between the two identifiers and may lead to interoperability problems. A signer could intend one to be used for assessment, and have a different intent in setting the value in the other. However the verifier might choose the wrong value to deliver to the assessor, thereby producing an unintended (and inaccurate) assessment.
目前，这使得签字人和评估人有可能在两个标识符之间做出不同的解释，并可能导致互操作性问题。签名者可能希望其中一个用于评估，并且在设置另一个中的值时有不同的意图。然而，验证人可能选择错误的值交付给评估人，从而产生非预期（且不准确）评估。
This Update resolves that confusion. It defines additional, semantic labels for the two values, clarifies their nature, and specifies their relationship. More specifically, it clarifies that the identifier intended for delivery to the assessor -- such as one that consults a whitelist -- is the value of the "d=" tag. However, this does not prohibit message filtering engines from using the "i=" tag, or any other information in the message's header, for filtering decisions.
此更新解决了这一困惑。它为这两个值定义了附加的语义标签，阐明了它们的性质，并指定了它们之间的关系。更具体地说，它澄清了要交付给评估员的标识符（例如咨询白名单的标识符）是“d=”标记的值。但是，这并不禁止消息过滤引擎使用“i=”标记或消息头中的任何其他信息进行过滤决策。
For signers and verifiers that have been using the i= tag as the primary value that is delivered to the assessor, a software change to using the d= tag is intended.
对于使用i=标记作为交付给评估员的主要值的签名人和验证人，计划将软件更改为使用d=标记。
So, this Update clarifies the formal interface to DKIM, after signature verification has been performed. It distinguishes DKIM's internal signing and verification activity, from its standardized delivery of data to that interface.
因此，在执行签名验证后，此更新澄清了与DKIM的正式接口。它将DKIM的内部签名和验证活动与其向该接口标准化交付数据区分开来。
The focus of the Update is on the portion of DKIM that is much like an API definition. If DKIM is implemented as a software library for use by others, it needs to define what outputs are provided, that is, what data that an application developer who uses the library can expect to obtain as a result of invoking DKIM on a message.
更新的重点是DKIM中与API定义非常相似的部分。如果DKIM被实现为供其他人使用的软件库，则需要定义提供了哪些输出，即使用该库的应用程序开发人员在消息上调用DKIM后可以获得哪些数据。
This Update defines the output of that library to include the yes/no result of the verification and the "d=" value. In other words, it says what (one) identifier was formally specified for use by the signer and whether the use of that identifier has been validated. For a particular library, other information can be provided at the discretion of the library developer, since developers of assessors -- these are the consumers of the DKIM library -- well might want more information than the standardized two pieces of information. However, that standardized set is the minimum that is required to be provided to a consuming module, in order to be able to claim that the library is DKIM compliant.
此更新定义了该库的输出，以包括验证的是/否结果和“d=”值。换句话说，它说明了签字人正式指定使用的（一）个标识符，以及该标识符的使用是否经过验证。对于一个特定的库，其他信息可以由库开发人员自行决定提供，因为评估员的开发人员——他们是DKIM库的消费者——可能需要比标准化的两条信息更多的信息。但是，该标准化集是要求提供给消费模块的最小值，以便能够声明库符合DKIM。
This does not state what the implicit value of "i=" is, relative to "d=". In this context, that fact is irrelevant.
这并没有说明“i=”相对于“d=”的隐式值是什么。在这方面，这一事实无关紧要。
Another example is the difference between the socket interface to TCP versus the TCP protocol itself. There is the activity within the protocol stack, and then there is the activity within in the software libraries that are actually used.
另一个例子是TCP的套接字接口与TCP协议本身之间的区别。在协议栈中有活动，然后在实际使用的软件库中有活动。
NOTE: The text provided here updates [RFC4871]. Text appearing in the "Corrected Text:" replaces text in RFC 4871. Hence, references that appear in the "Original Text:" can be found in RFC 4871, and are not duplicated in this document.
注：此处提供的文本更新了[RFC4871]。“更正文本：”中出现的文本替换RFC 4871中的文本。因此，“原始文本：”中出现的参考文献可在RFC 4871中找到，并且在本文件中不重复。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Original Text:
原文：
The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message,
该框架的最终目标是允许签名域声明对消息的责任，
Corrected Text:
更正文本：
The ultimate goal of this framework is to permit a person, role or organization that owns the signing domain to assert responsibility for a message,
此框架的最终目标是允许拥有签名域的个人、角色或组织声明对消息的责任，
Original Text:
原文：
...permitting a signing domain to claim responsibility
…允许签名域声明责任
Corrected Text:
更正文本：
permitting a person, role, or organization that owns the signing domain to claim responsibility
允许拥有签名域的个人、角色或组织声明责任
Original Text:
原文：
(None. New section. Additional text.)
（无。新章节。附加文本。）
Corrected Text:
更正文本：
A person, role, or organization. In the context of DKIM, examples include author, author's organization, an ISP along the handling path, an independent trust assessment service, and a mailing list operator.
个人、角色或组织。在DKIM的上下文中，示例包括作者、作者的组织、处理路径上的ISP、独立的信任评估服务和邮件列表操作员。
Original Text:
原文：
(None. New section. Additional text.)
（无。新章节。附加文本。）
Corrected Text:
更正文本：
A label that refers to an identity.
指代身份的标签。
Original Text:
原文：
(None. New section. Additional text.)
（无。新章节。附加文本。）
Corrected Text:
更正文本：
A single domain name that is the mandatory payload output of DKIM and that refers to the identity claiming responsibility for introduction of a message into the mail stream. For DKIM processing, the name has only basic domain name semantics; any possible owner-specific semantics are outside the scope of DKIM. It is specified in Section 3.5.
一个域名，是DKIM的强制有效负载输出，指的是声称负责将消息引入邮件流的身份。对于DKIM处理，名称只有基本的域名语义；任何可能的特定于所有者的语义都不在DKIM的范围之内。第3.5节对此进行了规定。
Original Text:
原文：
(None. New section. Additional text.)
（无。新章节。附加文本。）
Corrected Text:
更正文本：
A single identifier that refers to the agent or user on behalf of whom the Signing Domain Identifier (SDID) has taken responsibility. The AUID comprises a domain name and an optional <Local-part>. The domain name is the same as that used for the SDID or is a sub-domain of it. For DKIM processing, the domain name portion of the AUID has only basic domain name semantics; any possible owner-specific semantics are outside the scope of DKIM. It is specified in Section 3.5.
指代签名域标识符（SDID）所代表的代理或用户的单个标识符。AUID包括域名和可选的<Local part>。域名与SDID使用的域名相同，或者是SDID的子域。对于DKIM处理，AUID的域名部分只有基本的域名语义；任何可能的特定于所有者的语义都不在DKIM的范围之内。第3.5节对此进行了规定。
Original Text:
原文：
(None. New section. Additional text.)
（无。新章节。附加文本。）
Corrected Text:
更正文本：
A module that consumes DKIM's mandatory payload, which is the responsible Signing Domain Identifier (SDID). The module is dedicated to the assessment of the delivered identifier. Other DKIM (and non-DKIM) values can also be delivered to this module as well as to a more general message evaluation filtering engine. However, this additional activity is outside the scope of the DKIM signature specification.
使用DKIM的强制有效负载（即负责签名的域标识符（SDID））的模块。该模块专门用于评估交付的标识符。其他DKIM（和非DKIM）值也可以传递到此模块以及更通用的消息评估过滤引擎。但是，此附加活动不在DKIM签名规范的范围内。
Original Text:
原文：
d= The domain of the signing entity (plain-text; REQUIRED). This is the domain that will be queried for the public key. This domain MUST be the same as or a parent domain of the "i=" tag (the signing identity, as described below), or it MUST meet the requirements for parent domain signing described in Section 3.8. When presented with a signature that does not meet these requirement, verifiers MUST consider the signature invalid.
d=签名实体的域（纯文本；必填）。这是将查询公钥的域。此域必须与“i=”标记（签名标识，如下所述）相同或是其父域，或者必须满足第3.8节中所述的父域签名要求。当提交的签名不符合这些要求时，验证者必须考虑签名无效。
Internationalized domain names MUST be encoded as described in [RFC3490].
国际化域名必须按照[RFC3490]中所述进行编码。
ABNF:
荷兰银行：
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain)
; from RFC 2821 Domain,
but excluding address-literal
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain)
; from RFC 2821 Domain,
but excluding address-literal
Corrected Text:
更正文本：
d=
d=
Specifies the SDID claiming responsibility for an introduction of a message into the mail stream (plain-text; REQUIRED). Hence, the SDID value is used to form the query for the public key. The SDID MUST correspond to a valid DNS name under which the DKIM key record is published. The conventions and semantics used by a signer to create and use a specific SDID
指定声称负责将消息引入邮件流的SDID（纯文本；必需）。因此，SDID值用于形成公钥的查询。SDID必须对应于发布DKIM密钥记录时使用的有效DNS名称。签名者用于创建和使用特定SDID的约定和语义
are outside the scope of the DKIM Signing specification, as is any use of those conventions and semantics. When presented with a signature that does not meet these requirements, verifiers MUST consider the signature invalid.
不在DKIM签名规范的范围内，使用这些约定和语义也是如此。当提交的签名不符合这些要求时，验证者必须考虑签名无效。
Internationalized domain names MUST be encoded as described in [RFC3490].
国际化域名必须按照[RFC3490]中所述进行编码。
ABNF:
荷兰银行：
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain)
; from RFC 5321 Domain,
but excluding address-literal
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain)
; from RFC 5321 Domain,
but excluding address-literal
Original Text:
原文：
i= Identity of the user or agent (e.g., a mailing list manager) on behalf of which this message is signed (dkim-quoted-printable; OPTIONAL, default is an empty Local-part followed by an "@" followed by the domain from the "d=" tag). The syntax is a standard email address where the Local-part MAY be omitted. The domain part of the address MUST be the same as or a subdomain of the value of the "d=" tag.
i=代表其签署此邮件的用户或代理（例如，邮件列表管理员）的身份（dkim quoted printable；可选，默认为空本地部分，后跟“@”，后跟“d=”标记中的域）。语法是一个标准的电子邮件地址，可以省略本地部分。地址的域部分必须与“d=”标记的值相同或是其子域。
Internationalized domain names MUST be converted using the steps listed in Section 4 of [RFC3490] using the "ToASCII" function.
必须使用[RFC3490]第4节中列出的步骤，使用“ToASCII”功能转换国际化域名。
ABNF:
荷兰银行：
sig-i-tag = %x69 [FWS] "=" [FWS]
[ Local-part ] "@" domain-name
sig-i-tag = %x69 [FWS] "=" [FWS]
[ Local-part ] "@" domain-name
INFORMATIVE NOTE: The Local-part of the "i=" tag is optional because in some cases a signer may not be able to establish a verified individual identity. In such cases, the signer may wish to assert that although it is willing to go as far as signing for the domain, it is unable or unwilling to commit to an individual user name within their domain. It can do so by including the domain part but not the Local-part of the identity.
资料性说明：“i=”标记的本地部分是可选的，因为在某些情况下，签名者可能无法建立经验证的个人身份。在这种情况下，签名者可能希望声明，尽管它愿意为域签名，但它不能或不愿意在其域内提交个人用户名。它可以通过包含域部分而不是标识的本地部分来实现。
INFORMATIVE DISCUSSION: This document does not require the value of the "i=" tag to match the identity in any message header fields. This is considered to be a verifier policy issue. Constraints between the value of the "i=" tag and other
信息性讨论：本文档不要求“i=”标记的值与任何消息头字段中的标识匹配。这被认为是一个验证者策略问题。“i=”标记的值与其他值之间的约束
identities in other header fields seek to apply basic authentication into the semantics of trust associated with a role such as content author. Trust is a broad and complex topic and trust mechanisms are subject to highly creative attacks. The real-world efficacy of bindings between the "i=" value and other identities is not well established, nor is its vulnerability to subversion by an attacker. Hence reliance on the use of these options should be strictly limited. In particular, it is not at all clear to what extent a typical end-user recipient can rely on any assurances that might be made by successful use of the "i=" options.
其他头字段中的标识寻求将基本身份验证应用到与角色（如内容作者）关联的信任语义中。信任是一个广泛而复杂的话题，信任机制受到高度创造性的攻击。“i=”值与其他标识之间绑定的真实效果尚未得到充分证实，其易受攻击者破坏的漏洞也未得到充分证实。因此，应严格限制对这些选项使用的依赖。特别是，一个典型的最终用户接收者在多大程度上依赖于成功使用“i=”选项可能做出的任何保证，这一点根本不清楚。
Corrected Text:
更正文本：
i=
我=
The Agent or User Identifier (AUID) on behalf of which the SDID is taking responsibility (dkim-quoted-printable; OPTIONAL, default is an empty Local-part followed by an "@" followed by the domain from the "d=" tag).
SDID负责的代理或用户标识符（AUID）（dkim quoted printable；可选，默认为空本地部分，后跟“@”，后跟“d=”标记中的域）。
The syntax is a standard email address where the Local-part MAY be omitted. The domain part of the address MUST be the same as, or a subdomain of the value of, the "d=" tag.
语法是一个标准的电子邮件地址，可以省略本地部分。地址的域部分必须与“d=”标记的值相同，或是其值的子域。
Internationalized domain names MUST be converted using the steps listed in Section 4 of [RFC3490] using the "ToASCII" function.
必须使用[RFC3490]第4节中列出的步骤，使用“ToASCII”功能转换国际化域名。
ABNF:
荷兰银行：
sig-i-tag = %x69 [FWS] "=" [FWS]
[ Local-part ] "@" domain-name
sig-i-tag = %x69 [FWS] "=" [FWS]
[ Local-part ] "@" domain-name
The AUID is specified as having the same syntax as an email address, but is not required to have the same semantics. Notably, the domain name is not required to be registered in the DNS -- so it might not resolve in a query -- and the Local-part MAY be drawn from a namespace that does not contain the user's mailbox. The details of the structure and semantics for the namespace are determined by the Signer. Any knowledge or use of those details by verifiers or assessors is outside the scope of the DKIM Signing specification. The Signer MAY choose to use the same namespace for its AUIDs as its users' email addresses or MAY choose other means of representing its users. However, the signer SHOULD use the same AUID for each message intended to be evaluated as being within the same sphere of
AUID被指定为具有与电子邮件地址相同的语法，但不要求具有相同的语义。值得注意的是，域名不需要在DNS中注册——因此它可能不会在查询中解析——并且本地部分可能来自不包含用户邮箱的命名空间。命名空间的结构和语义细节由签名者确定。核查人员或评估人员对这些细节的任何了解或使用不在DKIM签署规范的范围内。签名者可以选择对其AUID使用与其用户电子邮件地址相同的名称空间，也可以选择其他表示其用户的方式。但是，签名者应该为每个消息使用相同的AUID，这些消息将被评估为在同一范围内
responsibility, if it wishes to offer receivers the option of using the AUID as a stable identifier that is finer grained than the SDID.
责任，如果它希望为接收方提供使用AUID作为比SDID粒度更细的稳定标识符的选项。
INFORMATIVE NOTE: The Local-part of the "i=" tag is optional because, in some cases, a signer may not be able to establish a verified individual identity. In such cases, the signer might wish to assert that although it is willing to go as far as signing for the domain, it is unable or unwilling to commit to an individual user name within their domain. It can do so by including the domain part but not the Local-part of the identity.
资料性说明：“i=”标记的本地部分是可选的，因为在某些情况下，签名者可能无法建立已验证的个人身份。在这种情况下，签名者可能希望声明，尽管它愿意为域签名，但它无法或不愿意在其域内提交个人用户名。它可以通过包含域部分而不是标识的本地部分来实现。
Original Text:
原文：
e.g., a key record for the domain example.com can be used to verify messages where the signing identity ("i=" tag of the signature) is sub.example.com, or even sub1.sub2.example.com. In order to limit the capability of such keys when this is not intended, the "s" flag may be set in the "t=" tag of the key record to constrain the validity of the record to exactly the domain of the signing identity. If the referenced key record contains the "s" flag as part of the "t=" tag, the domain of the signing identity ("i=" flag) MUST be the same as that of the d= domain. If this flag is absent, the domain of the signing identity MUST be the same as, or a subdomain of, the d= domain.
e、 例如，域example.com的密钥记录可用于验证签名标识（“i=”签名标签）为sub.example.com甚至sub1.sub2.example.com的消息。为了在非预期的情况下限制此类密钥的能力，可以在密钥记录的“t=”标记中设置“s”标志，以将记录的有效性严格限制在签名标识的域内。如果引用的密钥记录包含作为“t=”标记一部分的“s”标志，则签名标识的域（“i=”标志）必须与d=域的域相同。如果没有此标志，则签名标识的域必须与d=域相同或是其子域。
Corrected Text:
更正文本：
...for example, a key record for the domain example.com can be used to verify messages where the AUID ("i=" tag of the signature) is sub.example.com, or even sub1.sub2.example.com. In order to limit the capability of such keys when this is not intended, the "s" flag MAY be set in the "t=" tag of the key record, to constrain the validity of the domain of the AUID. If the referenced key record contains the "s" flag as part of the "t=" tag, the domain of the AUID ("i=" flag) MUST be the same as that of the SDID (d=) domain. If this flag is absent, the domain of the AUID MUST be the same as, or a subdomain of, the SDID.
…例如，域example.com的密钥记录可用于验证AUID（“i=”签名标记）为sub.example.com甚至sub1.sub2.example.com的消息。为了在非预期的情况下限制此类密钥的能力，可以在密钥记录的“t=”标记中设置“s”标志，以约束AUID域的有效性。如果引用的密钥记录包含作为“t=”标记一部分的“s”标志，则AUID（“i=”标志）的域必须与SDID（d=）域的域相同。如果没有此标志，AUID的域必须与SDID相同或是SDID的子域。
Original Text: (None. New section. Additional text.)
原始文本：（无。新节。附加文本。）
Corrected Text:
更正文本：
DKIM's primary task is to communicate from the Signer to a recipient-side Identity Assessor a single Signing Domain Identifier (SDID) that refers to a responsible identity. DKIM MAY optionally provide a single responsible Agent or User Identifier (AUID).
DKIM的主要任务是从签名者向接收方身份评估员传递一个引用责任身份的单一签名域标识符（SDID）。DKIM可以选择性地提供单个责任代理或用户标识符（AUID）。
Hence, DKIM's mandatory output to a receive-side Identity Assessor is a single domain name. Within the scope of its use as DKIM output, the name has only basic domain name semantics; any possible owner-specific semantics are outside the scope of DKIM. That is, within its role as a DKIM identifier, additional semantics cannot be assumed by an Identity Assessor.
因此，DKIM必须向接收方身份评估器输出一个域名。在作为DKIM输出的使用范围内，该名称只有基本的域名语义；任何可能的特定于所有者的语义都不在DKIM的范围之内。也就是说，在其作为DKIM标识符的角色中，身份评估员不能承担额外的语义。
A receive-side DKIM verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the Agent or User Identifier (i=) if present.
接收端DKIM验证器必须将签名域标识符（d=）传送给消费身份评估器模块，并且可以传送代理或用户标识符（i=）。
To the extent that a receiver attempts to intuit any structured semantics for either of the identifiers, this is a heuristic function that is outside the scope of DKIM's specification and semantics. Hence, it is relegated to a higher-level service, such as a delivery handling filter that integrates a variety of inputs and performs heuristic analysis of them.
在某种程度上，接收者试图对任一标识符的任何结构化语义进行直觉，这是一个启发式函数，超出了DKIM规范和语义的范围。因此，它被降级到更高级别的服务，例如集成各种输入并对其执行启发式分析的交付处理过滤器。
INFORMATIVE DISCUSSION: This document does not require the value of the SDID or AUID to match the identifier in any other message header field. This requirement is, instead, an assessor policy issue. The purpose of such a linkage would be to authenticate the value in that other header field. This, in turn, is the basis for applying a trust assessment based on the identifier value. Trust is a broad and complex topic and trust mechanisms are subject to highly creative attacks. The real-world efficacy of any but the most basic bindings between the SDID or AUID and other identities is not well established, nor is its vulnerability to subversion by an attacker. Hence, reliance on the use of such bindings should be strictly limited. In particular, it is not at all clear to what extent a typical end-user recipient can rely on any assurances that might be made by successful use of the SDID or AUID.
信息性讨论：本文档不要求SDID或AUID的值与任何其他消息头字段中的标识符匹配。相反，这一要求是一个评估员政策问题。这种链接的目的是验证另一个标头字段中的值。这又是基于标识符值应用信任评估的基础。信任是一个广泛而复杂的话题，信任机制受到高度创造性的攻击。SDID或AUID与其他身份之间的任何绑定（除了最基本的绑定外）的实际效果都没有得到很好的证实，其易受攻击者破坏的漏洞也没有得到很好的证实。因此，应严格限制对此类绑定使用的依赖。特别是，一个典型的最终用户接收者可以在多大程度上依赖成功使用SDID或AUID可能做出的任何保证，这一点根本不清楚。
Original Text:
原文：
It is beyond the scope of this specification to describe what actions a verifier system should make, but an authenticated email presents an opportunity to a receiving system that unauthenticated email cannot. Specifically, an authenticated email creates a predictable identifier by which other decisions can reliably be managed, such as trust and reputation. Conversely, unauthenticated email lacks a reliable identifier that can be used to assign trust and reputation.
描述验证器系统应采取的行动超出了本规范的范围，但经过身份验证的电子邮件为接收系统提供了未经身份验证的电子邮件无法提供的机会。具体来说，经过身份验证的电子邮件会创建一个可预测的标识符，通过该标识符可以可靠地管理其他决策，例如信任和声誉。相反，未经验证的电子邮件缺少可用于分配信任和声誉的可靠标识符。
Corrected Text:
更正文本：
It is beyond the scope of this specification to describe what actions an Identity Assessor can make, but mail carrying a validated SDID presents an opportunity to an Identity Assessor that unauthenticated email does not. Specifically, an authenticated email creates a predictable identifier by which other decisions can reliably be managed, such as trust and reputation.
描述身份评估员可以采取的行动超出了本规范的范围，但带有已验证SDID的邮件为身份评估员提供了未经验证的电子邮件无法提供的机会。具体来说，经过身份验证的电子邮件会创建一个可预测的标识符，通过该标识符可以可靠地管理其他决策，例如信任和声誉。
Original Text:
原文：
Once the signature has been verified, that information MUST be conveyed to higher-level systems (such as explicit allow/ whitelists and reputation systems) and/or to the end user. If the message is signed on behalf of any address other than that in the From: header field, the mail system SHOULD take pains to ensure that the actual signing identity is clear to the reader.
一旦签名得到验证，该信息必须传达给更高级别的系统（如明确的允许/白名单和信誉系统）和/或最终用户。如果邮件是代表除From:header字段之外的任何地址签名的，则邮件系统应尽力确保读者清楚实际签名标识。
Corrected Text:
更正文本：
Once the signature has been verified, that information MUST be conveyed to the Identity Assessor (such as an explicit allow/ whitelist and reputation system) and/or to the end user. If the SDID is not the same as the address in the From: header field, the mail system SHOULD take pains to ensure that the actual SDID is clear to the reader.
签名验证后，必须将该信息传达给身份评估员（如明确的允许/白名单和声誉系统）和/或最终用户。如果SDID与From:header字段中的地址不同，邮件系统应尽力确保读者清楚实际的SDID。
Original Text:
原文：
The tendency is to have the MUA highlight the address associated with this signing identity in some way, in an attempt to show the user the address from which the mail was sent.
趋势是让MUA以某种方式突出显示与此签名身份相关的地址，以尝试向用户显示邮件发送的地址。
Corrected Text:
更正文本：
The tendency is to have the MUA highlight the SDID, in an attempt to show the user the identity that is claiming responsibility for the message.
趋势是让MUA突出显示SDID，试图向用户显示声称对消息负责的身份。
This Update clarifies core details about DKIM's payload. As such, it affects interoperability, semantic characterization, and the expectations for the identifiers carried with a DKIM signature. Clarification of these details is likely to limit misinterpretation of DKIM's semantics. Since DKIM is fundamentally a security protocol, this should improve its security characteristics.
此更新澄清了DKIM有效载荷的核心细节。因此，它会影响互操作性、语义特征以及对DKIM签名所携带标识符的期望。澄清这些细节可能会限制对DKIM语义的误解。由于DKIM从根本上说是一种安全协议，因此应该可以改进其安全特性。
[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月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[RFC4871]Allman，E.，Callas，J.，Delany，M.，Libbey，M.，Fenton，J.，和M.Thomas，“域密钥识别邮件（DKIM）签名”，RFC 48712007年5月。
This appendix contains the full set of corrected ABNF fragments defined in this document.
本附录包含本文件中定义的全套更正ABNF片段。
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权所有（c）2009 IETF信托基金和被确定为代码作者的人员。版权所有。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
在满足以下条件的情况下，允许以源代码和二进制格式重新分发和使用，无论是否修改：
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- 源代码的重新分发必须保留上述版权声明、此条件列表和以下免责声明。
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- 以二进制形式重新分发时，必须在分发时提供的文档和/或其他材料中复制上述版权声明、本条件列表和以下免责声明。
- Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.
- 未经事先书面许可，不得使用互联网协会、IETF或IETF Trust的名称或特定贡献者的名称来认可或推广源自本软件的产品。
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
本软件由版权所有者和贡献者“按原样”提供，不承担任何明示或暗示的担保，包括但不限于适销性和特定用途适用性的暗示担保。在任何情况下，版权所有人或贡献者均不对任何直接、间接、偶然、特殊、惩戒性或后果性损害（包括但不限于替代商品或服务的采购；使用、数据或利润的损失；或业务中断）负责，无论是在合同中还是在任何责任理论下，严格责任，或因使用本软件而产生的侵权行为（包括疏忽或其他），即使告知可能发生此类损害。
This version of this MIB module is part of RFC 5672; see the RFC itself for full legal notices.
此版本的MIB模块是RFC 5672的一部分；有关完整的法律通知，请参见RFC本身。
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain)
; from RFC 5321 Domain,
but excluding address-literal
sig-d-tag = %x64 [FWS] "=" [FWS] domain-name
domain-name = sub-domain 1*("." sub-domain)
; from RFC 5321 Domain,
but excluding address-literal
sig-i-tag = %x69 [FWS] "=" [FWS]
[ Local-part ] "@" domain-name
sig-i-tag = %x69 [FWS] "=" [FWS]
[ Local-part ] "@" domain-name
This document was initially formulated by an ad hoc design team, comprising: Jon Callas, D. Crocker, J. D. Falk, Michael Hammer, Tony Hansen, Murray Kucherawy, John Levine, Jeff Macdonald, Ellen Siegel, and Wietse Venema. The final version of the document was developed through vigorous discussion in the IETF DKIM working group.
本文件最初由一个特设设计团队制定，该团队包括：Jon Callas、D.Crocker、J.D.Falk、Michael Hammer、Tony Hansen、Murray Kucherawy、John Levine、Jeff Macdonald、Ellen Siegel和Wietse Venema。该文件的最终版本是通过IETF DKIM工作组的积极讨论制定的。
Author's Address
作者地址
D. Crocker (editor) Brandenburg InternetWorking
D.克罗克（编辑）勃兰登堡互联网
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net