第 21 章 MTA 故障排除

本章介绍了对邮件传输代理（MTA）进行故障排除的常用工具、方法和过程。其中包括以下各节：


注	阅读本章之前，您应该查阅本指南的第 5 章至第 10 章以及 Sun Java System Messaging Server Administration Reference 中关于 MTA 配置和命令行实用程序的章节。

故障排除概述

对 MTA 进行故障排除的第一步之一是确定从何处开始诊断。您可能要根据问题在日志文件中查找错误消息。在其他情况下，您可能要检查所有标准 MTA 进程，查看 MTA 配置或启动和停止单个通道。无论使用何种方法，对 MTA 进行故障排除时请考虑以下问题：

配置或环境问题（例如，磁盘空间或配额问题）是否阻止了邮件的接收？

邮件进入邮件队列时，MTA 服务（如分发程序和作业控制器）是否存在？

网络连接性或路由问题是否造成了邮件在远程系统上阻塞或路由错误？

问题出现在邮件进入邮件队列之前还是之后？

标准 MTA 故障排除过程

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

检查 MTA 配置

使用 imsimta test -rewrite 实用程序测试您的地址配置。使用此实用程序，您可以测试 MTA 的地址重写和通道映射，而不必实际发送邮件。有关详细信息，请参见 Sun Java System Messaging Server Administration Reference 中的“MTA Command-line Utilities”一章。

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

检查邮件队列目录

检查邮件是否在 MTA 邮件队列目录中，该目录通常为 msg_svr_base/data/queue/。使用命令行实用程序（如 imsimta qm）检查期望的邮件文件是否在 MTA 邮件队列目录下。有关 imsimta qm 的详细信息，请参见 Sun Java System Messaging Server Administration Reference 中有关 MTA 命令行实用程序的章节以及 imsimta qm counters。

如果 imsimta test -rewrite 输出看上去正确，请检查邮件是否确实放在 MTA 邮件队列子目录中。要执行此操作，请启用邮件日志记录（有关 MTA 日志记录的详细信息，请参见第 3 部分：服务日志 (MTA)）。然后，您应该查看目录 /msg_svr_base/log/ 中的 mail.log_current 文件。可以根据特定邮件的邮件 ID 跟踪该邮件以确保该邮件将放在 MTA 邮件队列子目录中。如果找不到该邮件，则可能是文件磁盘空间或目录权限有问题。

检查重要文件的拥有权

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

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

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

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

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

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

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

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

有关 imsimta process 的详细信息，请参见 Sun Java System Messaging Server Administration Reference。

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

如果日志文件不存在或未指出错误，请使用 msg-start 命令来启动进程。有关详细信息，请参见 Sun Java System Messaging Server Administration Reference 中关于 MTA 命令行实用程序的章节。

检查日志文件


注	运行 imsimta process 时，不应该看到分发程序或作业控制器的多个实例。

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

表 21-1 MTA 日志文件
文件名	日志文件内容
channel_master.log-uniqueid	channel 的主程序（通常为客户机上的程序）的输出。
channel_slave.log-uniqueid	channel 的从程序（通常为服务器上的程序）的输出。
dispatcher.log-uniqueid	分发程序调试。无论是否设置了分发程序 DEBUG 选项，都会创建此日志。但是，要获取详细的调试信息，应将 DEBUG 选项设置为非零值。
imta	传送中存在问题时显示的 ims-ms 通道错误消息。
job_controller.log-uniqueid	作业控制器日志记录。无论是否设置了作业控制器 DEBUG 选项，都会创建此日志。但是，要获取详细的调试信息，应将 DEBUG 选项设置为非零值。
tcp_smtp_server.log-uniqueid	调试 tcp_smtp_server。此日志中的信息是针对服务器（而不是邮件）的。
return.log-uniqueid	周期性 MTA 邮件退回程序作业的调试输出；如果在 option.dat 中使用了 return_debug 选项，则将创建此日志文件。


注	每个日志文件均使用唯一的 ID (uniqueid) 创建以避免覆写先前由同一通道创建的日志。要查找特定日志文件，可以使用 imsimta view 实用程序。也可以使用 imsimta purge 命令清理过时的日志文件。有关详细信息，请参见 Sun Java System Messaging Server Administration Reference 中关于 MTA 命令行实用程序的章节。

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

您当前的配置存在错误。

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

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

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

手动运行通道程序

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

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

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


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

有关 imsimta submit 和 imsimta run 命令的语法、选项、参数和示例的信息，请参见 Sun Java System Messaging Server Administration Reference 中关于 MTA 命令行实用程序的章节。

启动和停止各个通道

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

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

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

imsimta qm 停止转换

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

imsimta qm start conversion

有关 imsimta qm start 和 imsimta qm stop 命令的详细信息，请参见 Sun Java System Messaging Server Administration Reference 中关于 MTA 命令行实用程序的章节。

从特定域或 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$ unable$ to$ \
connect$ at$ this$ time

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

MTA 故障排除示例

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

识别邮件路径中的通道


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

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

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

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

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

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

确定邮件通过的通道。

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

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

找到邮件的 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 进程的不同阶段保存邮件和日志文件。这些文件随后将用于识别邮件故障点。

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

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

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

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

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

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

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

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

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

# cp ZZ01K7LXW76T7O9TD0TB.00 ZZ01K7LXW76T7O9TD0TB.KEEP1

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

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

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

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

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

The log files you copied in Step 步骤 7 should correlate to the message files that you copied in Step 步骤 5.例如，如果在丢失邮件组成部分的情况下停止所有通道，则需保存 conversion_master.log-* 和 tcp_intranet_master.log-* 文件。也要保存源通道日志文件 tcp_local_slave.log-*。此外，还要保存每个目标通道中相应邮件文件的副本：conversion 通道中的 ZZ01K7LXW76T7O9TD0TB.KEEP1 和 tcp_intranet 通道中的 ZZ01K7LXW76T7O9TD0TB.KEEP2。

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

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

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

使用 imsimta cnbuild 重新编译配置。

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

识别邮件故障点

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

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

一个 tcp_local_slave.log-* 文件

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

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

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

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

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

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

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

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

查看邮件的最终目标。

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

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

常见 MTA 问题和解决方案

对配置文件或 MTA 数据库的更改未生效

MTA 可以发送外发邮件但不能接收外来邮件

TLS 问题

并且如果您已经安装了证书并将其用于 pop/imap 访问，请检查以下事项：

必须设置证书的保护/拥有权以便 mailsrv 帐户可以访问这些文件

存储证书的目录需要设置保护/拥有权以便 mailsrv 帐户可以访问该目录内的文件。

重新启动 MTA 即可，但最好是将其彻底关闭、安装证书，然后一切恢复正常。

对配置文件或 MTA 数据库的更改未生效

如果对配置、映射、转换、安全性、选项或别名文件的更改未生效，请检查以查看您是否执行了以下步骤：

重新编译配置（通过运行 imsimta cnbuild）。

重新启动相应的进程（如 imsimta restart dispatcher）。

重新建立所有客户机连接。

MTA 可以发送外发邮件但不能接收外来邮件

大多数 MTA 通道依赖从程序或通道程序来接收外来邮件。对于某些由 MTA（如 TCP/IP 和 UUCP）支持的传输协议，需要确保传输协议激活的是 MTA 从程序而不是其标准服务器。将本地 sendmail SMTP 服务器替换为 MTA SMTP 服务器是作为 Messaging Server 安装的一部分执行的。有关详细信息，请参见《Sun ONE Messaging Server 安装指南》。

对于多线程 SMTP 服务器，SMTP 服务器的启动是由分发程序控制的。如果将分发程序配置为使用一个 MIN_PROCS 值（大于或等于 SMTP 服务的值），则应始终至少有一个 SMTP 服务器进程在运行（并且根据 SMTP 服务的 MAX_PROCS 值，可能更多）。imsimta process 命令可用于检查 SMTP 服务器进程是否存在。有关详细信息，请参见 Sun Java System Messaging Server Administration Reference 中关于 MTA 命令行实用程序的章节。

分发程序（SMTP 服务器）无法启动

如果分发程序无法启动，请首先检查 dispatcher.log-* 以获取相关错误消息。如果日志表明在创建或访问 /tmp/.SUNWmsgsr.dispatcher.socket 文件时有问题，则验证 /tmp 保护是否设置为 1777。该设置在权限中将显示如下：

请勿删除 .SUNWmsgsr.dispatcher.file，如果丢失，也不要创建。分发程序将创建该文件。如果保护未设置为 1777，则分发程序不会启动或重新启动，因为无法创建/访问套接字文件。此外，还可能出现与 Messaging Server 无关的其他问题。

外来 SMTP 连接超时

外来 SMTP 连接超时通常与系统资源及其分配相关。以下技巧可用于识别造成外来 SMTP 连接超时的原因：

检查您允许同时进行多少个外来 SMTP 连接。这将由 SMTP 服务的 MAX_PROCS 和 MAX_CONNS 分发程序设置控制；允许同时进行的连接数量是 MAX_PROCS*MAX_CONNS。如果您可以提供系统资源，而连接数量太少不能满足使用要求，可以考虑增加此数量。

可以使用的另一个技巧是打开 TELNET 会话。在以下示例中，用户连接到 127.0.0.1 端口 25。连接后，将返回 220 标题。例如：

telnet 127.0.0.1 25
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is ’^]’.
220 budgie.sesta.com -- Server ESMTP (Sun Java System Messaging Server 6.1 (built May 7 2001))

如果已连接并且收到 220 标题，但其他命令（如 ehlo 和 mail from）没有违反响应，则应该运行 imsimta test -rewrite 以确保配置正确。

如果 220 标题的响应时间较慢，如果在 SMTP 服务器上运行 pstack 命令时显示以下 iii_res* 函数（这些函数表示正在执行的名称解析查找。）：

febe2c04 iii_res_send (fb7f4564, 28, fb7f4de0, 400, fb7f458c, fb7f4564) + 142c
febdfdcc iii_res_query (0, fb7f4564, c, fb7f4de0, 400, 7f) + 254

则可能是主机必须进行反向名称解析查找，即使对于普通对（如 localhost/127.0.0.1）。要防止此类性能降低，应该在 /etc/nsswitch.conf 文件中对主机的查找重新排序。要执行此操作，请将 /etc/nsswitch.conf 文件中的以下行从：

hosts:dns nis [NOTFOUND=return] files

更改为：

hosts:files dns nis [NOTFOUND=return]

在 /etc/nsswitch.conf 文件中进行此更改可以提高性能。只有少数 SMTP 服务器必须处理邮件，而不是多数 SMTP 服务器必须执行不必要的查找。

您还可以通过 TCP/IP 邮件（通常为 tcp_local 和 tcp_intranet）将 slave_debug 关键字放在处理外来 SMTP 的通道中。完成此操作后，请查阅最近的 tcp_local_slave.log-uniqueid 文件以识别超时邮件的所有具体特征。例如，如果大量收件人的外来邮件将要超时，请考虑在通道中使用 expandlimit 关键字。

请记住，如果您的系统过载和过分扩展，则很难完全避免超时。

邮件未被排出队列

在 TCP/IP 传送期间遇到的错误通常是瞬态的，遇到问题时 MTA 通常会保留邮件并定期重试传送。在大型网络的特定主机上遇到周期性故障而其他主机连接运行良好，这是正常的。要验证该问题，请检查日志文件以查看与传送尝试相关的错误。您可能会看到例如“来自 smtp_open 的致命错误”的错误消息。此类错误很常见并通常与瞬态网络问题相关联。要调试 TCP/IP 网络问题，请使用类似 PING、TRACEROUTE 和 NSLOOKUP 的实用程序。

以下示例显示了查看邮件停留在等待传送到 xtel.co.uk 的队列中的原因可能使用的步骤。要确定邮件未被排出队列的原因，可以创建 MTA 用于在 TCP/IP 上传送 SMTP 邮件的步骤。

使用 NSLOOKUP 实用程序以查看此主机的 MX 记录（如果有）。如果没有 MX 记录，则应尝试直接连接到主机。如果确实有 MX 记录，则必须连接到指定的 MX 中继。MTA 优先使用 MX 信息，除非明确地配置为不这样做。另请参见 TCP/IP MX 记录支持。

在此示例中，DNS（域名服务）为 xtel.co.uk 返回了指定的 MX 中继的名称。这是 MTA 将实际连接到的主机。如果列出了不止一个 MX 中断，则 MTA 将连续尝试每个 MX 记录，首先尝试最低的首选项值。

如果与远程主机之间确实存在连接，则应该通过 TELNET 连接到 SMTP 服务器端口 25 以检查远程主机是否接受外来 SMTP 连接。



注	如果使用 TELNET 时未指定端口，您将发现远程主机接受常规 TELNET 连接。这并不表示远程主机接受 SMTP 连接，许多系统接受常规 TELNET 连接但拒绝 SMTP 连接（反之亦然）。因此，您应该始终在 SMTP 端口上进行测试。

在上一个示例中，远程主机拒绝连接到 SMTP 端口。这就是 MTA 无法传送邮件的原因。连接可能被拒绝是由于远程主机的错误配置或远程主机上的某种资源的耗尽。在这种情况下，无法在本地进行任何操作以解决该问题。通常应该让 MTA 继续重试对邮件进行操作。

如果在未使用 DNS 的 TCP/IP 网络上运行 Messaging Server，则可以跳过步骤（步骤 1）和（步骤 2）。而可以使用 TELNET 以直接访问所述主机。要注意与 MTA 使用同一个主机名。查看 MTA 上一次尝试的相关日志文件以确定主机名。如果使用的是主机文件，则应该确保主机名信息正确。强烈建议使用 DNS 而不使用主机名。

请注意，如果使用交互式测试测试与 TCP/IP 主机的连接性时未遇到任何问题，则问题很可能在 MTA 上次尝试传送邮件后就已经完全解决了。您可以在相应的通道上重新运行 imsimta submit tcp_channel 以查看邮件是否正在被排出队列。

未传送 MTA 邮件

除了邮件传输问题，还有两种常见问题可导致未处理的邮件存在于邮件队列中：

队列高速缓存与队列目录中的邮件不同步。MTA 队列子目录中正在等待传送的邮件文件进入到内存中的队列高速缓存。通道程序运行时，将询问此队列高速缓存以确定要在通道队列中传送的邮件。有些情况下，队列中有邮件文件，但是没有相应的队列高速缓存条目。

要检查队列高速缓存中是否有某个特定文件，可以使用 imsimta cache -view 实用程序；如果该文件不在队列高速缓存中，则需要同步队列高速缓存。

通常每四小时同步队列高速缓存一次。如果需要，可以使用命令 imsimta cache 杝ync 手动重新同步高速缓存。同步后，通道程序将在处理了新邮件后处理原来未处理过的邮件。如果要更改缺省值（4 小时），则应该通过添加 sync_time=timeperiod（其中 timeperiod 反映同步队列高速缓存的频率）来修改目录 /msg_svr_base/config 中的 job_controller.cnf 文件。请注意，timeperiod 必须大于 30 分钟。在以下示例中，通过将 sync_time=02:00 添加到 job_controller.cnf 的全局缺省部分，队列高速缓存同步时间被修改为 2 小时：

! VERSION=5.0
!IMTA job controller configuration file
!
!Global defaults
tcp_port=27442
secret=N1Y9[HzQKW
slave_command=NULL
sync_time=02:00

您可以运行 imsimta submit channel 以在运行 imsimta cache -sync 后清除邮件的待办事项。要特别注意，如果邮件的待办事项较大（大于 1000），则清除通道可能需要花很长时间。

要获取队列高速缓存的摘要信息，请运行 imsimta qm -maint dir -database -total。

如果在同步了队列高速缓存后，仍没有传送邮件，则应该重新启动作业控制器。要执行此操作，请使用 imsimta restart job_controller 命令。

重新启动作业控制器将导致从磁盘上的邮件队列重建邮件数据结构。



注意	重新启动作业控制器是一个激烈步骤，应该仅在完全用尽了所有其他方法时才执行。

有关作业控制器的详细信息，请参见作业控制器。

通道处理程序无法运行，因为无法创建其处理日志文件。请检查访问权限、磁盘空间和配额。

邮件在循环

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

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

邮寄主管地址损坏。

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

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

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

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

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 忽略了邮件，而未尝试进一步的传送。出现此类问题时，请查看邮件中的标题行以确定退回邮件的服务器或通道。根据需要修复条目。

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



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

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

运行 imsimta submit channel 或 imsimta run channel。

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

接收到的邮件已编码

使用 MTA 解码器命令 imsimta decode 阅读时，这些邮件显示为未编码。有关详细信息，请参见 Sun Java System Messaging Server Administration Reference。

SMTP 协议仅允许如 RFC 821 中所述的 ASCII 字符（七位字符集）的传输。实际上，通过 SMTP 的八位字符的未经协商的传输是非法的，并且会导致某些 SMTP 服务器出现各种问题。例如，SMTP 服务器可能转入计算联结循环。邮件被反复发送。八位字符会使 SMTP 服务器崩溃。最后，八位字符设置会对不能处理八位数据的浏览器和邮箱造成严重破坏。

过去处理包含八位数据的邮件时，SMTP 客户机只有三种选项：将邮件按无法传送返回发件人、对邮件进行编码或直接违反 RFC 821 发送邮件。但是随着 MIME 和 SMTP 扩展的出现，现在可以通过使用 ASCII 字符集将标准编码用于对八位数据进行编码。

在前面的示例中，收件人收到带有 TEXT/PLAIN 内容类型的 MIME 的编码邮件。远程 SMTP 服务器（MTA SMTP 客户机将邮件传输到其上）不支持八位数据的传输。由于原邮件包含八位字符，MTA 必须对邮件进行编码。

服务器端规则 (SSR) 不生效

过滤器由一个或多个适用于邮件消息的条件操作组成。由于过滤器是在服务器上进行存储和评估，所以通常将其称作服务器端规则 (SSR)。

测试 SSR 规则

常见语法问题

测试 SSR 规则

要检查 MTA 的用户过滤器，请使用以下命令：

# imsimta test -rewrite -debug -filter user@domain

在输出中，查找以下信息：

mmc_open_url called to open ssrf:user@ims-ms
URL with quotes stripped: ssrd:user@ims-ms
Determined to be a SSRD URL.
Identifier: user@ims-ms-daemon
Filter successfully obtained.

此外，可以将 slave_debug 关键字添加到 tcp_local 通道以查看过滤器是如何应用的。结果显示在 tcp_local_slave.log 文件中。请确保在目录 /msg_svr_base/config 中的 option.dat 文件中添加 mm_debug=5 以获取足够的调试信息。

常见语法问题

如果过滤器存在语法问题，请在 tcp_local_slave.log-* 文件中查找以下消息：
Error parsing filter expression:...

如果过滤器没问题，则将在输出的末端显示过滤器信息。

如果过滤器有问题，则将在输出的末端显示以下错误：
Address list error -- 4.7.1 Filter syntax error: desdaemona@sesta.com

此外，如果过滤器有问题，则 SMTP RCPT TO 命令将返回一个临时错误响应代码：

RCPT TO:user@domain
452 4.7.1 Filter syntax error

一般错误消息

MTA 无法启动时，一般错误消息显示在命令行中。本节将介绍和诊断常见的一般错误消息。


注	要诊断您自己的 MTA 配置，请使用 imsimta test -rewrite -debug 实用程序以检查 MTA 的地址重写和通道映射进程。通过使用此实用程序，您可以检查配置而无需实际发送邮件。请参见检查 MTA 配置。

MTA 子组件还可能发出本章中未介绍的其他错误消息。有关每个子组件的详细信息，应该参见 Sun Java System Messaging Server Administration Reference 中有关 MTA 命令行实用程序和配置的章节以及第 5 章至第 10 章。本节包括以下类型的错误：

SMTP 通道中的错误：os_smtp_* 错误

mm_init 中的错误

mm_init 中的错误通常表示 MTA 配置问题。如果运行 imsimta test -rewrite 实用程序，就会显示这些错误。其他实用程序（如 imsimta cnbuild）、通道、服务器或浏览器也可能返回此类错误。

别名的错误等值 . . .

无法打开别名包含文件 . . .

发现重复的别名 . . .

两个别名文件条目具有相同的左侧部分。您需要找出并删除重复项。查找提示 error line #XXX 的错误消息，其中 XXX 是行号。您可以在此行上修复重复的别名。

通道表中的重复的主机 . . .

此错误消息表示您在 MTA 配置中有两个具有相同正式主机名的通道定义。

请注意，MTA 配置文件 (imta.cnf) 的重写规则（上部）中的多余空白行将导致 MTA 将配置文件的提示解释成通道定义。请确保文件的首行不是空白行。由于经常有多个相同模式（左侧）的重写规则，这就导致 MTA 将其解释成带有非唯一正式主机名的通道定义。请检查 MTA 配置中的所有带有重复正式主机名的通道定义和文件的上部（重写规则）中所有不正确的空白行。

发现重复的映射名称 . . .

此消息表示两个映射表具有相同的名称，需要删除其中一个重复的映射表。但是，映射文件中的格式化错误可能会导致 MTA 将某些内容错误地解释成映射表的名称。例如，无法正确地缩进映射表条目将导致 MTA 认为该条目的左侧实际上是映射表的名称。请检查映射文件中的常规格式并检查映射表名称。

映射名称太长 . . .

此错误表示映射表名称太长，需要缩短。映射文件中的格式化错误可能会导致 MTA 将某些内容错误地解释成映射表名称。例如，无法正确地缩进映射表条目将导致 MTA 认为该条目的左侧实际上是映射表的名称。检查映射文件和映射表名称。

初始化 ch_ facility 时出错：编译的字符集版本不匹配


注	在带有映射表名称的任一行的前后应有一行空白行。但是，在映射表的条目中间不应插入任何空白行。

如果看到此消息，则需要通过命令 imsimta chbuild 重新编译并重新安装已编译的字符集表。有关详细信息，请参见 Sun Java System Messaging Server Administration Reference。

初始化 ch_ facility 时出错：没有空间进入 . . .

此错误消息通常表示您需要调整 MTA 字符集内部表的大小，然后使用以下命令重建已编译的字符集表：

请验证在作出此更改前是否不需要重新编译和重新启动任何其他字符集表。有关 imsimta chbuild 的详细信息，请参见 Sun Java System Messaging Server Administration Reference 中关于 MTA 命令行实用程序的章节。

对于系统来说本地主机别名或本来的名称太长 . . .

此错误表示本地主机别名或本来的名称太长（通道块中第二个名称或后续名称的可选右侧部分）。但是，MTA 配置文件中较早的某些语法错误（例如，重写规则中的多余空白行）可能会导致 MTA 将某些内容错误地解释成通道定义。除了检查配置文件的提示行，还要检查该行以上的其他语法错误。特别是，如果 MTA 在其中发出此错误的行是要作为重写规则，则请确保检查此行之上的多余空白行。

别名没有等值地址 . . .

通道没有正式主机名 . . .

此错误表示通道定义块缺少所需第二行（正式主机名行）。有关通道定义块的详细信息，请参见 Sun Java System Messaging Server Administration Reference 中关于 MTA 配置及命令行实用程序的章节以及第 12 章“配置通道定义”。在每个通道定义块的前后需要一个空白行，但空白行不能存在于通道定义的通道名称行和正式主机名行之间。还要注意，MTA 配置文件的重写规则部分不允许有空白行。

正式主机名太长

通道的正式主机名（通道定义块的第二行）的长度限制为四十个八位字节。如果要尝试在通道上使用较长的正式主机名，请将其缩短成占位符名称，然后使用重写规则使较长名称与短的正式主机名匹配。如果使用 l（本地）通道主机名，您可能会看到此情形。例如：

请注意，使用 l（本地）通道时，需要使用 REVERSE 映射表。有关用法和语法的信息，请参见 Sun Java System Messaging Server Administration Reference 中关于 MTA 配置的章节。

较早出现在 MTA 配置文件（例如，重写规则中的多余空白行）中的某些语法错误可能会导致 MTA 将某些内容错误地解释成通道定义。这可能会导致将预定的重写规则解释为正式主机名。除了检查配置文件的提示行，还要检查该行以上的其他语法错误。特别是，如果 MTA 在其中发出此错误的行是要作为重写规则，请确保检查此行之上的多余空白行。

编译的配置版本不匹配

imsimta cnbuild 实用程序的功能之一是将 MTA 配置信息编译成可以快速装入的映像。编译的格式定义相当严格，经常在 MTA 的不同版本之间发生重大更改。修补程序发行版的部分可能会出现较小的更改。

发生此类更改时，内部版本部分也将更改，以便可以检测到不兼容的格式。检测到不兼容的格式时，MTA 组件将停止，并显示上述错误。此问题的解决方案是使用命令 imsimta cnbuild 生成一个新的、编译的配置。

还有个好办法是使用 imsimta restart 命令重新启动所有常驻 MTA 服务器进程，这样可以获得更新的配置信息。

交换空间错误

要确保正确操作，重要的是在邮件传送系统上配置足够的交换空间。所需交换空间的容量将根据配置而有所不同。一般的协调建议是，交换空间的容量应该至少是主内存容量的三倍。

您可能会在作业控制器日志文件中看到此错误。其他交换空间错误将根据配置而有所不同。

使用以下命令可以确定您剩余的交换空间以及确定您已使用的交换空间。

Solaris 系统：swap -s（在 MTA 进程繁忙时）、ps -elf 或 tail /var/adm/messages

HP-UX 系统：swapinfo 或 tail /var/adm/syslog/syslog.log

文件打开或创建错误

为发送邮件，MTA 将读取配置文件并在 MTA 邮件队列目录中创建邮件文件。配置文件必须可由 MTA 或使用 MTA 的 SDK 编写的任何程序读取。在安装期间，可将适当的权限指定给这些文件。创建配置文件的 MTA 实用程序和过程也可指定权限。如果这些文件受系统管理员、其他授权的用户或某些站点特定过程的保护，则 MTA 可能无法读取配置信息。这将导致“文件打开”错误或不可预测的性能。读取配置文件时遇到问题，imsimta test -rewrite 实用程序将报告附加信息。请参见 Sun Java System Messaging Server Administration Reference 的 MTA 有关章节中的 imsimta test -rewrite 文档。

如果 MTA 表现为从授权的帐户（而不是非授权帐户）运行时，则 MTA 表目录中的文件权限可能是导致该问题的原因。检查配置文件及其目录的权限。请参见检查重要文件的拥有权。

“文件创建”错误通常表示在 MTA 邮件队列目录中创建邮件文件时发生的问题。要诊断文件创建问题，请参见检查邮件队列目录。

非法主机/域错误

当通过浏览器为 MTA 提供地址时，可能会看见此错误。或者，该错误可能被延迟并作为错误返回邮件消息的一部分被返回。两种情况下，此错误消息均表示 MTA 无法将邮件传送到指定的主机。要确定不会将邮件发送到指定主机的原因，应按以下故障排除过程进行：

验证所述地址没有拼写错，没有抄写错，也没有使用不再存在的主机名或域名。

通过 imsimta test -rewrite 实用程序运行所述地址。如果此实用程序也返回关于该地址的“非法主机/域”错误，则 MTA 在 imta.cnf 文件和相关文件中不具有处理该地址的规则。验证已正确配置了 MTA、已相应回答了所有配置问题，并保持了最新的配置信息。

如果 imsimta test -rewrite 未遇到有关地址的错误，则 MTA 可以确定如何处理地址，但网络传输将不接受该地址。您可以通过其他细节的传送尝试检查相应的日志文件。瞬态网络路由或名称服务错误不应该导致返回的错误消息，但是严重配置错误的域名服务器有可能会导致这些问题。

如果是在 Internet 上，请检查已正确配置 TCP/IP 通道以支持 MX 记录查找。不能直接在 Internet 上访问许多域地址，因此需要您的邮件系统能够正确解析 MX 条目。如果您在 Internet 上，并且您的 TCP/IP 已配置为支持 MX 记录，则应该已配置了 MTA 以启用 MTA 支持。有关详细信息，请参见 TCP/IP 连接和 DNS 查找支持 TCP/IP 连接和 DNS 查找支持。如果您的 TCP/IP 软件包没有配置为支持 MX 记录查找，则无法访问仅用于 MX 的域。

SMTP 通道中的错误：os_smtp_* 错误

以下所示的错误不一定是 MTA 错误：os_smtp_* 错误，如 os_smtp_open、os_smtp_read 和 os_smtp_write 错误。这些错误是 MTA 报告在网络层遇到的问题时生成的。例如，os_smtp_open 错误表示无法打开与远程端的网络连接。由于寻址错误或通道配置错误，MTA 可能会配置为与无效系统连接。os_smtp_* 错误通常是由于 DNS 或网络连接性问题，特别是如果这是以前的工作通道或地址。os_smtp_read 和 os_smtp_write 错误通常表示其他端中止了连接或由于网络问题而中止了连接。

网络和 DNS 问题在本质上通常是瞬态的。通常不必担心偶尔的 os_smtp_* 错误。但是，如果不断地看到这些错误，可能表示有潜在的网络问题。

要获取有关特定 os_smtp_* 错误的详细信息，请在所述通道上启用调试。审查将显示所尝试的 SMTP 对话的详细信息的调试通道日志文件。特别是要查看在 SMTP 对话期间出现网络问题的时间。时间可以暗示网络问题和远程端问题的类型。在某些情况下，您可能还需要执行网络级别调试（例如，TCP/IP 软件包跟踪）来确定已发送或已接收的内容。

上一个目录索引下一个
Sun Java System Messaging Server 6 2004Q2 管理指南