Internet Engineering Task Force (IETF) J. Levine
Request for Comments: 7505 Taughannock Networks
Category: Standards Track M. Delany
ISSN: 2070-1721 Apple Inc.
June 2015
Internet Engineering Task Force (IETF) J. Levine
Request for Comments: 7505 Taughannock Networks
Category: Standards Track M. Delany
ISSN: 2070-1721 Apple Inc.
June 2015
A "Null MX" No Service Resource Record for Domains That Accept No Mail
不接受邮件的域的“Null MX”无服务资源记录
Abstract
摘要
Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately, this means that the A/AAAA record is taken to be mail server address even when that address does not accept mail. The No Service MX RR, informally called "null MX", formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server; this permits significant operational efficiencies.
Internet mail通过DNS确定接收服务器的地址，首先查找MX记录，然后查找a/AAAA记录作为备用记录。不幸的是，这意味着A/AAAA记录被视为邮件服务器地址，即使该地址不接受邮件。无服务MX RR，非正式地称为“空MX”，正式确定了现有机制，通过该机制，域可以宣布它不接受任何邮件，而无需提供邮件服务器；这使得运营效率显著提高。
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/rfc7505.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7505.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2
3. MX Resource Records Specifying Null MX . . . . . . . . . . . 3
4. Effects of Null MX . . . . . . . . . . . . . . . . . . . . . 3
4.1. SMTP Server Benefits . . . . . . . . . . . . . . . . . . 3
4.2. Sending Mail from Domains That Publish Null MX . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2
3. MX Resource Records Specifying Null MX . . . . . . . . . . . 3
4. Effects of Null MX . . . . . . . . . . . . . . . . . . . . . 3
4.1. SMTP Server Benefits . . . . . . . . . . . . . . . . . . 3
4.2. Sending Mail from Domains That Publish Null MX . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
This document defines the No Service MX, informally called "null MX", as a simple mechanism by which a domain can indicate that it does not accept email.
本文档将无服务MX（非正式称为“空MX”）定义为一种简单的机制，通过该机制，域可以表示它不接受电子邮件。
SMTP clients have a prescribed sequence for identifying a server that accepts email for a domain. Section 5 of [RFC5321] covers this in detail; in essence, the SMTP client first looks up a DNS MX RR, and, if that is not found, it falls back to looking up a DNS A or AAAA RR. Hence, this overloads a DNS record (that has a different primary mission) with an email service semantic.
SMTP客户端具有指定的序列，用于标识接受域电子邮件的服务器。[RFC5321]第5节对此进行了详细说明；本质上，SMTP客户端首先查找DNS MX RR，如果找不到，则返回到查找DNS a或AAAA RR。因此，这会使用电子邮件服务语义重载DNS记录（具有不同的主要任务）。
If a domain has no MX records, senders will attempt to deliver mail to the hosts at the addresses in the domain's A or AAAA records. If there are no SMTP listeners at the A/AAAA addresses, message delivery will be attempted repeatedly for a long period, typically a week, before the sending Mail Transfer Agent (MTA) gives up. This will delay notification to the sender in the case of misdirected mail and will consume resources at the sender.
如果域没有MX记录，发件人将尝试将邮件发送到域a或AAAA记录中地址的主机。如果A/AAAA地址没有SMTP侦听器，则在发送邮件传输代理（MTA）放弃之前，邮件传递将重复尝试很长一段时间，通常为一周。这将在邮件定向错误的情况下延迟通知发件人，并将消耗发件人的资源。
This document defines a null MX that will cause all mail delivery attempts to a domain to fail immediately, without requiring domains to create SMTP listeners dedicated to preventing delivery attempts.
本文档定义了一个空MX，该MX将导致向域的所有邮件传递尝试立即失败，而无需域创建专门用于阻止传递尝试的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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The terms "RFC5321.MailFrom" and "RFC5322.From" are used as defined in [RFC5598].
术语“RFC5321.MailFrom”和“RFC5322.From”的定义见[RFC5598]。
To indicate that a domain does not accept email, it advertises a single MX RR (see Section 3.3.9 of [RFC1035]) with an RDATA section consisting of preference number 0 and a zero-length label, written in master files as ".", as the exchange domain, to denote that there exists no mail exchanger for a domain. Since "." is not a valid host name, a null MX record cannot be confused with an ordinary MX record. The use of "." as a pseudo-hostname meaning no service available is modeled on the SRV RR [RFC2782] where it has a similar meaning.
为了表明域不接受电子邮件，它会公布一个MX RR（见[RFC1035]第3.3.9节），其中RDATA部分由首选项编号0和零长度标签组成，在主文件中写为“.”，作为交换域，表示域不存在邮件交换器。由于“.”不是有效的主机名，因此不能将空MX记录与普通MX记录混淆。使用“.”作为伪主机名表示没有可用的服务，这是在SRV RR[RFC2782]的基础上建模的，其含义类似。
A domain that advertises a null MX MUST NOT advertise any other MX RR.
播发空MX的域不得播发任何其他MX RR。
The null MX record has a variety of efficiency and usability benefits.
空MX记录具有多种效率和可用性优势。
Mail often has an incorrect address due to user error, where the address was mistranscribed or misunderstood, for example, to alice@www.example.com, alice@example.org, or alice@examp1e.com rather than alice@example.com. Null MX allows a mail system to report the delivery failure when the user sends the message, rather than hours or days later.
由于用户错误，邮件的地址通常不正确，例如，地址被误译或误解为alice@www.example.com, alice@example.org或alice@examp1e.com而不是alice@example.com. 空MX允许邮件系统在用户发送消息时报告传递失败，而不是数小时或数天之后。
Senders of abusive mail often use forged undeliverable return addresses. Null MX allows Delivery Status Notifications (DSNs) and other attempted responses to such mail to be disposed of efficiently.
滥发邮件的发件人经常使用伪造的无法投递的回信地址。Null MX允许有效地处理传递状态通知（DSN）和对此类邮件的其他尝试响应。
The ability to detect domains that do not accept email offers resource savings to an SMTP client. It will discover on the first sending attempt that an address is not deliverable, avoiding queuing and retries.
检测不接受电子邮件的域的能力为SMTP客户端节省了资源。它将在第一次发送尝试时发现地址不可传递，从而避免排队和重试。
When a submission or SMTP relay server rejects an envelope recipient due to a domain's null MX record, it SHOULD use a 556 reply code [RFC7504] (Requested action not taken: domain does not accept mail) and a 5.1.10 enhanced status code (Permanent failure: Recipient address has null MX).
当提交或SMTP中继服务器由于域的空MX记录而拒绝信封收件人时，应使用556回复代码[RFC7504]（未采取请求的操作：域不接受邮件）和5.1.10增强状态代码（永久故障：收件人地址的MX为空）。
A receiving SMTP server that chooses to reject email during the SMTP conversation that presents an undeliverable RFC5321.MailFrom or RFC5322.From domain can be more confident that for other messages a subsequent attempt to send a DSN or other response will reach a recipient SMTP server.
在SMTP会话期间选择拒绝电子邮件的接收SMTP服务器会显示无法传递的RFC5321.MailFrom或RFC5322.From域，对于其他邮件，后续发送DSN或其他响应的尝试将到达收件人SMTP服务器，这将更有信心。
SMTP servers that reject mail because a RFC5321.MailFrom or RFC5322.From domain has a null MX record SHOULD use a 550 reply code (Requested action not taken: mailbox unavailable) and a 5.7.27 enhanced status code (Permanent failure: Sender address has null MX).
由于RFC5321.MailFrom或RFC5322.From域具有空MX记录而拒绝邮件的SMTP服务器应使用550回复代码（未采取请求的操作：邮箱不可用）和5.7.27增强状态代码（永久故障：发件人地址具有空MX）。
Null MX is primarily intended for domains that do not send or receive any mail, but have mail sent to them anyway due to mistakes or malice. Many receiving systems reject mail that has an invalid return address. Return addresses are needed to allow the sender to handle message delivery errors. An invalid return address often signals that the message is spam. Hence, mail systems SHOULD NOT publish a null MX record for domains that they use in RFC5321.MailFrom or RFC5322.From addresses. If a system nonetheless does so, it risks having its mail rejected.
Null MX主要用于不发送或接收任何邮件，但由于错误或恶意而向其发送邮件的域。许多接收系统拒绝回信地址无效的邮件。需要返回地址以允许发件人处理邮件传递错误。无效的返回地址通常表示邮件是垃圾邮件。因此，邮件系统不应为它们在RFC5321.MailFrom或RFC5322.From地址中使用的域发布空MX记录。如果系统仍然这样做，则其邮件有被拒绝的风险。
Operators of domains that do not send mail can publish Sender Policy Framework (SPF) "-all" policies [RFC7208] to make an explicit declaration that the domains send no mail.
不发送邮件的域的操作员可以发布发件人策略框架（SPF）“-all”策略[RFC7208]，以明确声明域不发送邮件。
Null MX is not intended to be a replacement for the null reverse-path described in Section 4.5.5 of RFC 5321 and does not change the meaning or use of a null reverse-path.
Null MX不打算替代RFC 5321第4.5.5节中所述的Null反向路径，也不改变Null反向路径的含义或用途。
Within the DNS, a null MX RR is an ordinary MX record and presents no new security issues. If desired, it can be secured in the same manner as any other DNS record using DNSSEC.
在DNS中，空MX RR是普通MX记录，不会出现新的安全问题。如果需要，可以使用DNSSEC以与任何其他DNS记录相同的方式对其进行保护。
IANA has added the following entries to the "Enumerated Status Codes" subregistry of the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry".
IANA已将以下条目添加到“简单邮件传输协议（SMTP）增强状态代码注册表”的“枚举状态代码”子区。
Code: X.1.10 Sample Text: Recipient address has null MX Associated basic status code: 556 Description: This status code is returned when the associated address is marked as invalid using a null MX. Reference: This document Submitter: Authors of this document Change controller: IESG
代码：X.1.10示例文本：收件人地址具有空MX关联的基本状态代码：556说明：当使用空MX将关联地址标记为无效时，将返回此状态代码。参考：本文件提交人：本文件作者变更控制人：IESG
Code: X.7.27 Sample Text: Sender address has null MX Associated basic status code: 550 Description: This status code is returned when the associated sender address has a null MX, and the SMTP receiver is configured to reject mail from such sender (e.g., because it could not return a DSN). Reference: This document Submitter: Authors of this document Change controller: IESG
代码：X.7.27示例文本：发件人地址具有空MX关联的基本状态代码：550说明：当关联的发件人地址具有空MX时，将返回此状态代码，并且SMTP接收器配置为拒绝来自此类发件人的邮件（例如，因为它无法返回DSN）。参考：本文件提交人：本文件作者变更控制人：IESG
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] 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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 5321DOI 10.17487/RFC5321，2008年10月<http://www.rfc-editor.org/info/rfc5321>.
[RFC7504] Klensin, J., "SMTP 521 and 556 Reply Codes", RFC 7504, DOI 10.17487/RFC7504, June 2015, <http://www.rfc-editor.org/info/rfc7504>.
[RFC7504]Klensin，J.，“SMTP 521和556回复代码”，RFC 7504，DOI 10.17487/RFC7504，2015年6月<http://www.rfc-editor.org/info/rfc7504>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <http://www.rfc-editor.org/info/rfc2782>.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，DOI 10.17487/RFC2782，2000年2月<http://www.rfc-editor.org/info/rfc2782>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <http://www.rfc-editor.org/info/rfc5598>.
[RFC5598]Crocker，D.，“互联网邮件体系结构”，RFC 5598，DOI 10.17487/RFC5598，2009年7月<http://www.rfc-editor.org/info/rfc5598>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <http://www.rfc-editor.org/info/rfc7208>.
[RFC7208]Kitterman，S.，“授权在电子邮件中使用域的发件人策略框架（SPF），第1版”，RFC 7208，DOI 10.17487/RFC7208，2014年4月<http://www.rfc-editor.org/info/rfc7208>.
Acknowledgements
致谢
We thank Dave Crocker for his diligent and lengthy shepherding of this document, and members of the APPSAWG working group for their constructive suggestions.
我们感谢戴夫·克罗克（Dave Crocker）对本文件的辛勤和长期指导，并感谢APPSAWG工作组成员提出的建设性建议。
Authors' Addresses
作者地址
John Levine Taughannock Networks PO Box 727 Trumansburg, NY 14886 United States
John Levine Taughannock Networks美国纽约州杜鲁曼斯堡727号邮政信箱14886
Phone: +1 831 480 2300
Email: standards@taugh.com
URI: http://jl.ly
Phone: +1 831 480 2300
Email: standards@taugh.com
URI: http://jl.ly
Mark Delany Apple Inc. 1 Infinite Loop Cupertino, CA 95014 United States
马克·德拉尼苹果公司，美国加利福尼亚州库比蒂诺市无限环路1号，邮编95014
Email: mx0dot@yahoo.com
Email: mx0dot@yahoo.com