该服务器系统自 1997 年左右开始提供电子邮件服务，Red Hat v 1.1目前使用的是 Fedora Core 37；在此过程中经历了许多硬件和操作系统更新，它一直保持最新状态。而且，我们很早就选择了它们postfix，dovecot并且仍在使用它们。而我一直是系统管理员。
一周前的明天，我们的/var树因为备份脚本中的一个错误而被彻底毁掉了 - 糟糕！而且它需要完全重建操作系统，“从头开始”，到相同的版本。Fedora Server 37发行版中未包含的所有软件都是通过 重新加载的dnf install。而且，我们从良好的备份中恢复了完整的配置。
两天前的星期一，我注意到系统明显运行缓慢，但没有时间去研究它。我还注意到我们的互联网链接似乎存在性能问题。这是一个线索……
然后，我决定spamassassin重新开始工作——配置像这样的成熟环境需要时间！SA在丢失之前/var，它已被禁用，因此它不会重新启动。无论如何，当我去检查/etc/var/log/maillog它是否在工作时，我发现所有这些邮件都是中继消息？！威士忌探戈狐步舞？！
然后我检查了邮件队列——仅 Gmail 就有数十万封邮件！哇！
目前，我已关闭所有外发电子邮件：
default_transport = error: Sorry spammers, we're not sending your email! So sue us!
并开始尝试找出问题所在。
我确实发现有些程序声称是127.0.0.1，所以我关闭了它。我系统地检查了各种（和丰富的）postfix配置选项，没有发现任何错误...
因此，我去使用其中一个脚本测试开放中继测试网站，该网站尝试了十几种不同的黑客手段，垃圾邮件发送者使用这些手段说服配置良好的服务器中继他们的邮件，但我找不到任何方法 - 上次我查看时，有六个左右这样的网站！（他们怎么了？！如果你知道一个，请告诉我！）
所以我使用了nmap。它不能全面地完成工作，或者如果它可以，我不知道怎么做。但我转而发送并测试。在测试中，它说：
Host is up (0.00027s latency).
rDNS record for <ip-addr>: <reverse-lookup-map>
PORT STATE SERVICE
25/tcp open smtp
|_smtp-open-relay: Server doesn't seem to be an open relay, all tests failed
465/tcp filtered smtps
587/tcp open submission
|_smtp-open-relay: Server isn't an open relay, authentication needed
MAC Address: [its mac address] (controller's mfg name)
Nmap done: 1 IP address (1 host up) scanned in 22.03 seconds
我发现仅有的两个网站没有响应，一个已加载但没有响应，然后当我尝试重新加载页面时，它也无法重新加载，而第二个网站一直说很忙，请稍后再试。
所以...回到“手动”解决问题。
好的，那么现在我们该做什么？
所有设置信息请求都会被很乐意地满足，但是配置文件首先非常庞大，其次它包含大量我们不想泄露的私人信息。
更多信息- 应 anx 的要求，输出postconf -n：
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
compatibility_level = 3.6
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 10
debug_peer_list = <past-not-current-external-ip>
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5
default_transport = error: <our-middle-finger-to-spammers>
disable_vrfy_command = yes
html_directory = no
inet_interfaces = all
inet_protocols = all
local_recipient_maps = unix:passwd.byname $alias_maps
mail_owner = postfix
mailbox_size_limit = 1073741824
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 536870912
meta_directory = /etc/postfix
milter_default_action = accept
mydestination = $myhostname, localhost.$mydomain, localhost, <list-of-60ish-domain-names>
mydomain = <primary-domain>
myhostname = mail.<primary-domain>
mynetworks = <list-of-5-internal-ips>
mynetworks_style = subnet
newaliases_path = /usr/bin/newaliases.postfix
proxy_interfaces = <a-non-extant-external-ip-we-used-to-have>
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix/README_FILES
relay_domains = $mydestination, <list-of-11-internal-ips-most-don't-exist-now>
sample_directory = /usr/share/doc/postfix/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
shlib_directory = /usr/lib64/postfix
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_CApath = /etc/pki/tls/certs
smtp_tls_security_level = may
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, check_helo_access hash:/etc/postfix/helo_access, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unauth_destination, check_sender_access hash:/etc/postfix/sender_access, check_client_access hash:/etc/postfix/pop-before-smtp, permit_mynetworks
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = /var/spool/postfix/private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, check_client_access hash:/etc/postfix/pop-before-smtp, reject_non_fqdn_sender, reject_unknown_sender_domain
smtpd_tls_cert_file = /etc/letsencrypt/live/<primary-domain-name>/fullchain.pem
smtpd_tls_dh1024_param_file = $config_directory/dh2048.pem
smtpd_tls_dh512_param_file = $config_directory/dh512.pem
smtpd_tls_key_file = /etc/letsencrypt/live/<primary-domain-name>/privkey.pem
smtpd_tls_security_level = may
soft_bounce = no
strict_mailbox_ownership = no
unknown_local_recipient_reject_code = 550
更多信息- 大部分也是应 anx 的要求：
Postfix使用端口 25（smtp）和 587（submission或msa）。Dovecot使用端口 993 (imaps) 和 995 (pop3s)，同时监听被（多个）防火墙阻止的143 和 110 (imap/ )。pop后配置-M
smtp inet n-n--smtpd
提交 inet n - n - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes
拾音器 unix n - n 60 1 拾音器
清理 unix n - n - 0 清理
qmgr unix n - n 300 1 qmgr
tlsmgr unix--n 1000?1 tlsmgr
重写 unix - - n - - 简单重写
弹跳 unix - - n - 0 弹跳
推迟 unix - - n - 0 反弹
跟踪 unix - - n - 0 反弹
验证 unix - - n - 1 验证
刷新 unix n - n 1000? 0 刷新
代理映射 unix - - n - - 代理映射
proxywrite unix - - n - 1 proxymap
smtp unix - - n - - smtp
中继 unix - - n - - smtp -o syslog_name=postfix/$service_name
showq unix n - n - - showq
错误 unix - - n - - 错误
重试 unix - - n - - 错误
丢弃 unix - - n - - 丢弃
本地 unix-nn--本地
虚拟 unix - nn - - 虚拟
lmtp unix - - n - - lmtp
anvil unix - - n - 1 铁砧
scache unix - - n - 1 scache
postlog unix-dgram n - n - 1 postlogd
尚未获取的信息：
- “本地添加的接收头”中有什么。
- 分析给定队列 ID 的后缀日志“堆栈”。
坚持该计划！
只是必须发送几封重要的电子邮件，但又不想让垃圾邮件发送者使用我们的系统，所以我决定尝试关闭dovecot...我发现关闭dovecot并恢复default_transport设置可以让出站正常工作，并且Postfix确实不是成为开放中继！好极了！
当然，它对我们的非本地用户（数量 > 1 且 < 100）不起作用，但是，“你必须做你必须做的事......”
我认为这转移了焦点相当;dovecot才是问题所在。
答案1
我现在确信这不是一个Postfix问题，而是一个Dovecot问题。不过，这个答案可能对其他人有帮助。
Postfix特别是，对于一个已经使用同一系统（作为系统管理员）二十年甚至更长时间的人来说，如何确定它可能不是一个问题，这是一个比我预期的更大的学习曲线。
我没有意识到的是，这种配置Postfix本身就“放弃了权限控制”给Dovecot。而且，此时，Dovecot能够从我们这些不在内部网络中的人（除了我们在现场时）接收有效连接，已经成为我们运作的一个重要特征。
值得庆幸的是，对于我们来说，这不像对许多其他组织那么重要，因为我们有其他选择，但现实情况是，大多数人不想费心通过命令行登录来处理邮件 - 我怀疑这是最受欢迎的立场！ - 在这种情况下！但这并没有消除我所没有意识到的事情：
一旦配置完成，您就不能停止Dovecot，并期望能够发送而无需重新配置Postfix不使用Dovecot。而且，您甚至不能Dovecot从外部阻止端口，因为无论如何Postfix都会直接调用Dovecot！
最终，根据我的理解（很高兴被证明是错误的！）一旦配置，Postfix就会放弃几乎所有假装是有效用户的连接的安全权限Dovecot，尽管所有“内部”发送和接收功能都可以正常Dovecot运行并被Postfix阻止发送（如问题中所述）。
我认为用这个问题来询问Dovecot问题是徒劳无功和不恰当的，虽然我认为这些评论构成了一个有效的答案，但我需要问另一个问题，Dovecot因为“如果我能找出问题所在那就太糟糕了！”
我强烈怀疑我要么犯了一个（可能并不罕见的）错误，要么我们现在的版本在重建后存在错误，因为重新加载之前的配置并没有发送垃圾邮件，而这正是我们在垃圾邮件发送者开始使用我们的系统之前几天一直在使用的！值得注意的是，当我们没有停止Postfix发送时，我们发现/用于测试系统的外部系统都没有认为我们的系统是一个开放的邮件中继，但不可否认的是，它错误地中继了数十万封电子邮件！此外，重新打开它（允许 Postfix 发送）可以立即允许
值得一提的是，我已经检查了日志，由于时间有限，考虑到目前我面临的所有要求，我已经以 90% 以上的确定性确认没有“被盗凭证”，但这还有待证实。我确实没有在日志中看到证据，尽管我不愿意再次向垃圾邮件发送者开放新的日志配置来获取更多数据。或许正是由于这个原因，才值得始终进行最大限度的授权日志记录！