SMTP 的哪些实现通常处理邮件数据以响应 DATA 之后的 RSET？

Posted 2023-04-13

【中文标题】SMTP 的哪些实现通常处理邮件数据以响应 DATA 之后的 RSET？

【英文标题】：What implementations of SMTP typically do with the mail data in response to RSET after DATA?

【发布时间】：2017-03-18 11:42:25

【问题描述】：

这是我从 RFC 5321 中收集到的内容：

4.1.1.5。重置（RSET）

此命令指定当前邮件事务将被中止。必须丢弃所有存储的发件人、收件人、和邮件数据，并清除所有缓冲区和状态表。接收者必须发送一个“250 OK”回复到一个不带参数的 RSET 命令。客户端可以随时发出重置命令。 如果在 EHLO 之后立即发出，在会话中发出 EHLO 之前，在发送并确认数据结束指示符之后，它实际上等同于 NOOP（即，它没有效果） ，或在 QUIT 之前。

重点是我的。这表示如果我们在数据结束指示符“.”之后收到 RSET，但在我们发送确认之前，那么我们必须丢弃当前正在传递的消息内容。这似乎不切实际。此外，服务器可以很容易地表现得好像它在发送确认后收到了 RSET - 客户端将无法知道。试图知道通常会做什么，我发现这个讨论 https://www.ietf.org/mail-archive/web/ietf-smtp/current/msg00946.html 他们说：

Under a RFC5321 compliant "No Quit/Mail" cancellation implementation, after
completing the DATA state, the server is waiting for a pending RSET, MAIL
or QUIT command:

    QUIT - complete transaction, if any
    MAIL - complete transaction, if any
          perform a "reset"
    RSET - cancel any pending DATA transaction delivery,
          perform a "reset"
    drop - cancel any pending DATA transaction delivery

We added this support in 2008 as a local policy option (EnableNoQuitCancel)
which will alter your SMTP state flow, your optimization and now you MUST 
follow RSET vs QUIT/MAIL correctly. RSET (after DATA) aborts the
transaction, QUIT/MAIL (after DATA) does not. RSET is not an NOOP at this 
point.

规范说丢弃是必须的。然而，上述摘录表明在实践中它被解释为 MAY。我可以查看已知的 SMTP/LMTP 实现的代码，例如 Dovecot，但也许有人已经对其进行了审查，这样可以节省我的时间。

【参考方案1】：

文本显示“数据结束指示符已发送并确认”，这表明客户端已收到服务器对DATA 命令的响应。由于基本协议不支持命令流水线，我不认为在DATA 之后但在服务器响应之前发送任何内容（在终止DATA 的点之后但在您收到来自服务器的回复之前）是好的 -定义的行为。

就我个人而言，我想不出比“假装没有发生”更合理的服务器行为。

【讨论】：

问题是关于服务器的：服务器是否应该丢弃它已经收到、开始投递但尚未确认的邮件数据。是的，以服务器的名义，我打算假装在确认之前从未发生过 RSET。更重要的是，我打算在开始处理之前确认，因为在它不再真正在我手中之后 - 我只是将数据传递给我无法控制的第三方。

我稍微改变了措辞，使这个观点中立。我什至没有意识到对客户有偏见。我的意思是一个通用的“你”，非常有效的被动语态，但我现在明白这不是很清楚了。感谢您的反馈！

“在 DATA 命令之后”是什么意思？通常，这意味着在 354 OK 之后，在 DATA 之后返回。在您的回答中，它必须表示数据指示器结束后，点单独在一条线上。我同意，在 ".\r\n" 之后但在确认之前发送任何内容，即回复，不应被视为明确定义的行为。但是，我怀疑，如果发生这种情况，那不是客户的选择。可能存在传输问题和响应延迟，并且客户端不知道该怎么做。因此，它会重置并再次尝试。如果您可以使您的回答不那么模棱两可，我会接受。

【参考方案2】：

答案在这里：https://www.rfc-editor.org/rfc/rfc1047。他们基本上说您可以在开始处理之前确认，实际上建议您这样做。这并不违反 RFC 5321。当然，关于这个问题的更多信息会很有用，但我对 rfc1047 很满意。