← RFC Reference

RFC 6854: From 和 Sender 报头字段中的组语法

为什么这个功能存在

RFC 5322 要求 From 头包含一个或多个邮箱地址。但某些邮件确实没有单一人类作者：

• 自动化系统消息 — 监控告警、构建通知、计划报告。没有人写这些。
• 邮件列表摘要 — 摘要聚合来自多个作者的消息。谁是"From"地址？
• 团队协作文档 — 由团队共同起草的消息。
• Noreply 地址 — 某些组织希望表明不期望回复，而不暴露真实地址。

RFC 6854 更新了 RFC 5322，允许在 From 和 Sender 头中使用组语法。组语法可以包含零个或多个邮箱地址，意味着你可以有一个带有描述性名称但内部没有实际地址的 From 头。

工作原理

组语法基础

组语法已在 RFC 5322 中为 To 和 Cc 等头定义过。它看起来像这样：

; 组语法：display-name ":" [mailbox-list] ";"

; 带成员的组（已在 To/Cc 中允许）
To: Engineering Team: alice@example.com, bob@example.com;

; 空组 — 无地址（RFC 6854 的关键创新）
From: Engineering Team:;

关键的新功能是 From 中的空组：显示名称后跟 :;，冒号和分号之间没有地址。

在 From 中使用组语法时的要求

RFC 6854 设置了严格的条件：

1. 需要 Sender 头。 当 From 字段使用组语法（尤其是空组）时，消息必须包含一个 Sender 头，其中包含有效的邮箱地址。这确保消息始终有一个负责地址。
2. Sender 地址必须是真实的、可递送的邮箱。 它必须能够接收回复和退信。
3. 谨慎使用。 RFC 明确指出这仅用于无法识别单一作者的情况。普通人对人的电子邮件应继续在 From 中使用标准邮箱语法。

实际示例

; 自动监控告警 — 无人类作者
From: Monitoring System:;
Sender: noc@example.com
To: ops-team@example.com
Subject: [ALERT] Database connection pool exhausted

; 邮件列表摘要 — 多个作者聚合
From: Dev List Digest:;
Sender: dev-list-owner@lists.example.org
To: dev-list@lists.example.org
Subject: Dev List Digest, Vol 42, Issue 7

; 带一个成员的组 — 代表团队的命名作者
From: Security Team: security-lead@example.com;
To: all-staff@example.com
Subject: Mandatory password rotation notice

与标准 From 的区别

关键技术细节

与 DKIM 的交互

DKIM 对 From 头进行签名。当 From 包含组语法时，DKIM 对字面头值进行操作。DKIM 签名中的 d= 域不需要与 From 组中的地址匹配（因为可能没有）。相反，DMARC 的 DKIM 对齐回退到 Sender 头或信封发件人。

与 DMARC 的交互

DMARC 对齐要求 From 域与 DKIM d= 域或 SPF 认证的信封发件人域匹配。当 From 中有空组时，没有域可对齐。实际上，这意味着：

• DMARC 无法评估空组 From 头的对齐。
• 大多数 DMARC 实现将其视为不适用结果。
• Sender 头或信封发件人提供实际的认证锚点。

这使得空组 From 头在互联网面向的电子邮件中不常见，因为 DMARC 现已广泛部署。

客户端显示行为

邮件客户端对 From 中的组语法处理不一致：

• Gmail： 显示 Sender 地址作为 From，忽略组显示名称。
• Outlook： 可能显示组名称或 Sender 地址，取决于版本。
• Apple Mail： 通常显示 Sender 地址。
• Thunderbird： 显示组显示名称，括号中为 Sender 地址。

不一致的显示是此功能的主要实践限制。

ABNF 语法更新

RFC 6854 更新了 RFC 5322 中 from 和 sender 字段的语法：

; RFC 5322 原始
from = "From:" mailbox-list CRLF

; RFC 6854 更新
from = "From:" (mailbox-list / address-list) CRLF

; address-list 允许组语法
; group = display-name ":" [group-list] ";"

常见错误

• 在没有 Sender 头的情况下使用空组 From。 当 From 使用没有邮箱地址的组语法时，RFC 6854 需要 Sender 头。没有 Sender，没有负责地址用于退信或回复，严格解析器将拒绝消息。
• 期望一致的客户端呈现。 大多数邮件客户端不是为 From 中的组语法设计的。在部署前在 Gmail、Outlook 和 Apple Mail 上测试。显示可能对收件人造成困惑。
• 将其用于互联网面向的营销或事务性电子邮件。 DMARC 对齐问题使得空组 From 对需要在主要提供商处通过认证检查的电子邮件不切实可行。坚持使用标准邮箱 From 以获得可递送性。
• 忘记分号终止符。 组语法需要结尾的 ;。没有它，头格式错误：From: Team: 无效；From: Team:; 正确。
• 将组语法与显示名称混淆。 From: Team <team@example.com> 是带显示名称的邮箱。From: Team:; 是空组。它们是完全不同的构造，具有不同的语义和要求。
• 当 noreply 地址就足够时使用这个。 对于大多数自动消息，From: noreply@example.com 比组语法更简单、更兼容，收件人和垃圾邮件过滤器也更理解。

可递送性影响

• 空组 From 破坏 DMARC 对齐。 由于 From 地址中没有域，DMARC 没有什么可对齐的。依赖此语法的消息将在大多数接收方处失败 DMARC 检查，如果发件人域具有严格的 DMARC 策略，将导致拒绝或隔离。
• 垃圾邮件过滤器可能标记不熟悉的 From 语法。 组语法在 From 中很少见。针对正常电子邮件模式进行培训的垃圾邮件过滤器可能会将其视为异常，增加垃圾邮件评分。
• 优先对所有外部电子邮件使用标准 From 地址。 使用真实邮箱，如 noreply@example.com 或 notifications@example.com。这是通用兼容的，通过 DMARC，并在所有客户端中正确呈现。
• 组语法适用于内部或受控环境。 在组织内部，你控制邮件基础设施和客户端的地方，组语法可以有意义地表示团队或系统作者身份。对于互联网面向的电子邮件，可递送性权衡不值得。
• 始终包含有效的 Sender 头。 即使在你的测试中不包含它的交付有效，Sender 头也是退信、回复和认证的回退。在大规模情况下省略它会冒无声失败的风险。

Related RFCs