SMTP 传输组件

上一次修改主题： 2006-08-17

在 Exchange Server 2003 中，高级排队引擎使用下面的六个传输事件接收器将邮件传递到目标：

• Exchange Transport XEXCH50 Submission 此事件接收器在 Peexch50.dll 中实现，它使得 SMTP 传输子系统能够使用 XEXCH50 命令并通过 SMTP 接收来自远程 Exchange 服务器的邮件。此事件接收器是为 OnSubmission 事件注册的。

• Exchange Transport AntiVirus API 此事件接收器在 OnSubmit.dll 中实现，它使得非 Microsoft 供应商能够实现病毒扫描程序，从而在邮件到达其目标之前先检查每封邮件中是否有恶意的附件及数据结构。此事件接收器是为 OnSubmission 事件注册的。
  默认情况下，不启用传输扫描，因为它会导致邮件扫描两次，一次在 SMTP 层，一次在 Exchange 存储中。但是，如果您使用前端服务器将 Exchange 组织连接到 Internet，则可以使用下列注册表项在这些服务器上启用此功能。

  位置	HKey_Local_Machine\Software\Microsoft\Exchange\TransportAVAPI
  值	Enabled
  类型	REG_DWORD
  数值数据	0x1
  描述	0x1 值启用传输扫描。0x0 值禁用传输扫描。如果未指定值，则默认为 0x0。

  注意：
  传输扫描功能只能与基于病毒扫描应用程序编程接口 (VSAPI) 2.5 的 Exchange 病毒扫描程序一起使用。

• Exchange Categorizer 此事件接收器在 Phatcat.dll 中实现，并且是为 OnCategorize 事件类别中的各个事件注册的。分类程序是传输子系统中最重要的组件之一。它执行地址解析、完成邮件转发、设置每个域的出站和入站 Internet 邮件格式转换标志、展开通讯组列表，并强制实现阻止传递状态通知的全局设置。分类程序还可能出于日志记录的目的在邮件中添加替代的收件人，可能在必须创建邮件的多个副本时分割邮件，等等。分类程序将在本主题后面的“Exchange 分类程序”一节详细介绍。

• Mobile Categorizer 此事件接收器在 Miscat.dll 中实现，并且也是为 OnCategorize 事件类别中的各个事件注册的。此事件接收器支持移动设备（如 Microsoft Pocket PC）的最新通知，这是 Exchange Server 2003 中的新增功能。默认情况下，最新通知随同 Exchange Server 2003 一起安装。当事件生成，例如，当用户收到邮件时，就会向用户的 Pocket PC 发送通知。然后 Pocket PC 可以在后台执行同步，这样，当用户下一次检查设备时，就会了解到最新的信息。

  注意：
  只能在运行 Microsoft Windows Mobile 2003 操作系统的设备上使用最新通知。

• Exchange Router 此事件接收器在 Reapi.dll 中实现，并且是为 OnGetMessageRouter 事件类别中的各个事件注册的。Exchange Router 接收器是传输子系统中第二个最重要的组件。高级排队引擎使用该组件来确定通往邮件目标的下一个跃点。有关 Exchange Server 2003 路由体系结构的详细信息，请参阅 邮件路由体系结构。

• Exchange LoadBalancer 此事件接收器在 Reapi.dll 中实现，并且是为 OnDnsResolveRecord 事件注册的。高级排队引擎使用此接收器在为路由组连接器指定的所有桥头服务器之间平均分配出站邮件传输。有关路由组之间的负载平衡邮件传输的详细信息，请参阅邮件路由体系结构。

Exchange 分类程序

Exchange 邮件分类系统由两个组件组成，一个是基础分类程序，另一个是 Exchange 分类程序。基础分类程序由最初在 Aqueue.dll 中实现的代码组成。Exchange Server 2003 通过注册一个名为 Phatq.dll 的 DLL 来替代 Aqueue.dll。Phatq.dll 除了包含 Aqueue.dll 中可用的所有功能外，另外还包含 Exchange 特有的功能。Exchange 分类程序在 PhatCat.dll 中实现。PhatCat.dll 是为 OnCategorize 事件类别中的事件注册的。高级排队引擎通过基础分类程序触发这些事件。基础分类程序和 Exchange 分类程序共同通过十个分类程序事件来处理邮件。

注意：
基础分类程序触发驱动邮件分类过程的事件。

高级排队引擎触发下面的十个分类程序事件：

• Register 基础分类程序和 Exchange 分类程序使用此事件来初始化其接口。例如，Exchange 分类程序初始化自己与目录服务访问 (DSAccess)、路由引擎以及存储驱动程序之间的接口。如果其中的任何一个接口失败，那么 Exchange 分类程序都将无法完成自身的初始化。
  由于下列原因，所有分类程序都需要与这些组件的接口：

  1. 要确定收件人是否在 DSAccess 缓存中，必须与 DSAccess 通信。如果收件人在 DSAccess 缓存中，便可以直接从 DSAccess 中获取必要的信息，从而避免了执行 Active Directory 查找的开销。
     Exchange 分类程序还确定 DSAccess 使用的全局编录服务器列表，并将该列表提供给基础分类程序，以供其轻型目录访问协议 (LDAP) 查找使用。默认情况下，基础分类程序使用 Active Directory 域拓扑来确定可用于 LDAP 查找的全局编录服务器。但是，在运行 Exchange Server 2003 的服务器上，分类程序应使用 DSAccess 根据 Active Directory 站点拓扑动态确定的全局编录服务器；或者，如果您在注册表中的 DSAccess 配置文件中对全局编录服务器进行了硬编码，则应使用 DSAccess 静态确定的全局编录服务器。有关 DSAccess 探查过程的详细信息，请参阅 Exchange Server 2003 与 Active Directory。

  2. 必须与路由引擎进行通信，例如，将非 SMTP 一次性地址封装到 SMTP 地址中时，就必须与路由引擎通信。一次性地址是不根据 Active Directory 中的收件人对象进行解析的地址。为确定通往目标的路由路径是否存在，Exchange 分类程序调用路由引擎。如果路由路径不存在，分类程序将生成 NDR。如果路由路径存在，分类程序将用 MailMsg 对象上的封装地址标记一次性收件人。之后，高级排队引擎将地址信息传递给路由引擎，后者再确定收件人的下一跃点。

     注意：
     MailMsg 对象是内存中的结构，它包含邮件传输信封，以及指向 NTFS 存储或 Exchange 存储中的实际邮件的指针。邮件传输信封具有所有邮件头属性以及分类程序处理邮件所需的收件人用户信息。

  3. 与 Exchange 存储驱动程序的通信在分类过程中的某些情况下是必需的。例如，Exchange 分类程序可能必须复制 \Queue 文件夹中的邮件，以便 Exchange 存储能够使用在 Exchange 存储的 Internet 邮件 (IMAIL) 组件中实现的内容转换逻辑来处理和转换 RFC 822 内容。

• BeginMessageCategorization 对于提交到基础分类程序的每个 MailMsg 对象，此事件可以调用一次，它标志邮件分类过程的开始。

• EndMessageCategorization 对于提交到基础分类程序的每个 MailMsg 对象，此事件可以调用一次。它标志邮件分类的结束。

• BuildQuery 对于必须确定的每个收件人和每个发件人，此事件可以调用一次。但是，它不确定基于查询的通讯组成员，因为他们的属性在处理基于查询的通讯组时已决定。对于必须确定的所有收件人，Exchange 分类程序都验证收件人是否驻留在 DSAccess 缓存中。如果是，Exchange 分类程序将返回 ICategorizerItemAttributes 对象，以避开基础分类程序目录服务查找代码，而继续该收件人的 ProcessItem 事件。如果收件人不在 DSAccess 缓存中，基础分类程序的 LDAP 查找代码将为用户创建与 LDAP 兼容的搜索筛选器，该筛选器通常基于 proxyAddresses 属性及输入地址，例如：

  (proxyAddresses=smtp:ted@fabrikam.com)
  

  根据邮件的来源和目标的不同，输入地址可能是 SMTP 地址、X.400 地址或非 Exchange 地址。

  提示：

  若要说明如何使用基于 proxyAddresses 的 LDAP 筛选器来查找 Active Directory 中的特定收件人对象，可以使用 Windows Server 2003 中包含的 LDIFDE 工具 (Ldifde.exe)。使用 LDIFDE 命令行参数“r”可以指定 LDAP 搜索筛选器。例如，可以使用如下命令在 fabrikam.com 域中的 Server01 上的全局编录中查找 Ted：ldifde -f c:\Ted.ldf -s Server01 -t 3268 -d "dc=fabrikam,dc=com" -p subtree -r "(proxyAddresses=smtp:ted@fabrikam.com)"。如果 Ted 具有 SMTP 地址 ，LDIFDE 将在 Active Directory 中找到收件人对象，并将其所有属性写入到一个名为 Ted.ldf 的纯文本文件中。Exchange 分类程序使用完全相同的原理来查找收件人对象，从收件人中检索默认的 SMTP、X.400 和 legacyExchangeDN 属性，并将其设置为 MailMsg 对象上的属性。之后，Exchange 分类程序将在邮件处理过程中使用此信息。

  Exchange 分类程序对几乎所有的地址类型使用 proxyAddresses 属性（旧版 Exchange 可分辨名称和 X.500 可分辨名称除外，因为此地址信息未存储在 proxyAddresses 属性中）。例如，当 Outlook 用户将邮件发送到 Exchange 组织中的另一个用户，或者发送到在 Active Directory 中具有已启用邮件的收件人对象的外部用户时，Outlook 客户端在传出邮件中指定收件人的 legacyExchangeDN 地址，以向后兼容 Exchange Server 5.5。然后，Exchange 分类程序在搜索筛选器中使用 legacyExchangeDN 属性，以便在 Active Directory 中查找收件人对象。
  当解析通讯组的成员时，Exchange 分类程序必须处理 X.500 可分辨名称，因为在列出组成员时会在成员属性中列出其可分辨名称。在这种情况下，Exchange 分类程序解析可分辨名称，以确定收件人的相对可分辨名称 (RDN)，即收件人在 Active Directory 中的公用名 (CN)。然后，Exchange 分类程序在搜索筛选器中使用 cn 属性，并将可分辨名称的余下部分（指向收件人对象在 Active Directory 中的父容器）作为 LDAP 搜索的根，以查找收件人对象。默认情况下，在 Active Directory 中编制 cn 属性的索引，以提高目录查找的效率。

• BuildQueries 对于每个批查找操作，此事件可以调用一次。使用此事件，基础分类程序最多可以针对 20 个收件人在一个查询中组合独立搜索。然后 SendQuery 可以发出一个搜索，该搜索将返回一批收件人。对多个收件人发出一个搜索通常比对多个收件人发出多个搜索更高效，尽管由于在执行批搜索时需要将返回的结果与邮件的各个收件人进行匹配，从而需要更多的处理资源来处理 SortQueryResults 事件。对不超过 20 个人的结果进行匹配比 LDAP 来回多次查询 Active Directory 更高效。下面是与 LDAP 兼容的搜索筛选器的一个示例，该筛选器可以用于一次查找多个用户：

  (|(proxyAddresses=smtp:Ted@fabrikam.com) (proxyAddresses=smtp:Birgit@fabrikam.com))
  

  提示：

  若要了解查询多个用户的 LDAP 筛选器如何工作，可以使用如下命令在 fabrikam.com 域中的 Server01 上的全局编录中查找 Ted 和 Birgit：ldifde -f c:\TedandBirgit.ldf -s Server01 -t 3268 -d "dc=fabrikam,dc=com" -p subtree -r "(|(proxyAddresses=smtp:Ted@fabrikam.com) (proxyAddresses=smtp:Birgit@fabrikam.com))"。如果 Ted 有一个 SMTP 地址 ，Birgit 有一个 SMTP 地址 ，则LDIFDE 将同时在 Active Directory 中查找这两个收件人，并将其各个部分的所有属性写入到一个名为 TedandBirgit.ldf 的文件中。分类程序使用完全相同的原理来查找多个收件人对象。

• SendQuery 分类程序为每个批查找操作触发此事件一次，然后异步执行目录搜索。

• SortQueryResult 分类程序为每个批查找操作调用此事件一次，然后确定哪些用户属于哪个目录对象（为查询返回的 LDAP 结果）。proxyAddresses 属性用于根据 SMTP 地址、X.400 地址或非 Exchange 地址匹配查找所返回的结果。legacyExchangeDN 属性用于匹配 legacyExchangeDN 查找，而 distinguishedName 属性用于匹配 X.500 可分辨名称查找。只有在地址信息唯一地标识每个收件人时，才能用属性来匹配查找结果。如果值不是唯一的，将返回 5.1.4 NDR。下表提供了 5.1.4 NDR 的详细信息。

  代码为 5.1.4 的 NDR 的详细信息

  数值代码	5.1.4
  可能的原因	两个对象具有相同的（代理）地址，并且邮件发送到该地址。
  故障排除	检查收件人地址，然后重新发送邮件。如果收件人在远程服务器上不存在，则也会发生此问题。
  注释	有关 NDR 代码的详细信息，请参阅 Microsoft 知识库文章 284204“Exchange Server 和 Small Business Server 中的传递状态通知”。

• ProcessItem 基础分类程序触发此事件，以便将每个收件人的默认 SMTP、X.400、X.500 和 legacyExchangeDN 地址添加到 MailMsg 对象中。Exchange 分类程序在收件人上设置的地址基于从 Active Directory 中返回的收件人属性。mail 属性包含 SMTP 地址，textEncodedORAddress 属性包含 X.400 地址，distinguishedName 包含 X.500 地址，而 legacyExchangeDN 属性包含旧版的 Exchange 地址。

  注意：
  在此之后，收件人使用的地址与在 Active Directory 中查找收件人使用的地址不一定必须匹配。例如，非 Exchange 用户可能向 Exchange 用户的辅助代理地址发送邮件。在 ProcessItem 事件过程中，Exchange 分类程序用 Exchange 用户的主地址替代辅助代理地址。

  Exchange 分类程序还具有处理联系人和一次性地址的特殊代码。联系人是驻留在 Active Directory 中的非 Exchange 收件人。一次性地址不存在于 Active Directory 中。发件人可能直接在“收件人”行中键入了该收件人地址，或者在 Outlook 中的个人“联系人”文件夹中指定了联系人对象。无论在哪一种情况下，都只有收件人的目标地址是已知的，并添加到 MailMsg 对象中。如果联系人地址或一次性 SMTP 地址与本地 Exchange 组织的地址空间匹配，便会产生冲突，因为联系人或一次性地址必须指代本地 Exchange 组织外部的收件人。
  如果您选中了“此 Exchange 组织负责处理传递到此地址的所有邮件”复选框，则分类程序将针对与收件人策略中指定的地址空间相匹配的地址强制执行其权力。如果用户向不存在于 Active Directory 中、但与权威收件人策略中的地址空间匹配的地址发送邮件，则Exchange 分类程序将在收件人上设置错误状态，该状态之后将引起高级排队引擎生成 5.1.1 未送达报告，以表明地址未知。Exchange 分类程序还认为自己有权处理与本地管理组的站点地址空间匹配的 legacyExchangeDN 地址和 X.400 地址。

  注意：
  如果您在 SMTP 虚拟服务器上配置了备用服务器（“将具有未解析的收件人的所有邮件转发到下列主机”设置），那么，分类程序会将目标地址不在其权威地址空间中的邮件重新路由到备用服务器，而不是为收件人生成 5.1.1 未送达报告。此操作在 CompleteItem 事件过程中执行。

  下表提供了 5.1.1 未送达报告的详细信息。

  代码为 5.1.1 的未送达报告的详细信息

  数值代码	5.1.1
  可能的原因	电子邮件帐户在该邮件的目标组织中不存在。例如，如果 Internet 用户向 发送邮件（其中 fabrikam.com 是您的服务器所管辖的地址空间），但是 Active Directory 没有任何对象具有该地址，那么将生成 5.1.1 NDR。 5.1.1 NDR 是“找不到权威主机”NDR。它分别根据收件人策略、本地管理组的 legacyExchangeDN 属性以及管理组的 X.400 站点地址应用于 SMTP 地址、legacyExchangeDN 收件人以及 X.400 地址。否则，只要您有不可路由且与 Active Directory 中的收件人对象不匹配的非 SMTP 地址，就会生成 5.1.2 NDR。
  故障排除	或者是收件人地址的格式不正确，或者是分类程序无法正确解析收件人。必须检查收件人地址并重新发送邮件才能解决此错误。 有关 NDR 代码的详细信息，请参阅 Microsoft 知识库文章 284204“Exchange Server 和 Small Business Server 中的传递状态通知”。

  对于不在 Active Directory 中、并且与权威收件人策略或本地站点地址空间不匹配的地址，分类程序不注册错误，而是向远程目标注册中继。

• ExpandItem 分类程序触发此事件以处理下列任务：

  • 展开通讯组列表 如果本地服务器是邮件中的通讯组的展开服务器，便可以在本地展开通讯组。msExchExpansionServerName 属性列出了负责展开通讯组列表的 Exchange Server 2003 服务器。如果未设置该属性，那么运行 Exchange 的任何服务器都可以展开该通讯组。如果指定了非本地的服务器，分类程序必须将邮件转发到该服务器，因为已启用邮件的组必须在该特定服务器上展开。通讯组展开后，分类程序分别解析每个收件人。

  • 检查限制 分类程序对每个发件人和每个收件人的所有限制、限额和邮件格式设置进行检查，并相应地标记每个收件人。例如，如果发件人有收件人限额，而邮件超过该限额，那么分类程序将请求高级排队引擎生成 5.5.3，以确保邮件的收件人不超过所允许的最大收件人数。

    代码为 5.5.3 的 NDR 的详细信息

    数值代码	5.5.3
    可能的原因	所发送的邮件中的收件人过多。
    故障排除	收件人限额是可以在接收方服务器上配置的限额。要解决此问题，应增加收件人限额，或者根据服务器的限额相应地将邮件分成多个邮件。
    注释	有关 NDR 代码的详细信息，请参阅 Microsoft 知识库文章 284204“Exchange Server 和 Small Business Server 中的传递状态通知”。

  • 备用收件人：使用 Active Directory 用户和计算机，可以在“Exchange 常规”选项卡中的“传递选项”下为 Exchange 用户指定备用收件人。Exchange 分类程序将此收件人信息添加到 MailMsg 对象中并转发邮件。在 Exchange 组织中传输该邮件时，有一个标志会通过 XEXCH50 在邮件传输信封中随同原始收件人一起传递。这样可防止将多个邮件副本转发给备用收件人。当 Exchange 分类程序发现原始收件人的此标志时，会跳过代码以添加备用收件人。
    Exchange 分类程序还检查是否发生了循环（例如，Ted 转发给 Birgit，而后 Birgit 再转发给 Ted）。如果检测到循环，分类程序将通知高级排队引擎为循环中的第一个用户生成 5.4.6 NDR。

    代码为 5.4.6 的未送达报告的详细信息

    数值代码	5.4.6
    可能的原因	检测到分类程序转发循环。在已启用邮箱的用户上设置了包含权威 SMTP 域中的地址的 targetAddress 属性。targetAddress 属性必须指向远程域。 如果 Active Directory 中存在转发循环，也会生成 5.4.6 NDR。例如，如果一系列 Exchange 用户都具有备用收件人，并且这些备用收件人的相互转发关系中存在循环，便会生成此 NDR。
    故障排除	检查联系人的备用收件人。 检查并删除已启用邮箱的用户的 targetAddress 属性。
    注释	有关 NDR 代码的详细信息，请参阅 Microsoft 知识库文章 284204“Exchange Server 和 Small Business Server 中的传递状态通知”。

  • 邮件分叉 如果收件人要求不同的邮件格式，Exchange 分类程序便会对邮件执行分叉过程，以创建多个邮件副本。邮件分叉将在本节的后面详细说明。

• CompleteItem 当其他所有分类程序事件接收器的工作都已完成时，基础分类程序将调用此事件以执行最终的处理。最终处理包括下列任务：

  • 日志记录 日志记录是将 Exchange 服务器上的用户发送或接收的邮件复制到邮件档案中的过程。对于必须发生日志记录的发件人或收件人，如果当前的服务器是处理该发件人或收件人的第一台服务器（例如，由于对发件人或收件人的本地邮箱存储启用了邮件日志记录），Exchange 分类程序会将邮箱存储的日志记录地址添加到邮件传输信封中，然后再传输该邮件。
    日志记录配置存储在 Active Directory 中，可供组织中的所有 Exchange 服务器使用。例如，Exchange 用户（其主邮箱存储可能已启用了日志记录）可能使用 Internet 客户端并通过 SMTP 将邮件发送到 Exchange 组织中的桥头服务器。然后，桥头服务器将日志记录地址添加到邮件传输信封中，并将邮件的副本转发到该发件人的存档邮箱中。运行 Exchange Server 2003 的服务器使用 XEXCH50 命令来传递邮件传输信封中的信息，其中包括发件人和收件人的日志地址列表。如果在邮件传输过程中涉及到多台 Exchange 服务器，那么只要服务器在邮件传输信封中找到了日志记录地址，便不会再次添加日志记录地址，从而避免了邮件档案中有重复的邮件。

    注意：
    对于密送收件人、传输转发规则中的收件人或者通讯组展开中的收件人而言，邮件日志可能不可靠。如果除了邮件数据外，还必须记录邮件传输信封数据，则必须启用“信封日志记录”。使用 E-Mail Journaling Advanced Configuration（电子邮件日志记录高级配置）工具可以启用“信封日志记录”。可以在 Exchange Server Email Journaling Advanced Configuration 网站下载此工具。

  • 转发未解析的收件人 如果已对 SMTP 虚拟服务器进行了配置，通过该服务器可将具有未解析的收件人的所有邮件转发到备用主机，那么，Exchange 分类程序会将所有未解析的收件人的目标服务器设置为备用服务器的完全限定域名 (FQDN)。

  • 收件人标记 Exchange 分类程序通过在邮件上设置每个收件人的属性来标记每个收件人。此属性指示每个收件人的目标服务器。此属性的典型格式为收件人主服务器的 FQDN。高级排队引擎根据分类程序在每个收件人上设置的 FQDN，决定在本地传递邮件还是调用路由引擎。与本地服务器的 FQDN 匹配的所有邮件都直接从路由前队列进入本地传递队列，而不必执行邮件路由。对于非本地的收件人，高级排队引擎必须稍后调用路由引擎，以确定邮件传输中的下一跃点。

    注意：
    Exchange 分类程序通过一个名为 MDAccess 的组件来确定每个收件人主服务器的 FQDN。MDAccess 使用 Active Directory 中的配置信息来确定驻留收件人邮箱存储的服务器的网络地址。如果收件人的邮箱驻留在本地 Exchange 服务器上，Exchange 分类程序便会将收件人的 homeMDB 特性设置为邮件传输信封中的一个收件人属性。Exchange 存储驱动程序稍后使用此信息来确定应将收件人的邮件传递到哪个邮箱存储。

  • 重定向传递状态通知 当用户代表通讯组发送邮件（也就是，在“发件人”中指定通讯组）并要求返回已送达回执或已读回执时，所生成的传递状态通知会发送给通讯组，而不是只发送给该发件人。为解决此问题，分类程序将邮件传输信封中的发件人地址更改为实际发件人的地址，从而将状态通知定向到实际的发件人。
    用户很少代表通讯组发送邮件。一种更为常见的情形是，用户在向一个大型的通讯组发送邮件后，会收到多个外出通知、自动答复和传递状态通知（如未送达报告）。为缓解此问题，Exchange 分类程序在向通讯组发送邮件时默认禁用外出通知和自动答复。为此，Exchange 分类程序在邮件信封中为收件人添加一个属性。Exchange 存储在本地传递过程中将该属性用作参数，以禁用生成外出通知和自动答复的规则。如果各个通讯组成员驻留在不同的邮箱服务器上，则使用 XEXCH50 在运行 Exchange Server 2003 的服务器之间传输邮件信封的这一扩展属性。
    Exchange 分类程序按照下表列出的条件，重定向或删除外出通知、自动答复和传递状态通知。

    传递状态通知的重定向和删除条件

    条件	操作
    通讯组具有所有者，并且传递报告被配置为发送给该所有者	如果将邮件传递给通讯组或其中的某个成员时出错，则重定向未送达报告，以通知所配置的通讯组所有者。分类程序为通讯组成员重定向所有未送达报告，这些报告通常是返回给邮件发件人的。 默认情况下，只有 NDR 重定向给通讯组所有者。如果发件人请求明确的状态通知（例如，已送达回执通知），将使用 SMTP 协议传递状态通知扩展来生成报告。在发送给启用报告重定向的通讯组的邮件中，如果发件人请求传递状态通知，那么，当通讯组成功展开或重定向到其展开服务器（如果本地服务器不是通讯组的展开服务器）时，发件人会收到传递状态通知。
    传递报告被配置为发送给邮件原始发件人	将传递状态通知发送给邮件的发件人。如果没有在“Exchange 高级”选项卡中为通讯组选中“向原始发件人发送‘外出’邮件”复选框，分类程序将禁用外出通知和自动答复。默认情况下，此复选框处于未选中状态。
    通讯组被配置为禁用组成员传递报告，以避免泄露成员信息	禁用所有外出通知、自动答复以及所有类型的传递状态通知（如传递通知和已读回执）。这与重定向 NDR 类似，不同之处在于分类程序禁用所有类型的传递通知，其中包括各个组成员的未送达报告。为了禁用所有传递报告，分类程序将邮件传输信封中的发件人地址更改为“<>”。 如果发件人在发送给通讯组的邮件中请求传递状态通知（如已送达回执通知），那么，当通讯组成功展开或重定向到其展开服务器（如果本地服务器不是通讯组的展开服务器）时，SMTP 协议传递状态通知扩展会生成传递状态通知。

    注意：
    默认情况下，当用户向通讯组列表发送邮件时，分类程序禁用外出通知、自动答复和传递状态通知。在通讯组属性中的“Exchange 高级”选项卡上选中“向原始发件人发送‘外出’邮件”复选框，可以对此进行配置。有关详细信息，请参阅 Microsoft 知识库文章 325469 Exchange Server 2003 或 Exchange 2000 Server 中的通讯组自动答复不能正常运行。

  • 状态代码映射 Exchange 分类程序还映射状态代码，这些状态代码是以前的分类程序接收器通过电子邮件返回给收件人的。之后，错误代码将引起高级排队引擎为受影响的收件人生成 NDR。

邮件分叉

前面已提到，分类程序可能在分类过程中创建邮件的多个副本。此过程称为分叉。任何时候，只要不同收件人必须收到同一邮件的不同副本，就会执行此过程。在下列情况下需要执行分叉：

• 内容转换 任何时候，只要 Exchange 用户向非 MAPI 用户发送 MAPI 格式的邮件，就必须执行内容转换。例如，Outlook 用户可能向 Internet 上的收件人发送邮件，在这种情况下，分类程序必须执行从 MAPI 到 Internet 邮件格式的内容转换。当必须在混合模式的 Exchange 组织中通过基于 SMTP 的路由组连接器传输 MAPI 邮件时，也必须进行内容转换。由于分类程序无法更改现有邮件的内容，因此分叉对于内容转换是必需的。本节后面提供了有关内容转换的详细信息。
• 在每个收件人的基础上删除已送达回执请求和已读回执请求 当具有已读回执请求的邮件发送到具有隐藏成员信息的通讯组以及“收件人”行中的另外一个单独的收件人时，这是必要的。由于组成员必须保持机密，因此当通讯组成员收到邮件时，不得生成已读回执。否则，发件人便能够根据所收到的已读回执识别组成员。为了避免这种情况，将创建邮件的两个副本，一个用于具有隐藏成员的通讯组，另一个用于单独的收件人。已读回执请求将从发送到通讯组的邮件中删除。
• 具有多个收件人的传递状态通知 当 Exchange 分类程序检测到传递状态通知具有多个收件人时，将为每个收件人准备一个邮件副本，因为 Exchange MTA（为了符合 X.400 标准）不支持一个通知对应多个收件人。由于分类程序无法确定在邮件传输过程中是否涉及到 MTA（只有路由引擎能够确定这一点），因此分类程序必须为每个独立的收件人分别创建一个传递状态通知。

当邮件由客户端提交时，分叉发生在运行 Exchange Server 的服务器上。使用性能工具可以检查分类程序创建的新邮件数。下图显示了相关的性能计数器。

内容转换

MAPI 客户端（如 Outlook）的用户能够在每个邮件或每个收件人的基础上指定采用 RTF 格式、HTML 格式还是纯文本格式发送邮件。分类程序必须相应地转换邮件。管理员还可以在 Active Directory 中已启用邮件的收件人的属性中指定首选格式，或者在地址空间的基础上指定 Internet 邮件格式（例如，在 Exchange 系统管理器中的“全局设置”下为每个 Internet 域指定）。这样，发送到 Internet 域中的用户的邮件便可以采用 RTF、多用途 Internet 邮件扩展 (MIME) 或 Unix-to-Unix 编码 (UUEncoded) 等格式。分类程序使用特定的逻辑来接合各个收件人的不同格式设置。当分类程序解析邮件收件人时，可能会发现必须对一部分收件人或个别的收件人采用不同的邮件格式。之后，分类程序必须通过分叉过程使每个收件人的邮件都具有正确的邮件格式，如 RTF、HTML 或纯文本。

如果邮件是通过 SMTP 传输的，那么内容转换对于发送给本地 Exchange 组织内部的 Exchange 收件人的 MAPI 邮件也是必需的。本地路由组中的 Exchange Server 2003 服务器始终通过 SMTP 相互通信。如果部署了“路由组连接器”或 SMTP 连接器，不同路由组中的 Exchange Server 2003 服务器也通过 SMTP 通信。为了支持 SMTP，必须将 MAPI 格式转换为 RFC 822 格式才能够传输邮件。

注意：
内容转换在用户提交邮件的服务器上完成。这样，邮件便能够通过 SMTP 从一台服务器传输到另一台服务器，而不需要进一步的转换。内容转换仅仅针对 MAPI 邮件执行。

IMAIL

Exchange Server 2003 中的邮件转换过程称为 IMAIL。IMAIL 是 Exchange 存储的内部组件。Exchange 分类程序并不执行实际的邮件转换。Exchange 分类程序仅仅使用 Exchange 存储驱动程序创建邮件的副本，并在每个副本的邮件传输信封中设置某些属性。然后，存储驱动程序将这些属性设置用作参数，以指定向 Exchange 存储请求 RFC 822 内容时请求哪一种格式。Exchange 存储使用 IMAIL 以及所请求的格式参数将 MAPI 邮件转换为 RFC 822 格式。在生成邮件的 RFC 822 内容时，IMAIL 仅仅产生 MAPI 邮件的一种生成方式。Exchange 存储中的实际邮件并未发生改变。至于所生成的 RFC 822 内容的更改，它们并不与生成 RFC 822 内容的 MAPI 邮件进行动态的重新关联。

TNEF

Exchange Server 2003 使用传输不确定封装格式 (TNEF) 将 MAPI 邮件转换为 RFC 822 格式。TNEF 以 application/ms-tnef 类型的 MIME 附件的形式出现在邮件中。该附件的名称为 Winmail.dat。它包含完整的邮件内容以及所有附加文件。只有 MAPI 客户端（如 Outlook）能够对 Winmail.dat 附件进行解码。非 MAPI 客户端无法对 TNEF 进行解码，并且可能将 Winmail.dat 显示为典型但无用的文件。

注意：
在 Exchange 服务器上拥有邮箱的收件人（他们使用 Internet 客户端访问邮件）不会被视为非 MAPI 收件人。这是因为当用户使用 POP3 或 IMAP4 客户端从其收件箱中下载 MAPI 邮件时，驻留邮箱的 Exchange 存储能够产生必要的非 MAPI 格式的 RFC 822 内容。

在以下几种可能的 Exchange 对 Exchange 传输情形下，必须进行 MAPI 到 RFC 822 的转换：

• 收件人在同一路由组中的 Exchange 服务器上 Exchange Server 2003 将 MAPI 邮件转换为 Summary-TNEF (S/TNEF) 格式，这是一种特殊的传输不确定封装格式 (TNEF)，没有纯文本部分，并且以八位的二进制格式传送。S/TNEF 邮件仅仅包含 Winmail.dat。

  注意：
  在路由组内部，Exchange Server 2003 始终采用 S/TNEF，因为它在所有远程传递情况下，都保证邮件采用 SMTP 跃点直接到达运行 Exchange 2000 Server 或 Exchange Server 2003 的服务器，或者到达 Exchange MTA。Exchange 2000 Server 和 Exchange Server 2003 都支持二进制 MIME。另一方面，如果邮件传递给 Exchange MTA 以便通过 RPC 传递到运行 Exchange Server 5.5 的服务器，则不需要进行邮件转换，因为这种情况下不使用 RFC 822 格式。

• 收件人在另一个路由组中的 Exchange 服务器上，并且 Exchange 组织在纯模式下工作 Exchange Server 2003 将 MAPI 邮件转换为 Summary-TNEF (S/TNEF) 格式，因为纯模式下的 Exchange 组织只能包含支持二进制 MIME 的 Exchange 2000 Server 服务器和 Exchange Server 2003 服务器。

• 收件人在另一个路由组中的 Exchange 服务器上，并且 Exchange 组织在混合模式下工作 在混合模式下，有可能将 Exchange Server 5.5 的 Internet 邮件服务用作 SMTP 连接器，但是 Internet 邮件服务不支持二进制 MIME。由于 S/TNEF 的 RFC 822 表示（由 IMAIL 产生）是二进制 MIME，因此 Internet 邮件服务无法传输 S/TNEF 邮件。由于 Exchange 分类程序无法预先检测到邮件将采用什么路由路径，因此在混合模式下，分类程序不为本地路由组外部的服务器上的收件人进行邮件转换，也就是不将邮件转换为 S/TNEF。为了在传输路径中容纳可能的 Internet 邮件服务实例，Exchange 分类程序将邮件转换为纯文本部分以及旧版 TNEF 格式附件。旧版 TNEF 格式是 Internet 邮件服务能够传输的七位 MIME。

• 收件人是本地 Exchange 组织之外的 MAPI 收件人 *   *用户和管理员可以为外部邮件环境中使用 Outlook 的收件人启用跨本地 Exchange 组织边界的 TNEF 传输。由于收件人不在本地 Exchange 组织中，Exchange 分类程序无法确定邮件传输中涉及到的所有 SMTP 主机是否都支持二进制 MIME。因此，Exchange 分类程序将邮件转换为纯文本部分以及旧版 TNEF 格式的附件。

  注意：
  非 MAPI 收件人通常首先选择接收无 TNEF 的纯文本或 HTML，因为他们的客户端无法对包含邮件和所有附件的 Winmail.dat 文件进行解码。TNEF 封装使得非 MAPI 客户端无法访问附件。非 Microsoft 工具（如 EPOC WMDecode for Windows）可能能够从 Winmail.dat 文件中提取附件。

• 发送到公用文件夹中的 MAPI 邮件 发送到公用文件夹中的邮件始终以旧版 TNEF 格式中继。本节后面提供了有关公用文件夹邮件处理的详细信息。

• 通过 SMTP 发送到展开服务器的 MAPI 邮件 如果邮件包含通讯组列表，并且明确指定的展开服务器不是本地服务器，邮件将以旧版 TNEF 格式转发到展开服务器（如果使用 SMTP 传输邮件）。在这种情况下，会将一个属性放入邮件传输信封中通过 XEXCH50 传输。该属性通知展开服务器最初通过 Exchange 存储驱动程序收到邮件的时间。展开服务器上的分类程序展开通讯组列表后，必须分别对每个收件人应用有效的 RFC 822 邮件格式。分类程序使用 Exchange 存储驱动程序将邮件复制到 Exchange 存储中，IMAIL 再从 Exchange 存储中读取 TNEF 数据并用原始邮件的提交时间构建 MAPI 邮件。之后，SMTP 传输子系统便能够从存储中读取符合收件人格式要求的 RFC 822 格式 MAPI 邮件。

通过添加以下注册表项，可以控制发送邮件的 TNEF 格式行为。数字 nn 表示此计算机的虚拟服务器实例。

公用文件夹邮件处理

可以对公用文件夹启用邮件功能，这样用户便能够向其中发送邮件。但是，它与启用邮箱的用户帐户不同：用户帐户只能在组织中的指定的一个 Exchange 服务器上拥有自己的邮箱，而公用文件夹能够在多个服务器之间复制，而且，如果其他服务器中的公用文件夹存储与公用文件夹顶级层次结构相关联，那么，这样的服务器中可能没有公用文件夹。因此，很难确定发送到公用文件夹的邮件的传递位置。

要执行邮件传递，Exchange 分类程序必须将邮件传递到能确定公用文件夹副本驻留位置的公用文件夹存储中。此信息包含在 Exchange 存储的 PTagReplicaList 属性中。只有当 Exchange 存储的公用文件夹存储与公用文件夹顶级层次结构相关联时，Exchange 存储才具有此 PTagReplicaList 信息。

为了找到与公用文件夹的顶级层次结构关联的公用文件夹存储，Exchange 分类程序读取公用文件夹的 homeMDB 属性。homeMDB 属性包含顶级层次结构对象在 Active Directory 中的可分辨名称 (DN)。该对象的 msExchOwningPFTreeBL 属性列出与顶级层次结构关联的公用文件夹存储。然后，Exchange 分类程序从该列表中选择一个公用文件夹存储，并将邮件定向到该公用文件夹存储。公用文件夹存储确定该文件夹的 PTagReplicaList 条目，将邮件的目标地址改为存放公用文件夹副本的公用文件夹存储，然后重新提交邮件。邮件再次经过高级排队引擎（包括分类过程）的处理。当 Exchange 分类程序在公用文件夹存储中找到已更新的文件夹位置时，将已更新的文件夹位置设置为邮件的目标，然后重新路由邮件。

在为邮件选择公用文件夹存储时，Exchange 分类程序遵循下列优先级顺序（从上到下）：

1. 运行 Exchange Server 的本地服务器上的公用文件夹存储具有最高的优先级
2. 本地路由组中的公用文件夹存储
3. 本地管理组中的公用文件夹存储
4. 本地 Exchange 组织中的公用文件夹存储
5. 运行 Exchange Server 5.5 的服务器上的公用文件夹存储

注意：
如果本地路由组中存在多个公用文件夹存储，Exchange 分类程序将选择列表中的第一个存储。

分类程序性能优化

本主题前面的“Exchange 分类程序”一节已提到，Exchange 分类程序通过 DSAccess 确定可用于 LDAP 查找的全局编录服务器列表。DSAccess 根据 Active Directory 站点拓扑动态确定此列表，或者，如果您在注册表中的 DSAccess 配置文件夹中对全局编录服务器进行了硬编码，则 DSAccess 将静态确定此列表。这一点已在 Exchange Server 2003 与 Active Directory 中进行了说明。

默认情况下，DSAccess 动态确定全局编录服务器列表，这样，当全局编录服务器由于任何原因而变得不可用时，便可以将其从该列表中排除出去。不可用的全局编录服务器的连接重试期限为五分钟。默认情况下，DSAccess 至少每 15 分钟重新计算此列表一次。Exchange 分类程序每小时调用 DSAccess 一次，以更新全局编录服务器列表。

当每个全局编录服务器的连接失败次数超过 100 时，Exchange 分类程序也更新全局编录服务器列表。全局编录服务器可能由于维护或其他原因而关闭，或者由于网络通信问题而导致 LDAP 连接失败。可以使用以下注册表参数来指定超时值，超过此时间后，分类程序将 LDAP 连接归为不工作。

警告：
错误地使用注册表编辑器可能导致严重的问题，甚至可能需要重新安装操作系统。Microsoft 无法保证错误使用注册表编辑器所导致的问题可以得到解决。请自行承担使用注册表编辑器的风险。

如果由于超过了 MaxConnectionRetries 而导致分类失败，分类程序会将受影响的邮件重新放入分类前队列中，并通知高级排队引擎分类可能在稍后的尝试中成功。默认情况下，高级排队引擎将在一小时后重试分类。可以使用以下注册表参数来调整此时间期限。

全局编录负载平衡

如果运行 Exchange Server 2003 的服务器可以使用多个全局编录服务器，Exchange 分类程序可以在所有这些全局编录之间平衡 LDAP 搜索负载。默认情况下，当一个全局编录服务器上正在等待的 LDAP 搜索超过 16 个时，Exchange 分类程序便会开始平衡 LDAP 搜索负载。Exchange 分类程序根据开销值选择全局编录服务器。开销值是根据下列特征来确定的：

• 现有的 LDAP 连接数 Exchange 分类程序首选现有的 LDAP 连接，只有在现有的 LDAP 连接不可用时，才选择新连接，因为与建立到全局编录服务器的新连接相比，使用已建立的连接更为高效。建立连接会产生处理开销。
  默认情况下，基础分类程序在执行目录查找时，在每个全局编录服务器上最多可以打开八个（取决于工作负荷）并发 LDAP 连接。使用以下注册表项可以调整连接数。

  位置	HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSVC\Parameters
  值	MaxLdapConnections
  类型	REG_DWORD
  数值数据	0x8
  描述	这是 SMTP 服务中的组件最多可以打开的全局编录服务器的 LDAP 连接数。默认为八个连接。 注意： 该值分别应用于执行 LDAP 查找的分类程序中的每个进程：一个进程在分类过程中解析所提交的邮件中的收件人，另一个进程检查每个收件人的邮件限制。其中，每个进程都可以有八个连接，因此与全局编录服务器的最大总连接数是 16。

  • 现有 LDAP 连接的状态 Exchange 分类程序首选没有正在等待的搜索的可用 LDAP 连接。

  • 相对于 Exchange 服务器的位置 Exchange 分类程序首选本地 Active Directory 站点中的全局编录服务器，只有在没有本地的全局编录服务器时，才选择远程站点中的全局编录服务器。本地站点中的 TCP/IP 连接被认为快速而可靠。

  • 正在等待的 LDAP 查询数 分类程序首选空闲连接，只有在没有空闲连接时，才选择有正在等待的查询的连接。如果所有连接都有正在等待的查询，Exchange 分类程序将选择正在等待的查询数最少的连接。

  Exchange 分类程序选择开销最低的全局编录服务器。如果有多个全局编录服务器的开销值相同，分类程序将按轮循机制在所有可用的 LDAP 连接之间执行负载平衡。Exchange 分类程序按照如下过程选择连接：

  1. Exchange 分类程序依次检查现有 LDAP 连接列表中的每一个连接，并自动选择没有正在等待的搜索的第一个连接。
  2. 如果 LDAP 连接不存在或者不可用，Exchange 分类程序将建立与全局编录服务器的新连接。

  LDAP 搜索批操作

  Exchange 分类程序可以执行异步查找，并可以分批进行，在一个批操作中最多可以搜索 20 个收件人。使用 LDAP OR 筛选器对多个收件人对象执行一次 Active Directory 查找有助于改善性能，尽管将结果与邮件中的收件人进行匹配需要额外的处理资源。对于可以组织到全局编录的一个查询中的各个收件人对象而言，LDAP 批搜索能够很好地工作。大多数 Exchange 分类程序操作都属于这一类，但也有例外。

  在下列情况下，分类程序使用单次查询：

  • 分类程序必须展开动态的通讯组。
  • 分类程序必须请求分页属性。例如，当通讯组的成员超过 1,000 时。

  注意：
  Exchange 分类程序向 DSAccess 进行核实，以确定收件人对象是否在 DSAccess 缓存中。对于已缓存的对象，将不会执行目录查找。

  可以使用以下注册表项来管理 Exchange 分类程序的性能。例如，可以增加一次批搜索最多可以搜索的收件人数。但是，大幅度地增大该数字可能对性能产生实际负面影响，因为将结果与收件人进行匹配的开销也增加了。通常，默认值对于大多数情况已足够。因此，建议在没有 Microsoft 产品支持专家帮助的情况下，不要更改这些值。

  位置	HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSVC\Parameters
  值	MaxSearchBlockSize
  类型	REG_DWORD
  数值数据	0x14
  描述	这是“批限制”，也就是可以作为一个 LDAP 搜索同时提交的分类程序搜索的最大数目。默认为 0x14（十六进制）或 20（十进制）个分类程序搜索。

  位置	HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSVC\Parameters
  值	MaxPendingSearches
  类型	REG_DWORD
  数值数据	0x3C
  描述	这是分批前每个 LDAP 连接上正在等待的搜索的最大数目。默认为 0x3C（十六进制）或 60（十进制）个正在等待的搜索。

  邮件重分类

  邮件仅仅分类一次。对于文件系统上的 \Queue 文件夹中的邮件，分类程序使用备用数据流（一个很少有人知道的 NTFS 功能）来持久保存包含邮件信封和分类信息的 MailMsg 属性流。备用数据流通过隐藏文件（链接到 NTFS 分区中的可视文件）来实现数据存储。当 SMTP 服务无法立即传输邮件并且必须在稍后重试时，会保存并关闭邮件。此操作的一部分涉及到保存现有的 MailMsg 属性流，这样便能够在重试邮件传输时重新加载并使用该属性流。但是，如果必须再次对邮件进行分类（例如，如果该邮件在排队，并等待被传递到一个不再存在的目标服务器），您将注意到该分类只执行一次。

  高级排队引擎将邮件作为 .eml 文件存储在 SMTP 虚拟服务器的 \Queue 目录中，或者作为 Exchange 可安装文件系统 (ExIFS) 文件存储在 Exchange 存储中。对于 .eml 文件，分类程序在分类过程中使用两个 NTFS 备用数据流 PROPERTIES 和 PROPERTIES-LIVE 来持久保存 MailMsg 对象的属性以及分类信息。PROPERTIES 数据流提供原始邮件的副本。PROPERTIES-LIVE 数据流提供当前邮件的副本。当 SMTP 服务将邮件移入 \Badmail 文件夹后，备用数据流会被删除。在这种情况下，邮件使用 .bad 文件扩展名保存，而属性流则保存在另一个文件名匹配、但扩展名为 .bdp 的文件中。

  注意：
  保存属性流的方式取决于所使用的存储驱动程序。NTFS 存储驱动程序使用备用数据流来保存属性流。为了保存属性流，Exchange 存储驱动程序将数据复制到邮件的特殊二进制 MAPI 属性中（如果属性流很小），或者复制到单独的 ExIFS 文件中（如果属性流很大）。在后一种情况下，指向 ExIFS 文件的链接保存在二进制 MAPI 属性中。

  \Queue 目录中的备用数据流

  可以使用记事本来查看 SMTP 虚拟服务器 \Queue 目录中的 .eml 文件的备用数据流。例如，以下命令显示了文件名为 NTFS_0ec25fe701c4120a00000001.EML 的测试邮件的分类信息：**notepad C:\NTFS_0ec25fe701c4120a00000001.EML:PROPERTIES-LIVE.**请注意，末尾的句点是命令的一部分。如果遗漏，记事本将在 PROPERTIES-LIVE 的末尾追加 .txt 文件扩展名，但 PROPERTIES-LIVE.txt 不是备用数据流的名称。文件名的第一部分指向备用数据流的父文件。第二部分是实际的流名称。

  下图显示了父文件的内容示例（左侧），并同时显示了备用数据流中的 MailMsg 属性信息（右侧）。请注意上面窗口中的 PROPERTIES-LIVE 数据流包含从 Active Directory 中获取的详细发件人和收件人信息。

  

  注意：
  如果将具有备用数据流的 NTFS 文件移入文件分配表 (FAT) 分区中，备用数据流将丢失，因为 FAT 不支持此功能。丢失的内容包括分类信息和邮件传输信封。之后，如果将该文件移入分拣目录中，则除非指定了 x-sender 头和 x-receiver 头，否则将使用 P2 (RFC 822) 收件人列表来传递邮件。此列表可能不同于最初用来发送邮件的 P1 (RFC 821) 收件人列表，因此，有些收件人可能收到该邮件两次，密送收件人可能根本不会收到邮件，而非指定的收件人可能会收到邮件的副本。之所以会出现这样的结果是因为原始 P1 收件人列表与 MailMsg 属性流丢失，从而使 SMTP 服务除了 P2 收件人列表外没有其他信息。但是，P2 收件人列表并不是用来维护以传输与传递为目的的收件人列表的。

  强制重分类

  前面的讨论说明了，不应将文件移入 FAT 分区中，因为这会使 MailMsg 属性流丢失，从而强制传输子系统重新对邮件进行分类。

  在下列情况下，可能必须对邮件强制执行重新分类：

  • 元数据库损坏 如果 Internet 信息服务 (IIS) 元数据库损坏或者被非 Exchange 版本所取代，那么可能由错误的分类程序版本对邮件进行分类。要使用 Exchange 分类程序对邮件进行分类（可能是在重新安装 Exchange Server 2003 后），必须重新对邮件进行分类。
  • 采用了错误的展开服务器 如果更改了通讯组列表的展开服务器，那么，直至通讯组列表更改被复制到整个 Active Directory 中之前，邮件对象都可能会标记上错误的通讯组列表展开服务器。如果这种情况发生，邮件将被发送到错误的展开服务器。例如，如果已从网络中撤消了展开服务器，而且此时邮件已在本地服务器上分类，那么必须重新对邮件进行分类，这样才能使邮件发送到正确的展开服务器。
  • 采用了错误的后端服务器 如果在组织中的另一台 Exchange 服务器（而不是最初的 Exchange 服务器）上还原邮箱，也可能会导致分类问题。例如，如果邮箱服务器的硬件出现故障，您可能决定在另一台服务器上还原邮箱。这样，运行 Exchange Server 的其他服务器（如前端服务器）上的队列中的任何现有邮件可能都不会传递，因为高级排队引擎尝试将邮件传递到不存在的服务器。除非重新对邮件进行分类，否则前一个服务器的 FQDN 会包含在邮件传输信封中。

  在上述情况下，必须重新对邮件进行分类。但是，服务器重新启动不影响备用数据流。因此，重新启动运行 Exchange Server 的服务器不会导致邮件重新分类。要触发重新分类而不将文件移入 FAT 分区，必须使用以下注册表项来重置邮件状态：

  警告：
  错误地使用注册表编辑器可能导致严重的问题，甚至可能需要重新安装操作系统。Microsoft 无法保证错误使用注册表编辑器所导致的问题可以得到解决。请自行承担使用注册表编辑器的风险。

  位置	HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSVC\Queuing\
  值	ResetMessageStatus
  类型	REG_DWORD
  数值数据	0x1
  描述	此参数强制对枚举的所有邮件重新进行分类。如果此参数不存在，则默认为不重新分类 (0x0)。 要使更改生效，必须停止并重新启动 SMTP 服务。SMTP 服务重新启动后，分类程序会枚举并重新处理所有先前已排队的邮件。在邮件离开 \Queue 文件夹后，再删除 ResetMessageStatus 项。然后可以重新启动 SMTP 服务以恢复正常的运行。