跳到主要内容

RFC 6530 - 国际化电子邮件概述与框架

  • 状态: 提议标准
  • 发布: 2012 年 2 月
  • 文档流: IETF
  • 废止: RFC 4952, RFC 5504, RFC 5825
  • 勘误: 无勘误

文档信息​

  • RFC 编号: 6530
  • 标题: 国际化电子邮件概述与框架
  • 作者: J. Klensin, Y. Ko
  • 日期: 2012 年 2 月
  • 类别: 标准跟踪
  • 废止: RFC 4952, RFC 5504, RFC 5825
  • ISSN: 2070-1721

摘要​

要在世界范围内充分使用电子邮件, 人们就必须能够在其他约束允许的前提下, 使用与自己姓名非常接近的形式作为电子邮件地址中的邮箱名称, 并以自己的语言和文字正确书写该姓名. 本文档介绍一组规范, 它们定义了完整支持国际化电子邮件地址所需的机制和协议扩展. 这些变更包括一项 SMTP 扩展, 以及对电子邮件首部语法的扩展, 以容纳 UTF-8 数据. 这组文档还讨论了部署完全国际化电子邮件时的关键假设和问题. 本文档取代 RFC 4952, 并反映了该文档发布后发现的其他问题.

本备忘录的状态​

本文档是一份 Internet 标准跟踪文档.

本文档是 Internet 工程任务组(IETF)的产物. 它代表 IETF 社区的共识, 已经过公开审查, 并由 Internet 工程指导组(IESG)批准发布. 有关 Internet 标准的更多信息, 请参见 RFC 5741 第 2 节.

有关本文档的当前状态, 勘误以及如何提供反馈的信息, 可从 http://www.rfc-editor.org/info/rfc6530 获取.

版权声明​

版权所有 (c) 2012 IETF Trust 及本文档所列作者. 保留所有权利.

本文档受发布之日有效的 BCP 78 以及 IETF Trust 的 IETF 文档法律条款(http://trustee.ietf.org/license-info)约束. 请仔细阅读这些文档, 因为其中说明了您对本文档享有的权利和受到的限制. 从本文档中提取的代码组件必须包含法律条款第 4.e 节所述的简化 BSD 许可证文本, 并按简化 BSD 许可证所述不附带任何保证.

本文档可能包含在 2008 年 11 月 10 日之前发布或公开提供的 IETF 文档或 IETF 贡献中的材料. 对其中部分材料拥有版权控制权的人士可能尚未授予 IETF Trust 在 IETF 标准流程之外允许修改这些材料的权利. 在未从这些材料的版权控制者处取得充分许可的情况下, 不得在 IETF 标准流程之外修改本文档, 也不得基于本文档制作衍生作品, 但为将其作为 RFC 发布而进行格式调整, 或将其翻译为英语以外的语言除外.

目录​

  1. 引言
  2. 本规范的作用
  3. 问题陈述
  4. 术语
    • 4.1 邮件用户代理与邮件传输代理
    • 4.2 地址字符集
    • 4.3 用户类型
    • 4.4 消息
    • 4.5 邮件列表
    • 4.6 传统消息与国际化消息
    • 4.7 无法投递的消息, 通知与投递回执
  5. 方法概述与文档规划
  6. 实验结果回顾
  7. 协议扩展与变更概述
    • 7.1 国际化电子邮件地址的 SMTP 扩展
    • 7.2 以 UTF-8 编码传输电子邮件首部字段
    • 7.3 用于 DSN 的 SMTP 服务扩展
  8. SMTP 事务之前和之后的降级
    • 8.1 消息提交之前或期间的降级
    • 8.2 SMTP 最终投递之后的降级或其他处理
  9. 传输途中的降级
  10. 用户界面与配置问题
    • 10.1 邮箱名称的选择与 Unicode 规范化
  11. 其他问题
    • 11.1 对 URI 和 IRI 的影响
    • 11.2 将电子邮件地址用作标识符
    • 11.3 编码词, 签名消息与降级
    • 11.4 本地部分的其他用途
    • 11.5 非标准封装格式
  12. 相对于实验性协议和框架的关键变更
  13. 安全考虑
  14. 致谢
  15. 参考文献
    • 15.1 规范性参考文献
    • 15.2 资料性参考文献

1. 引言​

要使用国际化电子邮件地址, 必须同时对电子邮件地址的域部分和本地部分进行国际化. 电子邮件地址的域部分已经国际化 [RFC5890], 而本地部分尚未国际化. 如果没有本文档所规定的扩展, 邮箱名称将受限于 7 位 ASCII 的一个子集 [RFC5321]. MIME [RFC2045] 虽然支持传输非 ASCII 数据, 但没有提供国际化电子邮件地址机制. 在 RFC 2047 [RFC2047] 中, MIME 为某些特定的消息首部字段定义了编码机制, 以容纳非 ASCII 数据. 但是, 它不允许使用包含非 ASCII 字符的电子邮件地址. 如果没有本文定义的扩展或功能等价的一组扩展, 要在电子邮件地址的任何部分包含非 ASCII 字符, 唯一方法就是使用 RFC 2047 编码, 将其嵌入 RFC 5322 [RFC5322] 所称的相关首部字段的 "显示名称" 中(在其他地方也称为 "名称短语" 或其他名称). 编码到显示名称中的信息在消息信封中不可见, 而且对于许多用途而言根本不属于地址的一部分.

本文档取代 RFC 4952 [RFC4952], 并反映了该文档发布后发现的其他问题, 共享术语和若干体系结构变更. 本文档废止 RFC 4952. 由于第 12 节所述的变更, 关于传输途中降级的实验性说明 [RFC5504] [RFC5825] 已经失去意义, 不再需要. 现请求 RFC 编辑将这三份文档全部移至历史状态.

本文交替使用代词 "he" 和 "she", 用于指代性别未确定的人.

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" 和 "OPTIONAL" 应按 BCP 14 和 RFC 2119 [RFC2119] 的说明解释.

2. 本规范的作用​

本文档概述并构建电子邮件国际化下一阶段所采用方法的框架. 这一新阶段不仅要求地址和首部字段国际化, 也要求相关的传输和投递模型国际化. 本规范的先前版本 RFC 4952 [RFC4952] 还介绍了一组实验性协议 [RFC5335] [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825]. 本修订版为其中一部分协议的标准跟踪后继规范提供概述和概念性信息. 第 5 节说明各文档的细节及相互关系, 第 6 节讨论从实验性协议及其实现中得到的经验.

这些规范共同提供了实现和支持国际化电子邮件的方法细节. 本文档说明电子邮件国际化的各组成元素如何组合在一起, 以及与消息传输, 首部格式和处理相关的主要规范之间有何关系.

本文档及上述文档集合中的其他文档假定读者对基本 Internet 电子邮件规范和术语 [RFC5321] [RFC5322], 以及 MIME [RFC2045] 和 8BITMIME [RFC6152] 具有适当了解. 实现本规范虽不严格要求, 但也假定读者大致熟悉 IDNA [RFC5890] [RFC5891] [RFC5892] [RFC5893] [RFC5894] 的术语和功能.

3. 问题陈述​

应用程序中的国际化域名(IDNA) [RFC5890] 允许使用国际化域名, 但其部署尚未惠及大多数用户. 原因之一是我们仍然没有完全国际化的命名方案. 域名只是需要国际化的各种名称和标识符之一. 在许多场景中, 只要更多其他标识符尚未国际化, 单独使用国际化域名的价值就很有限.

电子邮件地址是说明仅对域名进行国际化还远远不够的典型例子. 大多数观察者都从经验中了解到, 相比看似毫无意义的字母或数字串, 用户更喜欢与姓名或首字母缩写相似的电子邮件地址. 除非整个电子邮件地址都能使用用户熟悉的字符和格式, 否则用户会认为电子邮件在文化上不够友好. 如果电子邮件地址中的姓名和首字母缩写可以用用户的母语和书写系统表示, Internet 就会显得更加自然, 对母语并非使用罗马字母派生文字子集书写的用户尤其如此.

电子邮件地址国际化并不只是更改 SMTP 信封, 或修改 "From:", "To:" 和 "Cc:" 首部字段, 也不只是允许升级后的邮件用户代理(MUA)解码某种特殊编码并显示本地字符. 为了让用户认为它可用, 地址在所有出现的场景中都必须国际化并得到一致处理. 这一要求影响深远, 零散的补丁和变通办法并不足够. 即使它们勉强够用, 基于变通办法的方法也可能产生采用不同补丁和变通办法组合的各种实现, 导致用户无法判断究竟哪些功能可用, 哪些功能受支持. 因此, 我们需要构建完全国际化的电子邮件环境, 重点支持共享同一种语言和书写系统的人们高效通信. 这又意味着必须更改邮件首部环境, 让适合国际化的首部字段能够使用完整的 Unicode 字符范围; 必须提供 SMTP 扩展, 以允许 UTF-8 [RFC3629] [RFC5198] 邮件寻址并投递这些扩展首部字段; 必须支持投递通知和服务通知的国际化 [RFC3461] [RFC3464]; 最后还必须要求支持 8BITMIME SMTP 扩展 [RFC6152], 从而让所有这些内容都能通过邮件系统传输, 而不必克服首部字段没有内容传输编码这一限制.

4. 术语​

本文档假定读者对 RFC 5321 [RFC5321] 和 RFC 5322 [RFC5322] 所述核心电子邮件标准中的协议和术语具有适当了解.

4.1 邮件用户代理与邮件传输代理​

本文档的大部分说明依赖于 "邮件传输代理"("MTA")和 "邮件用户代理"("MUA")这两个抽象概念. 不过必须理解, 这些术语及其背后的概念出现于 Internet 电子邮件体系结构设计之后, 也晚于 "线上协议" 原则在该体系结构中的应用. 随着电子邮件体系结构的演进, 这一体系结构和 "线上协议" 原则一直使人们无法对 MTA 与 MUA 在某个源主机或目标主机上如何交互(乃至它们是否彼此独立)作出明确且标准化的区分.

不过, 本文档使用的 "最终投递 MTA" 一词, 与 RFC 5321 中的 "投递系统" 或 "最终投递系统" 含义相同. 它是控制地址本地部分格式, 并被允许检查和解释该部分的 SMTP 服务器. 它从网络接收消息, 将其投递到邮箱或执行其他本地处理, 包括会更改信封地址的任何转发或别名处理, 而不是继续中继. 从网络的角度看, 保存到消息存储, 移交给特定消息投递程序或代理, 以及检索消息的机制等一切本地投递安排, 都位于最终投递 MTA "之后", 因而不属于 SMTP 传输或投递过程.

4.2 地址字符集​

在本文档中, 如果地址的每个字符都属于 ASCII 字符表 [ASCII], 则该地址称为 "全 ASCII 地址" 或简称 "ASCII 地址". 如果其中任何字符不属于 ASCII 字符表, 则称为 "非 ASCII 地址" 或 "i18n 地址". 这类地址 MAY 受到其他限制, 但这些限制与本定义无关. 当这种区分很重要时, "全 ASCII" 一词也适用于其他协议元素, 其反义词为 "非 ASCII" 或 "国际化".

用于统称本文档及其配套文档所规定的电子邮件地址国际化技术的术语是 "SMTPUTF8". 例如, 本规范允许的地址称为 "符合 SMTPUTF8 的地址".

请注意, 按照上述定义, 所有 "全 ASCII" 地址组成的集合与所有 "非 ASCII" 地址组成的集合互斥. 使用 SMTPUTF8 时允许的全部地址集合, 是这两个集合的并集.

4.3 用户类型​

"ASCII 用户" 满足以下两项条件: (i) 仅使用只包含 ASCII 字符的电子邮件地址; (ii) 无法生成包含非 ASCII 字符的收件人地址.

"国际化电子邮件用户" 拥有一个或多个非 ASCII 电子邮件地址, 或者能够生成包含非 ASCII 字符的收件人地址. 这类用户也可能拥有 ASCII 地址. 如果用户拥有多个电子邮件账户及其对应地址, 或同一地址拥有多个别名, 则该用户可以通过某种方式选择外发邮件使用的地址. 请注意, 根据本定义, 仅凭一个 ASCII 地址无法判断其所有者是否为国际化电子邮件用户. 非 ASCII 地址则表示发件人相信该地址的所有者是国际化电子邮件用户. 不存在所谓 "国际化电子邮件用户消息", 该术语只适用于用户及其代理和能力. 特别是, 非 ASCII 的消息内容(因而通常也是国际化内容)本来就是 MIME 规范 [RFC2045] 的组成部分, 并不需要这些扩展, 但与这些扩展兼容.

4.4 消息​

"消息" 是由一个用户(发件人)使用某个特定电子邮件地址, 发送给一个或多个其他收件人电子邮件地址的内容. 收件人也常简称为 "用户" 或 "收件用户".

4.5 邮件列表​

"邮件列表" 是一种机制, 通过向一个收件人地址发送消息, 可将该消息分发给多个收件人. 位于这个单一地址的代理(通常不是人)随后促使消息重新分发给目标收件人. 该代理会把重新分发消息的信封返回地址设置为不同于原始单一收件人消息的地址. 使用不同的信封返回地址(反向路径), 可使错误消息以及其他自动生成的消息发往专门的错误处理地址.

针对可能包含非 ASCII 地址的邮件列表, 专门讨论该主题的文档 [RFC5983] 及其预期后继文档 [RFC5983bis-MailingList] 给出了特殊管理规定.

4.6 传统消息与国际化消息​

  • 传统消息不使用本规范集合中的 SMTP 扩展文档 [RFC6531] 或 UTF8header 文档 [RFC6532] 所定义的任何扩展, 并严格符合 RFC 5322 [RFC5322].

  • 国际化消息使用本规范集合定义的一个或多个扩展, 因而不再符合传统的电子邮件消息或其传输规范.

4.7 无法投递的消息, 通知与投递回执​

按照 RFC 5321 的规定, 因某种原因无法投递的消息应当导致向发件人发送通知. 通知可能通过两种方式之一发生. 第一种通常称为 "拒绝", 即 SMTP 服务器返回表示致命错误的回复码("5yz" 代码), 或持续返回临时失败错误("4yz" 代码). 第二种是在 SMTP 处理期间接受消息, 随后向发件人生成一条消息, 通常称为 "未投递通知" 或 "NDN". 当前实践通常倾向于拒绝而不是 NDN, 因为这样可以降低生成 NDN 被用作垃圾邮件手段的可能性. 如果中间 MTA 接受一条消息, 而下一跳服务器随后拒绝该消息, 则后一种 NDN 情形不可避免.

发件人还 MAY 明确请求消息回执 [RFC3461]. 对这些国际化扩展而言, 这会引发与 NDN 相同的问题.

5. 方法概述与文档规划​

本规范集合同时更改 SMTP 和电子邮件消息首部的字符编码, 使非 ASCII 字符能够直接表示. 每个重要组成部分都由一份独立文档说明. 下文将介绍文档集合中的各个成员. 该集合还包含资料性文档, 旨在为相关协议提供实现建议和指导.

除本文档外, 以下文档构成本规范并为其提供建议和背景.

  • SMTP 扩展. SMTP 扩展文档 [RFC6531] 按 RFC 5321 所允许的方式, 为国际化地址规定了一项 SMTP 扩展.

  • UTF-8 电子邮件消息首部. 电子邮件消息首部文档 [RFC6532] 实质上更新了 RFC 5322, 允许在使用上述 SMTP 扩展时, 直接用 UTF-8 编码的 Unicode 字符表示电子邮件消息首部中的某些信息. 该文档以及可能的一份或多份补充文档还需要说明与 MIME 的交互, 包括 SMTPUTF8 与内部 MIME 首部和内容类型之间的关系.

  • 投递状态与通知处理扩展. 相关文档 [RFC6533] 调整投递状态与通知处理, 使其适用于国际化地址.

  • 后续文档. 后续文档将规定 IMAP 协议 [RFC3501] 的扩展, 以支持国际化消息首部 [RFC5738bis-IMAP]; 还将规定对应的 POP 协议扩展 [RFC5721] [RFC5721bis-POP3], 以及两者的一些共同属性 [POPIMAP-downgrade].

6. 实验结果回顾​

本组协议与其先前的实验性协议组 [RFC5335] [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825] 的关键区别是, 早期协议提供消息传输途中降级机制, 详见 RFC 5504. 该机制允许而且实质上要求每个非 ASCII 地址都附带一个等价的全 ASCII 地址. 这又引发了安全问题, 因为两个地址之间的配对关系无法得到认证. 它还构成多年来 Internet 邮件寻址的第一次不兼容变更. 如果新地址形式 "泄漏" 到旧式电子邮件实现中, 就可能造成互操作问题. 在研究这些规范的早期实验性前身所积累的经验后, 制定这些规范的工作组曾认为, 如果传输途中降级在操作上可行, 其优点将足以抵消上述疑虑.

事实证明并非如此, 早期实现之间出现了互操作问题. 在开始制定本组规范之前, 工作组得出结论, 早期模型所组合的各种要求及其长期影响过于复杂, 无法令人满意, 因此后续工作应在不采用该模型的情况下进行.

协议本身的另一项重大变更是, 当消息需要该扩展时, 现在要求 SMTP 客户端使用 SMTPUTF8 关键词进行声明. 在实验版本中, 只需服务器声明允许扩展信封和/或扩展内容.

7. 协议扩展与变更概述​

本节概述实现国际化电子邮件所需的主要协议扩展. 具体语法, 状态转换和错误处理规则由相应的配套规范定义.

7.1 国际化电子邮件地址的 SMTP 扩展​

RFC 6531 [RFC6531] 定义了名为 "SMTPUTF8" 的 SMTP 扩展, 具体如下:

  • 允许电子邮件地址的本地部分和域名使用 UTF-8 字符串.

  • 允许在电子邮件消息首部中有选择地使用 UTF-8 字符串, 见第 7.2 节.

  • 要求服务器通告 8BITMIME 扩展 [RFC6152], 并要求客户端支持 8 位传输, 从而无需特殊的内容传输编码即可传送首部信息.

该扩展遵循以下原则:

  1. 电子邮件地址会进入可能执行字符集转换或其他编码变更的子系统, 例如用户界面. 如果地址的本地部分包含 ASCII 字符表之外的字符, 则不鼓励对域部分使用 ASCII 兼容编码(ACE) [RFC3492] [RFC5890], 以促进整个地址中的字符得到一致处理.

  2. SMTP 中继 MUST 采取以下一种做法:

    • 显式识别该格式, 并通过 ESMTP 选项同意这样做.
    • 拒绝消息, 或在必要时返回未投递通知消息, 让发件人能够另作安排.

  3. 如果由于下一跳系统无法接受该扩展而不能转发消息, 则该消息 MUST 被拒绝, 或者当前系统 MUST 生成并发送未投递消息.

  4. 为了实现互操作, 通过 Internet 传输的邮件地址和消息首部禁止使用 UTF-8 以外的字符集. 如果不引入极大复杂性, 就没有实际可行的方法通过类似扩展正确标识多个字符集.

要符合这里规定的电子邮件传输和投递标准组, 实现必须实现 SMTP 扩展规范和 UTF-8 首部规范. 如果系统实现 IMAP 或 POP, 则分别 MUST 符合国际化 IMAP [RFC5738bis-IMAP] 或 POP [RFC5721bis-POP3] 规范.

7.2 以 UTF-8 编码传输电子邮件首部字段​

在 MUA 或用户所见内容中, 电子邮件地址或域名会出现在许多位置. 例如传统的 "From:", "To:" 和 "Cc:" 首部字段, 通常包含域名的 "Message-ID:" 和 "In-Reply-To:" 首部字段(但它们可能属于特殊情况), 以及消息正文. 必须从国际化角度检查其中每个位置. 用户期望看到以本地字符表示的邮箱名和域名, 而且期望它们始终保持一致. 如果使用协议特定的 ACE 变体等不直观编码, 用户就难免会偶尔看到这些编码而不是 "本族" 字符, 并因此感到不适或惊讶. 同样, 如果邮件传输和消息正文采用不同编码, 根据由来已久的 "事物总会泄漏" 原则, 用户尤其容易遇到意外. 无论从中期还是长期看, 避免这些问题的唯一实际方法, 都是让传输使用的编码尽可能接近消息首部和消息正文使用的编码.

电子邮件本地部分国际化时, SHOULD 同时作出安排, 使消息首部采用完全国际化形式. 这种形式 SHOULD 使用 UTF-8 而不是 ASCII 作为首部字段内容的基础字符集. 首部字段名称本身等协议元素不作变更, 仍完全采用 ASCII. 为了过渡并兼容旧式系统, 可以扩展传统 MIME 的非 ASCII 首部字符编码模型 [RFC2045] [RFC2231], 但即使采用这种方式, 也应尽可能以 UTF-8 而不是其他编码为基础 [RFC6055]. 不过, 目标是 [RFC6532] 所讨论的完全国际化消息首部, 而不是延长并增加痛苦的过渡过程.

7.3 用于 DSN 的 SMTP 服务扩展​

现有 DSN 格式 [RFC3461] [RFC3464] 的机器可读部分以 ASCII 为基础. RFC 6533 [RFC6533] 为国际化地址增加新的地址类型, 并规定国际化投递状态和处置通知的格式.

如果 SMTP 服务器同时通告 SMTPUTF8 和 DSN 扩展, 它 MUST 完整实现国际化 DSN, 包括正确处理 ORCPT 参数中的国际化地址. 实现不能一方面声明支持这些扩展, 另一方面仍假定所有通知地址都只包含 ASCII.

8. SMTP 事务之前和之后的降级​

这些扩展面临的一个重要问题是, 如何处理支持非 ASCII 地址的系统与期望 ASCII 的旧式系统之间的交互. 只支持 ASCII 的系统向能够处理国际化形式的系统发送邮件当然没有问题, 因为 ASCII 形式只是国际化形式的真子集. 但是, 支持这些扩展的系统发送邮件时, MAY 为发件人, 收件人或两者包含非 ASCII 地址, 还可能提供地址之外的非 ASCII 首部信息. 如果第一跳系统不支持该扩展, 即提交服务器作为 SMTP 客户端所访问的 SMTP 服务器不支持该扩展, 则消息发起系统 SHOULD 准备好发送传统信封和消息首部, 或把消息退回给发起用户, 由用户手工将消息降级为传统形式, 也可能在消息首部中使用编码词 [RFC2047]. 这类转换显然意味着, 发起用户或系统必须掌握所有发件人和收件人的纯 ASCII 地址. 如何查找或识别这些地址超出本规范范围. 发起系统的设计决策也超出本规范范围, 例如必要转换应由用户, 发起 MUA 还是提交服务器完成.

如果第一跳系统支持这些扩展, 但 SMTP 传输链中的某个后续服务器不支持, 情况会稍微复杂一些. 必须注意, 对于指向前方的地址, 这种情况大多源于配置错误. 接受这些扩展的最终投递 MTA, 特别是在它托管非 ASCII 地址时, SHOULD NOT 配置不支持这些扩展的较低优先级 MX 主机. 如果正在传输的唯一非 ASCII 地址指向后方, 例如位于 SMTP MAIL 命令中, 收件人配置通常无法提供帮助. 另一方面, 发件人的备用全 ASCII 地址最有可能由提交环境或发件人本人权威掌握. 因此, 如果需要这些扩展的中间 SMTP 中继发现传输链中的下一个系统不支持它们, 除了拒绝或退回消息之外几乎没有其他选择.

如上所述, 降级为纯 ASCII 形式可以发生在初始消息提交之前或期间. 为适应能力不同于投递 MTA 的消息存储, IMAP 或 POP 服务器或客户端, 降级也可以发生在消息到达最终投递 MTA 之后. 以下两个小节讨论这些情形.

8.1 消息提交之前或期间的降级​

IETF 一贯避免规定 MUA 的精确行为, 从而为相关用户界面提供最大灵活性. SMTP 标准 [RFC5321] 第 6.4 节给予 MUA 和提交服务器很大自由, 用户可以提供各种内容, 只要结果注入公共 Internet 时符合 "线上" 标准即可. 按照这一传统, 第 8 节余下内容是一般指导, 而不是规范性要求.

需要这些扩展的消息有时会被传送到不支持这些扩展的系统. 最常见的情况可能是, 指向前方的地址只包含 ASCII, 而指向后方的地址包含非 ASCII. 在这里所述扩展尚未在 Internet 电子邮件环境中普遍实现之前, 即使预期收件人只使用并期望全 ASCII 地址, 偏好使用非 ASCII 地址或在首部字段中使用原始 UTF-8 字符的发件人, 也需要特别留意可能出现的错误情形. 在未投递消息或提交服务器给出的其他指示经常被丢弃或忽略的环境中, 风险尤其高.

与国际化地址对应的 ASCII 地址, 最方便的查找时机显然是在发起 MUA 或与之密切相关的系统中. 查找既可以发生在消息发送之前, 也可以发生在国际化形式的消息被拒绝之后. 如果需要把消息从国际化形式转换为传统 ASCII 形式, 或向发件人生成未投递消息, 此时也是最方便的时机. 在这一阶段, 用户拥有完整的选择范围, 包括更改指向后方的地址, 通过带外方式联系预期收件人以取得备用地址, 查询适当的目录, 安排把地址和消息内容都翻译为另一种语言等. 人们很自然地把消息降级设想成完全自动化的最佳流程, 但不应低估一个至少具备中等理解能力并希望与另一个此类用户通信的用户所具有的处理能力.

在这种情况下, 很容易设想对 RFC 6409 [RFC6409] 所述消息提交服务器进行修改, 使其能够执行降级操作, 甚至执行升级操作. 这类操作允许服务器接收使用本文所述一个或多个国际化扩展的消息, 并根据其遇到的投递环境或下一跳环境, 按需调整外发消息.

8.2 SMTP 最终投递之后的降级或其他处理​

电子邮件消息由最终投递 MTA 接收后, 通常会以某种形式存储. 随后, 软件可以直接读取存储形式, 也可以由客户端软件通过 POP 或 IMAP 等电子邮件检索机制取回消息.

第 7.1 节所述 SMTP 扩展只在传输中提供保护. 它无法阻止尚未升级, 因而不能理解国际化地址和 UTF-8 消息首部的 MUA 和电子邮件检索机制访问已存储的国际化电子邮件.

由于最终投递 MTA, 更确切地说是对应的邮件存储代理, 无法安全地假设访问电子邮件存储的代理始终能够处理本文提出的扩展, 因而它 MAY 降级国际化电子邮件, 对使用这些扩展的消息作特殊标识, 或同时采取这两种做法. 如果采取其中一种或两种做法, 最终投递 MTA SHOULD 提供一种机制, 在不丢失信息的情况下保留或恢复原始国际化形式. 为支持了解 SMTPUTF8 的代理访问, 必须保留这些信息.

9. 传输途中的降级​

RFC 5321 规定, 地址本地部分 MUST 只由该地址域所指定的主机解释. 中间中继既不知道本地部分的语义, 也没有权限对其进行可靠转换. 因此, 本规范不允许在传输途中转换或降级本地部分.

遵守这一规则意味着, 转换电子邮件地址本地部分的降级机制不能用于传输途中. 它只能应用于端点, 具体来说只能由 MUA 或提交服务器, 或由最终投递 MTA 应用.

这一规则的原因之一与旧式电子邮件系统有关, 这些系统会把邮件路由信息嵌入地址字段的本地部分. 转换电子邮件地址会破坏这类路由信息. 例如, 最终投递服务器之外的任何服务器都无法知道 user%[email protected] 的本地部分究竟表示一条路由, 即通过 foo 到达 user, 还是仅仅表示一个本地地址.

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 接收端代码必须能够处理它们而不发生严重错误, 即使服务器不接受包含这些字符串的投递地址. 但在选定邮箱名称时依赖这些字符通常是不良做法, 可能导致互操作问题.

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 格式, 那么它们尚未准备好支持本系列文档规定的扩展, 可能需要采取特殊措施才能正确检测和处理这些消息.

12. 相对于实验性协议和框架的关键变更​

国际化电子邮件地址和首部的原始框架由 RFC 4952 及后续一组实验性协议文档描述. 这些关系在第 3 节中说明. 实验性规范与本组新规范之间最关键的体系结构差异是, 早期规范支持传输途中降级. 相关机制定义了语法和功能, 以便在传送非 ASCII 地址的同时传送备用全 ASCII 地址, 并使用特殊首部指明消息的降级状态. 实验表明这些功能比早先设想的更复杂, 必要性也更低, 因而已被删除. 第 6 节和第 9 节更详细地讨论了这些问题.

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] 中, 处理这些证书的标准就需要升级以支持国际化地址. 这些升级还必须处理地址自身因相似字符而被冒充的问题.

14. 致谢​

本文档是 RFC 4952 的更新, 也衍生自该文档. 没有 RFC 4952 所致谢的工作和贡献, 本文档就不可能完成. RFC 4952 发布后, IETF EAI 工作组及其他场合的讨论使本文档获益良多, 尤其是围绕国际化电子邮件文档集合中其他文档实验版本的讨论, 以及针对 RFC 4952 本身的勘误.

特别感谢 Ernie Dainow 对本版本进行细致审查并建议文本, 也感谢多位 IESG 成员的认真审查和具体建议.

15. 参考文献​

15.1 规范性参考文献​

  • [ASCII] American National Standards Institute, "USA Code for Information Interchange", ANSI X3.4-1968, 1968.

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

  • [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.

  • [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.

  • [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.

  • [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.

  • [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, March 2011.

  • [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Address", RFC 6531, February 2012.

  • [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012.

  • [RFC6533] Hansen, T., Newman, C., and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 6533, February 2012.

15.2 资料性参考文献​

  • [POPIMAP-downgrade] Fujiwara, K., "Post-delivery Message Downgrading for Internationalized Email Messages", Work in Progress, October 2011.

  • [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.

  • [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.

  • [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.

  • [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

  • [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

  • [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.

  • [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.

  • [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.

  • [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.

  • [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.

  • [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.

  • [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.

  • [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.

  • [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.

  • [RFC4155] Hall, E., "The application/mbox Media Type", RFC 4155, September 2005.

  • [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006.

  • [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.

  • [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.

  • [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.

  • [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.

  • [RFC5335] Yang, A., "Internationalized Email Headers", RFC 5335, September 2008.

  • [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.

  • [RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 5337, September 2008.

  • [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for Email Address Internationalization", RFC 5504, March 2009.

  • [RFC5721] Gellens, R. and C. Newman, "POP3 Support for UTF-8", RFC 5721, February 2010.

  • [RFC5721bis-POP3] Gellens, R., Newman, C., Yao, J., and K. Fujiwara, "POP3 Support for UTF-8", Work in Progress, November 2011.

  • [RFC5738] Resnick, P. and C. Newman, "IMAP Support for UTF-8", RFC 5738, March 2010.

  • [RFC5738bis-IMAP] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP Support for UTF-8", Work in Progress, December 2011.

  • [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.

  • [RFC5825] Fujiwara, K. and B. Leiba, "Displaying Downgraded Messages for Email Address Internationalization", RFC 5825, April 2010.

  • [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations", RFC 5863, May 2010.

  • [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.

  • [RFC5892] Faltstrom, P., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010.

  • [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, August 2010.

  • [RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, August 2010.

  • [RFC5983] Gellens, R., "Mailing Lists and Internationalized Email Addresses", RFC 5983, October 2010.

  • [RFC5983bis-MailingList] Levine, J. and R. Gellens, "Mailing Lists and UTF-8 Addresses", Work in Progress, December 2011.

  • [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011.

  • [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, October 2010.

  • [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.

  • [Unicode] The Unicode Consortium, "The Unicode Standard, Version 6.0.0", Mountain View, CA: The Unicode Consortium, 2011, ISBN 978-1-936213-01-6, http://www.unicode.org/versions/Unicode6.0.0/.

  • [Unicode-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", September 2010, http://www.unicode.org/reports/tr15/.

最后于 更新