摘要

  • 每个 Netnews 代理都把自己的 Path 身份加在最左边，因此最新一步在左、最早一步在右，轨迹按书写方向的反向生长。
  • 发送方可以跳过已经出现在 Path 中的邻居，在字节回头之前消除冗余；接收方的 Message-ID 历史库仍负责最终的重复件拒绝。
  • 单个 !、双 !!、POSTED、MISMATCH 与 SEEN 表达不同强度的观察；末尾的 not-for-mail 根本不属于已访问中继列表。

重复件被拒绝时，浪费已经发生

设想三个新闻服务器组成一个有环拓扑。A 把文章交给 B，B 接受后再向感兴趣的邻居扩散。如果 B 不记得来路，它可能马上把文章交还 A。A 根据 Message-ID 发现自己已经见过，随即丢弃。系统最终没有无限复制同一篇文章，但这条链路仍然搬运了注定被拒绝的内容。

这不是一个记忆能同时解决的两件事。本地历史库回答：“我是否已经接纳过这个逻辑对象？”Path 回答：“准备发送的这个邻居是否已经在文章的行程里？”前者保证洪泛收敛，后者在传输之前削掉明显无用的工作。

RFC 1036 明确区分了两层。按 Message-ID 保存历史足以终止循环；Path 则是额外优化，尤其用于阻止 B 立刻把 A 刚送来的文章退回 A。现有的 Message-ID 文章已经讲过对象身份与最终去重，本篇只处理它之前的那次邻居决策。

最新的脚印写在最左边

Path 的时间顺序与普通阅读方向相反。B 收到 A!X!Y!Z 后，把它变成 B!A!X!Y!Z。每个处理者在左侧加名，因而越靠左越新，越靠右越接近最早的注入端。

1983 年的 RFC 850 已经描述了左侧前置规则。它允许多种分隔符，保留了 UUCP 时代“叹号路径”的形状。这个形状很像人工指定的邮件路线，所以规范也立即划线：Path 不用于回复，不应当被当作邮件地址。

新闻文章走过的链路未必能承载回信。相邻新闻中继共同理解的短名称，可能对邮件系统毫无意义。旧软件偶尔能沿着类似路径送达，并不等于协议把“回程地址”的权力交给了这串字符。

RFC 1849 保存了中间阶段的实践。它来自 1990 年代初广泛流传的草案，2010 年以历史文献身份发表，不是今天的实现规范。文献把实际用法收紧为以 ! 分隔的中继名和一个尾部本地项，并要求每个中继在前面加上自己，不再发送给列表里已有的邻居。

它还点出一个容易被“最终正确”掩盖的成本：即使返回件会被 Message-ID 历史库丢弃，没有有效 Path 仍可能让每篇文章在每条馈送链路上多走一次。名称混乱不一定破坏收敛，却会持续吞噬容量。

尾巴不是最后一个中继

旧格式最右端可能保存与发送者有关的本地部分，它不属于已经访问过的中继列表。若解析器把每个 ! 之间的片段都塞进同一个“经过服务器”数组，可能因为字符串碰巧相同而错误地屏蔽合法中继。

RFC 5536 把 path-list 与 tail-entry 分开定义。尾项可以是 not-for-mail。它既不是错误码，也不是服务器名，而是在旧地址外形里公开声明：这里不该再被当成邮箱。

同一段文本出现在哪个语法位置，决定它有没有参与中继排除的资格。列表内的 path identity 可以说明“这个代理已经经过”；POSTED 后的来源和最终尾项不可以。脱离结构做字符串匹配，会凭空扩大字段的权力。

NNTP 是传输会话，不是 Path 的主人

Usenet 早期可以借助多种方式传播。RFC 977 在 1986 年把分发、检索和发布组织成运行于 TCP 等可靠字节流之上的 NNTP；RFC 3977 在 2006 年重写了这份协议合同。

NNTP 规定双方如何交谈，却没有把 Path 变成 TCP 连接清单。RFC 5537 更明确地说，Netnews 文章处理独立于具体底层传输。一篇文章可以跨越多次会话、在同一服务器的不同组件之间移动，也可能经过网关进入另一种媒介。

所以 Path 记录的是应用层新闻代理，不是 IP 包经过的路由器，也不是下一跳命令。运营者先有自己的邻居关系、新闻组、Distribution 与接收政策，随后才用文章中的身份作为一个否定条件：准备发送的对端已经在有效轨迹里，就不要再送一次。名字不在列表里，也不等于获得了发送授权。

规范没有把不确定性抹平

2009 年的两份规范要求处理文章的注入、转发与服务组件加入 path identity。优先选择完整域名，也可使用在相关对等范围内能够保证唯一的其他名称。关键不在于中央登记，而在于相邻运营者对名称及其别名达成一致。

两个连续叹号 !! 表示左侧代理“按自己的判断”验证了右侧相邻身份。单个 ! 不作这一承诺。它们不是同一种认证的长短写法，规范故意保留了证据强度差异。

POSTED 标示注入，并可附带注入者看到的来源。MISMATCH 表示从连接环境推断的预期来源身份，与文章最左侧所声称的身份不一致。SEEN 表示接收者记录了来源，却不愿或无法把它验证为所声称的 Path 身份。预期值可能来自对等认证身份或源 IP。

因此，每个诊断都是某个接收者在某条相邻关系里的观察。MISMATCH 可能来自冒充，也可能来自别名未同步、迁移、代理或大小写差异。!! 的链条也不是端到端签名：每一项只说明左边对右边的局部判断，没有密码学承诺把整条历史锁定起来。

RFC 5537 另外建议，中继只从可信代理接收文章，以降低 Path 与 Injection-Info 被伪造的风险。若字段自身已经是认证证明，这个外部信任条件就不再需要。

它只拥有“不发给谁”的一票

现代规则建议：若潜在接收方的 path identity 或已知别名出现在有效 path list 中，就不要向它转发；尾项和 POSTED 后的来源不参与这项判断。这个规则并不要求把文章发给所有未出现的邻居。

新闻组与 Distribution 匹配、文章合法性、对等信任、容量及本地政策仍各自把关。Message-ID 历史库仍处理从其他方向到来的副本，也应对不遵守优化的对端。跨媒介网关还需单独防环，因为转换可能丢掉 Netnews 用来维持身份与轨迹的属性，再把内容重新注入。

Path 的价值正在于权限很小。它把运行中继图所需的最少历史放进文章，消除最明显的回送，却没有自封为作者身份、全球路线、存储收据或阅读证明。

RFC 能证明这种设计及其已知边界，不能证明今天某家服务怎样实现，也不能证明某条 Path 真实、某个名称仍有效或文章后来被读到。这些结论必须依靠实时会话、转移、历史库和存储证据。