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的 SMTP 伺服器，但似乎RFC 2034和RFC 5321衝突，我不知道應該為我的伺服器做什麼。

RFC 5321說伺服器用“ ”MUST回復命令，但根據RFC 2034，它還應該給擴展優先級（“ ”）嗎？它不會違反RFC 5321嗎？250 OK``QUITmust preface the text part of almost all response lines with a status code.``250 2.0.0 OK

首先：伺服器不能回复250 OK而是回復221 OK命令QUIT。

但我認為你誤解了OK這裡的代表什麼，SMTP 標準（不帶副檔名）並不關心狀態碼之後的內容，它是一個愚蠢的標準，在其實施過程中，每個郵件伺服器都是一個開放的中繼。您可以回复，221 Have a nice day並且它仍然符合 RFC 5321。此外，RFC 5321 確實替換並合併了許多舊的東西（參見描述）。

對您來說重要的部分是：

本文件是 Internet 電子郵件傳輸基本協議的規範。它整合、更新和澄清了幾個以前的文件，使它們中的大部分文件全部或部分過時。它涵蓋了當代 Internet 的 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（和一般的電子郵件）是一個科學怪人，它沒有被完全替換的唯一原因是廣泛使用。為一個本質上已經超過 30 年的標準提供這種向後兼容性在 21 世紀簡直是荒謬的。

為了讓您更加安心：

2.2.3。擴展的特殊問題

允許更改相當基本的 SMTP 操作屬性的擴展。必須在該上下文中理解本文件其他部分中的文本。特別是，擴展可以改變第 4.5.3 節中指定的最小限制，可以改變上面提到的 ASCII 字元集要求，或者可以引入一些可選的消息處理模式。

特別是，如果一個擴展暗示傳遞路徑通常支持該擴展的特殊功能，並且中間 SMTP 系統找到不支持所需擴展的下一跳，它可以根據特定的擴展和情況選擇重新排隊消息並稍後嘗試和/或嘗試備用 MX 主機。如果採用此策略，則回退到未擴展格式的超時（如果可用）應該小於退回無法投遞的正常超時（例如，如果正常超時為三天，則在嘗試傳輸之前的重新排隊超時）沒有副檔名的郵件可能是一天）。

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

引用自：https://serverfault.com/questions/992951