RFC 4954《SMTP 服务扩展：认证》中文导读

IETF · RFC 4954 · 标准跟踪（Standards Track） · 2007 年 7 月 · 废止 RFC 2554 · 更新 RFC 3463

非官方中文导读声明：本页为 IETF RFC 4954《SMTP Service Extension for Authentication》 的非官方中文技术导读，按原文章节顺序梳理规范要点，并非逐字全文翻译；任何规范性判断均以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc4954.txt。

1. 定位：把 SASL 装进 SMTP

RFC 4954 定义了 SMTP 的认证服务扩展，允许客户端向服务端声明一种认证机制、完成一次认证协议交换，并可选地为本会话后续交互协商出一层安全层。它本质上是 SASL（简单认证与安全层）在 SMTP 协议上的剖面，废止了 RFC 2554，同时更新了 RFC 3463 的增强状态码集合。

这个扩展是现代“邮件提交”（Submission）场景的基石：用户代理向自己的提交服务器投递邮件时，靠它证明自己是该服务的合法用户，服务器才据此允许中继。

2. AUTH 命令的形式与约束

AUTH mechanism [initial-response]

第一个参数是 SASL 机制名；可选的第二个参数是初始客户端响应，若存在则必须按 base64 编码，或为单个 =（表示零长度初始响应）。使用初始响应可以省掉一次往返，但如果加上它会让命令超出 SMTP 的行长限制，客户端就不得使用该参数。

两条硬性限制值得实现者注意：

若客户端请求的机制无效（不被支持，或要求先有加密层），服务端以 504 拒绝；支持增强状态码时应当返回 5.5.4。

3. 挑战—响应交换

SASL 交换由一系列服务端挑战与客户端响应组成，具体内容由所选机制决定。在 SMTP 上的编码约定是：

认证成功后，若所选机制协商出了安全层，则该层在服务端发出成功应答的 CRLF 之后、客户端在收到成功应答之后立即生效；随后双方必须像 STARTTLS 一样丢弃此前的协议状态，客户端必须重新发送 EHLO。

4. 状态码对照

规范集中列出了本扩展相关的基本码与增强码组合，实现应当尽量返回增强码以便客户端做精确处置：

回复码增强码含义与客户端处置
2352.7.0认证成功。
4324.7.12需要口令迁移；通常先用 PLAIN 认证一次，之后所选机制即可正常工作。
4544.7.0服务端临时故障导致认证失败。客户端不应当再次向用户索要口令，而应提示服务端故障。
5005.5.6认证交换的某一行过长，超出当前机制可用的缓冲区。
5305.7.0需要先认证。除 AUTH、EHLO、HELO、NOOP、RSET、QUIT 外的命令在策略要求认证而当前未认证时应当返回它。
5345.7.9所选机制强度低于服务端对该用户的策略要求；客户端应当换用更强的机制重试。
5355.7.8凭据无效或不足；客户端应当请用户重新输入凭据。
5385.7.11所选机制要求底层连接已加密。此码仅作历史记录保留，现代实现在缺少足够强度加密层时不应当通告该机制。

5. MAIL FROM 的 AUTH 参数

扩展还为 MAIL FROM 命令增加了一个 AUTH 参数，用于把“这封邮件在上游是由谁认证提交的”这一信息随邮件向下游传递。当提交方身份不可信或不可知时，参数值使用 <>。

MAIL FROM: AUTH=
MAIL FROM: AUTH=<>

服务端只有在信任客户端所声明的身份时才应当接受并转发该值；不信任时必须把它替换为 <>，以免伪造身份沿链路扩散。

6. 安全考量与部署要点

规范专门补充了在 TLS 之上使用 SASL PLAIN 的附加要求：明文类机制把口令直接暴露给服务端与链路，因此只应在已建立足够强度的加密层之后使用；服务端在未加密时不应当通告这类机制。

此外，服务端通告的机制列表本身可能被主动攻击者篡改（降级攻击）——若客户端在明文阶段读取机制列表、在加密后不重新读取，就可能被诱导使用弱机制。这正是握手后必须重发 EHLO、重新获取能力列表的原因。

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