郵件迴圈

如果 MTA 偵測到郵件正在進行迴圈，則郵件將被劃分為 .HELD 檔案。請參閱診斷和清除 .HELD 郵件。某些情況可導致 MTA 無法偵測到的郵件迴圈。

第一步要確定郵件迴圈的原因。您應查看問題郵件檔案的副本 (當問題郵件檔案位於 MTA 佇列區域中時)、與問題郵件相關的 MTA 郵件記錄項目 (如果您已在 MTA 配置檔案中為有問題通道啟用 logging 通道關鍵字) 以及有問題通道的 MTA 通道除錯記錄檔。確定問題郵件的 From: 和 To: 位址、查看 Received: 標頭行以及查看郵件結構 (郵件內容的封裝類型)，均有助於指出您遇到的郵件迴圈情況的類型。

一些較常見的情況包括：

1. Postmaster 位址已損壞。

   MTA 要求 postmaster 位址是可接收電子郵件的有效位址。如果傳送至 Postmaster 的郵件出現迴圈，請檢查您的配置是否具有指向可接收郵件的帳號的正確 Postmaster 位址。

2. 刪除 Received: 標頭行會阻止 MTA 偵測到郵件迴圈。

   一般的郵件迴圈偵測基於 Received: 標頭行。如果 Received: 標頭行被刪除 (在 MTA 系統本身上被明確刪除或者在諸如防火牆之類的其他系統上被刪除)，就會干擾郵件迴圈的正確偵測。在這些情形中，請檢查是否出現不想要的 Received: 標頭行被刪除情況。此外，請查明郵件迴圈的根本原因。可能的原因包括：系統名稱的指定有問題或系統未被配置為辨識其自身名稱的變體、DNS 問題、存在問題的系統上沒有權威性的定址資訊，或者使用者位址轉寄錯誤。

3. 其他郵件傳送系統對通知郵件的錯誤處理正在產生重新封裝的郵件以回應通知郵件。

   網際網路標準要求通知郵件 (正在遞送郵件或退回郵件的報告) 具有空的訊息封 From: 位址以防止郵件迴圈。但是，某些郵件傳送系統不能正確處理此類通知郵件。當轉寄或退回通知郵件時，這些郵件傳送系統可能會插入新的訊息封 From: 位址。這可導致郵件迴圈。解決方案是修正不能正確處理通知郵件的郵件傳送系統。

診斷和清除 .HELD 郵件

如果 MTA 偵測到郵件在伺服器之間或通道之間往复傳送，則傳送停止且郵件被儲存在 /msg_svr_base/data/queue/channel 中具有後綴 .HELD 的檔案中。通常，郵件迴圈出現的原因是每個伺服器或通道均認為另一個伺服器或通道負責遞送郵件。

例如，一般使用者可設定一個選項以將兩個獨立郵件主機上的郵件相互轉寄。在其 sesta.com 帳號上，一般使用者將郵件轉寄至他的 varrius.com 帳號。然後，在忘記已啟用此設定的情況下，他又在 varrius.com 帳號上設定目標為 sesta.com 帳號的郵件轉寄。

如果 MTA 配置錯誤，也會出現迴圈。例如，MTA 主機 X 認為 mail.sesta.com 的郵件應由主機 Y 處理。然而，主機 Y 認為主機 X 應處理 mail.sesta.com 的郵件；結果，主機 Y 將郵件傳回至主機 X。

在這些情況下，郵件會被 MTA 忽略，並不再嘗試進一步遞送。當出現此類問題時，請查看郵件的標頭行以確定退回郵件的伺服器或通道。依需要修正項目。

您也可透過執行 imsimta qm release 或以下步驟重試 .HELD 郵件︰

1. 將 .HELD 副檔名重新命名為任意 2 位數數字 (00 除外)。例如，將 .HELD 重新命名為 .06。

   ---

   備註 –

   重新命名 .HELD 檔案之前，請確定郵件已停止迴圈。

   ---

2. 執行 imsimta cache -sync。執行此指令將更新快取記憶體。

3. 執行 imsimta submit channel 或 imsimta run channel。

可能必須多次執行這些步驟，原因是由於 Received: 標頭行的累積而使郵件可能被再次標記為 .HELD 。