Sun Java System Messaging Server 6.3 管理指南

26.2 標準 MTA 疑難排解程序

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

26.2.1 檢查 MTA 配置

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

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

26.2.2 檢查郵件佇列目錄

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

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

26.2.3 檢查重要檔案的所有權

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

msg-svr-base/data/queue/
msg-svr-base/data/log
msg-svr-base/data/tmp

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

ls -l -p -d /opt/SUNWmsgsr/data/queue
drwxr-x---   2 mailsrv  mail 512 Jan  4 16:09 /opt/SUNWmsgsr/data/queue/

ls -l -p -d /opt/SUNWmsgsr/data/log
drwxr-x---   2 mailsrv  mail  3072 Feb 16 12:07 /opt/SUNWmsgsr/data/log/

ls -l -p -d /opt/SUNWmsgsr/data/tmp
drwxr-x---   2 mailsrv  mail   512 Feb 16 12:55 /opt/SUNWmsgsr/data/tmp/

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

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

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

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

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

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

# imsimta process
USER      PID S VSZ    RSS   STIME    TIME     COMMAND
mailsrv 9567 S 18416 9368  02:00:02  0:00  /opt/SUNWmsgsr/lib/tcp_smtp_server
mailsrv 6573 S 18112 5720  Jul_13    0:00  /opt/SUNWmsgsr/lib/job_controller
mailsrv 9568 S 18416 9432  02:00:02  0:00  /opt/SUNWmsgsr/lib/tcp_smtp_server
mailsrv 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.3 Administration Reference」中的「imsimta process」。

您也可以使用 imsimta qm jobs，以逐一通道的方式，列出目前由工作控制器管理的所有使用中和擱置中傳遞處理工作。另外針對各個通道提供其他詳細資訊，包括成功傳遞的郵件檔案數量，以及後續嘗試傳遞時所需的郵件檔案數量。指令語法如下：

jobs [-[no]hosts] [-[no]jobs] [-[no]messages] [channel-name]

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

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

備註 –

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

26.2.5 檢查記錄檔

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

表 26–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 指令清除之前的記錄檔。但請注意，預設會定期執行此指令 (請參閱4.6.2 預先定義的自動作業)。如需更多資訊，請參閱「Sun Java System Messaging Server 6.3 Administration Reference」中的「imsimta purge」 MTA 指令行公用程式。

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

您的目前配置中有錯誤。
master_debug 或 slave_debug 關鍵字在 imta.cnf 檔案中的通道上設定。
如果 mm_debug 在 option.dat 檔案 (位於以下目錄︰/msg-svr-base /config/) 中設定為非零值 (mm_debug > 0)。

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

26.2.6 手動執行通道程式

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

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

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

備註 –

為了手動執行通道，工作控制器必須處於執行狀態。

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

26.2.7 啟動和停止個別通道

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

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

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

imsimta qm stop conversion

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

imsimta qm start conversion

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

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

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

若要停止特定主機或網域名稱的內寄處理，請將以下存取規則加入 MTA 對映檔案 (通常為 /msg-svr-base/config/mappings) 中的 ORIG_SEND_ACCESS 對映表：

ORIG_SEND_ACCESS 

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

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

若要停止特定 IP 位址的內寄處理，請將以下存取規則加入 MTA 對映檔案 (通常為 /msg-svr-base/config/mappings) 中的 PORT_ACCESS 對映表︰

PORT_ACCESS

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

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

26.2.8 MTA 疑難排解範例

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

備註 –

當您手動執行通過通道的郵件時，工作控制器必須處於執行狀態。

26.2.8.1 識別郵件路徑中的通道

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

將 log_message_id=1 增加到目錄 /msg-svr-base/config 內的 option.dat 檔案中。使用此參數，您會在 mail.log_current 檔案中看到郵件 ID: 標頭行。
執行 imsimta cnbuild 以重新編譯配置。
執行 imsimta restart dispatcher 以重新啟動 SMTP 伺服器。
讓一般使用者重新傳送帶郵件部分的郵件。
確定郵件通過的通道。

雖然有不同的方法可識別通道，但建議使用以下方法：
1. 在 UNIX 平台上，使用 grep 指令，在目錄 /msg-svr-base/log 內的 mail.log_current 檔案中搜尋郵件 ID: 標頭行。
2. 一旦找到郵件 ID：標頭行，則請尋找 E (排入佇列) 和 D (移出佇列) 記錄以確定郵件的路徑。請參閱25.3.1 瞭解 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 通道。

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

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

手動啟動和停止通道

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

將 slave_debug 和 master_debug 關鍵字增加至目錄 /msg-svr-base/config 下 imta.cnf 檔案中的適當通道中。
1. 從傳送具有郵件部分的郵件之遠端系統，在傳入通道 (或在初始對話期間將郵件切換至的任一通道) 上使用 slave_debug 關鍵字。在此範例中，slave_debug 關鍵字被增加至 tcp_local 通道。
2. 將 master_debug 關鍵字增加至傳送郵件且在26.2.8.1 識別郵件路徑中的通道中被識別的其他通道，將增加至 conversion 和 tcp_intranet 通道。
3. 執行指令 imsimta restart dispatcher 以重新啟動 SMTP 伺服器。

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

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

當郵件進入通道時，如果已使用 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 等)，請將 destination_channel目錄, 增加 subdirs 關鍵字加入通道。
2. 建議您每次擷取並複製郵件時，對郵件的副檔名進行編號以識別郵件處理的次序。

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

複製並儲存位於目錄 /msg-svr-bas/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。

複製完郵件和記錄檔後，請移除除錯選項。
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 伺服器。

識別郵件故障點

完成啟動和停止通道程式時，應具有以下檔案，可以使用這些檔案來疑難排解問題︰
1. 來自每個通道程式的郵件檔案 (例如︰ZZ01K7LXW76T7O9TD0TB.KEEP1) 的所有副本
2. tcp_local_slave.log-* 檔案
3. 每個目標通道的一組 channel _master.log-* 檔案
4. 顯示郵件路徑的一組 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) 以及 channel_master.log-* 檔案中發生改變，則 MTA 不會改變郵件，郵件部分將在通往其最終目標的路徑中之下一步消失。

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