产生未送达报告的常见情形

  • 项目

 

上一次修改主题： 2005-05-24

本主题讲述了可能导致产生 NDR 的下列常见情形：

  • Active Directory 问题。
  • 由于全局编录服务器出现问题而导致邮件传递延迟。
  • 将邮件发送到个人通讯簿或联系人列表中的收件人。
  • 将邮件发送到公用文件夹。

Active Directory 问题

Active Directory 问题可能导致产生未送达报告。以下类别的 NDR 与 Active Directory 问题有关：

  • 通过使用 Active Directory 连接器 (ADC) 将收件人移到 Active Directory。
  • 通过使用移动邮箱工具将收件人移到 Active Directory。
  • 缺少属性。

通过使用 Active Directory 连接器将收件人移到 Active Directory

如果在使用 Active Directory 连接器移动了收件人之后某些用户遇到了 NDR 问题，则应确定下列问题：

  • 哪些类型的收件人产生了 NDR（如邮箱、通讯组或联系人）？
  • 收件人是如何移动到 Active Directory 中的？如果收件人是通过 ADC 复制到 Active Directory 中的，应使用 ADCDump 工具来获取 ADC 转储文件，然后比较遇到问题的收件人在两个目录中同时存在的属性。ADC 转储文件显示出 Exchange 2003 对象与 Exchange Server 5.5 对象之间所存在的属性不匹配问题。要获取 ADCDump 工具，请与 Microsoft 产品支持服务联系。

如果用户是通过使用 ADC 移动的，则该用户必须存在于 Active Directory 中（至少作为被禁用的用户）。将用户作为联系人（自定义收件人）从 Exchange  5.5 目录复制到 Active Directory 会导致 NDR。如果 Exchange 5.5 和 Microsoft Windows NT® Server 4.0 收件人是作为联系人复制到 Active Directory 中的，则 Exchange 2003 不再将电子邮件发送到在 Active Directory 中表示为联系人的 Windows NT Server 4.0 收件人。在这种情况下，将返回下列 NDR：

A configuration error in the e-mail system caused the message to bounce between two servers or to be forwarded between two recipients. Contact your administrator. <servername.contoso.com #5.4.6>

有关其他信息，请参阅 Microsoft 知识库中编号为 272593 的文章：“XCON: Message Generates NDR When Sent to a Windows NT Server 4.0 Recipient Represented as Contact in Active Directory”。虽然该文章是针对 Exchange 2000 撰写的，但其中的基本要素也适用于 Exchange 2003。

这一情况不适用于在 Exchange 2003 中创建的联系人；只有通过 ADC 并作为联系人复制到 Active Directory 中的 Windows NT Server 4.0 用户才会遇到这种情况。邮件可以可靠地发送到本地的 Exchange 2003 联系人。

note注意：
如果被禁用的用户在 Active Directory 中未显示，并且您收到了 8277 MSADC 错误消息，则应将连接协议的复制服务器更改为用户要复制到其中的 Exchange 2003 站点或域中的桥头服务器。此外，为了在 Exchange 2003 服务器与 Exchange 5.5 计算机之间实现完整的互操作性，应确保 ADC 复制设置为双向的。

通过使用移动邮箱工具将收件人移到 Active Directory

如果收件人、通讯组或用户是作为本地 Exchange 2003 对象而存在的，或者是通过使用移动邮箱工具而从 Exchange 5.5 中移出的，则应确保存在所有已启用邮件属性。下列步骤很有用：

  • 确定发件人所在的 Exchange 服务器（从物理角度讲）。如果收件人是通讯组，应找到通讯组展开服务器。
  • 确定发件人的 Exchange 服务器或通讯组展开服务器与之联系以进行名称解析的全局编录服务器。（有关详细步骤，请参阅此部分后面所讲述的过程。）
  • 运行 Nltest 工具（在 Windows 2000 和 Windows Server 2003 中提供），以确定发件人的服务器或通讯组展开服务器正在与哪一台全局编录服务器联系。确保从发件人的 Exchange 服务器或通讯组展开服务器运行 Nltest。如果通讯组展开服务器被设置为组织中的任意服务器，则应从发送方服务器运行 Nltest。

有关详细说明，请参阅如何确定通讯组的展开服务器。

在知道了正在使用的是哪一台全局编录服务器之后，获取收件人用户通讯组的转储文件。有关如何获取转储文件的其他信息，请参阅下列 Microsoft 知识库文章：

还可以使用 LDP 工具来获取收件人对象的 LDP 转储文件。如果使用 LDP 工具，应确保在连接到全局编录服务器时使用 3268 端口。这是邮件分类程序用来查询全局编录服务器（以解析名称）的端口。

note注意：
如果结果被 LDP 工具截断，可以从 NDR 获取对象的基准可分辨名称信息（使用知识库中编号为 271201 的文章中所讨论的过程时必须使用该名称）。每个 NDR 都包含无法传递的对象的基准可分辨名称信息。如果 NDR 的格式或收件人对象的基准可分辨名称信息可疑，可以发送具有所请求的传递回执的新测试邮件。应由可以成功地向遇到问题的收件人发送邮件的用户来向该收件人发送此测试邮件。

缺少属性

对象缺少属性的原因有多种，既可能是由于属性被手动删除，也可能是由于全局编录同步问题。但是，无论缺少的是哪个属性，最可能的原因是收件人更新服务未正确写入这些属性，或者是 ADC 复制出现问题。

有关详细信息，请参阅如何纠正丢失属性问题。

由于全局编录服务器问题而导致邮件传递出现延迟

全局编录问题可能导致邮件传递出现延迟。在这种情况下，会生成 NDR 以通知发件人这一延迟。可以使用邮件跟踪中心来诊断这些问题。下面的示例显示了从邮件跟踪中心所收集到的数据：

6/22/2001 3:54 PM Tracked message history on server CONTOSO-MSG-01

6/22/2001 3:54 PM SMTP Store Driver: Message Submitted from Store

6/22/2001 3:54 PM SMTP: Message Submitted to Advanced Queuing

6/22/2001 3:54 PM SMTP: Started Message Submission to Advanced Queue

6/22/2001 3:54 PM SMTP: Message Submitted to Categorizer

6/22/2001 4:24 PM SMTP: Started Outbound Transfer of Message

6/22/2001 4:24 PM Message transferred out to FOURTHCOFFEE.COM through SMTP

6/22/2001 4:24 PM SMTP: Message Submitted to Advanced Queuing

6/22/2001 4:24 PM SMTP: Started Message Submission to Advanced Queue

6/22/2001 4:24 PM SMTP: Message Submitted to Categorizer

6/22/2001 4:24 PM SMTP: Started Outbound Transfer of Message

6/22/2001 4:24 PM Message transferred out to FOURTHCOFFEE.COM through SMTP

6/22/2001 4:24 PM SMTP Store Driver: Message Delivered Locally to Store

在上面的示例中，应注意到邮件在邮件分类程序中延迟了 30 分钟，之后才开始进行出站传输，并且最终被送达。在这些情况下，应通过运行 Nltest 工具来确定 Exchange 使用哪一台全局编录服务器。具体步骤在本主题前面的“通过使用移动邮箱工具将收件人移到 Active Directory”中已说明。然后，调查所涉及到的全局编录服务器。下面是全局编录服务器的常见问题：

  • 全局编录服务器超载或工作过度。
  • 全局编录服务器出现性能问题。
  • 内存不足。
  • 硬盘空间不足。
  • Exchange 2000 与全局编录服务器之间出现暂时性的网络问题。
  • 使用同一个全局编录服务器的 Exchange 服务器过多（推荐的 Exchange 处理器与全局编录服务器处理器的比率是四比一）。
important重要提示：
邮件跟踪日志可能会起到一种误导作用。例如，如果全局编录服务器正常工作，并且邮件分类程序也正常工作，但是远程 SMTP 服务器不可用达三十分钟，则邮件跟踪日志可能与上面显示的示例日志类似。此外，如果邮件必须在本地传递，并且 Exchange 存储执行速度很慢，则邮件跟踪日志将显示出“邮件已提交到邮件分类程序”与“邮件已传递到本地存储”之间存在很大的时间差异。

重现问题时，应从全局编录服务器中使用系统监视器日志。这有助于您诊断这些问题。再次使用全局编录服务器可以解决这些问题。要解决这些问题，可以为每一台 Exchange 服务器指定一台全局编录服务器。

note注意：
建议只有在要排除故障时才手动配置全局编录服务器。手动配置了全局编录服务器后，如果某个服务器不可用，Exchange 将无法检测到。

有关详细信息，请参阅如何指定全局编录服务器。

有关 DSAccess 的其他信息，请参阅 Microsoft 知识库中编号为 250570 的文章：“XCON: Directory Service Server Detection and DSAccess Usage”。

向个人通讯簿和联系人列表发送邮件时收到未送达报告

如果通过使用 Exchange 2003 移动邮箱工具将用户从 Exchange Server 5.5 计算机中移出，并且所移动的邮箱在 Exchange 5.5 邮箱中具有个人通讯簿或联系人列表，则该个人通讯簿或联系人列表在 Exchange 2003 邮箱中无效。已对照个人通讯簿或联系人列表进行解析的所有地址都会生成与下面类似的 NDR：

Your message did not reach some or all of the intended recipients.

Subject: Test

Sent: 8/3/2000 5:24 PM

The following recipient(s) could not be reached:

CN=\ Network,OU=United States,OU=Distribution Lists,DC=Contoso,DC=com on 8/3/2000 5:24 PM

The e-mail address could not be found. Perhaps the recipient moved to a different e-mail organization, or there was a mistake in the address. Check the address and try again.

<CONTOSO-MSG-01.Contoso.com #5.1.0>

由于移动邮箱工具不移动个人通讯簿和联系人列表，因此个人通讯簿和联系人列表中的所有地址信息都将无效。

若要解决此问题，请在 Outlook 客户端上确保全局地址列表被选定为通讯簿的来源。理想情况下，已从 Exchange 5.5 服务器移出的用户应删除个人通讯簿和联系人列表，然后重新创建这些个人通讯簿和联系人列表。

将邮件发送到公用文件夹

将电子邮件发送到 Exchange 中的公用文件夹比向邮箱发送电子邮件更为复杂。邮箱只能存在于一个服务器上，因此属于特定的邮箱存储。邮箱的 Active Directory 属性指向特定的服务器。因此，在解析条目后，Exchange 可以使用路由来确定要将邮件传递到哪个邮箱存储。

Active Directory 中的公用文件夹没有主服务器。公用文件夹可以存在于多个服务器上，并且 Active Directory 中没有信息指出该文件夹的副本存放在哪些服务器上。该信息由 Exchange 存储来处理。

当 Exchange 将邮件传递到公用文件夹中时，执行的第一个任务是将邮件传递到指向公用文件夹副本位置的 Exchange 存储。Exchange 存储查找 ptagReplicaList 条目（该条目列出具有该文件夹副本的 Exchange 服务器），然后重新提交邮件，并且此时邮件的接收地址是存放该文件夹副本的 Exchange 存储。

分类程序负责正确地解析邮件地址。对于公用文件夹，它负责：

  • 确定文件夹属于哪个顶级层次结构。
  • 对邮件加上正确的地址以便将邮件提交到该顶级层次结构的存储中。
  • 在获取副本列表后，将邮件的地址重新写入存放该公用文件夹副本的存储中。

在电子邮件发送到公用文件夹后，分类程序执行下列步骤以传递邮件：

  1. 初始公用文件夹查找
  2. 顶级层次结构服务器查找

初始公用文件夹查找

收到提交的电子邮件后，Exchange 将地址解析为 Active Directory 中的条目。如果该条目是公用文件夹而不是邮箱，分类程序尝试获取该公用文件夹的 homeMDB 属性。

homeMDB: CN=Public Folders,CN=Folder Hierarchies,CN=First Administrative Group,CN=Administrative Groups,CN=First Organization,CN=MicrosoftExchange,CN=Services,CN=Configuration,DC=contoso-msg-01,DC=contoso,DC=com;

文件夹的 homeMDB 属性包含该文件夹所属的顶级层次结构的可分辨名称。

顶级层次结构服务器查找

接下来，分类程序查找从文件夹的 homeMDB 属性检索到的顶级层次结构，以获取该文件夹顶级层次结构中的全部服务器列表。分类程序无法确定副本的位置，但是也可以将邮件提交到没有位置信息的 Exchange 存储。顶级层次结构可分辨名称包含指向该顶级层次结构中的所有服务器的链接。

为了确定分类程序应从顶级层次结构中选取哪个公用文件夹存储或服务器，Exchange 使用下列标准：

  • 其中的某个公用文件夹存储是否存在于本地服务器上？如果是，Exchange 使用该存储。
  • 其中的某个公用文件夹存储是否存在于本地路由组中的 Exchange 服务器上？如果是，Exchange 使用该存储。
  • 其中的某个公用文件夹存储是否存在于任意的 Exchange 服务器上？如果是，Exchange 使用该存储。否则，Exchange 使用列表中的第一个存储。

列表中的第一个服务器包含在 msExchOwningPFTreeBL 属性中。该属性位于文件夹层次结构下的公用文件夹树中。然后，分类程序选择 msExchOwningPFTreeBL 属性中的服务器，并将邮件发送到该服务器。

下面的示例显示了 msExchOwningPFTreeBL 属性中的内容（从 LDP 输出中获取）：

msExchOwningPFTreeBL: CN=Public Information Store (PFREP55),CN=First Storage Group,CN=InformationStore,CN=PFREP55,CN=Servers,CN=FourthCoffee,CN=Administrative Groups,CN=Lake District,CN=Microsoft Exchange,CN=Services,CN=Configuration, DC=cumbria,DC=extest,DC=microsoft, DC=com;

CN=Public Folder Store (PFREP57),CN=First Storage Group,CN=InformationStore, CN=PFREP57,CN=Servers,CN=Coniston,CN=Administrative Groups,CN=Lake District,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=cumbria,DC=example,DC=microsoft,DC=com;

CN=Public Information Store (PFREP56),CN=First Storage Group,CN=InformationStore,CN=PFREP56,CN=Servers,CN=Coniston,CN=Administrative Groups,CN=Lake District,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=cumbria,DC=example,DC=microsoft,DC=com;