Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 6686 Cloudmark
Category: Informational July 2012
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 6686 Cloudmark
Category: Informational July 2012
ISSN: 2070-1721
Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments
解析发送方策略框架（SPF）和发送方ID实验
Abstract
摘要
In 2006, the IETF published a suite of protocol documents comprising the Sender Policy Framework (SPF) and Sender ID: two proposed email authentication protocols. Both of these protocols enable one to publish, via the Domain Name System, a policy declaring which mail servers were authorized to send email on behalf of the domain name being queried. There was concern that the two would conflict in some significant operational situations, interfering with message delivery.
2006年，IETF发布了一套协议文档，其中包括发件人策略框架（SPF）和发件人ID：两个拟议的电子邮件身份验证协议。这两个协议都允许用户通过域名系统发布一个策略，声明哪些邮件服务器被授权代表被查询的域名发送电子邮件。有人担心，在某些重要的业务情况下，这两者会发生冲突，干扰信息的传递。
The IESG required all of these documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) to be published as Experimental RFCs and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication to determine a reasonable path forward.
IESG要求将所有这些文件（RFC 4405、RFC 4406、RFC 4407和RFC 4408）作为实验性RFC发布，并要求社区从发布之日起两年内观察协议的部署和运行情况，以确定合理的前进道路。
After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings.
六年后，已经收集了足够的经验和证据，可以认为这样创建的实验已经完成。本文件介绍了这些调查结果。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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/rfc6686.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6686.
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
3. Evidence of Deployment ..........................................3
3.1. DNS Resource Record Types ..................................3
3.2. Implementations ............................................5
3.3. The SUBMITTER SMTP Extension ...............................6
4. Evidence of Differences .........................................7
5. Analysis ........................................................7
6. Conclusions .....................................................8
7. Security Considerations .........................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References .....................................9
Appendix A. Background on the RRTYPE Issue ........................10
Appendix B. Acknowledgments .......................................11
1. Introduction ....................................................2
2. Definitions .....................................................3
3. Evidence of Deployment ..........................................3
3.1. DNS Resource Record Types ..................................3
3.2. Implementations ............................................5
3.3. The SUBMITTER SMTP Extension ...............................6
4. Evidence of Differences .........................................7
5. Analysis ........................................................7
6. Conclusions .....................................................8
7. Security Considerations .........................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References .....................................9
Appendix A. Background on the RRTYPE Issue ........................10
Appendix B. Acknowledgments .......................................11
In April 2006, the IETF published the [SPF] and Sender ID email authentication protocols, the latter consisting of three documents ([SUBMITTER], [SENDER-ID], and [PRA]). Both of these protocols enable one to publish, via the Domain Name System, a policy declaring which mail servers are authorized to send email on behalf of the selected domain name.
2006年4月，IETF发布了[SPF]和发件人ID电子邮件认证协议，后者由三个文件组成（[SUBMITTER]、[Sender-ID]和[PRA]）。这两种协议都允许用户通过域名系统发布策略，声明哪些邮件服务器有权代表所选域名发送电子邮件。
Consensus did not clearly support one protocol over the other, and there was significant concern that the two would conflict in some significant operational situations, interfering with message delivery. The IESG required the publication of all of these documents as Experimental, and requested that the community observe
协商一致意见显然不支持一种协议而不是另一种协议，人们非常担心这两种协议在某些重要的操作情况下会发生冲突，从而干扰消息的传递。IESG要求将所有这些文件作为实验性文件出版，并要求社区遵守
deployment and operation of the protocols over a period of two years from the date of publication in order to determine a reasonable path forward.
协议自发布之日起两年内的部署和运行，以确定合理的前进道路。
In line with the IESG's request to evaluate after a period of time, this document concludes the experiments by presenting evidence regarding both deployment and comparative effect of the two protocols. At the end, it presents conclusions based on the data collected.
根据IESG在一段时间后进行评估的要求，本文件通过提供有关两个协议的部署和比较效果的证据来结束实验。最后，根据收集到的数据得出结论。
It is important to note that this document makes no direct technical comparison of the two protocols in terms of correctness, weaknesses, or use case coverage. The email community at large has already done that through its deployment choices. Rather, the analysis presented here is merely an observation of what has been deployed and supported in the time since the protocols were published and lists conclusions based on those observations.
需要注意的是，本文档没有在正确性、弱点或用例覆盖率方面对两个协议进行直接的技术比较。整个电子邮件社区已经通过其部署选择做到了这一点。相反，本文的分析仅仅是对自协议发布以来所部署和支持的内容的观察，并列出了基于这些观察的结论。
The data collected and presented here are presumed to be a reasonable representative view of the global deployment data, which could never itself be fully surveyed within a reasonable period of time.
这里收集和提供的数据被认为是全球部署数据的合理代表性观点，而全球部署数据本身永远无法在合理的时间内进行全面调查。
The term "RRTYPE" is used to refer to a Domain Name System ([DNS]) Resource Record (RR) type. These are always expressed internally in software as numbers, assigned according to the procedures in [DNS-IANA] Assigned RRTYPEs also have names. The two of interest in this work are the TXT RRTYPE (16) and the SPF RRTYPE (99).
术语“RRTYPE”用于指域名系统（[DNS]）资源记录（RR）类型。这些在软件中始终表示为数字，根据[DNS-IANA]中的程序分配。分配的RRTYPE也有名称。这项工作中两个感兴趣的类型是TXT RRTYPE（16）和SPF RRTYPE（99）。
This section presents the collected research done to determine what parts of the two protocol suites are in general use as well as related issues like [DNS] support.
本节介绍了为确定这两个协议套件的哪些部分通用而进行的收集研究，以及[DNS]支持等相关问题。
Three large-scale DNS surveys were run that looked for the two supported kinds of RRTYPEs that can contain SPF policy statements. These surveys selected substantial sets of distinct domain names from email headers and logs over long periods, regardless of whether the DNS data for those domains included A, MX, or any other RRTYPEs. The nameservers for these domains were queried, asking for both of the RRTYPEs that could be used for SPF and/or Sender ID.
运行了三次大规模DNS调查，以查找两种受支持的可包含SPF策略语句的RRTYPE。这些调查长期从电子邮件头和日志中选择了大量不同的域名集，而不管这些域名的DNS数据是否包括A、MX或任何其他RRT类型。查询了这些域的名称服务器，询问可用于SPF和/或发件人ID的两种RRTYPE。
In the tables below, replies were counted only if they included prefixes that indicated the record was intended to be of a form defined in either [SPF] or [SENDER-ID], though complete syntax validation of the replies was not done. That is, the records started either "v=spf1" or "spf2.0/", or they were not counted as replies.
在下表中，仅当回复包含表明记录的形式为[SPF]或[SENDER-ID]中定义的前缀时，才会对回复进行计数，尽管回复的完整语法验证未完成。也就是说，记录以“v=spf1”或“spf2.0/”开头，或者它们不被计算为回复。
The tables are broken down into three parts: (a) the size of the sample set, (b) a report about RRTYPE use independent of content, and (c) a report about content independent of RRTYPE.
这些表格分为三个部分：（a）样本集的大小，（b）与内容无关的RRTYPE使用报告，以及（c）与内容无关的RRTYPE报告。
"SPF+TXT" indicates the count of domains where both types were in use.
“SPF+TXT”表示使用这两种类型的域的计数。
DNS Survey #1 (Cisco)
DNS调查#1（思科）
+------------------+-----------+-------+
| Domains queried | 1,000,000 | - |
+------------------+-----------+-------+
| TXT replies | 397,511 | 39.8% |
| SPF replies | 6,627 | <1.0% |
| SPF+TXT replies | 6,603 | <1.0% |
+------------------+-----------+-------+
| v=spf1 replies | 395,659 | 39.6% |
| spf2.0/* replies | 5,291 | <1.0% |
+------------------+-----------+-------+
+------------------+-----------+-------+
| Domains queried | 1,000,000 | - |
+------------------+-----------+-------+
| TXT replies | 397,511 | 39.8% |
| SPF replies | 6,627 | <1.0% |
| SPF+TXT replies | 6,603 | <1.0% |
+------------------+-----------+-------+
| v=spf1 replies | 395,659 | 39.6% |
| spf2.0/* replies | 5,291 | <1.0% |
+------------------+-----------+-------+
Domains were selected as the top million domains as reported by Alexa, which monitors browser activity.
根据Alexa的报告，域名被选为前百万域名，Alexa负责监控浏览器活动。
DNS Survey #2 (The Trusted Domain Project)
DNS调查#2（受信任域项目）
+------------------+-----------+-------+
| Domains queried | 278,353 | - |
+------------------+-----------+-------+
| TXT replies | 156,894 | 56.4% |
| SPF replies | 2,876 | 1.0% |
| SPF+TXT replies | 2,689 | <1.0% |
+------------------+-----------+-------+
| v=spf1 replies | 149,985 | 53.9% |
| spf2.0/* replies | 7,285 | 2.7% |
+------------------+-----------+-------+
+------------------+-----------+-------+
| Domains queried | 278,353 | - |
+------------------+-----------+-------+
| TXT replies | 156,894 | 56.4% |
| SPF replies | 2,876 | 1.0% |
| SPF+TXT replies | 2,689 | <1.0% |
+------------------+-----------+-------+
| v=spf1 replies | 149,985 | 53.9% |
| spf2.0/* replies | 7,285 | 2.7% |
+------------------+-----------+-------+
This survey selected its domains from data observed in email headers and previous SPF and Sender ID evaluations, collected from 23 reporting hosts across a handful of unrelated operators over a period of 22 months.
这项调查从电子邮件标题中观察到的数据以及之前的SPF和发件人ID评估中选择了自己的域名，这些数据是在22个月的时间里从23个报告主机、少数几个不相关的运营商收集的。
During this second survey, some domains were observed to provide immediate answers for RRTYPE 16 queries, but would time out waiting for replies to RRTYPE 99 queries. For example, it was observed that 4,360 (over 1.6%) distinct domains in the survey returned a result of some kind (a record or an error) for the TXT query in time N, while the SPF query ultimately failed after at least time 4N.
在第二次调查期间，观察到一些域会立即为RRTYPE 16查询提供答案，但会在等待RRTYPE 99查询的答复时超时。例如，据观察，调查中4360个（超过1.6%）不同域在时间N内返回了TXT查询的某种结果（记录或错误），而SPF查询在至少时间4N后最终失败。
DNS Survey #3 (Hotmail)
DNS调查#3（Hotmail）
+------------------+-----------+-------+
| Domains queried | 100,000 | - |
+------------------+-----------+-------+
| TXT replies | 46,221 | 46.2% |
| SPF replies | 954 | <1.0% |
| SPF+TXT replies | 1,383 | 1.4% |
+------------------+-----------+-------+
+------------------+-----------+-------+
| Domains queried | 100,000 | - |
+------------------+-----------+-------+
| TXT replies | 46,221 | 46.2% |
| SPF replies | 954 | <1.0% |
| SPF+TXT replies | 1,383 | 1.4% |
+------------------+-----------+-------+
Hotmail's domain set was selected from live email traffic at the time the sample was extracted. Only the RRTYPE portion of the report is available.
Hotmail的域集是从提取样本时的实时电子邮件流量中选择的。只有报告的RRTYPE部分可用。
A separate survey was done of queries for RRTYPE 16 and RRTYPE 99 records by observing nameserver traffic records. Only a few queries were ever received for RRTYPE 99 records, and those almost exclusively came from one large email service provider that queried for both RRTYPEs. The vast majority of other querying agents only ever requested RRTYPE 16.
通过观察名称服务器流量记录，对RRTYPE 16和RRTYPE 99记录的查询进行了单独的调查。对于RRTYPE 99记录，只收到过几次查询，这些查询几乎完全来自一家大型电子邮件服务提供商，该服务提供商查询了这两种RRTYPE记录。绝大多数其他查询代理只请求过RRTYPE 16。
It is likely impossible to determine from a survey which Mail Transfer Agents (MTAs) have SPF and/or Sender ID checking enabled at message ingress since it does not appear, for example, in the reply to the EHLO command from extended [SMTP]. Therefore, we relied on evidence found via web searches and observed the following:
可能无法通过调查确定哪些邮件传输代理（MTA）在邮件入口启用了SPF和/或发件人ID检查，因为它不会出现在（例如）来自扩展[SMTP]的对EHLO命令的回复中。因此，我们依靠通过网络搜索找到的证据，并观察到以下情况：
o A web site [SID-IMPL] dedicated to highlighting Sender ID implementations, last updated in late 2007, listed 13 commercial implementations, which we assume means they implement the Purported Responsible Address (PRA) checks. At least one of them is known no longer to be supported by its vendor. There were no free open-source implementations listed.
o 一个专门强调发送方ID实现的网站[SID-IMPL]，最近一次更新于2007年底，列出了13个商业实现，我们认为这意味着它们实现了所谓的责任地址（PRA）检查。据了解，至少有一家供应商不再支持这些产品。没有列出任何免费的开源实现。
o The [OPENSPF] web site maintains a list of implementations of SPF. At the time of this document's writing, it listed six libraries, 22 MTAs with built-in SPF implementations, and numerous patches for MTAs and mail clients. The set included a mix of commercial and free open-source implementations.
o [OPENSPF]网站维护SPF实现的列表。在撰写本文档时，它列出了六个库、22个内置SPF实现的MTA以及许多MTA和邮件客户端补丁。该系列包括商业和免费开源实现的混合。
The PRA is the output of a heuristic that seeks to scan a message header and extract from it the email address most likely to be the one responsible for injection of that message into the mail stream. The SUBMITTER extension to SMTP is a mechanism to provide an early hint (i.e., as part of the MAIL command in an SMTP session) to the receiving MTA of what the PRA would be on full receipt of the message.
PRA是一种启发式算法的输出，该算法试图扫描消息头并从中提取最有可能负责将该消息注入邮件流的电子邮件地址。SMTP的SUBMITTER扩展是一种向接收MTA提供早期提示（即，作为SMTP会话中邮件命令的一部分）的机制，提示PRA在完全收到邮件时将是什么。
In a review of numerous MTAs in current or recent use, two (Santronics WinServer and McAfee MxLogic) were found to contain implementations of the SMTP SUBMITTER extension as part of the MTA service, which could act as an enabler to Sender ID.
在对当前或最近使用的大量MTA的审查中，发现两个（Santronics WinServer和McAfee MxLogic）包含SMTP提交者扩展的实现，作为MTA服务的一部分，它可以作为发送者ID的启用码。
An unknown number of SMTP clients implement the SUBMITTER SMTP extension. Although information from MTA logs indicates substantial use of the SMTP extension, it is not possible to determine whether the usage is from multiple instances of the same SMTP client or different SMTP client implementations.
实现提交者SMTP扩展的SMTP客户端数目未知。虽然来自MTA日志的信息表明SMTP扩展的大量使用，但无法确定使用情况是来自同一SMTP客户端的多个实例还是来自不同的SMTP客户端实现。
An active survey of MTAs accessible over the Internet was performed. The MTAs selected were found by querying for MX and A resource records of a subset of all domains observed by The Trusted Domain Project's data collection system in the preceding 20 months. The results were as follows:
对可通过互联网访问的MTA进行了积极调查。通过查询受信任域项目的数据收集系统在过去20个月内观察到的所有域子集的MX和资源记录，找到选定的MTA。结果如下：
SUBMITTER Survey (The Trusted Domain Project)
提交者调查（受信任域项目）
+-------------------+-----------+-------+
| MTAs selected | 484,980 | - |
| MTAs responding | 371,779 | 76.7% |
| SUBMITTER enabled | 17,425 | 4.7% |
| MXLogic banner | 16,914 | 4.6% |
+-------------------+-----------+-------+
+-------------------+-----------+-------+
| MTAs selected | 484,980 | - |
| MTAs responding | 371,779 | 76.7% |
| SUBMITTER enabled | 17,425 | 4.7% |
| MXLogic banner | 16,914 | 4.6% |
+-------------------+-----------+-------+
Note: The bottom two rows indicate the percentage of responding MTAs with the stated property, not the percentage of selected MTAs.
注意：底部两行表示具有声明属性的响应MTA的百分比，而不是选定MTA的百分比。
Based on the SMTP banner presented upon connection, the entire set of SUBMITTER-enabled MTAs consisted of the two found during the review (above) and a third whose identity could not be positively determined.
根据连接时显示的SMTP横幅，整套启用提交者的MTA由审查期间发现的两个MTA（如上）和无法确定其身份的第三个MTA组成。
Of those few responding MTAs advertising the SUBMITTER SMTP extension, 97% were different instances of one MTA. The service operating that MTA (MXLogic, a division of McAfee) reported that
在为数不多的宣传提交者SMTP扩展的响应MTA中，97%是一个MTA的不同实例。MTA（MXLogic，McAfee的一个部门）报告的运营服务
about 11% of all observed SMTP sessions involved SMTP clients that make use of the SUBMITTER extension. Note that this represents about 11% of the clients of 4.6% of the responding MTAs in the survey.
在所有观察到的SMTP会话中，约有11%涉及使用提交者扩展名的SMTP客户端。请注意，这代表了调查中4.6%答复MTA中约11%的客户。
Separate surveys from Hotmail and The Trusted Domain Project compared the cases where the PRA (used by Sender ID) and the RFC5321.MailFrom address (used by SPF) differed. The results of these tests showed that, at least 50% of the time, the two addresses were the same, but, beyond that, the percentage varied substantially from one sampling location to the next due to the nature of the mail streams they each receive.
Hotmail和Trusted Domain项目的单独调查比较了PRA（由发件人ID使用）和RFC5321.MailFrom地址（由SPF使用）不同的情况。这些测试的结果表明，至少有50%的时间，这两个地址是相同的，但除此之外，由于每个采样位置接收到的邮件流的性质，这两个地址的百分比在不同的采样位置之间差异很大。
Further, The Trusted Domain Project analyzed approximately 150,000 messages and found that in more than 95% of those cases, Sender ID and SPF reach the same conclusion about a message, meaning either both protocols return a "pass" result or both return a "fail" result. Note that this does not include an evaluation of whether "fail" meant spam or other abusive mail was thus detected or that "pass" mail is good mail; it is merely a measure of how often the two protocols concurred. The data set yielding this response could not further characterize the cases in which the answers differed.
此外，Trusted Domain项目分析了大约150000条消息，发现在超过95%的情况下，发送方ID和SPF对消息得出了相同的结论，这意味着两个协议要么返回“通过”结果，要么都返回“失败”结果。注意，这不包括评估“失败”是否意味着垃圾邮件或其他滥用邮件因此被检测到，或者“通过”邮件是否是好邮件；这仅仅是衡量这两个协议是否经常一致的一个指标。产生这种反应的数据集不能进一步描述答案不同的情况。
A second analysis of the same nature by Hotmail found that the two protocols yielded the same result approximately 80% of the time when evaluated across billions of messages.
Hotmail对相同性质的第二次分析发现，当对数十亿条消息进行评估时，这两个协议大约80%的时间产生相同的结果。
Anecdotally, the differences in conclusions have not been noted as causing significant operational problems by the email-receiving community.
有趣的是，电子邮件接收社区并未注意到结论上的差异会导致重大的运营问题。
Given the six years that have passed since the publication of the Experimental RFCs, and the evidence reported in the earlier sections of this document, the following analysis appears to be supported:
鉴于实验性RFC出版以来的六年时间，以及本文件前面章节中报告的证据，以下分析似乎得到了支持：
1. There has not been substantial adoption of the RRTYPE 99 (SPF) DNS resource record. In all large-scale surveys performed for this work, fewer than 2% of responding domains published RRTYPE 99 records, and almost no clients requested them.
1. RRTYPE 99（SPF）DNS资源记录尚未被大量采用。在为这项工作进行的所有大规模调查中，只有不到2%的响应域发布了RRTYPE 99记录，几乎没有客户请求这些记录。
2. Of the DNS resource records retrieved, fewer than 3% included specific requests for processing of messages using the PRA algorithm, which is an essential part of Sender ID.
2. 在检索到的DNS资源记录中，不到3%包含使用PRA算法处理消息的特定请求，PRA算法是发送方ID的重要组成部分。
3. Although the two protocols often used different email address fields as the subject being evaluated, no data collected showed any substantial operational benefit, in terms of improved accuracy, to using one mechanism over the other.
3. 尽管这两个协议通常使用不同的电子邮件地址字段作为评估对象，但所收集的数据均未显示使用一种机制优于另一种机制在提高准确性方面有任何实质性的操作益处。
4. A review of known implementations shows significant support for both protocols, though there were more implementations in support of SPF than of Sender ID. Further, the SPF implementations showed better upkeep and current interest than the Sender ID implementations.
4. 对已知实现的回顾表明，这两种协议都得到了显著的支持，尽管支持SPF的实现比支持发送方ID的实现更多。此外，SPF实现比发送方ID实现表现出更好的维护和当前兴趣。
5. A survey of running MTAs shows fewer than 5% of them advertised the SUBMITTER extension, which is a Sender ID enabler. Only three implementations of it were found.
5. 一项对运行MTA的调查显示，只有不到5%的MTA广告了提交者扩展名，这是一个发送者ID启用程序。只找到了它的三个实现。
6. There remain obstacles to deployment of protocols that use DNS RRTYPEs other than the most common ones, including firewalls and DNS servers that block or discard requests for unknown RRTYPEs. Further, few if any web-based DNS configuration tools offer support for RRTYPE 99 records.
6. 部署使用DNS RRTYPE而不是最常见的DNS RRTYPE的协议仍然存在障碍，包括阻止或丢弃未知RRTYPE请求的防火墙和DNS服务器。此外，很少有基于web的DNS配置工具支持RRTYPE 99记录。
In light of the analysis in the previous section, the following conclusions are supported:
根据上一节中的分析，支持以下结论：
1. The experiments comprising the series of RFCs defining the SUBMITTER SMTP extension (RFC4405), the Sender ID mechanism (RFC4406), the Purported Responsible Address algorithm (RFC4407), and SPF (RFC4408), should be considered concluded.
1. 实验包括定义提交者SMTP扩展（RFC4405）、发送者ID机制（RFC4406）、声称的责任地址算法（RFC4407）和SPF（RFC4408）的一系列RFC，应视为已完成。
2. The absence of significant adoption of the RRTYPE 99 DNS Resource Record suggests that it has not attracted enough support to be useful.
2. RRTYPE 99 DNS资源记录没有被大量采用，这表明它没有吸引到足够的支持来发挥作用。
3. Unavailability of software implementing the protocols was not a gating factor in terms of the selection of which to use.
3. 在选择使用哪种协议方面，实施协议的软件不可用不是一个门控因素。
4. The absence of significant adoption of the [SUBMITTER] extension, [SENDER-ID], and [PRA], indicates that there is not a strong community deploying and using these protocols.
4. [SUBMITTER]扩展、[SENDER-ID]和[PRA]没有被大量采用，这表明没有强大的社区部署和使用这些协议。
5. [SPF] has widespread implementation and deployment, comparable to that of many Standards Track protocols.
5. [SPF]具有广泛的实现和部署，与许多标准跟踪协议相当。
Appendix A is offered as a cautionary review of problems that affected the process of developing SPF and Sender ID in terms of their use of the DNS.
附录A是对影响SPF和发送方ID使用DNS开发过程的问题的警告性审查。
This document contains information for the community, akin to an implementation report, and does not introduce any new security concerns.
本文档包含社区信息，类似于实施报告，不引入任何新的安全问题。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNS]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[PRA] Lyon, J., "Purported Responsible Address in E-Mail Messages", RFC 4407, April 2006.
[PRA]Lyon，J.，“电子邮件中声称的责任地址”，RFC 4407，2006年4月。
[SENDER-ID] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006.
[SENDER-ID]Lyon，J.和M.Wong，“发件人ID:验证电子邮件”，RFC 4406，2006年4月。
[SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.
[SPF]Wong，M.和W.Schlitt，“授权在电子邮件中使用域的发件人策略框架（SPF），第1版”，RFC 4408，2006年4月。
[SUBMITTER] Allman, E. and H. Katz, "SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message", RFC 4405, April 2006.
[提交人]Allman，E.和H.Katz，“用于指示电子邮件的负责提交人的SMTP服务扩展”，RFC 4405，2006年4月。
[DNS-EXPAND] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design Choices When Expanding the DNS", RFC 5507, April 2009.
[DNS-扩展]IAB，Faltstrom，P.，Austein，R.，和P.Koch，“扩展DNS时的设计选择”，RFC 5507，2009年4月。
[DNS-IANA] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6195, March 2011.
[DNS-IANA]Eastlake 3rd，D.，“域名系统（DNS）IANA注意事项”，BCP 42，RFC 61952011年3月。
[OPENSPF] "Sender Policy Framework: Project Overview", <http://www.openspf.net>.
[OPENSPF]“发件人策略框架：项目概述”<http://www.openspf.net>.
[SID-IMPL] "Sender ID Framework Industry Support and Solutions", October 2007, <http://www.microsoft.com/mscorp/safety/ technologies/senderid/support.mspx>.
[SID-IMPL]“发件人ID框架行业支持和解决方案”，2007年10月<http://www.microsoft.com/mscorp/safety/ technologies/senderid/support.mspx>。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
SPF was originally created by a community of interested developers outside the IETF, with the intent of bringing it to the IETF for standardization after it had become relatively mature and ready for the IETF Standards process.
SPF最初是由IETF之外的一个感兴趣的开发人员社区创建的，目的是在其变得相对成熟并为IETF标准过程做好准备后，将其带到IETF进行标准化。
At the time of SPF's initial development, the prospect of getting an RRTYPE allocated for SPF was not seriously considered, partly because doing so had high barriers to entry. As a result, at the time it was brought to the IETF for development and publication, there was already a substantial and growing installed base that had SPF running using TXT RRs. Eventually, the application was made for the new RRTYPE as a result of pressure from the DNS experts in the community, who insisted upon doing so as the preferred path toward using the DNS for storing such things as policy data.
在SPF最初开发时，没有认真考虑为SPF分配RRTYPE的前景，部分原因是这样做有很高的进入壁垒。因此，在将其提交IETF进行开发和发布时，已经有大量且不断增长的安装群使用TXT RRs运行SPF。最终，由于社区中DNS专家的压力，新的RRTYPE被应用，他们坚持将此作为使用DNS存储策略数据等内容的首选途径。
Later, after RRTYPE 99 was assigned (long after IESG approval of [SPF], in fact), a plan was put into place to effect a gradual transition to using RRTYPE 99 instead of using RRTYPE 16. This plan failed to take effect for four primary reasons:
后来，在分配了RRTYPE 99之后（事实上，在IESG批准[SPF]很久之后），制定了一项计划，逐步过渡到使用RRTYPE 99，而不是使用RRTYPE 16。该计划未能生效的主要原因有四个：
1. there was hesitation to make the transition because existing nameservers (and, in fact, DNS-aware firewalls) would drop or reject requests for unknown RRTYPEs (see Section 3 for evidence of this), which means successful rollout of a new RRTYPE is contingent upon widespread adoption of updated nameservers and resolver functions;
1. 由于现有名称服务器（事实上，DNS感知防火墙）会删除或拒绝未知RRTYPE的请求（参见第3节了解这方面的证据），因此在进行转换时存在犹豫，这意味着新RRTYPE的成功推出取决于更新名称服务器和解析器功能的广泛采用；
2. many DNS provisioning tools (e.g., web interfaces to controlling DNS zone data) were, and still are, typically lethargic about adding support for new RRTYPEs;
2. 许多DNS配置工具（例如，用于控制DNS区域数据的web接口）在添加对新RRTYPE的支持方面通常是，现在仍然是，迟钝的；
3. the substantial deployed base was already using RRTYPE 16, and it was working just fine, leading to inertia;
3. 大量部署的基地已经在使用RRTYPE 16，而且工作正常，导致惯性；
4. [SPF] itself included a faulty transition plan, likely because of the late addition of a requirement to develop one -- it said:
4. [SPF]本身包含了一个错误的过渡计划，可能是因为后来增加了开发计划的要求——它说：
An SPF-compliant domain name SHOULD have SPF records of both RR types. A compliant domain name MUST have a record of at least one type.
符合SPF的域名应具有两种RR类型的SPF记录。兼容域名必须具有至少一种类型的记录。
which means both can claim to be fully compliant while failing utterly to interoperate. Publication occurred without proper IETF review, so this was not detected prior to publication.
这意味着两者都可以声称完全兼容，而完全无法进行互操作。未经适当的IETF审查就发布，因此在发布之前未检测到。
It is likely that this will happen again if the bar to creating new RRTYPEs even for experimental development purposes is not lowered, and handling of unknown RRTYPEs in software becomes generally more graceful. Also, important in this regard is encouragement of support for new RRTYPEs in DNS record provisioning tools.
如果创建新的RRTYPE（即使是用于实验开发目的）的门槛没有降低，并且在软件中处理未知的RRTYPE变得更加优雅，那么这种情况很可能再次发生。此外，在这方面重要的是鼓励在DNS记录提供工具中支持新的RRTYPE。
Fortunately, in the meantime, the requirements for new RRTYPE assignments was changed to be less stringent (see [DNS-IANA]). Also, the publication of [DNS-EXPAND] has provided some useful guidance in this regard. However, there is still a common perception that adding new types of data to the DNS will face resistance due to the lack of appropriate software support.
幸运的是，在此期间，对新RRTYPE分配的要求变得不那么严格（参见[DNS-IANA]）。此外，[DNS-EXPAND]的发布在这方面提供了一些有用的指导。然而，人们仍然普遍认为，由于缺乏适当的软件支持，向DNS添加新类型的数据将面临阻力。
There are DNS experts within the community that will undoubtedly point to DNS servers and firewalls that mistreat queries for unknown RRTYPEs, and to overly simplistic provisioning tools, and claim they are broken as a way of answering these concerns. This is undoubtedly correct, but the reality is that they are among us and likely will be for some time, and this needs to be considered as new protocols and IETF procedures are developed.
社区中的DNS专家无疑会指出DNS服务器和防火墙错误地处理未知RRT类型的查询，以及过于简单的资源调配工具，并声称它们被破坏是解决这些问题的一种方式。这无疑是正确的，但现实是，他们在我们中间，而且可能会在一段时间内，这需要在开发新协议和IETF程序时加以考虑。
The following provided operational data that contributed to the evidence presented above:
以下提供了有助于上述证据的运营数据：
Cisco: contributed data about observed Sender ID and SPF records in the DNS for a large number of domains (DNS survey #1)
Cisco：提供了有关在大量域的DNS中观察到的发件人ID和SPF记录的数据（DNS调查#1）
Hotmail: contributed data about the difference between RFC5321.MailFrom and RFC5322.From domains across large mail volumes, and a survey of DNS replies observed in response to incoming mail traffic (DNS survey #3)
Hotmail：提供了有关RFC5321.MailFrom和RFC5322.From之间差异的数据，以及针对传入邮件流量观察到的DNS回复调查（DNS调查#3）
John Levine: conducted a survey of DNS server logs to evaluate SPF-related query traffic
John Levine：对DNS服务器日志进行了调查，以评估与SPF相关的查询流量
McAfee: provided details about their SUBMITTER implementation and usage statistics
McAfee：提供了有关其提交者实现和使用统计信息的详细信息
Santronics: contributed data about the use of the SUBMITTER extension in aggregate SMTP client traffic
Santronics：提供了有关在聚合SMTP客户端流量中使用提交者扩展的数据
The Trusted Domain Project: contributed data about the difference between Sender ID and SPF results, conducted one of the detailed TXT/SPF RRTYPE surveys including collecting timing data (DNS survey #2), and conducted the MTA SUBMITTER survey
Trusted Domain项目：提供了有关发件人ID和SPF结果之间差异的数据，进行了一次详细的TXT/SPF RRTYPE调查，包括收集时间数据（DNS调查#2），并进行了MTA提交人调查
The author would also like to thank the following for their contributions to the development of the text in this document: Dave Crocker, Scott Kitterman, Barry Leiba, John Leslie, John Levine, Hector Santos, and Alessandro Vesely.
作者还要感谢以下各方对本文件文本的发展所作的贡献：戴夫·克罗克、斯科特·基特曼、巴里·莱巴、约翰·莱斯利、约翰·莱文、赫克托·桑托斯和亚历山德罗·维斯利。
Author's Address
作者地址
Murray S. Kucherawy Cloudmark 128 King St., 2nd Floor San Francisco, CA 94107 USA
Murray S. Kucherawy CuldM标记128国王圣，第二楼旧金山，CA 94107美国
Phone: +1 415 946 3800
EMail: superuser@gmail.com
Phone: +1 415 946 3800
EMail: superuser@gmail.com