test

Sun Java System Messaging Server 6.3 管理指南

26.3.8 郵件迴圈

如果 MTA 偵測到郵件正在進行迴圈，則郵件將被劃分為 .HELD 檔案。請參閱26.3.8.1 診斷和清除 .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: 位址。這可導致郵件迴圈。解決方案是修正不能正確處理通知郵件的郵件傳送系統。

26.3.8.1 診斷和清除 .HELD 郵件

如果 MTA 偵測出與遞送郵件有關的嚴重問題，郵件會儲存在尾碼為 .HELD 的檔案中，檔案位在 /msg-svr-base/data/queue/channel。例如：


% ls 
ZZ0HXZ00G0EBRBCP.HELD
ZZ0HY200C0O6LGHU.HELD
ZZ0HYA006LP66O3H.HELD
ZZ0HZ7003EOQSE37.HELD

.HELD files can occur due to three major reasons:

由於迴圈造成郵件 .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 channel 或 imsimta run channel。

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

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

由於使用者或網域 hold 狀態的 .HELD 郵件

。使用者或網域 hold 狀態的 .HELD (並且只有這類因素造成的郵件 .HELD) 通常會儲存在暫停通道的佇列區域。這表示，在暫停通道的佇列區域中，.HELD 郵件可視為由於使用者或網域狀態造成的 .HELD。

由於可疑特徵的郵件 .HELD

由於某些可疑特徵造成的郵件 .HELD 當然會顯示該特徵。特徵可以是站台選擇顯示可疑特徵的任何項目。MTA 管理員應持續注意這些配置選擇和動作。然而，如果您不是此 MTA 的唯一或原始管理員，則檢查 MTA 配置中任何已配置的 holdlimit 通道關鍵字使用方式 (12.5.9 多位址延伸)、MTA 對映檔中位址式 *_ACCESS 對映表的任何 $H 旗標使用方式，或者在任何系統「篩選」檔案 (系統層級 imta.filter 檔案，或任何透過 sourcefilter 或 destinationfilter 通道配置和命名的通道層級「篩選」篩選器；請參閱12.12.4 指定電子信箱篩選器檔案位置) 中任何 hold 作業的使用方式；然後詢問其他任何 MTA 管理員最近可能曾經手動執行的任何手動指令行訊息暫停 (例如，透過 imsimta qm clean 指令)。另請注意，應用「篩選」篩選器 hold 動作時，不論是從系統「篩選」篩選器或從使用者的個人「篩選」篩選器，都可選擇記錄；如需更多資訊，請參閱 LOG_FILTER 全域選項 (「Sun Java System Messaging Server 6.3 Administration Reference」中的「hold」 的 「Sun Java System Messaging Server 6.3 Administration Reference」中的「Option File Format and Available Options」)。