Sun Java System Messaging Server 6.3 管理指南

由於迴圈造成郵件 .HELD

伺服器或通道之間的郵件彈回被視為迴圈。通常,郵件迴圈出現的原因是每個伺服器或通道均認為另一個伺服器或通道負責遞送郵件。迴圈郵件通常有大量的 *Received: 標頭行。Received: 標頭行會說明郵件迴圈的確切路徑。詳細檢視出現在這類標頭行的主機名稱和任何收件者資訊 (例如 for recipient陳述或 (ORCPT recipient) 註釋)。這類訊息迴圈的其中一個原因是使用者錯誤。

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

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

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

另一個常造成郵件迴圈的原因是,MTA 收到以 MTA 未辨識的網路名稱 (尚未配置進行辨識) 為其中一個自身名稱傳送至 MTA 主機的訊息。解決方案是,將額外的名稱新增至 MTA 辨識為自身名稱的名稱清單。請注意,MTA 判定郵件為迴圈的臨界值可供配置;請參閱 MAX_*RECEIVED_LINES option.dat 選項 (「Sun Java System Messaging Server 6.3 Administration Reference 」中的「Option File Format and Available Options」)。另請注意,MTA 也可供選擇進行配置 (請參閱 HELD_SNDOPR 全域 MTA 選項),以便郵件在超過這類臨界值時強制進 .HELD 狀態的狀況下,產生事件記錄通知。如果有 Received count exceeded; message held. 事件記錄訊息,即可得知發生的事件。

您可以執行「Sun Java System Messaging Server 6.3 Administration Reference」中的「release」,或按照下列步驟,重新傳送 .HELD 郵件。

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


    備註 –

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


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

  3. 執行 imsimta submit channelimsimta run channel

這可能需要多次執行這些步驟,原因是 Received: 標頭行累積,可能使得郵件再次標示為 .HELD。如果問題持續出現,會在與先前相同的通道下重新建立 *.HELD 檔案。如果問題已經解決,郵件會移出佇列進行傳遞。

如果您決定只要刪除郵件,而不要嘗試傳遞郵件,請參閱「Sun Java System Messaging Server 6.3 Administration Reference 」中的「clean」