摘要

  • RFC 1036 规定，只有本机存在相应 Message-ID 的文章时才能执行 cancel；无法撤销的系统不应把请求转发给邻站。
  • 控制消息使用与普通新闻相同的新闻组分发机制，但发起人必须是原作者或本地新闻管理员，并按邮件头字段核对身份。
  • 这是一条限定在单台主机上的规范，不代表文章已从所有主机、档案或读者手中消失。

一条请求可以传播，却不因此拥有全网权限

Usenet 上的文章分布在许多由不同组织运行的主机上。一个撤销命令能不能生效，首先取决于它到达的这台机器是否保存了指定文章。RFC 1036 把这个问题写得很清楚：cancel 后面跟着 Message-ID；本机找得到文章，才可能在本机撤销。

这份 1987 年 12 月发布的规范又补上一条关键限制：如果系统无法按请求撤销文章，就不应把撤销请求转发给邻近系统。停止点不是遥远的中心，而是那个已经无法对本地副本采取行动的主机。它不能替另一台服务器确认文章是否存在，更没有权限清除自己从未持有的副本。

因此，cancel 不是一条带有全局执行力的删除命令。请求能够到达一个节点，只说明控制消息被送到那里；它不证明节点找到文章、认可请求或执行了操作，更不证明所有副本都同步。

控制消息仍走新闻的分发通道

RFC 1036 把带有 Control 字段的文章视为面向 Usenet 主机软件的控制消息，而不是供用户阅读的普通内容。它们通过与普通新闻相同的新闻组机制分发。实现者和管理员可以让控制消息自动执行，也可以排队处理；需要人工处理的消息应及时处理。失败的控制消息应送到本地 usenet 账户，而不是寄回发起人。

这个设计让传输和执行保持分开。分发机制能够把消息交给其他主机，真正的操作仍由每台主机的软件和管理者完成。节点要先按 Message-ID 查询本地文章，再根据发送者规则决定是否处理。规范没有建立一个跨站共享的删除数据库，也没有定义一张全网确认表。

发送者核对是一条有限规则

RFC 1036 允许原作者或本地新闻管理员发出 cancel。它把 Sender 字段定义为已核实发送者；若消息没有 Sender，才使用 From。撤销消息的已核实发送者必须与原文章的 Sender 或 From 相同。规范还允许：撤销消息的已核实发送者与原文中未经核实的 From 相匹配。

RFC 822 对 Sender 的角色提供背景：当实际提交者不同于作者时，这个字段可以标明提交者。但两个 RFC 都没有把字段比对变成数字签名，也没有保证它能证明现代意义上的账户控制。它说明的是程序应比较哪些值，而不是某个发送者一定真实或每个站点都执行了检查。

与 RFC 850 相比，多出一条停止规则

RFC 1036 更新并取代了 RFC 850，以反映 News 程序 B2.11 版本。1983 年的前身已经规定，本机存在的文章可以由作者或本地超级用户发起撤销。1987 年文本改用“本地新闻管理员”的称谓，并明确写出了失败边界：本机无法撤销时，不应继续转发请求。

这是规范文本的变化，不是所有 Usenet 主机升级时间的记录。RFC 1036 还明确说，它并未规定 Internet 标准；传输硬件、软件和新闻批处理方式由主机保留灵活性。我们可以说 RFC 写下了什么，不能据此推断每个站点何时采用或如何执行。

一台主机的结果不等于所有副本的结果

有的节点保存着文章，可以处理符合条件的请求；另一个节点可能没有这篇文章，于是请求在这里停止。远处的 spool、档案或引用仍可能保有内容。规范描述的是收到请求的本机如何决定，并未承诺所有副本、索引或读者看到的内容都会随之改变。

可以把“不成功就不转发”理解为：不能执行本地动作的主机不应把同一命令无条件扩散。这是对机制的推论，不是 RFC 作者在文中陈述的动机。把推论标明，才能避免把一条有限的控制规则写成全网审查或普遍删除的历史。

来源与范围

主要依据是 RFC 1036 的 Control 与 Cancel 部分、前身 RFC 850，以及说明 Sender 字段的 RFC 822。它们能证明规范如何表述规则，不能证明采用率、每台服务器的实际行为、真实传播时延、加密认证或全网删除。