Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 7372 September 2014
Updates: 7208
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 7372 September 2014
Updates: 7208
Category: Standards Track
ISSN: 2070-1721
Email Authentication Status Codes
电子邮件身份验证状态代码
Abstract
摘要
This document registers code points to allow status codes to be returned to an email client to indicate that a message is being rejected or deferred specifically because of email authentication failures.
此文档注册代码点，以允许将状态代码返回到电子邮件客户端，以指示邮件被拒绝或延迟，特别是因为电子邮件身份验证失败。
This document updates RFC 7208, since some of the code points registered replace the ones recommended for use in that document.
本文档更新了RFC 7208，因为注册的一些代码点替换了该文档中推荐使用的代码点。
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/rfc7372.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7372.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. New Enhanced Status Codes . . . . . . . . . . . . . . . . . . 3
3.1. DKIM Failure Codes . . . . . . . . . . . . . . . . . . . 3
3.2. SPF Failure Codes . . . . . . . . . . . . . . . . . . . . 4
3.3. Reverse DNS Failure Code . . . . . . . . . . . . . . . . 5
3.4. Multiple Authentication Failures Code . . . . . . . . . . 5
4. General Considerations . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. New Enhanced Status Codes . . . . . . . . . . . . . . . . . . 3
3.1. DKIM Failure Codes . . . . . . . . . . . . . . . . . . . 3
3.2. SPF Failure Codes . . . . . . . . . . . . . . . . . . . . 4
3.3. Reverse DNS Failure Code . . . . . . . . . . . . . . . . 5
3.4. Multiple Authentication Failures Code . . . . . . . . . . 5
4. General Considerations . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8
[RFC3463] introduced Enhanced Mail System Status Codes, and [RFC5248] created an IANA registry for these.
[RFC3463]引入了增强的邮件系统状态代码，[RFC5248]为这些代码创建了IANA注册表。
[RFC6376] and [RFC7208] introduced, respectively, DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF), two protocols for conducting message authentication. Another common email acceptance test is the reverse Domain Name System (DNS) check on an email client's IP address, as described in Section 3 of [RFC7001].
[RFC6376]和[RFC7208]分别介绍了域密钥标识邮件（DKIM）和发送方策略框架（SPF），这两种协议用于执行消息身份验证。另一种常见的电子邮件接受测试是对电子邮件客户端IP地址进行反向域名系统（DNS）检查，如[RFC7001]第3节所述。
The current set of enhanced status codes does not include any code for indicating that a message is being rejected or deferred due to local policy reasons related to any of these mechanisms. This is potentially useful information to agents that need more than rudimentary handling information about the reason a message was rejected on receipt. This document introduces enhanced status codes for reporting those cases to clients.
当前的一组增强状态代码不包括任何代码，用于指示由于与这些机制相关的本地策略原因而拒绝或延迟消息。对于代理来说，这可能是非常有用的信息，因为代理需要的不仅仅是关于消息在接收时被拒绝的原因的基本处理信息。本文档介绍了向客户报告这些案例的增强状态代码。
Section 3.2 updates [RFC7208], as new enhanced status codes relevant to that specification are being registered and recommended for use.
第3.2节更新了[RFC7208]，因为与该规范相关的新增强状态代码正在注册并建议使用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
The new enhanced status codes are defined in the following subsections.
以下小节定义了新的增强状态代码。
In the code point definitions below, the following definitions are used:
在下面的代码点定义中，使用了以下定义：
passing: A signature is "passing" if the basic DKIM verification algorithm, as defined in [RFC6376], succeeds.
通过：如果[RFC6376]中定义的基本DKIM验证算法成功，则签名为“通过”。
acceptable: A signature is "acceptable" if it satisfies all locally defined requirements (if any) in addition to passing the basic DKIM verification algorithm (e.g., certain header fields are included in the signed content, no partial signatures, etc.).
可接受：如果签名除了通过基本DKIM验证算法（例如，签名内容中包含某些标题字段，没有部分签名等）外，还满足所有本地定义的要求（如果有），则该签名是“可接受的”。
Code: X.7.20 Sample Text: No passing DKIM signature found Associated basic status code: 550 Description: This status code is returned when a message did not contain any passing DKIM signatures. (This violates the advice of Section 6.1 of RFC 6376.) Reference: [RFC7372]; [RFC6376] Submitter: M. Kucherawy Change controller: IESG
代码：X.7.20示例文本：未找到传递的DKIM签名关联的基本状态代码：550说明：当消息不包含任何传递的DKIM签名时，将返回此状态代码。（这违反了RFC 6376第6.1节的建议。）参考：[RFC7372]；[RFC6376]提交人：M.Kucherawy变更控制员：IESG
Code: X.7.21 Sample Text: No acceptable DKIM signature found Associated basic status code: 550 Description: This status code is returned when a message contains one or more passing DKIM signatures, but none are acceptable. (This violates the advice of Section 6.1 of RFC 6376.) Reference: [RFC7372]; [RFC6376] Submitter: M. Kucherawy Change controller: IESG
代码：X.7.21示例文本：未找到可接受的DKIM签名关联的基本状态代码：550说明：当消息包含一个或多个正在传递的DKIM签名，但均不可接受时，将返回此状态代码。（这违反了RFC 6376第6.1节的建议。）参考：[RFC7372]；[RFC6376]提交人：M.Kucherawy变更控制员：IESG
Code: X.7.22 Sample Text: No valid author-matched DKIM signature found Associated basic status code: 550 Description: This status code is returned when a message contains one or more passing DKIM signatures, but none are acceptable because none have an identifier(s) that matches the author address(es) found in the From header field. This is a special case of X.7.21. (This violates the advice of Section 6.1 of RFC 6376.) Reference: [RFC7372]; [RFC6376] Submitter: M. Kucherawy Change controller: IESG
代码：X.7.22示例文本：未找到与DKIM签名匹配的有效作者关联的基本状态代码：550说明：当消息包含一个或多个正在传递的DKIM签名时，将返回此状态代码，但没有一个是可接受的，因为没有一个具有与发件人标头字段中找到的作者地址匹配的标识符。这是X.7.21的一个特例。（这违反了RFC 6376第6.1节的建议。）参考：[RFC7372]；[RFC6376]提交人：M.Kucherawy变更控制员：IESG
Code: X.7.23 Sample Text: SPF validation failed Associated basic status code: 550 Description: This status code is returned when a message completed an SPF check that produced a "fail" result, contrary to local policy requirements. Used in place of 5.7.1, as described in Section 8.4 of RFC 7208. Reference: [RFC7372]; [RFC7208] Submitter: M. Kucherawy Change controller: IESG
代码：X.7.23示例文本：SPF验证失败关联的基本状态代码：550说明：当消息完成产生“失败”结果的SPF检查时，返回此状态代码，与本地策略要求相反。用于代替5.7.1，如RFC 7208第8.4节所述。参考文献：[RFC7372]；[RFC7208]提交人：M.Kucherawy变更控制员：IESG
Code: X.7.24 Sample Text: SPF validation error Associated basic status code: 451/550 Description: This status code is returned when evaluation of SPF relative to an arriving message resulted in an error. Used in place of 4.4.3 or 5.5.2, as described in Sections 8.6 and 8.7 of RFC 7208. Reference: [RFC7372]; [RFC7208] Submitter: M. Kucherawy Change controller: IESG
代码：X.7.24示例文本：SPF验证错误相关基本状态代码：451/550说明：当与到达消息相关的SPF评估导致错误时，将返回此状态代码。如RFC 7208第8.6节和第8.7节所述，用于代替4.4.3或5.5.2。参考文献：[RFC7372]；[RFC7208]提交人：M.Kucherawy变更控制员：IESG
Code: X.7.25 Sample Text: Reverse DNS validation failed Associated basic status code: 550 Description: This status code is returned when an SMTP client's IP address failed a reverse DNS validation check, contrary to local policy requirements. Reference: [RFC7372]; Section 3 of [RFC7001] Submitter: M. Kucherawy Change controller: IESG
代码：X.7.25示例文本：反向DNS验证失败关联的基本状态代码：550说明：当SMTP客户端的IP地址未通过反向DNS验证检查时，将返回此状态代码，这与本地策略要求相反。参考文献：[RFC7372]；[RFC7001]提交人第3节：M.Kucherawy变更控制员：IESG
Code: X.7.26 Sample Text: Multiple authentication checks failed Associated basic status code: 550 Description: This status code is returned when a message failed more than one message authentication check, contrary to local policy requirements. The particular mechanisms that failed are not specified. Reference: [RFC7372] Submitter: M. Kucherawy Change controller: IESG
代码：X.7.26示例文本：多个身份验证检查失败关联的基本状态代码：550说明：与本地策略要求相反，当一条消息多次身份验证检查失败时，将返回此状态代码。未指定失败的特定机制。参考：[RFC7372]提交人：M.Kucherawy变更控制员：IESG
By the nature of the Simple Mail Transfer Protocol (SMTP), only one enhanced status code can be returned for a given exchange between client and server. However, an operator might decide to defer or reject a message for a plurality of reasons. Clients receiving these codes need to consider that the failure reflected by one of these status codes might not reflect the only reason, or the most important reason, for non-acceptance of the message or command.
根据简单邮件传输协议（SMTP）的性质，对于客户端和服务器之间的给定交换，只能返回一个增强的状态代码。然而，操作员可能出于多种原因决定延迟或拒绝消息。接收这些代码的客户端需要考虑，这些状态代码中的一个所反映的失败可能不反映不接受消息或命令的唯一原因，或最重要的原因。
It is important to note that Section 6.1 of [RFC6376] discourages special treatment of messages bearing no valid DKIM signature. There are some operators that disregard this advice, a few of which go so far as to require a valid Author Domain Signature (that is, one matching the domain(s) in the From header field) in order to accept the message. Moreover, some nascent technologies built atop SPF and DKIM depend on such authentications. This work does not endorse configurations that violate DKIM's recommendations but rather acknowledges that they do exist and merely seeks to provide for improved interoperability with such operators.
需要注意的是，[RFC6376]第6.1节不鼓励对没有有效DKIM签名的消息进行特殊处理。有些运营商无视此建议，其中一些运营商甚至要求有效的作者域签名（即，与发件人标头字段中的域匹配的签名）才能接受消息。此外，一些建立在SPF和DKIM之上的新兴技术依赖于此类认证。这项工作并不支持违反DKIM建议的配置，而是承认它们确实存在，只是寻求改进与此类运营商的互操作性。
A specific use case for these codes is mailing list software, which processes rejections in order to remove from the subscriber set those addresses that are no longer valid. There is a need in that case to distinguish authentication failures from indications that the recipient address is no longer valid.
这些代码的一个特定用例是邮件列表软件，它处理拒绝，以便从订户集中删除那些不再有效的地址。在这种情况下，需要区分身份验证失败与收件人地址不再有效的迹象。
If a receiving server performs multiple authentication checks and more than one of them fails, thus warranting rejection of the message, the SMTP server SHOULD use the code that indicates multiple methods failed rather than only reporting the first one that failed. It may be the case that one method is always expected to fail; thus, returning that method's specific code is not information useful to the sending agent.
如果接收服务器执行多个身份验证检查，并且其中多个检查失败，从而保证拒绝邮件，SMTP服务器应使用指示多个方法失败的代码，而不是仅报告第一个失败的方法。可能有一种方法总是会失败；因此，返回该方法的特定代码对于发送代理来说不是有用的信息。
The reverse IP DNS check is defined in Section 3 of [RFC7001].
[RFC7001]第3节中定义了反向IP DNS检查。
Any message authentication or policy enforcement technologies developed in the future should also include registration of their own enhanced status codes so that this kind of specific reporting is available to operators that wish to use them.
将来开发的任何消息身份验证或策略实施技术还应包括注册其自身的增强状态代码，以便希望使用它们的运营商可以使用此类特定报告。
Use of these codes reveals local policy with respect to email authentication, which can be useful information to actors attempting to deliver undesired mail. It should be noted that there is no specific obligation to use these codes; if an operator wishes not to reveal this aspect of local policy, it can continue using a generic result code such as 5.7.7, 5.7.1, or even 5.7.0.
这些代码的使用揭示了有关电子邮件身份验证的本地策略，这对于试图传递不需要的邮件的参与者来说是有用的信息。应注意的是，没有使用这些规范的具体义务；如果运营商不想透露本地政策的这一方面，可以继续使用通用结果代码，如5.7.7、5.7.1甚至5.7.0。
Registration of new enhanced status codes, for addition to the Enumerated Status Codes sub-registry of the SMTP Enhanced Status Codes Registry, can be found in Section 3.
可在第3节中找到新增强状态代码的注册，以添加到SMTP增强状态代码注册表的枚举状态代码子注册表中。
[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月。
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[RFC3463]Vaudreuil，G.，“增强邮件系统状态代码”，RFC 3463，2003年1月。
[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", BCP 138, RFC 5248, June 2008.
[RFC5248]Hansen，T.和J.Klensin，“SMTP增强邮件系统状态代码的注册表”，BCP 138，RFC 5248，2008年6月。
[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, September 2011.
[RFC6376]Crocker，D.，Hansen，T.，和M.Kucherawy，“域密钥识别邮件（DKIM）签名”，STD 76，RFC 63762011年9月。
[RFC7001] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7001, September 2013.
[RFC7001]Kucherawy，M.，“用于指示消息身份验证状态的消息头字段”，RFC 70012013年9月。
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, April 2014.
[RFC7208]Kitterman，S.，“授权在电子邮件中使用域的发件人策略框架（SPF），第1版”，RFC 7208，2014年4月。
Claudio Allocchio, Dave Crocker, Ned Freed, Arnt Gulbrandsen, Scott Kitterman, Barry Leiba, Alexey Melnikov, S. Moonesamy, Hector Santos, and Stephen Turnbull contributed to this work.
Claudio Allocchio、Dave Crocker、Ned Freed、Arnt Gulbrandsen、Scott Kitterman、Barry Leiba、Alexey Melnikov、S.Moonesamy、Hector Santos和Stephen Turnbull为这项工作做出了贡献。
Author's Address
作者地址
Murray S. Kucherawy 270 Upland Drive San Francisco, CA 94127 USA
Murray S. Kucherawy 270高地驱动旧金山，CA 94127美国
EMail: superuser@gmail.com
EMail: superuser@gmail.com