11. 其他问题

本节指出本规范集合尚未涵盖或尚未全面涵盖的问题. 在部署电子邮件地址和首部国际化的过程中, 这些问题需要持续审查.

11.1 对 URI 和 IRI 的影响

在本项工作完成并标准化之后, mailto: 方案 [RFC6068] 以及国际化资源标识符(IRI)规范 [RFC3987] 中对它的讨论可能需要修改.

11.2 将电子邮件地址用作标识符

在当代 Internet 的许多使用场景中, 电子邮件地址被用作个人标识符, 包括作为某些电子商务站点的 Web 服务器标识符, 以及用于某些 X.509 证书 [RFC5280]. 本文档集合不处理这些用途, 但可以合理预期, 国际化地址首次用于这些场景时会遇到一些困难, 因为其中许多系统甚至无法处理当前已经允许的完整地址范围.

11.3 编码词, 签名消息与降级

电子邮件格式的一个重要特征是持久性. MUA 不仅要处理几秒钟前刚投递的消息, 也应当能够处理几十年前发送的消息. 因此, MUA 和 Sieve [RFC5228] 所规定的邮件过滤软件等系统, 仍需继续接受并解码使用 "编码词" 机制 [RFC2047] 在某些首部字段中容纳非 ASCII 字符的消息. POP3 [RFC1939] 和 IMAP [RFC3501] 已分别定义扩展, 可由 POP3 服务器 [RFC5721bis-POP3] 或 IMAP 服务器 [RFC5738bis-IMAP] 自动升级以编码形式携带非 ASCII 信息的消息, 包括执行 RFC 2047 解码. 但是, 对某些消息结构和 MIME 内容类型而言, 这种升级无法执行, 或会产生不可接受的副作用.

例如, 使用 S/MIME [RFC5751] 或 Pretty Good Privacy(PGP) [RFC3156] 等技术进行密码签名的消息部分, 无法从 RFC 2047 形式升级为普通 UTF-8 字符而不破坏签名. 同样, 加密消息部分在解密后可能包含采用 RFC 2047 编码的首部字段. 没有密码密钥, 这类消息就无法得到 "完全" 升级.

如果消息先签名, 随后又按第 8.1 节所述方式降级, 然后再尝试恢复到原始形式并验证签名, 也可能出现类似问题. 降级后再升级算法产生的极细微变化, 只要影响主消息首部或 MIME 正文部分首部, 就可能足以使签名失效. 存在签名时, 即使确实要降级, 也必须极其谨慎.

11.4 本地部分的其他用途

本地部分有时用于构造域标签. 例如, 地址 [email protected] 中的本地部分 user 可以转换为主机名 user.domain.example, 其 Web 空间位于 http://user.domain.example, 并可使用 [email protected] 这样的全匹配地址.

这类方案显然会受到 SMTP 域名规则等因素限制, 而且如果不对其他本地部分施加进一步限制就无法工作. 这些限制是否与本规范有关仍是一个开放问题. 这也可能只是投递 MTA 在决定接受哪些邮箱名称以及如何解释它们时所拥有的高度灵活性的另一个例子.

11.5 非标准封装格式

某些应用使用类似 application/mbox [RFC4155] 的格式, 而不是 RFC 2046 第 5.1.5 节 [RFC2046] 定义的 message/digest 形式, 将多条消息作为一个单元传输. 如果这些应用假定所有存储消息都采用 RFC 2046 第 5.2.1 节 [RFC2046] 所述, 具有 ASCII 消息首部的 message/rfc822 格式, 那么它们尚未准备好支持本系列文档规定的扩展, 可能需要采取特殊措施才能正确检测和处理这些消息.