了解内容转换

 

适用于: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

上一次修改主题: 2009-09-09

“内容转换”是针对每个收件人正确设置邮件格式的过程。是否对邮件执行内容转换取决于要处理的邮件的目标和格式。发送到 Microsoft Exchange Server 组织内收件人的邮件不需要执行任何内容转换。只有发送到外部收件人的邮件才可能需要执行内容转换。

在 Exchange Server 2007 组织中,在安装了集线器传输服务器角色的服务器上通过分类程序处理内容转换。在将新到达的邮件放入提交队列之后,对每封邮件进行分类。除了收件人解析和路由解析外,还要对邮件执行内容转换,然后再将该邮件放入传递队列。如果单个邮件包含多个收件人,则内容转换会针对每个邮件收件人确定相应的编码。在边缘传输服务器上,将进行简化的分类。此操作并不涉及内容转换。

了解电子邮件的结构

为了更好地理解内容转换,您必须了解电子邮件的结构。简单邮件传输协议 (SMTP) 基于 7 位 US-ASCII 纯文本撰写和发送电子邮件。标准 SMTP 邮件由下列元素组成:

  • 邮件信封   邮件信封在 RFC 2821 中定义。邮件信封包含传输和发送邮件所需的信息。收件人不会看到邮件信封,因为它是由邮件传输进程生成的,实际上并不是邮件内容的一部分。

  • 邮件内容   邮件内容在 RFC 2822 中定义。邮件内容由下列元素组成:

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

      字段名称必须由可打印的 US-ASCII 文本字符(冒号 ( : ) 除外)组成。具体来说,允许使用值介于 33 到 57(含两者)和 59 到 126(含两者)之间的 ASCII 字符。

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

    • 邮件正文   邮件正文是继邮件头之后出现的 US-ASCII 文本字符行的集合。邮件头和邮件正文由一个以 CRLF 字符组合结尾的空行分隔。邮件正文是可选的。在邮件正文中,任何文本行都不得超过 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 头字段之后,任何其他非标准 RFC 2822 头字段之前。MIME 感知电子邮件客户端使用此头字段标识 MIME 编码的邮件。当缺少此头字段时,MIME 感知电子邮件客户端会将该邮件标识为纯文本。

Content-Type:

text/plain

此头字段标识 RFC 2046 中描述的邮件内容的媒体类型。媒体类型由类型、子类型以及一个或多个可选参数组成,如定义 MIME 字符编码的 charset= 参数。以“x-”开头的类型是非标准类型。以“vnd.”开头的子类型是供应商特定的类型。Internet 名称分配机构 (IANA) 维护已注册的媒体类型列表。有关详细信息,请参阅 MIME Media Types

note注意:
UNRESOLVED_TOKEN_VAL(exNote3rdPartyURL)

“多节”媒体类型通过使用由不同媒体类型定义的节允许在同一邮件中使用多个邮件部分。Content-Type: 字段值的示例有:text/plain、text/html、multipart/mixed 和 multipart/alternative。

Content-Transfer-Encoding:

7bit

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

  • 用于转换邮件正文中的任何非 US-ASCII 文本或二进制数据的编码算法。

  • 描述邮件正文当前情况的指示器。

MIME 邮件中的 Content-Transfer-Encoding: 头字段可能有多个值。如果 Content-Transfer-Encoding: 头字段出现在邮件头中,则适用于整个邮件正文。如果 Content-Transfer-Encoding: 头字段出现在多部分邮件的一部分中,则仅适用于该邮件部分。

如果对邮件正文数据应用编码算法,邮件正文数据将转换为 US-ASCII 纯文本。此转换允许邮件通过仅支持 US-ASCII 文本邮件的旧版 SMTP 邮件服务器。表示在邮件正文中使用的编码算法的 Content-Transfer-Encoding:头字段的值如下:

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

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

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

如果未对邮件正文使用编码算法,Content-Transfer-Encoding: 头字段只标识邮件正文数据的当前情况。Content-Transfer-Encoding:头字段的下列值表示邮件正文中没有使用编码算法:

  • 7bit   此值表示邮件正文数据已使用 RFC 2822 格式。具体来说,这表示必须满足下列条件:

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

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

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

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

    具有 7bit 正文的邮件可以使用标准 DATA 命令在 SMTP 邮件服务器之间传输。

  • 8bit   此值表示邮件正文数据包含非 US-ASCII 字符。具体来说,这表示必须满足下列条件:

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

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

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

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

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

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

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

  • Binary   此值表示邮件正文包含非 US-ASCII 文本或二进制数据。具体来说,这表示必须满足下列条件:

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

    • 行没有长度限制。

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

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

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

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

    • 邮件使用 BDAT 命令而不是标准 DATA 命令进行传输。

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

在同一个多部分邮件中不能同时存在 7bit、8bit 和 Binary。这些值相互排斥。Quoted-printable 或 Base64 值可以在 7bit 或 8bit 多部分邮件正文中出现,但永远不会在 Binary 邮件正文出现。如果多部分邮件正文包含由 7bit 和 8bit 内容组成的不同部分,则整个邮件被归类为 8bit。如果多部分邮件正文包含由 7bit、8bit 和 Binary 内容组成的不同部分,则整个邮件被归类为 Binary。

Content-Disposition:

Attachment

此头字段指示启用 MIME 的电子邮件客户端应如何显示附件,在 RFC 2183 中有相关说明。此字段的值可以是 Inline 或 Attachment。当此字段的值为 Inline 时,附件将显示在邮件正文中。当此字段的值为 Attachment 时,附件将显示为与邮件正文分开的常规附件。当值为 Attachment 时,可以使用其他参数,如 Filename、Creation-date 和 Size。

Exchange 2007 和 Outlook 邮件格式

下表介绍了 Exchange 2007 和 Microsoft Outlook 中可采用的基本邮件格式:

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

    • 邮件头和邮件正文由 US-ASCII 文本组成。

    • 邮件实际上是经过 MIME 编码的邮件,并且 Content-Type 的值为 text/plain(对于多部分邮件的文本部分,Content-Transfer-Encoding 的值为 7bit)。任何邮件附件都使用 Quoted-printable 或 Base64 编码进行编码。默认情况下,当您在 Outlook 中撰写和发送纯文本邮件时,该邮件实际上是经过 MIME 编码的邮件,Content-Type 值为 text/plain。

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

  • RTF 格式 (RTF)   RTF 支持文本格式和其他图形元素。RTF 与传输中性编码格式 (TNEF) 同义。TNEF 与 RTF 可以互换使用。

    仅 Outlook 和几个其他 MAPI 电子邮件客户端支持 RTF 邮件。MAPI 是一种 Microsoft 开发的邮件体系结构,可使多个应用程序在多种不同的硬件平台上与不同的邮件系统交互。MAPI 基于组件对象模型 (COM) 体系结构构建。Outlook 使用 MAPI 与安装了邮箱服务器角色的运行 Exchange 2007 的计算机上的邮箱进行通信。

    RTF 邮件格式与 Microsoft Word 中的 RTF 文档格式完全不同。

  • TNEF   TNEF 是特定于 Microsoft 的格式,用于封装 MAPI 邮件属性。TNEF 邮件包含一个纯文本版本的邮件和一个将原始格式版本的邮件打包在内的附件。通常,此附件名为 Winmail.dat,它包含以下信息:

    • 邮件的原始格式版本,如字体、文本大小和文字颜色

    • OLE 对象,如嵌入的图片或嵌入的 Microsoft Office 文档

    • 特殊 Outlook 功能,如自定义表单、投票按钮或会议请求

    • 原始邮件中的常规邮件附件

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

    • 符合 RFC 2822 的邮件仅包含 US-ASCII 文本

    • 带有 Winmail.dat 附件的多节 MIME 编码的邮件

    完全支持 TNEF 的符合 MAPI 的电子邮件客户端(如 Outlook)会处理 Winmail.dat 附件,并显示原始邮件内容而不显示 Winmail.dat 附件。不支持 TNEF 的电子邮件客户端可以通过下列任一方式显示 TNEF 邮件:

    • 显示纯文本版本的邮件,并且该邮件包含名为 Winmail.dat、Win.dat 或一些其他中性名称(如 Attnnnnn.dat 或 Attnnnnn.eml,其中 nnnnn 占位符表示随机数字)的附件。

    • 显示纯文本版本的邮件。忽略或删除 TNEF 附件。结果是纯文本邮件。

    • 支持 TNEF 的邮件服务器可以配置为从传入邮件中删除 TNEF 附件。结果是纯文本邮件。另外,某些电子邮件客户端(如 Microsoft Outlook Express)可能不支持 TNEF,但可以识别和忽略 TNEF 附件。结果是纯文本邮件。

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

    Exchange Server 5.0 和更高版本支持 TNEF。TNEF 邮件通过使用标准 DATA 命令动词在 SMTP 邮件服务器之间传输。Exchange 根据下列情况自动使用 TNEF:

    • Exchange 2000 Server   TNEF 用于在不同路由组中的 Exchange 服务器之间传输的邮件。

    • Exchange Server 2003   如果 Exchange 组织处于混合模式,TNEF 用于在不同路由组中的 Exchange 服务器之间传输的邮件。

  • 汇总传输中性编码格式 (STNEF)   STNEF 等同于 TNEF。但是,STNEF 邮件的编码方式与 TNEF 邮件不同。具体来说,STNEF 邮件始终进行 MIME 编码并且 Content-Transfer-Encoding 的值始终为 Binary。所以,该邮件没有纯文本表示形式,并且该邮件的正文中没有确切的 Winmail.dat 附件。整个邮件只使用二进制数据表示。Content-Transfer-Encoding 值为 Binary 的邮件只能在支持和公布在 RFC 3030 中定义的 BINARYMIME 和 CHUNKING SMTP 扩展的 SMTP 邮件服务器之间传输。通过 BDAT 命令而不是标准 DATA 命令,该邮件始终可以在 SMTP 邮件服务器之间传输。

    Exchange 2000 和更高版本支持 STNEF。如果出现下列情况,Exchange 将自动使用 STNEF:

    • Exchange 2000   STNEF 用于在相同路由组中的 Exchange 服务器之间传输的邮件。不受支持的修补程序还使 Exchange 2000 能够将 STNEF 用于在不同路由组中的 Exchange 服务器之间传输的邮件。

    • Exchange 2003   如果 Exchange 组织处于纯模式,则 STNEF 用于在组织中的 Exchange 服务器之间传输的所有邮件。

    • Exchange 2007   STNEF 用于在组织中的 Exchange 服务器之间传输的所有邮件。

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

内容转换的元素

内容转换是针对每个外部收件人正确设置邮件格式的行为。此转换由集线器传输服务器上的分类程序执行。

您可以在 Exchange 组织中设置的内容转换选项可以分为以下几类:

  • TNEF 转换选项   这些转换选项指定在从 Exchange 组织传出的邮件中应保留还是删除 TNEF。

  • 邮件编码选项   这些选项指定邮件编码选项,如 MIME 字符集和非 MIME 字符集、邮件编码以及附件格式。

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

您可以在各种 Exchange 组织级别指定内容转换,如下表所示:

  • 远程域设置   远程域定义 Exchange 2007 组织和 Active Directory 目录服务林外的域之间传输的传出邮件的设置。即使没有为特定域创建远程域条目,也会存在一个名为 Default 的预定义远程域,它适用于所有远程地址空间 ( * )。

  • 邮件用户和邮件联系人设置   邮件用户与邮件联系人相似 — 二者都具有外部电子邮件地址并包含有关 Exchange 组织外用户的信息。主要区别是邮件用户具有安全上下文,可用于登录到 Active Directory 域以及访问已经授予其权限的资源。

  • Outlook 设置   Outlook 允许您设置下表介绍的邮件格式和编码选项:

    • 邮件格式   您可以为所有邮件设置默认邮件格式。并且,您可以撰写特定邮件覆盖默认邮件格式。

    • Internet 邮件格式   您可以控制是否将 TNEF 邮件发送到远程收件人,或者是否先将这些邮件转换为更兼容的格式。您还可以为发送到远程收件人的邮件指定各种邮件编码选项。这些设置不适用于发送到 Exchange 组织中的邮件。

    • Internet 收件人邮件格式   您可以控制是否将 TNEF 邮件发送到特定收件人,或者是否先将这些邮件转换为更兼容的格式。您可以为联系人文件夹中的特定联系人设置转换选项,您可以在撰写邮件时在“收件人:”、“抄送:”或“密件抄送:”字段中覆盖特定收件人的转换选项。这些转换选项不适用于 Exchange 组织中的收件人。

    • Internet 收件人邮件编码选项   您可以控制联系人文件夹中特定联系人的 MIME 或纯文本编码选项,您可以在撰写邮件时在“收件人:”、“抄送:”或“密件抄送:”字段中覆盖特定收件人的转换选项。这些转换选项不适用于 Exchange 组织中的收件人。

    • 国际选项   您可以控制在邮件中使用的字符集。

TNEF 转换选项

您可以指定以下级别的 TNEF 转换选项:

  • 远程域设置

  • 邮件用户和邮件联系人设置

  • Outlook 设置

    • 邮件格式

    • Internet 邮件格式

    • Internet 收件人邮件格式

有关详细信息,请参阅 TNEF 转换选项

邮件编码选项

您可以指定以下级别的邮件选项:

  • 远程域设置

  • 邮件用户和邮件联系人设置

  • Outlook 设置

    • 邮件格式

    • Internet 邮件

    • Internet 收件人邮件格式

    • 邮件字符集编码选项

有关详细信息,请参阅邮件编码选项

存储驱动程序执行的内容转换

存储驱动程序也执行一种内容转换。集线器传输服务器上的存储驱动程序在邮箱服务器上的邮箱与提交列队之间传输邮件。具体来说,存储驱动程序将邮件从发件人的发件箱中发送到集线器传输服务器上的提交队列,并将邮件从集线器传输服务器上的 MAPI 传递队列中传输到收件人的收件箱中。存储驱动程序转换从 MAPI 传出和传入到 MAPI 的所有邮件。内容转换跟踪捕获这些存储驱动程序转换失败。

有关详细信息,请参阅管理内容转换跟踪