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

標準 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 記錄檔將在以下這些情況下建立︰

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

如需有關對通道主程式和從屬程式進行除錯的更多資訊，請參閱「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」。

啟動和停止個別通道

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

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

步驟

使用 imsimta qm stop 指令停止特定通道。這樣做可讓您不必停止 Job Controller，也不必重新編譯配置。在以下範例中，會停止 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 2005Q4 Administration Reference」中的「imsimta qm」。

停止來自特定網域或 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$ can't$ connect$ now

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

MTA 疑難排解範例

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

備註 –

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

識別郵件路徑中的通道

透過識別哪些通道位於郵件路徑中，您可以將 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 (移出佇列) 記錄以確定郵件的路徑。請參閱瞭解 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，以提供充足的除錯資訊。

將 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 伺服器。

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

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

當郵件進入通道時，如果已使用 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. 建議您每次擷取並複製郵件時，對郵件的副檔名進行編號以識別郵件處理的次序。

繼續在通道中進行郵件處理，並在郵件路徑的下一個目標通道中形成佇列。若要如此，請使用 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。

複製完郵件和記錄檔後，請移除除錯選項。
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 值應符合郵件 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，您需要重複整個疑難排解程序 (請參閱識別郵件路徑中的通道、手動啟動和停止通道以收集資料和本小節)。如果另一 MTA 未在您的管理之下，則報告此問題的使用者應與該特定網站聯絡。