摘要

  • RFC 1036 要求发往受审新闻组的文章带有 Approved:，并建议由版主添加其电子邮件地址。
  • 这是一种准入信号，而不是密码学凭证：后来的历史草案明确指出，系统无法验证这项批准声明。

决定必须随文章一起传递

Usenet 并没有把每篇文章交给某个中央服务器，由一个统一的权威批准最后版本。文章在彼此交换特定新闻组的站点之间传递，各站点保留本地副本。要让审核规则跨越这些转发环节生效，文章本身必须带有软件可读的状态：它是否可以进入正常传播，还是仍需经过审核？

1987 年 12 月发布的 RFC 1036 为这个状态指定了简短的字段名：Approved。它在一般格式中属于可选头字段，但发送到受审新闻组时就变成必需项。标准建议由版主添加该字段，并填写版主的邮件地址。地址提供了实际的联系途径，也让软件可以识别文章声称的处理状态。但文档没有规定数字签名、密钥，或可供接收站点查询的可信版主名册。

于是两个不同问题很容易被混为一谈：规则要求先有人工决定；头字段让软件知道文章声称已获得决定。这个字段既不展示审核过程，也不说明适用标准，更不能证明是谁作出的决定。“Approved”表达状态，地址指向联系人；二者都不是经过身份验证的批准收据。

同一字段也出现在新闻组控制指令上

RFC 1036 的示例让这个字段具体起来。一份日期为 1986 年 10 月 1 日的读者统计报告同时投向 news.lists 与 news.groups，头部包含 一个标明版主地址的 Approved 字段。Xref 还记录了 seismo 主机上的本地文章编号。它展示的是一条地址如何随普通新闻文章在网络上传播，并未说明字段的实际使用频率，也未说明各站点如何核验。

这个头字段还出现在影响更大的场景。RFC 1036 描述了 newgroup 控制消息，用来请求建立新闻组，并可将新组设为受审组。站点应忽略缺少 Approved 的这类消息。rmgroup 则请求从所有主机移除某个新闻组，也受到同样要求。标准提醒管理员谨慎处理，因为移除会影响整个网络。这个标记帮助软件区分普通控制消息与声称已经批准的请求，却没有认证其中的权力来源。

这揭示了分布式协议的张力：它能让某项决定在各站点可见，却不能让决定的来源自动可验证。站点可以检查字段是否存在，但字段存在本身不能证明邮箱属于认可的版主或管理员。标准提供共同的检查点，真正的信任仍来自各地的管理约定。

后来的草案直接指出信任缺口

“Son of 1036”的时间脉络需要说准确。RFC 1849 于 2010 年 3 月作为历史文档出版，保存一份据作者称在 1990 年代初广泛流传、并成为新闻软件实现事实参考的草案。文档明确表示，它提供的是历史背景，不是当前实现建议。

它把软件职责分得更清楚。发布代理处理本地读者的投稿，可以准备文章、检查格式，再把合规稿件交给传播流程。中继器接收其他发布代理或中继器已经准备好的文章，并继续转发。对于受审新闻组，没有 Approved 的文章代表读者投稿，发布代理应把它寄给版主。中继器收到这种文章时应丢弃，而不是把它改造成发给版主的邮件请求。同一套软件可能同时实现两种功能，但职责不能混淆。

这份历史草案明确写道：当时没有办法认证 Approved 头字段以确认所声称的批准确实发生，也没有一套可持续维护、及时更新的合法批准者名单。它把密码学认证列为值得探索的扩展，同时指出许多新闻系统不能实时访问密钥服务器，使问题更复杂。这说明文档承认身份边界，并不证明发生过某起伪造事件，也不证明所有站点都接受了伪造字段。

后来的 RFC 5537 形式化了注入路径：注入代理把未获批准的文章转交给 Newsgroups 中最靠前的受审组版主，通常通过电子邮件。批准与注入仍然不同于普通中继。这个较晚标准展示了职责如何被说清楚，但不能原样套用到 1980 年代的每个新闻系统。

这个标记做到了什么，又留下什么

Approved: 并非因为缺少密码学证明就毫无作用。它给相互独立的新闻软件提供共同的处理条件，也提供实际的审核联系地址，使编辑决定能够随文章穿过分布式出版系统。但这种可携带性止于该字段周围的信任关系。

网络可以传播一项批准声明，字段文字本身却不能证明声明背后的权威。人工审核、地址管理、本地规则和软件处理都是不同环节。标准给决定留了一个可见位置，却没有提供普遍适用的身份验证办法。

来源