10. 用户界面与配置问题

地址和消息首部的国际化, 特别是与 Unicode 固有的字符编码变化相结合时, 可能使谨慎选择地址以及谨慎配置服务器和 DNS 记录变得比传统 Internet 电子邮件中更加重要. 随着这些协议的使用经验不断积累, 很可能需要制定一份或多份额外文档, 为配置和界面提供指导. 预计还会制定一份讨论 MUA 问题, 尤其是降级问题的文档. 以下小节处理其他一些问题.

10.1 邮箱名称的选择与 Unicode 规范化

长期以来, 电子邮件语法一直允许选择一些在实践中并不明智的邮箱名称, 特别是当确实希望大量发件人都能访问这些邮箱时. 最常被引用的例子包括在邮箱本地部分中使用大小写敏感性, 以及以复杂引号方式嵌入字符. 协议允许这些刻意设计的特殊结构, 也期望服务器支持它们. 尽管它们在特殊情况下可能有价值, 但除非目的就是通过隐蔽性产生某种安全效果, 否则利用这些结构几乎总是不良做法.

如果没有这些扩展, SMTP 客户端和服务器只能使用 RFC 5321 允许的地址. 这些地址的本地部分 MAY 由 RFC 5321 禁止的控制字符之外的任何 ASCII 字符组成, 但其中一些字符 MUST 按该文档的规定加引号. 在国际化场景中值得注意的是, 某些系统长期在带引号字符串中使用叠打 ASCII 字符, 即一个字符, 一个退格符, 再加另一个字符, 以近似表示非 ASCII 字符. RFC 821 [RFC0821] 曾允许这种国际化形式, 但 RFC 5321 禁止这种做法, 因为它需要使用退格字符, 而退格是被禁止的 C0 控制字符. RFC 5321 及其前身 RFC 2821 已禁止 ASCII 邮箱名称使用该字符, 而该字符在非 ASCII 字符串中还会带来更严重的规范形式和规范化问题, 因此退格字符 MUST NOT 出现在 SMTPUTF8 邮箱名称中.

对于本地部分, 域部分或两者包含非 ASCII 字符的邮箱名称, MUST 特别注意 Unicode 规范化 [Unicode-UAX15]. 原因之一是, 独立于邮件协议的其他过程也可能规范化 Unicode 字符串, 这与传统地址可能经历加引号和去引号的情况完全类似. 因此, 对邮箱命名提出以下建议:

• 通常应支持规范化形式的地址, 至少支持 NFC. 除非 NFKC 会把目标邮件服务器管理者希望保持可区分的字符映射到一起, 否则支持符合 NFKC 的形式会让普通用户获得更可预测的行为.

• 通常还应支持同一本地部分字符串的其他形式, 方法可以是将其设为别名, 也可以对到达投递服务器的字符串进行规范化. 不应依赖发件人一定发送规范化形式的字符串.

• 换一种更具体的说法, 协议对本地部分字符串的规则实质上意味着:

  • 未规范化的字符串是有效的, 但这种做法很差, 可能无法在全球范围内可靠工作. 服务器不应依赖客户端发送规范化形式, 但应意识到 MUA 无法控制的客户端机器处理过程可能违背用户意图而发送规范化字符串.

  • C0 控制字符被禁止, C1 控制字符也应当被禁止. 前者由 RFC 5321 禁止, 后者是从该规则自然扩展而来 [RFC5198].

  • 其他类型的标点, 空格等字符具有风险. 它们也许能够工作, 而且 SMTP 接收端代码必须能够处理它们而不发生严重错误, 即使服务器不接受包含这些字符串的投递地址. 但在选定邮箱名称时依赖这些字符通常是不良做法, 可能导致互操作问题.