當你用電子郵件系統傳送自動回復時，你需要注意不要向自動生成的電子郵件傳送回復。最好的情況下，你將獲得無用的投遞失敗訊息。更可能的是，你會得到一個無限的電子郵件迴圈和一個混亂的世界。
事實證明，可靠地檢測自動生成的電子郵件並不總是那麼容易。以下是基於為此編寫的檢測器並使用它掃描大約 100,000 封電子郵件（大量的個人存檔和公司存檔）的觀察結果。
由 RFC 3834 定義。
這是表示你的郵件是自動回復的“官方”標準。如果存在 Auto-Submitted 信頭，並且其值不是 no，你應該不傳送回復。
由微軟定義。
此信頭由微軟 Exchange、Outlook 和其他一些產品使用。許多新聞訂閱等都設定了這個。如果 X-Auto-Response-Suppress 包含 DR（“抑制投遞報告”）、AutoReply（“禁止 OOF 通知以外的自動回復訊息”）或 All，你應該不傳送回復。
由 RFC 2919 定義。
你通常不希望給郵寄清單或新聞訂閱傳送自動回復。幾乎所有的郵寄清單和大多數新聞訂閱都至少設定了其中一個信頭。如果存在這些信頭中的任何一個，你應該不傳送回復。這個信頭的值不重要。
由谷歌定義。
Gmail 使用此信頭識別郵件是否是新聞訂閱，並使用它為這些新聞訂閱的所有者生成統計資訊或報告。如果此信頭存在，你應該不傳送回復。這個信頭的值不重要。
上述方法定義明確（即使有些是非標準的）。不幸的是，有些電子郵件系統不使用它們中的任何一個 :-( 這裡有一些額外的措施。
在 RFC 2076 中沒有真正定義，不鼓勵使用它（但通常會遇到此信頭）。
請注意，不建議檢查是否存在此信頭，因為某些郵件使用 normal 和其他一些（少見的）值（儘管這不常見）。
我的建議是如果其值不區分大小寫地匹配 bulk、auto_reply 或 list，則不傳送回復。
這是我遇到的另外的一些（不常見的）信頭。如果設定了其中一個，我建議不傳送自動回復。大多數郵件也設定了上述信頭之一，但有些沒有（這並不常見）。
X-MSFBL：無法真正找到定義（Microsoft 信頭？），但我只有自動生成的郵件帶有此信頭。X-Loop：在任何地方都沒有真正定義過，有點罕見，但有時有。它通常設定為不應該收到電子郵件的地址，但也會遇到 X-Loop: yes。X-Autoreply：相當罕見，並且似乎總是具有 yes 的值。檢查 From 或 Reply-To 信頭是否包含 noreply、no-reply 或 no_reply（正規表示式：^no.?reply@）。
如果電子郵件只有 HTML 部分，而沒有文字部分，則表明這是一個自動生成的郵件或新聞訂閱。幾乎所有郵件用戶端都設定了文字部分。
許多傳遞失敗訊息並不能真正表明它們是失敗的。一些檢查方法：
From 包含 mailer-daemon 或 Mail Delivery Subsystem許多郵件類庫留下了某種痕跡，大多數常規郵件用戶端使用自己的資料覆蓋它。檢查這個似乎工作得相當可靠。
X-Mailer: Microsoft CDO for Windows 2000：由某些微軟軟體設定；我只能在自動生成的郵件中找到它。是的，在 2015 年它仍然在使用。Message-ID 信頭包含 .JavaMail.：我發現了一些（5 個 50k 大小的）常規訊息，但不是很多；絕大多數（數千封）郵件是新聞訂閱、訂單確認等。^X-Mailer 以 PHP 開頭。這應該會同時看到 X-Mailer: PHP/5.5.0 和 X-Mailer: PHPmailer XXX XXX。與 “JavaMail” 相同。X-Library；似乎只有 Indy 設定了這個。X-Mailer 以 wdcollect 開頭。由一些 Plesk 郵件設定。X-Mailer 以 MIME-tools 開頭。即使遵循上述所有建議，你仍可能會遇到一個避開所有這些檢測的電子郵件程式。這可能非常危險，因為電子郵件系統只是“如果有電子郵件那麼傳送”，就有可能導致無限的電子郵件迴圈。
出於這個原因，我建議你記錄你自動傳送的電子郵件，並將此速率限制為在幾分鐘內最多幾封電子郵件。這將打破迴圈鏈條。
我們使用每五分鐘一封電子郵件的設定，但沒這麼嚴格的設定可能也會運作良好。
具體細節取決於你傳送的郵件型別。這是我們用於自動回復郵件的內容：
Auto-Submitted: auto-repliedX-Auto-Response-Suppress: AllPrecedence: auto_reply你可以傳送電子郵件至 [email protected] 或 建立 GitHub 議題以提交反饋、問題等。