5. 中介者
从 Author 到 Recipient 的基本消息传输, 是通过异步存储转发通信基础设施完成的, 消息会依次通过若干 MTA 进行独立传输. 另一类完全不同的任务是通过 Mediator 完成一连串投递与交付. Mediator 通过重新投递过程转发消息. Mediator 与基本 MTA 中继共享某些功能, 但在寻址和内容方面比 MTA 拥有更大灵活性.
以下是所有类型 Mediator 通常都会设置的核心消息信息:
RFC5321.HELO/.EHLO: 设置者 - Mediator Originator
RFC3461.ENVID: 设置者 - Mediator Originator
RFC5321.RcptTo: 设置者 - Mediator Author
RFC5321.Received: 设置者 - Mediator Dest
Mediator 可以记录接收信息, 表示已交付到原地址并提交到别名地址. Received: 头字段跟踪可以包括从原始投递,经过中继,到最终交付的全部过程.
Mediator 区别于任何其他创建消息的 MUA 之处在于, Mediator 会保留原始消息的完整性和语气, 包括其发起信息的关键方面. Mediator 也可以添加评论.
以下 MUA 消息示例不是由 Mediator 创建:
转发现有消息的新消息:
虽然这种动作提供了一类 Mediator 的基本模板, 但其典型发生形式本身并不是 Mediator 示例. 新消息被视为来自执行转发的 Actor, 而不是来自原 Author.
新消息封装原消息, 并被看作来自新的 Originator. 这个 Mediator Originator 可以添加评论, 也可以修改原消息内容. 因为被转发消息是新 Originator 所发送消息的一个组成部分, 新消息创建了新的对话. 不过最终 Recipient 仍会把其中包含的消息看作来自原 Author.
回复:
当 Recipient 响应某条消息的 Author 时, 新消息通常不被视为对原消息的转发. 它关注的是新内容, 尽管可能包含原消息的全部或部分材料. 早先材料只是上下文性的,次要的. 这也包括自动回复, 例如第 4.2.1 节讨论的休假外出通知.
注释:
原消息完整性通常会保留, 但会以区别于原文的方式添加一个或多个关于该消息的评论. 新消息的主要目的是由新的 Author 提供评论, 类似 Reply.
本节其余部分描述 Mediator 的常见示例.
5.1. 别名 (Alias)
MDA 的一个功能是确定邮箱的内部位置以执行交付. Alias (别名) 是一种简单的重寻址设施, 它提供一个或多个新的 Internet Mail 地址, 而不是单个内部地址; 消息会继续通过传输服务, 被交付到一个或多个替代地址. 虽然该设施通常作为 MDA 的一部分实现, 但它是 Recipient 功能. 它会重新提交消息, 但除信封 Recipient (RFC5321.RcptTo) 地址外, 所有处理信息都会保留. 特别是, Return Address (RFC5321.MailFrom) 不变.
这种转发机制的独特之处在于它非常接近普通 MTA 存储转发中继. 它唯一显著差异是更改 RFC5321.RcptTo 值. 因为变化很小, 别名可以被视为较低层邮件中继活动的一部分. 但这个小变化具有很大语义影响: 指定的 Recipient 选择了新的 Recipient.
注意: 当替换列表包含多个地址时, 别名越来越可能出现交付问题. 任何问题报告都会发送给原 Author, 而不是别名条目的管理员. 这会使问题更难解决, 因为原 Author 并不了解 Alias 机制.
除本节开头列出的核心消息信息外, Alias 通常会改变:
RFC5322.To/.CC/.BCC: 设置者 - Author
这些字段保留其原始地址.
RFC5321.MailFrom: 设置者 - Author
保留原 MailFrom 值的好处是确保与发起 ADMD 相关的 Actor 知道发生了交付问题. 另一方面, 从原 Recipient 邮箱转到别名邮箱时的问题处理责任通常属于该原 Recipient, 因为 Alias 机制严格受该 Recipient 控制. 保留原 MailFrom 地址会阻碍这一点.
5.2. 重发送者 (ReSender)
ReSender 也称为 ReDirector, 其动作不同于普通转发, 因为 Mediator 会 "拼接" 消息的寻址信息, 将原消息的 Author 与新消息的 Recipient 连接起来. 这种连接允许双方使用正常 MUA Reply 功能直接交换, 同时完整记录充当 Mediator 的 Recipient 的引用信息. 因此, 即使 Mediator 添加了评论, 新 Recipient 也会把消息看作来自原 Author.
除本节开头列出的核心消息信息外, 以下身份与重新发送的消息相关:
RFC5322.From: 设置者 - 原 Author
保留消息内容原 Author 的名称和地址. 地址的自由格式 display-name 部分可以被修改, 以提供对 ReSender 的非正式引用.
RFC5322.Reply-To: 设置者 - 原 Author
如果原消息中存在此字段, 则在重新发送的消息中保留.
RFC5322.Sender: 设置者 - Author 的 Originator 或 Mediator Originator
RFC5322.To/.CC/.BCC: 设置者 - 原 Author
这些字段指定原消息 Recipient.
RFC5322.Resent-From: 设置者 - Mediator Author
该地址是正在重定向消息的原 Recipient 的地址. 否则, Resent-From: 字段适用的规则与原 RFC5322.From 字段相同.
RFC5322.Resent-Sender: 设置者 - Mediator Originator
负责重新提交消息的 Actor 的地址. 与 RFC5322.Sender 一样, 当该字段包含与 RFC5322.Resent-From 相同的地址时可以省略.
RFC5322.Resent-To/-CC/-BCC: 设置者 - Mediator Author
这些是现在能够回复原 Author 的新 Recipient 地址.
RFC5321.MailFrom: 设置者 - Mediator Originator
负责重新提交的 Actor (RFC5322.Resent-Sender) 也负责指定新的 MailFrom 地址.
5.3. 邮件列表 (Mailing List)
Mailing List 作为显式收件人接收消息, 然后将消息重新投递给订阅成员列表. Mailing List 执行的任务可以被视为 ReSender 的扩展. 除了向数量可能很大的新 Recipient 发送新消息外, Mailing List 还可以修改内容, 例如删除附件,转换格式并添加列表专用评论. Mailing List 还会归档 Author 投递的消息. 但该消息仍保留来自原 Author 的特征.
除本节开头列出的核心消息信息外, Mailing List 处理器在提交消息时通常涉及以下身份:
RFC2919.List-Id: 设置者 - Mediator Author
RFC2369.List-*: 设置者 - Mediator Author
RFC5322.From: 设置者 - 原 Author
保留消息内容原 Author 的名称和电子邮件地址.
RFC5322.Reply-To: 设置者 - Mediator 或原 Author
虽然存在问题, 但 Mailing List 通常会把自己地址分配给所投递消息的 Reply-To: 头字段. 这样做意在确保回复发送给所有列表成员, 而不只是原 Author. 作为 User Actor, Mailing List 是新消息的 Author, 可以合法设置 Reply-To: 值. 但作为试图代表原 Author 呈现消息的 Mediator, 创建或修改 Reply-To: 字段可被视为违反该 Author 的意图. 如果以这种方式修改 Reply-To, 本应只发给原 Author 的回复会转发给整个列表. 如果 Mailing List 不设置该字段, 本应发给整个列表的回复可能只发给原 Author. 两种选择最多都是特定列表的群体文化问题.
RFC5322.Sender: 设置者 - Author Originator 或 Mediator Originator
此字段通常指定负责 Mailing List 运行的 Actor 地址. 以类似简单 MTA Relay 方式运行的 Mailing List 会尽可能保留原处理信息, 包括原 RFC5322.Sender 字段. 注意, 这种运行模式会使 Mailing List 表现得很像 Alias, 可能的差异只是新收件人的数量.
RFC5322.To/.CC: 设置者 - 原 Author
这些字段通常包含原 Recipient 地址列表.
RFC5321.MailFrom: 设置者 - Mediator Originator
因为 Mailing List 可以以任何方式修改消息内容, 它要对该内容负责; 也就是说, 它是 Author. 因此, Return Address 由 Mailing List 指定. Mailing List 复用原 Originator 使用的 Return Address 虽然看似可行, 但消息经 Mailing List 处理后再发送到该地址的通知可能会产生问题.
5.4. 网关 (Gateway)
Gateway 执行消息中继的基本路由和传输工作, 但它也被允许按需要修改内容,结构,地址或属性, 以便将消息发送到使用不同标准或潜在不兼容策略的消息环境中. 当 Gateway 连接两个不同消息服务时, 它的角色很容易识别和理解. 当它连接遵循相似技术标准但管理策略显著不同的环境时, 它很容易被看作只是一个 MTA.
MTA 与 Gateway 的关键区别在于 Gateway 可以对消息作实质性更改, 以便在标准之间映射. 几乎在所有情况下, 这种映射都会造成某种程度的语义损失. Gateway 设计的挑战是尽量减少这种损失. Internet Mail 的标准化 Gateway 包括传真 [RFC4143],语音邮件 [RFC3801] 和 Multimedia Messaging Service (MMS) [RFC4356].
Gateway 可以设置 MUA 可用的任何身份字段. 除本节开头列出的核心消息信息外, 以下身份通常与 Gateway 相关:
RFC5322.From: 设置者 - 原 Author
保留消息内容原 Author 的名称和地址. 与消息中所有原始寻址信息一样, Gateway 可以按目标环境继续可用所需翻译地址.
RFC5322.Reply-To: 设置者 - 原 Author
如果存在此信息, Gateway 最好保留. Recipient 能否成功回复是 Gateway 功能的典型测试.
RFC5322.Sender: 设置者 - Author Originator 或 Mediator Originator
此字段可以保留原值, 也可以设置为新地址.
RFC5322.To/.CC/.BCC: 设置者 - 原 Recipient
这些字段通常保留其原始地址.
RFC5321.MailFrom: 设置者 - Author Originator 或 Mediator Originator
负责处理消息的 Actor 可以指定新地址, 用于接收处理通知.
5.5. 边界过滤器 (Boundary Filter)
为执行安全边界, 组织可以对消息进行分析, 以判断其是否符合自身安全策略. 示例包括检测被归类为垃圾邮件或病毒的内容. 过滤器可能会修改内容以使其安全, 例如删除被认为不可接受的内容. 这些动作通常会向消息添加内容, 记录所执行的动作.