test

Sun Java System Messaging Server 6.3 管理指南

第 26 章 MTA 故障排除

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

相关主题（监视过程）可在第 27 章，监视 Messaging Server中找到。

注 –

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

26.1 故障排除概述

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

本章将在后续各节中解答这些问题。

26.2 标准 MTA 故障排除过程

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

26.2.1 检查 MTA 配置

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

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

26.2.2 检查邮件队列目录

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

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

26.2.3 检查重要文件的拥有权

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


msg-svr-base/data/queue/
msg-svrbase/data/log
msg-svr-base/data/tmp

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


ls -l -p -d /opt/SUNWmsgsr/data/queue
drwxr-x---   2 mailsrv  mail 512 Jan  4 16:09 /opt/SUNWmsgsr/data/queue/

ls -l -p -d /opt/SUNWmsgsr/data/log
drwxr-x---   2 mailsrv  mail  3072 Feb 16 12:07 /opt/SUNWmsgsr/data/log/

ls -l -p -d /opt/SUNWmsgsr/data/tmp
drwxr-x---   2 mailsrv  mail   512 Feb 16 12:55 /opt/SUNWmsgsr/data/tmp/

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

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

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

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

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

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


# imsimta process
USER      PID S VSZ    RSS   STIME    TIME     COMMAND
mailsrv 9567 S 18416 9368  02:00:02  0:00  /opt/SUNWmsgsr/lib/tcp_smtp_server
mailsrv 6573 S 18112 5720  Jul_13    0:00  /opt/SUNWmsgsr/lib/job_controller
mailsrv 9568 S 18416 9432  02:00:02  0:00  /opt/SUNWmsgsr/lib/tcp_smtp_server
mailsrv 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.3 Administration Reference》中的“imsimta process”。

您还可以使用 imsimta qm jobs 按通道列出当前由作业控制器管理的所有活动的和暂挂的传送处理作业。为每个通道提供了额外的累积信息，例如成功传送的邮件文件数和那些重新排队以进行后续传送尝试的邮件的数量。命令语法如下所示：


jobs [-[no]hosts] [-[no]jobs] [-[no]messages] [channel-name]

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

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

注 –

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

26.2.5 检查日志文件

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

表 26–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 命令清除过时的日志文件。但请注意，默认情况下，此命令定期运行（请参见4.6.2 预定义的自动任务）。有关详细信息，请参见 《Sun Java System Messaging Server 6.3 Administration Reference》中的“imsimta purge” 中关于 MTA 命令行实用程序的内容。

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

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

26.2.6 手动运行通道程序

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

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

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

注 –

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

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

26.2.7 启动和停止各个通道

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

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

  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.3 Administration Reference》中的“imsimta qm”。

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

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

ORIG_SEND_ACCESS 

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

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

PORT_ACCESS

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

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

26.2.8 MTA 故障排除示例

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

注 –

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

26.2.8.1 识别邮件路径中的通道

通过识别邮件路径中的通道，您可以将 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（出队列）记录以确定邮件的路径。有关日志记录条目代码的详细信息，请参阅25.3.1 了解 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 通道。

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

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

Procedure手动启动和停止通道

  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 关键字添加到邮件所通过的并在26.2.8.1 识别邮件路径中的通道中已经识别的其他通道。将被添加到 conversion 和 tcp_intranet 通道。

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

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

  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 服务器。

Procedure识别邮件故障点

  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，您将需要重复整个故障排除过程（请参见26.2.8.1 识别邮件路径中的通道、26.2.8.2 手动启动和停止通道以收集数据和本节内容）。如果另一个 MTA 不受您的管理，则报告问题的用户应与特定站点联系。

26.3 常见 MTA 问题和解决方案

本节列出了 MTA 配置和操作的常见问题和解决方案。

26.3.1 TLS 问题

如果在 SMTP 对话期间 STARTTLS 命令返回以下错误：

454 4.7.1 TLS 库初始化失败

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

在更改保护及安装证书后，必须运行以下命令：


stop-msg dispatcher 
start-msg dispatcher

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

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

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

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

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

  3. 重新建立所有客户端连接。

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

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

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

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

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


drwxrwxrwt 8 root sys 734 Sep 17 12:14 tmp/
.

还要对 .SUNWmsgsr.dispatcher.socket 文件执行 ls -l，并确认合适的拥有权。例如，如果它是由 root 创建的，则 inetmail 就无法访问。

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

26.3.5 外来 SMTP 连接超时

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

Procedure识别造成外来 SMTP 连接超时的原因

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

  2. 可以使用的另一个技巧是打开 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 以确保配置正确。

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


    febe2c04 iii_res_send (fb7f4564, 28, fb7f4de0, 400, fb7f458c, fb7f4564) + 
42c 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]

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

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

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

26.3.6 邮件未被排出队列

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

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


% nslookup -query=mx xtel.co.uk （步骤 1）
            
Server: LOCALHOST
Address: 127.0.0.1

Non-authoritative answer:
XTEL.CO.UK  preference = 10, mail exchanger = nsfnet-relay.ac.uk （步骤 2）

% telnet nsfnet-relay.ac.uk 25 （步骤 3）
Trying... [128.86.8.6]
telnet: Unable to connect to remote host: Connection refused

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

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

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

    注 –

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

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

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

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

26.3.6.1 创建新通道

在某些情况下，某个远程域可能出现故障，发送到该服务器的邮件数量可能会很大，以致外发通道队列将被无法传送的邮件填满。MTA 会尝试定期重新传送这些邮件（重试的频率和次数可以使用 backoff 关键字进行配置），正常情况下，不需要进行任何操作。但是，如果太多邮件阻塞在队列中，则其他邮件可能无法及时传送，因为所有通道作业都在处理积压的无法传送的邮件。

在这种情况下，您可以将这些邮件重新路由到在其自己的作业控制器池中运行的新通道。这将避免处理资源的争用并允许其他通道传送其邮件。下面介绍了此过程。我们先假定一个名为 siroe.com 的域。

Procedure创建新通道

  1. 创建名为 tcp_siroe-daemon 的新通道并为 pool 关键字添加新值。

    在 /msg-svr-base/ config/imta.cnf 的通道块部分创建通道。该通道与常规外发 tcp_* 通道应具有相同的通道关键字。通常，该通道是处理所有出站 (Internet) 通信的 tcp_local 通道。由于 siroe.com 在 Internet 上，因此这就是要模仿的通道。新通道可能类似于如下所示：

    tcp_siroe smtp nomx single_sys remotehost inner allowswitchchannel     \
dentnonenumeric subdirs 20 maxjobs 7 pool SMTP_SIROE maytlsserver      \
maysaslserver saslswitchchannel tcp_auth missingrecipientpolicy 0      \    
tcp_siroe-daemon

    注意新关键字-值对池 SMTP_SIROE。它指定传送到此通道的邮件将仅使用 SMTP_SIROE 池的计算机资源。另请注意，新通道的前后都需要留一个空白行。

  2. 将两个重写规则添加到 imta.cnf 文件的重写规则部分以将发往 siroe.com 的电子邮件定向到新通道。

    新重写规则类似于如下所示：


    siroe.com     $U%$D@tcp_siroe-daemon
.siroe.com      $U%$H$D@tcp_siroe-daemon

    这些重写规则将发往 siroe.com（包括如 host1.siroe.com 或 hostA.host1.siroe.com 的地址）的邮件定向到正式主机名为 tcp_siroe-daemon 的新通道。这些规则的重写部分，$U%$D 和 $U%$H$D，将保留邮件的原始地址。$U 复制原始地址的用户名。% 为分隔符，@ 位于用户名和域之间。$H 复制主机/域说明的不匹配部分（位于模式中点的左侧）。$D 复制域说明的匹配部分。

  3. 定义名为 SMTP_SIROE 的新作业控制器池。

    在 /msg-svr-base/ config/job_controller.cnf 中添加以下内容：


    [POOL=SMTP_SIROE]
job_limit=10

    这将创建名为 SMTP_SIROE 的邮件资源池，该池最多可以允许 10 个作业同时运行。确保没有在该池定义和其他项之间留下任何空白行。有关作业和池的详细信息，请参见8.7 作业控制器。

  4. 重新启动 MTA。

    发出以下命令：imsimta cnbuild;imsimta restart

    该命令重新编译配置并重新启动作业控制器和分发程序。

    本示例中，内部用户的大量电子邮件被发往名为 siroe.com 的特定远程站点。由于某些原因，siroe.com 临时不能接受外来 SMTP 连接，因此无法传送电子邮件。（此类情况并不是只在极少数情况下才发生。）

    发往 siroe.com 的电子邮件传入时，外发通道队列（通常为 tcp_local）将被无法传送的邮件填满。MTA 会尝试定期重新传送这些邮件（重试的频率和次数可以使用 backoff 关键字进行配置），正常情况下，不需要进行任何操作。

    但是，如果太多邮件阻塞在队列中，则其他邮件可能无法及时传送，因为所有通道作业都在处理积压的 siroe.com 邮件。在这种情况下，您可能希望将 siroe.com 邮件重新路由到在其自身的作业控制器池中运行的新通道（请参见8.7 作业控制器）。这将允许其他通道传送它们的邮件，而无需争用 siroe.com 邮件所使用的处理资源。下面将介绍如何创建新通道以解决此问题。

26.3.7 未传送 MTA 邮件

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

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

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

      通常每四小时同步队列高速缓存一次。如果需要，可以使用命令 imsimta cache -sync 手动重新同步高速缓存。同步后，通道程序将在处理完新邮件后处理原来未处理的邮件。如果要更改默认值（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。

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

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

      注意 – 注意 –

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

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

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

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”）。

26.3.9 接收到的邮件已编码

按已编码格式接收 MTA 发送的邮件。例如：

Date: Wed, 04 Jul 2001 11:59:56 -0700 (PDT)
From: "Desdemona Vilalobos" <Desdemona@sesta.com> 
To: santosh@varrius.com
Subject: test message with 8bit data 
MIME-Version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-transfer-encoding: QUOTED-PRINTABLE

2=00So are the Bo=F6tes Void and the Coal Sack the same?=

使用 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 必须对邮件进行编码。

26.3.10 服务器端规则（SSR）不生效

过滤器由一个或多个适用于邮件消息的条件操作组成。由于是在服务器上存储和评估过滤器，因此过滤器通常被称作服务器端规则 (Server-side Rules, SSR)。

本节包括有关以下 SSR 主题的信息：

另请参见18.15 调试用户级别的过滤器。

26.3.10.1 测试 SSR 规则


# 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.

26.3.10.2 常见语法问题

26.3.11 用户按下“发送电子邮件”按钮后响应缓慢

如果用户发送邮件时遇到延迟，这可能是由磁盘输入/输出降低（其原因是邮件队列磁盘大小不足）所致。用户按下其电子邮件客户端上的 "SEND" 按钮时，直到邮件被提交到邮件队列，MTA 才能完全接受邮件的回执。有关邮件队列大小调整的信息，可以在《》中找到。

26.3.12 地址的本地部分或接收字段中的星号

现在 MTA 在地址的本地部分及其构建的接收字段中查找 8 位字符（而不是仅 ASCII 字符）并用星号代替这些字符。

26.4 一般错误消息

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

注 –

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

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

26.4.1 mm_init 中的错误

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

经常遇到的 mm_init 错误包括：

26.4.1.1 别名的错误等值. . .

别名文件条目右侧部分的格式不正确。

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

无法打开别名文件所包含的文件。

26.4.1.3 发现重复的别名. . .

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

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

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

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

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

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

注 –

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

26.4.1.6 映射名称太长. . .

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

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

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

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

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


imsimta chbuild -noimage -maximum -option
imsimta chbuild

请验证在作出此更改前是否不需要重新编译和重新启动任何其他字符集表。有关 imsimta chbuild 的详细信息，请参阅 《Sun Java System Messaging Server 6.3 Administration Reference》中的“imsimta chbuild”。

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

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

26.4.1.10 别名没有等值地址. . .

别名文件中的某个条目缺少右侧部分（翻译值）。

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

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

26.4.1.12 正式主机名太长

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


Original l Channel:
!delivery channel to local /var/mail store
l subdirs 20 viaaliasrequired maxjobs 7 pool LOCAL_POOL
walleroo.pocofronitas.thisnameismuchtoolongandreallymakesnosensebutitisan
example.monkey.gorilla.orangutan.antidisestablismentarianism.newt.salaman
der.lizard.gecko.komododragon.com

Create Place Holder:
!delivery channel to local /var/mail store 
l subdirs 20 viaaliasrequired maxjobs 7 pool LOCAL_POOL
newt

Create Rewrite Rule:
newt.salamander.lizard.gecko.komododragon.com   $U%$D@newt

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

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

26.4.2 编译的配置版本不匹配

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

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

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

26.4.3 交换空间错误

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

如下所示的错误消息表示交换空间不足：

jbc_channels: chan_execute [1]: 分叉失败: 空间不足

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

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

26.4.4 文件打开或创建错误

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

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

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

26.4.5 非法主机/域错误

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

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

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

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

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