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

配置郵件處理和遞送

您可以根據特定準則來配置伺服器嘗試遞送郵件的時機。還可以指定工作處理的參數，例如服務工作的處理限制或何時產生新的 SMTP 通道執行緒。本節描述以下內容：

如需有關郵件處理和傳送的概念資訊，請參閱表 12–24

表 12–24 郵件處理和遞送關鍵字


關鍵字	定義
立即傳送	定義郵件的立即傳送規格。
`immnonurgent`	提交緊急、一般與非緊急郵件之後立即開始遞送。
通道定向性	指定為通道提供服務的程式之類型
bidirectional	通道由主要程式和從屬程式提供服務。
master	通道由主要程式 (`master`) 提供服務。
slave	通道由從屬程式 (`slave`) 提供服務。
延遲傳送	定義延遲工作的傳送規格。
`backoff`	指定嘗試重新遞送延遲郵件的頻率。可以用 `normalbackoff`、`nonurgentbackoff` 和 `urgentbackoff` 來置換。
`deferred`	實作識別和允許 `Deferred-delivery:` 標頭行。
`nodeferred`	預設。指定不接受 `Deferred-delivery:` 標頭行。
`nonurgentbackoff`	嘗試重新遞送非緊急郵件的頻率。
`normalbackoff`	嘗試重新遞送一般郵件的頻率。
`urgentbackoff`	嘗試重新遞送緊急郵件的頻率。
基於大小的郵件優先順序	根據郵件大小定義郵件優先順序。
`nonurgentblocklimit`	強制將大於此大小的郵件降為低於非緊急優先順序 (第二級優先順序)，這表示這些郵件總是要等待下一個週期性工作來進一步處理。
`normalblocklimit`	強制將大於此大小的郵件設定為非緊急優先順序。
`urgentblocklimit`	強制將大於此大小的郵件設定為一般優先順序。
通道執行工作的處理池	為具有不同緊急性的郵件以及工作的延遲指定處理池
`pool`	指定通道執行時所在的儲存區。
`after`	指定通道執行前的時間延遲。
服務工作限制	針對每個工作指定可處理的服務工作數目與郵件檔案最大數目
`maxjobs`	為通道指定可以並行執行的最大工作數量。
`filesperjob`	指定由單一工作處理的佇列項目數量。
SMTP 通道執行緒
`threaddepth`	透過多重執行緒 SMTP 用戶端觸發新執行緒的郵件數量。
多位址擴充	定義對具有多位收件者的郵件之處理
`expandlimit`	位址數量超過此限制時，「離線」處理內送郵件。
`expandchannel`	指定因應用而執行延遲延伸時所在的通道。
`holdlimit`	當內送郵件之位址數量超過此限制時扣留該郵件。
作業事件限制	指定連線作業事件限制
transactionlimit	限制每個連線允許的郵件數目。
無法傳送郵件通知	指定何時傳送無法傳送郵件通知。
`notices`	指定在通知傳送及郵件傳回之前可以經過的時間。
`nonurgentnotices`	指定在非緊急優先順序的郵件之通知傳送及郵件傳回之前可以經過的時間。
`normalnotices`	指定在一般優先順序的郵件之通知傳送及郵件傳回之前可以經過的時間。
`urgentnotices`	指定在緊急優先順序的郵件之通知傳送及郵件傳回之前可以經過的時間。

設定通道定向性

關鍵字：master、slave、bidirectional

這三個關鍵字可用於指定通道是由主要程式 (master) 還是從屬程式 (slave) 提供服務，或是由兩者共同提供服務 (bidirectional)。如果這三個關鍵字都未指定，則預設為 bidirectional。這些關鍵字可決定當郵件在通道上形成佇列時，MTA 是否啟動遞送活動。

這些關鍵字的使用反映相應通道程式的某些基本特徵。MTA 支援的各種通道的描述都指示這些關鍵字應在何時及何處使用。

實作延遲遞送日期

關鍵字：deferred、nodeferred 和 immnonurgent

deferred 通道關鍵字實作識別和允許 Deferred-delivery: 標頭行。包含未來 deferred 傳送日期的郵件，會在通道佇列中暫停傳送，直到郵件過期被傳回或是到達延遲傳送日期。請參閱 RFC 1327，以取得有關 Deferred-delivery: 標頭行的格式與作業的詳細資訊。

關鍵字 nodeferred 為預設。必須認識到，對延遲郵件處理的支援由 RFC 1327 指定，它的實際實作可有效地讓人們使用郵件系統來延伸他們的磁碟配額，這一點很重要。

關鍵字 immnonurgent 在提交緊急、一般與非緊急郵件之後，立即開始傳送。

指定傳送失敗之郵件的重試頻率

關鍵字：backoff、nonurgentbackoff、normalbackoff、urgentbackoff 和 notices

依預設，傳送失敗之郵件的傳送重試頻率取決於該郵件的優先順序。遞送嘗試之間的預設間隔時間 (以分鐘為單位) 顯示如下。優先順序後的第一個數字指示初次遞送失敗後第一次嘗試重新遞送的時間 (分鐘數)：

urgent: 30, 60, 60, 120, 120, 120, 240
normal: 60, 120, 120, 240, 240, 240, 480
nonurgent: 120, 240, 240, 480, 480, 480, 960

對於緊急郵件，嘗試重新遞送的時間是初次遞送失敗後 30 分鐘，第一次重試後 60 分鐘，第二次重試後 60 分鐘，第三次重試後 120 分鐘，以此類推。在指定的最後一次重試時間之後，都以相同的間隔時間重複。因此，對於緊急郵件，會每 240 分鐘重試一次。

傳送嘗試會持續一段時間，這段時間由 notices、nonurgentnotices、normalnotices 或 urgentnotices 關鍵字指定。如果無法成功傳送郵件，就會產生傳送失敗通知，且該郵件將會傳回給寄件者。(如需有關 notices 關鍵字的詳細資訊，請參閱設定通知郵件遞送間隔時間

backoff 關鍵字可讓您為不同優先順序的郵件指定幾組自訂的傳送重試間隔。nonurgentbackoff 指定非緊急郵件的間隔。normalbackoff 指定一般郵件的間隔。urgentbackoff 指定緊急郵件的間隔。如果這些關鍵字均未指定，backoff 會為所有郵件指定間隔，而不論其優先順序為何。

範例如下：

urgentbackoff "pt30m" "pt1h" "pt2h" "pt3h" "pt4h" "pt5h" "pt8h" "pt16h"

此時，緊急郵件嘗試重新遞送的時間是初次遞送失敗後 30 分鐘，第一次遞送嘗試後一小時 (初次遞送失敗後小時 30 分鐘)，第二次遞送嘗試後兩小時，第三次後三小時，第四次後四小時，第五次後五小時，第六次後八小時，第七次後十六小時。後續嘗試會每 16 小時執行一次，直至達到由 notices 關鍵字指定的時間段為止。如果無法成功遞送，就會產生遞送失敗通知，該郵件會傳回給寄件者。請注意，間隔語法位於 ISO 8601P 中，並在「Sun Java System Messaging Server Administration Reference」中加以說明。

在下一個範例中，

normalbackoff "pt30m" "pt1h" "pt8h" "p1d" "p2d” "p1w"

一般郵件的傳送重試時間是初次傳送失敗後 30 分鐘，第一次傳送嘗試後一小時，第二次嘗試後八小時，第三次後一天，第四次後兩天，第五次後一星期，而後每星期重複一次，直至達到由 notices 關鍵字指定的時間段為止。如果無法成功遞送，就會產生遞送失敗通知，該郵件會傳回給寄件者。

在最後一個範例中，

backoff "pt30m" "pt120m" "pt16h" "pt36h" "p3d"

不論郵件的優先順序為何 (除非以 nonurgentbackoff、normalbackoff 或 urgentbackoff 置換)，所有傳送失敗的郵件之傳送重試時間都會是初次遞送失敗後 30 分鐘，第一次重試後兩小時，第二次嘗試後十六小時，第三次後三十六小時，第四次後三天，而後每三天重複一次，直至達到由 notices 關鍵字指定的時間段為止。如果無法成功遞送，就會產生遞送失敗通知，該郵件會傳回給寄件者。

通道執行工作的處理儲存區

關鍵字：pool

可以透過在同一池中執行來配置各種通道，以共用資源。您可能想將其他通道配置為在特定通道的專用儲存區中執行。在各儲存區中，郵件會根據其優先順序，自動排序為不同的處理佇列。儲存區中優先順序較高的郵件會比優先順序較低的郵件先得到處理。(請參閱基於大小的郵件優先順序)

使用 pool 關鍵字可以逐個通道地選取建立工作的池。pool 關鍵字必須後接目前通道的傳送工作匯集時所在池的名稱。儲存區名稱包含的字元不應超過十二個。

如需有關工作控制器概念和配置的詳細資訊，請參閱工作控制器檔案、工作控制器檔案和服務工作限制。

服務工作限制

關鍵字：maxjobs 和 filesperjob

每次郵件在通道中形成佇列時，工作控制器均可確保有一項傳送郵件的工作正在執行。這可能涉及到啟動新的工作程序、新增執行緒或只指明工作已在執行中。但是，單一服務工作可能不足以確保及時遞送所有的郵件。(如需有關工作控制器概念和配置的詳細資訊，請參閱工作控制器檔案、通道執行工作的處理儲存區和工作控制器。

對於任何給定的安裝都會啟動合理的最大數量的程序與執行緒以遞送郵件。此最大數量取決於幾個因素，例如處理器的數量、磁碟的速度和連線的特徵。在 MTA 配置中，可以控制以下內容：

為執行給定通道而啟動的程序之最大數目 (maxjobs 通道關鍵字)
為一組通道啟動的程序之最大數量 (工作控制器配置檔案的相關池區段中的JOB_LIMIT 參數)
新執行緒或程序啟動之前，接收到的已形成佇列的郵件之數量 (threaddepth 通道關鍵字)
對於某些通道，將在給定傳送程式中執行的執行緒最大數量 (通道選項檔案中的 max_client_threads 參數)

為執行給定通道而啟動的程序之最大數目，是對通道設定的 maxjobs 和通道執行時為所在的池設定的 JOB_LIMIT 之最小值。

假定有一封郵件需要處理。通常，工作控制器會啟動新的程序詳情如下：

如果沒有為通道執行的程序，並且尚未達到儲存區工作限制，則工作控制器會啟動新的程序。
如果通道程式是單執行緒或已達到執行緒限制，而儲存區增加量超過了執行緒的一倍 (透過 threaddepth 指定)，且通道與池工作限制均未達到，則工作控制器會啟動新的程序。
如果通道程式是多重執行緒並且尚未達到執行緒限制，而郵件的儲存區增加量超過了 threaddepth 的一倍，則會啟動新的執行緒。

尤其對於 SMTP 通道，新的執行緒或程序會在不同主機的郵件形成佇列時啟動。因此，對於 SMTP 通道，工作控制器會啟動新的程序，詳情如下。假定有一封郵件需要處理：

如果沒有為 SMTP 通道執行的程序，並且尚未達到儲存區限制，則工作控制器會啟動新的程序。
如果已達到執行緒限制 (MAX_CLIENT_THREADS)，某個尚未獲得服務的主機之郵件將會形成佇列，且通道 (maxjobs) 和池工作限制 (JOB_LIMIT) 均尚未達到，則將啟動新的程序。
如果尚未達到執行緒限制，某個尚未獲得服務的主機之郵件已形成佇列，則會啟動新的執行緒。
如果尚未達到執行緒限制，而郵件已形成佇列，使相應主機的郵件儲存區增加量超過 threaddepth 的一倍，則會啟動新的執行緒。

請參閱SMTP 通道執行緒。

filesperjob 關鍵字可用於使 MTA 建立其他服務工作。此關鍵字接受單一正整數參數，指定在處理佇列項目 (即檔案) 的多個服務工作建立之前，有多少個佇列項目必須傳送至關聯的通道。如果此值小於或等於零，則表示佇列只請求一個服務工作。不指定關鍵字就相當於指定零值。此關鍵字的效果已經最大化；較大的估算數量將是實際建立的服務工作數量。

filesperjob 關鍵字會以實際佇列項目或檔案的數目除以給定值。請注意，給定郵件所產生的佇列項目之數目由多個因素所控制，包括但不僅限於 single 和 single_sys 關鍵字的使用，以及郵件收信人清單中標頭修改動作的規格。

maxjobs 關鍵字對可並行執行的服務工作之總數設定了一個上限。此關鍵字之後必須加整數值；即使服務工作的估算數目大於此值，實際上仍只會建立 maxjobs 數目的工作。如果未指定 maxjobs，則此值預設為 100。通常，maxjobs 的設定值應小於或等於通道使用的任何服務池中可同時執行的工作之總數。

設定連線異動限制

關鍵字：transactionlimit

transactionlimit 限制每個連線允許的郵件數目。此限制可透過以下方式來阻撓侵入者：

侵入者可透過 SMTP 連線並傳送多個 RCPT TO 指令，來嘗試推測出合法的電子郵件位址。透過限制作業事件所允許的無效 RCPT TO 數目可阻撓這類侵入。侵入者可能透過使用多個作業事件來進行回應，但藉由 transactionlimit 可以限制一個 SMTP 階段作業所允許的作業事件數目。侵入者可使用多個階段作業，但此時他的成本會增高。連線阻塞可用於以各種方式限制階段作業的數目，在大多數情況下會使成本變得過高。

不過我們一方也不是沒有負擔任何成本。某些用戶端對收件者限制、異動限制或兩種限制回應不佳。這些用戶端需要另行處理。但 TCP 通道選項可無條件套用至 SMTP 伺服器。解決方案為使用通道關鍵字和 switchchannel 將有問題的代理程式路由至具有較寬限制的通道。

基於大小的郵件優先順序

關鍵字：urgentblocklimit、normalblocklimit 和 nonurgentblocklimit

urgentblocklimit、normalblocklimit 和 nonurgentblocklimit 關鍵字可用於指示 MTA 根據郵件大小降低郵件的優先順序。這些關鍵字會影響工作控制器在處理郵件時所使用的優先順序。

SMTP 通道執行緒

關鍵字：threaddepth,

多重執行緒 SMTP 用戶端會將不同目的地的郵件排序至不同的執行緒。threaddepth 關鍵字可用於指示多重執行緒的 SMTP 用戶端僅用任一執行緒處理指定數目的郵件，即使是均為同一目的地的郵件，仍使用額外的執行緒 (因此通常是在一個執行緒中處理所有的郵件)。此關鍵字預設為 10。

每當通道儲存區的增加量超過 threaddepth 的一倍時，工作控制器會嘗試增加處理量，專門用於處理該通道中已形成佇列的郵件。對於多重執行緒通道，工作控制器會通知處理該通道郵件的任一工作啟動新的執行緒，如果所有工作所具有的執行緒都達到了該通道允許的最大數目 (tcp_* 通道之選項中的 MAX_CLIENT_THREADS)，工作控制器會啟動新的程序。對於單一執行緒通道，會啟動新的程序。請注意，如果已達到該通道 (maxjobs) 或池的工作限制 (JOB_LIMIT)，則工作控制器將不啟動新的工作。

實質上，threaddepth 可控制如何排程積極的工作。讓我們考量以下兩種不同情況：

(1) 一般 (外寄) SMTP 通道

(2) 轉寄至智慧主機的 SMTP 通道

工作控制器可排序目標主機指定其目標為特定通道的郵件，並排程工作以根據這些目標主機上的儲存區處理郵件。

第一個實例中有大量的目標主機，並且大多數目標主機的儲存區很小。許多執行緒將在那裡處於執行狀態，並且需要一切正常，但某些目標主機例如 aol、yahoo、hotmail 等可能無法正常運行，因為其中可能有大量的通訊流。如果執行緒深度為 128，則當儲存區達到 128 時，您才能向 yahoo 遞送另一個執行緒。但這是不夠的。

第二個實例中僅有一個目標主機，但可以將多個執行緒遞送至該主機。如果是所有執行緒均遞送至該主機，則預設值 10 就太小。

尤其通道連線的 SMTP 伺服器可處理多個同時連線時，可以使用 threaddepth 對常駐程式路由器 TCP/IP 通道 (一種連線單台特定 SMTP 伺服器的 TCP/IP 通道) 實現多執行緒。

多位址延伸

關鍵字：expandlimit、expandchannel 和 holdlimit

大多數通道在傳送每個內送郵件的過程中都支援多個收件者位址的規格。單封郵件中的多個收件者位址之規格，可能會導致郵件傳送處理延遲 (線上延遲)。如果延遲時間過長，就會發生網路逾時，然後導致重複嘗試提交郵件以及其他問題。

如果單封郵件中指定的位址數量超過給定數量，則 MTA 提供的一項特殊功能會強制延遲 (離線) 處理。延遲處理郵件可以大幅降低線上延遲。但請注意，並不能完全避免處理時間的延遲。

這項特殊功能可藉由通道與關鍵字組合來啟動，例如通用 reprocessing 通道和 expandlimit 關鍵字的組合。expandlimit 關鍵字接受整數引數，指定延遲處理之前，來自該通道的郵件中應接受的位址數目。如果未指定 expandlimit 關鍵字，則預設值為無限大。數值 0 將強制延遲處理來自該通道的所有送進的位址。

請勿對本機通道或 reprocessing 通道本身指定 expandlimit 關鍵字；一旦指定，所帶來的結果將無法預測。

實際用於執行延遲處理的通道可以使用 expandchannel 關鍵字來指定；如果未指定 expandchannel，依預設會使用 reprocessing 通道，但是其他一些重新處理通道或處理通道可以用於特殊用途。如果執行延遲處理的通道是透過 expandchannel 指定的，則該通道應為 reprocessing 通道或 processing 通道；其他種類的通道規格可能會導致無法預測的結果。

reprocessing 通道或用於執行延遲處理的任何通道，都必須增加至 MTA 配置檔案中，以使 expandlimit 關鍵字生效。如果您的配置是由 MTA 配置公用程式建立的，則您應該已具有重新處理通道。

垃圾電子郵件的一個特徵就是通常具有特大的收件者位址清單。holdlimit 關鍵字告知 MTA 應將進入通道且導致收件者數目超過指定數目的郵件標記為 .HELD 郵件，並且在 reprocess 通道 (或透過 expandchannel 關鍵字指定的任何通道) 上形成佇列。這些檔案將在 reprocess 佇列中保持未處理狀態，等待 MTA Postmaster 手動介入。

啟用服務轉換

關鍵字：service、noservice

service 關鍵字可無條件啟用服務轉換，不論 CHARSET-CONVERSION 項目為何。如果已設定 noservice 關鍵字，則必須透過 CHARSET-CONVERSION 對進入此通道的郵件啟用服務轉換。