摘要

  • RFC 2449 为 POP3 加入 CAPA，让客户端以结构化方式发现扩展和服务器行为，而不必只靠试发命令或解析自然语言错误。
  • 能力清单的含义取决于会话状态；它不是授权，也不是成功回执，并可能随认证、用户策略和完整性保护而变化。

“这台服务器能做什么？”听起来像一个问题，早期 POP3 的实际答案却取决于上下文。可选命令、认证机制和服务器行为并不完全一致，客户端往往要试发命令、解读面向人的错误，或者让用户手动切换兼容设置。RFC 2449 于 1998 年 11 月发布，是对 RFC 1939 的 Standards Track 更新。它引入 CAPA，让客户端在选用扩展之前，先取得机器可解析的能力列表。

这份列表并非服务器永久不变的产品说明。CAPA 在尚未登录的 AUTHORIZATION 状态和认证之后的 TRANSACTION 状态都可用。RFC 要求每种能力都说明它在哪些状态中公告、相关命令在哪些状态中有效。认证前可用的能力必须在两个状态中都公告；但参数可能在服务器知道用户身份后变得更具体。能力标签、参数值和可执行动作彼此相关，却不是同一件事。

LOGIN-DELAY 与 EXPIRE 展示了保守值的作用。若不同账户的 LOGIN-DELAY 不同，服务器在认证前必须公布可能出现的最大等待间隔；认证后则应提供更准确的账户值。EXPIRE 表示保证的最短保留期限，并不预报某一封邮件何时会消失。若期限随用户或邮件条件变化，认证前必须公布最短可能值，认证后再尽量给出准确值。服务器尚不知道适用哪项策略，所以先给出的范围必须保护所有用户。

认证还可能改变安全上下文。RFC 2449 建议：如果认证过程协商出完整性保护层，客户端应再次发出 CAPA，检查是否发生主动降级。后来的 RFC 5034 对 SASL 安全层把边界说得更明确：客户端应丢弃先前学到的服务器信息，包括旧能力列表。在受保护上下文之外得到的信息，不会自动成为新上下文里的可信事实。

即使服务器返回了某能力，也不能据此断言每位用户都能使用。USER 标签表示支持 USER 和 PASS，但 RFC 2449 特别指出，这些命令未必对所有用户开放。服务器列出 SASL 机制，不代表凭据或本地策略会接受它；认证成功，也不保证能够取得邮箱。若 CAPA 返回 -ERR，说明连查询机制都不支持，客户端仍需采用先前的探测方式。新机制减少了猜测，但没有抹去旧服务器带来的不确定性。

RFC 2449 还定义了结构化响应码，减少客户端从自由文本猜测失败原因的需要；未知细节应被忽略，从而保持共同语法的稳定。该 RFC 同时提醒，能力列表可能泄露服务器支持的认证机制，尽管自动发现也能帮助客户端选出更强的选项。可读信息既有运行价值，也有披露成本。

因此，RFC 2449 的贡献不是承诺 POP3 服务器彼此可替换，也不是宣布探测时代结束。它为服务器能声明什么、声明适用于哪个状态、以及每种扩展受何种规则约束，设定了边界。清单可以指导下一步选择；真正发生了什么，仍需观察后续命令、响应和邮箱状态。RFC 的状态以及 IANA 登记都不能证明普遍实现或部署。

来源

RFC 2449 正文；RFC 2449 记录；RFC 2449 勘误；RFC 1939；RFC 1957；RFC 5034；RFC 1734；RFC 4422；IANA POP3 能力注册表；RFC 2384；Lu Heng：运行代码优先；Lu Heng：最小初始规范与自愿采用。