13. 安全考虑

扩大电子邮件地址允许使用的字符和编码形式会增加一些风险. 人们已经讨论过所谓 "IDN 欺骗" 或 "IDN 同形异义字符攻击". 这类攻击使攻击者或网络钓鱼者能够冒充企业或其他实体的域名或 URL. 同类攻击也可能针对国际化电子邮件地址的本地部分. 应当注意, 强制把所有显示元素转换为规范化小写的修复方法适用于 URL 中的域名, 却不适用于电子邮件本地部分, 因为本地部分区分大小写.

电子邮件地址常从名片和纸质便笺上抄录, 因而容易受到可混淆字符问题的影响(见 [RFC4690]). 如果邮箱所属域明确无歧义, 且只支持少量遵循本地系统约定命名的邮箱, 这类问题会有所减轻. 如果邮件系统规模很大, 用户又能自由选择自己的地址, 问题就会加剧.

电子邮件地址和消息首部的国际化不得使 Internet 的安全性低于没有这些扩展时的水平. 本规范集合记录的要求和机制通常不会引入新的安全问题.

不过, 它们确实要求审查与可混淆字符有关的问题. 该主题已在其他地方得到深入研究, 例如 RFC 4690 [RFC4690]. 此外, 还可能需要审查 RFC 3629 [RFC3629] 所讨论的 UTF-8 规范化问题及其他转换. 规范化以及与转换和标准形式有关的其他问题, 也是其他工作所讨论的主题 [RFC5198] [RFC5893] [RFC6055].

本规范集合中的其他文档更详细地讨论了与国际化地址和消息首部直接相关的一些问题. 尤其应谨慎确保, 任何 "降级" 机制或降级后地址的使用, 都不会错误地假定国际化地址与 ASCII 地址之间存在经过认证的绑定关系. 如果规定绝大多数或全部这类转换都应在最终投递之前, 由推定处于发件用户管理控制之下的系统执行, 而不是在传输途中由不受发件用户管理控制的实体执行, 就能在一定程度上缓解这一潜在问题.

新的 UTF-8 首部和消息格式还可能引发或加剧另一个已知问题. 如果该模型产生了新的 "无效" 或 "格式错误" 消息形式, 就会出现一种新的电子邮件攻击. 为增强健壮性, 部分或大多数代理会接受这种消息, 并像解释格式良好的消息一样解释它. 如果过滤器对这种消息的解释与收件人所用 MUA 不同, 攻击者就可能构造一条在过滤器解释下看似可接受, 但按该 MUA 的解释本应拒绝的消息. 这种攻击已经出现在现有消息和编码层中, 例如无效的 MIME 语法, 无效的 HTML 标记以及特定图像类型的无效编码.

此外, 电子邮件地址还用于发送邮件以外的许多场景, 例如在各种情况下充当标识符(见第 11.2 节). 必须依次评估每种场景, 确定是否适合使用非 ASCII 形式, 以及它会引发哪些具体问题.

这项工作显然会影响依赖数字签名或类似完整性保护来保护电子邮件消息首部的系统和机制, 另见第 11.3 节. PGP 和 S/MIME 的许多传统用法只签署正文部分而不签署消息首部, 因此不受影响. 另一方面, 正在发展的域名密钥识别邮件(DKIM)工作 [RFC5863] 最终需要考虑本项工作, 反之亦然. 本规范没有处理或解决 DKIM 和其他首部签名机制提出的问题, 但如果两组协议要共存, 最终必须协调并解决这些问题. 此外, 只要电子邮件地址出现在 PKI(公钥基础设施)证书 [RFC5280] 中, 处理这些证书的标准就需要升级以支持国际化地址. 这些升级还必须处理地址自身因相似字符而被冒充的问题.