最近几天,我们的托管服务提供商偶尔会遇到与上游的连接问题。每次发生这种情况时,我们都会收到一大堆发往外发的电子邮件,而 Sendmail 无法处理这些邮件。
550 5.1.2 <*********@hotmail.com>... Host unknown (Name server: hotmail-com.olc.protection.outlook.com.: host not found)
Final-Recipient: RFC822; *********@hotmail.com
Action: failed
Status: 5.1.2
Remote-MTA: DNS; hotmail-com.olc.protection.outlook.com
Last-Attempt-Date: Tue, 17 Nov 2020 04:44:51 +0100
我首先想到的可能是我们从上游 DNS 服务器获取了 NXDOMAIN,这导致 Sendmail 将错误视为永久性错误。因此,我改为使用 9.9.9.9 而不是托管提供商 DNS 服务器。一夜之间,他们在重新启动 BGP 会话时又出现了短暂中断,同样的事情再次发生。
有人知道这里发生了什么吗?预期的行为是什么?我试过搜索,但也许我还没有找到正确的搜索内容。
在我看来,当出现 DNS 连接问题时,明智的做法是将电子邮件放入队列中以便稍后重试,就像与远程服务器通信时出现问题(临时电子邮件或连接问题)一样。这似乎也是 RFC 5321 所指定的。
所以,我的理解是:如果域不存在(NXDOMAIN),则视为永久失败并放弃。如果 DNS 没有响应,或者 DNS 服务器发生故障(SERVFAIL),则重新排队。
我不确定这真的是 DNS 问题还是 Sendmail 问题。我找不到任何相关的解析器设置,所以我猜想如果这不是默认设置,Sendmail 需要配置为在找不到主机时重试。
有问题的服务器在 CentOS 7.9.2009 上运行 sendmail-8.14.7-6.el7.x86_64
知道发生什么事了吗?
尽管我们的大多数用户都使用 Gmail,但这些问题似乎只会影响由 charter.net 或 Microsoft 托管的收件人域。
下面每行开头的数字是该域的失败次数。
73 Host unknown (Name server: hotmail-com.olc.protection.outlook.com.: host not found)
10 Host unknown (Name server: pkvw-mx.msg.pkvw.co.charter.net.: host not found)
8 Host unknown (Name server: msn-com.olc.protection.outlook.com.: host not found)
6 Host unknown (Name server: live-com.olc.protection.outlook.com.: host not found)
4 Host unknown (Name server: outlook-com.olc.protection.outlook.com.: host not found)
示例的完整日志:
Nov 17 04:46:26 llama sendmail[19358]: 0AH3kQNO019355: to=<*********@hotmail.com>, delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=133505, relay=hotmail-com.olc.protection.outlook.com., dsn=5.1.2, stat=Host unkno
wn (Name server: hotmail-com.olc.protection.outlook.com.: host not found)
Nov 17 04:46:26 llama sendmail[19358]: 0AH3kQNO019355: 0AH3kQNN019358: DSN: Host unknown (Name server: hotmail-com.olc.protection.outlook.com.: host not found)
答案1
RFC 3463表示这种特殊情况是永久性失败:
X.1.2 Bad destination system address
The destination system specified in the address does not exist
or is incapable of accepting mail. For Internet mail names,
this means the address portion to the right of the "@" is
invalid for mail. This code is only useful for permanent
failures.
事实上,邮件服务器无法知道 DNS 解析失败是暂时的,如果在一段时间后重试,解析会成功,而不是用户输入错误,这是最常见的情况。用户是否应该等待五天才能发现他们拼错了域名?此外,这种 DNS 问题不应该被隐藏;相反,应该尽快调查并(如果确实是问题)修复。