邮件在循环

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

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

某些更常见的情况包括：

1. 邮寄主管地址损坏。

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

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

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

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

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

诊断和清理 .HELD 邮件

如果 MTA 检测到邮件在服务器或通道之间跳动，传送将被停止并且邮件将被存储在 /msg_svr_base/data/queue/channel 中带后缀 .HELD 的文件中。通常，出现邮件循环是因为每个服务器或通道认为另一个服务器或通道负责邮件的传送。

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

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

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

您还可以通过运行 imsimta qm release 或执行以下步骤来重试 .HELD 邮件：

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

   ---

   注 –

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

   ---

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

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

由于邮件可能会再次标记为 .HELD，可能有必要多次执行这些步骤，因为 Received: 标题行会堆积。