摘要

  • RFC 3974 展示了一个只支持 IPv4 的备用 MX：它能接收邮件，却无法把邮件转给只支持 IPv6 的主 MX；MX 优先级只排列候选，不生成中继路径。
  • DNS 结果、TCP 连接、SMTP 接收、队列状态、内部转发与最终入箱是不同回执，前一层成功不能替后一层作证。

冗余系统最容易被误判的时刻，恰好是备用节点成功接管的时候。RFC 3974 的核心例子里，主 MX 只有 IPv6，两个较低优先级 MX 只有 IPv4。IPv4 发送方能找到备用，备用也能接受 SMTP 会话；但两类节点之间没有共同传输路径。

MX 记录只给出偏好值和主机名。发送 MTA 按偏好排列候选、解析地址并尝试投递。文件的 IESG 注释特别强调，完整算法仍以 RFC 2821 为准。RFC 3974 是信息类文件，不定义新协议；后来 RFC 5321 取代了 RFC 2821。

MX 次序不是 MX 之间的网络

第一段路径从发送方到被选中的 MX，第二段路径从接收邮件的 MX 到域内最终存储。两个名字出现在同一张 DNS 列表里，不会自动获得隧道、共同地址族或转发能力。RFC 3974 认为最简单的修复是让主 MX 双栈，但没有把“双栈主站”误写成唯一答案。UUCP、IPv4/IPv6 转换器或共享存储也可以完成内部搬运。

真正的不变量是责任：接收域必须保证所有被其 MX 接收的邮件最终进入收件人的邮件存储。备用 MX 给出成功 SMTP 响应，证明责任已经转移到该中继，并不证明邮件已经抵达主站。

这套历史规则建立在 RFC 974、RFC 1123、RFC 1035 的 DNS 机制与 RFC 3596 的 AAAA 记录之上。同一个 IN MX 命名空间服务 IPv4 与 IPv6，偏好数值却不描述中继之间的可达性。

DNS 的“没有”至少有三种

RFC 3974 明确区分 NODATA、NXDOMAIN 与 SERVFAIL。NODATA 表示名称有效但没有 MX 回答，进入隐式 MX 规则；NXDOMAIN 表示域不存在，形成永久失败；SERVFAIL 是临时解析失败，需要重试。

当时一些异常 DNS 服务器对 AAAA 查询返回 SERVFAIL，IPv6 就绪的 MTA 因而把邮件留在队列等待。RFC 4074 随后专门记录这类 IPv6 DNS 异常。一次 SERVFAIL 既不能证明没有 AAAA，也不能证明已经尝试 A 记录或 IPv4 连接。

得到地址后仍有多层状态。A 与 AAAA 只能在相同 MX 偏好组内重排。TCP 25 连接失败可以转向其他地址或 MX；连接成功只是打开 SMTP 会话。临时响应、永久错误与成功接收分别触发重试、终止或责任转移。即使 SMTP 成功，域内到主 MX 或最终邮箱的路径仍需单独验证。

后续文件补充了相邻边界：RFC 7505 提供明确的 Null MX；RFC 3463 与 IANA 状态码表 组织投递状态；RFC 6724 和 RFC 8305 讨论后来的地址选择与连接竞速。它们不是对 2005 年部署的倒推统计。

RFC Editor 记录、勘误查询 和 IETF Datatracker 证明文档状态与演进，不证明事故频率或丢信数量。

运营检查应沿邮件保管链展开：DNS 响应类别、候选组、选中地址、TCP 结果、SMTP 回复、队列标识、下一跳中继与最终入箱。外部探针显示绿色，可能只是证明故障发生在它看不见的下一段。RFC 3974 让这段内部路径成为一项必须举证的事实。

来源