RFC 9057《邮件 Author 头字段》中文导读

Independent Submission · RFC 9057 · 实验性（Experimental） · 2021 年 6 月

诚实披露：本页为 IETF RFC 的人类翻译版本，依 IETF Trust 条款可自由再制与翻译；译本由 AI 基于人类权威文献辅助整理生成，非人类原创，仅供学习参考。

本页按 RFC 9057《Email Author Header Field》 原文章节顺序梳理规范要点，并非逐字全文翻译；任何规范性判断均以英文原文为准。原文由 RFC 编辑器以独立提交（Independent Submission）流派发布并适用 BCP 78 与 IETF Trust 法律条款，英文原文见 rfc-editor.org/rfc/rfc9057.txt。

状态提示：本文档并非互联网标准跟踪规范，而是实验性（Experimental）文档，属独立提交流派，由 RFC 编辑器自行决定发布，且不对其实现或部署价值作出表态。原文第 7 节列出了本实验待回答的问题。

摘要

RFC 9057 的摘要把问题讲得很完整：互联网邮件以 From: 头字段表示邮件内容的作者，以 Sender: 字段表示代作者初次处理该邮件者；当 Sender: 与 From: 信息相同时，Sender: 可以省略。在出现针对 From: 使用的严格保护措施之前，这并不构成问题；此后，它促使邮件列表等中介（Mediator）修改 From: 字段，以规避由这些保护所导致的邮件退拒。实际效果是，From: 字段的角色已被“处理标识”所主导。

本规范针对 From: 这一被改变的用法作出补充，规定 Author: 字段，用以确保对邮件原始作者的标识，且该字段不受中介修改。原文注明，本文档作为实验性 RFC 发布，用于评估社区兴趣、功能有效性与技术充分性。

1. 语义冲突的由来（原文第 1 节）

第 1 节梳理了历史成因：From: 与 Sender: 两个字段最初在 RFC 733 中定义，而把冗余的 Sender: 字段设为可选，在通信速度慢、存储昂贵、算力较弱的年代是一个小而显然的优化。其后果是——当 Sender: 缺席时，From: 字段就同时兼具处理标识与内容创建者标识两种语义。

原文接着说明这种双重语义在严格的 From: 保护出现后如何变成问题：它促使邮件列表等中介修改 From: 以规避收件方的退拒，而这会影响作者与最终收件人之间的端到端可用性，因为同一作者发来的邮件，会因所走路径不同而被收件人软件区别对待。

原文给出的示例是：原本发出的邮件 From: 为 Example User <user@example.com>；若直接投递给收件人，作者显示名可正确呈现，收件方也能基于其邮件地址正确地分析、过滤与聚合来自该作者的邮件。但若作者经由邮件列表发送，而该列表执行了为绕过严格认证策略执行而常见的那种 From: 改写，收到的邮件 From: 可能变成 Example User via Example List <listname@list.example.org>——这一改动把中介的一个运营地址塞进了 From:，并扭曲了该字段的显示名以记录此次修改。

第 1 节把这一改动在邮件标识语义上的“深刻变化”归纳为两点：

第 1 节末尾解释了设计取舍：虽然转向更可靠地使用 Sender: 字段、并把它作为认证关注焦点或许更为干净，但对既有标准的增强，采取增量添加比试图替换更为可行。因此本规范提供的是一种不会被那些执行严格认证的处理过程所修改的作者信息承载手段。

2. Author 头字段定义（原文第 3 节）

第 3 节定义新头字段 Author:，其语法与 From: 头字段相同（见 RFC 5322）。与 From: 字段最初且首要的意图一致，Author: 字段意在容纳邮件内容作者的邮件地址，也可以包含作者的可显示人名。其 ABNF 为：

author = "Author:" mailbox-list CRLF

原文说明该语法与 From: 头字段的语法相呼应。该头字段既可以在原始邮件创建过程中加入，也可以稍后由中介加入，以保留 From: 字段中的原始作者信息。

第 3 节解释了为何允许中介创建：Author: 字段的目标是反映原始作者的信息，但作者的 MUA 或 MSA 有可能并不创建它，而中介可能预知自己将要修改 From: 字段并希望保留作者信息，因此需要允许中介在该字段尚不存在时创建它。

处理规则共三条，原文以规范性关键词写明：

① 若 Author: 字段已存在，则必须不（MUST NOT）创建新的，且必须不修改已存在的那一个。

② 作者的 MUA 或 MSA 可以（MAY）创建 Author: 字段，其值必须（MUST）与 From: 字段中的值完全相同。

③ 中介可以在 Author: 字段尚不存在时创建它，且该新字段的值必须与中介收到该邮件时（且在中介导致 From: 发生任何改动之前）的 From: 字段值完全相同。

3. 讨论：与既有字段的关系（原文第 4 节）

第 4 节说明 Author: 字段意在于邮件生成期间或中介处理期间创建，供收件方 MUA 使用——用法与它们通常使用 From: 字段的方式相当。原文由此提出一条合理性判断：对于通常会基于 From: 字段来组织、过滤或展示信息的 MUA 而言，优先采用 Author: 头字段是合理的。

第 4 节还辨析了一个近亲字段：Original-From:。该字段在 RFC 5703 中被引用并已在 IANA 登记，IANA 以 RFC 5703 作为该条目的控制来源；但原文指出，那份文档对该字段只有极简定义，且该字段仅供中介使用以保留被修改的 From: 字段中的信息。相比之下，本规范定义的 Author: 字段在邮件发起时或中介处理时都可以使用。

该节另有两条提醒：其一，尽管邮件头字段的基本模型具备高度可扩展性，但把该字段一路传递到最终用户（例如经由 IMAP）在实现与可用性上可能仍有需要考虑之处；其二，原文明确指出——任何与邮件相关的安全性处理都需要区分 From: 字段与 Author: 字段，并相应地对待各自的信息。

4. 安全考量（原文第 5 节）

第 5 节的立场颇为审慎且坦率。它首先指出：任何包含身份标识信息的头字段都是安全与隐私关注的来源，当该信息涉及内容作者身份时尤其如此；总体上，对 Author: 头字段的处理需要受到与 From: 头字段相当的审视与谨慎对待，但最好不要以一种会抵消其效用的方式进行。

随后原文讨论了“是否会成为新的欺骗向量”这一疑虑：鉴于 Author: 头字段的语义，很容易认为该字段的使用会为欺骗最终用户创造新的攻击面。但原文给出的判断是——尽管用户被邮件中具欺骗性或虚假的内容所骗的真实且严重的案例大量存在，却没有证据表明某个用于提供邮件作者相关信息的头字段中的问题内容，会直接导致最终用户产生差异化的、有问题的行为。原文并以括注的方式把“寻找可信且有据可查的证据”留作读者的练习。

5. IANA 登记（原文第 6 节）

IANA 已按 RFC 3864 把 Author: 头字段登记到 “Provisional Message Header Field Names”（临时性邮件头字段名称）注册表：

6. 实验目标（原文第 7 节）

第 7 节说明：由于该字段的语义呼应了长期存在的 From: 头字段，其创建与使用的基本机理已被充分理解；因此真正的关注点在于它与既有 From: 字段、反滥用系统以及 MUA 行为之间可能的相互作用，以及基本的市场接受度。原文列出在该头字段处于实验状态期间需要回答的问题：

原文致谢部分注明，该字段的构想源自 IETF DMARC 工作组中的讨论。

7. 术语英文对照

参考链接

参考：https://www.rfc-editor.org/rfc/rfc9057.txt