摘要

  • 2026 年 9 月 10 日发布的 draft-ietf-mailmaint-smtputf8-syntax-05，不再自行枚举几类可用字符，而是把判断交给 PRECIS IdentifierClass，并要求满足适用的上下文规则。
  • 新版举出两类明确拒绝的输入：可能显示为空的 U+3164 HANGUL FILLER，以及只会拉长前一个阿拉伯字母、可制造许多视觉拼法的 U+0640 ARABIC TATWEEL。
  • 字符通过准入只证明它满足这套拟议语法；它不能证明邮箱存在、申请者控制邮箱、地址能沿 SMTPUTF8 路径送达，或显示出来的身份可信。
  • 第 05 版关于引号内空格与地址标点的原文仍有不一致。实现者应等待澄清并记录自己的解释，不能默默把猜测当成标准。

截图无法保全的那一个码位

设想注册系统和账户恢复系统各自留下一条记录。两块屏幕显示的都是普通管理员邮箱；一个系统接受，另一个拒绝。后来排查时，工程师才发现被拒绝的本地部分多了 U+3164。这个 HANGUL FILLER 在所用字体里没有可见宽度，但它仍然存在于 UTF-8 输入中。

问题并不始于攻击者，也不止于“长得像”。表单可能原样保存，搜索服务可能先做规范化，日志可能只保留渲染结果，邮件网关又可能采用另一套字符表。每个组件都能给出看似合理的布尔值，而没有一项布尔值解释其他组件为何不同。

第 05 版草案把 U+3164 写成反例：它看起来什么也没有，却不能进入地址。新版还加入 U+0640 ARABIC TATWEEL。这个码位按 Unicode 一般分类属于字母，但作用是延长前一个阿拉伯字母；反复插入会给同一视觉词形制造数量不定的拼写。

Datatracker 条目显示，该文档是 Mail Maintenance 工作组的活跃 Internet-Draft，目标状态为 Proposed Standard。历史记录把第 05 版记在 9 月 10 日。这只是正在审议的文本，不是 RFC、部署证明或已经发生的安全事件。

从“列出类别”改为“执行分类”

第 04 版的第二条规则直接列出 RFC 8264 的 A、H、K、F 四类以及地址标点。第 05 版改写为：地址只能含有 PRECIS IdentifierClass 判定为有效的码位；若某个码位需要上下文规则，还必须通过那条规则。

这不是单纯缩短句子。复制一份类别清单，很容易把“需要上下文”误做成“无条件允许”。RFC 8264为 IdentifierClass 设置了有效、需要上下文、禁止和尚未分配四种处置。连接控制字符是否可用，取决于相邻字符和指定算法。只查看 Unicode 大类，判断链就没有走完。

PRECIS 把 IdentifierClass 用于能够标识或寻址网络实体的协议字符串，并明确把安全优先于表达范围。传统字母、数字和可打印 ASCII 可以进入；旧式 Hangul Jamo、控制符、可忽略属性、空格、符号、兼容分解字符等则受到禁止。框架同时说明，具体 profile 仍要定义宽度映射、其他映射、大小写、规范化和方向规则。

因此，第 05 版并不意味着旧版允许的全部字符突然被禁止。真正改变的是权威定义放在哪里，以及“上下文判断”是否成为显式合规步骤。若实现继续长期维护自己的静态表，引用 PRECIS 的意义就被架空了。

“Letter”不是最终裁决

U+0640 最能说明分类权力的层次。RFC 5892把 ARABIC TATWEEL 单独列入 Exceptions，并标为 DISALLOWED；如果只执行一般属性计算，它原本会得到 PVALID。例外表改变了结果。日志只写“这是一个字母”，无法证明准入判断正确。

作者公开的测试集还覆盖双向控制符、全角兼容字母和可组合的旧式 Hangul Jamo，并把预组合的对应韩文音节作为不同结果。测试让边界可以复现，却不能证明生产中的注册、登录、目录、恢复、邮件传输和导出环节都运行同一版本。

草案第三条规则保持不变：忽略 ASCII 后，一个地址不得出现一种以上的文字系统。它允许 Han 加 ASCII 的组合，却拒绝 Han 与非 ASCII 拉丁字符混用。Unicode Standard Annex #24提供了这里所说 Script 属性的定义。这是草案为地址互操作设置的准入线，不是对多语言姓名或组织合法性的评价。

引号里的空格仍需澄清

当前第 05 版有一处不能替作者补写的文字。第二条规则原文说，地址只能包含 IdentifierClass 视为有效的码位，以及一个引号中的空格；紧随其后的例子又单独提到点、斜杠和 at 符号。公开的作者源文件也保留了同样句子。

它可能是排版错误，也可能依赖上层邮箱语法，或只是尚未完成的修订。现有证据不能判断。尤其因为标点负责分隔本地部分与域名，字符类别和语法产生式并不是同一层规则，任何实现都应把自己的解释写进测试和版本记录，等待后续文本解决。

语法有效不等于身份有效

RFC 6532允许在国际化邮件头部和地址中直接使用 UTF-8。当前草案进一步尝试收窄哪些国际化地址字符串更适合互操作。但通过这两层规则的字符串，并不会自动获得邮箱所有权或人类身份。

邮箱可能不存在；域名可能合法却具有欺骗性；地址可能在输入端通过，却在账户恢复或导出时损坏；某一跳支持 SMTPUTF8，也不能证明整条送达路径都支持。反过来，一个用户提交被禁止码位，也不证明其恶意——他可能只是从视觉材料复制了自己无法看见的字符。

BTW 先前的 SMTPUTF8 历史文章讨论的是另一条边界：国际化本地部分没有通用降级形式，因此相关传输节点必须保全它。本篇只处理输入字符串是否通过第 05 版准入谓词。传输能力与字符准入可以分别失败。

为准入决定留下一张收据

可审计的记录不应只有 true 或 false。它至少要保存原始 UTF-8 字节、按顺序展开的码位、当前检查的是邮箱语法哪一部分、每个非 ASCII 码位的 IdentifierClass 处置、适用的上下文规则及结果、文字系统计算，以及服务采用的映射、大小写、规范化和方向策略。

随后再记录 Unicode/PRECIS 数据版本、验证器构建版本、调用入口、决定时间、最终动作与纠正路径。面向操作员的界面可以同时显示安全转义和可读字符串，原始值则进入受保护证据；不能让日志再次把不可见字符抹掉。

这张准入收据是 Daniel Kade 的编辑建议，不是 IETF 要求。它不统一各服务的账户政策，只让注册表单、API、恢复系统和邮件网关能够说明：它们是否对同一输入、依据同一版本、作出了同一类决定。

信息来源