Server iRedMail configurat folosind serverele DNS ale ISP. Rulează câțiva ani fără probleme. Trecerea de la ISP actual la Starlink. Se pare că Starlink folosește DNS-ul public Cloudflare.În prezent, ambii furnizori de servicii de internet rulează în paralel până la finalizarea trecerii. Din nou, serverul de e-mail funcționează bine pe ISP vechi.
Când trec la Starlink (inclusiv modificările DNS publice corespunzătoare), primesc eroarea 12.255.255.254 de la Spamhaus, care indică nu vor permite interogări de la serverele DNS publice. Destul de corect. Configurați soluția locală Unbound pentru a rezolva problema. Funcționează nelegat și este utilizat pentru toți clienții de rețea. Când IP-ul serverului nelegat este utilizat pentru DNS în serverul de e-mail cu poarta de acces al ISP-ului moștenit, fluxul de e-mail primit.
Când utilizați gateway-ul Starlink, e-mailul nu mai curge. Nu vedeți erori în jurnalul Postfix. Poșta nu mai curge. Chiar dacă Spamhaus părea bucuros să folosească serverul Unbound atunci când folosește gateway-ul moștenit, răspunsurile Spamhaus testate pentru orice eventualitate. Rezultatele au fost interesante:
% dig +short @[adresa serverului nelegat] 2.0.0.127.zen.spamhaus.org
127.0.0.2
127.0.0.10
127.0.0.4
%
Este corect. Cu toate acestea, următoarele nu returnează nimic:
% dig +short @[adresa serverului nelegat] 1.0.0.127.zen.spamhaus.org
%
Din documentația Spamhaus, ar trebui să se întoarcă:
Gazda 1.0.0.127.zen.spamhaus.org nu a fost găsită: 3(NXDOMAIN)
Documentația Spamhaus mai spune că „Interogările pentru obiectele „not_listed” trebuie să returneze întotdeauna NXDOMAIN pentru ca filtrarea e-mailului să funcționeze corect.” și „Este esențial să verificați rezultatele corecte atât pentru interogările „listate”, cât și pentru „nelistate”.
Interesant este că atunci când folosesc DNS și gateway ISP vechi, primesc și:
% dig +scurt @[IP DNS ISP vechi] 1.0.0.127.zen.spamhaus.org
%
Apropo, e-mailurile trimise funcționează în toate configurațiile ISP. Numai e-mailurile primite au probleme. De asemenea, rulează un server web în spatele Starlink, care funcționează bine. IP-ul public Starlink a fost același timp de două luni până acum.
Ce se întâmplă mai exact aici? Ar putea fi configurația serverului Unbound? Știu că Starlink este CGNAT, dar asta nu ar trebui să cauzeze această problemă. Vreo sfaturi de depanare? Chiar nedumerit. Ar aprecia orice ajutor.
ACTUALIZAȚI:
Am găsit în mesajele mele respinse multe intrări care arată astfel după ce am tăiat totul la Starlink:
451 4.3.5 <mta-d-130-24.infusionmail.com>: Comanda Helo a fost respinsă: Eroare de configurare a serverului; [email protected] to=<mike@[My public mail server name]> proto=ESMTP helo=<mta-d-130-24.infusionmail.com> (total: 1)
1 infusionmail.com ([email protected])
UPDATE 2:
Configurați serverul BIND9 așa cum este sugerat mai jos. Din nou, e-mailurile circulă în timp ce utilizați BIND9 DNS și gateway-ul ISP vechi, dar nu atunci când utilizați gateway-ul Starlink.
Am folosit următorul instrument pentru a testa https://mxtoolbox.com/diagnostic.aspx
Trece toate testele atunci când serverul de e-mail rulează în spatele DSL vechi. Când rulați în spatele Starlink, obțineți:
19.03.2022 17:33:54 Încercarea de conectare #1 - Nu se poate conecta după 15 secunde. [15.05 sec]
LookupServer 15051 ms
Este ca și cum serverul de e-mail nu răspunde pe portul 25 din spatele Starlink. Am încercat să elimin toate regulile de spam din Postfix. Încă nu răspunde.
Aproape se simte ca o problemă de firewall, dar am porturile 25, 587 și 993 redirecționate de la routerul Starlink, la fel ca și pentru routerul DSL vechi.
Din afara rețelei mele, am stabilit că următoarele porturi nu sunt blocate:
25:
% telnet [Numele serverului meu public de e-mail] 25
220 [Numele serverului meu public de e-mail] ESMTP Postfix
587:
% telnet [Numele serverului meu public de e-mail] 587
220 [Numele serverului meu public de e-mail] ESMTP Postfix
993:
% openssl s_client -connect [Numele serverului meu public de e-mail]:993 -crlf -quiet
adâncime=1 O = Digital Signature Trust Co., CN = DST Root CA X3
Verificați error:num=10:certificatul a expirat
notAfter=30 septembrie 14:01:15 2021 GMT
verifica returnarea:0
adâncime=1 O = Digital Signature Trust Co., CN = DST Root CA X3
Verificați error:num=10:certificatul a expirat
notAfter=30 septembrie 14:01:15 2021 GMT
verifica returnarea:0
adâncime=3 O = Digital Signature Trust Co., CN = DST Root CA X3
Verificați error:num=10:certificatul a expirat
notAfter=30 septembrie 14:01:15 2021 GMT
verifica returnarea:0
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=LOGIN] Dovecot (Ubuntu) gata.
Acest lucru ar trebui să demonstreze că Starlink nu blochează niciunul dintre porturile mele.
Cred că cel mai important bit de până acum este că comanda HELO este respinsă. Nu sunt sigur de ce ar fi respins atunci când serverul rulează în spatele Starlink și nu ISP vechi. Hmmm...
Ar putea fi aceasta o problemă de DNS inversă? Starlink are o înregistrare PTR pe adresa IP pe care mi-o oferă:
% gazdă [IP public Starlink]
[Starlink public IP].in-addr.arpa domain name pointer customer.sttlwax1.pop.starlinkisp.net.
% dig +short customer.sttlwax1.pop.starlinkisp.net
%
% dig +e-mail scurt.[domeniul meu].com
[IP public Starlink]
Apoi am verificat DSL-ul meu moștenit:
% gazdă [Legacy DSL public IP]
[Legacy DSL public IP].in-addr.arpa domain name pointer client-[Legacy DSL public IP].hostwindsdns.com.
% dig +client scurt-[Legacy DSL public IP].hostwindsdns.com
%
% dig +e-mail scurt.[domeniul meu].com
[IP public DSL moștenit]
Se pare că se comportă similar și au aceeași problemă.
