Exchange 2000 Server 和 Exchange Server 2003 郵件限制
發佈日期: 2006 年 2 月 1 日
作者: Kent Tilger
本文探討 Microsoft® Exchange Server 2003 和 Exchange 2000 Server 的郵件限制。
本頁內容
定義
限制檢查邏輯摘要
強制執行郵件限制
全域限制的潛在問題
其他相關資訊
定義
請參閱下列定義：
最大提交內容長度 (SubmissionContLength) 是指傳送大小限制。
最大傳遞內容長度 (DelivContLength) 是指接收大小限制。
組織全體限制等於全域限制。
限制檢查邏輯摘要
(SubmissionContLength) 的每一使用者設定會覆寫全域定義的 (SubmissionContLength) 設定。
(DelivContLength) 的每一使用者定義的優先順序高於全域定義的 (DelivContLength) 設定，不過在之後的產品版本中，如果提交期間的 (SubmissionContLength) 檢查失敗，將不再進行郵件分類。
(SubmissionContLength) 的每一使用者設定不會覆寫簡易郵件傳送通訊協定 (SMTP) 虛擬伺服器限制。
(SubmissionContLength) 的每一使用者設定不會覆寫連接器定義的限制。
請參考下列範例：
如果使用者的每一使用者傳送限制值高於全域定義的傳送限制值，那麼此使用者可以傳送比全域定義限制更大的郵件，但不能超過在 Active Directory® 目錄服務中的使用者物件上定義的傳送大小限制。
.gif "Dd159861.note(zh-tw,TechNet.10).gif")
附註:要注意在路由群組之間使用 SMTP 時，路由群組間郵件大小會增加，這是由 Microsoft Exchange Server 2003 原生模式所引起的。
如果收件者的每一使用者接收限制值超過全域定義的接收限制，其可接收的郵件大小不得超過專為此收件者定義的接收限制大小。
附註:上例假設進行的是非 MAPI 提交限制檢查，亦即提交時並未超過傳送大小限制值。
下面以流程圖方式概述最大傳送與最大傳遞大小限制評估如何運作。
.gif "Dd159861.db904dcd-51c4-4d85-afaf-ac09bc8e5ba6(zh-tw,TechNet.10).gif")
強制執行郵件限制
大小限制會在下列層級強制執行：
通訊協定層
郵件提交 (MAPI 用戶端)
分類
路由
如果已在虛擬伺服器內容中設定通訊協定層限制，只要進入系統的郵件大小超過設定的大小，進行傳輸之前，SMTP 就會先在通訊協定層拒絕這些郵件。
對於在 Exchange Server 2003 和 Exchange 2000 Server 上進行的 MAPI 用戶端提交，最大提交內容長度或傳送大小限制將於提交時予以評估，因此大於個別使用者或全域定義之傳送限制的郵件在提交前即被拒絕。
在上述這兩個範例中，並未考慮收件者的傳送大小限制便先拒絕郵件。
如果是透過 SMTP、MTA、X.400 或其他傳統連接器提交的郵件，將於分類期間評估傳送大小限制和接收大小限制的規定。
就傳送大小限制而言，Active Directory 使用者物件上的每一使用者限制的優先順序高於全域定義的傳送大小限制值。
評估過最大提交內容長度限制後，便會評估最大傳遞內容長度 (DelivContLength)。
就接收大小限制而言，每一使用者限制 (Active Directory) 的優先順序高於全域定義的接收大小限制值。
如果有任一郵件的大小超過全域定義的接收大小限制，而且收件者並未使用明確的每一使用者定義接收大小值來覆寫全域定義值，則該郵件將產生 5.2.3 傳遞狀態通知：
This message is larger than the current system limit or the
recipient's mailbox is full.
Create a shorter message body or remove attachments and try
sending it again. <Server.Domain.com #5.2.3>
分類程式會將全域定義的接收大小限制套用至本機和遠端傳遞。因此，如果傳送至非組織 (網際網路) 收件者的郵件超過全域定義的接收大小限制，便會產生 5.2.3 傳遞狀態通知：
Receive Size Limits cannot be overridden by explicit Sending Size
Limit values defined Per-User, but explicit Receive Size Limit
values do take precedence over globally defined Receive Size
values.
如果此郵件並非用於本機傳遞，路由會考量成本、郵件類型及限制等變數來選擇最佳路徑，並為郵件尋找作為下一個躍點的下一部伺服器，同時也會提供此 next-hop 伺服器名稱給「進階佇列」。
SMTP 虛擬伺服器限制和連接器限制會套用在路由的各個階段。
在郵件傳輸到最終目的地的過程中，相同的限制檢查邏輯會在處理郵件的每個伺服器上一再重複進行。
全域限制的潛在問題
請參考下列潛在問題：
在郵件提交時持續強制執行傳送大小限制，而非在之後的分類期間強制執行。
如需解決此問題的相關資訊，請參閱 Microsoft 知識庫文件 836738〈在 Exchange 2000 Server 中傳遞大於「傳送郵件大小」傳遞選項的電子郵件〉(英文)。全域傳送大小限制在問題解決前無法有效運作，因為提交限制要等到分類時才會評估。這個邏輯的潛在瑕疵在於：除非已經設定明確的傳送限制，否則有些使用者可能會 (有意或無意) 提交非常大的郵件至系統。因為直到分類時才會評估郵件，因此這些郵件會進入系統，但稍後傳輸時會被拒絕並顯示 5.2.3 傳遞狀態通知。
MAPI 用戶端有一項新行為，就是「傳送限制」限制檢查會在郵件提交時執行 (相對於分類時)。如果郵件超過定義的傳送大小限制，此郵件永遠無法到達儲存區。Microsoft Outlook® 會顯示如下圖所示的對話方塊，表示郵件超出傳送大小限制。
.gif "Dd159861.2941be00-cbf0-45eb-ae12-58c1c3a86815(zh-tw,TechNet.10).gif")
附註:請務必記得，初始的用戶端檢查僅適用於傳送限制。如果在提交期間超過此傳送限制，就不會考慮接收限制 (此限制無法被覆寫)。如果郵件系統管理員慣於在分類中執行評估時，使用較大的接收限制來牽制系統中的郵件，他會意外地發現在套用 Microsoft 知識庫文件 836738〈在 Exchange 2000 Server 中傳遞大於「傳送郵件大小」傳遞選項的電子郵件〉(英文) 參考的解決辦法之後，這種方式已經行不通。
針對接收郵件大小限制來設定組織全體限制將直接影響組織全體傳送限制大小。例如，如果您將全域接收郵件大小限制設定為 1 MB，然後不設定傳送限制 (無限制)，有些系統管理員可能會期望使用者能夠傳送大於 1 MB 的郵件。
附註:在傳送郵件大小選項中設定的郵件大小限制會限制可以傳送的郵件大小。在接收郵件大小選項中設定的郵件大小限制會限制可以接收的郵件大小。這些郵件大小限制將套用至整個組織。針對不屬於 Exchange 組織成員的收件者而言，這些傳送及接收郵件大小限制也會影響到傳送給及接收自這些收件者的郵件。
分類程式會將全域定義的接收大小限制套用至本機和遠端傳遞。如果郵件的目的地為本機收件者或外部非組織 (網際網路) 收件者且大小超過全域定義的接收大小限制，便會產生 5.2.3 傳遞狀態通知。
對分類程式而言，任何超過最大傳遞內容長度，並且因收件者未設定接收限制而沒有依每一使用者覆寫的郵件，都會視為超出設定限制之外，並產生 5.2.3 傳遞狀態通知。
如需詳細資訊，請參閱 Microsoft 知識庫文件 298572〈不傳遞大於傳送郵件大小限制或接收郵件大小限制的電子郵件〉(英文)。
分類程式會針對本機和遠端傳遞評估全域接收限制，任何使用者物件上較大的傳送限制都無法覆寫此全域接收限制。
謹慎使用全域接收限制。
全域接收限制的運作方式與大多數人預期的不同。對分類程式而言，全域大小限制的類型有兩種：
最大提交內容長度 (SubmissionContLength)
最大傳遞內容長度 (DelivContLength)
後者會套用至所有傳遞，包括遠端傳遞。
舉例來說，假設將寄件者信箱傳送限制設為 10 MB，不設定接收限制，然後將全域接收限制設為 5 MB。從寄件者傳送包含 6 MB 附件的郵件給任意收件者。
一般認為收件者將收到該郵件，因為寄件者的明確傳送限制高於接收限制。不過，這個操作會產生 5.2.3 傳遞狀態通知。
對分類程式而言，此郵件大小已超出最大傳遞內容長度，而且不會根據個別使用者的接收限制予以覆寫。
使用者無法接收超過全域定義之接收限制的郵件，除非此限制被每一使用者的明確接收限制覆寫。
如果使用者的每一使用者傳送值超過全域定義的傳遞值，該使用者將無法傳送大於全域定義之接收限制的郵件，除非收件者具有可覆寫全域定義之 (DelivContLength) 的 (DelivContLength)。
Microsoft 知識庫文件 836738〈在 Exchange 2000 Server 中傳遞大於「傳送郵件大小」傳遞選項的電子郵件〉(英文) 所參考的解決方法在此例中派不上用場，因為寄件者並未超出 (SubmissionContLength) 值。
(DelivContLength) 的每一使用者設定 (如果設定的話) 會覆寫全域定義的 (DelivContLength) 設定。
實作限制時，必須一併考量包含二進位附件且透過 SMTP 在路由群組之間流動而增加的額外郵件量。
對於在路由群組之間傳送的傳出 SMTP 郵件，Exchange Server 將以 Transport Neutral Encapsulation Format (TNEF) 來轉譯附件，這種格式是採用 Bbase64 或 Quoted Printable 而非二進位。這會導致郵件大小增加約 33% 。
使用者可以使用約等於三分之一的係數來增加全域郵件限制大小來彌補此負荷，即可解決這個問題。
在 Exchange Server 2003 原生模式中，組織內部電子郵件會自動使用 Summary Transport Neutral Encapsulation Format (STNEF)。因此，在通過路由群組連接器時並不會增加郵件大小。在混合模式中，此行為仍不改變，因為 STNEF 只用於路由群組內。
舉例來說，將全域傳送限制設為 10 MB，全域接收限制則不設定。而且也不設定明確的每一使用者大小限制。
在兩個路由群組中放入三個使用者。User1 與 User2 在同一個路由群組中，User3 則在另一個透過 SMTP 連接的路由群組中。從 User1 傳送包含 8 MB 附件的郵件給 User2 和 User3。您可能預期 User2 與 User3 都會收到此郵件。但是，實際上是位於相同路由群組中的 User2 如預期般收到郵件，而寄給 User3 郵件卻傳回 5.2.3 傳遞狀態通知。
在本例中，User1 並未使用明確的信箱傳送大小限制來覆寫全域傳送限制，因此會強制執行全域限制。
當 8 MB 的郵件經由 SMTP 跨過路由群組界限並到達目的地伺服器時，由於路由群組間 SMTP 增加的關係，會比原本的郵件多出 33% 的大小。當接收伺服器上的分類程式評估 SubmissionContLength 時，寄給 User2 的郵件在路由群組間躍點上已經超過 10 MB。最終郵件包含等於 11,594,558 (11 MB) 的內容大小，此郵件已超過 10 MB 的全域限制，因此會傳回 5.2.3 傳遞狀態通知。
Microsoft 知識庫文件 836738〈在 Exchange 2000 Server 中傳遞大於「傳送郵件大小」傳遞選項的電子郵件〉(英文) 所參考的解決方法在此例中派不上用場，因為郵件在跨過路由群組間界限之前並未到達最大提交值。
其他相關資訊
如需詳細資訊，請參閱下列 Microsoft 知識庫文件：
298572, 〈不傳遞大於傳送郵件大小限制或接收郵件大小限制的電子郵件〉(英文)
836738, 〈在 Exchange 2000 Server 中傳遞大於「傳送郵件大小」傳遞選項的電子郵件〉(英文)
322679, 〈如何在 Exchange Server 中設定郵件的大小限制〉(英文)