Dacă Zimbra raportează connect to mx.example.net[203.0.113.25]:25: Connection timed out, mesajul a ajuns de obicei în coada de e-mail Zimbra, dar serverul nu a finalizat o conexiune TCP la schimbătorul de e-mailuri al domeniului destinatarului. Începeți prin a verifica coada, DNS-ul și calea de rețea de ieșire. Nu modificați timeout-urile Postfix și nu goliți în mod repetat coada până când nu știți ce hop blochează conexiunea.
O expirare este diferită de o respingere SMTP. O respingere precum „550” înseamnă că un server la distanță a răspuns și a refuzat mesajul; „Conexiune expirată” înseamnă că încercarea de conectare nu a primit un răspuns în timp util. Cauza poate fi un firewall local, politica de e-mail de ieșire a unui furnizor de cloud sau de găzduire, rutare, o destinație inaccesibilă sau, mai rar, o problemă DNS/familie de adrese.
Zimbra își folosește MTA-ul pentru a direcționa mesajele trimise. Când un destinatar se află în afara organizației dvs., MTA-ul caută exchangerul de e-mailuri al domeniului respectiv și se conectează la acesta utilizând SMTP. Ghidul actual de administrare Daffodil al Zimbra descrie mesajele care nu pot fi livrate ca intrând în coada amânată, unde livrarea este reîncercată. Intrarea în coadă și jurnalul de e-mailuri identifică destinația și eroarea, deci acestea reprezintă cea mai bună dovadă de pornire.
Într-un flux tipic de e-mail, serverele publice de e-mail fac schimb de e-mailuri între ele prin portul TCP 25. Portul 587 este utilizat în mod obișnuit de clienții de e-mail autentificați pentru a trimite mesaje către un serviciu de retransmisie de ieșire. Comutarea căii de retransmisie Zimbra la portul 587 este o opțiune numai atunci când aveți un serviciu de retransmisie autorizat configurat în acest scop; nu este un înlocuitor general pentru primirea de e-mailuri de pe Internet pe portul 25.
Verificați coada de așteptare amânată înainte de a face modificări. Pe gazda Zimbra MTA, executați comenzi administrative în calitate de zimbracont:
su - zimbra
postqueue -pCăutați mesaje de timeout repetate și notați domeniul destinatarului, numele gazdei MX țintă și adresa IP rezolvată. În Consola de administrare Zimbra, deschideți Monitor → Cozi de e-mail și inspectați coada Amânată după tipul de eroare și domeniul destinatarului. Eticheta exactă a meniului poate varia în funcție de versiunea și ediția Zimbra.
Dacă erorile se grupează în jurul unui domeniu destinatar sau al unei adrese MX, este posibil ca destinația să fie temporar inaccesibilă sau să filtreze conexiunile de la serverul dvs. Dacă mai multe domenii fără legătură eșuează cu aceeași expirare a portului 25, suspectați mai întâi calea de ieșire a gazdei Zimbra, politica furnizorului sau firewall-ul. Înregistrați marcajele de timp și câteva destinații reprezentative; nu postați corpurile mesajelor sau acreditările atunci când solicitați ajutor.
Interogați înregistrările MX ale domeniului destinatar de pe serverul Zimbra. Înlocuiți example.netcu un domeniu care nu funcționează corect:
dig MX example.net +shortFolosește numele de gazdă MX returnat pentru a căuta adresele sale:
dig A mx.example.net +short
dig AAAA mx.example.net +shortUn domeniu poate avea mai multe gazde MX. Testați numele de gazdă reale afișate de DNS, în loc să presupuneți că serverul site-ului web al destinatarului acceptă e-mailuri. Dacă DNS nu returnează nicio țintă MX utilizabilă, verificați configurația DNS autoritară pentru domeniul destinatarului respectiv; nu adăugați o înregistrare MX inventată pe serverul Zimbra.
Apoi testați o conexiune TCP. Dacă nceste instalată, utilizați:
nc -vz -w 10 mx.example.net 25Sau utilizați telnet mx.example.net 25dacă este disponibil. O conexiune TCP reușită ar trebui să producă un mesaj de succes al conexiunii; un server SMTP poate afișa apoi un mesaj de întâmpinare. O expirare indică faptul că handshake-ul TCP nu s-a finalizat. Un rezultat „conexiune refuzată” este diferit: gazda la distanță a răspuns, dar nu a acceptat conexiunea pe adresa și portul respectiv.
Repetați testul pentru fiecare țintă MX și, acolo unde este practic, testați atât căile IPv4, cât și cele IPv6. Dacă numele de gazdă se rezolvă la o adresă IPv6, dar serverul nu are o rută IPv6 funcțională, o încercare IPv6 poate eșua în timp ce IPv4 funcționează. Verificați ruta și jurnalele înainte de a modifica setările familiei de adrese Postfix; orice astfel de modificare trebuie să fie specifică versiunii și implementării.
Verificați politica firewall a serverului fără a o modifica mai întâi. Pe sistemele care utilizează UFW:
sudo ufw status verboseUFW poate gestiona atât traficul de ieșire, cât și pe cel de intrare. Dacă politica de ieșire este restrictivă, verificați regulile numerotate și confirmați dacă conexiunile TCP către portul 25 la distanță sunt refuzate. Adăugați o regulă de permitere a ieșirii cu scop restrâns doar dacă aceasta corespunde politicii dvs. de securitate și serverul este autorizat să trimită e-mailuri direct.
Un firewall gazdă poate permite conexiunea, în timp ce un firewall din amonte, un control de securitate în cloud, un ACL de rețea sau o politică a furnizorului de găzduire o blochează. Întrebați furnizorul dacă este permisă conexiunea TCP/25 de ieșire pentru această instanță, dacă se aplică o restricție la nivel de cont și dacă este disponibil un proces de lansare sau de revizuire. Politicile diferă în funcție de furnizor, cont, regiune și produs, așadar o verificare reușită a firewall-ului local nu dovedește că este deschisă calea de acces la internet.
Dacă controlați un firewall de rețea, verificați regulile și jurnalele de ieșire ale acestuia pentru adresa IP sursă a serverului Zimbra, adresa IP MX de destinație, protocolul TCP și portul de destinație 25. O captură de pachete poate ajuta un administrator experimentat să distingă pachetele SYN fără răspuns de răspunsurile care sunt blocate pe calea de retur, dar să captureze doar anteturile relevante și să protejeze orice date operaționale. Nu deschideți portul de intrare 25 ca soluție pentru expirarea timpilor de ieșire; acestea sunt direcții de trafic separate.
Dacă furnizorul nu permite SMTP direct de ieșire, utilizați un smarthost autorizat sau un retransmisie de ieșire. Obțineți numele gazdei retransmiterii, portul, cerințele TLS, metoda de autentificare, domeniile expeditorului permise și orice cerințe de includere pe lista IP permisă. Configurați retransmiterea prin metoda de administrare Zimbra acceptată pentru versiunea dvs. sau urmați procesul de modificare Zimbra al organizației dvs. Ghidul administratorului Zimbra menționează că trebuie configurată o gazdă de retransmisie atunci când livrarea bazată pe DNS nu este activată.
Mulți furnizori oferă trimitere autentificată pe portul 587 cu STARTTLS, dar documentația retransmiterii este autorizată. O retransmitere poate necesita în schimb portul 465, listarea IP permisă sau un conector specific furnizorului. Nu presupuneți că portul 587 este deschis sau că orice server SMTP public poate fi utilizat ca retransmitere. Păstrați acreditările în configurația protejată acceptată, restricționați cine le poate citi și nu plasați niciodată o parolă de retransmitere într-un tichet de asistență sau într-un istoric shell.
După configurarea releului, trimiteți un mesaj de test controlat către o cutie poștală pe care o gestionați. Confirmați în jurnalul de e-mail Zimbra că conexiunea merge la gazda releului și la portul așteptat, TLS/autentificarea are succes dacă este necesar și releul acceptă mesajul. Dacă returnează o eroare SMTP, depanați răspunsul respectiv ca o problemă de autentificare, politică de expeditor, TLS sau permisiune de releu, mai degrabă decât ca o expirare a portului 25.
Odată ce cauza principală este corectată și un test direct către destinație sau releu are succes, solicitați o reîncercare în coadă. Din contul Zimbra, postqueue -fsolicită Postfix să încerce livrarea mesajelor din coadă:
su - zimbra
postqueue -fAcest lucru poate declanșa încercări de livrare pentru multe mesaje, așadar evitați să îl rulați în mod repetat în timpul unei întreruperi. De asemenea, puteți utiliza controalele cozii din Consola de administrare, acolo unde sunt disponibile. Zimbra documentează faptul că golirea încercărilor de livrare pentru mesajele din cozile Amânate, Primite și Active. Verificați ulterior câteva mesaje și verificați dacă numărul de mesaje amânate scade și dacă jurnalele arată o livrare reușită sau un nou răspuns SMTP acționabil.
| Observare | Probabil următoarea verificare |
|---|---|
| Un domeniu de destinație expiră | Testați fiecare gazdă MX; verificați accesibilitatea destinației și filtrarea la distanță. |
| Multe domenii expiră pe portul 25 | Verificați regulile, rutele și restricțiile furnizorului pentru firewall-ul de ieșire. |
| TCP se conectează, apoi SMTP returnează 4xx sau 5xx | Folosește răspunsul SMTP la distanță pentru a depana erorile de politică, reputație sau destinatar. |
| Portul 25 blocat de furnizorul de gazdă | Solicitați acces sau configurați un releu autentificat aprobat. |
| Releul acceptă testul, dar e-mailurile vechi rămân în coadă | Revizuiți jurnalele, încercați din nou coada o dată, apoi monitorizați livrările și notificările de returnare. |
Folosiți o secvență scurtă de verificare: confirmați că DNS returnează MX-ul sau releul dorit; confirmați că o conexiune TCP are succes la gazda și portul configurate; trimiteți un mesaj de test controlat; verificați dacă dispozitivul la distanță sau releul l-a acceptat; apoi inspectați coada de așteptare și jurnalele mesajelor originale. Un test de conexiune reușit nu dovedește în sine că destinatarul a acceptat mesajul, iar o predare reușită a releului nu garantează plasarea în inbox.
Nu „remediați” o expirare prin creșterea timeout-ului de conectare al Postfix. smtp_connect_timeoutSetarea Postfix controlează cât timp așteaptă clientul SMTP pentru a finaliza o conexiune TCP; extinderea acesteia nu poate face ca o rută blocată să funcționeze și poate lăsa încercările de livrare să aștepte mai mult. De asemenea, evitați ștergerea mesajelor din coadă sau modificarea duratei de viață a cozii pentru a ascunde simptomul. Dacă mesajele se apropie de durata de viață configurată pentru respingere, informați utilizatorii afectați că livrarea este întârziată și păstrați dovezile cozii în timp ce restaurați ruta.
Comparați 10 instrumente de scanare ping pentru descoperirea rapidă a rețelelor LAN, scanarea multi-platformă și gestionarea adreselor IP. Aflați ce vă poate spune o scanare (sweep).
Comparați șase instrumente de gestionare a rețelei pentru monitorizarea performanței, inclusiv acoperirea SNMP, maparea, alertele, modelele de implementare și compromisurile de costuri.
Aflați ce înseamnă QoS în rețele, cum marcajele DSCP și cozile de trafic prioritizează aplicațiile vocale, video și de business și ce nu poate remedia QoS.
Compară software-ul de server SFTP fiabil pentru Windows și Linux, inclusiv OpenSSH, Bitvise, SolarWinds și SFTPGo. Găsește soluția potrivită pentru nevoile tale de securitate și transfer de fișiere.
Construiți o monitorizare practică a rețelei cu o acoperire clară a dispozitivelor, indicatori de performanță utili, alerte acționabile și o comparație între SolarWinds NPM, PRTG și OpManager.
Comparați șapte instrumente de gestionare a adreselor IP pentru descoperirea subrețelelor, coordonarea DNS și DHCP, inventarul rețelei și IPAM open-source.
Comparați instrumentele de scanare a rețelei pentru descoperirea rapidă a dispozitivelor, scanări IP pe mai multe platforme și IPAM pentru întreprinderi, cu îndrumări privind potrivirea fiecărei opțiuni la rețeaua dvs.
Folosește opțiunea --traceroute din Nmap pentru a mapa salturi la o gazdă autorizată, a înțelege ieșirea saltului și a RTT-ului și a depana răspunsurile lipsă fără a suprascana.
Comparați șase instrumente de monitorizare Windows Server în funcție de colectarea datelor Windows, vizibilitatea aplicațiilor, modelul de implementare și licențierea pentru a găsi instrumentul potrivit.
Comparați șase instrumente de monitorizare a rețelei Linux pentru descoperirea dispozitivelor SNMP, grafice de interfață, metrici gazdă, verificări de servicii și fluxuri de trafic.
