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

MTA 如何將重寫規則套用至位址

以下步驟描述 MTA 如何將重寫規則套用至給定位址：

MTA 從位址中擷取第一個主機或網域規格。

一個位址可以指定多個主機或網域名稱，如下例所示：

jdoe%hostname@siroe.com.
識別第一個主機或網域名稱後，MTA 會執行搜尋，掃描重寫規則匹配主機或網域名稱的式樣。
找到匹配的重寫規則後，MTA 將根據此規則的範本部分重寫位址。
最後，MTA 會將通道標記和與每個通道關聯的主機名稱相比較。

如果找到匹配的通道，MTA 會將郵件形成佇列，傳送至關聯的通道；否則重寫程式會失敗。如果匹配的通道是本地通道，則可以透過查詢別名資料庫和 Alias 檔案來對位址進行額外重寫。

這些步驟將在以下小節中詳細描述。

備註 –

使用不屬於任何現有通道的通道標記將導致其位址匹配此規則的郵件被退回。即，它會使匹配的郵件無法路由。

步驟 1. 擷取第一個主機或網域規格

重寫位址的程序透過從位址中擷取第一個主機或網域規格開始。(建議不熟悉 RFC 822 位址慣例的讀者閱讀該標準，以理解以下討論內容。)位址中主機/網域規格的掃描順序如下︰

源路由中的主機 (從左至右讀取)
顯示在「at」符號 (@) 右側的主機
顯示在最後一個單百分比符號 (%) 右側的主機
顯示在第一個驚嘆號 (!)

如果 bangoverpercent 關鍵字在正在執行位址重寫的通道上有效，則最後兩個項目的順序將被交換。亦即，嘗試將郵件形成佇列的通道本身是否標記有 bangoverpercent 通道關鍵字。

在表 11–3 中顯示了一些可以首先擷取的位址和主機名稱範例。

表 11–3 擷取的位址和主機名稱


位址	第一個主機網域規格	註釋
`user@a`	`a`	「縮寫」網域名稱。
`user@a.b.c`	`a.b.c`	「完全合格的」網域名稱 (FQDN)。
`user@[0.1.2.3]`	`[0.1.2.3]`	「網域文字」。
`@a:user@b.c.d`	`a`	來源路由的位址，具有縮寫網域名稱「route」。
`@a.b.c:user@d.e.f`	`a.b.c`	源路由的位址；路由部分是完全合格的。
`@[0.1.2.3]:user@d.e.f`	`[0.1.2.3]`	源路由的位址；路由部分是網域文字。
`@a,@b,@c:user@d.e.f`	`a`	包含 a 至 b 至 c 路由的源路由位址。
`@a,@[0.1.2.3]:user@b`	`a`	在路由部分中包含網域文字的源路由位址。
`user%A@B`	`B`	此非標準的路由格式稱為「百分比入侵」。
`user%A`	`A`
`user%A%B`	`B`
`user%%A%B`	`B`
`A!user`	`A`	「Bang 樣式」定址；通常用於 UUCP。
`A!user@B`	`B`
`A!user%B@C`	`C`
`A!user%B`	`B`	`nobangoverpercent` 關鍵字處於使用中；預設。
`A!user%B`	`A`	`bangoverpercent` 關鍵字處於使用中。

RFC 822 不會定址位址中的驚嘆號 (!) 和百分比符號 (%) 的解釋。如果 at 符號 (@) 不存在，則通常使用與 at 符號相同的方式解譯百分比符號，因此 Messaging Server MTA 採用此慣例。

重複的百分比符號之特殊解譯用來允許將百分比符號做為本機使用者名稱的一部分，這在處理某些外部郵件系統位址時會十分有用。驚嘆號的解譯符合 RFC 976 的「bang 樣式」位址慣例，並可以配合使用 UUCP 位址和 Messaging Server MTA。

這些解譯的順序不是由 RFC 822 或 RFC 976 指定，因此可以使用 bangoverpercent 和 nobangoverpercent 關鍵字來控制執行重寫的通道套用它們的順序。雖然在某些情況下替代設定可能很有用，但預設更「標準」。

備註 –

不建議在位址中使用驚嘆號 (!) 或百分比符號 (%)。

步驟 2. 掃描重寫規則

從位址中擷取第一個主機或網域規格之後，MTA 將參考重寫規則以找出處理它的方法。然後將主機/網域規格與每個規則的式樣部分 (即每個規則的左側) 進行比較。這種比較不區分大小寫。RFC 822 規定不區分大小寫。MTA 不區分大小寫，但會儘可能保留大小寫。

如果主機或網域規格與任何式樣均不匹配，在這種情況下稱為「不匹配任何規則」，則主機或網域規格的第一部分 (第一個小數點號之前的部分，通常是主機名稱) 將被移除，並以星號 (*) 替代，然後系統將嘗試找出結果主機或網域規格的位置，但僅在配置檔案重寫規則中查找 (不諮詢網域資料庫)。

如果此作業失敗，將移除第一部分並重複該程序。如果此作業也失敗了，則會移除下一個部分 (通常是子網域)，然後重寫程式將重試，第一次帶星號，以後不帶星號。包含星號的所有探測僅在配置檔案重寫規則表中進行；不檢查網域資料庫。該程序將繼續進行，直至找到匹配或耗盡整個主機或網域規格。該程序的作用是，首先嘗試匹配最特殊的網域，然後匹配不太特殊和更為一般的網域。

從更規則的角度來看，此匹配程序為︰

使用主機/網域規格做為比較字串 spec_1 和 spec_2 的初始值。(例如，spec_1 = spec_2 = a.b.c)。
將比較字串 spec_1 與配置檔案中每個重寫規則的式樣部分進行比較，然後與網域資料庫中的式樣部分進行比較，直至找到匹配的式樣。如果找到匹配，匹配程序將結束。
如果未找到匹配的式樣，則將 spec_2 最左側的非星號部分轉換為星號。例如，如果 spec_2 為 a.b.c，則變更為*.b.c；如果 spec_2 為 *.b.c，則變更為 *.*.c。如果找到匹配的式樣，則匹配程序將結束。
如果未找到匹配的式樣，則比較字串 spec_1 的第一部分 (包括所有前導小數點號) 將被移除。其中，spec_1 僅具有一部分 (例如 .c 或 c)，使用單一小數點號「.」替代字串。如果結果字串 spec_1 的長度非零，則返回至步驟 1。如果結果字串長度為零 (例如，之前的「.」)，則查詢程序失敗並結束匹配程序。

例如，假設要重寫位址 dan@sc.cs.siroe.edu。這會導致 MTA 以給定次序查找以下式樣：

sc.cs.siroe.edu
*.cs.siroe.edu
.cs.siroe.edu
*.*.siroe.edu
.siroe.edu
*.*.*.edu
.edu
*.*.*.*
.

步驟 3. 根據範本重寫位址

一旦主機/網域規格匹配某個重寫規則，將使用此規則的範本部分對其進行重寫。範本指定三項內容：

位址的新使用者名稱。
位址的新主機/網域規格。
識別現有 MTA 通道 (到達該位址的郵件應傳送至該通道) 的通道標記

步驟 4. 完成重寫程序

一旦主機/網域規格被重寫，可能會出現以下兩種情況之一。

如果通道標記與本機通道或標有 routelocal 通道關鍵字的通道均不關聯，或者位址中沒有附加主機/網域規格，則重寫規格將被替換至位址中，替代從重寫中擷取的原始規格，並且重寫程序將終止。
如果通道標記匹配本機通道或標有 routelocal 的通道，並且位址中有附加主機/網域規格，則將捨棄重寫位址，將原始 (初始) 主機/網域規格從位址中移除，然後從位址中擷取新的主機/網域規格，然後再重複整個程序。重寫將繼續進行，直至用完所有的主機/網域規格，或找到一個通過非本地、非本地路由通道的路由。該反覆機制就是 MTA 為源路由提供支援的方式。實際上，通過本地系統和本地路由系統的多餘路由均由此程序從位址中移除。

重寫規則失敗

如果主機/網域規格與任何重寫規則均不匹配，並且未提供預設規則，則 MTA 將使用規格「現狀」；例如，原始規格同時成為新規格和路由系統。如果位址包含無意義的主機/網域規格，則當路由系統不匹配與任何通道關聯的任何系統名稱時，將偵測到該位址，並且郵件將被退回。

重寫後的語法檢查

重寫規則套用至位址後，未進行任何附加語法檢查。這是經過深思熟慮的 — 它可讓您使用重寫規則將位址轉換為與 RFC 822 不相符的格式。但是，這也意味著配置檔案中的錯誤可能會導致郵件為 MTA 留下錯誤或非法的位址。

處理網域文字

網域文字在重寫程序執行期間進行了特殊處理。如果位址網域部分中顯示的網域文字不匹配重寫規則式樣 as is，則文字將被解譯為一組以小數點分隔且由方括號包圍的字串。最右邊的字串將被移除並會重複搜尋。如果此作業不起作用，則將移除下一個字串，以此類推，直至僅剩下空括號。如果搜尋空括號失敗，則會移除整個網域文字，並且重寫將繼續處理網域位址的下一個區段 (如果有)。在網域文字的內部處理中不使用星號；若整個網域文字由星號取代，則星號的數量應與網域文字中的元素數量相符。

與一般網域或主機規格一樣，網域文字也是按照從最特定到最不特定的次序嘗試。其式樣匹配的第一個規則將是用於重寫主機或網域規格的規則。如果在規則清單中有兩個完全相同的式樣，則使用先出現的式樣。

例如，假設要重寫位址 dan@[128.6.3.40]。重寫程式搜尋 [128.6.3.40]、[128.6.3.]、[128.6.]、[128.]、[] 和 [*.*.*.*]，然後最終搜尋匹配全部規則「.」。