第 18 章 MTA 疑難排解

本章描述用於對郵件傳送代理程式 (MTA) 進行疑難排解的常用工具、方法以及程序。包含以下各節：


註	閱讀本章之前，您應查閱本指南中的第 5 章至第 10 章，以及「Sun ONE Messaging Server Reference Manual」中的 MTA 配置和指令行公用程式各章。

疑難排解簡介

對 MTA 進行疑難排解的首要步驟之一是確定從何處開始診斷。根據遇到的問題，您可以在日誌檔中尋找錯誤訊息。在其他情況下，您可以檢查所有標準 MTA 程序、查看 MTA 配置或啟動和停止個別通道。無論您使用何種方法，在對 MTA 進行疑難排解時，請考量以下問題：

配置或環境問題 (例如，磁碟空間或配額問題) 是否會阻止郵件的接受？

當郵件進入郵件佇列時，MTA 服務 (例如，派送程式和工作主控台) 是否存在？

在遠端系統上，網路連線或路由問題是否會導致郵件阻塞或錯誤路由？

郵件進入郵件佇列之前或之後是否會出現問題？

標準 MTA 疑難排解程序

本節概述 MTA 的標準疑難排解程序。如果問題未產生錯誤訊息、錯誤訊息未提供充足的診斷資訊，或者您要對 MTA 執行一般良好狀況檢查、測試以及標準維護，請遵循這些程序。

檢查 MTA 配置

使用 imsimta test -rewrite 公用程式測試您的位址配置。您可以使用此公用程式測試 MTA 的位址重寫和通道對映，而無需實際傳送郵件。請參閱「Sun ONE Messaging Server Reference Manual」中的「MTA command-line utilities」一章，以取得更多資訊。

此公用程式通常將顯示要被套用的位址重寫，以及要將郵件佇列到的通道。但是，MTA 配置中的語法錯誤將導致此公用程式發出錯誤訊息。如果輸出並非您所預期的，則可能需要改正您的配置。

檢查郵件佇列目錄

檢查郵件是否存在於 MTA 郵件佇列目錄 (通常為 msg_svr_base/data/queue/) 中。使用指令行公用程式 (如 imsimta qm) 檢查在 MTA 郵件佇列目錄下是否存在預期的郵件檔。如需有關 imsimta qm 的更多資訊，請參閱「Sun ONE Messaging Server Reference Manual」中的「MTA command-line utilities」一章以及 imsimta qm 計數器。

如果 imsimta test -rewrite 輸出看起來是正確的，請檢查郵件實際上是否被放置在 MTA 郵件佇列子目錄中。若要這樣做，請啟用郵件記錄 (如需有關 MTA 記錄的更多資訊，請參閱第 3 部分：服務日誌 (MTA))。然後，您應查看目錄 /msg_svr_base/log/ 中的 mail.log_current 檔案。您可以透過郵件 ID 追蹤特定郵件，以確保此特定郵件被放置在 MTA 郵件佇列子目錄中。如果您無法找到此郵件，則可能是檔案磁碟空間或目錄許可權出現問題。

檢查重要檔案的所有權

當您安裝 Messaging Server 時，您應已選取郵件伺服器使用者帳號 (依預設為 nobody)。此帳號應擁有以下目錄、子目錄以及檔案：

諸如以下 UNIX 系統範例中的指令，可用於檢查這些目錄的保護和所有權：

使用諸如以下 UNIX 系統範例中的指令，檢查 /msg_svr_base/data/queue 中的檔案是否由 MTA 帳號所擁有：

檢查工作主控台和派送程式是否正在執行

MTA 工作主控台處理 MTA 處理工作的執行，包括大多數外送 (主要) 通道工作。

某些 MTA 通道 (如 MTA 的多重執行緒 SMTP 通道) 包括處理進來郵件的常駐伺服器程序。這些伺服器處理通道從屬 (進來) 方向的郵件。MTA 派送程式處理此類 MTA 伺服器的建立。派送程式配置選項控制伺服器的可用性、已建立伺服器的數量以及每個伺服器可處理的連線數量。

若要檢查工作主控台和派送程式是否存在，以及查看 MTA 伺服器和處理工作是否正在執行，請使用指令 imsimta process。在閒置情況下，此指令會啟動 job_controller 和 dispatcher 程序。例如：

如果工作主控台不存在，則 /msg_svr_base/data/queue 目錄中的檔案將得以備份，並且郵件不會被遞送。如果您沒有派送程式，將無法接收任何 SMTP 連線。

如需有關 imsimta process 的更多資訊，請參閱「Sun ONE Messaging Server Reference Manual」。

如果工作主控台和派送程式都不存在，您應在 /msg_svr_base/data/log 中檢查 dispatcher.log-* 或 job_controller.log-* 檔案

如果日誌檔不存在或者未指出錯誤，請使用 msg-start 指令啟動程序。如需更多資訊，請參閱「Sun ONE Messaging Server Reference Manual」中的「MTA command-line utilities」一章。

檢查日誌檔


註	當您執行 imsimta process 時，您不會看到派送程式或工作主控台的多個實例。

如果 MTA 處理工作執行正確但郵件停留在郵件佇列目錄中，您可以檢查日誌檔以查看發生的情況。所有 MTA 日誌檔均在目錄 /msg_svr_base/log 中建立。各種 MTA 處理工作的日誌檔名稱格式在表格 18-1 中顯示。

表格 18-1 MTA 日誌檔
檔案名稱	日誌檔內容
通道_master.log-唯一的 ID	通道之主要程式 (通常為用戶端) 的輸出。
通道_slave.log-唯一的 ID	通道之從屬程式 (通常為伺服器) 的輸出。
dispatcher.log-唯一的 ID	派送程式除錯。無論派送程式 DEBUG 選項是否設定，系統均會建立此日誌。但是，若要取得詳細的除錯資訊，您應將 DEBUG 選項設定為非零值。
imta	遞送出現問題時的 ims-ms 通道錯誤訊息。
job_controller.log-唯一的 ID	工作主控台記錄。無論工作主控台 DEBUG 選項是否設定，系統均會建立此日誌。但是，若要取得詳細的除錯資訊，您應將 DEBUG 選項設定為非零值。
tcp_smtp_server.log-唯一的 ID	tcp_smtp_server 除錯。此日誌中的資訊針對伺服器，而不針對郵件。
return.log-唯一的 ID	週期性 MTA 郵件退回工作的除錯輸出；如果在 option.dat 中使用 return_debug 選項，則會建立此日誌檔。


註	每個日誌檔均使用唯一的 ID (唯一的 ID) 建立，以避免覆寫由同一通道建立的較早日誌。若要尋找特定日誌檔，您可以使用 imsimta view 公用程式。您還可以使用 imsimta purge 指令清除較舊的日誌檔。如需更多資訊，請參閱「Sun ONE Messaging Server Reference Manual」中的「MTA command-line utilities」一章。

通道_master.log-唯一的 ID 和通道_slave.log-唯一的 ID 日誌檔將在以下任一情況下建立：

您的目前配置中有錯誤。

master_debug 或 slave_debug 關鍵字設定在 imta.cnf 檔案中的通道上。

如果在您的 option.dat 檔案 (所在目錄為 /msg_svr_base/config/) 中，mm_debug 設定為非零值 (mm_debug > 0)。

如需有關通道主要程式和從程式除錯的更多資訊，請參閱「Sun ONE Messaging Server Reference Manual」。

手動執行通道程式

當診斷 MTA 遞送問題時，手動執行 MTA 遞送工作十分有用，尤其是在您為一個或多個通道啟用除錯之後。

指令 imsimta submit 將通知 MTA 工作主控台執行通道。如果為有問題的通道啟用了除錯，則 imsimta submit 將在目錄 /msg_svr_base/log 中建立日誌檔，如表格 18-1 中所示。

指令 imsimta run 將為目前作用中程序下的通道執行外送遞送，其輸出將被導向至您的終端機。這可能比提交工作更為方便，尤其是在您懷疑工作提交本身有問題時。


註	為了手動執行通道，工作主控台必須處於執行狀態。

如需有關 imsimta submit 和 imsimta run 指令之語法、選項、參數以及範例的資訊，請參閱「Sun ONE Messaging Server Reference Manual」中的「MTA command-line utilities」一章。

啟動和停止個別通道

在某些情況下，停止和啟動個別通道可能會使郵件佇列問題易於診斷和除錯。停止郵件佇列可讓您檢查已佇列的郵件，以確定是否存在迴圈或垃圾郵件攻擊。

為特定通道停止外送處理 (移出佇列) 的步驟

使用 imsimta qm stop 指令停止特定通道。這樣做可讓您不必停止工作主控台，也不必重新編譯配置。在以下範例中，會停止 conversion 通道：

imsimta qm stop conversion

若要繼續處理，請使用 imsimta qm start 指令重新啟動此通道。在以下範例中，會啟動 conversion 通道：

imsimta qm start conversion

如需有關 imsimta qm start 和 imsimta qm stop 指令的更多資訊，請參閱「Sun ONE Messaging Server Reference Manual」中有關 MTA 指令行公用程式一章。

停止來自特定網域或 IP 位址的內送處理 (加入到通道佇列中) 之步驟

如果您要停止特定網域或 IP 位址的內送郵件處理，同時傳回暫時 SMTP 錯誤至用戶端主機，您可以執行以下程序之一。這樣做，郵件將不會保留在您的系統上。請參閱第 1 部分：對映表。

若要停止特定主機或網域名稱的內送處理，請將以下存取規則新增至 MTA 對映檔案 (通常為 /msg_svr_base/config/mappings) 中的 ORIG_SEND_ACCESS 對映表：

ORIG_SEND_ACCESS

*|*@sesta.com|*|* $X4.2.1|$NHost$ blocked

透過使用此程序，寄件者的遠端 MTA 會將郵件保留在它們的系統上，並且繼續定期重新傳送這些郵件，直至您重新啟動內送處理。

若要停止特定 IP 位址的內送處理，請將以下存取規則新增至 MTA 對映檔案 (通常為 /msg_svr_base/config/mappings) 中的 PORT_ACCESS 對映表：

PORT_ACCESS

TCP|*|25|IP_address_to_block|* $N500$ unable$ to$ \
connect$ at$ this$ time

當您要重新啟動來自該網域或 IP 位址的內送處理時，請確定從對映表中移除這些規則並重新編譯您的配置。此外，您可能要為每個對映表建立唯一的錯誤訊息。這樣做將能夠讓您確定哪個對映表處於使用狀態。

MTA 疑難排解範例

本節說明如何逐步地對特定 MTA 問題進行疑難排解。在此範例中，郵件收件者未收到電子郵件的附件。注意：為了與 MIME 協定術語保持一致，本節中將「附件」稱為「郵件部分」。上述的疑難排解技術用於識別郵件部分在何處消失以及消失的原因 (請參閱標準 MTA 疑難排解程序)。您可以使用以下步驟確定郵件通過 MTA 的路徑。此外，您可以確定郵件部分是在郵件進入郵件佇列之前還是之後消失的。若要這樣做，您需要手動停止並執行通道，並且擷取相關的檔案。

識別郵件路徑中的通道


註	當您手動執行郵件通過通道時，工作主控台必須處於執行狀態。

透過識別哪些通道位於郵件路徑中，您可以將 master_debug 和 slave_debug 關鍵字套用至相應的通道。這些關鍵字會在通道的主要日誌檔和從屬日誌檔中產生除錯輸出；而主除錯資訊和從屬除錯資訊將有助於識別郵件部分消失的位置。

在目錄 /msg_svr_base/config 的 option.dat 檔案中，新增 log_message_id=1。使用此參數，您將在 mail.log_current 檔案中看到郵件 ID: 標頭行。

執行 imsimta cnbuild 以重新編譯配置。

執行 imsimta restart dispatcher 以重新啟動 SMTP 伺服器。

讓一般使用者重新傳送帶郵件部分的郵件。

確定郵件通過的通道。

雖然有不同的方法可識別通道，但建議使用以下方法：

在 UNIX 平台上，使用 grep 指令，在目錄 /msg_svr_base/log 的 mail.log_current 檔案中搜尋郵件 ID: 標頭行。

一旦找到郵件 ID: 標頭行，請尋找 E (形成佇列) 和 D (移出佇列) 記錄以確定郵件的路徑。請參閱 MTA 日誌項目格式，以取得有關記錄項目代碼的更多資訊。請參閱此範例的以下 E 和 D 記錄：

29-Aug-2001 10:39:46.44 tcp_local conversion     E 2 ...

29-Aug-2001 10:39:46.44 conversion tcp_intranet  E 2 ...

29-Aug-2001 10:39:46.44 tcp_intranet             D 2 ...

左側的通道為來源通道，右側的通道為目標通道。在此範例中，E 和 D 記錄表示郵件路徑是從 tcp_local 通道到 conversion 通道，並最後到 tcp_intranet 通道。

手動啟動和停止通道以收集資料

本節描述如何手動啟動和停止通道。請參閱啟動和停止個別通道，以取得更多資訊。透過手動啟動和停止郵件路徑中的通道，您可以在 MTA 程序的不同階段儲存郵件和日誌檔。這些檔案稍後被用於識別郵件故障點。

在目錄 /msg_svr_base/config 的 option.dat 檔案中設定 mm_debug=5，以提供充足的除錯資訊。

在目錄 /msg_svr_base/config 的 imta.cnf 檔案中，將 slave_debug 和 master_debug 關鍵字新增至相應的通道。

從傳送帶郵件部分的郵件之遠端系統，在內送通道 (或在初始對話期間將郵件切換至的任一通道) 上使用 slave_debug 關鍵字。在此範例中，slave_debug 關鍵字被新增至 tcp_local 通道。

將 master_debug 關鍵字新增至郵件通過並在識別郵件路徑中的通道中識別的其他通道。在此範例中，master_debug 關鍵字會被新增至 conversion 和 tcp_intranet 通道。

執行指令 imsimta restart dispatcher 以重新啟動 SMTP 伺服器。

使用 imsimta qm stop 和 imsimta qm start 指令手動啟動和停止特定通道。如需有關使用這些關鍵字的更多資訊，請參閱啟動和停止個別通道。

啟動擷取郵件檔的程序，讓一般使用者重新傳送帶郵件部分的郵件。

當郵件進入通道時，如果已使用 imsimta qm stop 指令停止此通道，則郵件將在此通道中停止。如需更多資訊，請參閱步驟 3。

在您手動執行郵件路徑中的下一個通道之前，複製並重新命名此郵件檔。請參閱以下 UNIX 平台範例：

# cp ZZ01K7LXW76T7O9TD0TB.00 ZZ01K7LXW76T7O9TD0TB.KEEP1

郵件檔通常常駐在類似於 /msg_svr_base/data/queue/目標_通道/001 的目錄中。目標_通道為郵件通過的下一個通道 (例如：tcp_intranet)。如果您要在目標_通道目錄中建立子目錄 (如 001 和 002 等)，請將 subdirs 關鍵字新增至通道。

建議您每次捕獲並複製郵件時，對郵件的副檔名進行編號以識別郵件處理的次序。

繼續在通道中進行郵件處理，並讓郵件在郵件路徑中的下一個目標通道中形成佇列。若要這樣做，請使用 imsimta qm start 指令。

複製並儲存位於目錄 /msg_svr_base/log 中的對應通道日誌檔 (例如：tcp_intranet_master.log-*)。選擇具有您要追蹤郵件之資料的相應日誌檔。確保您複製的檔案符合郵件進入通道時的時間標記以及主旨標頭。在 tcp_intranet_master.log-* 的範例中，您可以將此檔案儲存為 tcp_intranet_master.keep，以使此檔案不被刪除。

重複步驟 5 至 7，直至郵件已到達其最終目標。

您在步驟 7 中複製的日誌檔應與您在步驟 5 中複製的郵件檔相關聯。如果，例如您在遺漏郵件部分的情形下停止了所有通道，則應儲存 conversion_master.log-* 和 tcp_intranet_master.log-* 檔案。您還應儲存來源通道日誌檔 tcp_local_slave.log-*。此外，您還應從每個目標通道儲存一份對應的郵件檔：從 conversion 通道儲存 ZZ01K7LXW76T7O9TD0TB.KEEP1，從 tcp_intranet 通道儲存 ZZ01K7LXW76T7O9TD0TB.KEEP2。

一旦複製完郵件和日誌檔，便請移除除錯選項。

在目錄 /msg_svr_base/config 的 imta.cnf 檔案中，從相應的通道移除 slave_debug 和 master_debug 關鍵字。

在目錄 /msg_svr_base/config 的 option.dat 檔案中，重設 mm_debug=0 並移除 log_message_id=1。

使用 imsimta cnbuild 重新編譯配置。

執行指令 imsimta restart dispatcher 以重新啟動 SMTP 伺服器。

識別郵件故障點

當您完成啟動和停止通道程式時，您應具有以下可用來對問題進行疑難排解的檔案：

來自每個通道程式的郵件檔 (例如：ZZ01K7LXW76T7O9TD0TB.KEEP1) 的所有副本

tcp_local_slave.log-* 檔案

每個目標通道的一組通道_master.log-* 檔案

顯示郵件路徑的一組 mail.log_current 記錄

所有檔案的時間標記和郵件 ID 值應符合 mail.log_current 記錄中的郵件 ID: 標頭行。請注意，當郵件被退回給寄件者時例外；這些退回的郵件將具有不同於原來郵件的郵件 ID 值。

檢查 tcp_local_slave.log-* 檔案，以確定郵件在進入郵件佇列時是否帶郵件部分。

檢查 SMTP 對話和資料，以查看從用戶端機器傳送的內容。

如果郵件部分未顯示在 tcp_local_slave.log-* 檔案中，則問題出現在郵件進入 MTA 之前。結果郵件在不帶郵件部分的情況下形成佇列。如果發生此情況，則問題可能出現在寄件者的遠端 SMTP 伺服器上或寄件者的用戶端機器中。

研究郵件檔的副本，以查看郵件部分在何處被改變或遺漏。

如果有任何郵件檔顯示郵件部分被改變或遺漏，請檢查先前通道的日誌檔。例如，如果進入 tcp_intranet 通道的郵件中的郵件部分被改變或遺漏，您應檢查 conversion_master.log-* 檔案。

檢查郵件的最終目標。

如果郵件部分看上去未在 tcp_local_slave.log、郵件檔 (例如：ZZ01K7LXW76T7O9TD0TB.KEEP1) 以及通道_master.log-* 檔案中發生改變，則 MTA 不會改變郵件，郵件部分是在通往其最終目標的路徑中的下一步消失。

如果最終目標為 ims-ms 通道 (郵件儲存)，則您可以將郵件從伺服器下載至用戶端機器，以確定郵件部分是否在此傳送期間或之後被遺漏。如果目標通道為 tcp_* 通道，則您需要前往郵件路徑中的 MTA。假設此 MTA 為 Messaging Server MTA，則您將需要重複整個疑難排解程序 (請參閱識別郵件路徑中的通道、手動啟動和停止通道以收集資料以及本節)。如果其他 MTA 未在您的管理之下，則報告此問題的使用者應與該特定站點聯絡。

常見 MTA 問題和解決方案

對配置檔案或 MTA 資料庫所作的變更未生效

MTA 可傳送外送的郵件但不接收進來的郵件

TLS 問題

必須設定證書的保護/所有權，以便 mailsrv 帳號可存取檔案

儲存證書的目錄需要設定保護/所有權，以便 mailsrv 帳號可存取此目錄中的檔案。

重新啟動應該有效，但最好完全關機，安裝證書，然後開始備份內容。

對配置檔案或 MTA 資料庫所作的變更未生效

如果對您的配置檔案、對映檔案、轉換檔案、安全檔案、選項檔案或別名檔案所作的變更未生效，請查看您是否已執行以下步驟：

重新編譯配置 (透過執行 imsimta cnbuild)。

重新啟動相應的程序 (如 imsimta restart dispatcher)。

重新建立所有的用戶端連線。

MTA 可傳送外送的郵件但不接收進來的郵件

大多數 MTA 通道依賴從屬程式或通道程式接收進來的郵件。對於 MTA 所支援的某些傳輸協定 (如 TCP/IP 和 UUCP)，您需要確保傳輸協定啟動 MTA 從屬程式，而不是其標準伺服器。將以 MTA SMTPR 伺服器取代原生 sendmail SMTP 伺服器作為 Messaging Server 安裝的一部分執行。請參閱「Sun ONE Messaging Server 安裝指南」，以取得更多資訊。

對於多重執行緒 SMTP 伺服器，SMTP 伺服器的啟動由派送程式控制。如果派送程式被配置為使用的 MIN_PROCS 值大於或等於 SMTP 服務的此項值，則應至少有一個 SMTP 伺服器程序處於執行狀態 (也可能有多個，這取決於 SMTP 服務的 MAX_PROCS 值)。imsimta process 指令可用來檢查 SMTP 伺服器程序的存在。請參閱「Sun ONE Messaging Server Reference Manual」中有關 MTA 指令行公用程式一章，以取得更多資訊。

派送程式 (SMTP 伺服器) 無法啟動

如果派送程式無法啟動，請首先檢查 dispatcher.log-* 以取得相關的錯誤訊息。如果日誌指出建立或存取 /tmp/.SUNWmsgsr.dispatcher.socket 檔案時出現問題，則驗證 /tmp 保護是否被設定為 1777。這將在許可權中顯示如下：

請勿移除 .SUNWmsgsr.dispatcher.file，並且如果遺漏，請勿建立它。派送程式將建立此檔案。如果保護未被設定為 1777，則派送程式將不會啟動或重新啟動，因為它無法建立/存取套接字檔案。此外，可能還會出現與 Messaging Server 不相關的其他問題。

進來的 SMTP 連線逾時

進來的 SMTP 連線逾時通常與系統資源及其分配相關。以下技術可用於識別進來 SMTP 連線的逾時原因。

檢查您允許同時進來的 SMTP 連線的數量。這由 SMTP 服務的 MAX_PROCS 和 MAX_CONNS 派送程式設定控制；允許的同時連線數量為 MAX_PROCS*MAX_CONNS。如果您可以提供系統資源，則在此數量對於您的使用而言太小的情況下可以考量增加此數量。

您可以使用的另一項技術是開啟 TELNET 階段作業。在以下範例中，使用者連線至 127.0.0.1 連接埠 25。一旦連線成功，便會傳回 220 大標題。例如：

telnet 127.0.0.1 25
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is ’^]’.
220 budgie.sesta.com -- Server ESMTP (Sun ONE Messaging Server 5.1 (built May 7 2001))

如果您已連線並收到 220 大標題，但其他指令 (如 ehlo 和 mail from) 未非法回應，則您應執行 imsimta test -rewrite 以確保配置正確。

如果 220 大標題的回應時間較長，並且在 SMTP 伺服器上執行 pstack 指令顯示以下 iii_res* 功能 (這些功能表示正在執行名稱解決方案查找。)：

febe2c04 iii_res_send (fb7f4564, 28, fb7f4de0, 400, fb7f458c, fb7f4564) + 142c
febdfdcc iii_res_query (0, fb7f4564, c, fb7f4de0, 400, 7f) + 254

則主機可能必須進行反向名稱解決方案查找，即使是在常用對 (如 localhost/127.0.0.1) 上。若要防止此類效能下降，您應在 /etc/nsswitch.conf 檔案中重新排列主機的查找次序。若要這樣做，請變更 /etc/nsswitch.conf 檔案中的以下行，從：

hosts:dns nis [NOTFOUND=return] files

變更為：

hosts:files dns nis [NOTFOUND=return]

在 /etc/nsswitch.conf 檔案中進行此變更可提高效能。少數 SMTP 伺服器必須處理郵件，而不是多數 SMTP 伺服器必須執行不必要的查找。

您還可以將 slave_debug 關鍵字放到經由 TCP/IP 郵件 (通常為 tcp_local 和 tcp_intranet) 處理進來 SMTP 的通道上。這樣做之後，檢查最近的 tcp_local_slave.log-唯一的 ID 檔案以識別逾時郵件的所有特殊特徵。例如，如果具有眾多收件者的進來郵件逾時，請考量在此通道上使用 expandlimit 關鍵字。

請記住，如果您的系統超載並且過分延伸，則逾時將難以完全避免。

郵件未移出佇列

在 TCP/IP 遞送期間遇到的錯誤通常是暫時的；MTA 在遇到問題時通常會保留郵件，並定期重試遞送郵件。對於大型網路而言，當其他主機連線工作正常時，在某些主機上出現週期性中斷是很正常的。若要驗證此問題，請檢查日誌檔以取得與遞送嘗試相關的錯誤。您可能會看到諸如「Fatal error from smtp_open.」的錯誤訊息。此類錯誤並非罕見，並且通常與暫時網路問題相關聯。若要對 TCP/IP 網路問題進行除錯，請使用諸如 PING、TRACEROUTE 和 NSLOOKUP 之類的公用程式。

以下範例顯示您可用來查看郵件要在佇列中等待遞送至 xtel.co.uk 的原因之步驟。若要確定郵件未移出佇列的原因，您可以重新建立經由 TCP/IP 遞送 SMTP 郵件的步驟。

使用 NSLOOKUP 公用程式查看此主機存在的 MX 記錄 (如果有)。如果不存在 MX 記錄，則您應嘗試直接連線至此主機。如果確實存在 MX 記錄，則您必須連線至指定的 MX 中繼器。MTA 優先使用 MX 資訊，除非明確配置為不這樣做。另請參閱 TCP/IP MX 記錄支援。

在此範例中，DNS (網域名稱服務) 傳回 xtel.co.uk 的指定 MX 中繼器的名稱。這是 MTA 將實際連線至的主機。如果列出多個 MX 中繼器，則 MTA 將連續嘗試每個 MX 記錄，並且首先嘗試具有最低個人喜好值的記錄。

如果您確實已連線至遠端主機，您應透過對 SMTP 伺服器連接埠 25 使用 TELNET 以檢查此遠端主機是否接受內送 SMTP 連線。



註	如果您在未指定連接埠的情況下使用 TELNET，將發現遠端主機接受一般遠程登入連線。這並不表示它接受 SMTP 連線；許多系統接受一般 TELNET 連線，但拒絕 SMTP 連線，反之亦然。因此，您總是應該對 SMTP 連接埠進行測試。

在前面的範例中，遠端主機拒絕連線至 SMTP 連接埠。這是 MTA 無法遞送郵件的原因。由於遠端主機的配置錯誤，或遠端主機上的某種資源耗盡，連線可能會被拒絕。在此情況下，無法在本地進行操作來解決此問題。通常，您應讓 MTA 繼續重試遞送郵件。

如果您要在未使用 DNS 的 TCP/IP 網路上執行 Messaging Server，您可以略過 (步驟 1) 和 (步驟 2)。作為替代，您可以使用 TELNET 直接存取有問題的主機。注意應使用與 MTA 使用的相同主機名稱。請查看 MTA 的最後嘗試的相關日誌檔，以確定主機名稱。如果您要使用主機檔案，則應確保主機名稱資訊正確。極力建議您使用 DNS，而不是主機名稱。

請注意，如果您在使用互動式測試測試至 TCP/IP 主機的連線時未遇到問題，則問題很可能在 MTA 最後嘗試遞送郵件時便被解決。您可以在相應的通道上再次執行 imsimta submit tcp_channel，以查看郵件是否被移出佇列。

MTA 郵件未遞送

除了郵件傳輸問題，還有兩個可導致郵件佇列中郵件不被處理的常見問題：

佇列快取記憶體與佇列目錄中的郵件不同步。MTA 佇列子目錄中等待遞送的郵件檔被送到記憶體佇列快取記憶體中。當通道程式執行時，它們會查閱此佇列快取記憶體以確定要遞送佇列中的哪些郵件。可能會有這樣的情況：佇列中有郵件檔，但沒有對應的佇列快取記憶體項目。

若要檢查特定檔案是否存在於佇列快取中，您可以使用 imsimta cache -view 公用程式；如果此檔案不在佇列快取記憶體中，則需要對佇列快取記憶體進行同步化。

佇列快取記憶體通常每四小時進行一次同步化。如果需要，您可以使用指令 imsimta cache -sync 手動重新同步化快取記憶體。一旦經過同步化，通道程式將在處理新郵件之後來處理原來未處理的郵件。如果您要變更預設值 (4 小時)，您應修改目錄 /msg_svr_base/config 中的 job_controller.cnf 檔案，方法為新增 sync_time=時間段，其中時間段反映佇列快取記憶體進行同步化的頻率。請注意，時間段必須大於 30 分鐘。在以下範例中，透過將 sync_time=02:00 新增至 job_controller.cnf 的全域預設值區段，將佇列快取記憶體同步化修改為 2 小時：

! VERSION=5.0
!IMTA job controller configuration file
!
!Global defaults
tcp_port=27442
secret=N1Y9[HzQKW
slave_command=NULL
sync_time=02:00

您可以在執行 imsimta cache -sync 之後執行 imsimta submit 通道以清除郵件儲存區。請務必注意，如果郵件儲存區很大 (大於 1000)，則清除此通道可能要很長時間。

如需概括的佇列快取記憶體資訊，請執行 imsimta qm -maint dir -database -total。

如果同步化佇列快取記憶體之後郵件仍未遞送，您應重新啟動工作主控台。若要這樣做，請使用 imsimta restart job_controller 指令。

重新啟動工作主控台將導致磁碟上郵件佇列中郵件資料結構的重新建立。



小心	重新啟動工作主控台是迫不得已的步驟，應僅在所有其他方法已全部用完無效之後方可執行。

請參閱工作主控台，以取得有關工作主控台的更多資訊。

由於通道處理程式不能建立其處理日誌檔，因此無法執行。檢查存取許可權、磁碟空間以及配額。

郵件迴圈

如果 MTA 偵測到某郵件迴圈，則該郵件將被作為 .HELD 檔案放在一邊。請參閱診斷和清除 .HELD 郵件。某些情況可導致 MTA 無法偵測到的郵件迴圈。

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

Postmaster 位址損壞。

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

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

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

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

網際網路標準要求通知郵件 (正在遞送郵件或退回郵件的報告) 具有空的訊息封 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 忽略並不再嘗試進一步遞送。當出現此類問題時，請查看郵件的標頭行以確定退回郵件的伺服器或通道。依需要修正項目。

將 .HELD 副檔名重新命名為 00 以外的任何 2 個數字。例如將 .HELD 重新命名為 .06。



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

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

執行 imsimta submit 通道或 imsimta run 通道。

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

收到的郵件已編碼

當使用 MTA 解碼器指令 imsimta decode 閱讀時，這些郵件會顯示為未編碼的格式。請參閱「Sun ONE Messaging Server Reference Manual」，以取得更多資訊。

RFC 821 規定，SMTP 協定僅允許傳輸 ASCII 字元 (七位元字元集)。事實上，未經協商經由 SMTP 傳輸八位元字元是非法的，並且眾所週知會導致某些 SMTP 伺服器出現各種問題。例如，SMTP 伺服器會進入運算界限迴圈狀態。郵件會被再三傳送。八位元字元會使 SMTP 伺服器當機。最後，八位元字元集會導致無法處理八位元資料的瀏覽器和電子信箱崩潰。

在處理包含八位元資料的郵件時，SMTP 用戶端過去常常只有三種選擇：將郵件作為無法遞送的郵件傳回寄件者、為郵件編碼或直接違反 RFC 821 的規定傳送郵件。但是由於 MIME 和 SMTP 延伸程式的出現，現在已有標準編碼方法，可用來使用 ASCII 字元集為八位元資料編碼。

在前面的範例中，收件者收到 MIME 內容類型為 TEXT/PLAIN 的編碼郵件。遠端 SMTP 伺服器 (MTA SMTP 用戶端向其傳送郵件的伺服器) 不支援傳送八位元資料。由於原來的郵件包含八位元字元，因此 MTA 必須為郵件編碼。

伺服器端規則 (SSR) 無效

過濾器由一個或多個要套用至郵件的條件式動作組成。由於過濾器在伺服器上儲存和評估，因此它們通常被稱為伺服器端規則 (SSR)。

測試您的 SSR 規則

常見語法問題

測試您的 SSR 規則

若要檢查 MTA 的使用者過濾器，請使用以下指令：

# imsimta test -rewrite -debug -filter 使用者@網域

在輸出中，尋找以下資訊：

mmc_open_url called to open ssrf:使用者@ims-ms
URL with quotes stripped:ssrd:使用者@ims-ms
Determined to be a SSRD URL.
Identifier:user@ims-ms-daemon
Filter successfully obtained.

此外，您可以將 slave_debug 關鍵字新增至 tcp_local 通道，以查看如何套用過濾器。結果在 tcp_local_slave.log 檔案中顯示。確定在目錄 /msg_svr_base/config 的 option.dat 檔案中新增 mm_debug=5，以取得足夠的除錯資訊。

如果您要使用 imsimta dirsync 指令，請確保 imsimta dirsync 指令可正確同步化過濾器資訊。若要這樣做，請從目錄 /msg_svr_base 執行以下指令。請確定您是以 Messaging Server 使用者的身份執行指令：

# configutil -l -o service.imta.ssrenabled -v true

OK SET

# configutil | fgrep ssr

local.imta.ssrenabled = yes

service.imta.ssrenabled = true

常見語法問題

如果過濾器有語法問題，請在 tcp_local_slave.log-* 檔案中尋找以下訊息：
Error parsing filter expression:...

如果過濾器正常，則輸出末尾將出現過濾器資訊。

如果過濾器有問題，則輸出末尾將出現以下錯誤：
Address list error -- 4.7.1 Filter syntax error: desdaemona@sesta.com

此外，如果過濾器有問題，則 SMTP RCPT TO 指令將傳回暫時錯誤回應代碼：

RCPT TO:使用者@網域
452 4.7.1 Filter syntax error

一般錯誤訊息

當 MTA 無法啟動時，指令行中會出現一般錯誤訊息。在本節中，將描述與診斷常見的一般錯誤訊息。


註	若要診斷您自己的 MTA 配置，請使用 imsimta test -rewrite -debug 公用程式檢查 MTA 的位址重寫與通道對映程序。使用此公用程式可讓您檢查配置，而無需實際傳送郵件。請參閱檢查 MTA 配置。

MTA 子元件還可能發出未在本章中描述的其他錯誤訊息。您應參閱「Sun ONE Messaging Server Reference Manual」中有關 MTA 指令行公用程式和配置的各章以及第 5 章至第 10 章，以取得有關每個子元件的更多資訊。本節包括以下類型的錯誤：

SMTP 通道中的錯誤：os_smtp_* 錯誤

mm_init 中的錯誤

mm_init 中的錯誤通常表示 MTA 配置問題。如果您執行 imsimta test -rewrite 公用程式，這些錯誤將會顯示。其他公用程式 (如 imsimta cnbuild)、通道、伺服器或瀏覽器也可能會傳回此類錯誤。

別名不等效. . .

無法開啟別名中包括的檔案. . .

發現重複別名. . .

兩個別名檔案項目的左側相同。您需要找到並刪除重複的別名。尋找顯示為 error line #XXX (其中，XXX 為行號) 的錯誤訊息。您可以在該行修正重複的別名。

通道表中的重複主機. . .

此錯誤訊息表示在 MTA 配置中有兩個具有相同法定主機名稱的通道定義。

請注意，您的 MTA 配置檔案 (imta.cnf) 的重寫規則 (上半部分) 中的多餘空白行會導致 MTA 將配置檔案的剩餘部分解譯為通道定義。請確定檔案的第一行不為空白。由於多個重寫規則通常具有相同型樣 (左側)，因此這會導致 MTA 將這些重寫規則解譯為具有非唯一法定主機名稱的通道定義。檢查您的 MTA 配置，以查看是否存在具有重複法定主機名稱的任何通道定義，並查看檔案上半部分 (重寫規則) 是否存在不正確的空白行。

發現重複對映名稱. . .

此訊息表示兩個對映表具有相同的名稱，並且需要移除其中一個重複對映表。但是，對映檔案中的格式化錯誤可能會導致 MTA 將某些內容錯誤解譯為對映表名稱。例如，未正確縮排對映表項目將導致 MTA 認為項目的左側實際為對映表名稱。檢查對映檔案的一般形式，並檢查對映表名稱。

對映名稱太長.. .

此錯誤意味著對映表名稱太長，需要縮短。對映檔案中的格式化錯誤可能會導致 MTA 將某些內容錯誤解譯為對映表名稱。例如，未正確縮排對映表項目將導致 MTA 認為項目的左側實際為對映表名稱。檢查您的對映檔案以及對映表名稱。

初始化 ch_ facility 時出現錯誤：已編譯的字元集版本不匹配


註	空白行應位於前面，並跟隨在帶有對映表名稱的任何行之後。但是，對映表項目之間不應留有空白行。

如果您看到此訊息，則需要透過指令 imsimta chbuild 重新編譯並重新安裝您的已編譯字元集表。請參閱「Sun ONE Messaging Server Reference Manual」，以取得更多資訊。

初始化 ch_ facility 時出現錯誤：沒有空間. . .

此錯誤訊息通常意味著您需要調整 MTA 字元集內部表的大小，然後使用以下指令重新建立已編譯的字元集表：

進行此變更之前，請驗證沒有其他內容需要重新編譯或重新啟動。請參閱「Sun ONE Messaging Server Reference Manual」中的「MTA command-line utilities」一章，以取得有關 imsimta chbuild 的更多資訊。

系統的本地主機別名或本來的名稱太長. . .

此錯誤表示本地主機別名或本來的名稱太長 (通道塊中第二個或後續名稱中的可選右側)。但是，MTA 配置檔案中早先的某些語法錯誤 (例如，重寫規則中的多餘空白行) 可能會導致 MTA 將某些內容錯誤解譯為通道定義。除了檢查配置檔案指出的一行之外，還應檢查此行以上的內容是否存在其他語法錯誤。特別是，如果 MTA 發出此錯誤的行將成為重寫規則，則請務必檢查此行以上是否存在多餘空白行。

別名沒有等效位址. . .

通道沒有法定主機名稱. . .

此錯誤表示通道定義塊遺漏所需的第二行 (法定主機名稱行)。請參閱「Sun ONE Messaging Server Reference Manual 」中有關 MTA 配置和指令行公用程式的各章以及第 10 章「配置通道定義」，以取得有關通道定義塊的更多資訊。每個通道定義塊之前與之後均必須有一空白行，但空白行不能存在於通道名稱和通道定義的法定主機名稱行之間。另請注意，MTA 配置檔案的重寫規則部分不允許有空白行。

法定主機名稱太長

通道的法定主機名稱 (通道定義塊的第二行) 的長度限制為四十個八位元組。如果您要嘗試在通道上使用較長的法定主機名稱，請將其縮短為定位字元名稱，然後使用重寫規則使較長名稱與短的法定主機名稱相符。如果您使用 l (本地) 通道主機名稱，則可能會看到此情形。例如：

Original l Channel:
!delivery channel to local /var/mail store
l subdirs 20 viaaliasrequired maxjobs 7 pool LOCAL_POOL
newt.salamander.lizard.gecko.komododragon.com

Create Place Holder:
!delivery channel to local /var/mail store
l subdirs 20 viaaliasrequired maxjobs 7 pool LOCAL_POOL
newt

Create Rewrite Rule:
newt.salamander.lizard.gecko.komododragon.com $U%$D@newt

請注意，當使用 l (本地) 通道時，您將需要使用反向對映表。請參閱「Sun ONE Messaging Server Reference Manual 」中的「MTA configuration」一章，以取得有關用法和語法的資訊。

MTA 配置檔案中早先的某些語法錯誤 (例如，重寫規則中的多餘空白行) 可能會導致 MTA 將某些內容錯誤解譯為通道定義。這會導致預計的重寫規則被解譯為法定主機名稱。除了檢查配置檔案指出的一行之外，還應檢查此行以上的內容，看是否存在其他語法錯誤。尤其是如果 MTA 發出此錯誤的行預計作為重寫規則，則請確定檢查此行以上是否存在多餘空白行。

已編譯的配置版本不匹配

imsimta cnbuild 公用程式的功能之一是將 MTA 配置資訊編譯為可快速載入的影像。已編譯的格式定義非常嚴格，並且在不同版本的 MTA 之間常常大幅度變更。較小變更可能作為修補程式版次的一部分出現。

當出現此類變更時，內部版本欄位也進行變更，以便偵測到不相容的格式。當偵測到不相容的格式時，MTA 元件將會停止並顯示上述錯誤。此問題的解決方案為，使用指令 imsimta cnbuild 產生新的已編譯的配置。

還可以使用 imsimta restart 指令重新啟動任意常駐 MTA 伺服器程序，以便它們可取得更新的配置資訊。

交換空間錯誤

若要確保作業正確，在您的郵件傳送系統上配置足夠的交換空間十分重要。所需的交換空間容量將因您的配置而有所不同。一般調整建議為，交換空間的容量應至少為主記憶體容量的三倍。

您可能會在工作主控台日誌檔中看到此錯誤。其他的交換空間錯誤將因您的配置而有所不同。

使用以下指令以確定剩下的交換空間以及已使用的交換空間。

Solaris 系統：swap -s (MTA 程序處於忙碌狀態時)、ps -elf 或 tail /var/adm/messages

HP-UX 系統：swapinfo 或 tail /var/adm/syslog/syslog.log

檔案開啟或建立錯誤

為了傳送郵件，MTA 將閱讀配置檔案並在 MTA 郵件佇列目錄中建立郵件檔。配置檔案必須可由 MTA 或根據 MTA 的 SDK 編寫的任何程式讀取。安裝期間，系統會為這些檔案指定適當的許可權。建立配置檔案的 MTA 公用程式和程序也指定許可權。如果檔案由系統管理者或其他具有特權的使用者保護，或者透過某些站點特定的程序保護，則 MTA 可能無法讀取配置檔案。這將導致「檔案開啟」錯誤或不可預料的運作方式。當 imsimta test -rewrite 公用程式讀取配置檔案遇到問題時，它會報告其他資訊。請參閱「Sun ONE Messaging Server Reference Manual」的 MTA 各章中的 imsimta test -rewrite 說明文件。

如果 MTA 似乎可從具有特權的帳號運作，但不可從無特權的帳號運作，則 MTA 表目錄中的檔案許可權可能是問題的原因。檢查配置檔案及其目錄的許可權。請參閱檢查重要檔案的所有權。

「檔案建立」錯誤通常表示在 MTA 郵件佇列目錄中建立郵件檔時出現問題。請參閱檢查郵件佇列目錄以診斷檔案建立問題。

非法的主機/網域錯誤

當透過瀏覽器將位址提供給 MTA 時，您可能會看到此錯誤。或者，此錯誤可能作為錯誤傳回郵件的一部分而被延期並傳回。在這兩種情況下，此錯誤訊息均表示 MTA 無法將郵件遞送至指定的主機。若要確定郵件未被傳送至指定主機的原因，您應遵循以下疑難排解程序：

驗證有問題的位址沒有拼寫錯誤、沒有抄寫錯誤或者沒有使用不再存在的主機或網域名稱。

透過 imsimta test -rewrite 公用程式執行有問題的位址。如果此公用程式還是傳回有關該位址的「非法的主機/網域」錯誤，則 MTA 在 imta.cnf 檔案以及相關檔案中沒有可處理該位址的規則。驗證您已正確配置 MTA、您已正確回答所有的配置問題，並且您已保持配置資訊一直處於最新狀態。

如果 imsimta test -rewrite 未遇到有關位址的錯誤，則 MTA 可確定如何處理位址，但網路傳輸將不會接受該位址。您可以檢查遞送嘗試的相應日誌檔，以取得其他詳細資訊。暫時網路路由或名稱服務錯誤應不會導致傳回錯誤訊息，儘管嚴重配置錯誤的網域名稱伺服器可能會導致這些問題。

如果您在網際網路上，請檢查您是否已正確配置您的 TCP/IP 通道以支援 MX 記錄查找。許多網域位址在網際網路上不可直接存取，而要求您的郵件系統正確解析 MX 項目。如果您在網際網路上並且您的 TCP/IP 被配置為支援 MX 記錄，您應已將 MTA 配置為啟用 MX 支援；請參閱 TCP/IP 連線和 DNS 查找支援 (TCP/IP 連線和 DNS 查找支援)，以取得更多資訊。如果您的 TCP/IP 套裝軟體未配置為支援 MX 記錄查找，則您將無法存取僅針對 MX 的網域。

SMTP 通道中的錯誤：os_smtp_* 錯誤

以下錯誤並不一定是 MTA 錯誤：os_smtp_* 錯誤，例如 os_smtp_open、os_smtp_read 以及 os_smtp_write 錯誤。當 MTA 報告在網路層遇到問題時，會產生這些錯誤。例如，os_smtp_open 錯誤意味著至遠端的網路連線無法開啟。由於定址錯誤或通道配置錯誤，MTA 可能被配置為連線至無效的系統。os_smtp_* 錯誤通常由於 DNS 或網路連線問題而產生，尤其是如果這是先前工作的通道或位址。os_smtp_read 錯誤或 os_smtp_write 錯誤通常表示連線被另一端中斷或由於網路問題而中斷。

網路問題和 DNS 問題在本質上通常是暫時的。您一般不必擔心偶爾的 os_smtp_* 錯誤。但是，如果您經常看到這些錯誤，則可能表示存在潛在的網路問題。

若要取得有關特定 os_smtp_* 錯誤的更多資訊，請在有問題的通道上啟用除錯。研究將顯示嘗試的 SMTP 對話詳細資訊的除錯通道日誌檔。尤其是要查看在 SMTP 對話期間出現網路問題的時間。時間可能會暗示網路或遠端問題的類型。在某些情況下，您可能還需要執行網路級除錯 (例如，TCP/IP 封包追蹤) 以確定已傳送或已接收的郵件。