![为什么 postfix/smtpd DNS 查找会失败?](https://linux22.com/image/201989/%E4%B8%BA%E4%BB%80%E4%B9%88%20postfix%2Fsmtpd%20DNS%20%E6%9F%A5%E6%89%BE%E4%BC%9A%E5%A4%B1%E8%B4%A5%EF%BC%9F.png)
我正在准备替换已有 2 年历史的邮件服务器 — Debian 上的 Postfix。变化是:
- amd64 → ARM64
- Debian 10.2 → 11.2
- 后缀 3.4.7 → 3.5.6
配置保持不变。
当我尝试手动(使用telnet
)将电子邮件传递到新服务器时,它无法查找发件人的主机名:
postfix/smtpd[146]: lookup gmail.com type A flags
postfix/smtpd[146]: dns_query: gmail.com (A): Host not found, try again
postfix/smtpd[146]: lookup gmail.com type AAAA flags
postfix/smtpd[146]: dns_query: gmail.com (AAAA): Host not found, try again
postfix/smtpd[146]: lookup gmail.com type MX flags
postfix/smtpd[146]: dns_query: gmail.com (MX): Host not found, try again
旧服务器做得很好:
postfix/smtpd[5554]: lookup gmail.com type A flags
postfix/smtpd[5554]: dns_query: gmail.com (A): OK
postfix/smtpd[5554]: dns_query: reply len=43 ancount=1 nscount=0
postfix/smtpd[5554]: dns_get_answer: type A for gmail.com
sudo -s -u postfix dig +short mx gmail.com
在两台服务器上都运行良好。
两台服务器上的输出postconf | grep dns
相同。亦是如此/etc/resolv.conf
。
新的可能有什么问题?还可以调试什么来找出它?
/etc/resolv.conf
:
options timeout:2 attempts:5
; generated by /usr/sbin/dhclient-script
search us-west-2.compute.internal
nameserver 172.31.0.2
postconf | grep dns
:
disable_dns_lookups = no
dns_ncache_ttl_fix_enable = no
dnsblog_reply_delay = 0s
dnsblog_service_name = dnsblog
lmtp_dns_reply_filter =
lmtp_dns_resolver_options =
lmtp_dns_support_level =
lmtp_host_lookup = dns
postscreen_dnsbl_action = ignore
postscreen_dnsbl_max_ttl = ${postscreen_dnsbl_ttl?{$postscreen_dnsbl_ttl}:{1}}h
postscreen_dnsbl_min_ttl = 60s
postscreen_dnsbl_reply_map =
postscreen_dnsbl_sites =
postscreen_dnsbl_threshold = 1
postscreen_dnsbl_timeout = 10s
postscreen_dnsbl_whitelist_threshold = 0
smtp_dns_reply_filter =
smtp_dns_resolver_options =
smtp_dns_support_level =
smtp_host_lookup = dns
smtpd_dns_reply_filter =
如果这是相关的,那么“服务器”实际上是supervisor
作为主命令运行的 docker 容器,而主命令又/usr/sbin/postfix -c /etc/postfix start-fg
作为托管进程之一运行。
答案1
Postfix 默认以 chroot 运行。它一无所知/etc/resolv.conf
,而是寻找/var/spool/postfix/etc/resolv.conf
。除非有什么东西在那里创造它,否则它不会在那里。
要快速解决眼前的问题,只需:
cp /etc/resolv.conf /var/spool/postfix/etc/
在 Debian 上,这是通过运行/usr/lib/postfix/configure-instance.sh
from自动完成的/etc/init.d/postfix
- 当 Postfix 服务启动/停止等时依次执行。
在 docker 容器中,除非明确执行,否则不会执行任何操作。简单地运行该命令/usr/sbin/postfix -c /etc/postfix start-fg
并不能解决问题——它只是启动 Postfix,它看不到resolv.conf
.
为了正确起见,Postfix 可以运行为:
/bin/bash -c "/usr/lib/postfix/configure-instance.sh - && /usr/sbin/postfix -c /etc/postfix start-fg"
或者,Postfix 可以配置为正常运行,即非 chroot。这是一个安全考虑——即使在 Docker 容器中,如果有一些东西需要隐藏以防止恶意 SMTP 攻击,例如邮件存储。