第 12 章 配置通道定義

本章說明如何使用 MTA 配置檔案 imta.cnf 中的通道關鍵字定義。閱讀本章前，請先參閱第 10 章, 關於 MTA 服務和配置以及通道定義和MTA 配置檔案。本章包含以下各節：

• 配置通道預設

• 通道關鍵字 (依字母順序列出)

• 通道關鍵字 (依功能分類)

• 配置 SMTP 通道

• 配置郵件處理和遞送

• 配置位址處理

• 配置標頭處理

• 附件和 MIME 處理

• 對郵件、配額、收件者和認證嘗試次數的限制

• 在 MTA 佇列中建立檔案

• 指定電子信箱篩選器檔案位置

• 配置記錄和除錯

• 其他關鍵字

如果變更了 imta.cnf 中的通道定義，就必須使用 imsimta restart 指令，重新啟動僅在啟動時才載入一次配置資料的所有程式或通道，例如 SMTP 伺服器。如果您使用已編譯的配置，則必須重新編譯然後再重新啟動。如需有關編譯配置資訊和啟動程式的更多資訊，請參閱「Sun Java System Messaging Server 6 2005Q4 Administration Reference」。

配置通道預設

許多配置涉及到對所有或幾乎所有通道重複使用各種通道關鍵字。維護這樣一種配置不僅繁瑣而且容易出錯。為簡化某些配置，您可以為各種通道指定預設關鍵字。

例如，配置檔案中的以下一行表示跟隨在該行之後的所有通道區塊都將繼承該行中指定的關鍵字：

defaults keyword1 keyword2 keyword3 ...

defaults 行可視為特殊的通道區塊，該區塊可變更關鍵字 defaults 而無需實際指定通道。defaults 行也不需要其他任何通道區塊資訊行 (如有指定，都會被忽略)。

可以指定 defaults 行的數量沒有限制 — 多個 defaults 行的效果會累積，最後遇到的 (從上向下讀取) 行具有較高的優先順序。

無條件結束配置檔案中從某點 (例如，外部檔案中通道區塊獨立區段的起點) 開始的所有 defaults 行的效果可能會有用。nodefaults 行就用於此目的。例如，在配置檔案中插入以下行，就可使先前所有預設通道所建立的所有設定無效，並讓配置返回到未指定預設時要套用的狀態。

nodefaults

如同常規通道區塊，每個 defaults 或 nodefaults 通道區塊與其他通道區塊之間都必須有空行來進行分隔。在配置檔案中，只有 defaults 和 nodefaults 通道區塊才能出現在本機通道之前。但是，如同任何其他通道區塊，這兩種通道區塊必須出現在最後一個重寫規則之後。

通道關鍵字 (依字母順序列出)

下表是依字母順序列出的關鍵字清單。

通道關鍵字 (依功能分類)

下表是關鍵字分類清單。表格和種類如下：

• 表 12–2 位址處理關鍵字

• 表 12–3 附件和 MIME 處理

• 表 12–4 字元集與八位元資料

• 表 12–5 在 MTA 佇列區域建立檔案

• 表 12–6 標頭關鍵字

• 表 12–7 內送通道匹配和切換關鍵字

• 表 12–8 記錄和除錯通道關鍵字

• 表 12–9 詳細位址清單或標頭通道關鍵字

• 表 12–10 電子信箱篩選器關鍵字

• 表 12–11 NO-SOLICIT SMTP 延伸支援關鍵字

• 表 12–12 通知與 Postmaster 郵件關鍵字

• 表 12–13 處理控制與工作提交關鍵字

• 表 12–14 敏感性限制關鍵字

• 表 12–15 對郵件、使用者配額、權限和認證嘗試次數的限制之關鍵字

• 表 12–16 SMTP 認證、SASL 和 TLS 關鍵字

• 表 12–17 SMTP 指令與協定關鍵字

• 表 12–18 TCP/IP 連線和 DNS 查詢支援關鍵字

• 表 12–19 其他關鍵字

配置 SMTP 通道

根據安裝類型，在安裝時，Messaging Server 提供數種 SMTP 通道 (請參見下表)。這些通道實作經由 TCP/IP 的 SMTP。多重執行緒 TCP SMTP 通道包括在派送程式控制下執行的多重執行緒 SMTP 伺服器。外寄 SMTP 郵件由通道程式 tcp_smtp_client 處理，且依需要在工作控制器控制下執行。

透過增加或移除本節所述的通道關鍵字，您可以修改這些通道的定義或者建立新的通道。此外，可能使用某選項檔案來控制 TCP/IP 通道的各種特性。此類選項檔案必須儲存在 MTA 配置目錄 (msg_svr_base/config) 中，並且命名為 x_option，其中 x 是通道名稱。如需詳細資訊，請參閱「Sun Java System Messaging Server 6 2005Q4 Administration Reference」中的「Option File」。

本節分為以下子節：

• 配置 SMTP 通道選項

• SMTP 指令和協定支援

• TCP/IP 連線和 DNS 查詢支援

• SMTP 認證、SASL 與 TLS

• TCP/IP 連線和 DNS 查詢支援

• TCP/IP 連線和 DNS 查詢支援

• 指定 Microsoft Exchange 閘道通道

• 傳輸層安全

配置 SMTP 通道選項

TCP/IP 通道選項檔案可控制 TCP/IP 通道的各種特性。通道選項檔案必須儲存在 MTA 配置目錄中，並且命名為 x_option (其中 x 是通道的名稱)。例如，/msg_svr_base/config/tcp_local_option

選項檔案包含一個或多個關鍵字及關聯值。例如，可以在選項檔案中包含 DISABLE_EXPAND 關鍵字，並將其值設為 1，以停用伺服器上的郵件收信人清單擴充。

其他選項檔案關鍵字可讓您執行以下作業：

• 設定每封郵件允許的收件者數量限制 (ALLOW_RECIPIENTS_PER_TRANSACTION)

• 設定每個連線允許的郵件數量限制 (ALLOW_TRANSACTIONS_PER_SESSION)

• 詳細調校 MTA 記錄檔中記錄的資訊類型 (LOG_CONNECTION、LOG_TRANPORTINFO)

• 指定用戶端通道程式允許的同步外寄連線最大數目 (MAX_CLIENT_THREADS)

如需有關所有通道選項關鍵字和語法的資訊，請參閱「Sun Java System Messaging Server 6 2005Q4 Administration Reference」。

SMTP 指令和協定支援

可以指定 SMTP 通道是否支援某些 SMTP 指令 (例如 EHLO、ETRN、EXPN 和 VRFY)。還可以指定該通道是否支援 DNS 網域驗證、該通道接受哪些字元作為行終止符號等。本節描述以下內容：

• 通道協定選取和行終止符號

• EHLO 指令支援

• ETRN 指令支援

• VRFY 指令支援

• DNS 網域驗證

• 字元集標記與八位元資料

• 協定串流

表 12–21 概括本小節所說明的關鍵字。

通道協定選取和行終止符號

關鍵字：smtp、nosmtp、smtp_crlf、smtp_cr、smtp_crorlf 和 smtp_lf

smtp 和 nosmtp 關鍵字指定通道是否支援 SMTP 協定。smtp 關鍵字或其變化形式之一，對於所有 SMTP 通道都具有強制性。

關鍵字 smtp_crlf、smtp_cr、smtp_crorlf 和 smtp_lf 可用於 SMTP 通道，指定 MTA 將接受做為行終止符號的字元序列。關鍵字 smtp_crlf 表示行必須以換行鍵 (CR) 換行 (LF) 序列終止。關鍵字 smtp_lf 或 smtp 表示接受前面沒有 CR 的 LF。最後，smtp_cr 表示接受後面沒有 LF 的 CR。這些選項僅影響內送郵件之處理。

由於 SMTP 標準需要 CRLF 以作為行終止符號，因此 MTA 始終會產生標準 CRLF 序列。各種 smtp 關鍵字僅控制 MTA 是否接受其他非標準的行終止符號。例如，如果要 MTA 僅接受完全合法的 SMTP 郵件並拒絕所有包含非標準行終止符號的郵件，則可以指定 smtp_crlf。

EHLO 指令支援

關鍵字：ehlo、noehlo 和 checkehlo

SMTP 協定已延伸 (RFC 1869) 為允許協商其他指令。使用新的 EHLO 指令便可達此目的，該指令取代了 RFC 821 的 HELO 指令。延伸的 SMTP 伺服器透過提供其支援的延伸清單來回應 EHLO。未延伸的伺服器則會傳回不明的指令錯誤，然後用戶端會傳送舊的 HELO 指令。

退回策略通常可與延伸的以及未延伸的伺服器正常配合工作。但是如果伺服器未根據實作，則會發生問題。具體來說，曾經有某些不符合的伺服器在接收未知指令時中斷連線。

SMTP 用戶端會實作一種策略，如果任一伺服器在接收 EHLO 時中斷連線，SMTP 用戶端便會藉此策略嘗試重新連線並使用 HELO 。但是，如果遠端伺服器在接收 EHLO 時，不僅中斷連線，還處於問題狀態，則此策略可能無法奏效。

通道關鍵字 ehlo、noehlo 和 checkehlo 可用於處理此類情況。ehlo 關鍵字告知 MTA 在嘗試所有的初始連線時，使用 EHLO 指令。noehlo 關鍵字可完全停用 EHLO 指令。checkehlo 關鍵字測試由遠端 SMTP 伺服器傳回的回應大標題中有無字串「ESMTP」。如果發現此字串，則使用 EHLO；如果未發現，則使用 HELO。預設運作方式是在嘗試所有初始連線時使用 EHLO，除非大標題行包含字串「fire away」(在此情況下使用 HELO)；請注意，由於此預設運作方式介於 ehlo 和 checkehlo 關鍵字產生的運作方式之間，因此沒有對應於此預設運作方式的關鍵字。

ETRN 指令支援

關鍵字：allowetrn、blocketrn、disableetrn、domainetrn、silentetrn、 sendetrn、nosendetrn 和 novrfy

ETRN 指令在 RFC 1985 中定義，可提供 SMTP 服務的延伸，藉此，SMTP 用戶端與伺服器可以互動，使伺服器可以處理其要傳送至給定主機之郵件的佇列。

使用 ETRN，SMTP 用戶端可以請求遠端 SMTP 伺服器啟動對預定要傳送至 SMTP 用戶端的郵件佇列的處理。因此，ETRN 可提供一種實作遠端 SMTP 系統「輪詢」的方法，以便郵件內送至自己的系統。這對於彼此之間只有暫態連線的系統很有用，例如，作為其他站點之次要郵件交換 (MX) 主機而設定的站點與網際網路之間僅有撥接連線。透過啟用此指令，可允許遠端 (可能是撥接) 伺服器請求遞送它們的郵件。

SMTP 用戶端在 ETRN 指令行中指定郵件要傳送到的系統之名稱 (通常是 SMTP 用戶端系統自己的名稱)。如果遠端 SMTP 伺服器支援 ETRN 指令，它將觸發獨立程序的執行，以連線回已命名的系統，並為該系統傳送正等候傳送的所有郵件。

回應 ETRN 指令

allowetrn、blocketrn、domainetrn 和 silentetrn 關鍵字可控制傳送 SMTP 用戶端發出 ETRN 指令以請求 MTA 嘗試傳送 MTA 佇列中的郵件時 MTA 的回應。

依預設，MTA 將嘗試允許所有 ETRN 指令；亦即啟用 allowetrn 關鍵字。可以在通道定義中包含 blocketrn 關鍵字，從而指定 MTA 不允許 ETRN 指令。

可以包含 silentetrn 關鍵字，從而指定 MTA 允許所有 ETRN 指令，但不回應與網域相符的且 MTA 將嘗試執行的通道之名稱。domainetrn 關鍵字指定 MTA 僅接受用於指定網域的 ETRN 指令；它也會使 MTA 不回應網域相符的且 MTA 將嘗試執行的通道之名稱。

disableetrn 可完全停用對 ETRN 指令的支援；SMTP 伺服器不會將 ETRN 做為支援的指令進行通告。

傳送 ETRN 指令

sendetrn 和 nosendetrn 通道關鍵字可控制 MTA 在開始 SMTP 連線時是否傳送 ETRN 指令。預設是 nosendetrn，表示 MTA 不傳送 ETRN 指令。如果遠端 SMTP 伺服器表示支援 ETRN，sendetrn 關鍵字即會告知 MTA 傳送 ETRN 指令。sendetrn 關鍵字後面應加上請求其郵件接收傳送嘗試的系統之名稱。

VRFY 指令支援

關鍵字：domainvrfy、localvrfy、vrfyallow、vrfydefault 和 vrfyhide

VRFY 指令可讓 SMTP 用戶端傳送請求至 SMTP 伺服器，請求驗證該伺服器上特定使用者名稱的郵件。VRFY 指令在 RFC 821 中定義。

伺服器傳送回應指示該使用者是否位於本機、郵件是否將被轉寄等。250 回應指示使用者名稱位於本機，251 回應指示使用者名稱不在本機，但伺服器可轉寄該郵件。伺服器回應中包含電子信箱名稱。

傳送 VRFY 指令

一般情況下，沒有必要發出 VRFY 指令做為 SMTP 對話的一部分。SMTP RCPT TO 指令執行的功能應與 VRFY 所執行的功能相同，並傳回相應的錯誤。但是，有些伺服器可以接受 RCPT TO 中的任何位址 (並在以後退回)，而這些伺服器會執行更廣泛的檢查來做為 VRFY 指令的一部分。

依預設，MTA 不傳送 VRFY 指令 (啟用 novrfy 關鍵字)。

如有必要，可在通道定義中包含 domainvrfy 或 localvrfy 關鍵字，從而將 MTA 配置為發出 SMTP VRFY 指令。關鍵字 domainvrfy 可導致發出 VRFY 指令，並包含完整的位址 (user@host) 做為該指令的引數。localvrfy 關鍵字可使 MTA 發出 VRFY 指令，但僅包含位址中的本機部分 (user)。

回應 VRFY 指令

vrfyallow、vrfydefault 和 vrfyhide 關鍵字可控制傳送 SMTP 用戶端發出 SMTP VRFY 指令時 SMTP 伺服器的回應。

vrfyallow 關鍵字告知 MTA 發出詳細的資訊回應。vrfydefault 告知 MTA 提供詳細的資訊回應，除非已指定通道選項 HIDE_VERIFY=1。vrfyhide 關鍵字告知 MTA 僅發出模糊的回應。這些關鍵字允許針對各通道控制 VRFY 回應，而與之相對的 HIDE_VERIFY 選項通常適用於透過同一 SMTP 伺服器處理的所有內送 TCP/IP 通 道。

EXPN 支援

關鍵字：expnallow、expndisable 和 expndefault

expnallow 允許 EXPN，即使已在 SMTP 伺服器層級透過 DISABLE_EXPAND SMTP 通道選項停用了 EXPN。expndisable 無條件停用 EXPN。如果 SMTP 伺服器設定為允許 EXPN (預設)，則 expndefault 允許 EXPN。可針對每個清單停用延伸，但如果在伺服器級別停用延伸，則每個清單的設定不相關。

DNS 網域驗證

關鍵字：mailfromdnsverify 和 nomailfromdnsverify

對內送 TCP/IP 通道設定 mailfromdnsverify 會使 MTA 驗證 DNS 中是否存在 SMTP MAIL FROM 指令中所用網域的項目，如果該項目不存在，則拒絕郵件。預設為 nomailfromdnsverify，表示不執行上述檢查。請注意，對傳回位址網域執行 DNS 檢查可能會導致某些需要的有效郵件被拒絕 (例如，來自只是尚未註冊網域名稱，或有時在 DNS 中存在錯誤資訊的合法站點的郵件)；這樣就違背了 RFC 1123「Requirements for Internet Hosts」所體現的在接受與傳送電子郵件方面的包容性。但是，有些站點可能希望執行上述檢查，以避免傳送不存在的網域的帶有偽造電子郵件位址的垃圾電子郵件 (UBE)。

由於 COM 和 ORG 頂層網域中引入 DNS 萬用字元項目使 mailfromdnsverify 的作用降低，因此對 mailfromdnsverify 代碼進行了修改。DNS 傳回一個或多個 A 記錄時，這些值會與由新的 MTA 選項 BLOCKED_MAIL_FROM_IPS 所指定的網域文字列進行比較。如果匹配，該網域會視為無效。為了復原正確的運作方式，目前的正確設定為：

BLOCKED_MAIL_FROM_IPS=[64.94.110.11]

此選項的值預設為空字串。

字元集標記與八位元資料

關鍵字：charset7、charset8、charsetesc、sevenbit、eightbit、eightnegotiate 和 eightstrict

字元集標記

MIME 規格提供標記一般文字郵件中所使用的字元集的機制。具體來說，可指定 charset= 參數做為 Content-type: 標頭行的一部分。MIME 中定義了多種字元集名稱，包括 US-ASCII (預設)、ISO-8859-1 和 ISO-8859-2，後續還定義了許多其他字元集。

某些現有系統與使用者代理程式不提供產生上述字元集標籤的機制；因此，有些一般文字郵件可能不會被正確標記。charset7、charset8 和 charsetesc 通道關鍵字提供針對各通道的機制，可指定要在缺少字元集標記的郵件標頭中插入的字元集名稱。 每個關鍵字都需要單一引數，以提供字元集名稱。這些名稱的有效性不會被檢查。但請注意，只能對 MTA 表目錄字元集定義檔案 charsets.txt 中所指定的字元集執行字元集轉換。如有可能，應使用該檔案中定義的名稱。

如果郵件僅包含七位元字元，則使用 charset7 字元集名稱；如果郵件包含八位元資料，則使用 charset8 字元集名稱；如果在僅包含七位元資料的郵件中碰巧還包含退出字元，則使用 charsetesc。如果未指定適當的關鍵字，則不會在 Content-type: 標頭行中插入任何字元集名稱。

請注意，charset8 關鍵字還控制郵件標頭中 (8 位元資料對於該標頭絕對為非法) 8 位元字元的 MIME 編碼。如果未指定 charset8 值，MTA 通常會將在郵件標頭中遇到的所有 (非法) 8 位元資料進行 MIME 編碼，將其標記為 UNKNOWN 字元集。

這些字元集規格永遠不會置換現有標籤，即如果郵件已有字元集標籤或郵件是文字以外的其他類型，則這些字元集規格都無效。通常適合將 MTA 本機通道標記為以下形式：

l ... charset7 US-ASCII charset8 ISO-8859-1 ...
hostname

如果郵件中沒有 Content-type 標頭，則會加入該標頭。如果沒有 MIME-version: 標頭行，此關鍵字還會加入該標頭行。

對於接收使用日語或韓語字元集、且包含退出字元之未標記郵件的通道，charsetesc 關鍵字極其有用。

八位元資料

某些傳輸會限制使用序數值大於 127 (十進位) 的字元。最明顯的是，某些 SMTP 伺服器會刪除高位元，並因此竄改使用此八位元範圍內字元的郵件。

Messaging Server 提供對這類郵件自動編碼的功能，使棘手的八位元字元不會直接顯示在郵件中。透過指定 sevenbit 關鍵字，此編碼可套用於在給定通道上形成佇 列的所有郵件。如果不存在此類限制，則應將通道標記為 eightbit。

SMTP 協定不允許使用 eightbit，「除非遠端 SMTP 伺服器明確表示支援允許使用 eightbit 的 SMTP 延伸」。某些傳輸 (例如延伸的 SMTP) 可以實際支援某種協商形式，以確定是否可以傳輸八位元字元。因此，極力建議使用 eightnegotiate 關鍵字來指示通道在協商失敗時對郵件進行編碼。這是所有通道的預設；不支援協商的通道只假定傳輸能夠處理八位元資料。

eightstrict 關鍵字告知 Messaging Server 拒絕所有標頭包含非法八位元資料的內送郵件。

協定串流

關鍵字：streaming

某些郵件協定支援串流作業。這表示 MTA 可以一次發出多個作業，並等候各作業的回覆成批到達。streaming 關鍵字控制在與通道關聯的協定中使用的協定串流之程度。此關鍵字需要整數參數，而參數的解譯方式特定於使用的協定。

在一般情況下，串流支援的有效程度透過 SMTP 管線化作業延伸來進行協商。因此，此關鍵字不應用於一般情況。

串流值有效範圍為到。數值 0 指定無串流，數值 1 會使 RCPT TO 指令群組串流，數值 2 會使 MAIL FROM/RCPT TO 串流，而數值 3 會使 HELO/MAIL FROM/RCPT TO 或 RSET/MAIL FROM/RCPT TO 串流被使用。預設值為 0。

TCP/IP 連線和 DNS 查詢支援

可以指定有關伺服器如何處理 TCP/IP 連線與位址查詢的資訊。本節描述以下內容：

• TCP/IP 連接埠號碼和介面位址

• 快取通道連線資訊

• 反向 DNS 查詢

• IDENT 查詢

• TCP/IP MX 記錄支援

• 名稱伺服器查詢

• 最後一台主機

• 內送郵件的替代通道 (切換通道)

• 目標主機選擇

表 12–22 列出本小節說明的 TCP/IP 連線和 DNS 查詢關鍵字。

TCP/IP 連接埠號碼和介面位址

關鍵字：port 和 interfaceaddress

經由 TCP/IP 通道的 SMTP 在傳送郵件時，通常會連線連接埠 25。port 關鍵字可 用於指示經由 TCP/IP 通道的 SMTP 連線非標準連接埠。請注意，此關鍵字與派送程式選項PORT 互補，該選項用於控制 MTA 偵聽哪些連接埠來接受 SMTP 連線。

interfaceaddress 關鍵字控制 TCP/IP 通道連結的、做為外寄連線來源位址的位址；亦即在具有多個介面位址的系統上，此關鍵字可控制在 MTA 傳送外寄 SMTP 郵件時用做來源 IP 位址的位址。請注意，此關鍵字與派送程式選項 INTERFACE_ADDRESS 互補，該選項用於控制 TCP/IP 通道偵聽哪個介面位址來接受內送的連線與郵件。

快取通道連線資訊

關鍵字：cacheeverything、nocache、cachefailures 和 cachesuccesses

使用 SMTP 協定的通道會維護包含先前連線嘗試歷程記錄的快取記憶體。此快取記憶體可用於避免多次重新連線至無法存取的主機，以免浪費大量時間並延遲其他郵件。此快取記憶體針對各個程序，而且只在外寄 SMTP 遞送通道單次執行期間存留。

此快取記憶體通常會記錄連線成功與失敗。(記錄成功的連線嘗試是為了彌補後續的失敗 - 一台先前成功但現在失敗的主機並不保證進行另一次連線嘗試之前的延遲時間會與從未嘗試或先前失敗時進行連線嘗試之前的延遲時間一樣長。)

但是，MTA 所使用的快取策略不一定適合所有情況。因此，提供通道關鍵字來調整 MTA 快取記憶體。

cacheeverything 關鍵字啟用所有形式的快取，該關鍵字為預設。nocache 關鍵字可停用所有快取。

cachefailures 關鍵字啟用連線失敗而不是成功的快取 — 這會強制進行重試，而重試的限制比 cacheeverything 的限制更為嚴格。最後，cachesuccesses 只快取成功連線。最後這個關鍵字對於 SMTP 通道的效果等同於 nocache。

反向 DNS 查詢

關鍵字：forwardchecknone、forwardchecktag 和 forwardcheckdelete

forwardchecknone、forwardchecktag 和 forwardcheckdelete 通道關鍵字可修改執行反向 DNS 查詢的效果。這些關鍵字可控制 MTA 是否對使用 DNS 反向查詢找到的 IP 名稱執行正向查詢，如果請求執行正向查詢，這些關鍵字還可指定當 IP 名稱的正向查詢結果與連線中原始 IP 號碼不相符時，MTA 應執行何種作業。

forwardchecknone 關鍵字為預設，它表示不執行正向查詢。forwardchecktag 關鍵字告知 MTA 在每次反向查詢之後執行正向查詢，如果使用正向查詢找到的號碼與原始連線的號碼不相符，就以星號 (*) 標記相應的 IP 名稱。forwardcheckdelete 關鍵字告知 MTA 在每次反向查詢之後執行正向查詢，如果反向查詢傳回的名稱之結果與原始連線 IP 位址不匹配，就忽略 (刪除) 該名稱；在這種情況下，MTA 改為使用原始 IP 位址。

對於許多站點，正向查詢的結果與原始 IP 位址不匹配這種情況很正常，因為這些站點對數個不同的 IP 位址使用更「通用」的 IP 名稱。

IDENT 查詢

關鍵字：identnone、identnonelimited、identtnonnumeric、identnonesymbolic、identtcp、identtcpnumeric、identtcpsymbolic 和 identtcplimited

IDENT 關鍵字控制 MTA 如何使用 IDENT 協定來處理連線與查詢。IDENT 協定在 RFC 1413 中加以說明。

identtcp、identtcpsymbolic 和 identtcpnumeric 關鍵字告知 MTA 使用 IDENT 協定來執行連線與查詢。從 IDENT 協定獲取的資訊 ( 通常是進行 SMTP 連線的使用者身份) 會插入到郵件的 Received: 標頭中，如下所示：

• identtcp 插入對應於內送 IP 號碼的主機名稱 (DNS 反向查詢所報告的主機名稱) 和 IP 號碼本身。

• identtcpsymbolic 插入對應於內送 IP 號碼的主機名稱 (DNS 反向查詢所報告的主機名稱)；IP 號碼本身不包含在 Received: 標頭中。

• identtcpnumeric 插入實際內送 IP 號碼，而不對此 IP 號碼執行 DNS 反向查詢。

遠端系統必須為 identtcp、identtcpsymbolic 或 identtcpnumeric 引起的 IDENT 查詢執行 IDENT 伺服器，使其發揮作用。

請注意，IDENT 查詢嘗試可能會影響效能。路由器會越來越多地「鎖定」嘗試與它們無法識別的連接埠進行的連線。如果 IDENT 查詢發生這種情況，則 MTA 在連線逾時 (TCP/IP 堆疊控制的逾時，通常是一兩分鐘) 之前將不會回聽。

將 identtcp、indenttcplimited 或 identtcpsymbolic 與 identtcpnumeric 比較時，會發現其他影響效能的因素。透過 identtcp、identtcplimited 或 identtcpsymbolic 呼叫的 DNS 反向查詢，會耗用一些額外的時間來獲取更易使用的主機名稱。

identnone 關鍵字會停用 IDENT 查詢，但會指定 IP 至主機名稱轉換，而且 IP 號碼和主機名稱都將包含在郵件的 Received: 標頭中。

identnonesymbolic 關鍵字會停用 IDENT 查詢，但會指定 IP 至主機名稱轉換；僅主機名稱會包含在郵件的 Received: 標頭中。

identnonenumeric 關鍵字會停用此 IDENT 查詢，禁止執行通常 IP 號碼至主機名稱的 DNS 反向查詢轉換，並可能會提昇效能，但會造成 Received: 標頭中更易使用的資訊減少。這是預設。

對於 IDENT 查詢、反向 DNS 查詢和 Received: 標頭中顯示的資訊而言，identtcplimited 和 identnonelimited 關鍵字的效果分別與 identtcp 和 identnone 的效果相同。不同之處在於，使用 identtcplimited 或 identnonelimited 時，不論 DNS 反向查詢是否成功地決定了主機名稱，IP 文字列位址始終會用做由於使用 switchchannel 關鍵字而進行的任一通道切換之基礎。

TCP/IP MX 記錄支援

關鍵字：mx、nomx、defaultmx、randommx 和 nonrandommx

有些 TCP/IP 網路支援使用 MX (郵件轉寄) 記錄，有些則不支援。如果 MTA 系統所連線的網路不提供 MX 記錄，有些 TCP/IP 通道程式可被配置為不使用 MX 記錄。mx、nomx、defaultmx、randommx 和 nonrandommx 關鍵字控制 MX 記錄支援。

關鍵字 randommx 指定應執行 MX 查詢，而且應以隨機順序處理同等優先順序的 MX 記錄值。關鍵字 nonrandommx 指定應執行 MX 查詢，而且應以接收時的順序處理同等優先順序的 MX 值。

目前，mx 關鍵字等同於 nonrandommx；在未來的發行版本中可能會變更為等同於 randommx。nomx 關鍵字停用 MX 查詢。defaultmx 關鍵字指定在網路表示支援 MX 記錄時，應使用 mx。關鍵字 defaultmx 是以任何形式支援 MX 查詢的通道之預設。

名稱伺服器查詢

關鍵字：nameservers 和 defaultnameservers

執行名稱伺服器查詢時，nameservers 通道關鍵字可用於指定要查閱的名稱伺服器清單，而不是查閱 TCP/IP 堆疊自己的名稱伺服器選項。nameservers 關鍵字需要以空格分隔的名稱伺服器 IP 位址清單，如下例所示：

nameservers 1.2.3.1 1.2.3.2

預設為 defaultnameservers，表示使用 TCP/IP 堆疊自己的名稱伺服器選項。

為避免在 UNIX 上執行名稱伺服器查詢，可以修改 nsswitch.conf 檔案。在 NT 上修改 TCP/IP 配置。

最後一台主機

關鍵字：lastresort

lastresort 關鍵字用於指定即使所有其他連線嘗試均失敗，仍可連線的主機。實際上，它充當最後一個 MX 記錄。此關鍵字僅適用於 SMTP 通道。

此關鍵字需要單一引數以指定「最後一個可使用的系統」的名稱。例如：

tcp_local single_sys smtp mx lastresort mailhub.siroe.com
TCP-DAEMON

內送郵件的替代通道 (切換通道)

關鍵字：switchchannel、allowswitchchannel 和 noswitchchannel。另請參閱SMTP 認證、SASL 與 TLS的 saslswitchchannel 和傳輸層安全的 tlsswitchchannel

以下關鍵字控制內送郵件的替代通道選取：switchchannel、allowswitchchannel 和 noswitchchannel。

MTA 接受來自遠端系統的內送連線時，它必須選擇與此連線關聯的通道。通常此決定依使用的傳輸而定；例如，經由 TCP/IP 的內送 SMTP 連線會自動與 tcp_local 通道相關聯。

但是，使用具有不同特性的多個外寄通道處理經由同一傳輸的不同系統時，此慣例就無法奏效。發生這種情況時，內送連線不會與外寄連線所關聯的通道相關聯，因此對應的通道特性也不會與遠端系統相關聯。

switchchannel 關鍵字提供了解決此難題的方法。如果對伺服器使用的初始通道指定 switchchannel，連線 (原始) 主機的 IP 位址將對照通道表進行匹配，如果相符，則來源通道隨之變更。如果找不到相符的 IP 位址，或發現相符結果符合原始預設的送進的通道，則 MTA 可以選擇使用 DNS 反向查詢所找到的主機名稱來嘗試匹配。來源通道可以變更為標記了 switchchannel 或 allowswitchchannel (預設) 的任何通道。noswitchchannel 關鍵字指定不應自該通道進行切換，也不應切換至該通道。

switchchannel 的規格對於伺服器依預設關聯的通道以外的任何通道都無效。目前，switchchannel 僅影響 SMTP 通道，但實際上也沒有其他通道適合使用 switchchannel。

目標主機選擇

關鍵字：daemon、single 和 single_sys

daemon 關鍵字的解譯與用法取決於其所套用之通道的類型。

daemon 關鍵字用於 SMTP 通道，可控制目標主機的選擇。

通常，通道會連線至要處理的郵件之訊息封位址中列出的任一台主機。daemon 關鍵字用於告知通道改為連線特定的遠端系統，通常是防火牆或郵件中心系統，而不論訊息封位址為何。實際的遠端系統名稱應直接出現在 daemon 關鍵字之後，如以下範例所示：

tcp_firewall smtp mx daemon firewall.acme.com
TCP-DAEMON

如果 daemon 關鍵字之後的引數並非完全合格的網域名稱，該引數會被忽略，而通道將連線至其正式主機。正式主機是與通道相關的完全合格的主機名稱。它可以在三行通道區塊的第二行中進行指定：

tcp_firewall smtp mx daemon router
firewall.acme.com
TCP-DAEMON

正式主機也可以在兩行通道區塊的 TCP-DAEMON 之後指定，因此，外寄連線將其做為特定主機來識別自己：

tcp_firewall smtp mx daemon router
TCP-DAEMON firewall.acme.com

指定防火牆或閘道系統名稱做為正式主機名稱時，通常將指定給 daemon 關鍵字的引數指定為路由器，如下例所示：

tcp_firewall smtp mx daemon router
firewall.acme.com
TCP-DAEMON

其他所需關鍵字為 single 和 single_sys。single 關鍵字指定將為通道中的每個目標位址建立單份郵件副本。single_sys 關鍵字為使用的每個目標系統建立單份郵件副本。請注意，不論使用的關鍵字為何，都要為郵件形成佇列時所在的每個通道至少建立一份郵件副本。

SMTP 認證、SASL 與 TLS

關鍵字：maysaslserver、mustsaslserver、nosasl、nosaslserver、saslswitchchannel 和 nosaslswitchchannel)

可以使用 SASL ( 簡易認證和安全層) 控制 Messaging Server 是否支援 SMTP 伺服器認證。SASL 定義於 RFC 2222 中，如需有關 SASL、SMTP 認證和安全性的更多資訊，請參閱第 19 章, 配置安全性和存取控制。

maysaslserver、mustsaslserver、nosasl、nosaslserver、switchchannel 和 saslswitchchannel 通道關鍵字可用於將 SASL (SMTP AUTH) 配置為可由 SMTP 通道 (例如 TCP/IP 通道) 在 SMTP 協定期間使用。

nosasl 為預設，表示不允許或不嘗試 SASL 認證。它包含 nosaslserver，該關鍵字表示不允許 SASL 認證。指定 maysaslserver 會使 SMTP 伺服器允許用戶端嘗試使用 SASL 認證。指定 mustsaslserver 可使 SMTP 伺服器堅持要求用戶端使用 SASL 認證；除非遠端用戶端認證成功，否則 SMTP 伺服器不接受郵件。

使用 saslswitchchannel 可使內送連線在用戶端成功使用 SASL 時切換至指定的通道。它接受所需的值，以指定要切換至哪個通道。

使用標頭中 SMTP AUTH 的經認證的位址

關鍵字：authrewrite

authrewrite 通道關鍵字和相關的 AUTH_REWRITE 對映表允許使用從認證作業獲得的定址資訊修改標頭和訊息封位址。具體來說，SASL 可以將認證配置為提供授權的電子郵件位址。通常會使用 SMTP AUTH 資訊，雖然也可以透過 FROM_ACCESS 對映來置換該資訊。authrewrite 關鍵字根據表 12–23 接受所需位元值。

應嚴格限制 $Z 旗標，因為其很少正式用於修改訊息封和標頭位址。

指定 Microsoft Exchange 閘道通道

關鍵字：msexchange 和 nomsexchange

msexchange 通道關鍵字可用於 TCP/IP 通道，告知 MTA 此通道與 Microsoft Exchange 閘道和用戶端進行通訊。置於已啟用 SASL (透過 maysaslserver 或 mustsaslserver 關鍵字) 的內送 TCP/IP 通道時，它會導致 MTA 的 SMTP 伺服器使用「不正確的」格式 (根據原始 ESMTP AUTH 規格而不是新的已校正 AUTH 規格，原始 ESMTP AUTH 實際上與正確的 ESMTP 用法不相容) 通告 AUTH。例如，某些 Microsoft Exchange 用戶端無法識別正確的 AUTH 格式，僅能識別錯誤的 AUTH 格式。

msexchange 通道關鍵字還會通告 (和識別) 中斷的 TLS 指令。

nomsexchange 為預設。

傳輸層安全

關鍵字：maytls、maytlsclient、maytlsserver、musttls、musttlsclient、musttlsserver、notls、notlsclient、notlsserver 和 tlsswitchchannel

maytls、maytlsclient、maytlsserver、musttls、musttlsclient、 musttlsserver、notls、notlsclient、notlsserver 和 tlsswitchchannel 通道關鍵字可用於將 TLS 配置為由基於 SMTP 的通道 ( 例如 TCP/IP 通道) 在 SMTP 協定期間使用。

預設為 notls，表示不允許或不嘗試使用 TLS。它包含 notlsclient 關鍵字，該關鍵字表示 MTA SMTP 用戶端不會對外寄連線嘗試使用 TLS (在外寄連線期間不會發出 STARTTLS 指令)；還包含 notlsserver 關鍵字，該關鍵字表示 MTA SMTP 伺服器不會對內送連線允許使用 TLS (STARTTLS 延伸不會被 SMTP 伺服器通告，指令本身也不會被接受)。

指定 maytls 會使 MTA 為內送連線提供 TLS 並對外寄連線嘗試 TLS。它包含 maytlsclient，該關鍵字表示 MTA SMTP 用戶端在傳送外寄郵件時，如果是傳送給支援 TLS 的 SMTP 伺服器，則將嘗試使用 TLS；還包含 maytlsserver，該關鍵字表示 MTA SMTP 伺服器將通告支援 STARTTLS 延伸，並允許在接收郵件時使用 TLS。

請注意，為了使 TLS 發揮作用，必須滿足以下條件：

• 必須設定憑證的保護/所有權，使 mailsrv 帳號可以存取檔案。

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

指定 musttls 會使 MTA 堅持要求對外寄與內送連線都使用 TLS；如果無法與遠端系統成功協商 TLS 的使用，則不會與之交換電子郵件。它包含 musttlsclient，該關鍵字表示 MTA SMTP 用戶端在傳送外寄郵件時，將堅持要求使用 TLS，並且不會將郵件傳送至未能成功協商使用 TLS 的 SMTP 伺服器 (MTA 將發出 STARTTLS 指令，而且該指令必須成功)。它還包含 musttlsserver，該關鍵字表示 MTA SMTP 伺服器在接收內送郵件時，將通告支援 STARTTLS 延伸，並會堅持要求使用 TLS，且不會接受來自未能成功協商使用 TLS 的用戶端的郵件。

tlsswitchchannel 關鍵字用於使內送連線在用戶端成功協商 TLS 時切換至指定的通道。它接受所需的值，以指定要切換至哪個通道。

配置郵件處理和遞送

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

• 設定通道定向性

• 實作延遲遞送日期

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

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

• 服務工作限制

• 基於大小的郵件優先順序

• SMTP 通道執行緒

• 多位址延伸

• 啟用服務轉換

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

配置郵件處理和遞送概括了本小節說明的關鍵字。

設定通道定向性

關鍵字：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 對進入此通道的郵件啟用服務轉換。

配置位址處理

本節描述用於位址處理的關鍵字。包含以下各節：

• 啟用服務轉換

• 位址類型和慣例

• 解譯使用 ! 和 % 的位址

• 在位址中新增路由資訊

• 停用明確的路由位址之重寫功能

• 郵件移出佇列時重寫位址

• 指定校正不完整的位址時要使用的主機名稱

• 合法化無收件者標頭行的郵件

• 刪除非法空白收件者標頭

• 啟用通道特定的反向資料庫用途

• 啟用有限電子信箱編碼

• 產生 Return-path 標頭行

• 從訊息封 To 和 From 位址建構 Received 標頭行

• 處理位址標頭行中的註釋

• 處理位址標頭行中的個人名稱

• 指定 Alias 檔案和 Alias 資料庫探測

• 子位址處理

• 啟用通道特定的重寫規則檢查

• 移除來源路徑

• 指定位址必須來自別名

位址類型和慣例

關鍵字：822、733、uucp、 header_822、header_733 和 header_uucp

這組關鍵字控制通道支援的位址類型。傳輸層 (郵件訊息封) 中使用的位址和郵件標頭中使用的位址存在差異。

822 (sourceroute)

來源路徑訊息封位址。此通道支援完整 RFC 822 格式的訊息封定址慣例，包含來源路徑。關鍵字 sourceroute 也可做為 822 的同義詞。如果未指定其他訊息封位址類型關鍵字，則該關鍵字為預設。

733 (percents)

百分比符號訊息封位址。此通道支援完整 RFC 822 格式的訊息封定址慣例，但來源路徑除外；來源路徑必須使用百分比符號慣例來重寫。percents 也可做為 733 的同義詞。

在 SMTP 通道上使用 733 位址慣例會導致這些慣例在 SMTP 訊息封中的傳輸層位址上繼續存在。這樣可能會違背 RFC 821。只有在您確實需要時，才能使用 733 位址慣例。

uucp (bangstyle)

樣式訊息封位址。此通道在訊息封中使用符合 RFC 976 樣式位址慣例的位址 (例如 UUCP 通道)。bangstyle 關鍵字也可做為 uucp 的同義詞。

header_822

來源路徑標頭位址。此通道支援完整 RFC 822 格式的標頭定址慣例，包含來源路徑。如果未指定其他標頭位址類型關鍵字，則該關鍵字為預設。

header_733

百分比符號標頭位址。此通道支援 RFC 822 格式的標頭定址慣例，但來源路徑除外；來源路徑必須使用百分比符號慣例來重寫。

在郵件標頭中使用 733 位址慣例可能會違背 RFC 822 和 RFC 976。只有在您確定該通道連線至無法處理來源路徑位址的系統時，才能使用此關鍵字。

header_uucp

UUCP 或樣式標頭位址。建議不要使用此關鍵字。使用此關鍵字會違背 RFC 976。

解譯使用 ! 和 % 的位址

關鍵字：bangoverpercent、nobangoverpercent 和 percentonly

系統始終會根據 RFC 822 和 RFC 976 解譯位址。但是，對於上述標準無法定址的某些複合位址，在處理時會存在分歧。具體來說，A!B%C 形式的位址可解譯為：

• A 為路由主機，C 為最終目標主機

或

• C 為路由主機，A 為最終目標主機

雖然 RFC 976 隱含郵件程式可以使用後一組慣例來解譯位址，但並未表示這種解譯是必需的。在某些情況下，使用前面的解譯可能更好。

bangoverpercent 關鍵字強制執行前面的 A!(B%C) 解譯。nobangoverpercent 關鍵字強制執行後面的 (A!B)%C 解譯。nobangoverpercent 為預設。

此關鍵字不會影響對 A!B@C 形式的位址之處理。這些位址始終被視為 (A!B)@C。RFC 822 和 RFC 976 均指定了此種處理方式。

percentonly 關鍵字會忽略 bang 路徑。設定此關鍵字後，百分比會被解譯，以進行路由。

在位址中新增路由資訊

關鍵字：exproute、noexproute、improute 和 noimproute

MTA 所處理的定址模型假定所有系統均知悉其他所有系統的位址並瞭解如何到達這些系統。不幸的是，這種設想無法適用於所有情況，例如當通道連線至一個或多個不瞭解外界情形的系統 (例如，專用 TCP/IP 網路中的內部機器) 時。此通道上的這些系統位址在該站點以外的遠端系統上可能不合法。如果您希望能回覆這類位址，則這類位址必須包含來源路徑，告知遠端系統透過本地機器路由郵件。然後本地機器就會 (自動) 將郵件路由至這些機器。

exproute 關鍵字 (「明確路由」的縮寫形式) 告知 MTA，當關聯通道的位址被傳送至遠端系統時，該通道需要明確的路由。如果對通道指定了此關鍵字，MTA 會將包含本機系統名稱 (或本機系統目前的別名) 的路由資訊增加至匹配此通道的所有標頭位址與所有訊息封 From: 位址中。noexproute 為預設，指定不增加路由資訊。

EXPROUTE_FORWARD 選項可用於將 exproute 的動作限制為 反向指向位址。當 MTA 透過無法為自身執行正確路由的通道連線至系統時，會發生另一種情況。在這種情況下，當郵件傳送至的通道連線至能力不足的系統時，必須為郵件中使用的所有關聯其他通道的位址指示路由。

隱式路由和 improute 關鍵字可用於處理此情況。MTA 瞭解，當所有匹配其他通道的位址用於傳送至標記為 improute 之通道的郵件時，都需要路由。預設為 noimproute，指定經指定不在通道發出的郵件之位址中增加路由資訊。IMPROUTE_FORWARD 選項可用於將 improute 的動作限制為反向指向位址。

exproute 和 improute 關鍵字應謹慎使用。這些關鍵字會使位址更長、更複雜，並可能使其他系統所使用的智慧路由方案失敗。明確的路由和隱式路由不應與指定路徑產生混淆。指定路徑用於將重寫規則中的路由資訊插入位址中。這由特殊的 A@B@C 重寫規則範本啟動。

指定路徑啟動後可套用至標頭與訊息封中的所有位址。指定路徑由特殊的重寫規則來啟動，因此通常與目前使用的通道無關。另一方面，明確和都是針對通道進行控制的，插入的路由位址始終是本機系統。

停用明確的路由位址之重寫功能

關鍵字：routelocal

將位址重寫至通道時，routelocal 通道關鍵字會使 MTA 嘗試讓位址中任何明確的路由「短路」。明確路由的位址 (使用 !、% 或 @ 字元) 已簡化。

對「內部」通道 (例如內部 TCP/IP 通道) 使用此關鍵字可使轉送阻斷功能的配置更為簡單。

請注意，此關鍵字不應用於可能需要明確的 % 或其他路由的通道。

郵件移出佇列時重寫位址

關鍵字：connectalias 和 connectcanonical

MTA 通常會在郵件於其通道上形成佇列時重寫位址。郵件移出佇列期間不會執行額外的重寫。當主機名稱變更，而通道佇列中存在仍要傳送至舊名稱的郵件時，就會發生潛在的問題。

connectalias 關鍵字告知 MTA 傳送至收件者位址中列出的任何主機。這是預設。關鍵字 connectcanonical 告知 MTA 連線 MTA 可以連線的系統之主機別名。

指定校正不完整的位址時要使用的主機名稱

關鍵字：remotehost、noremotehost、defaulthost 和 nodefaulthost

MTA 通常會接收來自錯誤配置或不符合的郵件程式和 SMTP 用戶端的不包含網域名稱的位址。MTA 會在允許這些位址繼續傳送之前，嘗試將它們合法化。MTA 會透過在位址上附加網域名稱來達此目的 (例如，將 @siroe.com 附加至 mrochek)。

對於缺少網域名稱的訊息封 To: 位址，MTA 始終會假設應附加本地主機名稱。而對於其他位址 (例如 From: 位址)，如果是 MTA SMTP 伺服器，則至少有兩個合理的網域名稱選擇：本地 MTA 主機名稱和用戶端 SMTP 報告的遠端主機名稱。或在某些情況下，可能還有第三個合理的選項，亦即將特定的網域名稱增加至進入該通道的郵件。目前，前兩個選擇都可能是正確的，因為這兩者可能發生的機率較高。處理配置不正確的 SMTP 用戶端時，適合使用遠端主機的網域名稱。處理簡易遠端郵件用戶端 (例如使用 SMTP 傳送郵件的 POP 或 IMAP 用戶端) 時，適合使用本地主機的網域名稱。或者，如果是簡易遠端郵件用戶端 (例如 POP 或 IMAP)，用戶端應具有自己特定的網域名稱，此網域名稱並非本地主機的網域名稱，則可能適合加入特定的其他網域名稱。MTA 最理想的做法是允許逐個通道地進行選擇。

noremotehost 通道關鍵字指定應使用本地主機名稱。noremotehost 關鍵字為預設。

defaulthost 通道關鍵字用於指定特定主機名稱，以附加至不含網域名稱的內送使用者 ID。使用者 ID 後必須加上網域名稱，才能成為完整的位址 (訊息封 From: 和標頭中的位址) 進入該通道。(在提交通道中，defaulthost 關鍵字的第一個引數也會影響不含網域名稱的訊息封 To: 位址)。可以指定第二個網域名稱 (其中至少有一個小數點號)，用於使訊息封 To: 位址完整。nodefaulthost 為預設。

如之前內送郵件的替代通道 (切換通道)一節所述，switchchannel 關鍵字會將內送 SMTP 連線與特定通道相關聯。此功能可用於在通道上群組遠端郵件用戶端，在此通道上，它們可以得到適當的處理。或者，較簡單的做法是部署符合標準的遠端郵件用戶端 (即便使用了多個不符合的用戶端)，而非嘗試修正 MTA 主機上的整個網路的問題。

合法化無收件者標頭行的郵件

關鍵字：missingrecipientpolicy

RFC 822 (網際網路) 郵件必須包含收件者標頭行：To:、Cc: 或 Bcc: 標頭行。沒有上述標頭行的郵件是非法的。但是，有些不可靠的使用者代理程式和郵件程式 (例如，許多舊版 sendmail) 會傳送非法的郵件。

missingrecipientpolicy 關鍵字接受整數值，指定處理此類郵件的方法；如果未明確指定此關鍵字，則預設為 1 (原封不動地傳送非法郵件)。

請注意，可使用 MISSING_RECIPIENT_POLICY 選項將 MTA 系統預設為此運作方式。Messaging Server 的初始配置將 MISSING_RECIPIENT_POLICY 設定為 1。

刪除非法空白收件者標頭

關鍵字：dropblank 和 nodropblank

在 RFC 822 (網際網路) 郵件中，任何 To:、Resent-To:、Cc: 或 Resent-Cc: 標頭均需要包含至少一個位址，亦即標頭的值不得為空。但是，有些郵件程式可以傳送這類非法標頭。如果對來源通道指定 dropblank 通道關鍵字，則會使 MTA 刪除內送郵件中所有此類非法的空白標頭。

啟用通道特定的反向資料庫用途

關鍵字：reverse、noreverse

reverse 關鍵字會告知 MTA，如果存在位址反向資料庫或 REVERSE 對映，則在通道上形成佇列的郵件之位址應由位址反向資料庫或 REVERSE 對映進行檢查，可能還會予以修改。noreverse 使通道上形成佇列的郵件中之位址免於進行位址反向處理。reverse 關鍵字為預設。請參閱將位址從內部格式轉換為公用格式

啟用有限電子信箱編碼

關鍵字：restricted、unrestricted

有些郵件系統很難處理 RFC 822 所允許的全部位址類型。尤其常見的範例是配置檔案不正確的基於的郵件程式。加引號的本機部分 (或 電子信箱規格) 經常出現問題：

"smith, ned"@siroe.com

在 RFC 1137 中已經有方法可以解決這種麻煩之源。基本方法是從位址中移除引號，然後進行轉譯，將需要引號的字元對映至原子中允許的字元 (請參閱 RFC 822，以瞭解有關原子在此處使用時的定義)。例如，上述位址會變成：

smith#m#_ned@siroe.com

restricted 通道關鍵字告知 MTA 該通道會連線需要此編碼的郵件系統。然後，MTA 會在郵件寫入至通道時，對標頭位址和訊息封位址中加引號的本機部分進行編碼。而此通道上送進的位址會被自動解碼。unrestricted 關鍵字告知 MTA 不執行 RFC 1137 編碼和解碼。unrestricted 關鍵字為預設。

restricted 關鍵字應套用於連線無法接受加引號的本機部分的系統之通道。而不適用於實際產生加引號之本機部分的通道。(據假定，能夠產生此種位址的通道也能夠處理此種位址。)

產生 Return-path 標頭行

關鍵字：addreturnpath 和 noaddreturnpath

通常，增加 Return-path: 標頭行由執行最終傳送的通道負責。但對於某些通道 (例如 ims-ms 通道)，由 MTA 增加 Return-path: 標頭比讓通道執行增加動作更有效。addreturnpath 關鍵字可使 MTA 在此通道上形成佇列時，增加 Return-path: 標頭。

從訊息封 To 和 From 位址建構 Received 標頭行

關鍵字：receivedfor、noreceivedfor、receivedfrom 和 noreceivedfrom

receivedfor 關鍵字會指示 MTA，如果郵件只傳送給一位訊息封收件者，則在其建構的Received: 標頭行中包含訊息封 To: 位址。receivedfor 關鍵字為預設。noreceivedfor 關鍵字指示 MTA 建構 Received: 標頭行，但不包含任何訊息封位址資訊。

receivedfrom 關鍵字指示 MTA，如果 MTA 出於某些原因 (例如某種郵件收信人清單擴充) 變更了訊息封 From:位址，則在為內送郵件建構 Received: 標頭行時，包含原始訊息封的 From: 位址。receivedfrom 為預設。noreceivedfor 關鍵字指示 MTA 建構 Received: 標頭行，但不包含原始訊息封 From: 位址。

處理位址標頭行中的註釋

關鍵字：commentinc、commentmap commentomit、commentstrip、commenttotal、 sourcecommentinc、sourcecommentmap、sourcecommentomit、sourcecommentstrip 和 sourcecommenttotal

只有在必要時才解譯標頭行的內容。但是所有包含位址的已註冊標頭行都必須被剖析以重寫並消除縮寫形式的位址，否則就轉換成合法位址。在此過程中，如果重建標頭行，會擷取註釋 (括號中的字串)，並可能對註釋進行修改或排除。

使用 commentinc、commentmap、commentomit、commentstrip 和 commenttotal 關鍵字可控制此運作方式。commentinc 關鍵字告知 MTA 保留標頭行中的註釋。這是預設。關鍵字 commentomit 告知 MTA 移除定址標頭 (例如，To:、From: 或 Cc: 標頭行) 中的所有註釋。

關鍵字 commenttotal 告知 MTA 移除所有標頭行 (Received: 標頭行除外) 中的所有註釋；通常不使用或不建議使用此關鍵字。commentstrip 關鍵字告知 MTA 刪除所有註釋欄位中的所有不可分割字元。commentmap 關鍵字透過 COMMENT_STRINGS 對映表來執行註釋字串。

對來源通道，可使用 sourcecommentinc、sourcecommentmap、sourcecommentomit、sourcecommentstrip 和 sourcecommenttotal 關鍵字來控制此運作方式。sourcecommentinc 關鍵字指示 MTA 保留標頭行中的註釋。這是預設。sourcecommentomit 關鍵字指示 MTA 移除定址標頭 (例如 To:、From: 和 Cc: 標頭) 中的所有註釋。關鍵字 sourcecommenttotal 指示 MTA 移除所有標頭 (Received: 標頭除外) 中的所有註釋；通常不使用或不建議使用此關鍵字。最後，sourcecommentstrip 關鍵字指示 MTA 刪除所有註釋欄位中的所有不可分割字元。sourcecommentmap 關鍵字透過來源通道執行註釋字串。

這些關鍵字適用於任何通道。

COMMENT_STRINGS 對映表的語法如下所示：

(comment_text) | address

如果項目範本設定 $Y 旗標，則原始註釋將被指定的文字 (該文字應包括外圍的括號) 取代。

處理位址標頭行中的個人名稱

關鍵字：personalinc、personalmap、personalomit、personalstrip、 sourcepersonalinc、sourcepersonalmap、sourcepersonalomit 和 sourcepersonalstrip

在重寫過程中，所有包含位址的標頭行都必須被剖析以重寫並消除縮寫形式的位址，否則就轉換成合法位址。在此過程中，如果重建標頭行，則會擷取個人名稱 (角括號分隔的位址之前的字串)，並可以對個人名稱進行選擇性修改或排除。

可以使用 personalinc、personalmap、personalomit 和 personalstrip 關鍵字控制此運作方式。關鍵字 personalinc 告知 MTA 保留標頭中的個人名稱。這是預設。關鍵字 personalomit 告知 MTA 移除所有個人名稱。關鍵字 personalstrip 告知 MTA 刪除所有個人名稱欄位中的所有非原子字元。personalmap 關鍵字指示 MTA 透過 PERSONAL_NAMES 對映表執行個人名稱。

對於來源通道，可以使用 sourcepersonalinc、sourcepersonalmap、sourcepersonalomit 或 sourcepersonalstrip 關鍵字控制此運作方式。sourcepersonalinc 關鍵字指示 MTA 保留標頭中的個人名稱。這是預設。sourcepersonalomit 關鍵字指示 MTA 移除所有個人名稱。最後，sourcepersonalstrip 指示 MTA 刪除所有個人名稱欄位中的所有非原子字元。sourcepersonalmap 關鍵字指示 MTA 透過來源通道執行個人名稱。

這些關鍵字適用於任何通道。

PERSONAL_NAMES 對映表探測的語法如下：

personal_name | address

如果範本設定 $Y 旗標，則原始個人名稱將被指定的文字取代。

指定 Alias 檔案和 Alias 資料庫探測

關鍵字：aliaslocal

通常，只有重寫至本機通道 (即 UNIX 上的 l 通道) 的位址會在檔案和資料庫供人查詢。aliaslocal 關鍵字可置於某個通道，使重寫至該通道的位址在 Alias 檔案和 Alias 資料庫中供人查詢。而所建立的查詢探測之精確形式由 ALIAS_DOMAINS 選項控制。

子位址處理

關鍵字：subaddressexact、subaddressrelaxed 和 subaddresswild

根據子位址的概念，原生通道和 ims-ms 通道會解譯位址 (尤其是 name+subaddress@domain 形式的位址) 本機部分 (電子信箱部分) 中的 + 字元，MTA 會將加號字元後面的電子信箱部分視為子位址。原生通道會將子位址視為額外的表面資訊，實際遞送至帳號名稱，而與子位址無關；ims-ms 通道會將子位址解譯為要遞送至的資料夾名稱。

子位址還會影響到依本機通道 (即 UNIX 上的 L 通道) 的別名查詢、依 aliaslocal 關鍵字標記的任何通道的別名查詢，以及依目錄通道的電子信箱查詢。對此類匹配的子位址之確切處理是可配置的：比對位址與項目時，MTA 始終先檢查整個電子信箱包括子位址是否完全相符；之後 MTA 是否要執行額外的檢查，則是可配置的。

subaddressexact 關鍵字指示 MTA 在項目匹配期間，不執行特殊的子位址處理；整個電子信箱，包括子位址，都必須匹配項目，這樣才能將別名視為匹配。額外的比對 (尤其是萬用字元比對或移除子位址的比對) 不會執行。subaddresswild 關鍵字指示 MTA 在尋找包括整個子位址都完全匹配的項目後，接著應尋找 name+* 形式的項目。subaddressrelaxed 關鍵字指示 MTA 在尋找完全匹配的項目、且尋找了匹配 name+* 形式的項目之後，應額外檢查名稱部分是否匹配。使用 subaddressrelaxed，以下形式的別名項目匹配名稱或名稱+子位址形式，一般名稱會轉變成新名稱，而名稱+子位址會轉變成新名稱+子位址。subaddressrelaxed 關鍵字為預設。

name:   newname+*

因此，當別名或目錄通道正在使用中，而使用者希望接收使用任意子位址傳送的郵件時，subaddresswild 關鍵字或 subaddressrelaxed 關鍵字可能會有用。這兩個關鍵字使您不必為位址上各個子位址變體設定單獨的項目。

請注意，這兩個關鍵字只對本機通道 (即 UNIX 上的 L 通道)、目錄通道或使用 aliaslocal 關鍵字標記的任一通道有意義。

標準 Messaging Server 配置在確實具有 subaddressrelaxed 運作方式 (如果未明確使用其他關鍵字，則為預設) 的 L 通道上轉送。

啟用通道特定的重寫規則檢查

關鍵字：rules、norules

rules 關鍵字告知 MTA 對此通道強制執行通道專用的重寫規則檢查。這是預設。norules 關鍵字告知 MTA 不對此通道執行檢查。這兩個關鍵字通常用於除錯，在實際應用中很少使用。

移除來源路徑

關鍵字：dequeue_removeroute

dequeue_removeroute 關鍵字可在郵件移出佇列時，從信息封 To: 位址中移除來源路由。此關鍵字目前僅對 tcp-* 通道實作。它可用於將郵件傳送至未正確處理來源路徑的系統。

指定位址必須來自別名

關鍵字：viaaliasoptional 和 viaaliasrequired

viaaliasrequired 指定匹配通道的所有最終收件者位址必須由別名產生。最終收件者位址是指執行別名延伸 (如果有關) 之後的相符項目。該位址無法做為收件者位址直接傳送給 MTA；亦即對於位址而言，僅重寫至通道還不夠。重寫至通道之後，位址還必須透過被視為真正符合通道的別名來延伸。

例如，必須將 viaaliasrequired 關鍵字用於本機通道，以避免傳送至任意帳號 (例如 UNIX 系統上任意的原生 Berkeley 電子信箱)。

預設為 viaaliasoptional，表示匹配通道的最終收件者位址不需要由別名產生。

配置標頭處理

本節描述用於處理標頭和訊息封資訊的關鍵字。包含以下各節：

• 重寫內嵌式標頭

• 移除選取的郵件標頭行

• 產生/移除 X-Envelope-to 標頭行

• 轉換日期為兩位數或四位數

• 在日期中指定星期

• 自動分割長標頭行

• 標頭對齊和摺疊

• 指定標頭最大長度

• 敏感性檢查

• 設定標頭中的預設語言

重寫內嵌式標頭

關鍵字：noinner、inner

只有在必要時才會解譯標頭行的內容。但是，由於 MIME 郵件中可以嵌入郵件 (郵件/RFC822)，因此可以包含多組郵件標頭。MTA 通常只會解譯和重寫最外面一組郵件標頭。也可以選擇告知 MTA 將標頭重寫套用於郵件中的內部標頭。

可以使用 noinner 和 inner 關鍵字來控制此運作方式。關鍵字 noinner 告知 MTA 不重寫內部郵件標頭行。這是預設。關鍵字 inner 告知 MTA 剖析郵件並重寫內部標頭。這些關鍵字適用於任何通道。

移除選取的郵件標頭行

關鍵字：headertrim、noheadertrim、headerread、noheaderread、innertrim 和 noinnertrim

MTA 提供針對各通道在郵件中修整或移除選取的郵件標頭行的功能。此功能透過通道關鍵字與一個或兩個關聯標頭選項檔案組合而實現。「Sun Java System Messaging Server 6 2005Q4 Administration Reference」中的「Header Option Files」。

headertrim 關鍵字指示 MTA 在處理原始郵件標頭之後，諮詢與通道關聯的標頭選項檔案，並相應地修整已在目標通道上形成佇列的郵件之標頭。noheadertrim 關鍵字會略過標頭修整。noheadertrim 關鍵字為預設。

innertrim 關鍵字還指示 MTA 對內部郵件部分 (亦即內嵌的 MESSAGE/RFC822 部分) 執行標頭修整。noinnertrim 關鍵字為預設，告知 MTA 不對內部郵件部分執行任何標頭修整。

headerread 關鍵字指示 MTA 在處理原始郵件標頭之前，諮詢與通道關聯的標頭選項檔案，並相應地修整由來源通道形成佇列的郵件中的標頭。請注意，另一方面，headertrim 標頭修整是在處理郵件之後套用的，而且是針對目標通道而非來源通道。noheaderread 關鍵字會略過形成佇列的郵件之標頭修整。noheaderread 為預設。

與 headeromit 和 headerbottom 關鍵字不同，headertrim 和 headerread 關鍵字適用於任何通道。但請注意，刪除郵件中的重要標頭資訊，可能會導致 MTA 作業發生錯誤。當您選擇移除或限制標頭時，必須極其謹慎。此功能的存在是因為偶爾會有一些情況，必須要移除或限制選取的標頭行。

刪除郵件中的標頭資訊可能會導致 MTA 作業發生錯誤。當您選擇移除或限制標頭時，必須謹慎。在一些罕見的情況下，必須移除或限制選取的標頭行，這些關鍵字就是為此而提供的。修整或移除任何標題行之前，您必須瞭解標頭行的用法，並考量移除該標題行可能會牽涉到哪些方面。

headertrim 和 innertrim 關鍵字之標頭選項檔案的名稱形式為 channel_headers.opt，其中 channel 是標頭選項檔案關聯的通道名稱。同樣，headerread 關鍵字之標頭選項檔案的名稱形式為 channel_read_headers.opt。這些檔案儲存在 MTA 配置目錄 instance_root/imta/config/ 中。

產生/移除 X-Envelope-to 標頭行

關鍵字：x_env_to、nox_env_to

x_env_to 和 nox_env_to 關鍵字控制在特定通道上形成佇列之郵件副本中 X-Envelope-to 標頭行的產生和抑制。在使用 single 關鍵字標記的通道上，x_env_to 關鍵字可產生這些標頭，而 nox_env_to 則從形成佇列的郵件中移除此類標頭。預設為 nox_env_to。

x_env_to 關鍵字還需要 single 關鍵字才能生效。

轉換日期為兩位數或四位數

關鍵字：datefour、datetwo

原始 RFC 822 規格在郵件標頭的日期欄位中需要兩位數年份。後來 RFC 1123 將其變更為四位數。但是，某些較舊的郵件系統無法使用四位數日期。此外，一些較新的郵件系統無法再接受兩位數日期。

無法處理這兩種格式的系統是違反標準的。

datefour 和 datetwo 關鍵字控制 MTA 對郵件標頭日期中年份欄位的處理方式。關鍵字 datefour 為預設，指示 MTA 將所有年份欄位擴充為四位數。小於 50 的兩位數日期加上 2000，大於 50 的則加上 1900。

關鍵字 datetwo 指示 MTA 移除四位數日期中的前兩位數。這是為了與需要兩位數日期的不符合郵件系統相容；不應用於其他任何目的。

在日期中指定星期

關鍵字：dayofweek、nodayofweek

RFC 822 規格允許在郵件標頭的日期欄位前面加上星期規格。但是，有些系統無法適應星期資訊。這使某些系統不願納入此資訊，即使此資訊在標頭中非常有用。

dayofweek 和 nodayofweek 關鍵字控制 MTA 對星期資訊的處理。關鍵字 dayofweek 為預設，指示 MTA 保留任何星期資訊，如果日期和時間標頭中缺少此資訊，則增加此資訊。

關鍵字 nodayofweek 指示 MTA 從日期和時間標頭中移除前面的所有星期資訊。這是為了與無法正確處理此資訊的不符合郵件系統相容；不應用於其他任何目的。

自動分割長標頭行

關鍵字：maxheaderaddrs、maxheaderchars

某些郵件傳送程式 (尤其是某些實作) 無法正確處理長標頭行。這不但經常造成標頭損毀，還造成錯誤的郵件拒絕。雖然嚴重違反標準，但卻是一個常見問題。

MTA 提供針對通道將長標頭行分割 (換行) 為多個各自獨立的標頭行的功能。maxheaderaddrs 關鍵字控制一行中可以顯示的位址數。maxheaderchars 關鍵字控制一行中可以顯示的字元數。這兩個關鍵字都需要單一整數參數，以指定相關限制。依預設，標頭行的長度和可以顯示的位址數均無限制。

標頭對齊和摺疊

關鍵字：headerlabelalign、headerlinelength

headerlabelalign 關鍵字控制在此通道上形成佇列的郵件標頭之對齊點；其為值為整數的引數。對齊點就是標頭內容對齊時的邊界。例如，對齊點為 10 的範例標頭行外觀如下：

To:       joe@siroe.com
From:     mary@siroe.com
Subject:  Alignment test
         

預設 headerlabelalign 為 0，這將使標頭不會對齊。headerlinelength 關鍵字可控制在此通道上形成佇列的郵件標頭行的長度。超過此長度的行根據 RFC 822 摺疊規則進行摺疊。

這些關鍵字僅控制郵件佇列中郵件的標頭格式；標頭的實際顯示通常由使用者代理程式控制。此外，標頭在網際網路上傳送時會依慣例重新格式化，因此這些關鍵字即使與不重新格式化郵件標頭的簡易使用者代理程式一併使用，可能也沒有什麼明顯效果。

指定標頭最大長度

關鍵字：maxprocchars

處理包含大量位址的長標頭行會消耗大量的系統資源。maxprocchars 關鍵字用於指定 MTA 可以處理和重寫的標頭之最大長度。標頭超過此長度的郵件仍會被接受和遞送；唯一不同之處是長標頭行不會進行任何重寫。需要單一整數引數。預設為處理任何長度的標頭。

敏感性檢查

關鍵字：sensitivitynormal、sensitivitypersonal、sensitivityprivate 和 sensitivitycompanyconfidential

敏感性檢查關鍵字可設定通道可接受之郵件的敏感性上限。預設為 sensitivitycompanyconfidential；可接受所有敏感性的郵件。沒有 Sensitivity: 標頭的郵件會被視為一般郵件，即最低敏感性的郵件。敏感性高於此關鍵字指定敏感性的郵件，在通道上形成佇列時會被拒絕，螢幕上會顯示以下錯誤訊息：

message too sensitive for one or more paths used

請注意，MTA 會針對每封郵件進行敏感性檢查，而非針對各收件者進行檢查：如果一位收件者的目標通道無法通過敏感性檢查，則對於所有的收件者，該郵件均被退回，而不只是針對與敏感通道關聯的那些收件者。

設定標頭中的預設語言

關鍵字：language

標頭中的編碼文字可以使用特定語言。language 關鍵字指定預設語言。

附件和 MIME 處理

本節描述用於處理附件和處理的關鍵字。包含以下各節：

• 忽略 Encoding 標頭行

• 郵件/部分郵件的自動重新整理

• 大型郵件的自動分段程序

• 設定郵件行長度限制

忽略 Encoding 標頭行

關鍵字：ignoreencoding、interpretencoding

MTA 可使用 Yes CHARSET-CONVERSION 將各種非標準郵件格式轉換為 MIME。尤其是，使用非標準 Encoding: 標頭行的 RFC 1154 格式。但是，有些閘道會在此標頭行上加入錯誤的資訊，從而導致有時忽略此標頭行更好。ignoreencoding 關鍵字指示 MTA 忽略任一 Encoding: 標頭行。

除非 MTA 已啟用 CHARSET-CONVERSION，否則此類標頭在任何情況下都會被忽略。interpretencoding 關鍵字可指示 MTA 注意任一 Encoding: 標頭行 (如果配置為執行此動作)，而且該關鍵字為預設。

郵件/部分郵件的自動重新整理

關鍵字：defragment、nodefragment

MIME 標準提供郵件部分內容類型以將郵件斷成較小的部分。郵件必須通過有大小限制或不可靠的網路時，這項功能會很有用，郵件分段程序提供「檢查點」表單，在網路於郵件傳輸期間發生故障時，可減少後續重複傳輸工作。每個部分均包含資訊，使郵件在到達目的地之後可以自動重新組合。

defragment 通道關鍵字和重新整理通道可用於在 MTA 中重新組合郵件。通道標記為 defragment 時，在通道上形成佇列的所有部分郵件都會改為置於重新整理通道佇列中。所有部分均到達之後，郵件就會重建並傳送出去。nodefragment 停用這種特殊處理。關鍵字 nodefragment 為預設。

重新整理通道保留時間

郵件僅在磁碟重新整理通道佇列中保留有限時間。如果第一條未投遞通知被傳送之前時間已過半，則郵件各部分無需重新組合即會繼續傳送。這種時間值的選擇會避免傳送有關磁碟重新整理通道佇列中郵件的未投遞通知。

notices 通道關鍵字控制傳送未傳送通知之前的時間長度，從而也控制按部分傳送郵件之前保留郵件的時間長度。請將 notices 關鍵字的值設定為希望保留郵件之時間長度的兩倍 (以進行可能的重新整理)。例如，notices 值為 4 時會將郵件片段保留兩天：

defragment notices 4 
DEFRAGMENT-DAEMON

大型郵件的自動分段程序

關鍵字：maxblocks、maxlines

有些電子郵件系統或網路傳送程式無法處理超過特定大小限制的郵件。MTA 提供可逐個通道地強加此類限制的功能。大於設定限制的郵件將會自動分割 (分段) 成多個較小的郵件。用於此類分段的內容類型為 message/partial，並且會增加唯一的 ID 參數，使同一郵件的各個部分互相關聯，並可以由接收郵件程式自動重新組合。

maxblocks 和 maxlines 關鍵字可用於強加大小限制，超過此限制便會啟動自動分段程序。這兩個關鍵字之後都必須有單一整數值。關鍵字 maxblocks 指定郵件中允許的最大區塊數量。MTA 區塊通常為 1024 個位元組；可以透過 MTA 選項檔案中的 BLOCK_SIZE 選項變更此值。關鍵字 maxlines 指定郵件中允許的最大行數。如有必要，可同時設定這兩個限制。

在某種程度上郵件標頭包含在郵件的大小中。由於郵件標頭無法分割成多封郵件，可是它們本身也可能超過指定的大小限制，因此有一種更複雜的機制用於計算郵件標頭大小。此邏輯由 MTA 選項檔案中的 MAX_HEADER_BLOCK_USE 和 MAX_HEADER_LINE_USE 選項控制。

MAX_HEADER_BLOCK_USE 用於指定 0 到 1 之間的實數。預設值為 0.5。郵件的標頭幾乎可以佔用郵件可消耗的區塊總數 (由 maxblocks 關鍵字指定)。如果郵件標頭超過此大小，MTA 會將 MAX_HEADER_BLOCK_USE 和 maxblocks 的乘積做為標頭的大小 (標頭 大小會使用實際標頭大小和 maxblocks 兩者中較小的值) * MAX_HEADER_BLOCK_USE。

例如，如果 maxblocks 為 10，而 MAX_HEADER_BLOCK_USE 為預設值 0.5，任何大於 5 個區塊的郵件標頭都會被視為 5 區塊標頭，而如果郵件大小等於或小於 5 個區塊，將不會被分段。數值 0 會使標頭在有關郵件大小限制範圍內被實際忽略。

數值 1 允許標頭用完所有可用的大小。每個分段始終至少包含一個郵件行而不論此郵件行是否超過限制。MAX_HEADER_LINE_USE 以類似的方式和 maxlines 關鍵字一同運作。

設定郵件行長度限制

關鍵字：linelength

SMTP 規格允許文字行最多包含 1000 個位元組。但是，有些傳送程式可以對行長度設定更嚴格的限制。linelength 關鍵字提供一種機制，可逐個通道地限制允許的最大郵件行長度。對於在給定通道上形成佇列的郵件，如果有行長度超過為該通道指定的限制，則該郵件會被自動編碼。

MTA 中可用的各種編碼總會使行長度縮減到 80 個字元以下。執行上述編碼之後，透過套用適當的解碼篩選器，即可回復原始郵件。

編碼僅能將行長度縮減到 80 個字元以下。低於 80 的行長度值規格可能無法正確產生長度符合指定限制的行。

linelength 關鍵字可使資料編碼執行「軟」換行，以進行傳輸。編碼通常是在接收端執行解碼，以回復原始「長」行。如需瞭解「硬」換行，請參閱表 13–7 中的「Record, text」。

對郵件、配額、收件者和認證嘗試次數的限制

本節描述用於設定郵件大小限制、使用者配額和權限的關鍵字。包含以下各節：

• 對不成功的認證嘗試的限制

• 指定絕對郵件大小限制

• 重定郵件大小或收件者超出限制的郵件之目標

• 處理對超過配額的使用者的郵件遞送

• 處理行長度超過 1000 個字元的 SMTP 郵件

• 控制一般和檔案名稱內容類型及內容處理參數的長度

• 限制郵件收件者

• 限制標頭大小

對不成功的認證嘗試的限制

關鍵字：disconnectbadauthlimit

此關鍵字可用於設定對中斷連線之前階段作業內所允許的未成功認證嘗試次數的限制。此選項的預設值為 3。

指定絕對郵件大小限制

關鍵字：blocklimit、noblocklimit、linelimit、nolinelimit, sourceblocklimit

雖然分段程序可以自動將郵件分割成較小的部分，但在有些情況下，拒絕超出某種管理上定義之限制的郵件更為合適 (例如，為了避免拒絕服務型侵入)。

blocklimit、linelimit 和 sourceblocklimit 關鍵字用於強加絕對大小限制。這些關鍵字之後都必須有單一整數值。

關鍵字 blocklimit 指定郵件中允許的最大區塊數目。MTA 會拒絕將所含區塊超過此限制的郵件在通道上形成佇列的嘗試。MTA 區塊通常為 1024 個位元組；可以透過 MTA 選項檔案中的 BLOCK_SIZE 選項變更此值。

關鍵字 sourceblocklimit 指定內送郵件中允許的最大區塊數目。MTA 會拒絕將所含區塊超過此限制的郵件提交給通道的嘗試。換言之，blocklimit 適用於目標通道；sourceblocklimit 適用於來源通道。一個 MTA 區塊通常為 1024 個位元組；可以使用 MTA 選項檔案中的 BLOCK_SIZE 選項變更此值。

也可以根據寄件者指定來源區塊限制，方法是：使用 MTA 選項 LDAP_SOURCEBLOCKLIMIT 指定使用者 LDAP 屬性，並將該屬性增加至寄件者 LDAP 項目。根據寄件者的網域，來源區塊限制也受支援。使用 MTA 選項 LDAP_DOMAIN_ATTR_SOURCEBLOCKLIMIT 指定網域 LDAP 屬性，並將此屬性增加至寄件者的網域 LDAP 項目。這些值均無預設。

關鍵字 linelimit 指定郵件中允許的最大行數。MTA 會拒絕將所含行數超過此限制的郵件在通道上形成佇列的嘗試。如有必要，可以同時強加 blocklimit 和 linelimit 關鍵字。

MTA 選項 LINE_LIMIT 和 BLOCK_LIMIT 可用於對所有通道強加類似限制。這些限制的優點是適用於所有通道。因此，MTA 伺服器可在獲取郵件收件者資訊之前，讓郵件用戶端得知各項限制。這樣可簡化某些協定中拒絕郵件的程序。

nolinelimit 和 noblocklimit 通道關鍵字為預設，表示除了使用 LINE_LIMIT 或 BLOCK_LIMIT MTA 選項強加的所有全域限制之外，不再設定其他任何限制。

重定郵件大小或收件者超出限制的郵件之目標

關鍵字：alternatechannel、alternateblocklimit、alternatelinelimit 和 alternaterecipientlimit

MTA 能夠將收件者數量、郵件大小或郵件行數超過指定限制的郵件之目標重定至替代目標通道。這項功能透過一組通道關鍵字來實作，它們是：alternatechannel、alternateblocklimit、alternatelinelimit 和 alternaterecipientlimit，這些關鍵字可置於任何目標通道上。alternatechannel 關鍵字使用單一引數，用於指定要使用的替代通道之名稱。其他每個關鍵字都需要一個整數引數，用於指定對應的臨界值。超過任何臨界值的郵件將在替代通道 (而非原始目標通道) 上形成佇列。

在以下通道區塊範例中，超過 5000 個區塊的大型郵件會從 tcp_big 通道而非 tcp_local 通道發往網際網路：

tcp_local smtp ...other keywords... alternatechannel tcp_big alternateblocklimit 5
tcp-daemon


tcp_big smtp ...rest of keywords...
tcp-big-daemon

以下是 alternate* 通道關鍵字的使用範例：

• 如果要延遲或在下班時間傳送大型郵件，可以控制 alternatechannel (例如，tcp_big) 的執行時間。

  一種方法是使用 imsimta qm 公用程式的 STOP channel_name 和 START channel_name 指令，透過您自己自訂的週期性工作 (由工作控制器執行) 或透過 cron 工作定期執行這些指令。

• 當您讓工作控制器處理自己池內的大型郵件或具有許多收件者的郵件時，也可以使用 alternatechannel。

  您可以將小型郵件或收件者很少的郵件與大型郵件或具有許多收件者的郵件分開，因為遠端 SMTP 伺服器在處理和接收後者時需要較長時間，您不會希望較大郵件延遲較小郵件的遞送。

  請注意，大多數配置中，工作控制器對郵件定期排程並將郵件指定給執行緒和程序都是可以接受的。

• 當您要為大型郵件或具有許多收件者的郵件設定特殊 TCP/IP 通道逾時值時，可以使用 alternatechannel。

  尤其是，如果您要傳送郵件至遠端主機，而這些主機需要極長的時間來接收大型郵件或具有許多收件者的郵件，那麼設定特殊 TCP/IP 通道逾時值會很有用。

  請注意，對大多數配置而言預設的自動逾時調整就已足夠。最多是您會想調整預設值，並且不使用特殊通道。特請參閱「Sun Java System Messaging Server 6 2005Q4 Administration Reference」中的通道選項 STATUS_DATA_RECV_PER_ADDR_TIME 和 STATUS_DATA_RECV_PER_BLOCK_TIME。

• 如果要對特大型郵件進行特殊的 MIME 郵件分段程序，可以使用 alternatechannel 和 alternateblocklimit 通道關鍵字以及 maxblocks 通道關鍵字。

  通常，要對超過指定大小的郵件分段時，可以對定期外寄 TCP/IP 通道設定所需的 maxblocks 大小。maxblocks 通道關鍵字通常既是執行分段程序的臨界值，又是進行分段的大小。

  但是，如果想擁有較大的臨界值觸發器，而實際執行較小的分段，可以對外寄 TCP/IP 通道使用 alternatechannel 和 alternateblocklimit。然後，可以對替代通道使用 maxblock 大小，以對超過特定大小的郵件分段。

• 可以將 alternatechannel 與特殊的篩選作業配合使用。例如，可能需要更仔細地審查具有許多收件者的郵件的內容，以避免垃圾郵件。您可能想根據外寄通道執行不同的篩選作業 (請參閱指定電子信箱篩選器檔案位置中的 destinationfilter 通道關鍵字)。

  如果您要經由轉換通道執行資源相對密集的掃描作業 (例如病毒篩選)，郵件過大就可能導致資源問題。您可以使用替代轉換通道。或者，您可能想根據外寄通道，在常規轉換通道中執行特殊的轉換程序。

• 要將大型外寄的郵件從它們自己的通道發出時，可以使用 alternatechannel，如此一來，當您分析 mail.log* 檔案或在計數器上顯示時，這些郵件會特別明顯。

  此外，如果您嘗試仔細分析遞送統計資料，在大型郵件自己的通道中處理大型郵件會很有用。這是因為傳送至遠端 SMTP 主機的大型郵件或具有許多收件者的郵件，在完成處理從而建立不同的遞送統計資料上，比典型郵件需要更長的時間。

處理對超過配額的使用者的郵件遞送

關鍵字：holdexquota、noexquota

noexquota 和 holdexquota 關鍵字控制對傳送給 Berkeley 電子信箱使用者 (UNIX) (亦即傳送至 uid 原生通道而且超過其磁碟配額的使用者) 之郵件的處理。

noexquota 告知 MTA 將傳送給超過配額的使用者數目之郵件傳回給郵件寄件者。holdexquota 告知 MTA 保留傳送給超過配額的使用者數目之郵件；這類郵件會保留在 MTA 佇列中，直到其被傳送或逾時，然後由郵件傳回工作傳回給寄件者。

處理行長度超過 1000 個字元的 SMTP 郵件

關鍵字：rejectsmtplonglines、wrapsmtplonglines 和 truncatesmtplonglines

rejectsmtplonglines 增加拒絕行長度超過 SMTP 所允許的1000 個字元(包括 CRLF) 的郵件之選項。此區域中的其他選項為 wrapsmtplonglines (將過長的行換行) 和預設選項 truncatesmtplonglines (將過長的行截斷)。這兩種關鍵字均必須套用至用於提交的初始通道 (例如 tcp_local)。這不會影響隨後切換到的通道。