☰

RFC 5321 要求我的带有增强状态代码服务扩展的 SMTP 服务器回复“250 OK”

tag-icon • tag-icon smtp rfc
RFC 5321 要求我的带有增强状态代码服务扩展的 SMTP 服务器回复“250 OK”

RFC 2034

4.  The Enhanced-Status-Codes service extension

   Servers supporting the Enhanced-Status-Codes extension must preface
   the text part of almost all response lines with a status code. As in
   RFC 1893, the syntax of these status codes is given by the ABNF:

        status-code ::= class "." subject "." detail
        class       ::= "2" / "4" / "5"
        subject     ::= 1*3digit
        detail      ::= 1*3digit

   These codes must appear in all 2xx, 4xx, and 5xx response lines other
   than initial greeting and any response to HELO or EHLO. Note that 3xx
   responses are NOT included in this list.

221 2.0.0 Goodbye

RFC 5321

4.1.1.9.  NOOP (NOOP)

   This command does not affect any parameters or previously entered
   commands.  It specifies no action other than that the receiver send a
   "250 OK" reply.

4.1.1.10.  QUIT (QUIT)

   This command specifies that the receiver MUST send a "221 OK" reply,
   and then close the transmission channel.

我正在运行支持RFC 2034，但似乎RFC 2034和RFC 5321冲突，我不知道该为我的服务器做些什么。

RFC 5321服务器说MUST回复“ 250 OK”作为QUIT命令，但每RFC 2034， 它也是must preface the text part of almost all response lines with a status code.我应该给扩展赋予优先级（“ 250 2.0.0 OK”）吗？这不会违反RFC 5321？

答案1

首先：服务器不能用命令来回复，250 OK而必须用命令221 OK来回复QUIT。

但我认为你误解了OK这里的 代表什么，SMTP 标准（无扩展）不关心状态代码后面的内容，这是一个愚蠢的标准，在其实施期间，每个邮件服务器都是开放中继。你可以回复，它221 Have a nice day仍然符合 RFC 5321。此外，RFC 5321 确实取代并整合了许多旧内容（请参阅描述）。

对你来说最重要的部分是：

本文档是互联网电子邮件传输基本协议的规范。它整合、更新和澄清了几个以前的文档，使其中大部分文档的全部或部分内容过时。它涵盖了当代互联网的 SMTP 扩展机制和最佳实践，但没有提供详细信息 特定扩展。

在您的示例中，就 RFC 5321 而言，221是状态代码，除此之外的所有内容都只是文本。我认为，如果您阅读 RFC5321 的终止部分，就会更加清楚： https://www.rfc-editor.org/rfc/rfc5321#section-3.8

所以 TL;DR:221 2.0.0 Goodbye对于 RFC 5321 来说是完全有效的。

请记住，“扩展”之所以被称为扩展，是因为它们建立在基本标准之上。它们不是替代，而是对基本标准进行补充。

但别担心，SMTP（以及一般的电子邮件）是一个怪兽，它没有被完全取代的唯一原因是用途广泛。在 21 世纪，为一个本质上已有 30 多年历史的标准提供这种向后兼容性简直是荒谬的。

为了让您更加安心：

2.2.3. 扩展的特殊问题

允许使用更改 SMTP 操作基本属性的扩展。必须在该上下文中理解本文档其他部分中的文本。特别是，扩展可以更改第 4.5.3 节中指定的最小限制，可以更改上述 ASCII 字符集要求，或者可以引入一些可选的消息处理模式。

具体来说，如果扩展意味着投递路径通常支持该扩展的特殊功能，而中间 SMTP 系统发现下一跳不支持所需的扩展，则可以根据特定扩展和情况选择重新排队该消息并稍后再试和/或尝试备用 MX 主机。如果采用此策略，则返回到未扩展格式（如果有）的超时时间应小于因无法投递而退回的正常超时时间（例如，如果正常超时时间为三天，则在尝试传输没有扩展的邮件之前的重新排队超时时间可能是一天）。

https://www.rfc-editor.org/rfc/rfc5321#section-2.2.3

相关内容