Sun Java System Messaging Server 6 2005Q1 管理指南 |
第 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 Administration Reference」中的「MTA command-line utilities」一章,以取得更多資訊。
此公用程式通常將顯示要被套用的位址重寫,以及要將郵件佇列到的通道。但是,MTA 配置中的語法錯誤將導致此公用程式發出錯誤訊息。如果輸出並非您所預期的,則可能需要改正您的配置。
檢查郵件佇列目錄
檢查郵件是否存在於 MTA 郵件佇列目錄 (通常為 msg_svr_base/data/queue/) 中。使用指令行公用程式 (如 imsimta qm) 檢查在 MTA 郵件佇列目錄下是否存在預期的郵件檔。如需有關 imsimta qm 的更多資訊,請參閱「Sun Java System Messaging Server Administration Reference」中的「MTA command-line utilities」一章以及「imsimta qm 計數器」。
如果 imsimta test -rewrite 輸出看起來是正確的,請檢查郵件實際上是否被放置在 MTA 郵件佇列子目錄中。若要這樣做,請啟用郵件記錄 (如需有關 MTA 記錄的更多資訊,請參閱「管理 MTA 郵件和連線記錄」)。然後,您應查看目錄 /msg_svr_base/log/ 中的 mail.log_current 檔案。您可以透過郵件 ID 追蹤特定郵件,以確保此特定郵件被放置在 MTA 郵件佇列子目錄中。如果您無法找到此郵件,則可能是檔案磁碟空間或目錄許可權出現問題。
檢查重要檔案的所有權
當您安裝 Messaging Server 時,您應已選取郵件伺服器使用者帳號 (依預設為 nobody)。此帳號應擁有以下目錄、子目錄以及檔案:
/msg_svr_base/data/queue/
/msg_svr_base/log/
/tmp諸如以下 UNIX 系統範例中的指令,可用於檢查這些目錄的保護和所有權:
使用諸如以下 UNIX 系統範例中的指令,檢查 /msg_svr_base/data/queue 中的檔案是否由 MTA 帳號所擁有:
檢查工作控制器和派送程式是否正在執行
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 Administration Reference」。
如果工作控制器和派送程式都不存在,您應在 /msg_svr_base/data/log 中檢查 dispatcher.log-* 或 job_controller.log-* 檔案。
如果記錄檔不存在或者未指出錯誤,請使用 msg-start 指令啟動程序。如需更多資訊,請參閱「Sun Java System Messaging Server Administration Reference」中的「MTA command-line utilities」一章。
注意 當您執行 imsimta process 時,不會看到派送程式或工作控制器的多個實例,除非系統在執行 (exec()) 需要執行的程式之前正在衍生 (fork()) 子程序。然而,此種重複所需的時間很短。
檢查記錄檔
如果 MTA 處理工作執行正確但郵件停留在郵件佇列目錄中,您可以檢查記錄檔以查看發生的情況。所有 MTA 記錄檔均在目錄 /msg_svr_base/log 中建立。各種 MTA 處理工作的記錄檔名稱格式在表 22-1 中顯示。
表 22-1 MTA 記錄檔
檔案名稱
記錄檔內容
channel_master.log-uniqueid
通道之主要程式 (通常為用戶端) 的輸出。
channel_slave.log-uniqueid
通道之從屬程式 (通常為伺服器) 的輸出。
dispatcher.log-uniqueid
派送程式除錯。無論派送程式 DEBUG 選項是否設定,系統均會建立此記錄。但是,若要取得詳細的除錯資訊,您應將 DEBUG 選項設定為非零值。
imta
遞送出現問題時的 ims-ms 通道錯誤訊息。
job_controller.log-唯一的 ID
工作控制器記錄。無論工作控制器 DEBUG 選項是否設定,系統均會建立此記錄。但是,若要取得詳細的除錯資訊,您應將 DEBUG 選項設定為非零值。
tcp_smtp_server.log-uniqueid
tcp_smtp_server 除錯。此記錄中的資訊針對伺服器,而不針對郵件。
return.log-uniqueid
週期性 MTA 郵件退回工作的除錯輸出;如果在 option.dat 中使用 return_debug 選項,則會建立此記錄檔
注意 每個記錄檔均使用唯一的 ID (唯一的 ID) 建立,以避免覆寫由同一通道建立的較早記錄。若要尋找特定記錄檔,您可以使用 imsimta view 公用程式。您還可以使用 imsimta purge 指令清除較舊的記錄檔。如需更多資訊,請參閱「Sun Java System Messaging Server Administration Reference」中的「MTA command-line utilities」一章。
通道_master.log-唯一的 ID 和通道_slave.log-唯一的 ID 記錄檔將在以下任一情況下建立:
如需有關通道主要程式和從屬程式除錯的更多資訊,請參閱「Sun Java System Messaging Server Administration Reference」。
手動執行通道程式
當診斷 MTA 遞送問題時,手動執行 MTA 遞送工作十分有用,尤其是在您為一個或多個通道啟用除錯之後。
指令 imsimta submit 將通知 MTA 工作控制器執行通道。如果為有問題的通道啟用了除錯,則 imsimta submit 將在目錄 /msg_svr_base/log 中建立記錄檔,如表 22-1 中所示。
指令 imsimta run 將為目前使用中程序下的通道執行外寄遞送,其輸出將被導向至您的終端機。這可能比提交工作更為方便,尤其是在您懷疑工作提交本身有問題時。
如需有關 imsimta submit 和 imsimta run 指令之語法、選項、參數以及範例的資訊,請參閱「Sun Java System Messaging Server Administration Reference」中的「MTA command-line utilities」一章。
啟動和停止個別通道
在某些情況下,停止和啟動個別通道可能會使郵件佇列問題易於診斷和除錯。停止郵件佇列可讓您檢查已佇列的郵件,以確定是否存在迴圈或垃圾郵件攻擊。
為特定通道停止外寄處理 (移出佇列) 的步驟
如需有關 imsimta qm start 和 imsimta qm stop 指令的更多資訊,請參閱「Sun Java System Messaging Server Administration Reference」中有關 MTA 指令行公用程式一章。
停止來自特定網域或 IP 位址的內送處理 (加入到通道佇列中) 之步驟
如果您要停止特定網域或 IP 位址的內送郵件處理,同時傳回暫時 SMTP 錯誤至用戶端主機,您可以執行以下程序之一。這樣做,郵件將不會保留在您的系統上。請參閱「第 1 部分:對映表」。
當您要重新啟動來自該網域或 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 記錄:
左側的通道為來源通道,右側的通道為目標通道。在此範例中,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。
- 繼續在通道中進行郵件處理,並讓郵件在郵件路徑中的下一個目標通道中形成佇列。若要這樣做,請使用 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。
- 一旦複製完郵件和記錄檔,便請移除除錯選項。
識別郵件故障點
- 當您完成啟動和停止通道程式時,您應具有以下可用來對問題進行疑難排解的檔案:
- 檢查 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 配置與作業的常見問題和解決方案。
TLS 問題
如果在 SMTP 對話期間,STARTTLS 指令傳回以下錯誤:
454 4.7.1 TLS library initialization failure
並且您已安裝可用於 POP/IMAP 存取的憑證,請檢查以下內容:
變更保護並安裝憑證之後,您必須執行:
stop-msg dispatcher
start-msg dispatcher重新啟動應該有效,但最好完全關機,安裝憑證,然後開始備份內容。
對配置檔案或 MTA 資料庫所作的變更未生效
如果對您的配置檔案、對映檔案、轉換檔案、安全檔案、選項檔案或 Alias 檔案所作的變更未生效,請查看您是否已執行以下步驟:
MTA 可傳送外寄的郵件但不接收內送的郵件
大多數 MTA 通道依賴從屬程式或通道程式接收進來的郵件。對於 MTA 所支援的某些傳輸協定 (如 TCP/IP 和 UUCP),您需要確保傳輸協定啟動 MTA 從屬程式,而不是其標準伺服器。將以 MTA SMTPR 伺服器取代原生 sendmail SMTP 伺服器作為 Messaging Server 安裝的一部分執行。請參閱「Sun Java Enterprise System Installation Guide」,以取得更多資訊。
對於多重執行緒 SMTP 伺服器,SMTP 伺服器的啟動由派送程式控制。如果派送程式被配置為使用的 MIN_PROCS 值大於或等於 SMTP 服務的此項值,則應至少有一個 SMTP 伺服器程序處於執行狀態 (也可能有多個,這取決於 SMTP 服務的 MAX_PROCS 值)。imsimta process 指令可用來檢查 SMTP 伺服器程序的存在。請參閱「Sun Java System Messaging Server Administration Reference」中有關 MTA 指令行公用程式一章,以取得更多資訊。
派送程式 (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 連線的逾時原因。
- 檢查您允許同時內送的 SMTP 連線的數量。這由 SMTP 服務的 MAX_PROCS 和 MAX_CONNS 派送程式設定控制;允許的同時連線數量為 MAX_PROCS*MAX_CONNS。如果您可以提供系統資源,則在此數量對於您的使用而言太小的情況下可以考量增加此數量。
- 您可以使用的另一項技術是開啟 TELNET 階段作業。在以下範例中,使用者連線至 127.0.0.1 連接埠 25。一旦連線成功,便會傳回 220 大標題。例如:
如果您已連線並收到 220 大標題,但其他指令 (如 ehlo 和 mail from) 未非法回應,則您應執行 imsimta test -rewrite 以確保配置正確。
- 如果 220 大標題的回應時間較長,並且在 SMTP 伺服器上執行 pstack 指令顯示以下 iii_res* 功能 (這些功能表示正在執行名稱解決方案查詢):
則主機可能必須進行反向名稱解決方案查詢,即使是在常用對 (如 localhost/127.0.0.1) 上。若要防止此類效能下降,您應在 /etc/nsswitch.conf 檔案中重新排列主機的查找次序。若要這樣做,請變更 /etc/nsswitch.conf 檔案中的以下行,從:
變更為:
在 /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 -query=mx xtel.co.uk (步驟 1)
Server: LOCALHOST
Address: 127.0.0.1
Non-authoritative answer:
XTEL.CO.UK preference = 10, mail exchanger = nsfnet-relay.ac.uk (步驟 2)
% telnet nsfnet-relay.ac.uk 25 (步驟 3)
Trying...[128.86.8.6]
telnet:無法連線至遠端主機:連線被拒絕
- 使用 NSLOOKUP 公用程式查看此主機存在的 MX 記錄 (如果有)。如果不存在 MX 記錄,則您應嘗試直接連線至此主機。如果確實存在 MX 記錄,則您必須連線至指定的 MX 轉送器。MTA 優先使用 MX 資訊,除非明確配置為不這樣做。另請參閱「TCP/IP MX 記錄支援」。
- 在此範例中,DNS (網域名稱服務) 傳回 xtel.co.uk 的指定 MX 轉送器的名稱。這是 MTA 將實際連線至的主機。如果列出多個 MX 轉送器,則 MTA 將連續嘗試每個 MX 記錄,並且首先嘗試具有最低喜好設定值的記錄。
- 如果您確實已連線至遠端主機,您應透過對 SMTP 伺服器連接埠 25 使用 TELNET 以檢查此遠端主機是否接受內送 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/通道下帶有字尾 .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 郵件:
可能必須多次執行這些步驟,原因是由於 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」,以取得更多資訊。
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 規則
在輸出中,尋找以下資訊:
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.- 此外,您可以將 slave_debug 關鍵字新增至 tcp_local 通道,以查看如何套用篩選器。結果在 tcp_local_slave.log 檔案中顯示。確定在目錄 /msg_svr_base/config 的 option.dat 檔案中新增 mm_debug=5,以取得足夠的除錯資訊。
常見語法問題
在位址的本機部分或接收欄位中的星號
現在,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 錯誤包括:
別名不等效. . .
Alias 檔案項目的右側格式不正確。
無法開啟別名中包括的檔案. . .
別名中包括的檔案無法開啟。
發現重複別名. . .
兩個 Alias 檔案項目的左側相同。您需要找到並刪除重複的別名。尋找顯示為 error line #XXX (其中,XXX 為行號) 的錯誤訊息。您可以在該行修正重複的別名。
通道表中的重複主機. . .
此錯誤訊息表示在 MTA 配置中有兩個具有相同正式主機名稱的通道定義。
請注意,您的 MTA 配置檔案 (imta.cnf) 的重寫規則 (上半部分) 中的多餘空白行會導致 MTA 將配置檔案的剩餘部分解譯為通道定義。請確定檔案的第一行不為空白。由於多個重寫規則通常具有相同式樣 (左側),因此這會導致 MTA 將這些重寫規則解譯為具有非唯一正式主機名稱的通道定義。檢查您的 MTA 配置,以查看是否存在具有重複正式主機名稱的任何通道定義,並查看檔案上半部分 (重寫規則) 是否存在不正確的空白行。
發現重複對映名稱. . .
此訊息表示兩個對映表具有相同的名稱,並且需要移除其中一個重複對映表。但是,對映檔案中的格式化錯誤可能會導致 MTA 將某些內容錯誤解譯為對映表名稱。例如,未正確縮排對映表項目將導致 MTA 認為項目的左側實際為對映表名稱。檢查對映檔案的一般形式,並檢查對映表名稱。
對映名稱太長.. .
此錯誤意味著對映表名稱太長,需要縮短。對映檔案中的格式化錯誤可能會導致 MTA 將某些內容錯誤解譯為對映表名稱。例如,未正確縮排對映表項目將導致 MTA 認為項目的左側實際為對映表名稱。檢查您的對映檔案以及對映表名稱。
初始化 ch_ facility 時出現錯誤:已編譯的字元集版本不匹配
如果您看到此訊息,則需要透過指令 imsimta chbuild 重新編譯並重新安裝您的已編譯字元集表。請參閱「Sun Java System Messaging Server Administration Reference」,以取得更多資訊。
初始化 ch_ facility 時出現錯誤:沒有空間. . .
此錯誤訊息通常意味著您需要調整 MTA 字元集內部表的大小,然後使用以下指令重新建立已編譯的字元集表:
imsimta chbuild -noimage -maximum -option
imsimta chbuild進行此變更之前,請驗證沒有其他內容需要重新編譯或重新啟動。請參閱「Sun Java System Messaging Server Administration Reference」中的「MTA command-line utilities」一章,以取得有關 imsimta chbuild 的更多資訊。
系統的本地主機別名或本來的名稱太長. . .
此錯誤表示本地主機別名或本來的名稱太長 (通道塊中第二個或後續名稱中的可選右側)。但是,MTA 配置檔案中早先的某些語法錯誤 (例如,重寫規則中的多餘空白行) 可能會導致 MTA 將某些內容錯誤解譯為通道定義。除了檢查配置檔案指出的一行之外,還應檢查此行以上的內容是否存在其他語法錯誤。特別是,如果 MTA 發出此錯誤的行將成為重寫規則,則請務必檢查此行以上是否存在多餘空白行。
別名沒有等效位址. . .
Alias 檔案中的項目遺漏右側 (轉換值)。
通道沒有正式主機名稱. . .
此錯誤表示通道定義塊遺漏所需的第二行 (正式主機名稱行)。請參閱「Sun Java System Messaging Server Administration Reference 」中有關 MTA 配置和指令行公用程式的各章以及第 12 章「配置通道定義」,以取得有關通道定義塊的更多資訊。每個通道定義塊之前與之後均必須有一空白行,但空白行不能存在於通道名稱和通道定義的正式主機名稱行之間。另請注意,MTA 配置檔案的重寫規則部分不允許有空白行。
正式主機名稱太長
通道的正式主機名稱 (通道定義塊的第二行) 的長度限制為 128 個八位元組。如果您要嘗試在通道上使用較長的正式主機名稱,請將其縮短為定位字元名稱,然後使用重寫規則使較長名稱與短的正式主機名稱相符。如果您使用 l (本地) 通道主機名稱,則可能會看到此情形。例如:
Original l Channel:
!delivery channel to local /var/mail store
l subdirs 20 viaaliasrequired maxjobs 7 pool LOCAL_POOL
walleroo.pocofronitas.thisnameismuchtoolongandreallymakesnosensebutitisanexample.monkey.gorilla.orangutan.antidisestablismentarianism.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 Java System Messaging Server Administration Reference 」中的「MTA configuration」一章,以取得有關用法和語法的資訊。
MTA 配置檔案中早先的某些語法錯誤 (例如,重寫規則中的多餘空白行) 可能會導致 MTA 將某些內容錯誤解譯為通道定義。這會導致預計的重寫規則被解譯為正式主機名稱。除了檢查配置檔案指出的一行之外,還應檢查此行以上的內容,看是否存在其他語法錯誤。尤其是如果 MTA 發出此錯誤的行預計作為重寫規則,則請確定檢查此行以上是否存在多餘空白行。
已編譯的配置版本不匹配
imsimta cnbuild 公用程式的功能之一是將 MTA 配置資訊編譯為可快速載入的影像。已編譯的格式定義非常嚴格,並且在不同版本的 MTA 之間常常大幅度變更。較小變更可能作為修補程式版次的一部分出現。
當出現此類變更時,內部版本欄位也進行變更,以便偵測到不相容的格式。當偵測到不相容的格式時,MTA 元件將會停止並顯示上述錯誤。此問題的解決方案為,使用指令 imsimta cnbuild 產生新的已編譯的配置。
還可以使用 imsimta restart 指令重新啟動任意常駐 MTA 伺服器程序,以便它們可取得更新的配置資訊。
交換空間錯誤
若要確保作業正確,在您的郵件傳送系統上配置足夠的交換空間十分重要。所需的交換空間容量將因您的配置而有所不同。一般調校建議為,交換空間的容量應至少為主記憶體容量的三倍。
以下的錯誤訊息表示缺少交換空間:
jbc_channels: chan_execute [1]: fork failed: Not enough space
您可能會在工作控制器記錄檔中看到此錯誤。其他的交換空間錯誤將因您的配置而有所不同。
使用以下指令以確定剩下的交換空間以及已使用的交換空間。
檔案開啟或建立錯誤
為了傳送郵件,MTA 將閱讀配置檔案並在 MTA 郵件佇列目錄中建立郵件檔。配置檔案必須可由 MTA 或根據 MTA 的 SDK 編寫的任何程式讀取。安裝期間,系統會為這些檔案指定適當的許可權。建立配置檔案的 MTA 公用程式和程序也指定許可權。如果檔案由系統管理員或其他具有特權的使用者保護,或者透過某些網站特定的程序保護,則 MTA 可能無法讀取配置資訊。這將導致「檔案開啟」錯誤或不可預料的運作方式。當 imsimta test -rewrite 公用程式讀取配置檔案遇到問題時,它會報告其他資訊。請參閱「Sun Java System Messaging Server Administration Reference」的 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 封包追蹤) 以確定已傳送或已接收的郵件。