上一页    目录    索引    下一页
iPlanet Messaging Server 5.2 管理员指南

第 14 篇 MTA 故障诊断


本章介绍邮件传送代理（MTA）故障诊断的常用工具、方法和程序。本章包括下列各节：

与之相关的监视程序内容可在第 15 篇 “监控 iPlanet Messaging Server”中查找。


备注： 在阅读本章之前，应阅读本指南中的第 10 篇到第 6 篇以及 iPlanet Messaging Server Reference Manual 中有关 MTA 配置和命令行实用程序的章节。



故障诊断概述


对 MTA 进行故障诊断的首要步骤之一就是确定从何处开始诊断。视问题情况，可在日志文件中寻找出错信息。在其他情况下，可检查所有标准 MTA 处理，查看 MTA 配置，或启动和停止单个通道。不管使用什么方法，在对 MTA 进行故障诊断时需考虑如下问题：

本章将在下列小节中讨论这些问题。


标准 MTA 故障诊断程序


本节概括了 MTA 的标准故障诊断程序。如果问题没有生成出错信息或出错信息不能提供足够的诊断依据，或者只想对 MTA 进行一般的运行状态检查、测试和标准维护，可遵循使用这些程序步骤。


检查 MTA 配置

使用 imsimta test -rewrite 实用程序检查地址配置。运用此实用程序，不实际发送邮件即可测试 MTA 的地址重写和通道映射。详细信息，请参阅 iPlanet Messaging Server Reference Manual 中“MTA 命令行实用程序”一章。

该实用程序通常显示将要应用的地址重写以及邮件将要入队的那个通道。然而，MTA 配置中的句法错误会使实用程序产生出错信息。如果输出不是所预期的话，则需更正配置。


检查邮件队列目录

检查邮件是否在 MTA 邮件队列目录中，典型情况下这个目录就是 /server-root/msg-instance/imta/queue/.使用诸如 imsimta qm 这样的命令行实用程序检查 MTA 邮件队列目录下预期邮件文件的存在。有关 imsimta qm 的详细说明，请参阅 iPlanet Messaging Server Reference Manual 和“imsimta qm 计数器”中的“MTA 命令行实用程序”一章。

如果 imsimta test -rewrite 的输出看起来是正确的，检查确认邮件确实位于MTA 邮件队列子目录中。要做到这一点，需启用邮件日志记录（有关 MTA 的详细说明，请参阅“第三部分：服务日志（MTA）”）。然后应查看 /server-root/msg-instance/log/imta/ 目录中的 mail.log_current 文件。可根据邮件 ID 跟踪一个特定邮件，以证实该邮件确放置在 MTA 邮件队列的子目录中。如果找不到该邮件，可能是文件磁盘空间或目录权限出现问题。


检查关键文件的所有权

在安装 iPlanet Messaging Server 时，应当已经选择了一个邮件服务器用户帐户（默认 nobody）。下列目录、子目录和文件应属于此帐户：

/server-root/msg-instance/imta/queue/
/server-root/msg-instance/log/imta/
/service-root/msg-instance/imta/tmp

如下面 UNIX 系统示例中那样的命令可用于检查这些目录的保护和所有权：
ls -l -p -d /usr/iplanet/server5/msg-budgie/imta/queue
drwx------ 6 nobody bin 512 Feb 7 09:32 /usr/iplanet/server5/msg-budgie/imta/queue

ls -l -p -d /usr/iplanet/server5/msg-budgie/log/imta
drwx------ 2 nobody bin 1536 Mar 10 09:00 /usr/iplanet/server5/msg-budgie/log/imta

ls -l -p -d /usr/iplanet/server5/msg-budgie/imta/tmp
drwx------ 2 nobody bin 512 Feb 7 10:00 /usr/iplanet/server5/msg-budgie/imta/tmp

使用如下面 UNIX 系统示例中那样的命令检查确认 /server-root/msg-instance/imta/queue 中的文件属于 MTA 帐户：
ls -l -p -R /usr/iplanet/server5/msg-budgie/imta/queue


检查确认作业控制器和 dispatcher 的运行状态

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

有些 MTA 通道，如 MTA 的多线程 SMTP 通道，包含处理进入邮件的驻留服务器进程。这些服务器为通道处理从属（进入）目录。MTA dispatcher 处理这样的 MTA 服务器的创建。dispatcher 配置选项控制服务器的有效性，已创建服务器的数量以及每个服务器可处理的连接的个数。

要检查确认作业控制器和 dispatcher 的存在和 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/iplanet/
  server5/bin/msg/imta/bin/tcp_smtp_server

mailsrv 6573  S  18112   5720 Jul_13      0:00 /opt/iplanet/
  server5/bin/msg/imta/bin/job_controller

mailsrv 9568 S  18416   9432   02:00:02   0:00 /opt/iplanet/
  server5/bin/msg/imta/bin/tcp_smtp_server

mailsrv 6574 S  17848   5328   Jul_13     0:00 /opt/iplanet/
  server5/bin/msg/imta/bin/dispatcher

如果作业控制器不存在，于， /server-root/msg-instance/imta/queue 目录中的文件将得以备份，邮件也不会被传递。如果没有 dispatcher，那么将无法接受任何 SMTP 连接。

关于 imsimta process 的详细说明，请参阅 iPlanet Messaging Server Reference Manual。

如果作业控制器和 dispatcher 都不存在，应查看/server-root/msg-instance/log/imta/ 目录中的 dispatcher.log-* 文件或 job_controller.log-* 文件。

如果日志文件不存在或没指示有错误，则需通过使用 imsimta start 命令启动进程。详细信息，请参阅 iPlanet Messaging Server Reference Manual 的文件“MTA 命令行实用程序”一章。

备注： 在运行 imsimta process 时，不应有 Dispatcher 或作业控制器的多重实例。



检查日志文件

如果 MTA 处理作业运行正常而邮件却停留在邮件队列目录中，可检查日志文件确定问题所在。所有 MTA 日志文件均创建在 /server-root/msg-instance/log/imta 目录中。各种 MTA 处理作业的日志文件名格式见表 14-1。

表 14-1 MTA 日志文件


文件名

日志文件内容

channel_master.log-uniqueid

通道的主程序输出（通常为客户机）

channel_slave.log-uniqueid

通道的从属程序输出（通常为服务器）

dispatcher.log-uniqueid

Dispatcher 调试。不管 Dispatcher 的 DEBUG 选项是否已设置，都将创建此日志。尽管如此，若想得到详细的调试信息，还是需将 DEBUG 选项设置为一个非零值。

imta

ims-ms 在传递有误处的通道出错信息。

job_controller.log-uniqueid

作业控制器日志记录。不管作业控制器的 DEBUG 选项是否已设置，都将创建此日志。尽管如此，若想得到详细的调试信息，还是需将 DEBUG 选项设置为一个非零值。

tcp_smtp_server.log-uniqueid

tcp_smtp_server. 调试。此日志中的信息只针对服务器，而不针对邮件。

return.log-uniqueid

针对定期 MTA 退回作业的调试输出；如果 return_debug 选项用于 option.dat，则创建此日志。


备注： 每个日志文件在创建时都有唯一的 ID（uniqueid）以防覆盖用同一通道创建的早期日志文件。要找到特定的日志文件，可使用 imsimta view 实用程序。还可通过使用 imsimta purge 命令清除旧的日志文件。详细信息，请参阅 iPlanet Messaging Server Reference Manual 中的“MTA 命令行实用程序”一章。


channel _master.log-uniqueid 和 channel _slave.log-uniqueid 的日志文件将在下列任何一种情况下创建：

有关调试通道主代理和从属程序的详细说明，请参阅 iPlanet Messaging Server Reference Manual。


手工运行通道程序

在诊断 MTA 传递问题时，手工运行一个 MTA 传递任务是很有用的，特别是在为一个或多个通道启用了调试功能之后。

imsimta submit 命令会通知 MTA 作业控制器运行通道。如果为有问题的通道启用了调试功能，imsimta submit 将在/server-root/msg-instance/log/imta 目录下生成一个日志文件，如表 14-1 所示。

imsimta run 命令将为当前活动进程下的通道执行输出指向终端机的出站传递。这可能比提交一个任务更简便，尤其在问题可能存在于任务提交本身时。

备注： 为了手工运行通道，作业控制器必须处于运行状态。


有关 imsimta submit 和 imsimta run 命令的语法、选项、参数和示例的信息，请参阅 iPlanet Messaging Server Reference Manual 一章中的“MTA 命令行实用程序”。


启动和停止单个通道

在某些情况下，停止和启动单个通道也许会使邮件队列问题更容易诊断和调试。停止邮件队列能检查列队邮件，以确定是否有循环或垃圾邮件攻击的存在。


停止一个特定通道的出站处理（出队）

  1. 使用 imsimta qm stop 命令停止一个特定通道。这样做可不必停止作业控制器，也不必重新编译配置。在下面的例子中，conversion 通道被停止：

    imsimta qm stop conversion

  2. 要继续执行处理，需使用 imsimta qm start 命令重新启动通道。在下面的例子中，conversion 通道被启动：

    imsimta qm start conversion

有关 imsimta qm start 和 imsimta qm stop 命令的详细说明，请参阅 iPlanet Messaging Server Reference Manual 中关于 MTA 命令行实用程序的那一章。


停止来自特定域或 IP 地址（入列到一通道的）的入站处理

在将临时 SMTP 的错误返回客户主机时，若想停止针对一个特定域或 IP 地址的入站邮件处理，可运行下列程序之一。这样邮件将不会保留在系统内。请参阅“第一部分：映射表”。

若要重新启动来自域或 IP 地址的入站处理，需确保将这些规则从映射表中移出并重新编译配置。此外，您可能希望为每个映射表创建唯一的出错信息。这样做可以确定正在使用的是哪个映射表。


MTA 故障诊断实例

本节介绍如何一步一步地对特定的 MTA 问题进行故障诊断。在本例中，收件人没有收到邮件的附件。注意：为了和 MIME 协议术语保持一致，本节中将“附件”称为“邮件部分”。上述故障诊断技术用于识别邮件部分在何处和为何消失。（请参阅“标准 MTA 故障诊断程序”）。通过使用下列步骤，可确定邮件通过 MTA 的路径。此外，也可确定邮件部分是在邮件进入邮件队列之前还是之后消失的。要做到这一点，需以手动方式停止和运行通道，捕获相关文件。

备注： 用手动方式启动的邮件通过通道时，必须运行作业控制器。



识别邮件路径中的通道

通过识别邮件路径中有那些通道，可将 master_debug 和 slave_debug 两个关键字用于相应的通道。这些关键字在通道的主日志文件和从属日志文件中生成调试输出；而主程序和从属程序的调试信息又反过来有助于识别邮件部分的消失点。

  1. 把 log_message_id=1 添加到 /server-root/msg-instance/imta/config. 目录下的 option.dat 文件中。使用这个参数，就可以查看邮件 ID：在 mail.log_current 文件中的标题行。

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

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

  4. 让最终用户重发带邮件部分的邮件。

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

    尽管有不同方法识别通道，建议使用如下方法：

    1. 在 UNIX 平台上，用 grep 命令查找邮件 ID：在目录 /server-root/msg-instance/log/imta/ 中的 mail.log_current 文件中的标题行。在 Windows NT 平台上，使用 find 命令。

    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. 在 /server-root/msg-instance/imta/config 目录下的 option.dat 文件中设置 mm_debug=5，以提供详实的调试信息。

  2. 把 slave_debug 和 master_debug 这两个关键字添加到 /server-root/msg-instance/imta/config 目录下的 imta.cnf 文件中的相应通道中。

    1. 从发送带有邮件部分的邮件的远程系统将 slave_debug 关键字用于入站通道（或邮件在初始会对话过程中切换到的任何通道）上。在此例中，slave_debug 关键字被添加到 tcp_local 通道。

    2. 把 master_debug 关键字添加到其他邮件经过并在“识别邮件路径中的通道”被识别的通道上。在此例中，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

      邮件文件通常驻留在类似于
      /server-root/msg-instance/imta/queue/destination_channel/001 等目录中。destination_channel 是邮件要通过的下一个通道（例如：tcp_intranet）。如果希望在 destination_channel 目录中创建子目录（如 001，002 等），需将关键字 subdirs 添加到通道。

    2. 建议每次捕获和复制邮件时利用扩展名对邮件进行编号，以便识别邮件处理的顺序。

  6. 重新执行通道中邮件处理，并入队到下一个邮件路径的目标通道。要实现此步骤，需使用 imsimta qm start 命令。

  7. 复制并保存相关通道的日志文件（例如：tcp_intranet_master.log-*），日志文件位于 /server-root/msg-instance/log/imta/. 目录下。选择具备所跟踪邮件数据的适当的日志文件。确保所复制的文件与邮件进入通道时的时间戳和主题标题相匹配。以 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. 将 slave_debug 和 master_debug 关键字从 /server-root/msg-instance/imta/config 目录下 imta.cnf 文件中的相应通道中移除。

    2. 重新设置 mm_debug=0, 并将 /server-root/msg-instance/imta/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 记录

    所有文件都应具有与邮件 ID 相匹配的时间戳和邮件 ID 值：mail.log_current 记录中的标题行。注意当邮件退回发件人时例外，这些退回的邮件会具有与原邮件不同的邮件 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。假设它是一个 iPlanet Messaging Server MTA，则应重复整个故障诊断过程。（请参阅“识别邮件路径中的通道”，“手工启动和停止通道以收集数据”，和本节）如果那个 MTA 不在管理范围内，那么报告问题的用户应与该特定网站联系。


常见 MTA 问题和解决方案

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


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

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

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

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

  3. 重新创建任何客户连接


MTA 可发送外发的邮件但不接收入站邮件

大多数 MTA 通道依靠从属程序（或称通道程序）接收入站邮件。有关 MTA 支持的一些传输协议（比如 TCP/IP 和 UUCP），应确保传输协议激活 MTA 从属程序而不是它的标准服务器。将自带的 sendmail SMTP 服务器替换为 MTA SMTP 服务器作为 iPlanet Messaging Server 安装的一部分来执行。详细信息，请参阅针对 UNIX 的 iPlanet Messaging Server Installation Guide。

对于多线程 SMTP 服务器来说，SMTP 服务器的启动受 Dispatcher 控制的。如果 Dispatcher 配置使用的 MIN_PROCS 值大于或等于 SMTP 服务的那个值，那么总应有至少一个 SMTP 服务器进程在运行（可能更多，这取决于 SMTP 服务的 MAX_PROCS 值）。imsimta process 命令也可用于检查 SMTP 服务器进程的存在。详细说明，请参阅 iPlanet Messaging Server Reference Manual 中关于 MTA 命令行实用程序一章。


外来 SMTP 连接超时

外来 SMTP 连接超时常常与系统资源及其分配相关。下列技术可用语识别外来 SMTP 连接超时的原因：

  1. 检查可允许多少外来 SMTP 连接同时存在。这是由 MAX_PROCS 和 MAX_CONNS 这两个 SMTP 服务的 dispatcher 设置控制的；允许同时存在的连接数量即为 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 (iPlanet Messaging Server 5.1 (built May 7 2001))

    如果已连接上并接收了一个 220 标志区，但附加命令（如 ehlo 和邮件发件人）没有响应，那么应运行 imsimta test -rewrite 以保证配置正确。若正在使用 imsimta dirsync 命令，应确保此命令最近运行过。有些情况下，假设 dirsync 失败，SMTP 服务器中的命令不接收响应。在这种情况下，只要首先移除 dirsync 锁定文件，运行 imsimta dirsync -F 就会解决问题。

  3. 如果 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 服务器不得不执行不必要的查找。

  4. 也可将 slave_debug 关键字放置在处理跨越 TCP/IP 的外来 SMTP 邮件的通道上，通常就是 tcp_local 和 tcp_intranet。这样做之后，查看最新的 tcp_local_slave.log-uniqueid 文件以识别超时邮件的任何特殊特征。例如，若带有大量收件人的来件超时，可考虑在通道上使用 expandlimit 关键字。

记住，如果系统超过负荷并过度扩展，超时是难以完全避免的。


邮件未入队

在 TCP/IP 传递中遇到的错误通常是瞬时的； MTA 在遇到问题时一般会保留邮件并定期重试。在某些主机上经历周期性中断的同时其他主机连接工作良好，这对于大型网络是很常见的。要想验证此问题，需检查日志文件中与传递尝试相关的错误。可看到诸如“Fatal error from 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 信息，除非明确配置不这样做。还可参阅“TCP/IP MX 记录支持”。

  2. 在此例中，DNS（域名服务）返回 xtel.co.uk 的指定 MX 转发的名称。这是 MTA 实际连接的主机。如果列出不止一个 MX 转发，MTA 会依次尝试每个 MX 记录，最先尝试带有最小的首选值的记录。

  3. 如果确实已连接到远程主机，则应检查该主机是否通过使用 TELNET 接受入站 SMTP 连接到 SMTP 服务器端口 25。
    备注： 如果在没有指定端口的情况下使用 TELNET，将发现远程主机接受普通的 TELNET 连接。这并不表明该主机也接受 SMTP 连接；很多系统都接受常规的 TELNET 连接但却拒绝接受 SMTP 连接，反之亦然。因此，应对 SMTP 端口进行不可缺省的测试。


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

如果在不使用 DNS 的 TCP/IP 网络上运行 iPlanet Messaging Server，可省略步骤（1）和（2）。作为替代，可使用 TELNET 直接访问有问题的主机。注意应使用与 MTA 所用相同的主机名。查看从 MTA 最后一次尝试开始的相关日志文件以确定主机名。如果正在使用主机文件，则应确保主机名信息是正确的。我们强烈建议您使用 DNS 而不是主机名。

注意如果在使用交互式测试检测 TCP/IP 主机连通性时没有遇到问题，那么很可能在 MTA 的最后尝试传递邮件的过程中问题就已经解决了。可在适当通道上重新运行 imsimta submit tcp_channel 以查看邮件是否正在出队。


MTA 邮件未传递

除了邮件传输问题，还有两个常见可造成邮件队列邮件不被处理的问题：

  1. 队列缓存与队列目录中的邮件不同步。等待传递的 MTA 队列子目录中的邮件文件被输入到内存中的队列缓存中。通道程序在运行时会参考这个队列缓存来确定要传递队列中的哪些邮件。也会有这样的情况：队列中有邮件文件，但却没有相应的队列缓存条目。

    1. 要检查证实一特定文件是否存在于队列缓存中，可使用 imsimta cache -view 实用程序；如果文件不在队列缓存中，那么队列缓存就需要进行同步。

      队列缓存通常每四个小时同步一次。如有必要，可使用 imsimta cache -sync. 命令手工重新同步缓存。一经同步，通道程序就会在处理完新邮件之后处理原先未处理的邮件。如果希望更改默认同步间隔时间（4 小时），则应修改
      /server-root/msg-instance/imta/config 目录下的 job_controller.cnf 文件，在文件中添加 sync_time=timeperiod，其中 timeperiod 反映了进行队列缓存同步的频度。注意 timeperiod 必须大于 30 分钟。在下面的例子中，通过把 sync_time=02:00 添加到 job_controller.cnf 中的 global defaults（全局默认设置）节，队列缓存间隔时间被修改为 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 cache -sync 后运行 imsimta submit channel 清除待处理邮件。请注意如果待处理邮件过大（大于 1000）的话，清除过程可能需要较长时间，这一点很重要。

      要获取队列缓存的概括信息，可运行imsimta qm -maint dir -database -total。

    2. 如果在将队列缓存同步后，邮件仍未传递，则应重新启动作业控制器。这就需要运行 imsimta restart job_controller 命令。

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

      注意：

      		重新启动作业控制器是一较极端的步骤，应在所有其他方法全部试过无效之后方可执行。


      有关作业控制器的详细说明，请参阅“作业控制器”。

  2. 由于不能创建其处理日志文件，通道处理程序无法运行。请查看访问权限，磁盘空间和配额。


循环邮件

如果 MTA 检测出一邮件是循环的，该邮件将被退出作为 .HELD 文件。请参阅“诊断和清理 .HELD 邮件”。某些情况可导致产生 MTA 无法检测的邮件循环。

第一步是确定邮件为何循环。应当在有问题邮件文件还在 MTA 队列区域时查看该文件的一个副本，查看与有问题邮件相关的 MTA 邮件日志条目（如果在有问题通道的 MTA 通道配置文件中启用了 logging 通道关键字的话），以及查看有问题通道的 MTA 通道调试日志文件。确定有问题邮件的发件人：和收件人：地址，查看收件箱：标题行，并查看邮件结构（邮件内容封装类型），均可帮助查明所遇到的邮件循环属于哪种类型。

一些更常见的情况包括：

  1. Postmaster 地址损坏

    MTA 要求 Postmaster 地址是一个可接收邮件的功能地址。如果发送给邮件管理员的邮件是循环的，需查看配置中是否具有一个指向可接收邮件的帐户的正确 Postmaster 地址。

  2. 剥离收件箱：标题行是为了防止 MTA 检测循环邮件。

    常规邮件循环的检测是基于收件箱标题行的。如果收件箱标题行被剥离（显式地针对 MTA 系统自身，或针对类似与防火墙的另一系统），则会干扰邮件循环的正确检测。在这些情况下，需检查是否有不希望的收件箱标题行剥离的发生。还要检查邮件发生循环的深层原因。可能的原因包括：系统名分配问题或系统未配置为能辨识其自有名称的变体，DNS 问题，有问题系统缺少可靠的地址信息，用户地址转发错误等。

  3. 其他邮件系统对通知邮件的错误处理正在生成再包装邮件以响应通知邮件。

    Internet 标准要求通知邮件（正在传递或退回邮件的报告）具有一个空的信封发件人：地址以防邮件循环。然而，一些邮件系统没有正确处理这样的通知邮件。在转发或退回通知邮件时，这些邮件系统可能会插入一个新的信封发件人：地址。这就会导致邮件循环。解决方法是修正错误处理通知邮件的那个邮件系统。


诊断和清理 .HELD 邮件

如果 MTA 检测出邮件在服务器和通道之间正进行退回处理，传送将被暂停，邮件将被储存在 /server-root/msg-instance/imta/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 邮件：

  1. 将扩展名 .HELD 重命名为除 00 外的任意两个数字。例如，把 .HELD 改成 .06。
    备注： 在重命名 .HELD 文件前，确定邮件已经停止循环。


  2. 运行 imsimta cache -sync。运行这一命令可以更新缓存。

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

也许要重复执行这些步骤，因为邮件有可能再次被标记为 .HELD，原因是收件箱：标题行的累积。


接收的邮件为编码邮件

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 读取时，这些邮件在显示时为未编码邮件。有关详情，请参阅 iPlanet Messaging Server Reference Manual。

RFC 821 规定，SMTP 协议只允许 ASCII 字符（一种七位字符集）的传输。事实上，在未经协调的情况下通过 SMTP 传输八位字符是非法的，并且都知道会给 SMTP 服务器带来一系列问题。例如，SMTP 服务器可能产生计算限制循环。邮件会一遍一遍地被发送。八位字符可以使 SMTP 服务器崩溃。最后，八位字符集将使不能处理八位字符数据的浏览器和邮箱崩溃。

过去，SMTP 客户在处理包含八位数据的邮件时只有三种选择：将其作为无法传递邮件退回发件人，将邮件编码，或者将其发送造成对 RFC 821 的直接违规。但是有了 MIME 和对 SMTP 的扩展，现在有标准编码方法，可以用来利用 ASCII 字符集给八位数据编码。

在上面的例子中，收件人接收到一个其 MIME 内容类型为 TEXT/PLAIN 的编码邮件。远程 SMTP 服务器（MTA SMTP 客户机向其传输邮件）不支持八位数据的传输。由于原邮件包含八位字符，MTA 不得不对邮件进行编码。


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

一过滤器是由一个或多个应用于邮件的条件操作组成的。由于过滤器是在服务器上储存和检测的，因而常常被称为服务器端规则（SSR）。

目录同步命令（imsimta dirsync）用有关用户过滤器的信息更新 MTA 的 SSR 数据库。SSR 数据库存放短过滤器（小于 1016 字节）而一个 LDAP DN 则用于长过滤器。请注意，只有在 imsimta dirsync 命令更新了目录服务器之后，MTA 才能识别用户过滤器的更改。有关 SSR 的详细说明，请参阅“第二部分：邮箱过滤器”。

这一部分包括有关以下 SSR 主题的信息：


测试 SSR 规则


故障诊断程序

在诊断 SSR 问题时一定要遵循下列程序：


常见语法问题


一般出错讯息

MTA 不能启动时，一般出错讯息出现在命令行上。在这部分中介绍和诊断一般出错讯息。
备注： 要诊断 MTA 配置须，使用 imsimta test -rewrite -debug 实用程序来检查 MTA 的地址重写和通道映射处理。使用这一实用程序可以在不发送邮件的情况下检查配置。请参阅“检查 MTA 配置”。


MTA 的副组件也可能导致本章中没有介绍的出错讯息的产生。请参阅 iPlanet Messaging Server Reference Manual 中有关 MTA 命令行实用程序和配置的章节，有关各个副组件的详细说明，参见第 6 篇到第 10 篇各章。这章包括下列出错类型：


mm_init 中的错误

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

常见的 mm_init 错误包括：


错误别名等价

别名文件条目的右侧格式错误。


不能打开别名文件

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


发现重复别名

两个别名文件条目左侧一样。须找到并取消复制。寻找如下出错讯息：error line #XXX 其中 XXX 是行号。修正这一行上的重复别名。


在通道表里的重复主机

出错讯息说明 MTA 配置有两个正式主机名相同的通道定义。

注意，MTA 配置文件（imta.cnf）中的重写规则（上半部分）里的多余的空行可使 MTA 把配置文件的剩余部分视为通道定义。一定要保证文件的第一行不是空行。因为很多重写规则有相同的模式（左侧），MTA 据此把它们视为有着非唯一正式主机名的通道定义。检查 MTA 配置，看是否存在任何有重复正式主机名的通道定义以及文件上半（重写规则）部分是否有不正确的空行。


发现重复映射名

这个讯息说明两个映射表有相同的名称，其中一个重复映射表应移除。但是映射表中的格式错误有可能使 MTA 把别的内容误认为是映射表名。例如，对映射表条目的错误缩排会让 MTA 认为条目左侧其实是映射表名。检查映射文件的一般格式和映射表名。

备注： 应以一空行打头，后随任何带映射表名的行。但是映射表条目之间不得有任何空行。



映射名过长

这个错误表示映射名太长应该缩短。映射文件格式错误可能会使 MTA 把其他内容误认为是映射表名。例如，对映射表条目的错误缩排会让 MTA 认为条目左侧其实是映射表名。检查映射文件和映射表名。


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

这一讯息说明，需要用命令 imsimta chbuild. 重新编译并重新安装编译的字符集表。有关详情，请参阅 iPlanet Messaging Server Reference Manual。


初始化 ch_facility 时出错：无空间

这一出错讯息一般表示需调整 MTA 字符集内部表的大小然后重建编译的字符集表，需使用的命令如下：

imsimta chbuild -noimage -maximum -option
imsimta chbuild

请核实，进行此更改之前没有重新编译或重新启动任何别的内容。参考 iPlanet Messaging Server Reference Manual 中“MTA 命令行实用程序”一章可获得更多的关于 imsimta chbuild 的信息。


本地主机别名或固有名称对系统过长

这一错误说明本地主机别名或固有名称太长（在一通道块的第二个及随后的名称中的可选右侧）。但是 MTA 配置文件里早先的一些语法错误（比如重写规则里的多余的空行）可能使 MTA 把其它内容误认为是通道定义。除了检查配置文件里所提到的那行外，也要检查这一行以上的内容以便找到其他语法错误。特别是当 MTA 发现错误的那一行原本是一条重写规则时，一定要检查在它上面是否有多余的空行。


别名没有等价地址

别名文件的条目没有右侧（翻译值）部分。


通道没有正式主机名

这一错误说明，一通道定义块缺少必需的第二行（正式主机名行）。有关通道定义块的详细信息，请见 iPlanet Messaging Server Reference Manual 和第 8 篇 “配置通道定义”中的有关MTA 配置和命令行实用程序的章节。每个通道定义块的前后都必需有一空行。但是在块通道名和通道定义的正式主机名行之间不能出现空行。还要注意，MTA 配置文件的重写规则部分不允许有空行。


正式主机名过长

通道的正式主机名（通道定义块的第二行）长度限制在四十字节内。如想让通道的正式主机名超过这个长度，把它缩短成一个占位名称，然后用重写规则使长名称和短正式名称匹配。这种情况在处理 l（本地）通道主机名时可能出现。例如：

原始通道 1：
!delivery channel to local /var/mail store
l subdirs 20 viaaliasrequired maxjobs 7 pool LOCAL_POOL
newt.salamander.lizard.gecko.komododragon.com

创建占位名：
!delivery channel to local /var/mail store
l subdirs 20 viaaliasrequired maxjobs 7 pool LOCAL_POOL
newt

创建重写规则：
newt.salamander.lizard.gecko.komododragon.com   $U%$D@newt

注意，当使用 l（本地）通道时，需要使用反向映射表。有关用法和语法的信息，请参阅 iPlanet Messaging Server Reference Manual 中的“MTA 配置”一章。

MTA 配置文件中早期的一些语法错误（例如，重写规则里多余的空行）可能使 MTA 把其他内容误认成通道定义。这可能导致一原本为重写规则的文本被误认成正式主机名。除了检查配置文件里所提到的那行外，也要检查这一行以上的内容以便找到其他语法错误。特别是当 MTA 发现错误的那一行原本是一条重写规则时，一定要检查在它上面是否有多余的空行。


编译的配置版本不匹配

imsimta cnbuild 实用程序的功能之一就是把 MTA 配置信息编译成可以快速装载的图像。编译格式定义得十分严格并且在不同的 MTA 版本之间经常更改。小的更改可能作为补丁版的一部分出现。

当进行这种更改时，一内部版本字段也被更改，以便检测出不相容的格式。当检测出不相容格式时，MTA 组件就会中断并显示上面的错误。解决这个问题的办法就是用命令 imsimta cnbuild 生成一个新的编译的配置。

另一个不错的办法是用 imsimta restart 命令来重新启动任何驻留的 MTA 服务器进程，这些进程即可获取更新了的配置信息。


交换空间错误

为了确保正确操作，应在邮件传输系统上配置足够的交换空间。配置不同，必需的交换空间大小也不同。一个一般适用的建议是：交换空间至少应为主要内存的三倍。

下面的出错信息表明缺少交换空间：

jbc_channels: chan_execute [1]: fork failed: Not enough space

在作业控制器的日志文件可能会看到这样的出错信息。其他交换空间错误因配置不同而有所不同。

使用下列命令可以确定还剩多少交换空间和已经用了多少交换空间：


文件打开或创建错误

为了发送一封邮件，MTA 读取配置文件并在 MTA 邮件列队目录中创建邮件文件。对于 MTA 或其他用非 MTA 的 SDK 写的程序，配置文件都必须是可读的。在安装过程中，已给这些文件赋予了适当的权限。可创建配置文件的 MTA 实用程序和其他程序也赋予权限。如果文件受系统管理者、其他授权用户或通过针对站点的程序的保护，MTA 可能就不能读配置信息了。这会导致“打开文件”错误或其他无法预计的结果。在读取配置文件遇到问题时，imsimta test -rewrite 实用程序还会报告其他信息。请参见 iPlanet Messaging Server Reference Manual 的 MTA 有关章节中的 imsimta test -rewrite 说明文档。

如果 MTA 象是从授权帐户而不是从非授权帐户发挥功能，MTA 表目录中的文件权限很可能是产生问题的原因。检查配置文件及其目录的权限。请参阅“检查关键文件的所有权”。

“文件创建”错误通常表明在 MTA 邮件列队里创建邮件文件时出了问题。有关诊断文件创建问题请参见“检查邮件队列目录”。


非法主机／域错误

当地址通过浏览器提供给 MTA 时可能会出现这种错误。或者，此错误可能会作为出错退回邮件而被延迟并退回。在这两种情况下，这种出错讯息都表明 MTA 不能把邮件传递给指定的主机。要确定邮件为何不能送到特定的主机，需要遵循下面的故障诊断程序：


SMTP 通道中的错误：os_smtp_* errors

下列错误不一定是 MTA 错误：如 os_smtp_open，os_smtp_read 以及 os_smtp_write 这样的 os_smtp_* 错误。这些错误是在 MTA 报告在网络层遇到问题时生成的。例如，os_smtp_open 错误意味着网络对远程端的连接无法打开。由于地址错误或通道配置错误，MTA 可能被配置成与一个无效系统连接。os_smtp_* 错误通常是由于 DNS 或网络连接问题引起的，尤其是这是先前使用的通道或地址时。os_smtp_read 或 os_smtp_write 错误通常表明连接被另一端中止或网络引起了问题。

网络和 DNS 问题的本质常常是瞬时性的。偶然出现的 os_smtp_* 错误一般不用太担心。但是如果这些错误常常出现，这可能说明存在一潜在的网络问题。

要获取有关特定 os_smtp_* 错误的详细说明，可以启用有问题通道上的调试功能。查看调试通道的日志文件，可以显示有关 SMTP 对话的详细内容。尤其要查看 SMTP 对话过程中网络问题出现的时间。这个时间可能暗示网络问题或远程端问题。在某些情况下，可能还需要进行网络层调试（例如 TCP/IP 信息包跟踪），以确定发送和接收了什么。


上一页    目录    索引    下一页
(c) 2002 年 Sun Microsystems, Inc. 版权所有。

更新日期：2002 年 2 月 27 日