4. 服务和标准

Internet Mail 架构包含六种基本功能类型, 它们被安排为支持存储转发服务. 如图 5 所示, 每种类型都可以有多个实例, 其中一些表示专门角色. 本节讨论这些组件之间的活动和关系, 以及适用于它们的 Internet Mail 标准.

• Message (消息)

• Message User Agent (MUA, 消息用户代理)

  • Author MUA (aMUA)

  • Recipient MUA (rMUA)

• Message Submission Agent (MSA, 邮件提交代理)

  • 面向 Author 的 MSA 功能 (aMSA)

  • 面向 MHS 的 MSA 功能 (hMSA)

• Message Transfer Agent (MTA, 消息传输代理)

• Message Delivery Agent (MDA, 邮件交付代理)

  • 面向 Recipient 的 MDA 功能 (rMDA)

  • 面向 MHS 的 MDA 功能 (hMDA)

• Message Store (MS, 消息存储)

  • Author MS (aMS)

  • Recipient MS (rMS)

下图展示功能模块以及它们之间使用的标准化协议.

                     ++========++
                     ||        ||                             +-------+
          ...........++  aMUA  ||<............................+ Disp  |
          .          ||        ||                             +-------+
          .          ++=+==+===++                                 ^
          .  local,imap}|  |{smtp,submission                      .
          .  +-----+    |  |                          +--------+  .
          .  | aMS |<---+  | ........................>| Return |  .
          .  +-----+       | .                        +--------+  .
          .                | .    *****************       ^       .
          .          +-----V-.----*------------+  *       .       .
          .      MSA | +-------+  *   +------+ |  *       .       .
          .          | | aMSA  +-(S)->| hMSA | |  *       .       .
          .          | +-------+  *   +--+---+ |  *       .       .
          V          +------------*------+-----+  *       .       .
    //==========\\                *      V {smtp  *       .       .
    || MESSAGE  ||                *   +------+    *  //===+===\\  .
    ||----------||            MHS *   | MTA  |    *  ||  dsn  ||  .
    || ENVELOPE ||                *   +--+---+    *  \\=======//  .
    ||  smtp    ||                *      V {smtp  *     ^   ^     .
    || CONTENT  ||                *   +------+    *     .   . //==+==\\
    ||  imf     ||                *   | MTA  +....*......   . || mdn ||
    ||  mime    ||                *   +--+---+    *         . \\=====//
    \\==========//                * smtp}| {local *         .     ^
          .           MDA         *      | {lmtp  *         .     .
          .      +----------------+------V-----+  *         .     .
          .      | +----------+   *   +------+ |  *         .     .
          .      | |          |   *   |      | +..*..........     .
          .      | |   rMDA   |<-(D)--+ hMDA | |  *               .
          .      | |          |   *   |      | |<.*........       .
          .      | +-+------+-+   *   +------+ |  *       .       .
          .      +------+---------*------------+  *       .       .
          .  smtp,local}|         *****************       .       .
          .             V                                 .       .
          .          +-----+                         //===+===\\  .
          .          | rMS |                         || sieve ||  .
          .          +--+--+                         \\=======//  .
          .             |{imap,pop,local                  ^       .
          .             V                                 .       .
          .       ++==========++                          .       .
          .       ||          ||                          .       .
          .......>||   rMUA   ++...........................       .
                  ||          ++...................................
                  ++==========++

    Legend: --- lines indicate primary (possibly indirect)
                transfers or roles
            === boxes indicate data objects
            ... lines indicate supporting transfers or roles
            *** lines indicate aggregated service

                     Figure 5: Protocols and Services

4.1. 消息数据 (Message Data)

Message Handling System (MHS) 的目的是在参与者之间交换 IMF 消息对象 [RFC5322]. 它的所有底层机制都服务于将该消息从 Author 交付给 Recipient. 消息可以被显式标记其性质 [RFC3458].

一条消息由传输处理信封和消息内容组成. 信封包含 MHS 使用的信息. 内容分为结构化头部和正文. 头部包含传输处理跟踪信息, 以及属于 Author 消息内容的结构化字段. 正文可以是非结构化文本行, 也可以是多媒体从属对象树, 这些对象称为 "body-parts", 通俗称为 "attachments" [RFC2045], [RFC2046], [RFC2047], [RFC4288], [RFC4289], [RFC2049].

此外, Internet Mail 对特殊控制数据有若干约定, 主要包括:

Delivery Status Notification (DSN):

Delivery Status Notification (DSN, 交付状态通知) 是可由 MHS (MSA,MTA 或 MDA) 生成并发送到 RFC5321.MailFrom 地址的消息. 图 5 中 MDA 和 MTA 显示为 DSN 来源, 目的地显示为 Returns. DSN 提供关于消息传输的信息, 例如传输错误或成功交付 [RFC3461].

Message Disposition Notification (MDN):

Message Disposition Notification (MDN, 消息处置通知) 提供关于交付后处理的信息, 例如指示消息已显示 [RFC3798], 或指示可支持的内容形式 [RFC3297]. 它可由 rMUA 生成, 并发送到 Disposition-Notification-To 地址. 图 5 中该邮箱显示为 Disp.

Message Filtering (SIEVE):

Sieve 是一种脚本语言, 用于指定邮件差异化处理条件, 通常在交付时使用 [RFC5228]. 脚本可以通过多种方式传递, 例如作为消息中的 MIME 部分. 图 5 展示 Sieve 脚本从 rMUA 发送到 MDA. 但是过滤可以在传输路径的多个点执行, 其中任意一个或多个点都可能受 Sieve 指令约束, 尤其是在单个 ADMD 内. 为了相对简洁, 图 5 只展示一种关系.

4.1.1. 信封 (Envelope)

Internet Mail 对传输相关处理信息采用分散框架. MHS 直接使用的信息称为 "envelope" (信封). 它通过传输服务命令携带, 指示传输服务的处理活动. 也就是说, 信封存在于传输协议 SMTP 中 [RFC5321].

跟踪信息, 例如 RFC5322.Received, 记录在消息头部中, 后续不会被更改 [RFC5322].

4.1.2. 头字段 (Header Fields)

Header field (头字段) 是属性名称/值对, 覆盖可扩展的电子邮件服务参数,结构化用户内容和用户事务元信息. 核心头字段集合定义于 [RFC5322]. 针对不同应用扩展该集合是常见做法. 头字段注册过程定义于 [RFC3864]. [RFC4021] 提供了大量既有头字段注册项.

把附加信息放入头字段的一个风险是 Gateway 经常会修改或删除这些字段.

4.1.3. 正文 (Body)

消息正文可以是 ASCII 文本行, 也可以是使用 MIME 的多媒体正文部分附件层次结构 ([RFC2045], [RFC2046], [RFC2047], [RFC4288], [RFC2049]).

4.1.4. 消息中的身份引用

表 1 列出了消息传输过程中存在的核心标识符.

Layer	Field	Set By
Message Body	MIME Header	Author
Message header fields	From:	Author
	Sender:	Originator
	Reply-To:	Author
	To:, CC:, BCC:	Author
	Message-ID:	Originator
	Received:	Originator, Relay, Receiver
	Return-Path:	MDA, from MailFrom
	Resent-*:	Mediator
	List-Id:	Mediator
	List-*:	Mediator
SMTP	HELO/EHLO	Latest Relay Client
	ENVID	Originator
	MailFrom	Originator
	RcptTo	Author
	ORCPT	Originator
IP	Source Address	Latest Relay Client

图例:

• Layer - 使用该标识符的电子邮件架构部分.

• Field - 包含该标识符的协议构造.

• Set By - 负责指定该标识符值的 Actor 角色, 该角色可以不同于为协议构造执行填充功能的 Actor.

Table 1: Layered Identities

以下是最常见的地址相关字段:

RFC5322.From: 设置者 - Author

From: 字段列出消息内容 Author 的名称和地址.

RFC5322.Reply-To: 设置者 - Author

如果 Recipient 发送回复消息时原本会使用原消息中的 RFC5322.From 字段地址, 则改用 RFC5322.Reply-To 字段中的地址. 换言之, 对 Recipient 的响应而言, 该字段会覆盖 From: 字段.

RFC5322.Sender: 设置者 - Originator

此字段指定负责把消息提交给传输服务的地址. 如果它包含与 RFC5322.From 相同的地址, 可以省略此字段. 但是省略此字段并不表示没有指定 Sender; 它表示该头字段是虚拟的, 应使用 From: 字段中的地址.

通知 Return Address 的指定由 RFC5322.Sender 完成, 这些地址包含在 RFC5321.MailFrom 中. 通常 Return Address 与 Sender 地址相同. 但某些使用场景要求二者不同.

RFC5322.To/.CC: 设置者 - Author

这些字段指定 MUA Recipient 地址. 但是这些字段中的部分或全部地址可能不会出现在 RFC5321.RcptTo 命令中.

To 与 CC 之间的区别是主观的. 通常 To 收件人被视为主要收件人, 预期对消息采取行动. CC 收件人通常作为礼貌性副本接收消息.

RFC5322.BCC: 设置者 - Author

消息副本可以发送给不应向 RFC5322.To 或 RFC5322.CC Recipient 披露其参与情况的收件人, 通常也不向其他 BCC Recipient 披露. BCC: 头字段表示发送给此类 Recipient 的消息副本. 该字段用法见 [RFC5322].

RFC5321.HELO/.EHLO: 设置者 - Originator,MSA,MTA

任何 SMTP 客户端, 包括 Originator,MSA 或 MTA, 都可以为 SMTP HELO 或 EHLO 命令操作指定其托管域身份.

RFC3461.ENVID: 设置者 - Originator

MSA 可以指定一个不透明字符串, 该字符串会包含在 DSN 中, 用于帮助 Return Address Recipient 识别产生 DSN 或消息跟踪的消息.

RFC5321.MailFrom: 设置者 - Originator

此字段是端到端字符串, 指定用于接收退回控制信息的电子邮件地址, 例如退回消息. 该字段名称具有误导性, 因为它既不要求指定 Author, 也不要求指定负责提交消息的 Actor. 实际上, 负责提交的 Actor 指定 RFC5321.MailFrom 地址. 判断 RFC5321.MailFrom 字段应包含哪个地址的简单依据是: 哪个地址应被告知传输层问题, 也可能包括成功信息.

RFC5321.RcptTo: 设置者 - Author,Final MTA,MDA

此字段指定 Recipient 的 MUA 邮箱地址. 该字符串可能不会在消息内容头部中可见. 例如, RFC5322.To 等 IMF 目标地址头字段可能指定 Mailing List 邮箱, 而 RFC5321.RcptTo 地址指定该列表的某个成员.

RFC5321.ORCPT: 设置者 - Originator

这是 RCPT 命令的可选参数, 指示当前 RCPT TO 地址在传输过程中经过映射后所对应的原地址. ORCPT 是将多 Recipient 消息传输中的 DSN 与预期 Recipient 关联起来的唯一可靠方式.

RFC5321.Received: 设置者 - Originator,Relay,Mediator,Dest

此字段包含跟踪信息, 包括发起主机,Relay,Mediator,MSA 主机域名和/或 IP 地址.

RFC5321.Return-Path: 设置者 - Originator

MDA 将 RFC5321.MailFrom 地址记录到 RFC5321.Return-Path 字段中.

RFC2919.List-Id: 设置者 - Mediator,Author

此字段提供独立于特定主机的全局唯一 Mailing List 命名框架 [RFC2919].

该标识符采用域名形式; 但该字符串通常通过组合电子邮件地址的两个部分构造而成. 结果很少是列在域名服务中的真实域名, 尽管它可以是.

RFC2369.List-*: 设置者 - Mediator,Author

[RFC2369] 定义了一组供 Mailing List 使用的消息头字段. 实际上, 它们为常见 Mailing-List 用户操作提供列表专用参数. 这些操作的标识符面向列表本身以及作为订阅者的用户 [RFC2369].

RFC0791.SourceAddr: 设置者 - 当前接收 SMTP 服务器前一跳的客户端 SMTP 发送主机

[RFC0791] 定义 Internet 的基本数据传输单元: IP 数据报. 它包含 Source Address 字段, 指定发送该数据报的主机或接口的 IP 地址. 此信息由 IP 层设置和提供, 因而独立于邮件层机制. 因此, 它常被认为具有权威性, 尽管仍可能提供伪造地址.

4.2. 用户层服务 (User-Level Services)

用户层交互涉及协议交换, 不同于 Internet Mail MHS 架构较低层发生的交换, 而 MHS 架构又位于 Internet Transport 层之上. 由于电子邮件的动机及其大量用途是人际交互, 这些协议交换的性质和细节经常由人际和群组通信需要决定. 为适应此类通信固有的特殊行为, 对系统行为的某些方面只能提供主观指南而不是严格规则. Mailing List 就是特别突出的示例.

4.2.1. 消息用户代理 (Message User Agent, MUA)

Message User Agent (MUA) 代表 User Actor 和 User 应用程序工作. 它是它们在电子邮件服务中的代表.

Author MUA (aMUA) 创建消息, 并通过 Mail Submission Agent (MSA) 将其初始提交到传输基础设施. 它也可以在自己的 Message Store (aMS) 中执行创建和投递时归档. MUA aMS 可以用许多不同方式组织消息. 常见模型使用称为 "folders" 的聚合; 在 IMAP 中它们称为 "mailboxes". 该模型允许为开发中的消息 (Drafts),等待发送的消息 (Queued 或 Unsent), 以及已成功投递以供传输的消息 (Sent) 设置文件夹. 但这些文件夹都不是必需的. 例如, IMAP 允许草稿存储在任意文件夹中, 因此不需要存在 Drafts 文件夹.

Recipient MUA (rMUA) 代表 Recipient 处理已接收邮件. 该处理包括生成用户层处置控制消息,显示和处置已接收消息, 以及通过发起回复和转发新消息来闭合或扩展用户通信循环.

注意: 虽然图 5 未展示, MUA 本身可以采用分布式实现, 例如在智能手机等受限设备上运行 "thin" 用户界面模块, 而大部分 MUA 功能在能力更强的远程服务器上运行. 此类架构示例可能使用 IMAP [RFC3501] 处理 MUA 客户端与 MUA 服务器之间的大多数交互. [RFC4550] 定义了此类场景的一种方法.

Mediator 是特殊类别的 MUA. 它执行消息重新投递, 如第 2.1 节所述.

MUA 可以代表当时不在场的 User 自动运行. 一个示例是具有定时启动功能的批量发送服务. 这些服务不应与 Mailing List Mediator 混淆, 因为没有触发该自动化服务活动的传入消息.

一种常见且有问题的 MUA 是自动响应器, 例如发送外出通知的程序. 这种行为可能与 Mediator 行为混淆, 但该 MUA 正在生成新消息. 自动响应器可能打扰 Mailing List 用户, 除非它们遵循 [RFC3834].

以下身份字段与典型 MUA 相关:

• RFC5322.From
• RFC5322.Reply-To
• RFC5322.Sender
• RFC5322.To, RFC5322.CC
• RFC5322.BCC

4.2.2. 消息存储 (Message Store, MS)

MUA 可以使用长期 Message Store (MS). 图 5 描绘了 Author 的 MS (aMS) 和 Recipient 的 MS (rMS). MS 可以位于远程服务器上, 也可以与 MUA 位于同一机器上.

MS 可以通过本地机制主动从 MDA 获取消息, 甚至可以通过 SMTP 等标准化机制获取, 也可以使用 POP 或 IMAP 被动获取. MUA 通过本地机制或使用 POP/IMAP 访问 MS. 使用 POP 进行单条消息访问而非批量传输相对少见且低效.

4.3. MHS 层服务 (MHS-Level Services)

4.3.1. 邮件提交代理 (Mail Submission Agent, MSA)

Mail Submission Agent (MSA) 接收 aMUA 提交的消息, 并执行托管 ADMD 的策略和 Internet 标准要求. MSA 表示一种不寻常的功能二分. 它在消息投递期间代表 Author (aMUA) 的利益, 以促进投递成功; 它也代表 MHS 的利益. 在架构中, 如图 5 所示, 这些责任通过把 MSA 划分为 aMSA 和 hMSA 两个子组件来建模. 单条消息从 Author 环境到 MHS 的责任转移称为 "posting" (投递). 在图 5 中, 它标为 MSA 内部的 (S) 转换.

hMSA 对符合相关 Internet 标准和本地站点策略的消息承担传输责任. 它拒绝不合规消息. MSA 为提交执行最终消息准备, 并通过 hMSA 将责任转移给 MHS. 准备量取决于本地实现. aMSA 任务示例包括添加 Date: 和 Message-ID: 等头字段, 以及把消息部分内容从本地表示法转换为 Internet 标准, 例如把地址扩展为正式 IMF 表示.

历史上, 基于标准的 MUA/MSA 消息投递使用 SMTP [RFC5321]. 当前首选标准是 SUBMISSION [RFC4409]. 虽然 SUBMISSION 派生自 SMTP, 但它使用独立 TCP 端口并施加不同要求, 例如访问授权.

以下身份与 MSA 相关:

• RFC5321.HELO/.EHLO
• RFC3461.ENVID
• RFC5321.MailFrom
• RFC5321.RcptTo
• RFC5321.Received
• RFC0791.SourceAddr

4.3.2. 消息传输代理 (Message Transfer Agent, MTA)

Message Transfer Agent (MTA) 为一个应用层 "hop" 中继邮件. 它类似分组交换机或 IP 路由器, 任务是进行路由评估并把消息移近 Recipient. 当然, 电子邮件对象通常远大于分组或数据报负载, 端到端延迟也通常高得多. 中继由一系列 MTA 执行, 直到消息到达目标 MDA. 因此, MTA 同时实现客户端和服务器 MTA 功能; 它不更改信封中的地址, 也不重组编辑性内容. 数据形式变更, 例如改为 MIME Content-Transfer-Encoding, 属于 MTA 权限范围, 但删除或替换正文内容不属于. MTA 还会添加跟踪信息 [RFC2505].

注意: 在目标 ADMD 内, 电子邮件中继模块可以在交付前对消息进行各种更改. 在这种情况下, 这些模块充当 Gateway, 而不是 MTA.

Internet Mail 主要使用 SMTP ([RFC5321], [RFC2821], [RFC0821]) 在对等 MTA 之间执行点到点传输. 其他传输机制包括 Batch SMTP [RFC2442] 和 On-Demand Mail Relay (ODMR) SMTP [RFC2645]. 与大多数网络层机制一样, Internet Mail SMTP 通过在临时传输失败后支持重传来提供基本可靠性. 与典型分组交换机和 Instant Messaging 服务不同, Internet Mail MTA 预期以允许跨服务中断恢复的方式存储消息, 例如主机系统关机. MTA 的稳健性和持久性程度可能不同. 基础 SMTP 规范提供协议响应码框架. [RFC5248] 定义了对该框架的可扩展增强.

虽然非常基础, Internet Mail 的主要路由机制是 DNS MX 记录 [RFC1035], 它指定可到达被查询域的 MTA. 该机制假定存在一个公共的或至少共同的主干, 允许任何连接的 MTA 连接到任何其他 MTA.

MTA 可以执行以下成熟角色:

Boundary MTA:

属于某个 ADMD 并与其他 ADMD 中 MTA 交互的 MTA. 它也称为 Border MTA. 根据邮件流向可以有不同的 Boundary MTA.

Outbound MTA: 将消息中继到其他 ADMD 的 MTA.

Inbound MTA: 从其他 ADMD 的 MTA Relay 接收入站 SMTP 消息的 MTA, 例如运行在 MX 记录目标主机上的 MTA.

Final MTA:

将消息传输给 MDA 的 MTA.

以下身份与 MTA 相关:

• RFC5321.HELO/.EHLO
• RFC3461.ENVID
• RFC5321.MailFrom
• RFC5321.RcptTo
• RFC5322.Received: 设置者 - Relay Server
• RFC0791.SourceAddr

4.3.3. 邮件投递代理 (Mail Delivery Agent, MDA)

从 MHS 向 Recipient 环境 (邮箱) 的责任转移称为 "delivery" (交付). 在架构中, 如图 5 所示, 交付发生在 Mail Delivery Agent (MDA) 内部, 显示为从面向 MHS 的 MDA 组件 (hMDA) 到面向 Recipient 的 MDA 组件 (rMDA) 的 (D) 转换.

MDA 可以提供独特的基于地址的功能, 这得益于它掌握目标地址属性的详细信息. 这些信息也可能存在于 Recipient 的 ADMD 中其他位置, 例如组织边界 Relay. 但 MDA 必须拥有这些信息, 至少因为 MDA 必须知道把消息交付到哪里.

与 MSA 类似, MDA 也服务于两个角色, 如图 5 所示. 正式责任转移称为 "delivery", 在体现这些角色的两个组件之间完成, 图 5 中显示为 "(D)". MHS 部分 (hMDA) 主要作为服务器 SMTP 引擎工作. 一个常见附加角色是按照 Recipient 收件人偏好将消息重定向到替代地址. MDA 的 Recipient 部分 (rMDA) 负责执行 Recipient 指定的任何交付动作.

进入 MDA 的传输通过普通 MTA 传输机制完成. 从 MDA 到 MS 的传输使用访问协议, 例如 POP 或 IMAP.

注意: "delivery" 一词可以指这里规定的正式 MHS 功能, 也可以指消息第一次显示给 Recipient 的时刻. 判断是否适用基于 MHS 的定义有一个简单实用测试: 是否可以生成 DSN.

以下身份与 MDA 相关:

RFC5321.Return-Path: 设置者 - Author Originator 或 Mediator Originator

MDA 将 RFC5321.MailFrom 地址记录到 RFC5321.Return-Path 字段中.

RFC5322.Received: 设置者 - MDA server

MDA 可以记录 Received: 头字段以表示跟踪信息, 包括源主机和接收主机的域名和/或 IP 地址.

4.4. 转换模式 (Transition Modes)

从发起站点到交付点, Internet Mail 通常遵循 "push" 模型. 也就是说, 持有消息的 Actor 发起到下一场所的传输, 通常使用 SMTP [RFC5321] 或 Local Mail Transfer Protocol (LMTP) [RFC2033]. 在 "pull" 模型中, 持有消息的 Actor 等待下一场所中的 Actor 发起传输请求. 基于拉取的标准化 MHS 传输机制包括 ETRN [RFC1985] 和 ODMR [RFC2645].

交付后, Recipient 的 MUA 或 MS 可以通过让消息被推送给它来获得访问, 也可以让访问接收方拉取消息, 例如使用 POP [RFC1939] 和 IMAP [RFC3501].

4.5. 实现和运行 (Implementation and Operation)

当架构与实现被混淆时, 任何有趣系统架构的讨论都很容易陷入停滞. 架构定义服务的概念功能, 并将其划分为离散概念模块. 该架构的实现可以根据特定运行环境需要组合或分离架构组件. 例如, 主要执行消息中继的软件系统是 MTA, 但它也可能包含 MDA 功能. 同一个 MTA 系统也可能能够与非 Internet 电子邮件服务接口, 因而同时作为 MTA 和 Gateway 工作.

类似地, 已实现模块可以被配置成架构的扩展形式. 一个有趣示例是分布式 MS. 其中一部分可以是远程服务器, 另一部分可以位于 MUA 本地. 如 [RFC1733] 所述, 此类 MS 之间有三种运行关系:

Online:

MS 是远程的, 只有当 MUA 附接到 MS 时消息才可访问, 因而 MUA 会在一个会话到下一个会话之间重新获取消息的全部或部分内容.

Offline:

MS 位于 User 本地, 消息会从任何远程存储中完全移出, 而不是也保留在那里.

Disconnected:

rMS 和 uMS 在连接时保持全部或部分内容同步. 断开连接时, 邮件可以到达 rMS, User 也可以修改 uMS. 两个存储会在重新连接时重新同步.