使用 ISP 的 DNS 服务器配置 iRedMail 服务器。运行数年没有问题。从当前 ISP 迁移到 Starlink。看来 Starlink 使用 Cloudflare 的公共 DNS。目前两个 ISP 并行运行，直到切换完成。同样，邮件服务器在旧 ISP 上运行良好。
当我切换到 Starlink（包括适当的公共 DNS 更改）时，收到来自 Spamhaus 的错误 12.255.255.254，这表明它们将不允许来自公共 DNS 服务器的查询。 相当合理。设置本地 Unbound 解析器来解决问题。Unbound 正常工作并用于所有网络客户端。当 Unbound 服务器 IP 用于具有旧 ISP 网关的邮件服务器中的 DNS 时，传入邮件会流动。
使用 Starlink 网关时，邮件停止流动。在 Postfix 日志中看不到任何错误。邮件只是停止流动。尽管 Spamhaus 在使用旧网关时似乎很乐意使用 Unbound 服务器，测试了 Spamhaus 的响应以防万一。结果很有趣：
% dig +short @[address of Unbound server] 2.0.0.127.zen.spamhaus.org
127.0.0.2
127.0.0.10
127.0.0.4
%
这是正确的。但是，下面的代码没有返回任何内容：
% dig +short @[address of Unbound server] 1.0.0.127.zen.spamhaus.org
%
根据 Spamhaus 文档，它应该返回：
Host 1.0.0.127.zen.spamhaus.org not found: 3(NXDOMAIN)
Spamhaus 文档还指出，“对“not_listed”对象的查询必须始终返回 NXDOMAIN，以使邮件过滤正常工作。”并且“检查‘列出’和‘未列出’查询的正确结果至关重要。”
有趣的是，当我使用旧式 ISP DNS 和网关时，我也会得到：
% dig +short @[legacy ISP DNS IP] 1.0.0.127.zen.spamhaus.org
%
顺便说一句，外发邮件在所有 ISP 配置下都可以正常工作。只有传入邮件有问题。此外，在 Starlink 后面运行的 Web 服务器运行良好。到目前为止，Starlink 公共 IP 已经两个月没有变化了。
这里到底发生了什么？可能是 Unbound 服务器配置吗？我知道 Starlink 是 CGNAT，但这不应该导致此问题。有什么故障排除技巧吗？真的很困惑。非常感谢任何帮助。
更新：
在我将所有内容转移到 Starlink 后，我在被拒绝的邮件中发现许多如下所示的条目：
451 4.3.5 <mta-d-130-24.infusionmail.com>：Helo 命令被拒绝：服务器配置错误；[电子邮件保护]to=<mike@[我的公共邮件服务器名称]> proto=ESMTP helo=<mta-d-130-24.infusionmail.com> (total: 1) 1 infusionmail.com ([电子邮件保护]）
更新2：
按照以下建议设置 BIND9 服务器。同样，使用 BIND9 DNS 和旧式 ISP 网关时邮件可以流动，但使用 Starlink 网关时则不会。
使用以下工具进行测试https://mxtoolbox.com/diagnostic.aspx
当电子邮件服务器在传统 DSL 后面运行时，通过所有测试。在 Starlink 后面运行时，获得：
3/19/2022 5:33:54 PM Connection attempt #1 - Unable to connect after 15 seconds. [15.05 sec]
LookupServer 15051ms
就像 Starlink 后面的电子邮件服务器在端口 25 上没有响应一样。我尝试删除 Postfix 中的所有垃圾邮件规则。仍然没有响应。
几乎感觉像是防火墙问题，但我有从 Starlink 路由器转发的端口 25、587 和 993 端口，就像我对传统 DSL 路由器所做的那样。
从我的网络外部，我已确定以下端口未被阻止：
25：
% telnet [My public mail server name] 25
220 [My public mail server name] ESMTP Postfix
587：
% telnet [My public mail server name] 587
220 [My public mail server name] ESMTP Postfix
993：
% openssl s_client -connect [My public mail server name]:993 -crlf -quiet
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=LOGIN] Dovecot (Ubuntu) ready.
这应该可以证明 Starlink 没有阻塞我的任何端口。
我认为到目前为止最重要的一点是 HELO 命令被拒绝了。不确定当服务器运行在 Starlink 而不是传统 ISP 后面时为什么会被拒绝。嗯...
这可能是反向 DNS 问题吗？Starlink 在他们提供给我的 IP 地址上有一条 PTR 记录：
% host [Starlink public IP]
[Starlink public IP].in-addr.arpa domain name pointer customer.sttlwax1.pop.starlinkisp.net.
% dig +short customer.sttlwax1.pop.starlinkisp.net
%
% dig +short mail.[my domain].com
[Starlink public IP]
然后我检查了我的旧版 DSL：
% host [Legacy DSL public IP]
[Legacy DSL public IP].in-addr.arpa domain name pointer client-[Legacy DSL public IP].hostwindsdns.com.
% dig +short client-[Legacy DSL public IP].hostwindsdns.com
%
% dig +short mail.[my domain].com
[Legacy DSL public IP]
他们的行为似乎相似并且有相同的问题。
答案1
Starlink 表示他们正在阻止端口 25，CGNAT 可能导致路由问题。我通过创建一个 VPS，然后在 Starlink 后面的邮件服务器中创建一个隧道解决了这个问题。然后，所有流量都通过隧道从 VPS 转发到邮件服务器。来自邮件服务器的所有传出流量都通过隧道传出。效果很好。