RFC 3848《ESMTP 与 LMTP 传输类型注册》中文导读

IETF · RFC 3848 · 标准跟踪（Standards Track） · 2004 年 7 月 · 作者 C. Newman

诚实披露：本页为 IETF RFC 3848 的中文译介版本。原文由 IETF 发布，依 IETF Trust 条款可自由再制与翻译；本译本由 AI 基于人类权威一手文献（RFC 英文原文）辅助整理生成，非人类原创，亦非逐字全文翻译，仅供学习参考。任何规范性判断以英文原文为准，英文原文见 rfc-editor.org/rfc/rfc3848.txt。

摘要

RFC 3848 是一份短小但在邮件头取证中被高频用到的规范。它向 IANA 的「WITH protocol types」注册表新增了七个邮件传输类型关键字——ESMTPA、ESMTPS、ESMTPSA、LMTP、LMTPA、LMTPS、LMTPSA——供 Received 头字段的 with 子句使用。

在此之前，该注册表只有 SMTP 与 ESMTP 两项，无法表达「这一跳是否用了 STARTTLS」「是否通过了 SMTP AUTH」。有了这七个关键字，只需读一眼 Received 链，就能判断邮件在每一跳上分别启用了哪些安全框架。

1. IANA 考虑：七个新关键字的语义

按 SMTP 规范的要求，IANA 维护着一份用于 Received 头 with 子句的「WITH 协议类型」注册表。本规范对其做出如下扩充：

关键字基础协议STARTTLSSMTP AUTH含义
ESMTPESMTP——（原有）使用 ESMTP
ESMTPAESMTP否是使用 ESMTP，且 SMTP AUTH 扩展被使用并认证成功
ESMTPSESMTP是否使用 ESMTP，且 STARTTLS 成功协商，提供了强传输加密层
ESMTPSAESMTP是是STARTTLS 与 SMTP AUTH 均成功协商（即 ESMTPS 与 ESMTPA 的组合）
LMTPLMTP否否使用本地邮件传输协议 LMTP
LMTPALMTP否是使用 LMTP，且 SMTP AUTH 扩展被使用并认证成功
LMTPSLMTP是否使用 LMTP，且 STARTTLS 成功协商
LMTPSALMTP是是使用 LMTP，且 STARTTLS 与 SMTP AUTH 均成功协商

需要强调的是「成功」这个限定词：关键字中的 A 表示认证已成功达成，S 表示 TLS 已成功协商——尝试过但失败的情况不应记为这些关键字。

此外，本文档还要求把注册表中 SMTP 与 ESMTP 两项的引用更新到当时最新的 SMTP 规范（RFC 2821），因为 RFC 821 与 RFC 1869 已被其废止。今日应对应到 RFC 5321。

2. 实现经验

文档记载，ESMTPA、ESMTPS、ESMTPSA 三个关键字在本文发布时已在部署中的邮件服务器软件里实现多年，未收到使用问题的报告。这解释了为何这份规范只是「把既成事实登记入册」，篇幅极短。

3. 安全考量：可用于取证，不可用于决策

这一节是本 RFC 篇幅最长、也最值得工程团队反复阅读的部分。其立场可概括为四点：

3.1 提供逐跳的安全框架痕迹

"Use of these additional keywords provides trace information to indicate when various high-level security framing protocols are used for hop-to-hop transport of email without exposing details of the specifics of the security mechanism."（§3）

译：使用这些附加关键字可提供追踪信息，标示邮件在逐跳传输中何时使用了各种高层安全框架协议，同时又不暴露该安全机制的具体细节。

这既是一种非正式的机制部署度量方式，也能在事后诊断邮件滥用时提供帮助。

3.2 不具备真实安全保证

"They should not be used for mail filtering or relaying decisions except in very controlled environments."（§3）

译：除非在受到严格控制的环境中，否则不应将它们用于邮件过滤或中继决策。

理由有二：其一，这些关键字在传输中通常不受保护，主动攻击者可以任意伪造或篡改；其二，它们不指明所用机制的具体细节（例如未说明 TLS 版本、密码套件、证书是否校验），因此不构成任何真实世界的安全断言。若需要更高可信度的信息，应把 Received 头与各 MTA 的日志做关联比对。

3.3 不会误导终端用户

文档认为，由于这些关键字既晦涩又隐藏在主要用于诊断问题的追踪头中，预计不会让终端用户产生虚假的安全感。

3.4 反对无谓地删除 Received 信息

原文特别批评了一种常见做法：出于「隐藏内部服务器信息」的考虑而剥离 Received 头中的有用信息。文档指出，这类做法通常是误入歧途的——它削弱了事后纠正安全滥用的能力，其净效果往往是降低系统的整体安全性。

4. 参考文献

原文的规范性引用包括：STARTTLS（RFC 3207）、SMTP（RFC 2821，现为 RFC 5321）、SMTP AUTH（RFC 2554，现为 RFC 4954）、LMTP（RFC 2033）；资料性引用包括 RFC 1869、RFC 821，以及 IANA 的 mail-parameters 注册表。

阅读 Received 链时的对照要点

结合本 RFC，读一条 Received 头时可关注：with 子句的关键字告诉你该跳的安全框架状态；由于每一跳各自独立，某一跳是 ESMTPS 并不代表全链路加密——端到端的强制加密需求应由 MTA-STS（RFC 8461）、DANE（RFC 7672）或 REQUIRETLS（RFC 8689）来承担，而不是靠读取这些关键字来推断。

参考链接