摘要

  • RFC 821 允许发送者把明确的中继顺序写在邮箱之前；每台中继会从正向路径中取走自己的名字，再把它加入反向路径。
  • RFC 1123 选择以通用域名和 DNS MX 处理普通邮件路由。接收端仍须接受旧语法，却可以丢弃中间节点，直接按最终邮箱域投递。
  • 现行 SMTP 将“能解析”“允许中继”“实际执行”分成三件事：服务器可以忽略、拒绝，或在受限场景下严格执行源路由。

同一串字符，三种合规处置

设想服务器收到：

RCPT TO:<[中继 alpha、中继 beta]:[gamma 域中的 user 邮箱]>

冒号右侧是 gamma 域中的 user 最终邮箱。前面的两个域名是发送者希望经过的路线。语法仍能把二者准确分开，但它已经不能单独决定下一跳。

一台服务器可能删掉路线，直接为 gamma.example 查找目的地。另一台可能拒绝替该客户端中继。还有一台在经过认证的故障诊断中，可能真的先连接 alpha.example。三台都正确理解了输入；差别在于谁有权把输入变成网络动作。

这正是兼容性常被忽略的一面。新系统可以承诺不误读旧语言，却不承诺把旧语言曾经拥有的全部控制权一并复活。

路线曾经随邮件逐跳搬家

RFC 822 把这种结构称为 route-addr。路线部分列出发件人希望经过的主机或传输服务，而冒号后的地址仍是绝对邮箱。路线与名称在语法上本来就是两个对象。

RFC 821 让这份路线在 SMTP 信封中真正执行。标准示例把中继 ONE、TWO 写在 THREE 域的 JOE 邮箱之前：邮箱是目的地，ONE 与 TWO 是抵达它的步骤。

当邮件抵达名单中的一台中继时，该服务器从 forward-path 删除自己的标识，把它放到 reverse-path 最前面，随后从接收者变成新的 SMTP 发送者，连接名单中的下一台服务器。正向清单越走越短，反向清单越积越长；失败报告因此拥有一条回到原点的候选路径。

不过，中继仍可拒绝任务。写出一个主机名，从来不等于获得使用那台主机的凭证。RFC 821 还明确指出，信封中的路线不必出现在 To、From 或 CC 中。传输行程与作者写下的消息身份并不是同一层记录。

稳定的域名取代了发送者编写的行程表

到 1989 年，RFC 1123 已要求发送 SMTP 不再生成显式源路由形式。它给出的理由不是单纯“旧功能不好用”，而是一项架构选择：互联网邮件采用通用命名，而不是源路由。SMTP 提供端到端连通，DNS 提供全局唯一且与位置无关的名称，MX 记录则处理过去最需要中继清单的情形。

中继并没有消失。改变的是决定中继的权力。发送者指出目标域；目标域用 DNS 发布邮件交换器；参与服务器再按当前授权、可达性和策略选择下一跳。拓扑变化时，域的管理者可以更新 DNS，无须让所有通信者修改地址簿里的中间路径。

这也把不同寿命的事实拆开。gamma 域中的 user 邮箱可能长期稳定；alpha、beta 的顺序可能在一次故障、合同变更或反滥用策略调整后立即过期。

接受语法，不等于接受命令

RFC 1123 没有把旧式路径直接判为语法错误。接收 SMTP 必须接受其写法；若不实现旧中继算法，就应该尝试投递到邮箱的最终域。标准示例删除中继 ALPHA、BETA，再把 JOE 的邮箱直接交给 GAMMA 域处理。

RFC 2821 进一步固定了这条边界。接收系统必须识别源路由，却应该将其剥离，并像从未收到路线一样使用邮箱域。中继名也不得复制进 reverse-path。解析器即使认出了旧标点，也不能仅凭这一点重建 RFC 821 的返回路线。

两种错误由此同时得到约束。完全不解析，可能让旧客户端失败，甚至把分隔符错当成邮箱内容。解析后自动执行，则可能让一个遗留字符串替发送者选择当前策略禁止的中间节点。识别保障互通，不服从保障信任边界。

现行标准保留的是受限例外

RFC 5321 仍在规范路径语法中保留 A-d-l，也就是以逗号分隔的域名列表。旁边的一句规则概括了整个迁移：必须接受这种形式，不应生成，并且应该忽略。

服务器可以拒绝提供中继，也可以拒绝带源路由的地址；还可以删掉列表，直接使用最终目的地。若它明确决定执行路线，就必须先发送给列表中的第一个域，不能自作主张跳过中间项。功能虽然被弃用，例外执行仍有精确语义。

标准也指出一个迁移陷阱：有些发送者把无法由 DNS 解析的名字放在最后，指望中间中继代为理解。符合现行规则的服务器一旦剥离路线，这种隐藏依赖便会失败。字符串可以继续通过语法检查，其旧执行前提却已无效。

严重临时故障或调试仍可能构成少数使用理由。但此时的执行权来自服务器的明确政策，而不是任何客户端只要写出一串主机名就能取得。

邮件头留下了另一枚化石

RFC 5322 把消息头中的 route 归入过时地址语法，并要求解释地址时忽略路线部分。这样，归档系统仍可读懂旧邮件，而不会把历史标点重新变成一条活的 SMTP 指令。

这一点也防止层次混淆。旧 To 字段中的 route 不能证明 SMTP 信封实际包含哪些收件人，更不能证明邮件真正经过哪些服务器。真实路径需要交易记录、连接结果与 Received 轨迹来支持。

来源与证据边界

RFC 821、RFC 822、RFC 1123、RFC 2821、RFC 5321 与 RFC 5322 共同支持上述语法和规范演变。它们不统计当代部署率、产品默认值、过滤比例或实际送达结果。

历史结论因此很有限，也很清楚：SMTP 保留了理解旧路线的责任，却不再默认承认旧路线替服务器作决定的权威。