第 12 章 配置通道定義

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

• 12.1 配置通道預設

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

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

• 12.4 配置 SMTP 通道

• 12.5 配置郵件處理和遞送

• 12.6 配置位址處理

• 12.7 配置標頭處理

• 12.8 附件和 MIME 處理

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

• 12.10 在 MTA 佇列中建立檔案

• 12.11 配置記錄和除錯

• 12.12 其他關鍵字

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

12.1 配置通道預設

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

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

defaults keyword1 keyword2 keyword3 ...

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

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

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

nodefaults

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

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

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

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

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

• 表 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 其他關鍵字

12.4 配置 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.3 Administration Reference」中的「Option File」。

本節分為以下子節：

• 12.4.1 配置 SMTP 通道選項

• 12.4.2 SMTP 指令和協定支援

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

• 12.4.4 SMTP 認證、SASL 與 TLS

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

• 12.4.6 SMTP 資料塊支援

• 12.4.7 指定 Microsoft Exchange 閘道通道

• 12.4.8 傳輸層安全

12.4.1 配置 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.3 Administration Reference」。

12.4.2 SMTP 指令和協定支援

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

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

• 12.4.2.2 EHLO 指令支援

• 12.4.2.3 ETRN 指令支援

• 12.4.2.4 VRFY 指令支援

• 12.4.2.5 EXPN 支援

• 12.4.2.6 DNS 網域驗證

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

• 12.4.2.8 協定串流

表 12–21 摘要本小節所說明的關鍵字。

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

關鍵字：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。

12.4.2.2 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 關鍵字產生的運作方式之間，因此沒有對應於此預設運作方式的關鍵字。

12.4.2.3 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 關鍵字後面應加上請求其郵件接收遞送嘗試的系統名稱。

12.4.2.4 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 通道。

12.4.2.5 EXPN 支援

關鍵字：expnallow、expndisable 和 expndefault

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

12.4.2.6 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]

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

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

關鍵字：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 拒絕所有標頭包含非法八位元資料的內送郵件。

12.4.2.8 協定串流

關鍵字：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。

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

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

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

• 12.4.3.2 快取通道連線資訊

• 12.4.3.3 反向 DNS 查詢

• 12.4.3.4 IDENT 查詢

• 12.4.3.5 TCP/IP MX 記錄支援

• 12.4.3.6 名稱伺服器查詢

• 12.4.3.7 最後一台主機

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

• 12.4.3.9 來源通道會根據使用者或網域設定進行切換

• 12.4.3.10 目標主機選擇

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

12.4.3.1 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 通道偵聽哪個介面位址，以接受內送連線與郵件。

12.4.3.2 快取通道連線資訊

關鍵字：cacheeverything、nocache、cachefailures 和 cachesuccesses

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

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

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

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

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

12.4.3.3 反向 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 名稱。

12.4.3.4 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 關鍵字而進行的任一通道切換之基礎。

12.4.3.5 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 查詢的通道上之預設值。

12.4.3.6 名稱伺服器查詢

關鍵字：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 配置。

12.4.3.7 最後一台主機

關鍵字：lastresort

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

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

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

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

關鍵字：switchchannel、allowswitchchannel 和 noswitchchannel。另請參閱12.4.4 SMTP 認證、SASL 與 TLS上的 saslswitchchannel、12.4.8 傳輸層安全上的 tlsswitchchannel 和12.4.3.9 來源通道會根據使用者或網域設定進行切換上的 userswitchchannel

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

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

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

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

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

12.4.3.9 來源通道會根據使用者或網域設定進行切換

關鍵字：userswitchchannel。另請參閱12.4.3.8 內送的郵件的替代通道 (切換通道)上的 switchchannel

來源通道現在可以根據使用者或網域設定進行切換。其中包含三項新設定：

1. 新的通道關鍵字 userswitchchannel。初始來源通道上必須有此關鍵字，使用者通道才能切換。

2. 新的 MTA 選項 LDAP_DOMAIN_ATTR_SOURCE_CHANNEL，指定網域層級屬性名稱包含要切換的通道名稱。

3. 新的 MTA 選項 LDAP_SOURCE_CHANNEL，指定使用者層級屬性名稱包含要切換的通道名稱。

此外，切換至的通道必須設定為允許通道切換。亦即，其不得以 noswitchchannel 關鍵字進行標記。切換會根據重寫 MAIL FROM 位址所傳回的資訊完成。請注意，由於這些 MAIL FROM 位址很容易遭偽造，因此請格外小心使用此功能。

12.4.3.10 目標主機選擇

關鍵字：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 關鍵字為使用的每個目標系統建立單份郵件副本。請注意，不論使用的關鍵字為何，都要為郵件排入佇列時所在的每個通道至少建立一份郵件副本。

12.4.4 SMTP 認證、SASL 與 TLS

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

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

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 時切換至指定的通道。它接受所需的值，以指定要切換至哪個通道。

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

關鍵字：authrewrite

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

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

12.4.6 SMTP 資料塊支援

關鍵字： chunkingclient、chunkingserver、nochunkingclient 、nochunkingserver

SMTP 資料塊 (RFC 3030) 支援已增至 SMTP 用戶端和伺服器。預設啟用這項支援。您可以使用四個新的通道關鍵字控制是否允許資料塊，如下所示：

• chunkingclient - 啟用用戶端資料塊支援 (預設)。

• chunkingserver - 啟用伺服器資料塊支援 (預設)。

• nochunkingclient - 停用用戶端資料塊支援。

• nochunkingserver - 停用伺服器資料塊支援。

已延伸記錄檔動作欄位，以指出傳輸指定的郵件時是否使用了資料塊。尤其是，如果使用資料塊，會附加 C。請注意，必須已使用 ESMTP，才能進行資料分塊，因此一般會看到如 EEC 或 DEC 的欄位值。

12.4.7 指定 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 為預設。

12.4.8 傳輸層安全

關鍵字：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 時切換至指定的通道。它接受所需的值，以指定要切換至哪個通道。

12.5 配置郵件處理和遞送

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

• 12.5.1 設定通道定向性

• 12.5.2 實作延遲遞送日期

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

• 12.5.4 通道執行工作的處理區

• 12.5.5 服務工作限制

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

• 12.5.8 SMTP 通道執行緒

• 12.5.9 多位址延伸

• 12.5.10 啟用服務轉換

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

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

12.5.1 設定通道定向性

關鍵字：master、slave 和 bidirectional

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

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

12.5.2 實作延遲遞送日期

關鍵字：deferred、nodeferred 和 immnonurgent

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

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

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

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

關鍵字：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 關鍵字的詳細資訊，請參閱10.10.4.3 設定通知郵件遞送間隔時間

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 關鍵字指定的時間段為止。如果無法成功遞送，就會產生遞送失敗通知，該郵件會傳回給寄件者。

12.5.4 通道執行工作的處理區

關鍵字：pool

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

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

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

12.5.5 服務工作限制

關鍵字：maxjobs 和 filesperjob

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

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

• 為執行指定通道而啟動的程序之最大數目 (maxjobs 通道關鍵字)

• 為一組通道啟動的程序之最大數 (工作控制器配置檔案的相關處理區區段中之 JOB_LIMIT 參數)

• 新執行緒或程序啟動之前，接收到的已排入佇列的郵件之數量 (threaddepth 通道關鍵字)

• 對於某些通道而言，將在指定遞送程式中執行的執行緒最大數 (通道選項檔案中的 max_client_threads 參數)

為執行指定通道而啟動的程序之最大數，是對通道設定的 maxjobs 和通道執行所在的處理區設定之 JOB_LIMIT 最小值。

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

• 如果沒有為通道執行的程序，並且尚未達到處理區工作限制，則工作控制器會啟動新的程序。

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

• 如果通道程式是多重執行緒並且尚未達到執行緒限制，而郵件的儲存區增加量超過了 threaddepth 的一倍，則會啟動新的執行緒。

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

• 如果沒有為 SMTP 通道執行的程序，並且尚未達到處理區限制，則工作控制器會啟動新的程序。

• 如果已達到執行緒限制 (MAX_CLIENT_THREADS)，某個尚未獲得服務的主機之郵件將會排入佇列，且通道 (maxjobs) 和處理區工作限制 (JOB_LIMIT) 均尚未達到，則將啟動新的程序。

• 如果尚未達到執行緒限制，某個尚未獲得服務的主機之郵件已排入佇列，則會啟動新的執行緒。

• 如果尚未達到執行緒限制，而郵件已排入佇列，使相應主機的郵件儲存區增加量超過了 threaddepth 的一倍，則會啟動新的執行緒。

請參閱12.5.8 SMTP 通道執行緒。

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

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

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

12.5.6 設定連線作業事件限制

關鍵字：transactionlimit

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

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

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

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

關鍵字：urgentblocklimit、normalblocklimit 和 nonurgentblocklimit

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

12.5.8 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 通道) 實現多執行緒。

12.5.9 多位址延伸

關鍵字：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 手動介入。

12.5.10 啟用服務轉換

關鍵字：service 和 noservice

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

12.6 配置位址處理

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

• 12.5.10 啟用服務轉換

• 12.6.1 位址類型和慣例

• 12.6.2 解譯使用 ! 和 % 的位址

• 12.6.3 在位址中新增路由資訊

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

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

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

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

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

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

• 12.6.10 啟用有限電子信箱編碼

• 12.6.11 產生 Return-path 標頭行

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

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

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

• 12.6.15 指定別名檔案和別名資料庫探測

• 12.6.16 子位址處理

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

• 12.6.18 移除來源路徑

• 12.6.19 指定位址必須來自別名

12.6.1 位址類型和慣例

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

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

12.6.1.1 822 (sourceroute)

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

12.6.1.2 733 (percents)

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

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

12.6.1.3 uucp (bangstyle)

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

12.6.1.4 header_822

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

12.6.1.5 header_733

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

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

12.6.1.6 header_uucp

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

12.6.2 解譯使用 ! 和 % 的位址

關鍵字：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 路徑。設定此關鍵字後，百分比會被解譯，以進行路由。

12.6.3 在位址中新增路由資訊

關鍵字：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 重寫規則範本啟動。

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

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

關鍵字：routelocal

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

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

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

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

關鍵字：connectalias 和 connectcanonical

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

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

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

關鍵字：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 為預設值。

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

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

關鍵字：missingrecipientpolicy

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

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

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

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

關鍵字：dropblank 和 nodropblank

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

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

關鍵字：reverse 和 noreverse

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

12.6.10 啟用有限電子信箱編碼

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

12.6.11 產生 Return-path 標頭行

關鍵字：addreturnpath 和 noaddreturnpath

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

12.6.12 從訊息封 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: 位址。

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

關鍵字：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 旗標，則原始註釋將被指定的文字 (該文字應包括外圍的括號) 取代。

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

關鍵字：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 旗標，則原始個人名稱將被指定的文字取代。

12.6.15 指定別名檔案和別名資料庫探測

關鍵字：aliaslocal

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

12.6.16 子位址處理

關鍵字：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 通道上進行轉送。

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

關鍵字：rules 和 norules

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

12.6.18 移除來源路徑

關鍵字：dequeue_removeroute

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

12.6.19 指定位址必須來自別名

關鍵字： viaaliasoptional 和 viaaliasrequired

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

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

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

12.6.20 收件者位址處理

關鍵字： acceptalladdresses、acceptvalidaddresses

acceptvalidaddresses 是預設值，對應於 MTA 的標準運作方式，這會在 SMTP 對話期間立即報告任何收件者錯誤。如果在通道上指定關鍵字 acceptalladdresses，則在 SMTP 對話期間會接受全部的收件者位址。任何無效的位址都會在稍後傳送 DSN。

12.7 配置標頭處理

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

• 12.7.1 重寫內嵌式標頭

• 12.7.2 移除選取的郵件標頭行

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

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

• 12.7.5 在日期中指定星期

• 12.7.6 自動分割長標頭行

• 12.7.7 標頭對齊和摺疊

• 12.7.8 指定標頭最大長度

• 12.7.9 敏感性檢查

• 12.7.10 設定標頭中的預設語言

• 12.7.11 控制 Message-hash: 標頭

12.7.1 重寫內嵌式標頭

關鍵字：noinner 和 inner

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

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

12.7.2 移除選取的郵件標頭行

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

MTA 提供針對各通道在郵件中修整或移除選取的郵件標頭行的功能。此功能透過通道關鍵字與一個或兩個關聯標頭選項檔案組合而實現。「Sun Java System Messaging Server 6.3 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/config/ 中。

12.7.3 產生/移除 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。

現在即使未在通道上設定 single，也能使用 x_env_to 關鍵字，但其意義不大。

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

關鍵字：datefour 和 datetwo

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

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

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