Domain-Name-System

無法接收電子郵件 - Postfix iRedMail 伺服器使用 Spamhaus 和 Unbound / BIND9 DNS 伺服器

  • April 9, 2022

使用 ISP 的 DNS 伺服器配置的 iRedMail 伺服器。執行幾年沒有問題。從目前的 ISP 轉移到 Starlink。Starlink 似乎使用 Cloudflare 的公共 DNS。目前讓兩個 ISP 並行執行,直到切換完成。同樣,郵件伺服器在舊版 ISP 上執行良好。

當我切換到 Starlink(包括適當的公共 DNS 更改)時,收到來自 Spamhaus 的錯誤 12.255.255.254,這表明他們不允許來自公共 DNS 伺服器的查詢。很公平。設置本地未綁定解析器以解決問題。不受約束的工作並用於所有網路客戶端。當帶有傳統 ISP 網關的郵件伺服器中用於 DNS 的未綁定伺服器 IP 時,傳入的郵件會流動。

使用 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 文件還說“對“未列出”對象的查詢必須始終返回 NXDOMAIN 才能使郵件過濾正常工作。” “檢查‘列出’和‘未列出’查詢的正確結果至關重要。”

有趣的是,當我使用舊版 ISP DNS 和網關時,我還得到:

% dig +short @[legacy ISP DNS IP] 1.0.0.127.zen.spamhaus.org
%

順便說一句,外發郵件適用於所有 ISP 配置。只有傳入的郵件有問題。還在 Starlink 後面執行一個執行良好的網路伺服器。星鏈公網IP到現在已經兩個月了。

這裡到底發生了什麼?會不會是 Unbound 伺服器配置?我知道 Starlink 是 CGNAT,但這不應該導致這個問題。任何故障排除提示?真是難住了。將不勝感激任何幫助。

更新:

在我將所有內容都轉到 Starlink 之後,我在被拒絕的消息中發現了許多看起來像這樣的條目:

451 4.3.5 <mta-d-130-24.infusionmail.com>:Helo 命令被拒絕:伺服器配置錯誤;從=mailer@infusionmail.com 到=<mike@

$$ My public mail server name $$> proto=ESMTP helo=<mta-d-130-24.infusionmail.com> (總數: 1) 1 infusionmail.com (mailer@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]

他們似乎表現相似並且有同樣的問題。

Starlink 表示他們封鎖了 25 埠,而 CGNAT 可能導致了路由問題。我通過創建一個 VPS 然後在 Starlink 後面的郵件伺服器中創建一個隧道解決了這個問題。然後所有流量都通過隧道從 VPS 轉發到郵件伺服器。來自郵件伺服器的所有傳出流量都通過隧道傳出。奇蹟般有效。

引用自:https://serverfault.com/questions/1096221