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 的代理访问, 必须保留这些信息.