摘要

  • RFC 9755 把服务器广告的 UTF-8 能力与已认证客户端的显式启用分开；两者都不能单独证明身份、邮件库、索引与客户端已经协同工作。
  • 验收应以一封目标用户能够列出、搜索、取回、理解并采取行动的测试邮件结束，而不是以绿色协议日志结束。

最值得调查的失败，往往紧跟在一次成功之后。测试程序提交了一封含国际化头部的邮件，服务器返回 OK；目标用户却按发件人搜不到它，打不开其中嵌套的邮件，或在某个受支持客户端里完全看不到它。APPEND 的成功并非虚假，只是它回答的问题远小于“服务是否可用”。

RFC 9755 于 2025 年 3 月以标准跟踪文件发布，并取代 RFC 6855。它扩展 IMAP4rev1；IMAP4rev2 已经包含大致相同的能力。UTF8=ACCEPT 表示服务器能打开含国际化邮件的邮箱，并返回 UTF-8 邮箱名；UTF8=ONLY 包含前者，同时不再接受旧的 modified UTF-7 约定。

能力广告不是会话启用

客户端必须先完成认证，再发送 ENABLE UTF8=ACCEPT。即使服务器广告 UTF8=ONLY，客户端仍发送前一个命令，不存在 ENABLE UTF8=ONLY。RFC 5161 规定，ENABLED 响应才记录本会话实际启用的扩展；CAPABILITY 在 ENABLE 前后并不会变成会话收据。

因此，验收包要同时保留服务器版本与能力响应，以及每种真实客户端的命令和 ENABLED 响应。脱离测试会话的配置截图，无法证明任何一项。

语法能承载身份，不等于系统已配置身份

RFC 9755 没有让 LOGIN 支持 UTF-8 用户名或密码；需要这些凭据时必须使用 AUTHENTICATE。但标准随即划定边界：AUTHENTICATE 能合法传送字符串，不保证服务器所连接的身份供应系统允许这个账号。

身份应单独验收：权威身份源中确有该用户，生产认证机制能够通过，身份映射到正确邮箱，并在每条受支持访问路径上保留预期权限。否则，只是解析器接受了一串字节，服务并没有接受一个人。

APPEND 成功只是存储证明的起点

完成 ENABLE 后，支持该能力的服务器应接受带 UTF-8 头部的 APPEND；未启用时，则必须拒绝同一类 8 位头部。这组正负测试很有价值，却没有承诺消息已经被索引、呈现或发现。

新版 RFC 删除了旧的 APPEND UTF8 数据项，并指出 IMAP4rev1、IMAP4rev2 与 JMAP 都不能可靠告诉客户端某一封邮件过去是否以该数据项存储。更有意义的凭据应绑定到具体消息：保存原始测试邮件与哈希、APPEND 响应及可得的 UID，再按消息身份取回并比较服务承诺保留的字段。

邮箱名也需要独立测试向量。RFC 9755 要求它符合 Net-Unicode，并排除若干控制和分隔字符。RFC 5198 说明 NFC 如何统一规范等价序列；RFC 6532 对国际化头部也建议 NFC，并警告 NFKC 可能抹去姓名拼写信息。视觉相同、字节相同和搜索结果相同，是三种不同承诺。

Dovecot 当前文档 提供了一个实现层例子：UTF-8 邮箱名存储是独立配置，改变它会破坏既有的非 ASCII 邮箱名。这不是行业普查，也不能代表任何生产部署；它证明协议升级与邮件库存储迁移不能混为一谈。

合规的 BODYSTRUCTURE 可能有两种形态

RFC 6532 定义 message/global；不识别它的软件可能把它当作未知附件。对已启用 UTF-8 的 IMAP4rev1，RFC 9755 允许两种合法 BODYSTRUCTURE 处理，并要求客户端都能接受；IMAP4rev2 则遵循 RFC 9051。已验证的勘误 8697 把相关比较项更正为 message/rfc822。

单一顺利样例不足以验收。测试应覆盖两种 rev1 形态、rev2 形态、嵌套国际化头部，以及原始 MIME 部分的取回。界面显示一个附件图标，并不能证明客户端正确理解了服务器保存的结构。

“能取回”与“能找到”仍是两件事

启用 UTF-8 后，SEARCH 不得再带 charset 参数；SORT、THREAD 这类强制 charset 命令应使用 UTF-8。旧客户端可能正常 LIST 和 FETCH，却仍用不兼容的搜索写法。验收应记录确切查询与返回 UID，覆盖组合/分解形式、头部、邮箱名和正文。

RFC 9755 还明确承认：同一邮件库可能经 IMAP、POP、网页邮件及能力不同的客户端访问。拒绝、提示、隐藏或生成标准化 surrogate 都是政策选择，不是等价访问证明。本文不重复既有文章关于 surrogate 原件由谁保管的主线；这里要求每一条正式支持的路径，都对同一封邮件产生预先声明并实际观察到的结果。

最后一张凭据属于用户。用户能否看到邮箱、找到测试邮件、辨认发件人与收件人、打开各部分，并在政策允许时回复或转发？本文依据能证明标准语义和一个实现配置断点，不能证明厂商采用率或具名系统质量。借用 Heng Lu 对符号表示与可执行现实的区分：能力标记是表示，用户能用的邮件才是需要观察的现实。 标准链还包括 SMTP 国际化、降级转换、相应的简化 POP 行为与 IMAP4rev2 基线。它们限定互操作结论，却不会把一条成功路径变成普遍可见性。