跳到主要内容

1. 引言

在三十五年的历史中, Internet Mail 的规模和复杂度已经发生显著变化, 并逐步成为全球性基础设施服务. 这些变化是演进式而非革命式的, 反映出人们强烈希望保留既有部署基础和服务实用性. 今天的 Internet Mail 由许多独立运营者,许多向用户提供服务的组件, 以及许多传输消息的组件共同构成.

Internet Mail 的底层技术标准包含一组丰富的功能能力. 核心规范包括:

  • Simple Mail Transfer Protocol (SMTP) ([RFC0821], [RFC2821], [RFC5321]) 负责在 Internet 中移动消息.

  • Internet Mail Format (IMF) ([RFC0733], [RFC0822], [RFC2822], [RFC5322]) 定义消息对象.

  • Multipurpose Internet Mail Extensions (MIME) [RFC2045] 定义对消息对象的增强, 允许使用多媒体附件.

围绕电子邮件的技术,运营和策略活动开展的公开协作, 包括应对电子邮件滥用挑战的工作, 已经把更广泛的参与者带入技术社区. 要在这个庞大而复杂的系统上高效协作, 所有参与者都需要基于共同视图工作, 并使用共同语言描述其组件以及组件之间的交互. 但当前视角差异很多, 使人们很难准确判断其他参与者所指的含义.

本文档正是为了解决这些差异而编写, 用于描述当前系统的实际状况. Internet Mail 仍处在持续的技术,运营和策略工作之中, 相关讨论经常受阻于不同的电子邮件服务设计模型, 以及同一术语的不同含义.

为提供必要的共同参照框架, 本文档描述增强后的 Internet Mail 架构, 反映当前服务. 文档重点包括:

  • 捕捉电子邮件模型的细化内容.

  • 澄清架构组件的功能角色.

  • 澄清整个电子邮件服务中的身份相关问题.

  • 定义架构组件及其交互的术语.

1.1. 历史​

第一个标准化的网络电子邮件架构规定了用户世界和传输世界之间的简单划分: 用户世界以 Message User Agent (MUA, 消息用户代理) 的形式存在, 传输世界以 Message Handling Service (MHS, 消息处理服务) 的形式存在, 而 MHS 由 Message Transfer Agent (MTA, 消息传输代理) 组成 [RFC1506]. MHS 从一个 User 接收消息并将其交付给一个或多个其他 User, 从而创建虚拟的 MUA 到 MUA 交换环境.

如图 1 所示, 该架构定义了两个逻辑互操作层. 一个层面直接存在于 User 之间. 另一个层面存在于传输路径上的组件之间. 此外, 两层之间也存在互操作: 首先是消息从 User 投递到 MHS, 随后是消息从 MHS 交付给 User.

运营服务已经演进, 但服务的核心方面, 例如邮箱寻址和消息格式风格, 仍保持高度稳定. 原先用户层和传输层之间的区别仍然存在, 但每一层都有了进一步展开. 本文使用 "Internet Mail" 指代用户组件,传输组件及其服务的完整集合.

对于 Internet Mail, "end-to-end" 通常指一次投递以及 MHS 的一次传输所产生的一组交付. 一个常见例外是通过 Mailing List (邮件列表) 中介的群组对话; 在这种情况下, 预期 Recipient 收到 Author 的消息前会发生两次投递, 如第 2.1.4 节所述. 实际上, 某些电子邮件用途会把整个电子邮件服务, 包括 Author 和 Recipient, 都视为从属组件. 对这些服务而言, "end-to-end" 指电子邮件服务之外的端点. 示例包括基于电子邮件的语音邮件 [RFC3801],基于电子邮件的 EDI (Electronic Data Interchange, 电子数据交换) [RFC1767], 以及基于电子邮件的传真 [RFC4142].

                                     +--------+
                  ++================>|  User  |
                  ||                 +--------+
                  ||                      ^
      +--------+  ||          +--------+  .
      |  User  +==++=========>|  User  |  .
      +---+----+  ||          +--------+  .
          .       ||               ^      .
          .       ||   +--------+  .      .
          .       ++==>|  User  |  .      .
          .            +--------+  .      .
          .                 ^      .      .
          .                 .      .      .
          V                 .      .      .
      +---+-----------------+------+------+---+
      |   .                 .      .      .   |
      |   .................>.      .      .   |
      |   .                        .      .   |
      |   ........................>.      .   |
      |   .                               .   |
      |   ...............................>.   |
      |                                       |
      |     Message Handling Service (MHS)    |
      +---------------------------------------+

      Legend: === lines indicate primary (possibly indirect)
                  transfers or roles
              ... lines indicate supporting transfers or roles

            Figure 1: Basic Internet Mail Service Model

端到端 Internet Mail 交换通过标准化基础设施完成, 该基础设施具有以下组件和特征:

  • 一个电子邮件对象.

  • 全局寻址.

  • 一组异步的点到点传输机制.

  • 不要求 MTA 之间或 Author 与 Recipient 之间预先安排.

  • 不要求开放 Internet 上的点到点传输服务之间预先安排.

  • 不要求 Author,Originator 或 Recipient 同时在线.

服务的端到端部分是电子邮件对象, 称为 "message" (消息). 广义上, 消息本身区分用于处理的控制信息和 Author 的内容.

开放 Internet 上邮件设计的一条准则是: 允许 User 到 User 和 MTA 到 MTA 互操作, 而无需负责处理消息的各独立管理机构之间预先直接安排. 所有参与者都依赖核心服务被普遍支持并可访问, 访问方式可以是直接访问, 也可以是通过 Gateway (网关) 在 Internet Mail 与符合其他标准的电子邮件环境之间进行转换. 鉴于人际通信中自发性和偶然发现的重要性, 不要求参与者之间预先安排是 Internet Mail 的核心收益, 并且仍然是其核心要求.

在公共 Internet 边缘的本地化网络中, 通常需要预先的管理安排, 其中可以包括访问控制,路由约束和信息查询服务的配置. 自 Internet Mail 早期以来, 消息访问通常要求 Recipient 认证; 近年来, 消息提交也通常要求认证. 在这些情况下, 服务器会验证客户端身份, 方式可以是显式安全协议, 也可以是通过隐式基础设施查询来识别 "local" 参与者.

1.2. 此架构的角色​

Internet 服务是在两个或更多参与节点之间集成相关能力. 这些能力通过一个或多个协议跨 Internet 实现. 将协议连接到服务的是架构. 架构通过定义服务的逻辑组件及其关系, 规定协议如何实现服务. 从逻辑视角看, 服务定义正在做什么, 架构定义各部分位于何处以及相互关系, 协议定义具体能力如何执行.

因此, 架构会以相对较高层次更正式地描述服务. 实现某部分服务的协议会在不同程度上符合架构, 这取决于实现者在现实约束下实现架构时所做的实际权衡. 未精确遵循架构并不表示协议失败, 未精确塑造协议也不表示架构失败. 当协议偏离架构时, 它当然应当说明偏离原因. 但这种偏离本身不是协议的缺点: IETF 更看重可运行代码而非架构纯粹性.

在本文档的特定场景中, 此架构试图事后定义 Internet email 的逻辑组件, 捕捉当前电子邮件协议所体现的架构原则. 不同电子邮件协议对该架构的符合程度会有所不同. 只要此架构与这些协议存在差异, 其原因通常是明确的, 并且是互操作所必需的. 这些差异并不表示协议需要修复. 然而, 此架构是对 Internet email 逻辑模型的尽力描述; 如果新的协议开发偏离此架构, 设计者需要理解这些差异并仔细解释.

1.3. 文档约定​

对消息结构化字段的引用使用两部分点号记法. 第一部分引用包含该字段规范的文档, 第二部分是字段名称. 因此, <RFC5322.From> 是电子邮件内容头部中的 IMF From: 头字段, <RFC5321.MailFrom> 是 SMTP "Mail From" 命令中的地址.

当未带 IMF (RFC 5322) 限定符出现时, 头字段名称带冒号后缀显示. 例如, From:.

对参与者,功能或组件标签的引用采用首字母大写形式.

最后于 更新