test

Sun Java System Messaging Server 6 2005Q4 管理指南

第 22 章 MTA 疑難排解

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

相關主題「監視程序」，可在第 23 章, 監視 Messaging Server中找到

備註 –

閱讀本章之前，您應查閱本指南中的第 5 至 10 章，以及「Sun Java System Messaging Server Administration Reference」中關於 MTA 配置和指令行公用程式的章節。

疑難排解簡介

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

本章將在其後幾節中說明這些問題。

標準 MTA 疑難排解程序

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

檢查 MTA 配置

透過使用 imsimta test -rewrite 公用程式測試您的位址配置。使用此公用程式，您可以測試 MTA 的位址重寫和通道對映，而無需實際傳送郵件。請參閱「Sun Java System Messaging Server 6 2005Q4 Administration Reference」中的第 2 章「Message Transfer Agent Command-line Utilities」中的 MTA 指令行公用程式，以取得更多資訊。

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

檢查郵件佇列目錄

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

如果 imsimta test -rewrite 輸出表面上正確，則請檢查郵件是否實際置於 MTA 郵件佇列子目錄中。若要執行此作業，請啟用郵件記錄 (如需有關 MTA 記錄的更多資訊，請參閱目錄 /msg_svr_base/log/ 中的管理 MTA 郵件和連線記錄。您可以透過郵件 ID 追蹤特定郵件，以確保此特定郵件被放置在 MTA 郵件佇列子目錄中。如果您無法找到此郵件，則可能是檔案磁碟空間或目錄許可權出現問題。

檢查重要檔案的所有權

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


/msg_svr_base/data/queue/
/msg_svr_base/log
/tmp

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


ls -l -p -d /opt/SUNWmsgsr/data/queue
drwx------ 6 inetuser bin 512 Feb 7 09:32 /opt/SUNWmsgsr/data/queue

ls -l -p -d /opt/SUNWmsgsr/log/imta
drwx------ 2 inetuser bin 1536 Mar 10 09:00 /opt/SUNWmsgsr/log/imta

ls -l -p -d /opt/SUNWmsgsr/imta/tmp
drwx------ 2 inetuser bin 512 Feb 7 10:00 /opt/SUNWmsgsr/imta/tmp

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

ls -l -p -R /opt/SUNWmsgsr/data/queue

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

MTA 工作控制器處理 MTA 處理工作 (包括大多數外寄 [主] 通道工作) 的執行。

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

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


# imsimta process
USER      PID S VSZ    RSS   STIME    TIME     COMMAND
inetuser 9567 S 18416 9368  02:00:02  0:00  /opt/SUNWmsgsr/lib/tcp_smtp_server
inetuser 6573 S 18112 5720  Jul_13    0:00  /opt/SUNWmsgsr/lib/job_controller
inetuser 9568 S 18416 9432  02:00:02  0:00  /opt/SUNWmsgsr/lib/tcp_smtp_server
inetuser 6574 S 17848 5328  Jul_13    0:00  /opt/SUNWmsgsr/lib/dispatcher

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

如需有關 imsimta process 的更多資訊，請參閱「Sun Java System Messaging Server 6 2005Q4 Administration Reference」中的「imsimta process」。

如果工作控制器和派送程式均不存在，您應查閱 /msg_svr_base/data/log 中的 dispatcher.log-* 或 job_controller.log-* 檔案

如果記錄檔不存在或並未指示錯誤，則透過使用 start-msg 指令啟動程序。如需更多資訊，請參閱「Sun Java System Messaging Server 6 2005Q4 Administration Reference」中的「start-msg」 MTA 指令行公用程式。

備註 –

當您執行 imsimta process 時，不會看到派送程式或工作控制器的多個實例，除非系統在執行 (exec()) 需要執行的程式之前正在衍生 (fork()) 子程序。然而，此種重複需要的時間區段很短。

檢查記錄檔

如果 MTA 處理工作正確執行，但郵件仍保留在郵件佇列目錄中，則您可以檢查記錄檔查看情況。所有 MTA 記錄檔均建立在目錄 /msg_svr_base/log 中。各種 MTA 處理工作的記錄檔名稱格式在表 22–1 中顯示。

表 22–1 MTA 記錄檔

檔案名稱 

記錄檔內容 

channel_master.log- uniqueid

channel 的主程式 (通常為用戶端) 的輸出。

channel_slave.log- uniqueid

channel 的從屬程式 (通常為伺服器) 的輸出。

dispatcher.log-uniqueid

派送程式除錯。無論是否設定派送程式 DEBUG 選項，系統均會建立此記錄。然而，若要取得詳細的除錯資訊，您應將 DEBUG 選項設定為非零值。

imta

出現傳送問題時顯示的 ims-ms 通道錯誤訊息。

job_controller.log-uniqueid

工作控制器記錄。無論是否設定工作控制器 DEBUG 選項，系統均會建立此記錄。然而，若要取得詳細的除錯資訊，您應將 DEBUG 選項設定為非零值。

tcp_smtp_server.log-uniqueid

tcp_smtp_server 的除錯。此記錄中的資訊是針對伺服器的資訊，而非針對郵件的資訊。

return.log-uniqueid

週期性 MTA 郵件退回工作的除錯輸出；如果在 option.dat 中使用 return_debug 選項，則會建立此記錄檔

備註 –

每個記錄檔均使用唯一的 ID (uniqueid) 建立，以避免覆寫同一通道建立的較早記錄。若要尋找特定記錄檔，您可以使用 imsimta view 公用程式。您還可以使用 imsimta purge 指令清除之前的記錄檔。如需更多資訊，請參閱「Sun Java System Messaging Server 6 2005Q4 Administration Reference」中的「imsimta purge」 MTA 指令行公用程式。

channel_master.log- uniqueid 和 channel_slave.log- uniqueid 記錄檔將在以下這些情況下建立︰

如需有關對通道主程式和從屬程式進行除錯的更多資訊，請參閱「Sun Java System Messaging Server Administration Reference」。

手動執行通道程式

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

指令 imsimta submit 將通知 MTA 工作控制器執行通道。如果為有問題的通道啟用了除錯，imsimta submit 將在目錄 /msg_svr_base/log 中建立記錄檔，如表 22–1 中所示。

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

備註 –

為了手動執行通道，Job Controller 必須處於執行狀態。

如需有關語法、選項、參數、imsimta submit 和 imsimta run 指令範例的資訊，請參閱「Sun Java System Messaging Server 6 2005Q4 Administration Reference」中的「Command Descriptions」。

啟動和停止個別通道

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

Procedure為特定通道停止外寄處理 (移出佇列)

步驟

  1. 使用 imsimta qm stop 指令停止特定通道。這樣做可讓您不必停止 Job Controller，也不必重新編譯配置。在以下範例中，會停止 conversion 通道︰

    imsimta qm stop conversion

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

    imsimta qm start conversion

    如需有關 imsimta qm start 和 imsimta qm stop 指令的更多資訊，請參閱「Sun Java System Messaging Server 6 2005Q4 Administration Reference」中的「imsimta qm」。

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

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

ORIG_SEND_ACCESS 

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

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

PORT_ACCESS

    TCP|*|25|IP_address_to_block|*    $N500$ can't$ connect$ now

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

MTA 疑難排解範例

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

備註 –

當您手動執行通過通道的郵件時，Job Controller 必須處於執行狀態。

識別郵件路徑中的通道

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

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

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

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

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

  5. 確定郵件通過的通道。

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

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

    2. 一旦找到郵件 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 程序的不同階段儲存郵件和記錄檔。稍後會將這些檔案用以識別郵件故障點。

Procedure手動啟動和停止通道

步驟

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

  2. 將 slave_debug 和 master_debug 關鍵字增加至目錄 /msg_svr_base/config 下 imta.cnf 檔案中的適當通道中。

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

    2. 將 master_debug 關鍵字增加至傳送郵件且在識別郵件路徑中的通道中被識別的其他通道，將增加至 conversion 和 tcp_intranet 通道。

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

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

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

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

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

      # cp ZZ01K7LXW76T7O9TD0TB.00 ZZ01K7LXW76T7O9TD0TB.KEEP1

      郵件檔案通常存在於與 /msg_svr_base/data/queue/destination_channel /001 相似的目錄中。destination_channel 是郵件傳送的下一個通道 (例如︰tcp_intranet)。如果您要在 destination_channel 目錄中建立子目錄 (如 001、002 等)，請將 subdirs 關鍵字增加至通道。

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

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

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

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

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

  9. 複製完郵件和記錄檔後，請移除除錯選項。

    1. 將 slave_debug 和 master_debug 關鍵字從目錄 /msg_svr_base/config 下 imta.cnf 檔案中的適當通道中移除。

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

    3. 使用 imsimta cnbuild 重新編譯配置。

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

Procedure識別郵件故障點

步驟

  1. 完成啟動和停止通道程式時，您應具有以下檔案，可以使用這些檔案來疑難排解問題︰

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

    2. tcp_local_slave.log-* 檔案

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

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

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

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

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

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

  3. 檢查郵件檔的副本以查看郵件部分在何處被改變或遺漏。

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

  4. 檢查郵件的最終目標。

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

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

常見 MTA 問題和解決方案

本節列出 MTA 配置與作業的常見問題和解決方案。

TLS 問題

如果在 SMTP 對話期間，STARTTLS 指令傳回以下錯誤：

454 4.7.1 TLS library initialization failure

並且如果您已安裝可用於 pop/imap 存取的憑證，請檢查以下內容：

變更保護並安裝憑證之後，您必須執行：


stop-msg dispatcher 
start-msg dispatcher

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

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

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

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

  2. 重新啟動適當的程序 (如 imsimta restart dispatcher)。

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

MTA 可傳送外寄的郵件，但不接收內送的郵件

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

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

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

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


drwxrwxrwt 8 root sys 734 Sep 17 12:14 tmp/
.

還要執行 .SUNWmsgsr.dispatcher.socket 檔案的 ls -l，並確認所有權正確。例如，如果透過 root 建立，則其無法由 inetmail 存取。

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

內送 SMTP 連線逾時

內送 SMTP 連線逾時通常與系統資源及其配置有關。以下技術可用於識別內送 SMTP 連線的逾時原因：

Procedure識別內送 SMTP 連線逾時的原因

步驟

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

  2. 您可以使用的另一項技術是開啟 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 Java System Messaging Server 6.1 
(built May  7 2001))

    如果已連線且接收到 220 大標題，但是其他指令 (如 ehlo 和 mail from) 未禁止回應，則您應執行 imsimta test -rewrite 以確定該配置正確。

  3. 如果 220 大標題的回應時間較長，且正在執行 pstack 指令，則在 SMTP 伺服器上會顯示以下 iii_res* 函數 (這些函數表明正在執行名稱解析查詢)︰


    febe2c04 iii_res_send (fb7f4564, 28, fb7f4de0, 400, fb7f458c, fb7f4564) + 
42c 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 伺服器不必執行不必要的查詢。

  4. 您還可以將 slave_debug 關鍵字置於經由 TCP/IP 郵件 (通常為 tcp_local 和 tcp_intranet) 處理內送 SMTP 的通道上。執行此作業之後，檢查最近的 tcp_local_slave.log-uniqueid 檔案，以識別逾時郵件的所有特定特徵。例如，如果具有眾多收件者的內送郵件逾時，請考量在此通道上使用 expandlimit 關鍵字。

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

郵件未移出佇列

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

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


% nslookup -query=mx xtel.co.uk (Step 1)
            
Server: LOCALHOST
Address: 127.0.0.1

Non-authoritative answer:
XTEL.CO.UK  preference = 10, mail exchanger = nsfnet-relay.ac.uk (Step 2)

% telnet nsfnet-relay.ac.uk 25 (Step 3)
Trying... [128.86.8.6]
telnet: Unable to connect to remote host: Connection refused

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

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

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

    備註 –

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

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

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

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

建立新通道

在某些情況下，遠端網域可能會出現故障，且定址至此伺服器的郵件容量可能很大，從而導致外寄通道佇列被無法傳送的郵件填滿。MTA 嘗試定期重新傳送這些郵件 (使用 backoff 關鍵字配置重試的頻率和次數)，且在一般情況下，無需任何動作。然而，如果太多郵件滯留在佇列中，則其他郵件可能無法及時傳送，因為所有通道正在處理無法傳送的積壓郵件。

在此情況下，您可以重新將這些郵件路由至在其自己的工作控制器池中執行的新通道。這將避免處理的競爭狀態，並允許其他通道傳送郵件。下面對此程序進行說明。我們假設網域名為 siroe.com

Procedure建立新通道

步驟

  1. 建立名為 tcp_siroe-daemon 的新通道並為 pool 關鍵字增加新值。

    通道在 /msg_svr_base/config/imta.cnf 的通道區段中建立。通道應該具有與一般外寄 tcp_* 通道上相同的通道關鍵字。通常為 tcp_local 通道，其處理所有外寄 (網際網路) 流量。由於 siroe.com 在網際網路上無法使用，此為要模擬的通道。新通道可能與以下顯示類似︰

    tcp_siroe smtp nomx single_sys remotehost inner allowswitchchannel     \
dentnonenumeric subdirs 20 maxjobs 7 pool SMTP_SIROE maytlsserver      \
maysaslserver saslswitchchannel tcp_auth missingrecipientpolicy 0      \    
tcp_siroe-daemon

    請注意新關鍵字值對池 SMTP_SIROE。其指定此通道的郵件將僅使用 SMTP_SIROE 池中的電腦資源。另請注意，新通道前後均需要一個空行。

  2. 將兩個重寫規則增加至 imta.cnf 檔案的重寫規則區段，以將為 siroe.com 指定的電子郵件導向至新通道。

    新重寫規則與以下顯示類似︰


    siroe.com     $U%$D@tcp_siroe-daemon
.siroe.com      $U%$H$D@tcp_siroe-daemon

    這些重寫規則會將郵件導向至 siroe.com (包括諸如 host1.siroe.com 或 hostA.host1.siroe.com 的位址)，從而導向至正式主機名稱為 tcp_siroe-daemon 的新通道。這些規則的重寫部分 $U%$D 和 $U%$H$D 保留郵件的原始位址。$U 從原始位址中複製使用者名稱。% 為分隔符號—@ 位於使用者名稱和網域之間。$H 複製式樣中小數點號左側不符合的主機/網域規格部分。$D 複製符合的網域規格部分。

  3. 定義名為 SMTP_SIROE 的新工作控制器池。

    在 /msg_svr_base/config/job_controller.cnf 中，增加以下內容︰


    [POOL=SMTP_SIROE]
job_limit=10

    這將建立名為 SMTP_SIROE 的郵件資源池，允許同時執行最多 10 個工作。請勿在此池定義和其他池定義之間保留任何空行。請參閱工作控制器，以取得有關工作和池的詳細資訊。

  4. 重新啟動 MTA。

    發出指令：imsimta refresh

    其會重新編譯配置並重新啟動工作控制器和派送程式。

    在此範例中，來自內部使用者的大量電子郵件將名為 siroe.com 的特定遠端網站做為目標。出於某種原因，siroe.com 暫時無法接受內送 SMTP 連線，因而無法傳送電子郵件。(此類情況並不罕見。)

    隨著以 siroe.com 為目標的電子郵件不斷傳入，無法傳送的郵件將會填滿外寄通道佇列 (通常為 tcp_local)。MTA 嘗試定期重新傳送這些郵件 (使用 backoff 關鍵字配置重試的頻率和次數)，且在一般情況下，無需任何動作。

    然而，如果太多郵件滯留在佇列中，則其他郵件可能無法及時傳送，因為所有通道都在處理積壓的 siroe.com 郵件。在此情況下，您可能要將 siroe.com 郵件重新路由至在其自己的工作控制器池中執行的新通道 (請參閱工作控制器)。此作業使其他通道可以傳送各自的郵件，而無需佔用 siroe.com 郵件使用的處理資源。請依照下一小節中的說明建立新通道來解決此問題。

MTA 郵件未遞送

除了郵件傳輸問題以外，還有兩個一般問題，會在郵件佇列中產生未處理的郵件︰

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

    1. 若要檢查特定檔案是否位於佇列快取記憶體中，可以使用 imsimta cache -view 公用程式；如果檔案未在佇列快取記憶體中，則需要同步化佇列快取記憶體。

      佇列快取記憶體通常每四小時進行一次同步。如果需要，可以使用指令 imsimta cache -sync 手動重新同步化快取記憶體。同步化之後，通道程式將在處理新郵件後處理原始未處理的郵件。如果要變更預設 (4 小時)，您應透過增加 sync_time= timeperiod (其中，timeperiod 反映同步化佇列快取記憶體的頻率) 來修改目錄 /msg_svr_base/config 中的 job_controller.cnf 檔案。請注意，timeperiod 必須大於 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 channel 以清除積壓的郵件。請務必注意如果積壓的郵件很多 (大於 1000)，則清除此通道可能要很長時間。

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

    2. 如果同步化佇列快取記憶體之後郵件仍未遞送，則您應重新啟動 Job Controller。若要如此，請使用 imsimta restart job_controller 指令。

      重新啟動 Job Controller 將導致磁碟上郵件佇列中郵件資料結構的重新建立。

      注意 – 注意 –

      重新啟動 Job Controller 是迫不得已的步驟，應僅在所有其他方法無效之後方可執行。

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

  2. 由於通道處理程式不能建立其處理記錄檔而無法執行。檢查存取許可權、磁碟空間以及配額。

郵件迴圈

如果 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 。

收到的郵件已編碼

由 MTA 傳送的郵件以編碼格式接收。例如：

Date: Wed, 04 Jul 2001 11:59:56 -0700 (PDT)
From: "Desdemona Vilalobos" <Desdemona@sesta.com> 
To: santosh@varrius.com
Subject: test message with 8bit data 
MIME-Version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-transfer-encoding: QUOTED-PRINTABLE

2=00So are the Bo=F6tes Void and the Coal Sack the same?=

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

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

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

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

伺服器端規則 (SSR) 無效

篩選器由一個或多個要套用至郵件的條件式動作組成。由於篩選器儲存在伺服器上，並在其上進行計算，因此它們經常被稱為伺服器端規則 (SSR)。

本節包括有關以下 SSR 主題的資訊：

另請參閱使用者層級篩選器除錯。

測試您的 SSR 規則


# imsimta test -rewrite -debug -filter user@domain

在輸出中尋找以下資訊：


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

常見語法問題

使用者按下 [傳送電子郵件] 按鈕後回應緩慢

如果使用者在傳送郵件時遇到延遲，可能是由於未充分地計算郵件佇列磁碟的大小而導致磁碟輸入/輸出減少而引起的。當使用者在電子郵件用戶端上按下 [傳送] 按鈕，MTA 不能完全接受郵件接收，直至郵件已在郵件佇列中確定。有關郵件佇列大小的資訊可在「」中找到。

位址的本機部分或接收欄位中的星號

現在，MTA 檢查位址本機部分以及其建構的接收欄位中的 8 位元字元 (而非僅ASCII 字元)，並使用星號將其替代。

一般錯誤訊息

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

備註 –

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

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

mm_init 中的錯誤

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

通常遇到的 mm_init 錯誤包括：

別名不等效. . .

別名檔案項目的右端格式不正確。

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

別名檔案中包含的檔案無法開啟。

找到重複的別名. . .

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

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

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

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

找到重複的對映名稱. . .

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

備註 –

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

對映名稱太長. . .

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

初始化 ch_ facility 時發生錯誤︰編譯的字元集版本不符

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

初始化 ch_ facility 時發生錯誤︰沒有空間. . .

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


imsimta chbuild -noimage -maximum -option
imsimta chbuild

進行此變更之前，請驗證沒有其他內容需要重新編譯或重新啟動。請參閱「Sun Java System Messaging Server 6 2005Q4 Administration Reference」中的「imsimta chbuild」，以取得有關 imsimta chbuild 的更多資訊。

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

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

別名沒有等效位址. . .

別名檔案中的項目缺少右端 (翻譯值)。

通道沒有正式主機名稱. . .

此錯誤表明通道定義區段缺少必要的第二行 (正式主機名稱行)。請參閱「Sun Java System Messaging Server Administration Reference」和第 12 章, 配置通道定義中有關 MTA 配置和指令行公用程式的章節，以取得有關通道定義區段的更多資訊。每個通道定義塊之前與之後均必須有一空白行，但空白行不能存在於通道名稱和通道定義的正式主機名稱行之間。另請注意，MTA 配置檔案的重寫規則部分不允許有空白行。

正式主機名稱太長

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


Original l Channel:
!delivery channel to local /var/mail store
l subdirs 20 viaaliasrequired maxjobs 7 pool LOCAL_POOL
walleroo.pocofronitas.thisnameismuchtoolongandreallymakesnosensebutitisan
example.monkey.gorilla.orangutan.antidisestablismentarianism.newt.salaman
der.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 Java System Messaging Server Administration Reference」中的 MTA 配置章節，以取得有關用法和語法的資訊。

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

已編譯的配置版本不相符

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

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

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

交換空間錯誤

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

以下的錯誤訊息表示缺少交換空間：

jbc_channels: chan_execute [1]: fork failed: Not enough space

您可能會在 Job Controller 記錄檔中看到此錯誤。其他的交換空間錯誤將因您的配置而有所不同。

使用以下指令確定剩餘的交換空間容量，以及已使用的交換空間容量︰

檔案開啟或建立錯誤

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

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

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

非法的主機/網域錯誤

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

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 封包追蹤) 以確定已傳送或已接收的郵件。