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

常見 MTA 問題和解決方案

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

TLS 問題

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

454 4.7.1 TLS library initialization failure

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

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

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

stop-msg dispatcher 
start-msg dispatcher

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

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

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

重新編譯配置 (透過執行 imsimta cnbuild)。
重新啟動適當的程序 (如 imsimta restart dispatcher)。
重新建立所有的用戶端連線。

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 連線的逾時原因：

識別內送 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 Java System Messaging Server 6.1 (built May 7 2001))
如果已連線且接收到 220 大標題，但是其他指令 (如 ehlo 和 mail from) 未禁止回應，則您應執行 imsimta test -rewrite 以確定該配置正確。

如果 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 伺服器不必執行不必要的查詢。

您還可以將 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

使用 NSLOOKUP 公用程式查看此主機存在的 MX 記錄 (如果有)。如果不存在 MX 記錄，則您應嘗試直接連線至此主機。如果確實存在 MX 記錄，則您必須連線至指定的 MX 轉送器。MTA 優先使用 MX 資訊，除非明確配置為不這樣做。另請參閱TCP/IP MX 記錄支援。
在此範例中，DNS (網域名稱服務) 傳回 xtel.co.uk 的指定 MX 轉送器的名稱。這是 MTA 將實際連線至的主機。如果列出多個 MX 轉送器，則 MTA 將連續嘗試每個 MX 記錄，並且首先嘗試具有最低喜好設定值的記錄。
如果您確實已連線至遠端主機，您應透過對 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

建立新通道

步驟

建立名為 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 池中的電腦資源。另請注意，新通道前後均需要一個空行。

將兩個重寫規則增加至 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 複製符合的網域規格部分。

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

在 /msg_svr_base/config/job_controller.cnf 中，增加以下內容︰
[POOL=SMTP_SIROE] job_limit=10
這將建立名為 SMTP_SIROE 的郵件資源池，允許同時執行最多 10 個工作。請勿在此池定義和其他池定義之間保留任何空行。請參閱工作控制器，以取得有關工作和池的詳細資訊。

重新啟動 MTA。

發出指令：imsimta refresh

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

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

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

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

MTA 郵件未遞送

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

佇列快取記憶體與佇列目錄中的郵件不同步。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 是迫不得已的步驟，應僅在所有其他方法無效之後方可執行。
  
  請參閱工作控制器，以取得有關工作控制器的更多資訊。
由於通道處理程式不能建立其處理記錄檔而無法執行。檢查存取許可權、磁碟空間以及配額。

郵件迴圈

如果 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 忽略，並不再嘗試進一步遞送。當出現此類問題時，請查看郵件的標頭行以確定退回郵件的伺服器或通道。依需要修正項目。

您也可透過執行 imsimta qm release 或以下步驟重試 .HELD 郵件︰

將 .HELD 副檔名重新命名為任意 2 位數數字 (00 除外)。例如，將 .HELD 重新命名為 .06。

備註 –
重新命名 .HELD 檔案之前，請確定郵件已停止迴圈。
執行 imsimta cache -sync。執行此指令將更新快取記憶體。
執行 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 規則

若要檢查 MTA 的使用者篩選器，請使用以下指令︰

# 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.

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

常見語法問題

如果篩選器有語法問題，則請在 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: user@domain 452 4.7.1 Filter syntax error

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

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

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

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