非官方中文译本声明：本页为 IETF RFC 7505《A "Null MX" No Service Resource Record for Domains That Accept No Mail》 的非官方中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布、不受版权限制；依据 BCP 78，本译本为署名翻译作品，译文力求忠实但不构成官方版本，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc7505。

RFC 7505《Null MX：声明域名不接收邮件》中文译本

IETF · RFC 7505 · 标准跟踪（Standards Track）· 2015 年 6 月

1. 引言

本文档定义了「无服务 MX」（No Service MX，非正式称为 "null MX"）作为一种简单的机制，使域名能够表明其不接收电子邮件。

SMTP 客户端在识别接收某域名邮件的服务器时，遵循一套规定的流程。[RFC5321] 的第 5 节对此有详尽说明；本质上，SMTP 客户端首先查询 DNS 的 MX 资源记录（RR），若未找到，则回退查询 DNS 的 A 或 AAAA 资源记录。因此，这种做法将一个（本有不同主要用途的）DNS 记录赋予了邮件服务语义。

若某域名没有任何 MX 记录，发件方将尝试把邮件投递到该域名 A 或 AAAA 记录中地址所指向的主机。如果这些 A/AAAA 地址上没有 SMTP 监听器，在发送方的邮件传输代理（MTA）放弃之前，邮件投递会被反复尝试很长一段时间（通常长达一周）。这会在邮件被误投时延迟对发件方的通知，并消耗发送方的资源。

本文档定义了一种 null MX，可使所有指向该域名的邮件投递尝试立即失败，而无需域名专门创建用于阻止投递尝试的 SMTP 监听器。

2. 本文档使用的约定

本文档中的关键词 "MUST"（必须）、"MUST NOT"（不得）、"REQUIRED"（需要）、"SHALL"（应）、"SHALL NOT"（不应）、"SHOULD"（应当）、"SHOULD NOT"（不应）、"RECOMMENDED"（推荐）、"MAY"（可以）和 "OPTIONAL"（可选）应按照 [RFC2119] 中的描述进行解释。

术语 "RFC5321.MailFrom" 与 "RFC5322.From" 的使用如 [RFC5598] 中所定义。

3. 指定 Null MX 的 MX 资源记录

为表明某域名不接收邮件，该域名应通告一条单独的 MX 资源记录（参见 [RFC1035] 第 3.3.9 节），其 RDATA 部分由一个优先级数值 0 和一个零长度标签组成，在区主文件（master file）中写作 "."，作为交换域名（exchange domain），用以表示该域名不存在任何邮件交换器（mail exchanger）。由于 "." 不是一个合法的主机名，null MX 记录不会与普通 MX 记录相混淆。使用 "." 作为表示「无可用服务」的伪主机名，其做法参照了 SRV 资源记录 [RFC2782]，后者中它具有类似的含义。

通告了 null MX 的域名不得（MUST NOT）再通告任何其他 MX 资源记录。

一条 null MX 记录示例如下：

example.com.  IN  MX  0  .

4. Null MX 的效果

null MX 记录在效率与可用性方面具有多种收益。

4.1. SMTP 服务器收益

邮件因用户操作失误而地址错误的情况很常见，例如地址被误写或误解，变成了 alice@www.example.com、alice@example.org 或 alice@examp1e.com，而非 alice@example.com。null MX 使邮件系统能够在用户发送该消息时就报告投递失败，而不必等到数小时或数天之后。

滥用邮件的发送者常使用伪造的、不可投递的回信地址。null MX 使投递状态通知（DSN）以及对此类邮件的其他尝试响应能够被高效地处理掉。

识别出不接收邮件的域名的能力，为 SMTP 客户端节省了资源。客户端会在首次发送尝试时就发现某地址不可投递，从而避免排队与重试。

当提交（submission）或 SMTP 中继服务器因某域名的 null MX 记录而拒绝某个信封收件人（envelope recipient）时，它应当（SHOULD）使用 556 应答码 [RFC7504]（Requested action not taken: domain does not accept mail，未采取请求的操作：域名不接收邮件）以及 5.1.10 增强状态码（Permanent failure: Recipient address has null MX，永久失败：收件人地址具有 null MX）。

一台接收方 SMTP 服务器若在 SMTP 会话中拒绝呈现了不可投递的 RFC5321.MailFrom 或 RFC5322.From 域名的电子邮件，则可以更有把握地认为：对于其他消息，后续发送 DSN 或其他响应时将能到达某个收件方 SMTP 服务器。

因某 RFC5321.MailFrom 或 RFC5322.From 域名具有 null MX 记录而拒绝邮件的 SMTP 服务器，应当（SHOULD）使用 550 应答码（Requested action not taken: mailbox unavailable，未采取请求的操作：邮箱不可用）以及 5.7.27 增强状态码（Permanent failure: Sender address has null MX，永久失败：发件人地址具有 null MX）。

556 5.1.10  Recipient address has null MX
550 5.7.27  Sender address has null MX

4.2. 从发布 Null MX 的域名发送邮件

null MX 主要用于那些不发送也不接收任何邮件，却因失误或恶意行为而仍收到邮件的域名。许多接收系统会拒绝带有无效回信地址的邮件。回信地址是处理邮件投递错误所需要的。无效的回信地址往往表明该消息是垃圾邮件。因此，邮件系统不应（SHOULD NOT）为其在 RFC5321.MailFrom 或 RFC5322.From 地址中所使用的域名发布 null MX 记录。如果某个系统仍然这样做了，它就有其邮件被拒绝的风险。

不发送邮件的域名运营者可以发布发件人策略框架（SPF）的 "-all" 策略 [RFC7208]，以明确声明这些域名不发送任何邮件。

null MX 无意取代 RFC 5321 第 4.5.5 节所描述的 null 反向路径（null reverse-path），也并不改变 null 反向路径的含义或用法。

5. 安全考虑

在 DNS 体系内，null MX 资源记录是一条普通的 MX 记录，不会带来新的安全问题。如有需要，可以使用 DNSSEC 以与普通 DNS 记录相同的方式对其加以保护。

6. IANA 考虑

IANA 已向「简单邮件传输协议（SMTP）增强状态码注册表」的「枚举状态码（Enumerated Status Codes）」子注册表添加了以下条目。

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

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

7. 参考文献

7.1. 规范性参考文献

7.2. 资料性参考文献

致谢（Acknowledgements）

我们感谢 Dave Crocker 对本文档孜孜不倦、历时长久的引导（shepherding），以及 APPSAWG 工作组成员所提出的有益建议。

作者地址（Authors' Addresses）

John Levine
Taughannock Networks
PO Box 727
Trumansburg, NY 14886
United States

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

Email: mx0dot@yahoo.com