配置位址處理
本節描述用於位址處理的關鍵字。包含以下各節：
位址類型和慣例
關鍵字：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 通道關鍵字會使 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 主機上的整個網路的問題。
合法化無收件者標頭行的郵件
RFC 822 (網際網路) 郵件必須包含收件者標頭行：To:、Cc: 或 Bcc: 標頭行。沒有上述標頭行的郵件是非法的。但是，有些不可靠的使用者代理程式和郵件程式 (例如，許多舊版 sendmail) 會傳送非法的郵件。
missingrecipientpolicy 關鍵字接受整數值，指定處理此類郵件的方法；如果未明確指定此關鍵字，則預設為 1 (原封不動地傳送非法郵件)。
表 12–25 missingrecipientpolicy 值|
值 |
動作 |
|---|---|
|
0 |
將訊息封 To: 收件者放入 To: 標頭行中。 |
|
1 |
原封不動地傳送非法郵件。 |
|
2 |
將訊息封 To: 收件者放入 To: 標頭行中。 |
|
3 |
將所有訊息封 To: 收件者放入單一 Bcc: 標頭行中。 |
|
4 |
產生群組建構 (例如「;」) To: 標頭行「To: Recipients not specified: ;」 |
|
5 |
產生空白 Bcc: 標頭行。 |
|
6 |
拒絕郵件。 |
請注意，可使用 MISSING_RECIPIENT_POLICY 選項將 MTA 系統預設為此運作方式。Messaging Server 的初始配置將 MISSING_RECIPIENT_POLICY 設定為 1。
刪除非法空白收件者標頭
在 RFC 822 (網際網路) 郵件中，任何 To:、Resent-To:、Cc: 或 Resent-Cc: 標頭均需要包含至少一個位址，亦即標頭的值不得為空。但是，有些郵件程式可以傳送這類非法標頭。如果對來源通道指定 dropblank 通道關鍵字，則會使 MTA 刪除內送郵件中所有此類非法的空白標頭。
啟用通道特定的反向資料庫用途
reverse 關鍵字會告知 MTA，如果存在位址反向資料庫或 REVERSE 對映，則在通道上形成佇列的郵件之位址應由位址反向資料庫或 REVERSE 對映進行檢查，可能還會予以修改。noreverse 使通道上形成佇列的郵件中之位址免於進行位址反向處理。reverse 關鍵字為預設。請參閱將位址從內部格式轉換為公用格式
啟用有限電子信箱編碼
有些郵件系統很難處理 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 資料庫探測
通常，只有重寫至本機通道 (即 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 關鍵字告知 MTA 對此通道強制執行通道專用的重寫規則檢查。這是預設。norules 關鍵字告知 MTA 不對此通道執行檢查。這兩個關鍵字通常用於除錯，在實際應用中很少使用。
移除來源路徑
dequeue_removeroute 關鍵字可在郵件移出佇列時，從信息封 To: 位址中移除來源路由。此關鍵字目前僅對 tcp-* 通道實作。它可用於將郵件傳送至未正確處理來源路徑的系統。
指定位址必須來自別名
關鍵字：viaaliasoptional 和 viaaliasrequired
viaaliasrequired 指定匹配通道的所有最終收件者位址必須由別名產生。最終收件者位址是指執行別名延伸 (如果有關) 之後的相符項目。該位址無法做為收件者位址直接傳送給 MTA；亦即對於位址而言，僅重寫至通道還不夠。重寫至通道之後，位址還必須透過被視為真正符合通道的別名來延伸。
例如，必須將 viaaliasrequired 關鍵字用於本機通道，以避免傳送至任意帳號 (例如 UNIX 系統上任意的原生 Berkeley 電子信箱)。
預設為 viaaliasoptional，表示匹配通道的最終收件者位址不需要由別名產生。
- © 2010, Oracle Corporation and/or its affiliates