← RFC Reference

RFC 1869 – SMTP 服务扩展 (ESMTP)

为什么存在这个RFC

原始SMTP协议（RFC 821, 1982）没有添加新功能的机制。客户端无法发现服务器支持什么，服务器也无法通告功能。每个扩展都需要一个新的、不兼容的协议版本。

1995年发布的RFC 1869通过定义SMTP扩展的通用框架解决了这个问题。它引入了EHLO命令（扩展HELLO）作为HELO的替代品。当客户端发送EHLO时，服务器用一列它支持的扩展来响应。客户端然后可以使用双方都理解的任何扩展。

这个框架如此基础，以至于后来被直接纳入了RFC 5321中的基础SMTP规范。如今几乎每个SMTP会话都使用ESMTP——纯HELO实际上已过时。

工作原理

1. 客户端连接并接收服务器的问候横幅。
2. 客户端发送EHLO client.example.com（而不是旧的HELO）。
3. 服务器用250及其主机名响应，然后每行一个扩展关键字。除了最后一行使用250 （最终），其他行都使用250-（继续）。
4. 客户端检查扩展列表，仅使用服务器通告的功能。
5. 如果服务器不理解EHLO（当今极其罕见），它返回500错误，客户端回退到HELO。

SMTP示例

典型的ESMTP能力协商：

关键技术细节

扩展注册表

ESMTP扩展向IANA注册。每个扩展定义一个关键字（例如STARTTLS、AUTH、PIPELINING）和可选参数。电子邮件最重要的扩展：

EHLO vs. HELO

HELO是1982年的原始SMTP问候。它不提供能力发现。EHLO是严格的超集：它执行相同的问候功能，但也触发能力列表。服务器必须支持两者，但客户端应始终首先尝试EHLO，仅在EHLO被拒绝时回退到HELO。

状态变化后重新EHLO

能力列表可在会话期间改变。在STARTTLS握手后，客户端必须发送新的EHLO，因为服务器可能在加密连接上通告不同的扩展（例如，AUTH通常仅在TLS后可用）。在RSET后，能力列表保持有效。

扩展参数

某些扩展在EHLO响应行上包括参数。例如，SIZE 52428800声明50 MB限制，AUTH PLAIN LOGIN列出可用的身份验证机制。扩展还可以向MAIL FROM和RCPT TO命令添加参数，如MAIL FROM:<user@example.com> SIZE=1048576。

常见错误

• 使用HELO而不是EHLO。某些遗留应用仍然发送HELO。这会禁用所有SMTP扩展，包括身份验证和加密。始终使用EHLO。
• 不检查EHLO响应。盲目使用扩展而不验证服务器是否通告它们的客户端会收到错误。始终在使用任何扩展前解析能力列表。
• 跨会话缓存功能。服务器支持的扩展可能在连接间改变。始终为每个新连接执行新鲜的EHLO。
• 忘记在STARTTLS后重新EHLO。升级到TLS后，前TLS能力列表无效。必须执行新的EHLO以获取更新的功能。
• 发送无效的EHLO主机名。EHLO的参数应该是你的服务器的FQDN，或者如果没有主机名可用，一个地址字面量如[192.0.2.1]。发送空的或虚假的主机名可能导致拒绝。
• 忽视EHLO域的安全性。接收服务器不应该为身份验证信任EHLO主机名——它是自我报告的且容易伪造的。改用SPF、DKIM和DMARC。

可投递性影响

• ESMTP是现代电子邮件所必需的。没有EHLO，你无法使用STARTTLS、AUTH、PIPELINING或任何其他扩展。仅说HELO的客户端被大多数邮件服务器视为可疑。
• 扩展支持表明合法性。通告并正确实现标准扩展（ENHANCEDSTATUSCODES、PIPELINING、SIZE）的服务器被视为配置良好。缺少或损坏的扩展支持可能在垃圾邮件过滤器中触发负面评分。
• EHLO主机名对声誉很重要。虽然EHLO主机名未被身份验证，许多垃圾邮件过滤器检查它在DNS中是否解析以及是否与连接IP的反向DNS匹配。不匹配会增加垃圾邮件评分。
• SIZE声明防止浪费带宽。当服务器通告其大小限制时，客户端可以避免发送会在完整数据传输后被拒绝的超大消息。这提高了投递效率。

Related RFCs