我注意到我的 postfix SMTP 事务似乎在中间暂停了 3 秒钟。查看我的 SMTP 跟踪日志时，我看到以下内容：
2021-03-17 00:19:54,869 TRACE SmtpClientImpl - wrote MAIL FROM <foo@...>
2021-03-17 00:19:54,869 TRACE SmtpClientImpl - read MAIL FROM response 250 2.1.0 Ok
2021-03-17 00:19:54,869 TRACE SmtpClientImpl - wrote RCPT TO <bar@...>
--- NOTE: ~3 second gap here ---
2021-03-17 00:19:57,871 INFO SmtpHandler - 38:1615954066423: rcpt address foo@...
2021-03-17 00:19:57,872 TRACE SmtpClientImpl - read RCPT TO response 250 2.1.5 Ok
2021-03-17 00:19:57,872 TRACE SmtpClientImpl - wrote DATA start
2021-03-17 00:19:57,872 TRACE SmtpClientImpl - read DATA response 354 End data with ...
其余一切都会在 0-3 毫秒内完成，但RCPT TO命令需要 3秒回复。
很长一段时间以来，我都认为是我的代码有问题，但现在我想知道是不是我新安装的 Postfix 配置不正确。我发现提到了一个verify进程，但我从未看到该进程在运行，我想知道它是否有问题。我还在 Postfix 文档中看到了address_verify_poll_delay(default 3s) 和的提及address_verify_poll_count，这似乎表明进程会验证地址，verify而邮件程序则会等待检查地址。
我有以下内容/etc/postfix/master.cf
verify unix - - n - 1 verify
但是，我从未看到该应用程序运行，并且address_verify_map设置指向不存在的文件。
- 知道我在这里遗漏了什么吗？
- 我应该看一个验证过程吗？
- 知道如何弄清楚为什么它无法启动吗？
- 还有其他验证可以解释这种延迟吗？
非常感谢您的帮助。
答案1
还有其他验证可以解释这种延迟吗？
也许我太专注于验证了，因为事实证明这不是问题所在。默认情况下，smtpd_client_restrictions具有以下值：
睡眠 3，reject_unauth_pipelining
这意味着在RCPT TO命令执行后，postfix 会休眠 3 秒，以查看客户端是否继续发送 SMTP 命令，这表明存在某种愚蠢的机器人。是的，postfix 很酷。我将其更改为main.cf：
permit_mynetworks, sleep 3, reject_unauth_pipelining
短路permit_mynetworks限制并删除了本地网络（包括 localhost）上连接的客户端的睡眠。我打开后发现了这一点：
debug_peer_list = 127.0.0.1
debug_peer_level = 3
这会在从本地主机连接时启用更高级别的调试。然后在 syslog 日志中我看到（以及大量其他日志行）：
Mar 17 22:02:16 postfix/smtpd[19934]: < localhost[127.0.0.1]: RCPT TO:<foo@...>
...
Mar 17 22:02:16 postfix/smtpd[19934]: >>> START Client host RESTRICTIONS <<<
Mar 17 22:02:16 postfix/smtpd[19934]: generic_checks: name=sleep
--- NOTE the 3 second delay here --- ^^^^^
Mar 17 22:02:19 postfix/smtpd[19934]: generic_checks: name=sleep status=0
Mar 17 22:02:19 postfix/smtpd[19934]: generic_checks: name=reject_unauth_pipelining
当时这是非常明显的。Postfix logsing++。