Network Working Group                                          E. Allman
Request for Comments: 5617                                Sendmail, Inc.
Category: Standards Track                                      J. Fenton
                                                     Cisco Systems, Inc.
                                                               M. Delany
                                                             Yahoo! Inc.
                                                               J. Levine
                                                    Taughannock Networks
                                                             August 2009
        
Network Working Group                                          E. Allman
Request for Comments: 5617                                Sendmail, Inc.
Category: Standards Track                                      J. Fenton
                                                     Cisco Systems, Inc.
                                                               M. Delany
                                                             Yahoo! Inc.
                                                               J. Levine
                                                    Taughannock Networks
                                                             August 2009
        

DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)

域密钥识别邮件(DKIM)作者域签名实践(ADSP)

Abstract

摘要

DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise whether a domain signs its outgoing mail as well as how other hosts can access that record.

DomainKeys Identified Mail(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). 请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。

Table of Contents

目录

   1. Introduction ....................................................3
   2. Language and Terminology ........................................3
      2.1. Terms Imported from the DKIM Signatures Specification ......3
      2.2. Valid Signature ............................................4
      2.3. Author Address .............................................4
      2.4. Author Domain ..............................................4
      2.5. Alleged Author .............................................4
      2.6. Author Domain Signing Practices ............................4
      2.7. Author Domain Signature ....................................4
   3. Operation Overview ..............................................5
      3.1. ADSP Applicability .........................................5
      3.2. ADSP Usage .................................................6
      3.3. ADSP Results ...............................................6
   4. Detailed Description ............................................7
      4.1. DNS Representation .........................................7
      4.2. Publication of ADSP Records ................................7
           4.2.1. Record Syntax .......................................7
      4.3. ADSP Lookup Procedure ......................................9
   5. IANA Considerations ............................................10
      5.1. ADSP Specification Tag Registry ...........................10
      5.2. ADSP Outbound Signing Practices Registry ..................11
      5.3. Authentication-Results Method Registry Update .............11
      5.4. Authentication-Results Result Registry Update .............11
   6. Security Considerations ........................................13
      6.1. ADSP Threat Model .........................................14
      6.2. DNS Considerations ........................................14
      6.3. DNS Wildcards .............................................15
      6.4. Inappropriate Application of Author Domain Signatures .....15
   7. References .....................................................16
      7.1. Normative References ......................................16
      7.2. Informative References ....................................16
   Appendix A.  Lookup Examples ......................................17
     A.1.  Domain and ADSP Exist .....................................17
     A.2.  Domain Exists, ADSP Does Not Exist ........................17
     A.3.  Domain Does Not Exist .....................................17
   Appendix B.  Usage Examples .......................................18
     B.1.  Single Location Domains ...................................18
     B.2.  Bulk Mailing Domains ......................................18
     B.3.  Bulk Mailing Domains with Discardable Mail ................19
     B.4.  Third-Party Senders .....................................19
     B.5.  Domains with Independent Users and Liberal Use Policies ...19
     B.6.  Non-Email Domains .......................................20
   Appendix C.  Acknowledgements .....................................20
        
   1. Introduction ....................................................3
   2. Language and Terminology ........................................3
      2.1. Terms Imported from the DKIM Signatures Specification ......3
      2.2. Valid Signature ............................................4
      2.3. Author Address .............................................4
      2.4. Author Domain ..............................................4
      2.5. Alleged Author .............................................4
      2.6. Author Domain Signing Practices ............................4
      2.7. Author Domain Signature ....................................4
   3. Operation Overview ..............................................5
      3.1. ADSP Applicability .........................................5
      3.2. ADSP Usage .................................................6
      3.3. ADSP Results ...............................................6
   4. Detailed Description ............................................7
      4.1. DNS Representation .........................................7
      4.2. Publication of ADSP Records ................................7
           4.2.1. Record Syntax .......................................7
      4.3. ADSP Lookup Procedure ......................................9
   5. IANA Considerations ............................................10
      5.1. ADSP Specification Tag Registry ...........................10
      5.2. ADSP Outbound Signing Practices Registry ..................11
      5.3. Authentication-Results Method Registry Update .............11
      5.4. Authentication-Results Result Registry Update .............11
   6. Security Considerations ........................................13
      6.1. ADSP Threat Model .........................................14
      6.2. DNS Considerations ........................................14
      6.3. DNS Wildcards .............................................15
      6.4. Inappropriate Application of Author Domain Signatures .....15
   7. References .....................................................16
      7.1. Normative References ......................................16
      7.2. Informative References ....................................16
   Appendix A.  Lookup Examples ......................................17
     A.1.  Domain and ADSP Exist .....................................17
     A.2.  Domain Exists, ADSP Does Not Exist ........................17
     A.3.  Domain Does Not Exist .....................................17
   Appendix B.  Usage Examples .......................................18
     B.1.  Single Location Domains ...................................18
     B.2.  Bulk Mailing Domains ......................................18
     B.3.  Bulk Mailing Domains with Discardable Mail ................19
     B.4.  Third-Party Senders .....................................19
     B.5.  Domains with Independent Users and Liberal Use Policies ...19
     B.6.  Non-Email Domains .......................................20
   Appendix C.  Acknowledgements .....................................20
        
1. Introduction
1. 介绍

DomainKeys Identified Mail (DKIM) defines a mechanism by which email messages can be cryptographically signed, permitting a signing domain to claim responsibility for the introduction of a message into the mail stream. Message recipients can verify the signature by querying the Signer's domain directly to retrieve the appropriate public key, and thereby confirm that the message was attested to by a party in possession of the private key for the signing domain.

DomainKeys Identified Mail(DKIM)定义了一种机制,通过该机制可以对电子邮件进行加密签名,从而允许签名域声明将消息引入邮件流的责任。消息接收者可以通过直接查询签名者的域以检索适当的公钥来验证签名,从而确认消息已由拥有签名域私钥的一方证明。

However, the legacy of the Internet is such that not all messages will be signed, and the absence of a signature on a message is not an a priori indication of forgery. In fact, during early phases of deployment, it is very likely that most messages will remain unsigned. However, some domains might decide to sign all of their outgoing mail, for example, to protect their brand names. It might be desirable for such domains to be able to advertise that fact to other hosts. This is the topic of Author Domain Signing Practices (ADSP).

然而,互联网的遗留问题是,并非所有消息都会被签名,消息上没有签名也不是伪造的先验迹象。事实上,在部署的早期阶段,很可能大多数消息都没有签名。然而,有些域名可能会决定对所有发送的邮件进行签名,例如,以保护其品牌名称。这类域可能希望能够向其他主机公布这一事实。这是作者域签名实践(ADSP)的主题。

Hosts implementing this specification can inquire what Author Domain Signing Practices a domain advertises. This inquiry is called an Author Domain Signing Practices check.

实现此规范的主机可以查询作者域签名在域广告中的做法。此查询称为作者域签名实践检查。

The basic requirements for ADSP are given in [RFC5016]. This document refers extensively to [RFC4871] and assumes the reader is familiar with it.

[RFC5016]中给出了ADSP的基本要求。本文档广泛引用[RFC4871],并假设读者熟悉该文档。

Requirements Notation:

要求符号:

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]中所述进行解释。

2. Language and Terminology
2. 语言和术语
2.1. Terms Imported from the DKIM Signatures Specification
2.1. 从DKIM签名规范导入的术语

Some terminology used herein is derived directly from [RFC4871]. In several cases, references in that document to "Sender" have been changed to "Author" here, to emphasize the relationship to the Author address(es) in the From: header field described in [RFC5322]. Briefly,

本文使用的一些术语直接来源于[RFC4871]。在某些情况下,该文档中对“发件人”的引用已在此处更改为“作者”,以强调与[RFC5322]中所述发件人:标题字段中作者地址的关系。短暂地

o A "Signer" is the agent that signs a message, as defined in Section 2.1 of [RFC4871].

o “签名者”是对消息进行签名的代理,如[RFC4871]第2.1节所定义。

o A "Local-part" is the part of an address preceding the @ character, as defined in [RFC5322] and used in [RFC4871].

o “本地部分”是地址中@字符前面的部分,如[RFC5322]中定义并在[RFC4871]中使用。

2.2. Valid Signature
2.2. 有效签名

A "Valid Signature" is any signature on a message that correctly verifies using the procedure described in Section 6.1 of [RFC4871].

“有效签名”是指使用[RFC4871]第6.1节所述程序正确验证的消息上的任何签名。

2.3. Author Address
2.3. 作者地址

An "Author Address" is an email address in the From: header field of a message [RFC5322]. If the From: header field contains multiple addresses, the message has multiple Author Addresses.

“作者地址”是消息[RFC5322]的发件人:标题字段中的电子邮件地址。如果发件人:标头字段包含多个地址,则消息具有多个作者地址。

2.4. Author Domain
2.4. 作者域

An "Author Domain" is everything to the right of the "@" in an Author Address (excluding the "@" itself).

“作者域”是作者地址中“@”右边的所有内容(不包括“@”本身)。

2.5. Alleged Author
2.5. 指称的作者

An "Alleged Author" is an Author Address of a message; it is "alleged" because it has not yet been checked.

“被指控的作者”是消息的作者地址;这是“声称的”,因为它还没有被检查。

2.6. Author Domain Signing Practices
2.6. 作者域签名实践

"Author Domain Signing Practices" (or just "practices") consist of a machine-readable record published by the domain of an Alleged Author that includes statements about the domain's practices with respect to mail it sends with its domain in the From: line.

“作者域签名实践”(或简称“实践”)由声称作者的域发布的机器可读记录组成,其中包括关于域在发件人:行中与其域一起发送邮件的实践的声明。

2.7. Author Domain Signature
2.7. 作者域签名

An "Author Domain Signature" is a Valid Signature in which the domain name of the DKIM signing entity, i.e., the d= tag in the DKIM-Signature header field, is the same as the domain name in the Author Address. Following [RFC5321], domain name comparisons are case insensitive.

“作者域签名”是一种有效的签名,其中DKIM签名实体的域名,即DKIM签名头字段中的d=标记,与作者地址中的域名相同。[RFC5321]之后,域名比较不区分大小写。

For example, if the From: line address is bob@domain.example, and the message has a Valid Signature with the DKIM-Signature header field containing "d=domain.example", then the message has an Author Domain Signature.

例如,如果From:行地址为bob@domain.example,消息具有有效的签名,DKIM签名头字段包含“d=domain.example”,则消息具有作者域签名。

3. Operation Overview
3. 操作概述

Domain owners publish ADSP information via a query mechanism such as the Domain Name System; specific details are given in Section 4.1. Hosts can look up the ADSP information of the domain(s) specified by the Author Address(es) as described in Section 4.3. If a message has multiple Author Addresses, the ADSP lookups SHOULD be performed independently on each address. This document does not address the process a host might use to combine the lookup results.

域名所有者通过域名系统等查询机制发布ADSP信息;具体细节见第4.1节。如第4.3节所述,主机可以查找由作者地址指定的域的ADSP信息。如果一条消息有多个作者地址,则应在每个地址上独立执行ADSP查找。本文档不涉及主机可能用于组合查找结果的进程。

3.1. ADSP Applicability
3.1. ADSP适用性

ADSP as defined in this document is bound to DNS. For this reason, ADSP is applicable only to Author Domains with appropriate DNS records (i.e., A, AAAA, and/or MX) indicating the possible use of the domain for email. The handling of other Author Domains is outside the scope of this document. However, attackers may use such domain names in a deliberate attempt to sidestep an organization's ADSP policy statements. It is up to the ADSP checker implementation to return an appropriate error result for Author Domains outside the scope of ADSP.

本文档中定义的ADSP绑定到DNS。因此,ADSP仅适用于具有适当DNS记录(即A、AAAA和/或MX)的作者域,这些记录表明该域可能用于电子邮件。其他作者域的处理超出了本文档的范围。但是,攻击者可能会故意使用此类域名来规避组织的ADSP策略声明。由ADSP检查器实现为ADSP范围之外的作者域返回适当的错误结果。

ADSP applies to specific domains, not domain subtrees. If, for example, an Author Address were user@domain.example, the Author Domain would be domain.example, and the applicable ADSP record would be at _adsp._domainkey.domain.example. An Author Address in a subdomain such as user@sub.domain.example would have a different ADSP record at _adsp._domainkey.sub.domain.example. ADSP makes no connection between a domain and its parent or child domains.

ADSP适用于特定的域,而不是域子树。例如,如果作者地址为user@domain.example,作者域将是Domain.example,适用的ADSP记录将位于_ADSP._domainkey.Domain.example。子域中的作者地址,如user@sub.domain.example将在_ADSP._domainkey.sub.domain.example处具有不同的ADSP记录。ADSP在域与其父域或子域之间不建立连接。

Note: If an organization wants to publish Author Domain Signing Practices for all the subdomains it uses, such as host names of servers within the domain, it does so by creating ADSP records for every _adsp._domainkey.<sub>.domain.example. Wildcards cannot be used (see Section 6.3.); however, suitable DNS management tools could automate creation of the ADSP records.

注意:如果一个组织想要发布其使用的所有子域的作者域签名实践,例如域内服务器的主机名,那么它可以通过为每个_ADSP._domainkey.<sub>.Domain.example创建ADSP记录来实现。不能使用通配符(见第6.3节);然而,合适的DNS管理工具可以自动创建ADSP记录。

Note: The results from DNS queries that are intended to validate a domain name unavoidably approximate the set of Author Domains that can appear in legitimate email. For example, a DNS A record could belong to a device that does not even have an email implementation. It is up to the checker to decide what degree of approximation is acceptable.

注意:用于验证域名的DNS查询的结果不可避免地近似于合法电子邮件中可能出现的作者域集。例如,DNS a记录可能属于甚至没有电子邮件实现的设备。由检查人员决定可接受的近似程度。

3.2. ADSP Usage
3.2. ADSP使用

Depending on the Author Domain(s) and the signatures in a message, a recipient gets varying amounts of useful information from each ADSP lookup.

根据邮件中的作者域和签名,收件人从每次ADSP查找中获得不同数量的有用信息。

o If a message has no Valid Signature, the ADSP result is directly relevant to the message.

o 如果消息没有有效的签名,则ADSP结果与消息直接相关。

o If a message has an Author Domain Signature, ADSP provides no benefit relative to that domain since the message is already known to be compliant with any possible ADSP for that domain.

o 如果消息具有作者域签名,则ADSP不会提供与该域相关的任何好处,因为已知该消息与该域的任何可能的ADSP兼容。

o If a message has a Valid Signature other than an Author Domain Signature, the receiver can use both the Signature and the ADSP result in its evaluation of the message.

o 如果消息具有作者域签名以外的有效签名,则接收方可以使用签名和ADSP结果对消息进行评估。

3.3. ADSP Results
3.3. ADSP结果

An ADSP lookup for an Author Address produces one of four possible results:

ADSP查找作者地址会产生以下四种可能结果之一:

o Messages from this domain might or might not have an Author Domain Signature. This is the default if the domain exists in the DNS but no ADSP record is found.

o 来自此域的邮件可能有作者域签名,也可能没有作者域签名。如果DNS中存在域,但未找到ADSP记录,则这是默认值。

o All messages from this domain are signed with an Author Domain Signature.

o 来自此域的所有邮件都使用作者域签名进行签名。

o All messages from this domain are signed with an Author Domain Signature and are discardable, i.e., if a message arrives without a valid Author Domain Signature, the domain encourages the recipient(s) to discard it.

o 来自此域的所有邮件都使用作者域签名进行签名,并且可以丢弃,即,如果邮件到达时没有有效的作者域签名,则域会鼓励收件人丢弃该邮件。

o This domain is out of scope, i.e., the domain does not exist in the DNS.

o 此域超出范围,即DNS中不存在该域。

An ADSP lookup could terminate without producing any result if a DNS lookup results in a temporary failure.

如果DNS查找导致临时故障,ADSP查找可能会终止而不产生任何结果。

4. Detailed Description
4. 详细说明
4.1. DNS Representation
4.1. DNS表示

ADSP records are published using the DNS TXT resource record type.

ADSP记录使用DNS TXT资源记录类型发布。

The RDATA for ADSP resource records is textual in format, with specific syntax and semantics relating to their role in describing ADSP. The "Tag=Value List" syntax described in Section 3.2 of [RFC4871] is used, modified to use whitespace (WSP) rather than folding whitespace (FWS). Records not in compliance with that syntax or the syntax of individual tags described in Section 4.3 MUST be ignored (considered equivalent to a NODATA result) for purposes of ADSP, although they MAY cause the logging of warning messages via an appropriate system logging mechanism. If the RDATA contains multiple character strings, the strings are logically concatenated with no delimiters between the strings.

ADSP资源记录的RDATA是文本格式,具有与其在描述ADSP中的角色相关的特定语法和语义。使用[RFC4871]第3.2节中描述的“Tag=Value List”语法,修改为使用空白(WSP)而不是折叠空白(FWS)。出于ADSP的目的,必须忽略不符合该语法或第4.3节所述单个标记语法的记录(视为等同于NODATA结果),尽管它们可能会通过适当的系统日志记录机制记录警告消息。如果RDATA包含多个字符串,则字符串在逻辑上是串联的,且字符串之间没有分隔符。

Note: ADSP changes the "Tag=Value List" syntax from [RFC4871] to use WSP rather than FWS in its DNS records.

注意:ADSP将“Tag=Value List”语法从[RFC4871]更改为在其DNS记录中使用WSP而不是FWS。

Domains MUST NOT publish ADSP records with wildcard names. Wildcards within a domain publishing ADSP records pose a particular problem, as discussed in more detail in Section 6.3.

域不得发布具有通配符名称的ADSP记录。域内的通配符发布ADSP记录会带来一个特殊的问题,如第6.3节所述。

4.2. Publication of ADSP Records
4.2. 公布ADSP记录

ADSP is intended to apply to all mail sent using the domain name string of an Alleged Author.

ADSP适用于所有使用所谓作者的域名字符串发送的邮件。

4.2.1. Record Syntax
4.2.1. 记录语法

ADSP records use the "tag=value" syntax described in Section 3.2 of [RFC4871], modified to use WSP rather than FWS. Every ADSP record MUST start with an outbound signing-practices tag, so the first four characters of the record are lowercase "dkim", followed by optional whitespace and "=".

ADSP记录使用[RFC4871]第3.2节中描述的“tag=value”语法,修改为使用WSP而不是FWS。每个ADSP记录必须以outbound signing practices标记开头,因此记录的前四个字符是小写的“dkim”,后跟可选的空格和“=”。

Tags used in ADSP records are described below. Unrecognized tags MUST be ignored. In the ABNF below, the WSP token is imported from [RFC5234].

ADSP记录中使用的标签如下所述。必须忽略无法识别的标记。在下面的ABNF中,WSP令牌从[RFC5234]导入。

dkim= Outbound Signing Practices for the domain (plain-text; REQUIRED). Possible values are as follows:

dkim=域的出站签名实践(纯文本;必需)。可能的值如下所示:

unknown The domain might sign some or all email.

未知域可能会签署部分或全部电子邮件。

all All mail from the domain is signed with an Author Domain Signature.

域中的所有邮件都使用作者域签名进行签名。

discardable All mail from the domain is signed with an Author Domain Signature. Furthermore, if a message arrives without a valid Author Domain Signature due to modification in transit, submission via a path without access to a signing key, or any other reason, the domain encourages the recipient(s) to discard it.

域中的所有可丢弃邮件都使用作者域签名进行签名。此外,如果由于传输中的修改、通过无法访问签名密钥的路径提交或任何其他原因,邮件到达时没有有效的作者域签名,则域会鼓励收件人放弃该邮件。

Any other values are treated as "unknown".

任何其他值都被视为“未知”。

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:
        
   ; 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.
        
   ; - 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.
        
   ; - 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.
        
   ; 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 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.
        
        adsp-dkim-tag = %x64.6b.69.6d *WSP "=" *WSP
                        ("unknown" / "all" / "discardable" /
                         x-adsp-dkim-tag)
        x-adsp-dkim-tag = hyphenated-word   ; for future extension
        ; hyphenated-word is defined in RFC 4871
        
        adsp-dkim-tag = %x64.6b.69.6d *WSP "=" *WSP
                        ("unknown" / "all" / "discardable" /
                         x-adsp-dkim-tag)
        x-adsp-dkim-tag = hyphenated-word   ; for future extension
        ; hyphenated-word is defined in RFC 4871
        
4.3. ADSP Lookup Procedure
4.3. ADSP查找程序

Hosts doing an ADSP lookup MUST produce a result that is semantically equivalent to applying the following steps in the order listed below. In practice, these steps can be performed in parallel in order to improve performance. However, implementations SHOULD avoid doing unnecessary DNS lookups.

执行ADSP查找的主机必须生成一个结果,该结果在语义上等同于按照下面列出的顺序应用以下步骤。实际上,这些步骤可以并行执行,以提高性能。但是,实现应该避免进行不必要的DNS查找。

For the purposes of this section, a "valid ADSP record" is one that is both syntactically and semantically correct; in particular, it matches the ABNF for a "tag-list" and starts with a valid "dkim" tag.

就本节而言,“有效ADSP记录”是指在语法和语义上都正确的记录;特别是,它匹配ABNF的“标记列表”,并以有效的“dkim”标记开始。

Check Domain Scope: An ADSP checker implementation MUST determine whether a given Author Domain is within the scope for ADSP. Given the background in Section 3.1, the checker MUST decide which degree of approximation is acceptable. The checker MUST return an appropriate error result for Author Domains that are outside the scope of ADSP.

检查域范围:ADSP检查器实现必须确定给定的作者域是否在ADSP的范围内。鉴于第3.1节中的背景,检查人员必须确定可接受的近似程度。对于ADSP范围之外的作者域,检查程序必须返回适当的错误结果。

The host MUST perform a DNS query for a record corresponding to the Author Domain (with no prefix). The type of the query can be of any type, since this step is only to determine if the domain itself exists in DNS. This query MAY be done in parallel with the query to fetch the named ADSP Record. If the result of this query is that the Author Domain does not exist in the DNS (often called an NXDOMAIN error, rcode=3 in [RFC1035]), the algorithm MUST terminate with an error indicating that the domain is out of scope. Note that a result with rcode=0 but no records (often called NODATA) is not the same as NXDOMAIN.

主机必须对与作者域(无前缀)对应的记录执行DNS查询。查询的类型可以是任何类型,因为此步骤仅用于确定DNS中是否存在域本身。此查询可以与获取命名ADSP记录的查询并行进行。如果此查询的结果是DNS中不存在作者域(通常称为NXDOMAIN错误,[RFC1035]中的rcode=3),则算法必须终止,并显示一个错误,表明该域超出范围。请注意,rcode=0但没有记录(通常称为NODATA)的结果与NXDOMAIN不同。

NON-NORMATIVE DISCUSSION: Any resource record type could be used for this query since the existence of a resource record of any type will prevent an NXDOMAIN error. MX is a reasonable choice for this purpose because this record type is thought to be the most common for domains used in email, and will therefore produce a result that can be more readily cached than a negative result.

非规范性讨论:任何类型的资源记录都可以用于此查询,因为任何类型的资源记录都可以防止NXDOMAIN错误。MX是用于此目的的合理选择,因为此记录类型被认为是电子邮件中使用的域中最常见的记录类型,因此将产生比负面结果更容易缓存的结果。

If the domain does exist, the checker MAY make more extensive checks to verify the existence of the domain, such as the ones described in Section 5 of [RFC5321]. If those checks indicate

如果域确实存在,则检查者可进行更广泛的检查,以验证域的存在,如[RFC5321]第5节所述。如果这些检查表明

that the Author Domain does not exist for mail, e.g., the domain has no MX, A, or AAAA record, the checker SHOULD terminate with an error indicating that the domain is out of scope.

如果邮件的作者域不存在,例如,该域没有MX、A或AAAA记录,则检查程序应终止,并显示一个错误,表明该域超出范围。

Fetch Named ADSP Record: The host MUST query DNS for a TXT record corresponding to the Author Domain prefixed by "_adsp._domainkey." (note the trailing dot).

获取命名的ADSP记录:主机必须在DNS中查询与作者域(前缀为“\u ADSP.\u domainkey.”(注意后面的点)对应的TXT记录。

If the result of this query is a NOERROR response (rcode=0 in [RFC1035]) with an answer that is a single record that is a valid ADSP record, use that record, and the algorithm terminates.

如果此查询的结果是一个无错误响应(在[RFC1035]中,rcode=0),其答案是一条有效的ADSP记录,则使用该记录,算法终止。

If the result of the query is NXDOMAIN or NOERROR with zero records, there is no ADSP record. If the result of the query contains more than one record, or a record that is not a valid ADSP record, the ADSP result is undefined.

如果查询结果为NXDOMAIN或无错误且记录为零,则不存在ADSP记录。如果查询结果包含多个记录,或记录不是有效的ADSP记录,则ADSP结果未定义。

If a query results in a "SERVFAIL" error response (rcode=2 in [RFC1035]), the algorithm terminates without returning a result; possible actions include queuing the message or returning an SMTP error indicating a temporary failure.

如果查询导致“SERVFAIL”错误响应(在[RFC1035]中,rcode=2),则算法终止而不返回结果;可能的操作包括将邮件排队或返回指示临时故障的SMTP错误。

See Appendix A for examples of ADSP lookup.

有关ADSP查找的示例,请参见附录A。

5. IANA Considerations
5. IANA考虑

ADSP adds the following namespaces to the IANA registry. In all cases, new values are assigned only for values that have been documented in a published RFC after IETF Review, as specified in [RFC5226].

ADSP将以下名称空间添加到IANA注册表中。在所有情况下,按照[RFC5226]中的规定,新值仅分配给IETF审查后已发布的RFC中记录的值。

5.1. ADSP Specification Tag Registry
5.1. ADSP规范标记注册表

An ADSP record provides for a list of specification tags. IANA has established the ADSP Specification Tag Registry for specification tags that can be used in ADSP fields.

ADSP记录提供规范标签列表。IANA已为可在ADSP字段中使用的规范标记建立了ADSP规范标记注册表。

The initial entry in the registry is:

注册表中的初始条目为:

                         +------+-----------------+
                         | TYPE | REFERENCE       |
                         +------+-----------------+
                         | dkim | (RFC 5617)      |
                         +------+-----------------+
        
                         +------+-----------------+
                         | TYPE | REFERENCE       |
                         +------+-----------------+
                         | dkim | (RFC 5617)      |
                         +------+-----------------+
        

ADSP Specification Tag Registry Initial Values

ADSP规范标记注册表初始值

5.2. ADSP Outbound Signing Practices Registry
5.2. ADSP出站签名实践注册表

The "dkim=" tag specification, defined in Section 4.2.1, provides for a value specifying Outbound Signing Practices. IANA has established the ADSP Outbound Signing Practices Registry for Outbound Signing Practices.

第4.2.1节中定义的“dkim=”标签规范提供了一个值,用于指定出站签名实践。IANA已经为出站签名实践建立了ADSP出站签名实践注册中心。

The initial entries in the registry comprise:

登记册中的初始条目包括:

                     +-------------+-----------------+
                     | TYPE        | REFERENCE       |
                     +-------------+-----------------+
                     | unknown     | (RFC 5617)      |
                     | all         | (RFC 5617)      |
                     | discardable | (RFC 5617)      |
                     +-------------+-----------------+
        
                     +-------------+-----------------+
                     | TYPE        | REFERENCE       |
                     +-------------+-----------------+
                     | unknown     | (RFC 5617)      |
                     | all         | (RFC 5617)      |
                     | discardable | (RFC 5617)      |
                     +-------------+-----------------+
        

ADSP Outbound Signing Practices Registry Initial Values

ADSP出站签名实践注册表初始值

5.3. Authentication-Results Method Registry Update
5.3. 验证结果方法注册表更新

IANA has added the following to the Email Authentication Method Name Registry:

IANA已将以下内容添加到电子邮件身份验证方法名称注册表中:

Method: dkim-adsp

方法:dkim-adsp

Defined In: RFC 5617

定义见:RFC 5617

ptype: header

p类型:标题

property: from

物业:来自

value: contents of the [RFC5322] From: header field, with comments removed

值:[RFC5322]发件人:标题字段的内容,删除注释

5.4. Authentication-Results Result Registry Update
5.4. 验证结果注册表更新

IANA has added the following in the Email Authentication Result Name Registry:

IANA在电子邮件身份验证结果名称注册表中添加了以下内容:

Code: none

代码:无

Existing/New Code: existing

现有/新代码:现有

Defined In: [RFC5451]

定义于:[RFC5451]

Auth Method: dkim-adsp (added)

验证方法:dkim adsp(新增)

Meaning: No DKIM Author Domain Signing Practices (ADSP) record was published.

含义:未发布DKIM作者域签名实践(ADSP)记录。

Code: pass

代码:pass

Existing/New Code: existing

现有/新代码:现有

Defined In: [RFC5451]

定义于:[RFC5451]

Auth Method: dkim-adsp (added)

验证方法:dkim adsp(新增)

Meaning: This message had an Author Domain Signature that was validated. (An ADSP check is not strictly required to be performed for this result since a valid Author Domain Signature satisfies all possible ADSP policies.)

含义:此邮件具有已验证的作者域签名。(由于有效的作者域签名满足所有可能的ADSP策略,因此不严格要求对此结果执行ADSP检查。)

Code: unknown

代码:未知

Existing/New Code: new

现有/新代码:新

Defined In: RFC 5617

定义见:RFC 5617

Auth Method: dkim-adsp

身份验证方法:dkim adsp

Meaning: No valid Author Domain Signature was found on the message and the published ADSP was "unknown".

意思:在邮件上找不到有效的作者域签名,发布的ADSP为“未知”。

Code: fail

代码:失败

Existing/New Code: existing

现有/新代码:现有

Defined In: [RFC5451]

定义于:[RFC5451]

Auth Method: dkim-adsp (added)

验证方法:dkim adsp(新增)

Meaning: No valid Author Domain Signature was found on the message and the published ADSP was "all".

意思:在邮件上找不到有效的作者域签名,发布的ADSP为“全部”。

Code: discard

代码:放弃

Existing/New Code: new

现有/新代码:新

Defined In: RFC 5617

定义见:RFC 5617

Auth Method: dkim-adsp

身份验证方法:dkim adsp

Meaning: No valid Author Domain Signature was found on the message and the published ADSP was "discardable".

意思:在邮件上找不到有效的作者域签名,并且发布的ADSP是“可丢弃的”。

Code: nxdomain

代码:nxdomain

Existing/New Code: new

现有/新代码:新

Defined In: RFC 5617

定义见:RFC 5617

Auth Method: dkim-adsp

身份验证方法:dkim adsp

Meaning: Evaluating the ADSP for the Author's DNS domain indicated that the Author's DNS domain does not exist.

含义:评估作者DNS域的ADSP表明作者的DNS域不存在。

Code: temperror

代码:temperor

Existing/New Code: existing

现有/新代码:现有

Defined In: [RFC5451]

定义于:[RFC5451]

Auth Method: dkim-adsp (added)

验证方法:dkim adsp(新增)

Meaning: An ADSP record could not be retrieved due to some error that is likely transient in nature, such as a temporary DNS error. A later attempt may produce a final result.

含义:由于某些可能是暂时性的错误,例如临时DNS错误,无法检索ADSP记录。以后的尝试可能会产生最终结果。

Code: permerror

代码:permerror

Existing/New Code: existing

现有/新代码:现有

Defined In: [RFC5451]

定义于:[RFC5451]

Auth Method: dkim-adsp (added)

验证方法:dkim adsp(新增)

Meaning: An ADSP record could not be retrieved due to some error that is likely not transient in nature, such as a permanent DNS error. A later attempt is unlikely to produce a final result.

含义:由于某些可能不是暂时性的错误,例如永久性DNS错误,无法检索ADSP记录。以后的尝试不太可能产生最终结果。

6. Security Considerations
6. 安全考虑

Security considerations in the ADSP are mostly related to attempts on the part of malicious senders to represent themselves as Authors for whom they are not authorized to send mail, often in an attempt to defraud either the recipient or an Alleged Author.

ADSP中的安全考虑主要与恶意发件人试图将自己描述为未经授权发送邮件的作者有关,通常是为了欺骗收件人或被指控的作者。

Additional security considerations regarding Author Domain Signing Practices are found in the DKIM threat analysis [RFC4686].

关于作者域签名实践的其他安全考虑,请参见DKIM威胁分析[RFC4686]。

6.1. ADSP Threat Model
6.1. ADSP威胁模型

Email recipients often have a core set of content Authors that they already trust. Common examples include financial institutions with which they have an existing relationship and Internet web transaction sites with which they conduct business.

电子邮件收件人通常有一组他们已经信任的核心内容作者。常见的例子包括与其有现有关系的金融机构以及与其开展业务的互联网交易网站。

Email abuse often seeks to exploit a legitimate email Author's name-recognition among recipients by using the Author's domain name in the From: header field. Especially since many popular Mail User Agents (MUAs) do not display the Author's email address, there is no empirical evidence of the extent that this particular unauthorized use of a domain name contributes to recipient deception or that eliminating it will have significant effect.

电子邮件滥用通常试图通过在发件人:标题字段中使用作者的域名,利用收件人之间合法的电子邮件作者姓名识别。特别是由于许多流行的邮件用户代理(MUA)不显示作者的电子邮件地址,因此没有经验证据表明这种未经授权使用域名的行为在多大程度上导致了收件人欺骗,或者消除它将产生重大影响。

However, closing this potential exploit could facilitate some types of optimized processing by receive-side message filtering engines, since it could permit them to maintain higher-confidence assertions about From: header field uses of a domain when the occurrence is authorized.

但是,关闭此潜在漏洞可能有助于接收端消息过滤引擎进行某些类型的优化处理,因为这可以使它们在授权事件时对域的From:头字段使用保持更高的可信度。

Unauthorized uses of domain names occur elsewhere in messages, as do unauthorized uses of organizations' names. These attacks are outside the scope of this specification.

未经授权的域名使用发生在邮件的其他地方,组织名称的未经授权使用也是如此。这些攻击不在本规范的范围内。

ADSP does not provide any benefit -- nor, indeed, have any effect at all -- unless an external system acts upon the verdict, either by treating the message differently during the delivery process or by showing some indicator to the end recipient. Such a system is out of scope for this specification.

ADSP不提供任何好处——事实上,也没有任何效果——除非外部系统根据判决采取行动,在传递过程中以不同的方式处理消息,或者向最终接收者显示一些指标。此类系统超出本规范的范围。

ADSP checkers may perform multiple DNS lookups per Alleged Author Domain. Since these lookups are driven by domain names in email message headers of possibly fraudulent email, legitimate ADSP checkers can become participants in traffic multiplication attacks on domains that appear in fraudulent email.

ADSP检查器可以对每个声称的作者域执行多个DNS查找。由于这些查找是由可能存在欺诈性电子邮件的电子邮件消息头中的域名驱动的,因此合法的ADSP检查器可能成为欺诈性电子邮件中出现的域流量倍增攻击的参与者。

6.2. DNS Considerations
6.2. DNS注意事项

An attacker might attack the DNS infrastructure in an attempt to impersonate ADSP records to influence a receiver's decision on how it will handle mail. However, such an attacker is more likely to attack at a higher level, e.g., redirecting A or MX record lookups in order to capture traffic that was legitimately intended for the target domain. These DNS security issues are addressed by DNSSEC [RFC4033].

攻击者可能攻击DNS基础设施,试图模拟ADSP记录,以影响接收者处理邮件的决定。但是,此类攻击者更有可能在更高级别进行攻击,例如,重定向或MX记录查找,以捕获合法用于目标域的流量。这些DNS安全问题由DNSSEC[RFC4033]解决。

Because ADSP operates within the framework of the legacy email system, the default result in the absence of an ADSP record is that the domain does not sign all of its messages. It is therefore important that the ADSP clients distinguish a DNS failure such as "SERVFAIL" from other DNS errors so that appropriate actions can be taken.

由于ADSP在传统电子邮件系统的框架内运行,因此在没有ADSP记录的情况下,默认结果是域不会对其所有消息进行签名。因此,ADSP客户端必须将DNS故障(如“SERVFAIL”)与其他DNS错误区分开来,以便采取适当的措施。

6.3. DNS Wildcards
6.3. DNS通配符

DNS wildcards (described in [RFC4592]) that exist in the DNS hierarchy at or above the domain being checked interfere with the ability to verify the scope of the ADSP check described in Section 4.3. For example, a wildcard record for *.domain.example makes all subdomains such as foo.domain.example exist in the DNS. Domains that intend to make active use of ADSP by publishing a practice other than unknown are advised to avoid the use of wildcards in their hierarchy.

存在于被检查域或其上的DNS层次结构中的DNS通配符(如[RFC4592]所述)会干扰验证第4.3节所述ADSP检查范围的能力。例如,*.domain.example的通配符记录使所有子域(如foo.domain.example)都存在于DNS中。建议打算通过发布非未知实践来积极使用ADSP的域避免在其层次结构中使用通配符。

If a domain contains wildcards, then any name that matches the wildcard can appear to be a valid mail domain eligible for ADSP. But the "_adsp._domainkey." prefix on ADSP records does not allow publication of wildcard records that cover ADSP records without also covering non-ADSP records, nor does it allow publication of wildcard records that cover non-ADSP records without also covering ADSP records. A domain that uses ADSP practices other than unknown SHOULD NOT publish wildcard records.

如果域包含通配符,则与通配符匹配的任何名称都可能是符合ADSP条件的有效邮件域。但adsp记录上的“_adsp._domainkey.”前缀不允许发布覆盖adsp记录但不覆盖非adsp记录的通配符记录,也不允许发布覆盖非adsp记录但不覆盖adsp记录的通配符记录。使用非未知ADSP实践的域不应发布通配符记录。

6.4. Inappropriate Application of Author Domain Signatures
6.4. 作者域签名的不当应用

In one model of DKIM usage, a domain signs messages that are in transit through their system. Since any signature whose domain matches the Author Domain is, by definition, an Author Domain Signature, it would be unwise to sign mail whose Author Domain is the Signer's domain if the mail is not known to meet the domain's standards for an Author Domain Signature.

在DKIM使用的一种模型中,域对通过其系统传输的消息进行签名。由于根据定义,域与作者域匹配的任何签名都是作者域签名,因此,如果已知邮件不符合域的作者域签名标准,则对作者域为签名者域的邮件进行签名是不明智的。

One such use case is where a domain might apply such a signature following application of an Authentication-Results header field as described in Section 7.1 of [RFC5451]. This problem can be easily avoided either by not applying a signature that might be confused with an Author Domain Signature or by applying a signature from some other domain, such as a subdomain of the Author Domain.

一个这样的用例是域在应用[RFC5451]第7.1节中描述的身份验证结果报头字段后可以应用这样的签名。通过不应用可能与作者域签名混淆的签名,或者应用来自其他域(例如作者域的子域)的签名,可以轻松避免此问题。

7. References
7. 工具书类
7.1. Normative References
7.1. 规范性引用文件

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[RFC1035]Mockapetris,P.,“域名-实现和规范”,STD 13,RFC 1035,1987年11月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.

[RFC4033]Arends,R.,Austein,R.,Larson,M.,Massey,D.,和S.Rose,“DNS安全介绍和要求”,RFC 4033,2005年3月。

[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, July 2006.

[RFC4592]Lewis,E.,“通配符在域名系统中的作用”,RFC4592,2006年7月。

[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月。

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5226]Narten,T.和H.Alvestrand,“在RFCs中编写IANA注意事项部分的指南”,BCP 26,RFC 5226,2008年5月。

[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

[RFC5234]Crocker,D.和P.Overell,“语法规范的扩充BNF:ABNF”,STD 68,RFC 5234,2008年1月。

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.

[RFC5322]Resnick,P.,Ed.“互联网信息格式”,RFC5222008年10月。

[RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.

[RFC5451]Kucherawy,M.,“用于指示消息身份验证状态的消息头字段”,RFC 5451,2009年4月。

7.2. Informative References
7.2. 资料性引用

[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006.

[RFC4686]Fenton,J.,“驱动域密钥识别邮件(DKIM)的威胁分析”,RFC4686,2006年9月。

[RFC5016] Thomas, M., "Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol", RFC 5016, October 2007.

[RFC5016]Thomas,M.“域密钥识别邮件(DKIM)签名实践协议的要求”,RFC 5016,2007年10月。

[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.

[RFC5321]Klensin,J.,“简单邮件传输协议”,RFC 53212008年10月。

Appendix A. Lookup Examples
附录A.查找示例

Assume the example domain publishes these DNS records (in these examples, the numbers in parentheses are comments to help identify the records, not part of the records themselves):

假设示例域发布这些DNS记录(在这些示例中,括号中的数字是有助于识别记录的注释,而不是记录本身的一部分):

aaa.example A 192.0.2.1 (1) _adsp._domainkey.aaa.example TXT "dkim=all" (2)

aaa.example A 192.0.2.1(1)\u adsp.\u domainkey.aaa.example TXT“dkim=all”(2)

bbb.example MX 10 mail.bbb.example (3) mail.bbb.example A 192.0.2.2 (4)

bbb.example MX 10 mail.bbb.example(3)mail.bbb.example A 192.0.2.2(4)

A.1. Domain and ADSP Exist
A.1. 域和ADSP存在

A mail message contains this From: header line:

邮件包含以下发件人:标题行:

From: bob@aaa.example (Bob the Author)

发件人:bob@aaa.example(作者鲍勃)

The ADSP lookup first identifies the Author Address bob@aaa.example and the Author Domain aaa.example. It does an MX DNS query for aaa.example and gets back a NOERROR result with no DNS records. (There's no MX record, but since record (1) exists, the name exists in the DNS.) Since that query didn't return an error, the lookup proceeds to a TXT DNS query for _adsp._domainkey.aaa.example, which returns record (2). Since this is a valid ADSP record, the result is that all messages from this domain are signed.

ADSP查找首先标识作者地址bob@aaa.example以及作者域aaa.example。它对aaa.example执行MX DNS查询,并返回没有DNS记录的无错误结果。(没有MX记录,但由于记录(1)存在,因此名称存在于DNS中。)由于该查询未返回错误,因此查找继续进行TXT DNS查询,以获取_adsp._domainkey.aaa.example,该查询返回记录(2)。因为这是一个有效的ADSP记录,所以结果是来自这个域的所有消息都被签名。

A.2. Domain Exists, ADSP Does Not Exist
A.2. 域存在,ADSP不存在

A mail message contains this From: header line:

邮件包含以下发件人:标题行:

From: alice@bbb.example (Old-fashioned Alice)

发件人:alice@bbb.example(老式的爱丽丝)

The ADSP lookup first identifies the Author Address alice@bbb.example and the Author Domain bbb.example. It does an MX DNS query for bbb.example and gets back record (3). Since that query didn't return an error, it then proceeds to a TXT DNS query for _adsp._domainkey.bbb.example, which returns NXDOMAIN. Since the domain exists but there is no ADSP record, ADSP returns the default unknown result: messages may or may not have an author domain signature.

ADSP查找首先标识作者地址alice@bbb.example以及作者域bbb.example。它对bbb.example执行MX DNS查询并返回记录(3)。由于该查询没有返回错误,因此它将继续执行针对_adsp._domainkey.bbb.example的TXT DNS查询,该查询返回NXDOMAIN。由于域存在但没有ADSP记录,ADSP返回默认的未知结果:消息可能有作者域签名,也可能没有作者域签名。

A.3. Domain Does Not Exist
A.3. 域不存在

A mail message contains this From: header line:

邮件包含以下发件人:标题行:

From: frank@ccc.example (Unreliable Frank)

发件人:frank@ccc.example(不可靠的弗兰克)

The ADSP lookup first identifies the Author Address frank@ccc.example and the Author Domain ccc.example. It does an MX DNS query for ccc.example and gets back an NXDOMAIN result since there are no records at all for ccc.example. The lookup terminates with the result that the domain does not exist in the DNS and so is out of scope.

ADSP查找首先标识作者地址frank@ccc.example以及作者域ccc.example。它对ccc.example执行MX DNS查询,并返回NXDOMAIN结果,因为ccc.example根本没有记录。查找终止,结果是DNS中不存在域,因此超出范围。

Appendix B. Usage Examples
附录B.使用示例

These examples are intended to illustrate typical uses of ADSP. They are not intended to be exhaustive or to apply to every domain's or mail system's individual situation.

这些示例旨在说明ADSP的典型用途。它们并非详尽无遗,也不适用于每个域或邮件系统的具体情况。

Domain managers are advised to consider the ways that mail processing can modify messages in ways that will invalidate an existing DKIM signature, such as mailing lists, courtesy forwarders, and other paths that could add or modify headers, or modify the message body. If the modifications invalidate the DKIM signature, recipient hosts will consider the mail not to have an Author Domain Signature, even though the signature was present when the mail was originally sent.

域管理者建议考虑邮件处理可以以无效的方式修改现有的DKIM签名的方式,例如邮件列表、礼貌转发器和其他可以添加或修改标头的路径,或者修改消息体。如果修改无效DKIM签名,接收方主机将考虑邮件不具有作者域签名,即使邮件最初发送时签名存在。

B.1. Single Location Domains
B.1. 单位置域

One common mail system configuration handles all of a domain's users' incoming and outgoing mail through a single Mail Transport Agent (MTA) or group of MTAs. With this configuration, the MTA(s) can be configured to sign outgoing mail with an Author Domain Signature.

一种常见的邮件系统配置通过单个邮件传输代理(MTA)或一组MTA处理域用户的所有传入和传出邮件。使用此配置,可以将MTA配置为使用作者域签名对传出邮件进行签名。

In this situation, it might be appropriate to publish an ADSP record for the domain containing "all", depending on whether the users also send mail through other paths that do not apply an Author Domain Signature. Such paths could include MTAs at hotels or hotspot networks used by travelling users, web sites that provide "mail an article" features, user messages sent through mailing lists, or third-party mail clients that support multiple user identities.

在这种情况下,可能适合发布包含“all”的域的ADSP记录,这取决于用户是否也通过不应用作者域签名的其他路径发送邮件。这些路径可能包括旅店的MTA或旅行用户使用的热点网络、提供“邮寄文章”功能的网站、通过邮件列表发送的用户消息,或支持多个用户身份的第三方邮件客户端。

B.2. Bulk Mailing Domains
B.2. 批量邮寄域

Another common configuration uses a domain solely for bulk or broadcast mail, with no individual human users -- again, typically sending all the mail through a single MTA or group of MTAs that can apply an Author Domain Signature. In this case, the domain's management can be confident that all of its outgoing mail will be sent through the signing MTA(s). Lacking individual users, the domain is unlikely to participate in mailing lists, but could still send mail through other paths that might invalidate signatures.

另一种常见的配置是将域仅用于批量邮件或广播邮件,而不使用个人用户——同样,通常通过一个MTA或一组可以应用作者域签名的MTA发送所有邮件。在这种情况下,域的管理层可以确信其所有传出邮件都将通过签名MTA发送。由于缺少个人用户,域不太可能参与邮件列表,但仍然可以通过其他路径发送邮件,这可能会使签名无效。

Domain owners often use specialist mailing providers to send their bulk mail. In this case, the mailing provider needs access to a suitable signing key in order to apply an Author Domain Signature. One possible route would be for the domain owner to generate the key and give it to the mailing provider. Another would be for the domain to delegate a subdomain to the mailing provider, for example, bigbank.example might delegate email.bigbank.example to such a provider; in this case, the provider can generate the keys and DKIM DNS records itself and use the subdomain in the Author Address in the mail.

域名所有者经常使用专业的邮件提供商发送他们的批量邮件。在这种情况下,邮件提供商需要访问合适的签名密钥才能应用作者域签名。一种可能的途径是域所有者生成密钥并将其交给邮件提供商。另一种是域将子域委托给邮件提供商,例如,bigbank.example可以将email.bigbank.example委托给这样的提供商;在这种情况下,提供者可以自己生成密钥和DKIM DNS记录,并在邮件中使用作者地址中的子域。

Regardless of the DNS and key management strategy chosen, whoever maintains the DKIM records for the domain could also install an ADSP record containing "all".

无论选择何种DNS和密钥管理策略,维护域的DKIM记录的人也可以安装包含“all”的ADSP记录。

B.3. Bulk Mailing Domains with Discardable Mail
B.3. 具有可丢弃邮件的批量邮件域

In some cases, a domain might sign all of its outgoing mail with an Author Domain Signature and prefer that recipient systems discard mail without a valid Author Domain Signature in order to avoid having its mail confused with mail sent from sources that do not apply an Author Domain Signature. (In the case of domains with tightly controlled outgoing mail, this latter kind of mail is sometimes loosely called "forgeries".) In such cases, it might be appropriate to publish an ADSP record containing "discardable". Note that a domain SHOULD NOT publish a "discardable" record if it wishes to maximize the likelihood that mail from the domain is delivered, since it could cause some fraction of the mail the domain sends to be discarded.

在某些情况下,域可能会使用作者域签名对其所有传出邮件进行签名,并且希望收件人系统丢弃没有有效作者域签名的邮件,以避免其邮件与从不应用作者域签名的来源发送的邮件相混淆。(对于具有严格控制的传出邮件的域,后一种邮件有时被松散地称为“伪造”。)在这种情况下,发布包含“可丢弃”的ADSP记录可能是合适的。请注意,如果域希望最大限度地提高来自该域的邮件被传递的可能性,则不应发布“可丢弃”记录,因为这可能会导致域发送的部分邮件被丢弃。

B.4. Third-Party Senders
B.4. 第三方发件人

Another common use case is for a third party to enter into an agreement whereby that third party will send bulk or other mail on behalf of a designated Author or Author Domain, using that domain in the [RFC5322] From: or other headers. Due to the many and varied complexities of such agreements, third-party signing is not addressed in this specification.

另一个常见的使用案例是第三方签订协议,根据该协议,该第三方将使用[RFC5322]From:或其他标题中的指定作者或作者域发送批量邮件或其他邮件。由于此类协议的复杂性多种多样,本规范不涉及第三方签署。

B.5. Domains with Independent Users and Liberal Use Policies
B.5. 具有独立用户和自由使用策略的域

When a domain has independent users and its usage policy does not explicitly restrict them to sending mail only from designated mail servers (e.g., many ISP domains and even some corporate domains), then it is only appropriate to publish an ADSP record containing "unknown". Publishing either "all" or "discardable" will likely result in significant breakage because independent users are likely to send mail from the external paths enumerated in Appendix B.1.

如果一个域有独立的用户,并且其使用策略没有明确限制他们仅从指定的邮件服务器(例如,许多ISP域,甚至一些公司域)发送邮件,则只适合发布包含“未知”的ADSP记录。发布“全部”或“可丢弃”都可能导致重大破坏,因为独立用户可能从附录B.1中列举的外部路径发送邮件。

B.6. Non-Email Domains
B.6. 非电子邮件域

If a domain sends no mail at all, it can safely publish a "discardable" ADSP record, since any mail with an Author Address in the domain is a forgery.

如果域根本不发送邮件,它可以安全地发布“可丢弃”的ADSP记录,因为域中任何带有作者地址的邮件都是伪造的。

Appendix C. Acknowledgements
附录C.确认书

This document greatly benefited from comments by Steve Atkins, Jon Callas, Dave Crocker, Pasi Eronen, JD Falk, Arvel Hathcock, Ellen Siegel, Michael Thomas, and Wietse Venema.

本文件从Steve Atkins、Jon Callas、Dave Crocker、Pasi Eronen、JD Falk、Arvel Hatchock、Ellen Siegel、Michael Thomas和Wietse Venema的评论中获益匪浅。

Authors' Addresses

作者地址

Eric Allman Sendmail, Inc. 6475 Christie Ave, Suite 350 Emeryville, CA 94608

Eric Allman Sendmail,Inc.地址:加利福尼亚州埃默维尔克里斯蒂大道6475号350室,邮编94608

   Phone: +1 510 594 5501
   EMail: eric+dkim@sendmail.org
        
   Phone: +1 510 594 5501
   EMail: eric+dkim@sendmail.org
        

Jim Fenton Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134-1706

Jim Fenton Cisco Systems,Inc.加利福尼亚州圣何塞塔斯曼大道西170号,邮编95134-1706

   Phone: +1 408 526 5914
   EMail: fenton@cisco.com
        
   Phone: +1 408 526 5914
   EMail: fenton@cisco.com
        

Mark Delany Yahoo! Inc. 701 First Avenue Sunnyvale, CA 94089

马克·德拉尼雅虎!加利福尼亚州桑尼维尔第一大道701号,邮编94089

   Phone: +1 408 349 6831
   EMail: markd+dkim@yahoo-inc.com
        
   Phone: +1 408 349 6831
   EMail: markd+dkim@yahoo-inc.com
        

John Levine Taughannock Networks PO Box 727 Trumansburg, NY 14886

纽约州杜鲁曼斯堡市约翰·莱文·塔甘诺克网络公司邮政信箱727号,邮编14886

   Phone: +1 831 480 2300
   EMail: standards@taugh.com
   URI:   http://www.taugh.com
        
   Phone: +1 831 480 2300
   EMail: standards@taugh.com
   URI:   http://www.taugh.com