Sun Java System Messaging Server 6.3 管理指南

12.8 附件和 MIME 處理

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

12.8.1 忽略 Encoding 標頭行

關鍵字:ignoreencodinginterpretencoding

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


備註 –

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


12.8.2 郵件/部分郵件的自動重組

關鍵字:defragmentnodefragment

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

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

12.8.2.1 重組通道

如果目標通道上有 defragment 關鍵字,郵件會路由至重組通道。也就是說,當 MTA 一般會讓郵件在此排入佇列的目標通道上有 defragment 關鍵字時,MTA 會「在內部尋找」(MIME 剖析) 郵件結構,如果 MTA 找到的結構為 MIME 郵件片段,則 MTA 會自動將此郵件路由至重組通道,而不是直接路由至 (一般) 目標通道。

重組資料庫包含關於進入 MTA 的郵件片段之資訊,包括指出接收每封郵件片段的主機資訊。一旦重組資料庫接收並記錄了初始片段後,在使用相同重組資料庫的任何其他系統上所接收的郵件其他部分,都將會路由至接收最初部分的主機。例如:

  1. 由於目標/外寄通道上有 defragment 關鍵字,message/partial; id=123; part=x 會在抵達主機 1 後,路由至主機 1 上的重組通道。

  2. 主機 1 上的重組通道會檢查重組資料庫的此封郵件,是否還有任何其他部分要抵達。如果沒有,重組通道 (位於主機 1 上) 會將此部分輸入重組資料庫,並標記此部分目前在主機 1 上。

  3. 由於目標/外寄通道上有 defragment 關鍵字,message/partial; id=123; part=y 會在抵達主機 2 後,路由至主機 2 上的重組通道。

  4. 主機 2 上的重組通道會檢查重組資料庫,查看此封郵件的 x 部分是否已存在並儲存在主機 1 上。重組通道會將此郵件片段重新導入主機 1 (來源會路由具有 @host1 的位址)。

  5. message/partial' id=123; part=y 會抵達主機 1,路由至重組通道,接著重組通道會執行並將此部分輸入資料庫等。

其餘郵件片段部分會重新導入接收此郵件第一部分 (第一個接收的部分,不一定是 part=1) 的主機。主機的重組通道會重新組合這些片段,此重新組合(reassemble) 與重組 (defragment) 的郵件最後會傳送至實際的目標通道 (或者如果由於超過通知次數而導致重組動作逾時,則會以現狀傳送個別片段)。視接收每封郵件的「第一」部分之主機而定,您可能會取得郵件重組的部分負載平衡。

12.8.2.2 重組通道保留時間

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

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


defragment notices 4 
DEFRAGMENT-DAEMON

12.8.2.3 使用 NFS 型檔案系統進行重組和自動回覆快取

NFS 型檔案系統經常用在重組和自動回覆快取。若要讓應用程式共用多台 MTA 系統之間的重組資料庫,這些系統必須共用相同的重組快取。若要執行這項作業,請建立每台系統上的 msg-svr-base/config/defragment_cache 與共用重組資料庫所在的檔案連結,此連結將位於共用 NFS 磁碟上。

在任何情況下,支援適當 NFS 檔案語義的 NFS 伺服器 (特別是那些接受鎖定請求的伺服器,如 Solaris NFS) 皆可用於自動回覆和重組快取。如果使用 NFS,請使用軟式掛載選項。(預設值為硬式掛載。)設定由 mount timeo 選項控制、極短的逾時值 (請參閱 mount_nfs(1M) 線上手冊) 也是很好的方法。

若是使用 NFS 硬式掛載且 NFS 離線,使用者會看到各種系統上的重組通道當機。若是使用軟式掛載,重組通道不會當機,但由於通道無法開啟重組快取,因此無法與其他主機上的重組通道進行協調。若是郵件所有片段剛好同時首次抵達同一台主機 (機率很小),則主機的重組通道可能會重新組合郵件,並傳送此完整重新組合的郵件。比較可能的情況,是這些片段位於不同的主機,並在相關重組通道的保留時間過期時,不重新組合便以個別片段進行傳送。

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

關鍵字:maxblocksmaxlines

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

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

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

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

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

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

12.8.4 設定郵件行長度限制

關鍵字:linelength

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

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


備註 –

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


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

12.8.5 解譯 Multiparts 和郵件/RFC822 部分的 Content-transfer-encoding 欄位

關鍵字:interpretmultipartencodingignoremultipartencoding interpretmessageencodingignoremessageencoding

MIME 規格禁止在 multipart 或郵件/rfc822 部分使用 7 位元、8 位元和二進位之外的 content-transfer-encoding。長久以來,某些代理程式違反這個規格,而將 multipart 和郵件/rfc822 物件編碼。相應地,MTA 程式碼可以接受和移除此類編碼。然而,最近出現了另一種違反標準的情形,也就是 content-transfer-encoding 欄位上雖然有以引號括住的可列印值或 base63,但事實上並未編碼此部分。如果 MTA 嘗試將此類訊息解碼,結果通常是出現空白訊息,與預期的結果不同。

出現這種問題的訊息相當常見,因此新增兩組新的通道關鍵字,可啟用或停用 multipart 和郵件/rfc822 部分的 content-transfer-encoding 欄位編譯。第一組是 interpretmultipartencodingignoremultipartencoding,第二組是 interpretmessageencodingignoremessageencoding。預設值是 interpretmultipartencodinginterpretmessageencoding