test

Sun Java System Messaging Server 6.3 管理指南

26.3.8 邮件在循环

如果 MTA 检测到某个邮件在循环，则该邮件将停止传送，并保存为 .HELD 文件。请参见26.3.8.1 诊断和清理 .HELD 邮件。某些特定情况可能会导致 MTA 无法检测到的邮件循环。

第一步是确定邮件循环的原因。您应该查看问题邮件文件在 MTA 队列区域时的副本、与问题邮件相关的 MTA 邮件日志条目（如果在 MTA 配置文件中为所述通道启用了 logging 通道关键字）和所述通道的 MTA 通道调试日志文件。确定问题邮件的 From: 地址和 To: 地址、查看 Received标题行并查看邮件结构（邮件内容的封装类型），这些均可以帮助准确地确定遇到的是哪种邮件循环情况。

某些更常见的情况包括：

  1. 邮寄主管地址损坏。

    MTA 要求邮寄主管地址为可以接收电子邮件的有效地址。如果至邮寄主管的邮件在循环，请检查配置是否具有指向可以接收邮件的帐户的正确邮寄主管地址。

  2. Received: 标题行的删除将阻止 MTA 检测邮件循环。

    邮件循环的常规检测基于 Received: 标题行。如果 Received: 标题行被删除（明显在 MTA 系统本身中或是在类似防火墙的另一个系统中），将影响邮件循环的正确检测。在这些情况下，请检查是否没有出现不希望的 Received: 标题行的删除。也要检查邮件循环的潜在原因。可能的原因包括：系统名称的指定有问题或系统未配置为可以识别其自身名称的变体、DNS 问题、缺少有关所述系统的授权的寻址信息或用户地址转发错误。

  3. 其他邮件传送系统对通知邮件的不正确处理将在响应通知邮件时生成重新封装的邮件。

    Internet 标准要求通知邮件（将要传送的邮件的报告或邮件退回）具有一个空包络 From: 地址，以防止邮件循环。但是，某些邮件传送系统不能正确地处理此类通知邮件。当转发或退回通知邮件时，这些邮件传送系统可能会插入一个新的包络 From: 地址。这可能会导致邮件循环。解决方案是修复不正确地处理通知邮件的邮件传送系统。

26.3.8.1 诊断和清理 .HELD 邮件

如果 MTA 检测到一个与邮件传送有关的严重问题，则邮件将被存储在 /msg-svr-base/data/queue/ channel 中后缀为 .HELD 的文件中。例如：


% ls 
ZZ0HXZ00G0EBRBCP.HELD
ZZ0HY200C0O6LGHU.HELD
ZZ0HYA006LP66O3H.HELD
ZZ0HZ7003EOQSE37.HELD

.HELD 文件的产生主要是由于以下三个原因：

循环导致的 .HELD 邮件

邮件在服务器或通道之间的来回传送称为循环。通常，出现邮件循环是因为每个服务器或通道认为另一个服务器或通道负责邮件的传送。循环邮件通常有大量的 *Received: 标题行。Received: 标题行将说明邮件循环的准确路径。 请仔细查看这些标题行中显示的主机名和所有收件人地址信息（例如，for recipient 子句或 (ORCPT recipient) 注释）。 导致这种邮件循环的原因之一是用户错误。

例如，最终用户可能设置了在两个独立的邮件主机上相互转发邮件的选项。在用户的 sesta.com 帐户上，最终用户启用了将邮件转发至其 varrius.com 帐户的设置。而用户忘记了已启用此设置，又在其 varrius.com 帐户上将邮件转发设置到 sesta.com 帐户。

错误的 MTA 配置也会导致出现循环。例如，MTA 主机 X 认为 mail.sesta.com 的邮件应由主机 Y 处理。而主机 Y 认为主机 X 应该处理 mail.sesta.com 的邮件；结果是主机 Y 将邮件返回到主机 X。

在这些情况下，MTA 忽略了邮件，而未尝试进一步的传送。出现此类问题时，请查看邮件中的标题行以确定退回邮件的服务器或通道。根据需要修复条目。

另一个导致邮件循环的常见原因是，MTA 使用某个网络名接收发送给 MTA 主机的邮件，而 MTA 没有将该网络名识别（尚未配置为识别）为其自身名称中的一个。解决方案是将额外的名称添加到其中的名称被 MTA 识别为自身名称的列表中。请注意，MTA 用来确定邮件是否正在循环的阈值是可以配置的；请参见 MAX_*RECEIVED_LINES option.dat 选项（《Sun Java System Messaging Server 6.3 Administration Reference》中的“Option File Format and Available Options”）。同时请注意， MTA 可以配置为（请参见 HELD_SNDOPR 全局 MTA 选项）只要邮件由于超出此阈值而被强制设置为 .HELD 状态，就生成一则系统日志通知。如果收到 Received count exceeded; message held. 系统日志邮件，就说明发生了邮件循环。

您也可以通过运行《Sun Java System Messaging Server 6.3 Administration Reference》中的“release”或按照以下步骤来重新发送 .HELD 邮件。

  1. 将 .HELD 扩展名将 .HELD 扩展名重命名为除 00 以外的任何 2 位数。例如，将 .HELD 重命名为 .06。

    注 –

    在重命名在重命名 .HELD 文件前，请确保邮件已停止循环。

  2. 运行 imsimta cache -sync。运行此命令将更新高速缓存。

  3. 运行 imsimta submit channel 或 imsimta run channel。

邮件可能会被再次标记为 .HELD，所以有必要多次执行这些步骤，因为 Received: 标题行会累积。如果仍存在问题，将像以前一样在同一通道下重新创建 *.HELD 文件。如果问题已经解决，则邮件将出队列并被传送。

如果您决定只是删除邮件而不尝试传送它们，请参见《Sun Java System Messaging Server 6.3 Administration Reference》中的“clean”。

由于用户或域的 hold 状态导致的 .HELD 邮件

由于用户或域的 hold 状态导致的 .HELD 邮件（并且仅因这种原因导致的 .HELD 邮件）一般将存储在 hold 通道的队列区域中。即，hold 通道队列区域中的 .HELD 邮件文件可以认为是由于用户或域状态导致的 .HELD 邮件。

由于可疑特征导致的 .HELD 邮件

由于某些可疑特征导致的 .HELD 邮件必然会表现出相应特征。这些特征可以是站点已经选定为具有可疑特征的任何内容。MTA 管理员应该始终了解这些配置选项和操作。但是，如果您不是该 MTA 的唯一或原始管理员，请检查是否进行了以下方面的 MTA 配置：使用 holdlimit 通道关键字（12.5.9 多个地址扩展）、在基于地址的 *_ACCESS 映射表（在 MTA 映射文件中）中使用 $H 标志，或者在任何系统 Sieve 文件（系统级别的 imta.filter 文件，或者所有使用 sourcefilter 或 destinationfilter 通道关键字配置和指定的通道级别的 Sieve 过滤器；请参见12.12.4 指定邮箱过滤器文件位置）中使用 hold 操作；然后询问所有其他 MTA 管理员最近是否执行过任何手动命令行邮件 hold 操作（例如，通过 imsimta qm clean 命令） 。同时请注意，无论是来自系统 Sieve 过滤器还是来自用户的个人 Sieve 过滤器，应用 Sieve 过滤器 hold 操作时都能可选地进行记录；有关更多信息，请参见 LOG_FILTER 全局 MTA 选项（《Sun Java System Messaging Server 6.3 Administration Reference》中的“Option File Format and Available Options”）。