Internet Engineering Task Force (IETF) J. Klensin
Request for Comments: 7504 June 2015
Updates: 1846, 5321
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Klensin
Request for Comments: 7504 June 2015
Updates: 1846, 5321
Category: Standards Track
ISSN: 2070-1721
SMTP 521 and 556 Reply Codes
SMTP 521和556回复代码
Abstract
摘要
This memo defines two Simple Mail Transfer Protocol (SMTP) reply codes, 521 and 556. The 521 code was originally described in an Experimental RFC in 1995 and is in wide use, but has not previously been formally incorporated into SMTP. The 556 code was created to support the new tests and actions specified in RFC 7505. These codes are used to indicate that an Internet host does not accept incoming mail at all. This specification is not applicable when the host sometimes accepts mail but may reject particular messages, or even all messages, under specific circumstances.
此备忘录定义了两个简单邮件传输协议（SMTP）回复代码521和556。521代码最初是在1995年的一个实验性RFC中描述的，目前正在广泛使用，但之前尚未正式并入SMTP。创建556代码是为了支持RFC 7505中指定的新测试和操作。这些代码用于指示Internet主机根本不接受传入邮件。当主机有时接受邮件，但在特定情况下可能拒绝特定邮件，甚至拒绝所有邮件时，本规范不适用。
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/rfc7504.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7504.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The 521 Reply Code . . . . . . . . . . . . . . . . . . . . . 4
4. The 556 Reply Code . . . . . . . . . . . . . . . . . . . . . 4
5. Small Details to Avoid Loose Ends . . . . . . . . . . . . . . 5
5.1. Specific Changes to RFC 5321 . . . . . . . . . . . . . . 5
5.2. The RFC 1846 Experiment . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The 521 Reply Code . . . . . . . . . . . . . . . . . . . . . 4
4. The 556 Reply Code . . . . . . . . . . . . . . . . . . . . . 4
5. Small Details to Avoid Loose Ends . . . . . . . . . . . . . . 5
5.1. Specific Changes to RFC 5321 . . . . . . . . . . . . . . 5
5.2. The RFC 1846 Experiment . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
The SMTP specification [2] (referred to, along with its various updates, as "SMTP" below) contains a list and discussion of reply codes. This document updates that list with a new code, 521, for use in response to an initial connection. In that context, it specifically denotes a system that does not receive mail or otherwise handle SMTP mail or inquiry transactions. That code differs from the use of reply code 554, recommended by RFC 5321, because the latter code can be used in a larger variety of situations, including mail that is not accepted for, or from, particular sources, destinations, or addresses. It also introduces a second reply code, 556, for use when an SMTP client encounters a domain in a forward-pointing address that it can determine (e.g., from the DNS "null MX" convention [5]) does not support receipt of mail and has to report that condition to a host that delivered the message to it for further processing.
SMTP规范[2]（以下称为“SMTP”及其各种更新）包含回复代码的列表和讨论。本文档使用新代码521更新该列表，以用于响应初始连接。在该上下文中，它特别表示不接收邮件或以其他方式处理SMTP邮件或查询事务的系统。该代码不同于RFC 5321建议的回复代码554的使用，因为后者可用于更广泛的情况，包括不接受特定来源、目的地或地址的邮件。它还引入了第二个回复代码556，用于SMTP客户端遇到转发地址中的域时使用，该域可以确定（例如，根据DNS“null MX”约定[5]）不支持接收邮件，并且必须向向向其发送邮件的主机报告该情况以供进一步处理。
This specification updates RFC 5321 to add the new codes. The 521 code was first formally proposed in the Experimental RFC 1846 [4]; this document updates that specification to standardize the code and provide more specific treatment of it.
本规范更新RFC 5321以添加新代码。521代码首次在实验性RFC 1846[4]中正式提出；本文档更新了该规范，以标准化代码并提供更具体的处理方法。
The reader of this document is expected to have reasonable familiarity with the SMTP specification in RFC 5321, particularly its discussion of reply codes and their use and theory.
本文档的读者应熟悉RFC 5321中的SMTP规范，尤其是其对回复代码及其使用和理论的讨论。
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 RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
Many Internet hosts are not in a position -- whether technically, operationally, or administratively -- to offer mail service. If an SMTP client (sender) attempts to open a mail connection to a system that does not have an SMTP server, the connection attempt will time out. SMTP requires that timeouts result in the client queuing the message and retrying it for an extended period. That behavior will result in wasted resources and long delays in getting an error message back to its originator.
许多互联网主机在技术上、操作上或管理上都无法提供邮件服务。如果SMTP客户端（发件人）试图打开与没有SMTP服务器的系统的邮件连接，则连接尝试将超时。SMTP要求超时导致客户端将消息排队并在较长时间内重试。这种行为将导致资源浪费，并且在将错误消息返回给其发起者时出现长时间延迟。
One alternative is to run a dummy SMTP server on hosts that do not receive mail under any circumstances and have that dummy server return a fatal error reply code in response to any connection-opening
一种替代方法是在任何情况下都不接收邮件的主机上运行虚拟SMTP服务器，并让该虚拟服务器在响应任何连接打开时返回致命错误回复代码
attempt. Another is to determine, from a separate source such as a DNS record, that the host does not receive mail. This document specifies reply codes to be used for those purposes.
企图另一种方法是从单独的源（如DNS记录）确定主机不接收邮件。本文件规定了用于这些目的的回复代码。
This specification adds the 521 reply code to the repertoire specified in SMTP, reserving it for use at connection-opening time to indicate that the host does not accept mail under any circumstances. It SHOULD be used for dummy SMTP servers whose sole purpose is to notify systems that attempt to open mail connections that the host never accepts mail. It MAY be used in other situations where the intent is to indicate that the host never accepts mail. It SHOULD NOT be used for situations in which the server rejects mail from particular hosts or addresses or in which mail for a particular destination host is not accepted. As discussed in SMTP, reply code 554 is more appropriate for most of those conditions; an additional case, in which the determination that mail is not accepted is determined outside the mail system, is covered in the next section (Section 4).
此规范将521回复代码添加到SMTP中指定的指令表中，保留在连接打开时使用，以指示主机在任何情况下都不接受邮件。它应该用于虚拟SMTP服务器，其唯一目的是通知试图打开邮件连接的系统主机从不接受邮件。它可以用于其他情况，目的是表明主机从不接受邮件。它不应用于服务器拒绝来自特定主机或地址的邮件或不接受特定目标主机的邮件的情况。如SMTP中所述，回复代码554更适合大多数情况；下一节（第4节）将介绍另一种情况，即在邮件系统之外确定邮件不被接受。
"Server does not accept mail" (or a variant such as "Host", "Domain", or a related term) is an acceptable message to accompany a 521 code used for this purpose.
“服务器不接受邮件”（或“主机”、“域”或相关术语等变体）是用于此目的的521代码附带的可接受消息。
Once the 521 reply code is returned instead of the usual 220, the SMTP session proceeds normally. If the SMTP client attempts to send additional commands other than QUIT, the server MAY either continue sending 521 reply codes or simply close the connection. If the purpose of running a dummy SMTP server that returns a 521 code is to conserve resources, the latter will usually be preferable.
一旦返回521回复代码而不是通常的220，SMTP会话将正常进行。如果SMTP客户端尝试发送除QUIT以外的其他命令，服务器可能会继续发送521个回复代码，或者干脆关闭连接。如果运行返回521代码的虚拟SMTP服务器的目的是为了节省资源，则后者通常更可取。
This specification adds the 556 reply code to the repertoire specified in SMTP. When an intermediate SMTP system (typically a relay) that would normally attempt to open a mail connection to a host referred to in a forward-pointing address can determine that the host does not accept mail connections, and do so without attempting to open a connection to that target host, it is appropriate for it to return a reply with a 556 code to the system that sent it the message for outbound transmission. Interpretation of a special DNS record, found when a lookup is performed in conjunction with a RCPT command [5], is one such method (and the only standardized one at the time this specification was written).
此规范将556回复代码添加到SMTP中指定的指令表中。如果中间SMTP系统（通常是中继）通常会尝试打开到转发地址中引用的主机的邮件连接，则可以确定该主机不接受邮件连接，并且不尝试打开到该目标主机的连接，它应该向向其发送出站传输消息的系统返回带有556代码的回复。在结合RCPT命令[5]执行查找时发现的特殊DNS记录的解释就是这样一种方法（也是编写本规范时唯一的标准化方法）。
When an SMTP server returns a 556 reply code after receiving a command (such as RCPT, which contains a forward-pointing address) because it has information (such as discussed above) that the mail will not be accepted, the SMTP client is expected to handle the response like any other permanent negative completion reply to the command. This is consistent with the SMTP specification.
当SMTP服务器在收到命令（如RCPT，其中包含转发地址）后返回556回复代码，因为它具有邮件将不被接受的信息（如上文所述），SMTP客户端将像处理对该命令的任何其他永久性否定完成回复一样处理该响应。这与SMTP规范一致。
This document adds the 521 code, with message "Host does not accept mail", and the 556 code, with message "Domain does not accept mail", to the function group and numerical lists (Sections 4.2.2 and 4.2.3, respectively) of RFC 5321. It also adds the 521 code to the "CONNECTION ESTABLISHMENT" portion of Section 4.3.2 ("Command-Reply Sequences"), preceding the 554 code, and the 556 code to the "RCPT" portion of that same section.
本文件将带有消息“主机不接受邮件”的521代码和带有消息“域不接受邮件”的556代码添加到RFC 5321的功能组和数字列表（分别为第4.2.2节和第4.2.3节）。它还将521代码添加到第4.3.2节（“命令应答序列”）的“连接建立”部分（554代码之前），并将556代码添加到同一节的“RCPT”部分。
By formalizing reply code 521, this specification ends the experiment proposed in RFC 1846. That document also discusses general strategies for hosts that do not accept mail directly. That discussion is out of scope for the present document.
通过形式化回复代码521，本规范结束了RFC1846中提出的实验。该文档还讨论了不直接接受邮件的主机的一般策略。这种讨论超出了本文件的范围。
This document updates RFC 5321 to add descriptions and text for two reply codes, but there is no registry for those codes. IANA has updated the "Enumerated Status Codes" subregistry of the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry" [3] to include these codes, specifically:
本文档更新RFC 5321，为两个回复代码添加说明和文本，但这些代码没有注册表。IANA已更新了“简单邮件传输协议（SMTP）增强状态代码注册表”的“枚举状态代码”子区[3]，以包括这些代码，特别是：
o Added 521 to the list of codes associated with the enhanced code entry for X.3.2, which now references this document.
o 将521添加到与X.3.2的增强代码条目相关的代码列表中，该条目现在引用本文档。
o Added this document to the references associated with the enhanced code entry for X.1.10 and reply code 556. Note that, if a use for 556 arises that is not associated with null MX [5], it may be necessary to add an additional enhanced code, but such action is outside the scope of this document.
o 将此文档添加到与X.1.10的增强代码条目和回复代码556相关的参考中。请注意，如果出现与null MX[5]无关的556用法，则可能需要添加额外的增强代码，但此类操作不在本文档的范围内。
Not running any SMTP server, or running an SMTP server that simply emits fixed strings in response to incoming connections, should provide significantly fewer opportunities for security problems than running a complete SMTP implementation. See the Security Considerations section of RFC 7505 [5] for a discussion of security issues with that approach. Use of the specific codes provided here provides more information to the client than a generic or arbitrarily chosen 5yz code but should have no other effect on security.
不运行任何SMTP服务器，或运行简单地发出固定字符串以响应传入连接的SMTP服务器，应该比运行完整的SMTP实现提供更少的安全问题机会。请参阅RFC 7505[5]的安全注意事项部分，以了解该方法的安全问题讨论。使用此处提供的特定代码比通用或任意选择的5yz代码向客户提供更多信息，但不应对安全性产生其他影响。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[2] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[2] 《简单邮件传输协议》，RFC 5321DOI 10.17487/RFC5321，2008年10月<http://www.rfc-editor.org/info/rfc5321>.
[3] IANA, "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry", <http://www.iana.org/assignments/smtp-enhanced-status-codes>.
[3] IANA，“简单邮件传输协议（SMTP）增强状态码注册表”<http://www.iana.org/assignments/smtp-enhanced-status-codes>.
[4] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, DOI 10.17487/RFC1846, September 1995, <http://www.rfc-editor.org/info/rfc1846>.
[4] 杜兰德，A.和F.杜邦，“SMTP 521回复代码”，RFC 1846，DOI 10.17487/RFC18461995年9月<http://www.rfc-editor.org/info/rfc1846>.
[5] Levine, J. and M. Delany, "A "Null MX" No Service Resource Record for Domains That Accept No Mail", RFC 7505, DOI 10.17487/RFC7505, June 2015, <http://www.rfc-editor.org/info/rfc7505>.
[5] Levine，J.和M.Delany，“不接受邮件的域的“空MX”无服务资源记录”，RFC 7505，DOI 10.17487/RFC7505，2015年6月<http://www.rfc-editor.org/info/rfc7505>.
Acknowledgments
致谢
Alain Durand and Francis Dupont proposed the 521 code in RFC 1846 [4]. They also participated in an extended conversation and provided many useful comments that led to this document. The document also contains, with their permission, some text copied from that early specification.
Alain Durand和Francis Dupont在RFC 1846[4]中提出了521代码。他们还参加了一次广泛的对话，并提出了许多有用的意见，最终形成了这份文件。在他们的许可下，该文档还包含一些从早期规范复制的文本。
Discussion of the "null MX" approach and proposal [5] inspired the creation of this specification. Specific comments and suggestions from John Levine (co-author of that document) were also helpful.
“空MX”方法和建议[5]的讨论启发了本规范的创建。约翰·莱文（该文件的合著者）的具体评论和建议也很有帮助。
Martin Duerst and Tom Petch identified significant issues in the initial draft of the current form of the document.
Martin Duerst和Tom Petch在当前文件形式的初稿中发现了重大问题。
Dilyan Palauzov did a careful reading and identified an editorial error.
Dilyan Palauzov仔细阅读后发现了一个编辑错误。
Ned Freed, Tony Hansen, and Rolf Sonneveld suggested textual improvements that were incorporated. Tony Hansen also acted as document shepherd and made several contributions in conjunction with that role.
Ned Freed、Tony Hansen和Rolf Sonneveld建议合并文本改进。托尼·汉森（Tony Hansen）还担任文件保管员，并在担任该职务的同时做出了一些贡献。
Author's Address
作者地址
John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 United States
美国马萨诸塞州剑桥322号马萨诸塞大道1770号约翰·C·克伦辛邮编：02140
Phone: +1 617 245 1457
Email: john-ietf@jck.com
Phone: +1 617 245 1457
Email: john-ietf@jck.com