RFC 5598 – 互联网邮件架构
RFC 的存在理由
在 RFC 5598 之前，电子邮件社区对"MTA""中继"和"网关"等术语的使用松散且不一致。不同的 RFC 对相同的概念使用不同的术语。这造成了真实的混淆，特别是当 SPF、DKIM 和 DMARC 等身份验证机制需要精确定义消息路径中谁在做什么时。
由 Dave Crocker 于 2009 年发布，RFC 5598 为互联网电子邮件提供了一个综合的架构模型。它不是协议规范——它不定义任何新的数据格式或命令。相反，它是一个参考框架，用于命名和定义电子邮件生态系统中的每个参与者、角色和函数。几乎每个现代电子邮件 RFC 都引用 5598 的术语。
工作原理
RFC 5598 将电子邮件系统分解为围绕消息从发件人到收件人的旅程组织的不同功能组件。
四个主要环境
该架构定义了消息通过的四个运营环境：
- 邮件用户代理 (MUA) 环境：用户编写和阅读消息的地方。您的电子邮件客户端——Gmail、Outlook、Thunderbird 或您的应用程序调用的 API。
- 邮件提交代理 (MSA) 环境：接受来自 MUA 的消息并将其传递到邮件系统的服务。根据 RFC 6409 在端口 587 上运行，需要身份验证。
- 邮件传输代理 (MTA) 环境：核心路由基础设施。MTA 使用 SMTP (RFC 5321) 在端口 25 上跨互联网中继消息。
- 邮件投递代理 (MDA) 环境：将消息放入收件人邮箱的最终系统，通过 IMAP、POP3 或网络邮件使其可用。
消息流
关键参与者和角色
| 参与者 | 缩写 | 角色 |
|---|---|---|
| 邮件用户代理 | MUA | 为用户编写和显示消息。电子邮件客户端。 |
| 邮件提交代理 | MSA | 接受来自已认证 MUA 的消息、执行策略并将其注入 MTA 基础设施。 |
| 邮件传输代理 | MTA | 使用 SMTP 路由和中继域间消息。电子邮件的"骨干"。 |
| 邮件投递代理 | MDA | 最终投递到收件人的邮箱。可能应用过滤规则。 |
| 邮件存储 | MS | 存储消息并通过 IMAP/POP3/JMAP 提供访问。 |
身份类型
RFC 5598 仔细区分了与消息关联的不同身份：
| 身份 | 出现位置 | 含义 |
|---|---|---|
| 发件人 |
From: 标头 |
编写消息的人或实体 |
| 发送者 |
Sender: 标头 |
实际传输消息的代理（与发件人不同时） |
| 返回路径 |
MAIL FROM 信封 / Return-Path: 标头 |
退信应送往的位置；运输中的责任方 |
| 收件人 |
RCPT TO 信封 / To:/Cc: 标头 |
预期的收件人 |
这种区分对身份验证至关重要。SPF 验证返回路径身份。DKIM 可以代表发件人或中介签名。DMARC 将发件人身份与 SPF 和 DKIM 结果对齐。
关键技术细节
中介者
RFC 5598 识别了一类至关重要的参与者，称为中介者——接收消息然后重新发布的实体，可能在途中修改消息：
-
邮件列表：接收消息，添加列表标头，可能修改主题或正文，并重新分发给订阅者。列表成为新的
MAIL FROM发件人。 - 网关：在电子邮件和另一个消息系统之间转换（例如，电子邮件到短信、电子邮件到传真）。
- 转发者/重新分发者：转发或重新分发邮件，例如校友转发地址。
中介者是电子邮件身份验证复杂的主要原因。当邮件列表更改信封发件人并修改消息时，SPF 会失败（新的发件人 IP 未获得原始域的授权），DKIM 也可能失败（正文被修改）。这正是 ARC (RFC 8617) 设计用来解决的问题。
ADMD：管理管理域
RFC 5598 引入了ADMD 的概念——邮件操作的管理边界。ADMD 是在单一管理机构下运营一个或多个邮件服务的组织。例子：
- 运行自己的 Exchange 服务器的公司是一个 ADMD。
- Gmail/Google Workspace 是一个 ADMD。
- 像 MailerToGo 这样的事务性电子邮件服务是一个 ADMD。
当消息离开一个组织的邮件基础设施并进入另一个组织的邮件基础设施时，消息会跨越 ADMD 边界。身份验证和信任决策发生在这些边界处。
信封与内容
该架构规范化了每条电子邮件消息的两个层级：
-
信封：用于路由的 SMTP 级别信息（
MAIL FROM、RCPT TO）。在提交期间创建并在每跳修改。 - 内容：消息标头和 RFC 5322 定义的正文。打算在编写后保持不变，尽管中介者可能会修改。
常见错误
- 混淆 MTA 和 MSA。MSA（端口 587、已认证）和 MTA（端口 25、服务器到服务器）有不同的用途。直接将应用程序电子邮件发送到远程 MTA 的端口 25 ——绕过 MSA ——会跳过身份验证和策略执行。大多数云提供商因此阻止出站端口 25。
-
忽视中介者问题。如果您在未考虑消息可能通过邮件列表的情况下强制执行严格的 DMARC (
p=reject)，这些转发的消息将在目标处被拒绝。理解中介者概念有助于您为此做计划。 -
将 From: 视为发件人。
From:标头识别发件人，而不是传输发件人。SPF 检查信封发件人，而不是 From 标头。这种区分是整个 DMARC 对齐的基础。 - 假设平面拓扑。消息不总是直接从发件人到接收人。它们可能通过多个 MTA、邮件列表、转发服务和网关。每一跳都可以修改信封并可能修改内容。
- 不理解 ADMD 边界。当您委托发送到电子邮件服务时，消息会跨越 ADMD 边界。必须配置 SPF、DKIM 和 DMARC 来考虑这种委托。
可递送性影响
- 正确的提交架构。使用 MSA（端口 587 和身份验证）而不是直接注入 MTA，确保您的消息从一开始就经过正确的身份验证和策略兼容。像 MailerToGo 这样的服务充当您的 MSA。
- 身份验证对齐。理解每个身份验证机制检查哪个身份——SPF 检查返回路径，DKIM 代表域签名，DMARC 将其与 From 标头对齐——需要理解 RFC 5598 的身份模型。
- 转发和列表处理。如果您的收件人使用转发服务或邮件列表（中介者），您的消息可能在最终目的地处无法通过身份验证。理解中介者角色有助于您诊断"为什么我通过 DMARC 的消息被拒绝了？"
- 退信处理。该架构区分了发件人（From 标头）和返回路径（MAIL FROM）。退信发送到返回路径。如果您正确设置返回路径，可以自动处理退信，而不会将其与对发件人的回复混淆。