标准 MTA 故障排除过程

本节概述了 MTA 的标准故障排除过程。如果问题未生成错误消息、如果错误消息未提供足够的诊断信息、如果要对 MTA 执行整体完好性检查、测试和标准维护，请按照以下过程进行。

• 检查 MTA 配置

• 检查邮件队列目录

• 检查重要文件的拥有权

• 检查作业控制器和分发程序是否正在运行

• 检查日志文件

• 手动运行通道程序

• 启动和停止各个通道

• MTA 故障排除示例

检查 MTA 配置

使用 imsimta test -rewrite 实用程序测试您的地址配置。使用该实用程序，您可以测试 MTA 的地址重写和通道映射，而不必实际发送邮件。有关更多信息，请参阅《Sun Java System Messaging Server 6 2005Q4 Administration Reference》中的第 2  章 “Message Transfer Agent Command-line Utilities” 中关于 MTA 命令行实用程序的内容。

实用程序通常会显示要应用的地址重写以及邮件将排入其中的通道。但是，MTA 配置中的语法错误将导致实用程序发出错误消息。如果输出不是您所期望的，则可能需要更正您的配置。

检查邮件队列目录

检查邮件是否在 MTA 邮件队列目录中，该目录通常为 msg_svr_base/data/queue/。使用命令行实用程序（如 imsimta qm）检查期望的邮件文件是否在 MTA 邮件队列目录中。有关 imsimta qm 的更多信息，请参阅《Sun Java System Messaging Server 6 2005Q4 Administration Reference》中的“imsimta qm” 中关于 MTA 命令行实用程序的内容以及imsimta qm counters。

如果 imsimta test -rewrite 输出看上去正确，请检查邮件是否确实放到了 MTA 邮件队列子目录中。要执行此操作，请启用目录 /msg_svr_base/log/ 中的邮件日志记录（有关 MTA 日志记录的更多信息，请参见管理 MTA 邮件和连接日志）。可以根据特定邮件的邮件 ID 跟踪该邮件以确保该邮件将放在 MTA 邮件队列子目录中。如果找不到该邮件，则可能是文件磁盘空间或目录权限有问题。

检查重要文件的拥有权

安装 Messaging Server 时，应该已选择邮件服务器用户帐户（默认情况下为 nobody）。此帐户应该拥有以下目录、子目录和文件：

/msg_svr_base/data/queue//msg_svr_base/log/tmp

类似以下 UNIX 系统示例中的命令可以用于检查这些目录的保护和拥有权：

ls -l -p -d /opt/SUNWmsgsr/data/queue
drwx------ 6 inetuser bin 512 Feb 7 09:32 /opt/SUNWmsgsr/data/queue

ls -l -p -d /opt/SUNWmsgsr/log/imta
drwx------ 2 inetuser bin 1536 Mar 10 09:00 /opt/SUNWmsgsr/log/imta

ls -l -p -d /opt/SUNWmsgsr/imta/tmp
drwx------ 2 inetuser bin 512 Feb 7 10:00 /opt/SUNWmsgsr/imta/tmp

使用类似以下 UNIX 系统示例中的命令检查 /msg_svr_base/data/queue 中的文件是否由 MTA 帐户拥有：

ls -l -p -R /opt/SUNWmsgsr/data/queue

检查作业控制器和分发程序是否正在运行

MTA 作业控制器可以控制 MTA 处理作业的执行，包括大多数外发（主）通道作业。

某些 MTA 通道（例如 MTA 的多线程 SMTP 通道）包括处理外来邮件的常驻服务器进程。这些服务器可以控制通道的从（外来）方向。MTA 分发程序可以控制此类 MTA 服务器的创建。分发程序配置选项可以控制服务器的可用性、创建的服务器的数量和每个服务器可以控制的连接数量。

要检查作业控制器和分发程序是否存在以及查看 MTA 服务器和处理作业是否正在运行，请使用命令 imsimta process。在闲置情况下，该命令应导致启动 job_controller 和 dispatcher 进程。例如：

# imsimta process
USER      PID S VSZ    RSS   STIME    TIME     COMMAND
inetuser 9567 S 18416 9368  02:00:02  0:00  /opt/SUNWmsgsr/lib/tcp_smtp_server
inetuser 6573 S 18112 5720  Jul_13    0:00  /opt/SUNWmsgsr/lib/job_controller
inetuser 9568 S 18416 9432  02:00:02  0:00  /opt/SUNWmsgsr/lib/tcp_smtp_server
inetuser 6574 S 17848 5328  Jul_13    0:00  /opt/SUNWmsgsr/lib/dispatcher

如果作业控制器不存在，则 /msg_svr_base/data/queue 目录中的文件将会被备份，而邮件不会被传送。如果不具备分发程序，则将无法接收任何 SMTP 连接。

有关 imsimta process 的更多信息，请参阅《Sun Java System Messaging Server 6 2005Q4 Administration Reference》中的“imsimta process”。

如果作业控制器和分发程序都不存在，则应该查阅 /msg_svr_base/data/log 中的 dispatcher.log-* 或 job_controller.log-* 文件。

如果日志文件不存在或未指出错误，请使用 start-msg 命令启动进程。有关更多信息，请参阅《Sun Java System Messaging Server 6 2005Q4 Administration Reference》中的“start-msg” 中关于 MTA 命令行实用程序的内容。

运行 imsimta process 时，不应该看到分发程序或作业控制器的多个实例，除非系统在执行 (exec()) 需要运行的程序之前正在处理分叉 (fork()) 子进程。但是，此类重复过程的时间范围很小。

检查日志文件

如果 MTA 处理作业运行正常，但邮件仍留在邮件队列目录中，您可以检查日志文件以查看发生的情况。所有 MTA 日志文件均创建于目录 /msg_svr_base/log 中。表 22–1 显示了各种 MTA 处理作业的日志文件名称格式。

每个日志文件均使用唯一的 ID (uniqueid) 创建以避免覆写由同一通道以前创建的日志。要查找特定日志文件，可以使用 imsimta view 实用程序。也可以使用 imsimta purge 命令清除过时的日志文件。有关更多信息，请参见《Sun Java System Messaging Server 6 2005Q4 Administration Reference》中的“imsimta purge” 中关于 MTA 命令行实用程序的内容。

在以下任何一种情况下，将创建 channel_master.log-uniqueid 和 channel_slave.log-uniqueid 日志文件：

• 您当前的配置存在错误。

• 在 imta.cnf 文件中的通道上设置了 master_debug 或 slave_debug 关键字。

• 如果在 option.dat 文件中将 mm_debug 设置为非零值 (mm_debug > 0)，此文件所在目录为：/msg_svr_base/config/。

有关调试通道主程序和从程序的更多信息，请参见 Sun Java System Messaging Server Administration Reference。

手动运行通道程序

诊断 MTA 传送问题时，手动运行 MTA 传送作业（特别是在为一个或多个通道启用调试后）将非常有帮助。

命令 imsimta submit 将通知 MTA 作业控制器运行通道。如果针对所述的通道启用了调试，则 imsimta submit 将在目录 /msg_svr_base/log 中创建一个日志文件，如表 22–1 所示。

命令 imsimta run 将在当前活动进程下执行通道的出站传送，并将输出指向您的终端。这可能比提交作业更方便，特别是在您怀疑作业提交本身有问题时。

要手动运行通道，作业控制器必须正在运行。

有关 imsimta submit 和 imsimta run 命令的语法、选项、参数和示例的信息，请参阅《Sun Java System Messaging Server 6 2005Q4 Administration Reference》中的“Command Descriptions”。

启动和停止各个通道

在某些情况下，停止和启动各个通道可能更易于诊断和调试邮件队列问题。停止邮件队列使您可以检查排列的邮件以确定存在的循环和垃圾邮件侵袭。

停止特定通道的出站处理（排出队列）

步骤

1. 使用 imsimta qm stop 命令停止特定通道。执行此操作可以不必停止作业控制器以及重新编译配置。在以下示例中，将停止 conversion 通道：

   imsimta qm stop conversion

2. 要恢复处理，请使用 imsimta qm start 命令重新启动通道。在以下示例中，将启动 conversion 通道：

   imsimta qm start conversion

   有关 imsimta qm start 和 imsimta qm stop 命令的更多信息，请参见《Sun Java System Messaging Server 6 2005Q4 Administration Reference》中的“imsimta qm”。

从特定域或 IP 地址停止外来处理（进入通道队列）

将临时 SMTP 错误返回到客户机主机时，如果要停止某个特定域或 IP 地址的入站邮件处理，请使用以下进程之一。执行此操作，邮件将不会保存在您的系统中。请参阅第 1 部分：映射表。

• 要停止特定主机或域名的入站处理，请将以下访问规则添加到 MTA 映射文件（通常为 /msg_svr_base/config/mappings）的 ORIG_SEND_ACCESS 映射表中：

ORIG_SEND_ACCESS 

  *|*@sesta.com|*|*        $X4.2.1|$NHost$ blocked

通过使用此进程，发件人的远程 MTA 将把邮件保存在其系统上，继续定期重新发送这些邮件直到您重新启动入站处理。

• 要停止特定 IP 地址的入站处理，请将以下访问规则添加到 MTA 映射文件（通常为 /msg_svr_base/config/mappings）的 PORT_ACCESS 映射表中：

PORT_ACCESS

    TCP|*|25|IP_address_to_block|*    $N500$ can't$ connect$ now

当希望从域或 IP 地址重新启动外来处理时，请确保从映射表中删除这些规则并重新编译配置。此外，您可能需要为每个映射表创建唯一的错误消息。这样做将使您可以确定正在使用哪个映射表。

MTA 故障排除示例

本节说明了如何逐步对特定 MTA 问题进行故障排除。在本例中，邮件收件人没有收到电子邮件消息的附件。注意：为了与 MIME 协议术语保持一致，在本节中“附件”被称为“邮件组成部分”。前面提到的故障排除技巧可用来识别邮件组成部分消失的位置和原因（请参见标准 MTA 故障排除过程）。通过使用以下步骤，可以确定邮件通过 MTA 的路径。此外，您还可以确定邮件组成部分是在邮件进入邮件队列之前还是之后消失的。要实现此目的，您需要手动停止和运行通道以捕获相关文件。

手动使邮件通过通道时，作业控制器必须正在运行。

识别邮件路径中的通道

通过识别邮件路径中的通道，您可以将 master_debug 和 slave_debug 关键字应用于相应的通道。这些关键字将在通道的主日志文件和从日志文件中生成调试输出，反过来，主调试信息和从调试信息将帮助识别邮件组成部分消失的位置。

1. 在目录 /msg_svr_base/config 中的 option.dat 文件中添加 log_message_id=1。使用此参数，您可以在 mail.log_current 文件中看到邮件的 ID: 标题行。

2. 运行 imsimta cnbuild 以重新编译配置。

3. 运行 imsimta restart dispatcher 以重新启动 SMTP 服务器。

4. 使最终用户重新发送带有邮件组成部分的邮件。

5. 确定邮件通过的通道。

   尽管识别通道有各种方法，但建议使用以下方法：

   1. 在 UNIX 平台上，使用 grep 命令在目录 /msg_svr_base/log 的 mail.log_current 文件中搜索邮件的 ID: 标题行。

   2. 找到邮件的 ID: 标题行之后，查找 E（入队列）记录和 D（出队列）记录以确定邮件的路径。有关日志记录条目代码的更多信息，请参阅了解 MTA 日志条目格式。有关此示例，请参见以下 E 记录和 D 记录：

      29-Aug-2001 10:39:46.44 tcp_local conversion E 2 ... 29-Aug-2001 10:39:46.44 conversion tcp_intranet E 2 ... 29-Aug-2001 10:39:46.44 tcp_intranet D 2 ...

左边的通道是源通道，右边的通道是目标通道。在本示例中，E 记录和 D 记录表明邮件路径是从 tcp_local 通道到 conversion 通道，最后到达 tcp_intranet 通道。

手动启动和停止通道以收集数据

本节说明了如何手动启动和停止通道。请参见启动和停止各个通道。通过启动和停止邮件路径中的通道，您可以在 MTA 进程的不同阶段保存邮件和日志文件。这些文件随后将用于识别邮件故障点中介绍的内容。

手动启动和停止通道

步骤

1. 在目录 /msg_svr_base/config 的 option.dat 文件中设置 mm_debug=5，以提供重要的调试信息。

2. 将 slave_debug 和 master_debug 关键字添加到目录 /msg_svr_base/config 中的 imta.cnf 文件中的相应通道。

   1. 在发送带有邮件组成部分的邮件的远程系统的入站通道（或初始对话期间邮件被切换到的任意通道），使用 slave_debug 关键字。本示例中，slave_debug 关键字被添加到 tcp_local 通道。

   2. 将 master_debug 关键字添加到邮件所通过的并在识别邮件路径中的通道中已经识别的其他通道。将被添加到 conversion 和 tcp_intranet 通道。

   3. 运行命令 imsimta restart dispatcher 以重新启动 SMTP 服务器。

3. 使用 imsimta qm stop 和 imsimta qm start 命令手动启动和停止特定通道。有关使用这些关键字的更多信息，请参见启动和停止各个通道。

4. 为启动捕获邮件文件的进程，请使最终用户重新发送带有邮件组成部分的邮件。

5. 当邮件进入某个通道时，如果使用 imsimta qm stop 命令停止了该邮件，则该邮件将停留在此通道中。有关更多信息，请参见步骤 3。

   1. 在手动运行邮件路径中的下一个通道之前，复制并重命名邮件文件。请参见以下 UNIX 平台示例：

      # cp ZZ01K7LXW76T7O9TD0TB.00 ZZ01K7LXW76T7O9TD0TB.KEEP1

      邮件文件通常位于类似 /msg_svr_base/data/queue/destination_channel/001 的目录中。destination_channel 是邮件将通过的下一个通道（例如：tcp_intranet）。如果要在 destination_channel 目录中创建子目录（如 001、002 等等），请将 subdirs 关键字添加到通道中。

   2. 建议每次捕获和复制邮件时为该邮件的扩展名编号，以标识处理该邮件的顺序。

6. 恢复通道中的邮件处理并将其加入邮件路径中的下一个目标通道队列。要执行此操作，请使用 imsimta qm start 命令。

7. 复制并保存位于目录 /msg_svr_base/log 中的相应通道日志文件（例如：tcp_intranet_master.log-*）。选择包含您正在跟踪的邮件数据的相应日志文件。确保邮件进入通道时，复制的文件与该邮件的时间戳和主题标题相匹配。在 tcp_intranet_master.log-* 的示例中，可以将文件另存为 tcp_intranet_master.keep，这样文件就不会被删除。

8. 重复步骤 5 至步骤 7 直到邮件到达其最终目标。

   在步骤 7 中复制的日志文件应该与在步骤 5 中复制的邮件文件相关联。例如，如果在丢失邮件组成部分的情况下停止所有通道，则需保存 conversion_master.log-* 和 tcp_intranet_master.log-* 文件。也要保存源通道日志文件 tcp_local_slave.log-*。此外，还要保存每个目标通道中相应邮件文件的副本：conversion 通道中的 ZZ01K7LXW76T7O9TD0TB.KEEP1 和 tcp_intranet 通道中的 ZZ01K7LXW76T7O9TD0TB.KEEP2。

9. 复制完邮件文件和日志文件后，删除调试选项。

   1. 从目录 /msg_svr_base/config 中的 imta.cnf 文件的相应通道中删除 slave_debug 和 master_debug 关键字。

   2. 重置 mm_debug=0，并删除目录 /msg_svr_base/config 中的 option.dat 文件的 log_message_id=1。

   3. 使用 imsimta cnbuild 重新编译配置。

   4. 运行命令 imsimta restart dispatcher 以重新启动 SMTP 服务器。

识别邮件故障点

步骤

1. 在完成启动和停止通道程序后，您应该具有可用于解决问题的以下文件：

   1. 每个通道程序中的邮件文件（例如 ZZ01K7LXW76T7O9TD0TB.KEEP1）的所有副本

   2. 一个 tcp_local_slave.log-* 文件

   3. 每个目标通道的一组 channel_master.log-* 文件

   4. 可以显示邮件路径的一组 mail.log_current 记录

      所有文件应该具有与mail.log_current 记录中的邮件 ID: 标题行相匹配的时间戳和邮件 ID 值。请注意有一个例外，当邮件被退回发件人时，这些退回的邮件将具有与原邮件不同的邮件 ID 值。

2. 检查 tcp_local_slave.log-* 文件以确定邮件进入邮件队列时是否有邮件组成部分。

   查看 SMTP 对话和数据以查看从客户机发送的内容。

   如果邮件组成部分未出现在 tcp_local_slave.log-* 文件中，则问题出现在邮件进入 MTA 之前。结果是，邮件被排入队列而没带邮件组成部分。这种情况下，问题可能发生在发件人的远程 SMTP 服务器或发件人的客户机上。

3. 审查邮件文件的副本以查看邮件组成部分被更改或丢失的位置。

   如果任一邮件文件显示邮件组成部分被更改或丢失，请检查以前的通道日志文件。例如，如果进入 tcp_intranet 通道的邮件中的邮件组成部分被更改或丢失，则应查看 conversion_master.log-* 文件。

4. 查看邮件的最终目标。

   如果邮件组成部分看起来没有在 tcp_local_slave.log、邮件文件（例如：ZZ01K7LXW76T7O9TD0TB.KEEP1）和 channel_master.log-* 文件中更改，则 MTA 未更改邮件，邮件组成部分是在通向其最终目标的路径中的下一步上消失的。

   如果最终目标是 ims-ms 通道（邮件存储），则可以将邮件从服务器下载到客户机上，以确定邮件组成部分是在此传输期间还是在此之后丢失的。如果目标通道是 tcp_* 通道，则需要转至邮件路径中的 MTA。假定是 Messaging Server MTA，您将需要重复整个故障排除过程（请参见识别邮件路径中的通道、手动启动和停止通道以收集数据和本节内容）。如果另一个 MTA 不受您的管理，则报告问题的用户应与特定站点联系。