摘要

  • 早期 SMTP 允许把中继顺序写进 forward-path；每个中继消费自己的首项，并把合适的本机名称压入 reverse-path。
  • 路由与绝对邮箱不是同一件事，SMTP 信封路径也不是正文头部的 To: 或 From:。这条边界决定了谁在安排下一跳、谁承担后续退信责任。
  • DNS MX 与全局可解释的域名把日常路由选择从发件人写下的行程移交给本地策略和分布式命名；新规范仍读得懂旧语法，却不恢复它原有的转发权力。

一个会自行缩短的收件地址

先把一笔 SMTP 事务停在 ONE。发件方已经用 MAIL FROM 提供 reverse-path，随后发出：

RCPT TO:<@ONE,@TWO:JOE@THREE>

RFC 821称 RCPT 参数为 forward-path。冒号右侧的 JOE@THREE 是绝对邮箱，冒号左侧的 @ONE,@TWO 是 source route。邮箱回答“最终要交给谁”，路由回答“先经谁去那里”。规范特意提醒，不应混淆这两种概念。

当 ONE 确认自己正是 forward-path 的第一项，它删掉 @ONE。发送到下一个环境时，剩余的向前路径成为 @TWO:JOE@THREE。与此同时，ONE 把自己的标识加到 reverse-path 前端。原来朝向收件人的一段状态，被转换成朝向错误返回方向的一段状态。

这不是给字符串做视觉上的左右移动。forward-path 决定尚未完成的递送路线；reverse-path 是已经接受中继责任后无法送达时通知所依赖的返回路线。每次交接都改变两边的状态，也改变哪一方已经进入责任链。

reverse-path 不是读者看到的 From

SMTP 信封与邮件正文头部必须分开。MAIL FROM 的 reverse-path 不必等于正文里的 From:；RCPT TO 的 forward-path 也不必逐字等于 To: 或 Cc:。前者服务于机器间传输与失败处理，后者服务于消息展示、作者身份和读者语义。

如果把本文标题里的“向后移动”理解成每个中继都改写读者看到的发件人，整套机制就会被写反。移动的是信封中的路由元素，不是作者署名。它也不等于 Reply-To，不证明谁写了正文，更不认证某个域名的控制权。

RFC 822在消息格式中把 route-addr 的 route 与 addr-spec 分开，并已劝告除特殊需要外不要采用源路由。它说明相近语法曾穿过信封与消息格式的历史边界，但不能用来取消这条边界。捕获一封邮件的头部，并不等于捕获了 SMTP 会话里实际收到的路径。

因此，事后调查若只保留规范化后的 To: 与 From:，可能根本没有保存本文研究的对象。原始 envelope-from、每个 envelope-recipient、进入时的 source route、服务器采取的路由决定和最终状态要分别记录。

名称还会随着环境改变

ONE 加入 reverse-path 时，并非机械复制来信环境里别人叫它的名称。RFC 821 要求它使用下一传输环境认识的本机名称。一个网关可能在一侧属于一种命名体系，在另一侧以另一个名称被识别；返回路径必须对将要接收它的环境有意义。

这条细节暴露了显式路径的真实成本。列表中的每一项不只要拼写正确，还要在恰当的传输环境内可以解释。发送者以为自己写下了一条全局行程，实际上每次跨环境都可能要求中继重新表达自身。

若收到 forward-path 的服务器并不是最左端命名的中继，规则也不同。它不能擅自删掉前项。它可以把那一项作为下一 SMTP 的选择依据，同时仍把自己按规则加入 reverse-path。消费动作依赖位置与身份相符，不是任何接收者都能随意截短列表。

然而“名称相符”也不是认证结论。早期语法描述的是路由处理关系，不是现代意义上的域名所有权证明、消息签名或实际经过路径的不可抵赖日志。把 reverse-path 当成经过节点的可信审计链，会赋予它从未拥有的证据强度。

MX 没有把一串中继换成另一串中继

RFC 974给邮件路由带来的变化，不是把 @ONE,@TWO 搬进 DNS。MX 记录把一个目的域映射到带优先值的邮件交换机。发送 SMTP 针对目的域查询，按规则尝试合适的交换机；发件人不再需要把完整中继次序埋进收件地址。

这把两个决定拆开了。用户或应用命名稳定的目的邮箱；发送侧 MTA 结合 DNS、可达性和本地策略决定下一跳。域的邮件主机可以更换，邮箱仍可保持不变。旧源路由则把某个时期的拓扑知识冻结进每一份地址。

RFC 974还警告，不应把 MX 记录递归追成一条夸张的路径。查询 MX 得到的是对一个目的地的交付候选与偏好，不是要求依次穿过的多个中继。把 MX-of-MX 画成 source route 的替身，会错过控制权迁移的实质。

所以，MX 的历史贡献不只是“DNS 帮邮件找到服务器”。它让普通发件人只需提供目的名称，让路由知识留在能更新、能施加策略、能观察失败的传输系统中。路径从地址内容变成了一次本地决策的结果。

1989 年：不得生成，却必须读懂

RFC 1123把迁移写成一组有意不对称的要求。Sender-SMTP 不应在 RCPT 中发送显式 @...: 源路由。文档选择了普遍命名而不是源路由：只要 user@domain 的域名全局有意义，DNS 与 MX 就能覆盖主要需求。

但 Receiver-SMTP 仍必须接受这种语法。这里的“接受”首先是解析层面的兼容，不是无条件承诺替陌生人中继。若服务器不实现所请求的源路由，它可按规范条件尝试直接向最右侧 @ 之后的最终域递送。例如从 @ALPHA,@BETA:joe@GAMMA 取出 joe@GAMMA，不代表必须依次服务 ALPHA 与 BETA。

这是一种重要的协议退役方式：停止制造旧形式，同时继续理解已在网络里流动的旧形式。若两件事同日关闭，仍在队列、网关、别名或老软件中的地址会立刻变成不可解析垃圾；若两件事永远都保持同等权力，旧拓扑又会继续支配新系统。

兼容因此不是保留原权威。它只是给接收端足够信息，在拒绝、忽略路线或向最终域递送之间作出可说明的决定。

“接受语法”绝不等于“开放中继”

显式源路由与滥用中继很容易被一句话混在一起。一个服务器可以正确解析 @ONE,@TWO:JOE@THREE，然后依据本地策略拒绝替该会话跨域转发。它也可以忽略路线，只处理最终目的地。还可以在极少数受控情形里采用路线。三者都与“解析器是否理解冒号前的语法”不同。

后来的 RFC 2821把 source route 标为 deprecated。服务器必须准备接收其语法，通常应忽略路线，也可以拒绝中继；客户端不应生成。若服务器按普通方式忽略路线，就不应再把那些中继名复制进 reverse-path。RFC 821的逐跳搬移动作只属于真正使用旧路线的模式。

若实现选择使用路线，规范反而要求它尊重第一项，不可凭猜测抄近路。这条规则限制了“半使用”状态：要么在允许范围内按声明顺序处理，要么走明确的忽略/拒绝路径，不能一边声称执行路线、一边擅自重新解释其中几项。

这也说明安全策略不能只看地址中有没有 @...:。需要分别观察解析结果、认证状态、收发域关系、允许的中继范围、最终域解析、实际选择的下一跳和响应码。把所有含源路由的地址都标为“已开放中继”，与把所有成功解析都标为“安全”，同样失真。

1994 年的邮件孤岛解释了它曾经为何合理

RFC 1711从邮件路由分类角度回看这套机制。源路由让用户把希望经过的 MTA 集成进地址；消息到达该 MTA 后，它剥去自己，再按剩余地址继续。文档举出测试路径、选择更快、更便宜或更可靠通道等可能用途。

更关键的是历史背景。早期 RFC 822 世界由许多连接稀疏的“邮件孤岛”构成。某个网关已知能抵达远端孤岛时，用户掌握拓扑并写出路径可能是送达条件，而不是多余干预。

到1994年，RFC 1711认为互联网互联已使普通最终用户不再需要掌握邮件网络拓扑，并指出不同中继对显式路径处理不一致。这不是今天的部署普查，也不能证明每种网关用途同时消失。它记录的是理由结构发生了变化：原先补足稀疏连接的用户知识，后来变成易陈旧、难一致的输入。

percent-hack、UUCP bang path 与网关地址映射属于同一时代的邻近适配，却不是本文的主机制。它们可能把路由埋入 local-part，或使用另一套分隔符。把它们统称成一种语法，会掩盖 @relay1,@relay2:user@host 独有的 forward/reverse 转换规则。

2008 年：旧语法留下，日常理由退出

RFC 5321继续把显式源路由称为不必要且不受欢迎的旧形式。MX 已消除日常需要，要求使用完全限定域名又移除了最后一个普遍性理由。客户端除调试或严重、暂时的 DNS 问题等非常情形外，不应生成。

服务器仍要读得懂旧语法，却可拒绝中继，也可忽略路线并朝最终目的地处理。这个安排不是矛盾，而是安装基础的现实：识别一个旧对象的成本，与让该对象决定新系统行为的成本可以分开。

不过，“忽略路线”也不是保证一定能救活邮件。有些历史地址依赖只在中间环境可解释的名称。若删掉路径后剩下的最终域在全球 DNS 中无意义，直送仍会失败。规范禁止制造或依赖这类无效路线，并不承诺接收端能从所有过去的局部命名中猜出正确目的地。

因此，今天看到一条旧源路由时，最准确的状态不是简单的“支持”或“不支持”。应问：语法是否被识别？路线是否被保留为证据？服务器是拒绝中继、忽略中继表，还是在受控情形中真正使用？最终域是否可解析？失败发生在会话内还是接受责任之后？

一条路径不能证明自己走过这条路径

source route 是指令，不是回执。reverse-path 的逐步增长看起来像足迹，却由参与传输的系统按照协议构造，而且历史命名可随环境改写。它不具备密码认证，也没有保证每个写入名称都对应实际、诚实、唯一的一次转发。

同样，最后看到被剥去路线的 JOE@THREE，不能证明邮件从未带过显式路径。标准化可能在边缘发生；日志可能只记录处理后的地址；消息头更可能从未保存信封路线。不存在于归一化结果，不等于不存在于输入。

可靠证据至少需要原始命令参数、会话端点、时间、服务器给出的决定、响应码、下一跳解析与转发日志。若系统为了索引方便再生成规范化地址，应把它标为派生值，并与收到的原串并存。

这套证据边界也阻止反向夸大。一个文本字段里出现 @ONE,@TWO，只能证明某处保存了这种字面形式；没有事务上下文时，它甚至不能证明某台 SMTP 服务器接受过它，更不能证明 ONE 与 TWO 真的中继了邮件。

来源与论证边界

本文只使用 RFC 821、RFC 822、RFC 974、RFC 1123、RFC 1711、RFC 2821 与 RFC 5321。它们能确定语法、处理规则、架构选择和历史判断，却不能给出当前服务器的接受率、中继暴露率、实现正确率或真实流量占比。

它们也不允许把 SMTP 源路由与 IPv4 LSRR/SSRR 合并。两者都让发送侧写下一些路径信息，但对象、语法、处理节点、安全边界和退役过程不同。相似词汇不是共同证据。