跳到主要内容

2. 责任参与者角色

Internet Mail 是一种高度分布式服务, 多种 Actor (参与者) 扮演不同角色. 这些 Actor 分为三种基本类型:

  • User (用户)

  • Message Handling Service (MHS, 消息处理服务)

  • ADministrative Management Domain (ADMD, 管理域)

虽然这些角色与技术架构相关, 但 Actor 视角关注的是参与者责任, 而不是模块功能. 因此, 本文使用的标签不同于经典电子邮件架构图中的标签.

2.1. 用户参与者 (User Actor)​

User 是消息的源和汇. User 可以是人,组织或进程. User 之间的交换可以反复迭代, 也可以扩展或收缩参与一组交换的 User 集合. 在 Internet Mail 中, User 有四种类型:

  • Author (作者)

  • Recipient (收件人)

  • Return Handler (退回处理者)

  • Mediator (中介者)

图 2 展示它们之间的主要和辅助消息流. 一个实用判断是: User Actor 可以生成,修改或查看整条消息.

         ++==========++
         ||  Author  ||<..................................<..
         ++=++=++=++=++                                     .
            || || ||     ++===========++                    .
            || || ++====>|| Recipient ||                    .
            || ||        ++=====+=====++                    .
            || ||               .                           .
            || ||               ..........................>.+
            || ||                                           .
            || ||               ...................         .
            || ||               .                 .         .
            || ||               V                 .         .
            || ||         +-----------+    ++=====+=====++  .
            || ++========>| Mediator  +===>|| Recipient ||  .
            ||            +-----+-----+    ++=====+=====++  .
            ||                  .                 .         .
            ||                  ..................+.......>.+
            ||                                              .
            ||    ..............+..................         .
            ||    .             .                 .         .
            \/    V             V                 '         .
         +-----------+    +-----------+    ++=====+=====++  .
         | Mediator  +===>| Mediator  +===>|| Recipient ||  .
         +-----+-----+    +-----+-----+    ++=====+=====++  .
               .                .                 .         .
               .................+.................+.......>..

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

               Figure 2: Relationships among User Actors

从 User 视角看, 所有消息传输活动都由一个整体式 MHS 执行, 即使实际服务可能由许多独立组织提供. User 是这个统一服务的客户.

当任何 MHS Actor 在处理消息的过程中向 Author 或 Originator 回送信息时, 该 Actor 就是一个 User.

2.1.1. 作者 (Author)​

Author 负责创建消息,消息内容以及 Recipient 地址列表. MHS 从 Author 处传输消息并交付给 Recipient. MHS 中有一个与 Author 角色相关联的 Originator 角色 (第 2.2.1 节).

2.1.2. 收件人 (Recipient)​

Recipient 是已交付消息的消费者. MHS 中有一个与 Recipient 角色相关联的 Receiver 角色 (第 2.2.4 节). 图 3 中该角色标记为 Recv.

任何 Recipient 都可以创建并提交回复 Author 的新消息, 从而闭合用户通信循环. 自动回复的一种形式是 Message Disposition Notification (MDN, 消息处置通知), 用于向 Author 告知 Recipient 如何处理了该消息. 参见第 4.1 节.

2.1.3. 退回处理者 (Return Handler)​

Return Handler 也称为 "Bounce Handler", 是一种特殊的 Recipient, 负责处理 MHS 在传输或交付消息时生成的通知. 参见图 3. 这些通知可以关于失败或完成, 并发送到 Originator 指定的地址. 这个 Return Handling 地址也称为 Return Address, 其可见特征可能与 Author 或 Originator 的地址完全不同.

2.1.4. 中介者 (Mediator)​

Mediator 在 Author 与 Recipient 之间接收,聚合,重组并重新分发消息, 这些 Author 和 Recipient 是可能长期交换过程中的主体. 这种活动很容易与底层 MHS 传输交换混淆. 但二者目标完全不同, 运行方式也完全不同.

当邮件被交付给原始消息的 RFC5321.RcptTo 命令中指定的 Mediator 时, MHS 会像处理任何其他 Recipient 一样处理它. 特别是, MHS 将源和汇之间每一次投递与交付活动视为独立活动; 它不会把后续重新投递视为同一过程的延续. 因为 Mediator 会发起消息, 它也可以接收回复. 因此, 在提交重组后的消息时, Mediator 是 Author, 尽管它实际上是代表一个或多个其他 Author 工作的 Author. 所以 Mediator 是完整意义上的 User. 第 5 节会详细讨论 Mediator.

Mediator 试图在其重组的消息中保留原 Author 的信息, 但允许对消息内容或信封进行有意义的更改. MHS 看到的是一条新消息, 但 User 收到的消息会被理解为来自原始消息的 Author, 或至少由该 Author 发起. Mediator 的角色不限于简单连接其他参与者; Mediator 对新消息负责.

Mediator 的角色复杂且依赖上下文, 例如修改和添加内容, 或控制哪些 User 可在何时参与. 该角色的常见示例是群组 Mailing List. 在更复杂的用法中, 一连串 Mediator 可以执行一系列正式步骤, 例如审阅,修改并批准采购请求.

Gateway 是一种特别值得注意的 Mediator. 它是连接异构邮件服务的 User 与 Relay 混合体. 其目的是模拟 Relay. 详细讨论见第 2.2.3 节.

2.2. 消息处理服务 (MHS) 参与者 (Message Handling Service Actor)​

Message Handling Service (MHS) 代表 Author 执行一次端到端传输, 以到达原始 RFC5321.RcptTo 命令中指定的 Recipient 地址. 经由中介或迭代且长期的交换, 例如随时间开展协作时使用的交换, 由 User Actor 处理, 而不是由 MHS Actor 处理. 一个实用判断是: MHS Actor 只生成,修改或查看传输数据, 而不是整条消息.

图 3 展示 Internet Mail 中传输参与者之间的关系. 虽然图中把 Originator (标记为 Origin) 与 Author 区分开, 也把 Receiver (标记为 Recv) 与 Recipient 区分开, 但每对角色通常由同一个 Actor 扮演. 传输通常涉及一个或多个 Relay. 不过, 从 Originator 到 Receiver 的直接交付也是可能的. 组织内部邮件服务通常只有一个 Relay.

         ++==========++                        ++===========++
         ||  Author  ||                        || Recipient ||
         ++====++====++   +--------+           ++===========++
               ||         | Return |                  /\
               ||         +-+------+                  ||
               \/           .    ^                    ||
           +---------+      .    .                +---++---+
           |         |      .    .                |        |
        /--+---------+----------------------------+--------+----\
        |  |         |      .    .      MHS       |        |    |
        |  | Origin  +<......    .................+  Recv  |    |
        |  |         |           ^                |        |    |
        |  +---++----+           .                +--------+    |
        |      ||                .                    /\        |
        |      ||  ..............+..................  ||        |
        |      \/  .             .                 .  ||        |
        |  +-------+-+        +--+------+        +-+--++---+    |
        |  |  Relay  +=======>|  Relay  +=======>|  Relay  |    |
        |  +---------+        +----++---+        +---------+    |
        |                          ||                           |
        |                          ||                           |
        |                          \/                           |
        |                     +---------+                       |
        |                    | Gateway +-->...                  |
        |                     +---------+                       |
        \-------------------------------------------------------/

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

               Figure 3: Relationships among MHS Actors

2.2.1. 发起者 (Originator)​

Originator 确保消息适合投递, 然后将其提交给 Relay. 如果消息同时符合 Internet Mail 标准和本地运行策略, 它就是有效消息. Originator 可以只是检查消息合规性并在发现错误时拒绝消息, 也可以创建部分或全部必要信息. 实际上, Originator 负责 Mail Submission Agent (邮件提交代理) 的功能.

Originator 具有双重归属. 它服务于 Author, 并且可以与 Author 是同一实体. 但它确保有效性的角色也意味着它代表 MHS 的本地运营者, 即本地 ADMD.

Originator 还执行与消息传输和交付相关的任何提交后 Author 管理任务. 这些任务特别包括发送错误和交付通知,执行本地策略, 以及处理来自 Author 但对 Internet 造成问题的消息. 即使 Originator 不负责消息内容, 它也要对消息内容承担可问责性. Author 创建消息, 而 Originator 处理该消息的传输问题.

2.2.2. 中继 (Relay)​

Relay 通过向 Recipient 传输或重传消息, 执行 MHS 级传输服务路由和存储转发. Relay 添加跟踪信息 [RFC2505], 但不修改信封信息或消息内容语义. 它可以修改消息内容表示, 例如将传输编码形式从二进制改为文本, 但只能在满足 MHS 下一跳能力所必需时这样做.

Message Handling System (MHS) 网络由一组 Relay 构成. 该网络位于可能使用的底层分组交换网络之上, 并位于 Gateway 或其他 Mediator 之下.

换言之, 电子邮件场景可以涉及三个不同架构层, 每层提供自身类型的存储转发数据服务:

  • User Mediator.

  • MHS Relay.

  • Packet Switch (分组交换机).

最底层是 Internet 的 IP 服务. 最基本的电子邮件场景涉及 Relay 和 Switch.

当 Relay 停止尝试传输消息时, 它会成为 Author, 因为它会向 Return Address 发送错误消息. 通过在该消息中省略 Return Address, 可以避免潜在循环.

2.2.3. 网关 (Gateway)​

Gateway 是连接异构邮件服务的 User 与 Relay 混合体. 其目的是模拟 Relay, 越接近这一目标越好. 当 Gateway 需要修改消息内容的能力时, 它以 User 身份运行.

邮件服务之间的差异可以小到语法细节变化, 但通常包含重要语义差异. 一种差异可能是电子邮件地址采用层次化且机器相关的形式, 而不是扁平的全局命名空间. 另一种差异可能是只支持纯文本内容或支持多媒体内容. 因此, 如果希望结果表现得近似无缝, Gateway 中的 Relay 功能会带来显著设计挑战. 该挑战是: 尽管服务在语法和语义上存在差异, 仍要确保服务之间的 User 到 User 功能.

Gateway 设计的基本测试是: Gateway 一侧的 Author 是否能向另一侧的 Recipient 发送有用消息, 而无需更改 Author 或 Recipient 邮件服务中的任何组件, 除了增加 Gateway. 对这些原本独立的服务而言, Gateway 看起来像本地参与者. 但 Gateway 设计的最终测试是 Author 和 Recipient 能否维持对话. 特别是, Recipient 的 MUA 能否自动形成一个可达 Author 的有效 Reply?

2.2.4. 接收者 (Receiver)​

Receiver 执行最终交付, 或将消息发送到替代地址. 它也可以在交付前后立即执行过滤和其他策略执行.

2.3. 管理参与者 (Administrative Actor)​

Administrative Actor 可以关联到不同组织, 每个组织都有自己的管理权限. 这种运营独立性, 加上不同组之间交互的需要, 构成了区分 ADMD 的动机. 每个 ADMD 可以具有非常不同的运行策略和基于信任的决策方式. 一个明显示例是组织内部交换的邮件与独立组织之间交换的邮件之间的区别. 处理这两类流量的规则往往很不相同. 这种差异要求定义二者边界, 因而需要 ADMD 构造.

Internet Mail 服务由不同提供者或运营者运行. 每个提供者都可以是独立 ADMD. 这种管理决策独立性定义了边界, 用于区分 Internet Mail 服务的不同部分. 运行本地 Relay 的部门,运行企业 Relay 的 IT 部门, 以及运行公共共享电子邮件服务的 ISP, 可以被配置成许多管理和运营关系组合. 每个都是独立 ADMD, 可能具有复杂的功能组件安排. 图 4 描绘 ADMD 之间的关系. ADMD 构造的好处是, 它便于讨论需要区分内部问题与外部问题的设计,策略和运营.

边界需求对架构的影响在 [Tussle] 中讨论. 最重要的是, 跨 ADMD 边界通信的实体通常额外承担执行组织外部通信策略的负担. 在更日常的层面上, ADMD 之间的邮件路由也可能成为问题, 例如需要通过特别受信路径在组织伙伴之间路由邮件.

ADMD 有三种基本类型:

Edge: : 开放 Internet Mail 服务边缘网络中的独立传输服务.

Consumer: : 可能是一种 Edge 服务, 基于 Web 的电子邮件访问中很常见.

Transit: : Mail Service Provider (MSP, 邮件服务提供商), 为 Edge ADMD 提供增值能力, 例如聚合和过滤.

邮件层传输服务不同于分组层交换. 端到端分组传输通常经过中间路由器; 开放 Internet 上的电子邮件交换可以直接发生在 Edge ADMD 的 Boundary MTA 之间. 这种直接交互与间接交互的区别突出了第 2.2.2 节讨论的差异.

       +--------+     +---------+     +-------+     +-----------+
       |  ADMD1 |<===>|  ADMD2  |<===>| ADMD3 |<===>|   ADMD4   |
       |  ----- |     |  -----  |     | ----- |     |   -----   |
       |        |     |         |     |       |     |           |
       | Author |     |         |     |       |     | Recipient |
       |   .    |     |         |     |       |     |     ^     |
       |   V    |     |         |     |       |     |     .     |
       |  Edge..+....>|.Transit.+....>|-Edge..+....>|..Consumer |
       |        |     |         |     |       |     |           |
       +--------+     +---------+     +-------+     +-----------+

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

            Figure 4: Administrative Domain (ADMD) Example

Edge 网络可以在内部使用专有电子邮件标准. 然而, Transit 网络与 Edge 网络传输服务之间的区别非常重要, 因为它突出了独立管理机构之间交互和保护所需关注的问题. 特别是, 这种区别要求更谨慎地评估消息传输参与者之间的责任转移,可问责性和授权关系.

ADMD 组件之间的交互受该域策略约束, 这些策略覆盖如下关注点:

  • 可靠性.

  • 访问控制.

  • 可问责性.

  • 内容评估和修改.

这些策略可以根据 ADMD 的需要在不同功能组件中实现. 示例见 [RFC5068].

Consumer,Edge 和 Transit 服务可以由运行组件服务或服务集合的提供者提供. 此外, 一个 ADMD 也可以为其他 ADMD 托管服务.

以下是常见 ADMD 示例:

Enterprise Service Provider: : 这些 ADMD 运行组织内部的数据服务和/或邮件服务.

Internet Service Provider (ISP): : 这些 ADMD 运行底层数据通信服务, 供一个或多个 Relay 和 User 使用. ISP 不负责执行电子邮件功能, 但它们可以提供执行这些功能的环境.

Mail Service Provider: : 这些 ADMD 运行电子邮件服务, 例如面向消费者或客户公司的服务.

实际运行问题要求提供者参与管理和执行事务. 这种参与也可以扩展到较低层分组服务的运营者.

最后于 更新