摘要

  • 早期规范把 Expires 称作“建议的过期日期”；字段缺失时采用站点本地默认值，磁盘空间等资源约束明确属于本地政策。
  • RFC 5536 将它定义为投稿者认为文章不再相关、可以被有效移除的时刻。这是用途判断，不是存储租约，也不是可验证的删除命令。
  • NNTP 只能回答某台服务器当前是否有文章。按编号或 Message-ID 查询失败，都不能证明文章何时、为何或是否已在所有地方消失。

同一则通知，两段存储历史

设想一则研讨会通知抵达两台新闻服务器，Message-ID 相同，Expires 都写在活动次日。第一台磁盘充足，惯例是把通知留到投稿者给出的期限；第二台正承受容量压力，采用更短的本地保留规则。

日期并没有自相矛盾。它记录投稿者知道的事实：活动结束后，这则通知对读者的用途会下降。它并未替投稿者在远端设备上划出磁盘。每个运营者掌握的则是容量、读者需求、归档规则与合规责任。

最初的关键字是“建议”

RFC 850 把 Expires 定义为建议的文章过期日期。没有该字段时，使用本地默认期限。它既可用于较早清理有自然时限的消息，也可表达重要材料需要比通常更久地保留。

规范以研讨会为例：活动之后，通知自然失去用途。同一节也提醒，站点的过期政策受可用磁盘空间等条件影响。因此，除非主题确有自然期限，用户不应随意填写；系统软件更不应为每篇文章自动生成默认 Expires。

这项克制保护了证据来源。若客户端自动加日期，它看起来像投稿者的判断，实际只是模板设置。省略字段，让站点普通政策发挥作用；写入字段，则表明投稿者提供了一项例外的用途信息。

RFC 1036 延续了同一结构：共同语法被保留，存储管理没有因此集中化。

遥远日期不是磁盘债权

很晚的日期表示投稿者预期文章长期有用，并不表示所有接收者已承诺为它保留容量。很近的日期也不是全网擦除保证。归档、调查记录、转发站、私有副本或引用都可能在日期之后继续存在。

字段既不列出保管者，也不收集删除回执。因而必须把信息期限与保管决定分开：前者写一次，随文章复制；后者在每一个真正控制字节的地方重新作出。

现代定义精确限制了投稿者的权限

RFC 5536 说，Expires 指投稿者认为文章不再相关、可以被有效移除的日期和时间，并指出它适合异常长或异常短的期限。

句子的主体很重要：是投稿者“认为”。规范没有说投稿者已预订截至该时刻的存储，也没有要求所有代理同时删除。文章可能因本地政策提前消失，也可能因归档例外在日期后继续存在。两种结果都不能单独证明日期虚假；它们只说明相关性与保管状态不同。

服务器只对自己的可用性作答

RFC 3977 把可用性置于具体 NNTP 服务器。GROUP 报告所选组内当前可用文章；按本地编号查询不到时可返回 423，按 Message-ID 查询而本机没有该文时可返回 430。

这些响应不说明文章从未存在，不证明 Expires 导致清除，也不证明其他服务器没有副本。限制回答范围并非缺陷，而是避免把本地观察伪装成全球删除证书。

RFC 5537 对保留限制给出更一般的架构边界：通过 Netnews 携带的请求依赖接收站点合作，协议本身无法强制。该段讨论 Archive 与 Distribution，并未重新定义 Expires；它所确认的是同一保管边界——语法不能接管远端存储。

注册稳定名称，不认证结果

现行 IANA 消息头字段注册表 把 Netnews 的 Expires 列为标准字段，并指向 RFC 5536。注册让实现共享名称和依据，却不审核供应商的磁盘配额、归档例外或现实执行情况。

Usenet 的历史价值正在于没有夸大能力。知道信息何时失去价值的人，可以表达这一判断；掌握磁盘的人，仍决定字节留在哪里。日期之所以能穿过网络，正因为它没有假装拥有沿途的存储空间。