Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 6541 Cloudmark, Inc.
Category: Experimental February 2012
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 6541 Cloudmark, Inc.
Category: Experimental February 2012
ISSN: 2070-1721
DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures
域密钥识别邮件（DKIM）授权第三方签名
Abstract
摘要
This experimental specification proposes a modification to DomainKeys Identified Mail (DKIM) allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author.
本实验性规范提出了对DomainKeys Identified Mail（DKIM）的修改，允许发布第三方签名授权，该授权将被解释为等同于消息作者的管理域添加的签名。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6541.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6541.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Definitions .....................................................3
2.1. Key Words ..................................................3
2.2. Email Architecture Terminology .............................3
3. Roles and Scope .................................................3
4. Queries and Replies .............................................4
4.1. Hash Selection .............................................4
4.2. Extension to DKIM ..........................................5
4.3. ATPS Query Details .........................................5
4.4. ATPS Reply Details .........................................7
5. Interpretation ..................................................8
6. Relationship to ADSP ............................................8
7. Experiment Process ..............................................8
8. IANA Considerations .............................................9
8.1. ATPS Tag Registry ..........................................9
8.2. Email Authentication Methods Registry Update ..............10
8.3. Email Authentication Result Names Registry Update .........10
8.4. DKIM Signature Tag Specifications Registry ................12
9. Security Considerations ........................................12
9.1. Hash Selection ............................................12
9.2. False Privacy .............................................12
9.3. Transient Security Failures ...............................13
9.4. Load on the DNS ...........................................13
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................14
Appendix A. Example Query and Reply ...............................15
Appendix B. Choice of DNS RR Type .................................15
Appendix C. Acknowledgements ......................................16
1. Introduction ....................................................2
2. Definitions .....................................................3
2.1. Key Words ..................................................3
2.2. Email Architecture Terminology .............................3
3. Roles and Scope .................................................3
4. Queries and Replies .............................................4
4.1. Hash Selection .............................................4
4.2. Extension to DKIM ..........................................5
4.3. ATPS Query Details .........................................5
4.4. ATPS Reply Details .........................................7
5. Interpretation ..................................................8
6. Relationship to ADSP ............................................8
7. Experiment Process ..............................................8
8. IANA Considerations .............................................9
8.1. ATPS Tag Registry ..........................................9
8.2. Email Authentication Methods Registry Update ..............10
8.3. Email Authentication Result Names Registry Update .........10
8.4. DKIM Signature Tag Specifications Registry ................12
9. Security Considerations ........................................12
9.1. Hash Selection ............................................12
9.2. False Privacy .............................................12
9.3. Transient Security Failures ...............................13
9.4. Load on the DNS ...........................................13
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................14
Appendix A. Example Query and Reply ...............................15
Appendix B. Choice of DNS RR Type .................................15
Appendix C. Acknowledgements ......................................16
[DKIM] defines a mechanism for transparent domain-level signing of messages for the purpose of declaring that a particular ADministrative Management Domain (ADMD) takes some responsibility for a message.
[DKIM]定义了一种用于对消息进行透明域级签名的机制，以声明特定的管理域（ADMD）对消息承担某些责任。
DKIM, however, deliberately makes no binding between the DNS domain of the Signer and any other identity found in the message. Despite this, there is an automatic human perception that an Author Domain Signature (one for which the RFC5322.From domain matches the DNS domain of the Signer) is more valuable or trustworthy than any other.
但是，DKIM故意不在签名者的DNS域和消息中找到的任何其他标识之间进行绑定。尽管如此，人们还是自动认为作者域签名（RFC5322.From域与签名者的DNS域相匹配的签名）比任何其他签名更有价值或更可信。
To enable a third party to apply DKIM signatures to messages, the DKIM specification suggests delegation to a third party of either subdomains or private keys, so that the third party can add DKIM
为了使第三方能够对消息应用DKIM签名，DKIM规范建议将子域或私钥委托给第三方，以便第三方可以添加DKIM
signatures that appear to have been added by the Author ADMD. Absent is a protocol by which an Author ADMD can announce that messages bearing specific valid DKIM signatures on its mail, which are added by other ADMDs, are to be treated as if they were signed by the Author ADMD itself. This memo presents an experimental mechanism for doing so, called Authorized Third-Party Signatures (ATPS).
似乎是作者ADMD添加的签名。缺少一个协议，作者ADMD可以根据该协议宣布，由其他ADMD添加的邮件上带有特定有效DKIM签名的邮件将被视为由作者ADMD自己签名。本备忘录提供了一种实验性机制，称为授权第三方签名（ATP）。
ATPS augments the semantics of DKIM by providing to the Verifier multiple identifiers rather than one. Specifically, it validates the identifier found in the DKIM signature, and then provides the RFC5322.From domain for evaluation.
ATPS通过向验证器提供多个标识符而不是一个标识符来增强DKIM的语义。具体来说，它验证在DKIM签名中找到的标识符，然后提供RFC5322.From域以进行评估。
This memo also registers, per [AUTHRES], the means to indicate to agents downstream of the Verifier that a third-party signature verification occurred.
根据[AUTHRES]，本备忘录还登记了向验证器下游代理表明发生了第三方签名验证的方法。
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 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
Readers are advised to be familiar with the material and terminology discussed in [MAIL] and [EMAIL-ARCH].
建议读者熟悉[MAIL]和[EMAIL-ARCH]中讨论的材料和术语。
The context of this protocol involves the following roles:
本协议的上下文涉及以下角色：
o ADministrative Management Domains (ADMDs), whose DNS domain name(s) appear in the RFC5322.From field of a [MAIL] message;
o 管理管理域（ADMD），其DNS域名出现在[邮件]消息的RFC5322.发件人字段中；
o ATPS Signers, which apply [DKIM] signatures using their own domains, but on behalf of the message Author's ADMD; and
o ATPS签名者，他们使用自己的域应用[DKIM]签名，但代表消息作者的ADMD；和
o the Verifier, who implements the signature validation procedures described in [DKIM].
o 实施[DKIM]中所述签名验证程序的验证者。
An ADMD implements this protocol if it wishes to announce that a signature from any in a set of specified DNS domains is to be considered equivalent to one from the ADMD itself. For example, an ADMD might wish to delegate signing authority for its DNS domain to an approved messaging service provider without doing the work of key transfer described in Appendix B.1.1 of [DKIM]. An authorized ATPS
如果ADMD希望宣布来自一组指定DNS域中任何一个域的签名被视为等同于来自ADMD本身的签名，则ADMD将实现此协议。例如，ADMD可能希望将其DNS域的签名权限委托给经批准的消息服务提供商，而无需执行[DKIM]附录B.1.1中所述的密钥传输工作。经授权的自动测试程序
Signer makes a claim of this relationship via new tags in the DKIM signature, and the ADMD confirms this claim by publishing a specific TXT record in its DNS.
签名者通过DKIM签名中的新标记声明此关系，ADMD通过在其DNS中发布特定TXT记录来确认此声明。
A Verifier implements this protocol if it wishes to ensure that a message bears one or more signatures from sources authorized to sign mail on behalf of the ADMD, and identify for special treatment mail that meets (or does not meet) that criterion. It will do so by treating the Signer's authorization on behalf of the Author's ADMD to mean that the Signer's signature is equivalent to one affixed by the Author's ADMD.
如果验证器希望确保邮件具有一个或多个来自授权代表ADMD对邮件进行签名的来源的签名，并识别满足（或不满足）该标准的邮件进行特殊处理，则验证器将实施该协议。它将通过将签名人代表作者的ADMD的授权视为签名人的签名等同于作者的ADMD所贴的签名来实现这一点。
This section describes in detail the queries issued, the replies received, and how they should be interpreted and applied.
本节详细介绍发出的查询、收到的答复以及应如何解释和应用这些查询。
The Author's ADMD will indicate authorization of a third party to sign its mail via the presence of a DNS TXT record that contains an encoding of the third party's DNS domain name. There are two supported methods for doing so -- one that involves a plain copy of the third party's DNS domain name, and one that involves an encoded version of the name. The encoding mechanism is provided so that any domain name can be added to the DNS in a fixed length, so that longer third-party domain names are not excluded from participation because of the overall length limit on a DNS query.
作者的ADMD将表示授权第三方通过存在包含第三方DNS域名编码的DNS TXT记录对其邮件进行签名。有两种受支持的方法可以执行此操作——一种涉及第三方DNS域名的纯拷贝，另一种涉及名称的编码版本。提供了编码机制，以便可以在固定长度内将任何域名添加到DNS，从而不会因为DNS查询的总长度限制而将较长的第三方域名排除在参与范围之外。
If selected, the encoding mechanism requires constructing a digest of the third party's DNS domain name. The Author ADMD MUST select a digest ("hash") method currently supported by DKIM (see Section 7.7 of [DKIM]), and this selection needs to be communicated to the ATPS Signer, as it is used in generation of the third-party signatures.
如果选中，编码机制需要构造第三方DNS域名的摘要。作者ADMD必须选择DKIM当前支持的摘要（“哈希”）方法（见[DKIM]第7.7节），该选择需要传达给ATPS签名人，因为它用于生成第三方签名。
Where the encoding mechanism is not used, the ATPS Signer MUST use a hash name of "none".
在未使用编码机制的情况下，ATPS签名者必须使用哈希名称“无”。
The full DNS mechanism is specified in Section 4.3.
第4.3节规定了完整的DNS机制。
[DKIM] signatures contain a "tag=value" sequence. This protocol will add additional tags called "atps" and "atpsh".
[DKIM]签名包含“标记=值”序列。该协议将添加名为“atps”和“atpsh”的附加标签。
When the ATPS Signer generates a DKIM signature for another ADMD, it MUST put its own domain in the signature's "d" tag, and include an "atps" tag that has as its value the domain name of the ADMD on whose behalf it is signing.
当ATPS签名者为另一个ADMD生成DKIM签名时，它必须将自己的域放在签名的“d”标记中，并包含一个“ATPS”标记，该标记的值为它所代表的ADMD的域名。
The tag name that carries the name of the selected hash algorithm is "atpsh". This tag MUST also be included, as it is required as part of the algorithm that will be enacted by the Verifier.
携带所选哈希算法名称的标记名为“atpsh”。该标签也必须包括在内，因为它是验证者将实施的算法的一部分。
The formal syntax definition, per [ABNF], is as follows:
根据[ABNF]，正式语法定义如下：
dkim-atps-tag = %x61.74.70.73 *WSP "=" *WSP domain-name
dkim-atps-tag = %x61.74.70.73 *WSP "=" *WSP domain-name
dkim-atpsh-tag = %x61.74.70.73.68 *WSP "=" *WSP
( "none" / key-h-tag-alg )
dkim-atpsh-tag = %x61.74.70.73.68 *WSP "=" *WSP
( "none" / key-h-tag-alg )
"domain-name" and "key-h-tag-alg" are defined in [DKIM]. Note that according to [DKIM], internationalized domain names are to be encoded as A-labels, as described in Section 2.3 of [IDNA].
[DKIM]中定义了“域名”和“key-h-tag-alg”。请注意，根据[DKIM]，国际化域名将被编码为A标签，如[IDNA]第2.3节所述。
The registration for these tags can be found in Section 8.
可在第8节中找到这些标签的注册。
When a [DKIM] signature including an "atps" tag is successfully verified, and is considered acceptable to the Verifier according to any local policy requirements (which are not discussed here or in [DKIM]), the Verifier compares the domain name in the value of that tag with the one found in the RFC5322.From field of the message. The match MUST be done in a case-insensitive manner.
当包含“atps”标记的[DKIM]签名被成功验证，并且根据任何本地策略要求（此处或[DKIM]中未讨论）被认为是验证者可接受的时，验证者将该标记值中的域名与消息RFC5322.From字段中的域名进行比较。必须以不区分大小写的方式进行匹配。
If they do not match, the "atps" tag MUST be ignored.
如果它们不匹配，则必须忽略“atps”标记。
If they do match, the Verifier issues a DNS TXT query, as specified below, looking for confirmation by the Author ADMD that the ATPS Signer is authorized by that ADMD to sign mail on its behalf. Where multiple DKIM signatures including valid "atps" tags are present, these queries MAY be done in any order or MAY be done in parallel.
如果它们确实匹配，验证器将发出DNS TXT查询（如下所述），以寻求作者ADMD确认ATPS签名者已被该ADMD授权代表其签署邮件。如果存在多个DKIM签名，包括有效的“atps”标记，这些查询可以按任意顺序进行，也可以并行进行。
Where the RFC5322.From field contains multiple addresses, this process SHOULD be applied if the "atps" tag's value matches any of the domains found in that field. These MAY be done in any order.
如果RFC5322.From字段包含多个地址，则如果“atps”标记的值与该字段中找到的任何域匹配，则应应用此过程。这些可以按任何顺序进行。
Note that the algorithm uses hashing, but this is not a security mechanism. See Section 9.2 for discussion.
请注意，该算法使用哈希，但这不是一种安全机制。有关讨论，请参见第9.2节。
The name for the query is constructed as follows:
查询的名称构造如下：
1. Select the hash algorithm from the "atpsh" tag in the signature. If the hash algorithm specified does not appear in the list registered with IANA as one valid for use with DKIM (see Section 7.7 of [DKIM]), and is not the reserved name "none" as described above, abort the query.
1. 从签名中的“atpsh”标记中选择哈希算法。如果指定的哈希算法在IANA注册的列表中没有显示为可与DKIM一起使用的有效哈希算法（见[DKIM]第7.7节），并且不是上述保留名称“无”，则中止查询。
2. Extract the value of the "d=" tag from the signature.
2. 从签名中提取“d=”标记的值。
3. Convert any uppercase characters in that string to their lowercase equivalents.
3. 将该字符串中的任何大写字符转换为其等价的小写字符。
4. If the selected hash algorithm is not "none", apply the following additional steps:
4. 如果所选哈希算法不是“无”，请应用以下附加步骤：
A. Feed the resulting string to the selected hash algorithm.
A.将结果字符串馈送到所选哈希算法。
B. Convert the output of the hash to a string of printable ASCII characters by applying base32 encoding as defined in Section 6 of [BASE32]. The base32 encoding is used because its output is restricted to characters that are legal for use in labels in the DNS, and it is evaluated the same way in the DNS whether encoded using uppercase or lowercase characters.
B.通过应用[base32]第6节中定义的base32编码，将散列输出转换为可打印ASCII字符字符串。之所以使用base32编码，是因为其输出仅限于在DNS中的标签中合法使用的字符，并且在DNS中，无论是使用大写或小写字符编码，都以相同的方式对其进行计算。
5. Append the string "._atps."
5. 附加字符串“.\u atps”
6. Append the domain name found in the "atps" tag of the validated signature.
6. 附加在已验证签名的“atps”标记中找到的域名。
The query's formal syntax definition, per [ABNF], is as follows:
根据[ABNF]，查询的正式语法定义如下：
atps-query = ( 1*63BASE32 / domain-name )
%x2e.5f.61.74.70.73.2e domain-name
atps-query = ( 1*63BASE32 / domain-name )
%x2e.5f.61.74.70.73.2e domain-name
BASE32 = ( ALPHA / %x32-37 )
BASE32 = ( ALPHA / %x32-37 )
The width limit of 63 on the base32 encoding is based on the maximum label limit as defined in Section 2.3.4 of [DNS].
base32编码上63的宽度限制基于[DNS]第2.3.4节中定义的最大标签限制。
See Appendix A for an example of a query construction.
有关查询构造的示例，请参见附录A。
In the descriptions below, the label NOERROR symbolizes DNS response code ("rcode") 0, and NXDOMAIN represents rcode 3. See Section 4.1.1 of [DNS] for further details.
在下面的描述中，标签NOERROR表示DNS响应代码（“rcode”）0，NXDOMAIN表示rcode 3。有关更多详细信息，请参见[DNS]第4.1.1节。
At this time, only three possibilities need to be identified in this specification:
此时，本规范中只需确定三种可能性：
o An answer is returned (i.e., [DNS] reply code NOERROR with at least one answer) containing a valid ATPS reply. In this case, the protocol has been satisfied and the Verifier can conclude that the signing domain is authorized by the ADMD to sign its mail. Further queries SHOULD NOT be initiated.
o 返回包含有效ATPS应答的应答（即，[DNS]应答代码无错误，至少有一个应答）。在这种情况下，协议已得到满足，验证者可以断定签名域已被ADMD授权对其邮件进行签名。不应启动进一步的查询。
o No answer is returned (i.e., [DNS] reply code NXDOMAIN, or NOERROR with no answers), or one or more answers have been returned as described above but none contain a valid ATPS reply. In this case, the Signer has not been authorized to act as a third-party Signer for this ADMD, and thus the Verifier MUST continue to the next query, if any.
o 未返回任何答案（即[DNS]回复代码NXDOMAIN，或无答案的无错误），或者如上所述已返回一个或多个答案，但均不包含有效的ATPS回复。在这种情况下，签名者未被授权作为此ADMD的第三方签名者，因此验证者必须继续进行下一个查询（如果有）。
o An error is returned (i.e., any other [DNS] reply code). It is no longer possible to determine whether or not this message satisfies the ADMD's list of authorized third-party Signers. The Verifier SHOULD stop processing and defer the message for later processing, such as requesting a temporary failure code from the Mail Transfer Agent (MTA).
o 返回错误（即任何其他[DNS]回复代码）。无法再确定此消息是否满足ADMD的授权第三方签名者列表。验证器应停止处理并将邮件推迟到以后处理，例如从邮件传输代理（MTA）请求临时故障代码。
If all queries are completed and return either NXDOMAIN or NOERROR with no answers, then the Signer was not authorized by the ADMD.
如果所有查询都已完成并返回NXDOMIN或NOERROR，但没有回答，则签名者未经ADMD授权。
A valid ATPS reply consists of a sequence of tag=value pairs as described in Section 3.2 of [DKIM]. The following tags and values are currently supported in ATPS records:
有效的ATPS回复由[DKIM]第3.2节所述的标签=值对序列组成。ATPS记录中当前支持以下标记和值：
d: Domain (plain-text; RECOMMENDED). This tag includes a plain-text copy of the DNS domain being authorized as an ATPS Signer. This is included to assist with collision detections; for example, if the base32 encoding of this name is not the same as the base32 portion of the query, or more simply if this name is not the same as that found in the "atps" tag, a hash collision could have occurred. Its use where no name hashing has occurred is redundant. The ABNF is as follows:
d：域（纯文本；推荐）。此标记包括被授权为ATPS签名者的DNS域的纯文本副本。这包括协助碰撞检测；例如，如果此名称的base32编码与查询的base32部分不同，或者更简单地说，如果此名称与“atps”标记中的名称不同，则可能发生哈希冲突。在没有名字散列的情况下使用它是多余的。ABNF如下所示：
atps-d-tag = %x64 [FWS] "=" [FWS] domain-name
; FWS is defined in [DKIM]
atps-d-tag = %x64 [FWS] "=" [FWS] domain-name
; FWS is defined in [DKIM]
v: Version (plain-text; REQUIRED). This tag indicates the version of the ATPS specification to which the record complies. The record MUST be ignored if the value is not "ATPS1". The ABNF is as follows:
v：版本（纯文本；必填）。此标签表示记录符合的ATPS规范版本。如果该值不是“ATPS1”，则必须忽略该记录。ABNF如下所示：
atps-v-tag = %x76 [FWS] "=" [FWS] %x41.54.50.53.31
; FWS is defined in [DKIM]
atps-v-tag = %x76 [FWS] "=" [FWS] %x41.54.50.53.31
; FWS is defined in [DKIM]
For each DKIM signature that verifies (see Section 6 of [DKIM]), if a Verifier succeeds in confirming that the Author's ADMD authorized the ATPS Signer using this protocol, then the Verifier SHOULD evaluate the message as though it contained a valid signature from the Author's ADMD. It MAY also independently evaluate the ATPS Signer when determining message disposition.
对于验证的每个DKIM签名（见[DKIM]第6节），如果验证者成功确认作者的ADMD使用此协议授权ATPS签名者，则验证者应评估消息，就好像它包含来自作者的ADMD的有效签名一样。它还可以在确定消息处置时独立评估ATPS签名者。
This assertion is based on the fact that the ADMD explicitly endorsed the ATPS Signer. Therefore, a module assessing reputation that is based on DKIM signature verification SHOULD apply the reputation of the Author's ADMD domain instead of, or in addition to, that of the ATPS Signer domain.
此断言基于ADMD明确认可ATPS签名者这一事实。因此，基于DKIM签名验证的声誉评估模块应该应用作者的ADMD域的声誉，而不是ATPS签名者域的声誉，或者是ATPS签名者域的声誉。
[ADSP] defined a protocol by which the owner of an Author Domain can advertise a request to message receivers that messages bearing no valid author signature be treated with suspicion or even discarded.
[ADSP]定义了一种协议，根据该协议，作者域的所有者可以向消息接收者公布一个请求，即没有有效作者签名的消息将被怀疑甚至丢弃。
A Verifier implementing both Author Domain Signing Practices (ADSP) and ATPS MUST test ATPS first. If ATPS indicates a valid delegation, the Verifier MUST act, with respect to ADSP, as though the message has a valid Author Domain Signature (because that's what the delegation means), and no ADSP test is required.
实现作者域签名实践（ADSP）和ATP的验证器必须首先测试ATP。如果ATPS表示有效的委托，那么验证者必须针对ADSP采取行动，就像消息具有有效的作者域签名一样（因为这就是委托的意思），并且不需要ADSP测试。
The working group that developed DKIM considered a third-party mechanism such as this one to be controversial, in terms of need and practicality, and decided that an alternative mechanism was sufficient. However, this was not based on actual experience, as there is no specific history on this question. Thus, this experiment was devised.
开发DKIM的工作组认为像这样的第三方机制在必要性和实用性方面是有争议的，并决定替代机制就足够了。然而，这并不是基于实际经验，因为在这个问题上没有具体的历史。因此，设计了这个实验。
The experimental protocol described here has been implemented as an extension to DKIM in two software products, one of which is open source and seeing increasingly wide use. It is included there to allow customers of those systems to make use of it if they believe such third-party assertions are useful to the overall DKIM mechanism. Further adoption as part of the experiment is welcome and encouraged.
这里描述的实验协议已经在两个软件产品中实现为DKIM的扩展，其中一个是开源的，并且使用越来越广泛。如果这些系统的客户认为这样的第三方断言对整个DKIM机制有用，则可以使用它。欢迎并鼓励作为实验一部分的进一步采用。
Use of the protocol and anecdotes of how it affects the overall DKIM experience will be collected by those implementers and the author of this memo. Those participating in the experiment are also advised to observe and report the impact of what is discussed in Section 9.4, especially with respect to MTA latency that may be introduced.
这些实施者和本备忘录的作者将收集协议的使用及其如何影响整体DKIM体验的轶事。还建议参与实验的人员观察并报告第9.4节中讨论的内容的影响，特别是可能引入的MTA延迟。
If the response is substantial and positive, advancement along the Standards Track might be warranted.
如果响应是实质性的和积极的，则可以保证沿着标准轨道前进。
This section enumerates requested IANA actions.
本节列举了请求的IANA操作。
IANA has created an Authorized Third-Party Signature (ATPS) Tag Registry, under the DomainKeys Identified Mail (DKIM) Parameters group, to enumerate the tags that are valid for use in ATPS records.
IANA已在DomainKeys Identified Mail（DKIM）参数组下创建了授权第三方签名（ATPS）标记注册表，以枚举可在ATPS记录中使用的有效标记。
New registrations or updates MUST be made in accordance with the "Specification Required" guidelines described in [IANA]. Such registry changes MUST contain the following information:
必须按照[IANA]中描述的“所需规范”指南进行新的注册或更新。此类注册表更改必须包含以下信息：
1. Name of the tag being registered or updated
1. 正在注册或更新的标记的名称
2. The document where the specification is created or updated
2. 创建或更新规范的文档
3. The status of the tag, one of "active" (tag is in current use), "deprecated" (tag is in current use but its use is discouraged), or "historic" (tag is no longer in use)
3. 标记的状态为“活动”（标记当前正在使用）、“已弃用”（标记当前正在使用，但不鼓励使用）或“历史”（标记不再使用）
The registry's initial entries are below:
登记处的初始条目如下：
+-----+------------+--------+
| Tag | Reference | Status |
+-----+------------+--------+
| d | [RFC6541] | active |
+-----+------------+--------+
| v | [RFC6541] | active |
+-----+------------+--------+
+-----+------------+--------+
| Tag | Reference | Status |
+-----+------------+--------+
| d | [RFC6541] | active |
+-----+------------+--------+
| v | [RFC6541] | active |
+-----+------------+--------+
The following has been added to the Email Authentication Methods registry (in the Email Authentication Parameters group) established by [AUTHRES] as per [IANA]:
以下内容已添加到[AUTHRES]根据[IANA]建立的电子邮件身份验证方法注册表（在电子邮件身份验证参数组中）：
Method: dkim-atps
方法：dkim-atps
Defined In: [RFC6541]
定义于：[RFC6541]
ptype: header
p类型：标题
property: from
物业：来自
value: contents of the [MAIL] From: header field, with comments removed
值：[MAIL]发件人：标题字段的内容，删除注释
The following have been added to the Email Authentication Result Names registry (in the Email Authentication Parameters group) established by [AUTHRES] as per [IANA]:
以下内容已添加到[AUTHRES]根据[IANA]建立的电子邮件身份验证结果名称注册表（在电子邮件身份验证参数组中）：
Code: none
代码：无
Existing/New Code: existing
现有/新代码：现有
Defined In: [AUTHRES]
定义于：[AUTHRES]
Auth Method: dkim-atps
验证方法：dkim atps
Meaning: No valid DKIM signatures were found on the message bearing "atps" tags.
含义：在带有“atps”标记的邮件上未找到有效的DKIM签名。
Code: pass
代码：pass
Existing/New Code: existing
现有/新代码：现有
Defined In: [AUTHRES]
定义于：[AUTHRES]
Auth Method: dkim-atps
验证方法：dkim atps
Meaning: An ATPS evaluation was performed, and a valid signature from an authorized third party was found on the message.
含义：执行ATPS评估，并在邮件上找到授权第三方的有效签名。
Code: fail
代码：失败
Existing/New Code: existing
现有/新代码：现有
Defined In: [AUTHRES]
定义于：[AUTHRES]
Auth Method: dkim-atps
验证方法：dkim atps
Meaning: All valid DKIM signatures bearing an "atps" tag either did not reference a domain name found in the RFC5322.From field, or the ATPS test(s) performed failed to confirm a third-party authorization.
含义：所有带有“atps”标记的有效DKIM签名要么未引用RFC5322.From字段中的域名，要么执行的atps测试未能确认第三方授权。
Code: temperror
代码：temperor
Existing/New Code: existing
现有/新代码：现有
Defined In: [AUTHRES]
定义于：[AUTHRES]
Auth Method: dkim-atps
验证方法：dkim atps
Meaning: An ATPS evaluation could not be completed due to some error that is likely transient in nature, such as a temporary DNS error. A later attempt might produce a final result.
含义：由于某些可能是暂时性错误，例如临时DNS错误，无法完成ATPS评估。稍后的尝试可能会产生最终结果。
Code: permerror
代码：permerror
Existing/New Code: existing
现有/新代码：现有
Defined In: [AUTHRES]
定义于：[AUTHRES]
Auth Method: dkim-atps
验证方法：dkim atps
Meaning: An ATPS evaluation could not be completed due to some error that is not likely transient in nature, such as a permanent DNS error. A later attempt is unlikely to produce a final result.
含义：由于某些本质上不可能是暂时的错误，例如永久性DNS错误，无法完成ATPS评估。以后的尝试不太可能产生最终结果。
The following have been added to the DKIM Signature Tag Specifications registry (in the DomainKeys Identified Mail (DKIM) Parameters group) established by [DKIM] as per [IANA]:
以下内容已添加到由[DKIM]根据[IANA]建立的DKIM签名标签规范注册表（在域密钥标识邮件（DKIM）参数组中）：
+-------+-----------+--------+
| Type | Reference | Status |
+-------+-----------+--------+
| atps | [RFC6541] | active |
+-------+-----------+--------+
| atpsh | [RFC6541] | active |
+-------+-----------+--------+
+-------+-----------+--------+
| Type | Reference | Status |
+-------+-----------+--------+
| atps | [RFC6541] | active |
+-------+-----------+--------+
| atpsh | [RFC6541] | active |
+-------+-----------+--------+
This section discusses potential security issues related to this experimental protocol.
本节讨论与此实验协议相关的潜在安全问题。
The selection of the hash algorithm to be used (see Section 4.1) has security implications, as weaker algorithms have more risk of collision, meaning a second DNS domain name could in theory be constructed to appear to have been authorized by the Author ADMD.
选择要使用的哈希算法（见第4.1节）具有安全含义，因为较弱的算法具有更大的冲突风险，这意味着第二个DNS域名在理论上可以被构造为似乎已经由作者ADMD授权。
At the time of publication of [DKIM], use of SHA256 was preferred over SHA1 for this reason, though support for both has been maintained. See Section 3.3 of [DKIM] for additional discussion.
在[DKIM]发布时，出于这个原因，使用SHA256比使用SHA1更受欢迎，尽管对两者的支持一直保持不变。更多讨论见[DKIM]第3.3节。
The fact that the authorized third-party domain name is hashed and then encoded with base32 might give some the false sense that the relationship between the two parties is somehow protected. This is not the case. Indeed, the very purpose of this protocol is to make it possible for such relationships to be discovered, so such an obscuration would make that process more difficult without a shared secret delivered out-of-band to message verifiers (which also adds further complexity). Rather, the hash and encode steps are done merely to convert any third-party domain name to a fixed width in the construction of the DNS query.
授权的第三方域名被散列，然后用base32编码，这一事实可能会给人一种错误的感觉，即双方之间的关系受到了某种程度的保护。事实并非如此。事实上，该协议的目的正是为了使发现此类关系成为可能，因此，如果不将共享秘密传送到带外消息验证器，这种模糊将使该过程更加困难（这也增加了复杂性）。相反，哈希和编码步骤只是为了在DNS查询的构造中将任何第三方域名转换为固定宽度。
Approving a third-party Signer exposes the ADMD to the risk that the third-party Signer becomes compromised and then begins to sign malicious or nuisance messages on behalf of the ADMD. This can obviously reflect negatively on the ADMD, and the impact of this can become more severe as automated domain reputation systems are developed and deployed. Thorough vetting and monitoring practices by ADMDs of third-party Signers will likely need to become the norm.
批准第三方签名者会使ADMD面临以下风险：第三方签名者受到威胁，然后开始代表ADMD签署恶意或有害消息。这显然会对ADMD产生负面影响，随着自动化域信誉系统的开发和部署，这种影响可能会变得更加严重。ADMD对第三方签名者的彻底审查和监控实践可能需要成为规范。
A Verifier participating in DKIM, ADSP, and ATPS will now issue a number of TXT queries to the DNS equal to as many as one (for the ADSP query) plus the number of signatures on the message (one for each key that is to be verified) plus the number of signatures that validated and that also bear an "atps" tag. This is in addition to any PTR and A queries the MTA might issue at the time the actual message relaying or delivery is initiated. Obviously, this can be burdensome on the DNS at both ends, and waiting for that number of queries to return when they are issued in parallel could trigger timeouts in the MTA.
参与DKIM、ADSP和ATPS的验证器现在将向DNS发出大量TXT查询，其数量等于一个（用于ADSP查询）加上消息上的签名数量（每个待验证密钥一个）加上已验证且也带有“ATPS”标记的签名数量。这是MTA在实际邮件中继或传递启动时可能发出的任何PTR和A查询的补充。显然，这对两端的DNS来说都是一个负担，当并行发出查询时，等待返回的查询数可能会触发MTA中的超时。
An alternative that has not yet been explored is the storage of the ATPS data at a specific URL tied to the Author's domain name. This would alleviate pressure on the DNS at the expense of requiring the ADMD to operate a web server (which has its own security implications) and the addition of the establishment of a TCP connection. Moreover, the Verifier would be well advised to implement caching of this data to prevent ATPS from being used as a denial-of-service vector.
另一种尚未探索的方法是将ATPS数据存储在与作者域名相关的特定URL上。这将减轻DNS的压力，代价是要求ADMD操作web服务器（这有其自身的安全隐患）并增加TCP连接的建立。此外，最好建议验证者实现该数据的缓存，以防止ATP被用作拒绝服务向量。
See Section 8.5 of [DKIM] for further discussion of DNS-related issues.
有关DNS相关问题的进一步讨论，请参见[DKIM]第8.5节。
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[AUTHRES] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
[AUTHRES]Kucherawy，M.，“用于指示消息身份验证状态的消息头字段”，RFC 54512009年4月。
[BASE32] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[BASE32]Josefsson，S.，“Base16、BASE32和Base64数据编码”，RFC4648，2006年10月。
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[DKIM]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，RFC 63762011年9月。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNS]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[EMAIL-ARCH]Crocker，D.，“互联网邮件体系结构”，RFC 55982009年7月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[邮件]Resnick，P.，Ed.，“互联网信息格式”，RFC5322，2008年10月。
[ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009.
[ADSP]Allman，E.，Fenton，J.，Delany，M.，和J.Levine，“域密钥识别邮件（DKIM）作者域签名实践（ADSP）”，RFC 56172009年8月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[IANA]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[IDNA] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[IDNA]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
This section presents an example of the use of this protocol to query for a third-party authorization and discusses the interpretation of the result.
本节介绍了使用此协议查询第三方授权的示例，并讨论了结果的解释。
Presume a message for which the RFC5322.From domain is "example.com", and it bears two valid signatures, from "one.example.net" and from "two.example.net", each with an "atps" tag whose value is "example.com", and an "atpsh" tag whose value is "sha1". The following actions are taken:
假设一条消息的RFC5322.From域是“example.com”，它有两个有效的签名，分别来自“one.example.net”和“two.example.net”，每个签名都有一个值为“example.com”的“atps”标记和一个值为“sha1”的“atpsh”标记。采取了以下行动：
1. A SHA1 hash of "one.example.net" is computed and then converted to printable form using base32 encoding, resulting in the string "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6".
1. 计算“one.example.net”的SHA1散列，然后使用base32编码将其转换为可打印形式，生成字符串“QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6”。
2. A TXT query is issued to "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps.example.com".
2. 向“QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps.example.com”发出TXT查询。
3. If a valid reply arrives, the algorithm stops with [AUTHRES] result "pass". If a DNS error code other than NXDOMAIN is returned, the algorithm stops with a result of "temperror" or "permerror" as appropriate.
3. 如果收到有效的回复，算法将停止，并显示[AUTHRES]结果“通过”。如果返回NXDOMAIN以外的DNS错误代码，则算法将停止，并根据情况显示“temperror”或“permerror”。
4. A SHA1 hash of "two.example.net" is computed and then converted to printable form using base32 encoding, resulting in the string "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX".
4. 计算“two.example.net”的SHA1散列，然后使用base32编码将其转换为可打印形式，生成字符串“ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX”。
5. A TXT query is issued to "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX._atps.example.com".
5. 向“ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX._atps.example.com”发出TXT查询。
6. If a valid reply arrives, the algorithm stops with [AUTHRES] result "pass". If a DNS error code other than NXDOMAIN is returned, the algorithm stops with a result of "temperror" or "permerror" as appropriate.
6. 如果收到有效的回复，算法将停止，并显示[AUTHRES]结果“通过”。如果返回NXDOMAIN以外的DNS错误代码，则算法将停止，并根据情况显示“temperror”或“permerror”。
7. As there are no valid signatures left to test, the algorithm stops with an "unknown" result.
7. 由于没有有效的签名可供测试，因此该算法将以“未知”结果停止。
It was proposed that this work appear within the DNS under a new Resource Record (RR) Type. Although this is possibly an appropriate thing to do, consideration was also given to the fact that major portions of DKIM already use an ASCII-based "tag=value" syntax, and store key and ADSP data in the DNS using TXT resource records. To enable re-use of existing DKIM code, it was decided to re-use the TXT message scheme.
有人建议这项工作以新的资源记录（RR）类型出现在DNS中。尽管这可能是一件合适的事情，但也考虑到DKIM的主要部分已经使用基于ASCII的“tag=value”语法，并使用TXT资源记录在DNS中存储密钥和ADSP数据。为了能够重用现有的DKIM代码，决定重用TXT消息方案。
The author wishes to acknowledge Dave Crocker, Frank Ellermann, Mark Martinec, and Phil Pennock for their review and constructive criticism of this proposal.
作者希望感谢Dave Crocker、Frank Ellermann、Mark Martinec和Phil Pennock对本提案的审查和建设性批评。
The author also wishes to acknowledge Doug Otis and Daniel Black for their original document, upon which this work was based.
作者还希望感谢Doug Otis和Daniel Black，感谢他们的原始文档，这部作品就是基于这些文档编写的。
Author's Address
作者地址
Murray S. Kucherawy Cloudmark, Inc. 128 King St., 2nd Floor San Francisco, CA 94107 US
MurayS.KuCaWaWy CuldMax公司，128国王圣，第二楼旧金山，CA 94107美国
Phone: +1 415 946 3800
EMail: msk@cloudmark.com
Phone: +1 415 946 3800
EMail: msk@cloudmark.com