摘要

  • RFC 1957 观察到 popclient 和 netApp Systems Internet Series 会在状态指示符后没有空格时失败，但 RFC 1939 并不要求无附加文本的响应携带该空格。
  • 常见的 UCB popper 服务器总会附加信息，因此总会输出空格；稳定的多余格式逐渐成了客户端解析前提。
  • Netscape 要求 UIDL、Eudora 要求 TOP，尽管 RFC 1939 把两者列为可选命令；客户端的普及由此把服务器选项变成了实际准入条件。

POP3 状态行的核心很短：正向是 +OK，负向是 -ERR。后面如果还有文字，就用空格隔开；如果没有，响应可以直接结束。RFC 1957 明确指出，引发问题的那个空格不是 RFC 的必需项。

现实里最常见的样子却更长。UCB 的 popper 被广泛使用，后来由 Qualcomm 继续开发；它总在状态指示符后提供附加信息，也就总会留下空格。这个行为本身没有违反规范。真正的变化发生在接收端：客户端把反复见到的一个实现样式，当成了协议语法。

RFC 1957 点名了两个观察对象。可自由复制的 Unix popclient 与专有的 netApp Systems Internet Series 都期待那个空格，找不到便失败。于是，新服务器即使发出规范允许的最短响应，也可能无法与既有客户端通信。

这不是“规范错误、实现正确”的简单故事。文字规范决定哪些形式合法；部署生态决定哪些形式能活下来。当占优势的发送端只使用合法集合中的一种形式，而接收端也只学会接受这一种，规范原本保留的实现自由就会在没有修订、没有表决的情况下消失。

RFC 1957 的处理很克制。两款客户端的作者已被联系，新版本将不再要求空格；与此同时，旧版本仍应获得支持。这等于把问题拆成两个时间尺度：立即兼容已经部署的依赖，同时修复依赖的来源，避免它继续扩散。兼容并不等于承认偶然行为永远正确。

可选命令带来了另一种收窄。RFC 1939 把 TOP 与 UIDL 都放在“可选 POP3 命令”章节。RFC 1957 却记录，Netscape 要求 UIDL，Eudora 要求 TOP。这里重要的不是命令内部机制，而是条件发生了变化：规范给服务器的选择权，被常用客户端变成了是否能服务其用户的门槛。

能力发现当时也不充分。RFC 1939 说明，客户端没有通用方法判断服务器究竟未实现某个可选命令，还是暂时不愿或不能执行。1998 年的 RFC 2449 进一步指出，可选功能往往只能靠试探发现，甚至无法发现，并引入 CAPA 来公布包括 TOP、UIDL 在内的能力。它让不确定性有了显式表达，但现有证据不能证明 RFC 1957 直接导致了 RFC 2449，也不能证明所有软件随后都正确协商。

这份历史材料的价值正在于范围有限。RFC 1957 是一份更新 RFC 1939 的信息性文档，只报告了具名观察，没有给出装机量、故障频率、市场份额或损失。它没有说 popper 不合规，也没有断言客户端作者有意违背规范，更没有把 TOP 或 UIDL 改成正式必选项。

运行代码因此提供的是证据，不是自动授权。它能揭示真正会中断业务的依赖，也可能凭借重复与规模，把偶然习惯包装成不可质疑的规则。成熟的互操作性治理必须同时承认两件事：不能假装旧依赖不存在，也不能因为移除它很贵，就把它误写成协议本来如此。

来源