Exchange Server中的内容转换

  • 项目

“内容转换”是针对每个收件人正确设置邮件格式的过程。 对消息执行内容转换的决定取决于消息的目标和格式。 Exchange 2016 和 Exchange 2019 中发生的内容转换类型与 Exchange 2013 相比保持不变：

  • 外部收件人的邮件转换：此类型的内容转换包括传输中性封装格式 (TNEF) 外部收件人的转换选项和邮件编码选项。 发送到 Exchange 组织内部的收件人的邮件不要求此类型的内容转换。 此类内容转换由邮箱服务器上的传输服务中的分类程序处理。 在将新到达的邮件放入提交队列之后，对每封邮件进行分类。 除了收件人解析和路由解析外，还要对邮件执行内容转换，然后再将该邮件放入传递队列。 如果单个邮件包含多个收件人，则分类程序会针对每个邮件收件人确定相应的编码。 但是，内容转换跟踪不会捕获分类程序转换发送到外部收件人的邮件时遇到的任何内容转换失败。

  • 内部收件人的 MAPI 转换：此类内容转换由邮箱传输服务处理。 邮箱传输服务位于邮箱服务器上，用于在本地服务器上邮箱数据库和邮箱服务器上的传输服务之间传输邮件。 具体来说，邮箱传输提交服务将邮件从发件人的发件箱传输到邮箱服务器上的传输服务。 邮箱传输传递服务将邮件从邮箱服务器的传输服务传输到收件人的收件箱。 邮箱传输提交服务转换 MAPI 的所有传出邮件，邮箱传输传递服务将所有传入邮件转换为 MAPI。 内容转换跟踪捕获这些 MAPI 转换失败。 有关详细信息，请参阅Managing Content Conversion Tracing。

Exchange 和 Outlook 邮件格式

以下列表介绍了 Exchange 和 Outlook 中可用的基本邮件格式：

  • 纯文本：纯文本消息仅使用 RFC 5322 中所述的 US-ASCII 文本。 这种邮件不能包含其他的字体或其他文本格式。 纯文本邮件可以使用以下两种格式：

    • 邮件头和邮件正文由 US-ASCII 文本组成。 必须使用 Uuencode 对附件进行编码。 Uuencode 指的是“Unix 到 Unix”的编码，它定义使用 US-ASCII 文本字符存储电子邮件正文中的二进制附件的编码算法。

    • 该消息是 MIME 编码的， Content-Type 值为 text/plain，对于多部分消息的文本部分， 则 Content-Transfer-Encoding 值 7bit 为 。 任何邮件附件都使用 Quoted-printable 或 Base64 编码进行编码。 默认情况下，在 Outlook 中撰写和发送纯文本邮件时，该邮件是 MIME 编码的， 内容类型 值为 text/plain。

  • HTML：HTML 消息支持文本格式、背景图像、表格、项目符号和其他图形元素。 根据定义，必须对 HTML 格式的邮件进行 MIME 编码以保留这些格式元素。

  • RTF (RTF) 格式：RTF 支持文本格式和其他图形元素。 RTF 与 TNEF 同义 (TNEF 和 RTF 可以互换使用) 。 富文本消息格式与 Word 中可用的格式文本文档格式完全不同。

  • TNEF：传输中性封装格式是 Microsoft 特定的格式，用于封装 MAPI 消息属性。 TNEF 邮件包含纯文本形式的邮件以及打包原始格式形式的邮件的附件。 通常，此附件名为 Winmail.dat。 Winmail.dat 附件包括以下信息：

    • 邮件的原始格式版本 (例如字体、文本大小和文本颜色)
    • OLE 对象 (，例如嵌入图片或嵌入的 Office 文档)
    • Outlook 特殊功能 (，例如自定义窗体、投票按钮或会议请求)
    • 原始邮件中的常规邮件附件

    最终生成的纯文本邮件可以通过下列格式表示：

    • RFC 5322 兼容邮件，仅由 US-ASCII 文本组成，带有以 Uuencode 编码的 Winmail.dat 附件
    • 带有 Winmail.dat 附件的多节 MIME 编码的邮件

    Outlook 和其他完全了解 TNEF 的电子邮件客户端处理 Winmail.dat 附件并显示原始邮件内容，而无需显示 Winmail.dat 附件。 不了解 TNEF 的Email客户端可能采用以下任一方式显示 TNEF 消息：

    • 将显示邮件的纯文本版本，邮件包含名为 Winmail.dat、Win.dat 的附件或其他一些通用名称，例如 Att nnnnn.dat 或 Att nnnnn.eml，其中 nnnnn 占位符表示随机数。
    • 显示纯文本版本的邮件。 忽略或删除 TNEF 附件。 结果是纯文本邮件。
    • 支持 TNEF 的邮件服务器可以配置为从传入邮件中删除 TNEF 附件。 结果是纯文本邮件。 此外，某些电子邮件客户端可能不了解 TNEF，但识别并忽略 TNEF 附件。 结果是纯文本邮件。

    有一些第三方实用程序可以帮助转换 Winmail.dat 附件。

    从 Exchange Server 版本 5.5 开始，所有 Exchange 版本均支持 TNEF。

  • 摘要 传输中性封装格式 (STNEF) ：STNEF 等效于 TNEF。 但是，STNEF 邮件的编码方式与 TNEF 邮件不同。 具体而言，STNEF 消息始终采用 MIME 编码，并且始终具有 Content-Transfer-Encoding 值 Binary。 所以，该邮件没有纯文本表示形式，并且该邮件的正文中没有确切的 Winmail.dat 附件。 整个邮件只使用二进制数据表示。 内容 传输编码 值为 Binary 的邮件只能在支持和播发 BINARYMIME 和 CHUNKING SMTP 扩展（如 RFC 3030 中定义）的消息服务器之间传输。 始终使用 BDAT 命令（而不是标准 DATA 命令）在消息服务器之间传输消息。

    从 Exchange 2000 开始，所有 Exchange 版本均支持 STNEF。 从本机模式 Exchange Server 2003 开始，STNEF 自动用于组织中 Exchange 服务器之间传输的所有邮件。

    Exchange 从不将 STNEF 邮件发送到外部收件人。 只有 TNEF 邮件可以发送到 Exchange 组织外的收件人。

外部收件人的内容转换选项

您可以在 Exchange 组织中为外部收件人设置的内容转换选项可以分为以下几类：

  • TNEF 转换选项：这些转换选项指定是应保留还是应从离开 Exchange 组织的邮件中删除 TNEF。
  • 邮件编码选项：这些选项指定邮件编码选项，例如 MIME 和非 MIME 字符集、邮件编码和附件格式。

这些转换和编码选项相互独立。 例如，TNEF 邮件是否可以从 Exchange 组织发出与这些邮件的 MIME 编码设置或纯文本编码设置无关。

您可以在各种 Exchange 组织级别指定内容转换，如下面列表所示：

  • 远程域设置：远程域定义 Exchange 组织和外部域之间的传出邮件传输设置。 即使没有为特定域创建远程域条目，也会存在一个名为 Default 的预定义远程域，它适用于所有远程地址空间 ( * )。 有关远程域的详细信息，请参阅 远程域。

  • 邮件用户和邮件联系人设置：邮件用户和邮件联系人相似，因为两者都有外部电子邮件地址，并且包含有关 Exchange 组织外部人员的信息。 主要区别在于邮件用户拥有可用于登录 Active Directory 和访问组织中的资源的帐户。 有关详细信息，请参阅 收件人。

  • Outlook 设置：可以在 Outlook 中设置以下邮件格式和编码选项：

    • 邮件格式：可以设置所有邮件的默认消息格式。 撰写特定邮件时，您可以覆盖默认邮件格式。
    • Internet 邮件格式：可以控制是否将 TNEF 邮件发送给远程收件人，或者是否首先将其转换为更兼容的格式。 您还可以为发送到远程收件人的邮件指定各种邮件编码选项。 这些设置不适用于发送到 Exchange 组织中的邮件。
    • (Outlook 2010 或更早版本的 Internet 收件人邮件格式) ：您可以控制是否将 TNEF 邮件发送到“联系人”文件夹中的特定联系人。 这些转换选项不适用于 Exchange 组织中的收件人。
    • (Outlook 2010 或更早版本的 Internet 收件人邮件编码选项) ：您可以控制“联系人”文件夹中特定联系人的 MIME 或纯文本编码选项。 这些转换选项不适用于 Exchange 组织中的收件人。
    • 国际选项：可以控制消息中使用的字符集。

    有关这些设置的详细信息，请参阅 Exchange Server 中的 TNEF 转换选项和消息编码选项。

了解电子邮件消息的结构

为了更好地了解外部收件人的内容转换选项，需要了解电子邮件的结构。 SMTP 邮件基于 7 位 US-ASCII 纯文本来撰写和发送电子邮件。 标准 SMTP 邮件由下列元素组成：

  • 邮件信封：消息信封在 RFC 5321 中定义。 邮件信封包括传输和传递邮件所需的信息。 收件人从不会看到邮件信封，因为它是由邮件传输进程生成的，实际上并不是邮件内容的一部分。

  • 消息内容：消息内容在 RFC 5322 中定义。 邮件内容由下列元素组成：

    • 邮件头：邮件头是标头字段的集合。 头字段包括字段名称，后跟冒号 (:)、字段正文，最后是回车换行 (CR/LF) 字符组合。

      字段名称必须由可打印的 US-ASCII 文本字符（冒号 (:) 除外）组成。 具体来说，允许使用值范围在 33 到 57 和 59 到 126 的 ASCII 字符。

      字段正文可由任何 US-ASCII 字符组成，但回车符 (CR) 和换行符 (LF) 除外。 但是，在“头折叠”中使用时，字段正文可以包含 CR/LF 字符组合。 标头折叠是将单个标头字段正文分隔成多个行，如 RFC 5322 第 2.2.3 节中所述。 RFC 5322 第 3 节和第 4 节介绍了其他字段正文语法要求。

    • 邮件正文：邮件正文是邮件头后面的 US-ASCII 文本字符行的集合。 邮件头和邮件正文由一个以 CR/LF 字符组合结尾的空行分隔。 邮件正文是可选的。 在邮件正文中，任何文本行都不得超过 998 个字符。 CR 和 LF 字符同时显示才能表示一行的结束。

当 SMTP 邮件包含非 US-ASCII 纯文本元素时，必须对其进行编码以保留这些元素。 MIME 标准定义了一种对邮件中非文本内容进行编码的方法。 MIME 允许存在使用其他字符集的文本、不带文本的附件、多部分邮件正文以及使用其他字符集的头字段。 MIME 在 RFC 2045、RFC 2046、RFC 2047、RFC 4288、RFC 4289 和 RFC 2049 中定义。 MIME 定义了指定其他邮件属性的头字段集合。 以下部分介绍一些重要的 MIME 标头字段。

MIME-Version标头字段

默认值： 1.0

此头字段是 MIME 格式的邮件中出现的第一个 MIME 头字段。 此标头字段显示在其他标准 RFC 5322 标头字段之后，但在任何其他 MIME 标头字段之前。 MIME 感知电子邮件客户端使用此头字段标识 MIME 编码的邮件。 当缺少此头字段时，MIME 感知电子邮件客户端会将该邮件标识为纯文本。

Content-Type 标头字段

默认值： text/plain

此头字段标识 RFC 2046 中描述的邮件内容的媒体类型。 媒体类型包括：

  • 类型：

    • 以 x- 开头的类型不是标准类型。 Internet 号码分配机构 (IANA) 维护已注册的媒体类型列表。 有关详细信息，请参阅 MIME 媒体类型。

    • 多节媒体类型通过使用由不同媒体类型定义的节允许在同一邮件中使用多个邮件部分。 某些 Content-Type 字段值包括 text/plain、 text/html、 multipart/mixed和 multipart/alternative。

  • 子类型：以 vnd. 开头的子类型特定于供应商。

  • 一个或多个可选参数：例如， charset= 定义 MIME 字符编码的参数。

Content-Transfer-Encoding 标头字段

默认值： 7bit

此头字段可以说明有关邮件的以下信息：

  • 用于转换邮件正文中的任何非 US-ASCII 文本或二进制数据的编码算法。
  • 描述邮件正文当前情况的指示器。

MIME 邮件中 “Content-Transfer-Encoding 标头”字段可以有多个值。 当邮件头中出现 Content-Transfer-Encoding 标头字段时，它将应用于邮件的整个正文。 当 内容传输编码 标头字段出现在多部分消息的其中一部分时，它仅适用于邮件的该部分。

如果对邮件正文数据应用编码算法，邮件正文数据将转换为 US-ASCII 纯文本。 此转换允许消息通过仅支持 US-ASCII 文本中的消息的旧消息传送服务器。 指示在邮件正文上使用编码算法 的 Content-Transfer-Encoding 标头字段值为：

  • Quoted-printable：使用可打印的 US-ASCII 字符对消息正文数据进行编码。 如果原始邮件文本大部分都是 US-ASCII 文本，则 quoted-printable 编码可提供便于阅读的紧凑的显示结果。 除了等号字符 (=) 之外，所有可打印 US-ASCII 文本字符都可不经过编码而呈现。

  • Base64：主要基于 RFC 4648 中定义的) 标准的 PEM (增强隐私的邮件。 Base64 编码使用 64 个字符字母编码算法和 PEM 定义的输出填充字符对邮件正文数据进行编码。 经过 Base64 编码的邮件通常比原始邮件大 33%。 经 Base64 编码而增加的邮件大小是可预测的，对于二进制数据和非 US-ASCII 文本来说它是最佳选择。

通常，您不会看到在同一个邮件中使用多个编码算法。

如果邮件正文上未使用编码算法， 则 Content-Transfer-Encoding 标头字段仅标识消息正文数据的当前状况。 指示邮件正文上未使用编码算法 的内容传输编码 标头字段值为：

  • 7bit：指示消息正文数据已采用 RFC 5322 格式。 具体来说，这表示必须满足下列条件：

    • 所有文本行的长度不得超过 998 个字符。

    • 所有字符必须是字符值为 1 到 127（包括 1 和 127）的 US-ASCII 文本。

    • CR 和 LF 字符一起使用才能表示一个文本行的结束。

      整个消息正文可以是 7 位，或者多部分消息中的部分消息正文可能是 7 位。 如果多部分邮件包含具有任何二进制数据或非 US-ASCII 文本的其他部分，则必须使用 Quoted-printable 或 Base64 编码算法对邮件的该部分进行编码。

      具有 7 位正文的消息可以使用标准 DATA 命令在消息传送服务器之间传输。

  • 8bit：指示消息正文数据包含非 US-ASCII 字符。 具体来说，这表示必须满足下列条件：

    • 所有文本行的长度不得超过 998 个字符。

    • 邮件正文中一个或多个字符的值大于 127。

    • CR 和 LF 字符一起使用才能表示一个文本行的结束。

      整个消息正文可以是 8 位，或者多部分消息中的部分消息正文可能是 8 位。 如果多部分邮件包含具有二进制数据的其他部分，则必须使用 Quoted-printable 或 Base64 编码算法对邮件的该部分进行编码。

      具有 8 位正文的邮件只能在支持 RFC 6152 中定义的 8BITMIME SMTP 扩展的邮件服务器之间传输，例如 Exchange 2000 Server 或更高版本。 具体来说，这表示必须满足下列条件：

    • 必须在服务器的 EHLO 响应中播发 8BITMIME 关键字。

    • 仍使用 SMTP 标准 DATA 命令传输邮件。 但是， BODY=8BITMIME 必须将 参数添加到 MAIL FROM 命令的末尾。

  • Binary：指示消息正文包含非 US-ASCII 文本或二进制数据。 具体来说，这表示必须满足下列条件：

    • 允许使用任何字符序列。

    • 行没有长度限制。

    • 二进制邮件元素不需要编码。

      具有二进制正文的邮件只能在支持 RFC 3030 中定义的 BINARYMIME SMTP 扩展的邮件服务器之间传输，例如 Exchange 2000 Server 或更高版本。 具体来说，这表示必须满足下列条件：

    • BINARYMIME 关键字必须在服务器的 EHLO 响应中播发。

    • BINARYMIME SMTP 扩展只能与 CHUNKING SMTP 扩展一起使用。 “分块”允许以多个较小块的形式发送大型邮件正文。 分块也在 RFC 3030 中定义。 此外，还必须在服务器的 EHLO 响应中播发 CHUNKING 关键字。

    • 使用 BDAT 命令而不是标准 DATA 命令传输消息。

    • 当邮件具有邮件 BODY=BINARYMIME 正文时，必须将 参数添加到 MAIL FROM 命令的末尾。

值 7bit、 8bit和 Binary 永远不会在同一多部分消息中一起存在， (值) 互斥。 Quoted-printable或 Base64 值可能显示在 7 位或 8 位多部分消息正文中，但绝不出现在二进制消息正文中。 如果多部分消息正文包含由 7 位和 8 位内容组成的不同部分，则整个消息被归类为 8 位。 如果多部分消息正文包含由 7 位、8 位和二进制内容组成的不同部分，则整个消息被归类为二进制。

Content-Disposition 标头字段

默认值： Attachment

此头字段指示启用 MIME 的电子邮件客户端应如何显示附件，在 RFC 2183 中有相关说明。 有效值包含:

  • Inline：附件显示在邮件正文中。

  • Attachment：附加文件显示为独立于邮件正文的常规附件。 其他参数也与此值 (， Filename例如、 Creation-date和 Size) 。