Internet Engineering Task Force (IETF) S. Kitterman
Request for Comments: 6652 Agari
Updates: 4408 June 2012
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) S. Kitterman
Request for Comments: 6652 Agari
Updates: 4408 June 2012
Category: Standards Track
ISSN: 2070-1721
Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format
使用滥用报告格式的发件人策略框架（SPF）身份验证失败报告
Abstract
摘要
This memo presents extensions to the Abuse Reporting Format (ARF) and Sender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion.
本备忘录对滥用报告格式（ARF）和发送方策略框架（SPF）规范进行了扩展，以允许按需方式详细报告消息身份验证失败。
This memo updates RFC 4408 by providing an IANA registry for SPF modifiers.
本备忘录通过为SPF修改器提供IANA注册表来更新RFC 4408。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc6652.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6652.
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. Imported Definitions .......................................3
3. Optional Reporting Address for SPF ..............................3
4. Requested Reports ...............................................4
4.1. Requested Reports for SPF Failures .........................5
5. IANA Considerations .............................................5
5.1. SPF Modifier Registration ..................................5
6. Security Considerations .........................................6
6.1. Identity Selection .........................................6
6.2. Report Volume ..............................................6
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................7
Appendix A. Acknowledgements .......................................8
Appendix B. Examples ...............................................8
B.1. SPF DNS Record for Domain That Sends No Mail but
Requests Reports ...........................................8
B.2. Minimal SPF DNS Record Change to Add a Reporting
Address ....................................................8
B.3. SPF DNS Record with Reporting Address, Report
Percentage, and Requested Report Type ......................8
1. Introduction ....................................................2
2. Definitions .....................................................3
2.1. Key Words ..................................................3
2.2. Imported Definitions .......................................3
3. Optional Reporting Address for SPF ..............................3
4. Requested Reports ...............................................4
4.1. Requested Reports for SPF Failures .........................5
5. IANA Considerations .............................................5
5.1. SPF Modifier Registration ..................................5
6. Security Considerations .........................................6
6.1. Identity Selection .........................................6
6.2. Report Volume ..............................................6
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................7
Appendix A. Acknowledgements .......................................8
Appendix B. Examples ...............................................8
B.1. SPF DNS Record for Domain That Sends No Mail but
Requests Reports ...........................................8
B.2. Minimal SPF DNS Record Change to Add a Reporting
Address ....................................................8
B.3. SPF DNS Record with Reporting Address, Report
Percentage, and Requested Report Type ......................8
The Abuse Reporting Format [ARF] defines a message format for sending reports of abuse in the messaging infrastructure, with an eye toward automating both the generation and consumption of those reports.
滥用报告格式[ARF]定义了一种用于在消息传递基础设施中发送滥用报告的消息格式，旨在自动化这些报告的生成和使用。
The Sender Policy Framework [SPF] is one mechanism for message sender authentication; it is "path-based", meaning it authenticates the route that a message took from origin to destination. The output is a verified domain name that can then be subjected to some sort of evaluation process (e.g., comparison to a known-good list, submission to a reputation service, etc.).
发送方策略框架[SPF]是消息发送方身份验证的一种机制；它是“基于路径的”，这意味着它验证了消息从源站到目的地的路由。输出是一个经过验证的域名，然后可以对其进行某种评估过程（例如，与已知良好列表进行比较、提交给声誉服务等）。
This document extends [SPF] to add an optional reporting address and other parameters. Extension of [ARF] to add features required for the reporting of these incidents is covered in [ARF-AUTHFAIL] and [ARF-AS].
本文档扩展了[SPF]以添加可选的报告地址和其他参数。[ARF-AUTHFAIL]和[ARF-AS]中介绍了[ARF]的扩展，以添加报告这些事件所需的功能。
This document additionally creates a an IANA registry of [SPF] record modifiers to avoid modifier namespace collisions.
本文档还创建了[SPF]记录修饰符的IANA注册表，以避免修饰符命名空间冲突。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
The [ABNF] token "qp-section" is defined in [MIME].
[ABNF]标记“qp节”在[MIME]中定义。
"local-part" is defined in [MAIL].
“本地部分”在[邮件]中定义。
"addr-spec" is defined in [MAIL].
“地址规范”在[MAIL]中定义。
There exist cases in which an ADministrative Management Domain (ADMD) (see [EMAIL-ARCH]) employing [SPF] for announcing sending practices may want to know when messages are received via unauthorized routing. Currently, there is no such method defined in conjunction with standardized approaches such as [ARF]. Similar information can be gathered using a specially crafted [SPF] record and a special DNS server to track [SPF] record lookups.
在某些情况下，使用[SPF]宣布发送实践的管理管理域（ADMD）（参见[EMAIL-ARCH]）可能想知道何时通过未经授权的路由接收到消息。目前，没有与[ARF]等标准化方法一起定义此类方法。使用特制的[SPF]记录和特殊的DNS服务器来跟踪[SPF]记录查找，可以收集类似的信息。
This document defines the following optional "modifier" (as defined in Section 4.6.1 of [SPF]) to SPF records, using the form defined in that specification:
本文件使用规范中定义的格式，对SPF记录定义了以下可选“修改器”（如[SPF]第4.6.1节所定义）：
ra= Reporting Address (plain-text; OPTIONAL; no default). MUST be a local-part (see Section 3.4.1 of [MAIL]) specifying an e-mail address to which a report SHOULD be sent when mail claiming to be from this domain (see Section 2.4 of [SPF] for a description of how domains are identified for SPF checks) has failed the evaluation algorithm described in [SPF], in particular because a message arrived via an unauthorized route. To generate a complete address to which the report is sent, the Verifier simply appends to this value an "@" followed by the SPF-compliant domain per Section 4.1 of [SPF]. ra= modifiers in a record that was reached by following an "include" mechanism (defined in Section 5.2 of [SPF]) MUST be ignored.
ra=报告地址（纯文本；可选；无默认值）。必须是本地部分（请参见[MAIL]第3.4.1节），指定当声称来自该域的邮件（请参见[SPF]第2.4节了解如何识别域进行SPF检查）未能通过[SPF]中描述的评估算法时，报告应发送到的电子邮件地址，特别是因为消息是通过未经授权的路由到达的。为了生成报告发送到的完整地址，验证者只需根据[SPF]第4.1节在该值后面加上“@”，后跟SPF兼容域。ra=必须忽略通过遵循“包含”机制（定义见[SPF]第5.2节）而达到的记录中的修饰符。
ABNF:
荷兰银行：
spf-report-tag = "ra=" qp-section
spf报告标签=“ra=”qp节
rp= Requested Report Percentage (plain-text; OPTIONAL; default is "100"). The value is an integer from 0 to 100 inclusive that indicates what percentage of incidents of SPF failures, selected at random, are to cause reports to be generated. The report generator SHOULD NOT issue reports for more than the requested percentage of incidents. An exception to this might be some out-of-band arrangement between two parties to override it with some mutually agreed value. Report generators MAY make use of the "Incidents:" field in [ARF] to indicate that there are more reportable incidents than there are reports.
rp=请求的报告百分比（纯文本；可选；默认值为“100”）。该值是一个0到100（含0到100）的整数，表示随机选择的SPF故障事件的百分比将导致生成报告。报告生成器发布的报告不应超过请求的事件百分比。例外情况可能是双方之间的一些带外安排，以某种相互商定的价值覆盖该协议。报告生成器可以使用[ARF]中的“事件：”字段来表示可报告的事件多于报告。
ABNF:
荷兰银行：
spf-rp-tag = "rp=" 1*12DIGIT "/" 1*12DIGIT
spf-rp-tag = "rp=" 1*12DIGIT "/" 1*12DIGIT
rr= Requested Reports (plain-text; OPTIONAL; default is "all"). The value MUST be a colon-separated list of tokens representing those conditions under which a report is desired. See Section 4.1 for a list of valid tags.
rr=请求的报告（纯文本；可选；默认为“全部”）。该值必须是以冒号分隔的标记列表，表示需要报告的条件。有效标签列表见第4.1节。
ABNF:
荷兰银行：
spf-rr-type = ( "all" / "e" / "f" / "s" / "n" )
spf-rr-type = ( "all" / "e" / "f" / "s" / "n" )
spf-rr-tag = "rr=" spf-rr-type *( ":" spf-rr-type )
spf-rr-tag = "rr=" spf-rr-type *( ":" spf-rr-type )
In the absence of an "ra=" tag in the SPF record, the "rp=" and "rr=" tags MUST be ignored, and the report generator MUST NOT issue a report.
如果SPF记录中没有“ra=”标记，则必须忽略“rp=”和“rr=”标记，并且报告生成器不得发布报告。
This memo also includes, as the "rr" tokens defined above, the means by which the sender can request reports for specific circumstances of interest. Verifiers MUST NOT generate reports for incidents that do not match a requested report and MUST ignore requests for reports not included in this list.
该备忘录还包括上文定义的“rr”标记，发送方可以通过该标记请求特定感兴趣情况的报告。验证者不得为与请求的报告不匹配的事件生成报告，并且必须忽略对未包含在此列表中的报告的请求。
The following report requests are defined for SPF results:
为SPF结果定义了以下报告请求：
all All reports are requested.
要求提交所有报告。
e Reports are requested for messages that produced an SPF result of "TempError" or "PermError".
对于产生SPF结果“TempError”或“PermError”的消息，将请求e报告。
f Reports are requested for messages that produced an SPF result of "Fail".
对于产生“失败”SPF结果的消息，请求f报告。
s Reports are requested for messages that produced an SPF result of "SoftFail".
对于产生“SoftFail”SPF结果的消息，将请求s报告。
n Reports are requested for messages that produced an SPF result of "Neutral" or "None".
n对于产生“中性”或“无”SPF结果的消息，请求报告。
As required by [IANA-CONS], this section contains registry information for the new [SPF] modifiers.
根据[IANA-CONS]的要求，本节包含新[SPF]修饰符的注册表信息。
IANA has created the Modifier Names registry under Sender Policy Framework Parameters, to include a list of all registered SPF modifier names and their defining documents.
IANA已在发件人策略框架参数下创建了修改器名称注册表，以包括所有已注册SPF修改器名称及其定义文档的列表。
New registrations or updates are to be published in accordance with the "Specification Required" guidelines as described in [IANA-CONS]. New registrations and updates MUST contain the following information:
根据[IANA-CONS]中所述的“所需规范”指南发布新注册或更新。新注册和更新必须包含以下信息：
1. Name of the modifier being registered or updated
1. 正在注册或更新的修改器的名称
2. The document in which the specification of the modifier is published
2. 发布修改器规范的文档
3. New or updated status, which MUST be one of the following:
3. 新状态或更新状态，必须是以下状态之一：
Current: The field is in current use
当前：该字段处于当前使用状态
Deprecated: The field might be in current use but its use is discouraged
不推荐使用：该字段可能当前正在使用，但不鼓励使用
Historic: The field is no longer in current use
历史：该字段不再处于当前使用状态
An update may make a notation on an existing registration indicating that a registered field is historic or deprecated if appropriate.
更新可能会在现有注册上做标记，表明已注册字段是历史字段或已弃用字段（如果适用）。
+------------+-----------------+---------+
| MODIFIER | REFERENCE | STATUS |
+------------+-----------------+---------+
| exp | RFC 4408 | Current |
| redirect | RFC 4408 | Current |
| ra | (this document) | Current |
| rp | (this document) | Current |
| rr | (this document) | Current |
+------------+-----------------+---------+
+------------+-----------------+---------+
| MODIFIER | REFERENCE | STATUS |
+------------+-----------------+---------+
| exp | RFC 4408 | Current |
| redirect | RFC 4408 | Current |
| ra | (this document) | Current |
| rp | (this document) | Current |
| rr | (this document) | Current |
+------------+-----------------+---------+
Inherited considerations: implementers are advised to consider the Security Considerations sections of [SPF], [ARF], [ARF-AS], and [ARF-AUTHFAIL].
继承考虑：建议实施者考虑[SPF]、[ARF]、[ARF-As]和[ARF AuthValu]的安全考虑部分。
In addition to the advice in the Security Considerations section of [ARF-AS], these additional considerations apply to the generation of [SPF] authentication failure reports:
除了[ARF-AS]安全注意事项部分中的建议外，这些额外注意事项还适用于生成[SPF]身份验证失败报告：
Preventing an [SPF] failure for SPF authentication failure reports is essential to mitigate the risk of data loops.
防止SPF身份验证失败报告的[SPF]失败对于降低数据循环的风险至关重要。
If the [SMTP] return address to be used will not be the NULL return address, i.e., "MAIL FROM:<>", then the selected return address MUST be selected such that it will pass [SPF] MAIL FROM checks upon initial receipt.
如果要使用的[SMTP]返回地址不是空的返回地址，即“邮件发件人：<>”，则必须选择所选的返回地址，以便在初次收到时将[SPF]邮件从支票中传递出去。
If the report is passed to the Message Submission Agent (MSA) (MSA is described in [EMAIL-ARCH] using [SMTP]), the HELO/EHLO command parameter SHOULD also be selected so that it will pass [SPF] HELO checks.
如果将报告传递给邮件提交代理（MSA）（MSA在[EMAIL-ARCH]中使用[SMTP]进行了描述），则还应选择HELO/EHLO命令参数，以便通过[SPF]HELO检查。
It is impossible to predict the volume of reports this facility will generate when enabled by a report receiver. An implementer ought to anticipate substantial volume, since the amount of abuse occurring at receivers cannot be known ahead of time, and may vary rapidly and unpredictably.
当由报告接收器启用时，无法预测此工具将生成的报告量。实施者应该预测大量的滥用，因为在接收者处发生的滥用量无法提前知道，并且可能会迅速变化，不可预测。
[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月。
[ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010.
[ARF]Shafranovich，Y.，Levine，J.，和M.Kucherawy，“电子邮件反馈报告的可扩展格式”，RFC 59652010年8月。
[ARF-AS] Falk, J. and M. Kucherawy, Ed., "Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)", RFC 6650, June 2012.
[ARF-AS]Falk，J.和M.Kucherawy，Ed.，“电子邮件反馈报告的创建和使用：滥用报告格式（ARF）的适用性声明”，RFC 66502012年6月。
[ARF-AUTHFAIL] Fontana, H., "Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6591, April 2012.
[ARF-AUTHFAIL]Fontana，H.，“使用滥用报告格式的认证失败报告”，RFC 65912012年4月。
[IANA-CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[IANA-CONS]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[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月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[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月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[EMAIL-ARCH]Crocker，D.，“互联网邮件体系结构”，RFC 55982009年7月。
The author wishes to acknowledge the following for their review and constructive criticism of this proposal: Murray Kucherawy, Tim Draegen, Julian Mehnle, and John Levine.
作者希望感谢以下各方对该提案的审查和建设性批评：Murray Kucherawy、Tim Draegen、Julian Mehnle和John Levine。
v=spf1 ra=postmaster -all
v=spf1 ra=postmaster -all
v=spf1 mx:example.org ra=postmaster -all
v=spf1 mx:example.org ra=postmaster -all
B.3. SPF DNS Record with Reporting Address, Report Percentage, and Requested Report Type
B.3. 具有报告地址、报告百分比和请求的报告类型的SPF DNS记录
v=spf1 mx:example.org -all ra=postmaster rp=10 rr=e
v=spf1 mx:example.org -all ra=postmaster rp=10 rr=e
Author's Address
作者地址
Scott Kitterman Agari 3611 Scheel Dr. Ellicott City, MD 21042 US
斯科特·基特曼·阿加里3611美国马里兰州埃利科特市谢尔博士21042
Phone: +1 301 325 5475
EMail: scott@kitterman.com
Phone: +1 301 325 5475
EMail: scott@kitterman.com