摘要

  • Approved 记录哪些个人或机构批准一篇 Netnews 文章发布；它不取代作者，也不能证明字段中的邮箱确实由该批准者写入。
  • proto-article 只要包含任何受管组而没有 Approved，注入代理就必须把整篇文章转给最左侧受管组的版主，无法转交时则拒绝；不能先把普通组那一份发布出去。
  • 多个受管组可以形成连续审批链。最终版主加入 Approved 并对全部必要批准负责，注入代理则通过字段之外的传输认证判断这篇文章是否真的来自版主。

一个普通组、两个受管组、一次都不能先发

设想作者把同一篇技术文章投往三个组：第一个允许普通投稿，后两个由版主审核。文章还是 proto-article，也没有 Approved。

直觉可能会把它拆成三份：普通组立即发布，另外两份分别排队。但 Netnews 后来的注入规则不是这样。只要 Newsgroups 中存在受管组而 Approved 缺席，注入代理就要把完整 proto-article 转给最左侧的受管组版主；若无法转交，则拒绝。

第一个版主批准后，可以把文章送往第二个版主。等所有受管目的地都同意，最终版主才加入批准者信息，把同一篇文章送回注入路径。普通组和两个受管组随后一起得到正式注入的文章。

这种“整篇先停下”的设计，避免了审稿还没结束，文章却已在部分目的地成为公开事实。它也清楚分开三种行为：作者创作、版主批准、注入代理准入。

早期字段已经把作者与版主并列保留

RFC 1036 规定，任何发布到受管组的消息都需要 Approved，而且应由版主加入版主的邮件地址。某些控制消息也需要这一字段。

文章的 From 并没有因此改成版主。作者依然是作者，版主的地址只是多出的一条发布授权归属。一个人对文字负责，另一个人对它是否进入某个受管空间负责。

这条界线保护双方。真实作者不因为身份可信就自动拥有直发权限；版主也不因为批准文章就成为正文作者。字段不是把两种责任合并，而是让它们能够同时被看见。

服务器公布的是常规路径，不是个人权利

RFC 3977 的 NNTP LIST ACTIVE 让客户端查看服务器如何处理各组。状态 y 表示通常允许投稿，n 表示不允许，m 表示投稿会被转给版主。

规范同时提醒，这个状态未必针对当前客户端定制。即使显示 y，某个客户端仍可能没有投稿权；拥有特殊权限的客户端，也可能在显示 n 的组里执行不同操作。

所以 m 描述的是服务器的常规流程，而不是发给读者的一张永久许可证。它告诉软件“这里通常先去版主那里”，却不负责说明版主是谁、认证凭据是什么，或者某篇文章会不会被接受。

Approved 只是一份批准者邮箱清单

RFC 5536 把 Approved 定义为 mailbox-list：其中的邮箱地址以及可能出现的全名，标识批准文章发布的个人或机构。主要用途是受管文章与组控制消息。

允许多个邮箱很重要，因为一篇 crosspost 可能穿过多个受管组。但这个语法能回答的只是：“文章声称由谁批准？”

它不能证明邮箱存在，不能证明邮箱所有者看过这篇文章，不能证明该地址今天仍是版主，也不能迫使接收站点信任它。结构正确的邮箱清单是可携带的归属声明，并不是密码学证明。

转给版主时，文章仍在注入边界之外

RFC 5537 把受管流程直接放进注入步骤。注入代理发现任何受管组而文章没有 Approved 时，必须转交或拒绝。它会在必要时先补齐 Message-ID 与 Date，但转交发生在加入 Injection-Info、Injection-Date 等正式注入痕迹之前。

因此，这个对象已经有了足以维持审稿旅程的身份，却还不能冒充已发布文章。它可以封装成 application/news-transmission 通过邮件送给版主，也可以用包含新闻字段的普通邮件形式，或进入一套能够保留 proto-article 而不执行注入的本地数据库。

选择 Newsgroups 中最左侧的受管组，给多版主流程一个确定的起点。这个顺序并不表示第一个版主能够代表其余所有受管组。

最后加入字段的人承担整条批准链责任

如果还有其他受管组没有批准，版主可以与同行协调，也可以附上中间批准说明，把 proto-article 转给下一个尚未批准的版主。文章保持为同一审稿对象，不需要先在网络里制造多个公开版本。

当所有必要批准到齐，最后一位版主加入 Approved，标识自己，并在可行范围内列出其他批准者。RFC 5537 把责任写得很重：执行这一步的版主负责确保文章已经得到所有受管目的地版主的同意。

因此，字段是审批流程的结论，却不是完整流程记录。它看不出版主采用什么准则、相互如何协调、修改了哪些地方，或最后一位版主检查了什么证据。版主可以修改头部和正文，不过规范建议尽量少改，因为修改可能破坏作者或前序版主创建的签名。

伪造字段不需要破坏任何语法

RFC 5537 的安全部分直言：恶意投稿者可以自己加入 Approved，试图绕过受管流程。mailbox-list 再规范，也无法阻止一个人键入别人的地址。

所以注入代理应当确认：声称已经获批的文章，确实由版主注入。证据来自底层传输的认证信息，或站点与版主另行约定的认证机制。规范还承认，当时没有一种标准化方法来认证受管组批准，虽然存在非标准方案。

这形成两个互补层次。文章内部携带“谁被声称为批准者”的可移植信息；注入边界持有“文章是否真的从受权版主通道返回”的本地证据。只有字段而没有外部认证，声明可以伪造；只有通道而没有字段，下游又失去可携带的批准归属。

IANA 登记了字段，没有登记谁值得信任

IANA 消息头字段注册表 把 Approved 列为标准 Netnews 字段，并指向 RFC 5536。实现可以据此统一名称、协议范围和规范出处。

登记表不会任命版主，不提供今天的版主名单，不验证邮箱所有权，也不要求每个服务器接受某位批准者。官方来源同样不能证明当前 Usenet 服务怎样实现这一流程。字段可以跨系统，信任关系仍停留在各系统边缘。

发布授权可以随文传播，却不会变成作者身份

Approved 解决的是一个很窄但很难的分布式问题：一篇文章通过审稿后，如何让后续中继站知道这一事实，并保留批准归属，同时不把版主写成作者。邮箱清单足以携带声明。

但它不足以保护声明。安全性来自注入代理对版主的认识，以及文章返回时采用的认证通道。字段看似打开了发布之门，实际上门早已由本地信任边界决定“相信谁”。

这段历史留下两个仍然重要的区别：批准不等于创作，可读身份也不等于已认证身份。作者写文章，版主授权目的地，注入代理判断这份授权是否可信。三种责任只有被分别保存，受管发布才不会变成一行可随意伪造的文字。