test

Sun Java System Messaging Server 6.3 管理指南

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 字符）并用星号代替这些字符。