內容轉換

  • 發行項

適用於：Exchange Server 2013

內容轉換 是為每個收件者正確格式化訊息的程式。 在訊息上執行內容轉換的決定取決於所處理訊息的目的地和格式。 在 Microsoft Exchange Server 2013 中，有兩種不同類型的內容轉換：

  • 外部收件者的郵件轉換：這種類型的內容轉換包括傳輸中性封裝格式 (TNEF) 轉換選項和外部收件者的訊息編碼選項。 傳送給 Exchange 組織內收件者的郵件不需要這種類型的內容轉換。 這種類型的內容轉換是由信箱伺服器上傳輸服務中的分類器所處理。 在提交佇列中放入新抵達的訊息之後，就會對每個訊息進行分類。 除了收件者解析和路由解析之外，在郵件放入傳遞佇列之前，還會在郵件上執行內容轉換。 如果單一訊息包含多個收件者，分類器會決定每個郵件收件者的適當編碼方式。 內容轉換追蹤不會擷取分類器在轉換傳送給外部收件者的訊息時遇到的任何內容轉換失敗。

  • 內部收件者的 MAPI 轉換：此類型的內容轉換是由信箱傳輸服務處理。 信箱傳輸服務存在於信箱伺服器上，可在本機伺服器的信箱資料庫與信箱伺服器上的傳輸服務之間傳輸訊息。 具體而言，信箱傳輸提交服務會將郵件從寄件者的 Outbox 傳輸到信箱伺服器上的傳輸服務。 信箱傳輸傳遞服務會將郵件從信箱伺服器上的傳輸服務傳輸到收件者的收件匣。 信箱傳輸提交服務會從 MAPI 轉換所有傳出訊息，而信箱傳輸傳遞服務會將所有傳入訊息轉換成 MAPI。 內容轉換追蹤會擷取這些 MAPI 轉換失敗。 如需詳細資訊，請參閱 內容轉換追蹤。

本主題說明外部收件者的郵件轉換選項。

Exchange 和 Outlook 郵件格式

下列清單描述 Exchange 和 Microsoft Outlook 中可用的基本郵件格式：

  • 純文字：純文字訊息只會使用 US-ASCII 文字，如 RFC 2822 中所述。 郵件不能包含不同字型或其他文字格式。 下列兩種格式可用於純文字訊息：

    • 訊息標頭和訊息本文是由 US-ASCII 文字所組成。 附件必須使用 Uuencode進行編碼。 Uuencode 代表 Unix-to-Unix 編碼，並定義編碼演算法，以使用 US-ASCII 文字字元將二進位附件儲存在電子郵件的本文中。

    • 訊息會以文字/純文字的 Content-Type 值進行 MIME 編碼，而多部分訊息文字部分的 Content-Transfer-Encoding 值為 7 位。 任何訊息附件都會使用 Quoted-printable 或 Base64 編碼進行編碼。 根據預設，當您在 Outlook 中撰寫及傳送純文字訊息時，訊息會以文字/純文字的 Content-Type 值進行 MIME 編碼。

  • HTML：HTML 訊息支援文字格式設定、背景影像、資料表、專案符號點和其他圖形元素。 根據定義，HTML 格式的訊息必須是 MIME 編碼，才能保留這些格式化元素。

  • RTF) (RTF 格式 ：RTF 支援文字格式設定和其他圖形化元素。 RTF 與 TNEF 同義。 TNEF 和 RTF 可以交替使用。 RTF 簡訊格式與 Microsoft Word 中提供的 RTF 檔案格式完全不同。

    只有 Outlook 和少數其他 MAPI 電子郵件用戶端能夠判讀 RTF 郵件。

  • TNEF：傳輸中性封裝格式是用於封裝 MAPI 訊息屬性的 Microsoft 特定格式。 TNEF 郵件包含一個純文字版的郵件，以及一個包裝原始格式版本郵件的附件。 此附件通常命名為 Winmail.dat。 Winmail.dat 附件包含下列資訊：

    • 原始格式版本的郵件，例如包括字型、文字大小及文字色彩

    • OLE 物件，例如包括內嵌圖片或內嵌 Microsoft Office 文件

    • 特殊的 Outlook 功能，例如包括自訂表單、投票按鈕或會議邀請

    • 原始郵件中的一般郵件附件

      產生的純文字郵件可以用下列格式呈現：

    • RFC 2822 相容郵件，只由 US-ASCII 文字及 Uuencode 編碼的 Winmail.dat 附件組成

    • 含有 Winmail.dat 附件的 Multipart MIME 編碼郵件

      完全瞭解 TNEF 的 MAPI 相容電子郵件用戶端，例如 Outlook，會處理 Winmail.dat 附件並顯示原始郵件內容，而不需要顯示 Winmail.dat 附件。 無法判讀 TNEF 的電子郵件用戶端，可透過下列任何方式來呈現 TNEF 郵件：

    • 郵件的純文字版本隨即顯示，且訊息包含名為 Winmail.dat、Win.dat 的附件，或一些其他泛型名稱，例如 Att_nnnnn_.dat 或 Att_nnnnn_.eml，其中 nnnnn 預留位置代表亂數。

    • 顯示純文字版的郵件。 忽略或移除 TNEF 附件。 結果為純文字郵件。

    • 瞭解 TNEF 的傳訊伺服器可以設定為從傳入訊息中移除 TNEF 附件。 結果為純文字郵件。 此外，某些電子郵件用戶端，例如 Microsoft Outlook Express 可能不了解 TNEF，但會辨識並忽略 TNEF 附件。 結果為純文字郵件。

      有協力廠商公用程式可以協助轉換 Winmail.dat 附件。

      自 Exchange Server 5.5 版 起，所有 Exchange 版本都可判讀 TNEF。

  • 摘要傳輸中性封裝格式 (STNEF) ：STNEF 相當於 TNEF。 不過，STNEF 訊息的編碼方式與 TNEF 訊息不同。 具體而言，STNEF 訊息一律會以 MIME 編碼，且一律具有 Content-Transfer-Encoding 值二進位。 因此，訊息沒有純文字標記法，而且訊息本文中沒有包含不同的 Winmail.dat 附件。 整個訊息只會使用二進位資料來表示。 Content-Transfer-Encoding 值為 Binary 的訊息只能在支援及公告 BINARYMIME 和 CHUNKING SMTP 擴充功能的 SMTP 訊息伺服器之間傳輸，如 RFC 3030 中所定義。 訊息一律會使用 BDAT 命令，而不是標準 DATA 命令，在 SMTP 訊息之間傳輸。

    自 Exchange 2000 起，所有 Exchange 版本都瞭解 STNEF。 STNEF 會自動用於組織中 Exchange 伺服器之間傳輸的所有訊息，因為原生模式Exchange Server 2003 年。

    Exchange 永遠不會將 STNEF 訊息傳送給外部收件者。 只有 TNEF 訊息可以傳送給 Exchange 組織外部的收件者。

外部收件者的內容轉換選項

您在 Exchange 組織中可為外部收件者設定的內容轉換選項分為下列幾類來說明：

  • TNEF 轉換選項：這些轉換選項會指定應該保留 TNEF，還是從離開 Exchange 組織的訊息中移除 TNEF。

  • 訊息編碼選項：這些選項會指定訊息編碼選項，例如 MIME 和非 MIME 字元集、訊息編碼和附件格式。

這些轉換和編碼選項彼此獨立。 例如，TNEF 訊息是否可以離開 Exchange 組織，與這些訊息的 MIME 編碼設定或純文字編碼設定無關。

您可以在 Exchange 組織的各種層級指定內容轉換，如下列清單所述：

  • 遠端網域設定：遠端網域會定義 Exchange 組織與外部網域之間傳出訊息傳輸的設定。 即使您未為特定網域建立遠端網域專案，也有名為 Default 的預先定義遠端網域適用于所有遠端位址空間 (*) 。

  • 郵件使用者和郵件連絡人設定：郵件使用者和郵件連絡人很類似，因為兩者都有外部電子郵件地址，而且包含 Exchange 組織外部人員的相關資訊。 主要差異在於郵件使用者的帳戶可用來登入 Active Directory 網域，並存取組織中的資源。

  • Outlook 設定：在 Outlook 中，您可以設定下列清單中所述的訊息格式設定和編碼選項：

    • 訊息格式：您可以設定所有訊息的預設訊息格式。 在撰寫特定郵件時，也可以覆寫預設郵件格式。

    • 網際網路訊息格式：您可以控制 TNEF 訊息是否傳送給遠端收件者，或是否先轉換成更相容的格式。 對於傳送給遠端收件者的郵件，您也可以指定各種郵件編碼選項。 這些設定不適用於傳送給 Exchange 組織中收件者的郵件。

    • 網際網路收件者訊息格式：您可以控制 TNEF 訊息是否傳送給特定收件者，或是否先轉換成更相容的格式。 您可以在 [連絡人] 資料夾中設定特定連絡人的轉換選項，而且可以在撰寫郵件時，覆寫 [收件者]、[副本] 或 [密件副本] 欄位中特定收件者的轉換選項。 Exchange 組織中的收件者無法使用這些轉換選項。

    • 網際網路收件者郵件編碼選項：您可以控制 [連絡人] 資料夾中特定連絡人的 MIME 或純文字編碼選項，而且您可以在撰寫郵件時，覆寫 [收件者]、[副本] 或 [密件副本] 欄位中特定收件者的轉換選項。 Exchange 組織中的收件者無法使用這些轉換選項。

    • 國際選項：您可以控制訊息中使用的字元集。

TNEF 轉換選項

您可以指定下列層級的 TNEF 轉換選項：

  • 遠端網域設定
  • 郵件使用者和郵件連絡人設定
  • Outlook 設定，包括：
    • 郵件格式
    • 網際網路郵件格式
    • 網際網路收件者郵件格式

郵件編碼選項

您可以指定下列層級的郵件編碼選項：

  • 遠端網域設定
  • 郵件使用者和郵件連絡人設定
  • Outlook 設定，包括：
    • 郵件格式
    • 網際網路郵件
    • 網際網路收件者郵件格式
    • 郵件字元集編碼選項

如需詳細資訊，請參閱郵件編碼選項。

了解電子郵件的結構

若要進一步瞭解外部收件者的內容轉換選項，您必須瞭解電子郵件訊息的結構。 SMTP 訊息是以用來撰寫和傳送電子郵件訊息的純 7 位 US-ASCII 文字為基礎。 標準 SMTP 訊息包含下列元素：

  • 郵件信封：郵件信封定義于 RFC 2821 中。 訊息信封包含傳輸和傳遞訊息所需的資訊。 收件者永遠不會看到郵件信封，因為它是由訊息傳輸程式所產生，而且實際上不是郵件內容的一部分。

  • 訊息內容：訊息內容是在 RFC 2822 中定義。 郵件內容是由下列元素組成：

    • 訊息標頭：訊息標頭是標頭欄位的集合。 標頭欄位是由功能變數名稱所組成，後面接著冒號 (：) 字元，後面接著欄位本文，最後是換行字元/換行字元 (CR/LF) 字元組合。

      • 功能變數名稱必須由可列印的 US-ASCII 文字字元組成，但冒號 (：) 字元除外。 具體而言，允許具有 33 到 57 和 59 到 126 值的 ASCII 字元。

      • 欄位主體可以由任何 US-ASCII 字元組成，但 CR) 字元 (歸位字元和換行字元 (LF) 字元除外。 不過，欄位主體在頁 首資料夾中使用時，可能會包含 CR/LF 字元組合。 標標頭檔夾是將單一標頭欄位主體分成多行，如 RFC 2822 2.2.3 節所述。 RFC 2822 第 3 和 4 節說明其他欄位主體語法需求。

    • 訊息本文：訊息本文是顯示在訊息標頭後面之 US-ASCII 文字字元行的集合。 訊息標頭和訊息本文會以以 CR/LF 字元組合結尾的空白行分隔。 訊息本文是選擇性的。 訊息本文中的任何文字行都必須小於 998 個字元。 CR 和 LF 字元只能一起顯示，以表示行的結尾。

當 SMTP 訊息包含不是純 US-ASCII 文字的專案時，必須編碼訊息才能保留這些元素。 MIME 標準會定義非文字之訊息中內容編碼的方法。 MIME 允許其他字元集中的文字、不含文字的附件、多部分訊息本文，以及其他字元集中的標頭欄位。 MIME 定義于 RFC 2045、RFC 2046、RFC 2047、RFC 2048 和 RFC 2077 中。 MIME 會定義指定其他訊息屬性的標頭欄位集合。 下表描述一些重要的 MIME 標頭欄位。

重要 MIME 標頭欄位

標頭功能變數名稱 預設值 描述
MIME-Version 1.0 此標頭欄位是出現在 MIME 格式訊息中的第一個 MIME 標頭欄位。 此標頭欄位會出現在其他標準 RFC 2822 標頭欄位之後，但在任何其他 MIME 標頭欄位之前。 MIME 感知電子郵件用戶端會使用此標頭欄位來識別 MIME 編碼的訊息。 當此標頭欄位不存在時，MIME 感知電子郵件用戶端會將訊息識別為純文字。
Content-Type text/plain 此標頭欄位會識別訊息內容的媒體類型，如 RFC 2046 中所述。 媒體類型包含類型、子類型，以及一或多個選擇性參數，例如定義 MIME 字元編碼的 charset= 參數。 開頭為 「x-」 的類型不是標準的。 開頭為 「vnd」 的子類型是廠商特有的。 IANA (的網際網路指派號碼授權單位) 維護已註冊媒體類型的清單。 如需詳細資訊，請參閱 MIME 媒體類型。

多部分媒體類型可讓您使用不同媒體類型所定義的區段，在相同的訊息中提供多個訊息元件。 某些 Content-Type 域值包括 text/plain、text/html、multipart/mixed 和 multipart/alternative。
Content-Transfer-Encoding 7 位 此標頭欄位可以描述有關訊息的下列資訊：
  • 編碼演算法，用來轉換存在於訊息本文中的任何非 US-ASCII 文字或二進位資料。
  • 描述訊息本文目前條件的指標。

MIME 訊息中可以有多個 Content-Transfer-Encoding 標頭欄位的值。 當 Content-Transfer-Encoding 標頭欄位出現在訊息標頭中時，它會套用至訊息的整個本文。 當 Content-Transfer-Encoding 標頭欄位出現在多部分訊息的其中一個部分時，它只適用于訊息的該部分。

將編碼演算法套用至訊息本文資料時，訊息本文資料會轉換成純文字 US-ASCII 文字。 此轉換可讓訊息通過僅支援 US-ASCII 文字訊息的舊版 SMTP 訊息伺服器。 表示在訊息本文上使用編碼演算法的 Content-Transfer-Encoding 標頭欄位值如下所示：

  • 可引號列印：此編碼演算法會使用可列印的 US-ASCII 字元來編碼訊息本文資料。 如果原始郵件內文大部分是 US-ASCII 文字，可加上引號的可列印編碼會提供一些可讀取且精簡的結果。 除了等號之外，所有可列印的 US-ASCII 文字字元 (=) 字元都可以在沒有編碼的情況下表示。
  • Base64：此編碼演算法主要以 RFC 1421 中定義的隱私權增強型郵件 (PEM) 標準為基礎。 Base64 編碼會使用 64 個字元的字母編碼演算法和 PEM 所定義的輸出填補字元來編碼訊息本文資料。 Base64 編碼的訊息通常比原始訊息大 33%。 Base64 編碼會產生可預測的訊息大小增加，並且最適合用於二進位資料和非 US-ASCII 文字。

一般而言，您不會在相同的訊息中看到使用多個編碼演算法。

當訊息本文上未使用任何編碼演算法時，Content-Transfer-Encoding 標頭欄位只會識別訊息本文資料的目前條件。 Content-Transfer-Encoding 標頭欄位的下列值指出訊息本文上未使用任何編碼演算法：

  • 7 位：這個值表示訊息本文資料已經是 RFC 2822 格式。 具體而言，這表示下列條件必須成立：
    • 所有文字行長度都必須小於 998 個字元。
    • 所有字元都必須是具有 1 到 127 字元值的 US-ASCII 文字。
    • CR 和 LF 字元只能一起用來表示文字行的結尾。

    整個訊息本文可能是 7 位，或多部分訊息中訊息本文的一部分可能是 7 位。 如果多部分訊息包含具有任何二進位資料或非 US-ASCII 文字的其他元件，則必須使用可加上引號或 Base64 編碼演算法來編碼訊息的該部分。

    具有 7 位主體的訊息可以使用標準 DATA 命令在 SMTP 訊息伺服器之間移動。

  • 8 位：此值表示訊息本文資料包含非 US-ASCII 字元。 具體而言，這表示下列條件必須成立：
    • 所有文字行長度都必須小於 998 個字元。
    • 訊息本文中的一或多個字元具有大於 127 的值。
    • CR 和 LF 字元只能一起用來表示文字行的結尾。

    整個訊息本文可以是 8 位，或多部分訊息中訊息本文的一部分可能是 8 位。 如果多部分訊息包含具有二進位資料的其他元件，則必須使用可加引號或 Base64 編碼演算法來編碼訊息的該部分。

    具有 8 位主體的訊息只能在支援 RFC 1652 中定義之 8BITMIME SMTP 延伸模組的 SMTP 訊息伺服器之間移動，例如執行 Exchange 2000 Server 或更新版本的伺服器。 具體而言，這表示下列條件必須成立：

    • 8BITMIME 關鍵字必須在伺服器的 EHLO 回應中公告。
    • 訊息仍會使用 SMTP 標準 DATA 命令來傳輸。 不過，BODY=8BITMIME 參數必須新增至 MAIL FROM 命令的結尾。
  • 二進位：這個值表示訊息本文包含非 US-ASCII 文字或二進位資料。 具體而言，這表示下列條件成立：
    • 允許任何字元序列。
    • 沒有行長度限制。
    • 二進位訊息元素不需要編碼。

    具有二進位主體的訊息只能在支援 RFC 3030 中定義之 BINARYMIME SMTP 擴充功能的 SMTP 訊息伺服器之間移動，例如執行 Exchange 2000 Server 或更新版本的伺服器。 具體而言，這表示下列條件必須成立：

    • BINARYMIME 關鍵字必須在伺服器的 EHLO 回應中公告。
    • BINARYMIME SMTP 擴充功能只能與 CHUNKING SMTP 擴充功能搭配使用。 區塊化 可讓大型訊息本文以多個較小的區區塊轉送。 區塊處理也定義于 RFC 3030 中。 CHUNKING 關鍵字也必須在伺服器的 EHLO 回應中公告。
    • 訊息會使用 BDAT 命令而非標準 DATA 命令來傳輸。
    • 當訊息具有訊息本文時，BODY =BINARYMIME 參數必須新增至 MAIL FROM 命令的結尾。

7 位、8 位和二進位值永遠不會一起存在於相同的多部分訊息中。 這些值互斥。 可加上引號的可列印或 Base64 值可能會出現在 7 位或 8 位多部分訊息本文中，但絕不會出現在二進位訊息本文中。 如果多部分訊息本文包含由 7 位和 8 位內容組成的不同部分，則整個訊息會分類為 8 位。 如果多部分訊息本文包含由 7 位、8 位和二進位內容組成的不同部分，則整個訊息會分類為二進位。
Content-Disposition 附件 此標頭欄位會指示啟用 MIME 的電子郵件用戶端應如何顯示附加檔案，如 RFC 2183 中所述。 此欄位的值可以是 [內嵌] 或 [附件]。 當此欄位的值為 Inline 時，附件會顯示在訊息本文中。 當此欄位的值為 Attachment 時，附加檔案會顯示為與訊息本文不同的一般附件。 當值為 Attachment 時，可以使用其他參數，例如 Filename、Creation-date 和 Size。