Se Zimbra segnala un errore connect to mx.example.net[203.0.113.25]:25: Connection timed out, di solito il messaggio ha raggiunto la coda di posta di Zimbra, ma il server non ha completato una connessione TCP con il server di posta del dominio del destinatario. Inizia controllando la coda, il DNS e il percorso di rete in uscita. Non modificare i timeout di Postfix né svuotare ripetutamente la coda finché non hai individuato il passaggio che blocca la connessione.
Un timeout è diverso da un rifiuto SMTP. Un rifiuto come "550" significa che un server remoto ha risposto ma ha rifiutato il messaggio; "Timeout di connessione" significa che il tentativo di connessione non ha ricevuto una risposta tempestiva. La causa può essere un firewall locale, le policy di posta in uscita del provider di servizi cloud o di hosting, il routing, una destinazione irraggiungibile o, meno comunemente, un problema DNS/di famiglia di indirizzi.
Zimbra utilizza il suo MTA (Mail Transfer Agent) per instradare i messaggi in uscita. Quando un destinatario si trova al di fuori della tua organizzazione, l'MTA individua il server di posta di quel dominio e si connette ad esso tramite SMTP. La guida di amministrazione di Zimbra Daffodil, nella sua versione attuale, descrive i messaggi che non possono essere recapitati come inseriti nella coda di messaggi differiti, dove la consegna viene ritentata. La voce nella coda e il registro di posta identificano la destinazione e l'errore, rappresentando quindi la migliore prova iniziale.
In un tipico flusso di posta, i server di posta pubblici si scambiano email tramite la porta TCP 25. La porta 587 è comunemente utilizzata dai client di posta autenticati per inviare messaggi a un server di inoltro in uscita. Il passaggio del percorso di inoltro di Zimbra alla porta 587 è un'opzione disponibile solo se si dispone di un servizio di inoltro autorizzato configurato a tale scopo; non rappresenta una soluzione alternativa per la ricezione della posta Internet sulla porta 25.
Prima di apportare modifiche, controlla la coda differita. Sull'host Zimbra MTA, esegui i comandi amministrativi come l' zimbraaccount:
su - zimbra
postqueue -pCerca messaggi di timeout ripetuti e annota il dominio del destinatario, il nome host MX di destinazione e l'indirizzo IP risolto. Nella console di amministrazione di Zimbra, apri Monitor → Code di posta e controlla la coda di posta differita in base al tipo di errore e al dominio del destinatario. L'etichetta esatta del menu può variare a seconda della versione e dell'edizione di Zimbra.
Se gli errori si concentrano attorno a un dominio destinatario o a un indirizzo MX, la destinazione potrebbe essere temporaneamente irraggiungibile o filtrare le connessioni dal server. Se molti domini non correlati presentano lo stesso timeout sulla porta 25, il problema potrebbe risiedere nel percorso di uscita dell'host Zimbra, nelle policy del provider o nel firewall. Annotate i timestamp e alcuni indirizzi di destinazione rappresentativi; non pubblicate il corpo dei messaggi o le credenziali quando richiedete assistenza.
Interroga i record MX del dominio del destinatario dal server Zimbra. Sostituiscili example.netcon il dominio che presenta il problema:
dig MX example.net +shortUtilizza il nome host MX restituito per cercare i relativi indirizzi:
dig A mx.example.net +short
dig AAAA mx.example.net +shortUn dominio può avere più record MX. Verifica i nomi host effettivi visualizzati dal DNS anziché presumere che il server del sito web del destinatario accetti la posta. Se il DNS non restituisce alcun record MX utilizzabile, controlla la configurazione DNS autorevole per quel dominio del destinatario; non aggiungere un record MX fittizio sul tuo server Zimbra.
Successivamente, prova una connessione TCP. Se ncè installato, usa:
nc -vz -w 10 mx.example.net 25Oppure, se disponibile, utilizzare telnet mx.example.net 25questa opzione. Una connessione TCP riuscita dovrebbe produrre un messaggio di successo; un server SMTP potrebbe quindi mostrare un messaggio di benvenuto. Un timeout indica che l'handshake TCP non è stato completato. Un risultato di "connessione rifiutata" è diverso: l'host remoto ha risposto ma non ha accettato la connessione su quell'indirizzo e porta.
Ripetere il test per ogni target MX e, ove possibile, testare sia i percorsi IPv4 che IPv6. Se il nome host si risolve in un indirizzo IPv6 ma il server non dispone di una rotta IPv6 funzionante, un tentativo IPv6 potrebbe fallire mentre IPv4 funziona. Verificare la rotta e i log prima di modificare le impostazioni della famiglia di indirizzi di Postfix; qualsiasi modifica di questo tipo deve essere specifica per la versione e l'implementazione.
Verifica prima le impostazioni del firewall del server senza modificarle. Sui sistemi che utilizzano UFW:
sudo ufw status verboseUFW è in grado di gestire sia il traffico in uscita che quello in entrata. Se la policy in uscita è restrittiva, esaminare le regole numerate e verificare se le connessioni TCP alla porta remota 25 sono bloccate. Aggiungere una regola di autorizzazione in uscita con ambito ristretto solo se questa è in linea con la policy di sicurezza e il server è autorizzato a inviare la posta direttamente.
Un firewall host potrebbe consentire la connessione mentre un firewall a monte, un controllo di sicurezza cloud, un ACL di rete o una policy del provider di hosting la bloccano. Chiedi al provider se il traffico TCP/25 in uscita è consentito in questo caso, se si applica una restrizione a livello di account e se è disponibile una procedura di rilascio o revisione. Le policy variano in base al provider, all'account, alla regione e al prodotto, quindi un controllo del firewall locale con esito positivo non dimostra che il percorso Internet sia aperto.
Se gestisci un firewall di rete, controlla le sue regole in uscita e i log per l'indirizzo IP di origine del server Zimbra, l'indirizzo IP MX di destinazione, il protocollo TCP e la porta di destinazione 25. Un'analisi dei pacchetti può aiutare un amministratore esperto a distinguere i pacchetti SYN senza risposta dalle risposte bloccate sul percorso di ritorno, ma è importante acquisire solo le intestazioni rilevanti e proteggere i dati operativi. Non aprire la porta in entrata 25 come soluzione ai timeout in uscita; si tratta di due direzioni di traffico separate.
Se il provider non consente l'invio diretto di SMTP in uscita, utilizzare uno smarthost autorizzato o un relay in uscita. Richiedere al gestore del relay il nome host del relay, la porta, i requisiti TLS, il metodo di autenticazione, i domini del mittente consentiti e gli eventuali requisiti di whitelist IP. Configurare il relay tramite il metodo di amministrazione Zimbra supportato per la propria versione oppure seguire la procedura di modifica di Zimbra della propria organizzazione. La guida di amministrazione di Zimbra indica che è necessario configurare un host relay quando la consegna basata su DNS non è abilitata.
Molti provider offrono l'invio autenticato sulla porta 587 con STARTTLS, ma la documentazione del relay è quella autorevole. Un relay potrebbe invece richiedere la porta 465, l'inserimento di indirizzi IP in una lista bianca o un connettore specifico del provider. Non dare per scontato che la porta 587 sia aperta o che qualsiasi server SMTP pubblico possa essere utilizzato come relay. Conserva le credenziali nella configurazione protetta supportata, limita chi può leggerle e non inserire mai la password del relay in un ticket di supporto o nella cronologia della shell.
Dopo aver configurato il relay, invia un messaggio di prova controllato a una casella di posta che gestisci. Verifica nel registro di posta di Zimbra che la connessione raggiunga l'host del relay e la porta prevista, che l'autenticazione TLS/TLS abbia esito positivo (se richiesta) e che il relay accetti il messaggio. Se viene restituito un errore SMTP, analizza la risposta come un problema di autenticazione, di policy del mittente, di TLS o di autorizzazioni del relay, piuttosto che come un timeout della porta 25.
Una volta corretta la causa principale e dopo aver effettuato con successo un test diretto verso la destinazione o il relay, richiedere un nuovo tentativo di consegna. Dall'account Zimbra, postqueue -fchiedere a Postfix di tentare la consegna dei messaggi in coda:
su - zimbra
postqueue -fQuesta operazione può attivare tentativi di consegna per molti messaggi, quindi è consigliabile evitare di eseguirla ripetutamente durante un'interruzione del servizio. In alternativa, è possibile utilizzare i controlli della coda della Console di amministrazione, ove disponibili. La documentazione di Zimbra indica che lo svuotamento della coda tenta la consegna dei messaggi nelle code Rimandati, In arrivo e Attivi. Dopo l'operazione, verificare alcuni messaggi e assicurarsi che il numero di messaggi rimandati diminuisca e che i log mostrino una consegna avvenuta con successo o una nuova risposta SMTP utilizzabile.
| Osservazione | Probabilmente al prossimo controllo |
|---|---|
| Il dominio di destinazione va in timeout | Testa ciascun host MX; verifica la raggiungibilità della destinazione e il filtraggio remoto. |
| Molti domini vanno in timeout sulla porta 25 | Verifica le regole del firewall in uscita, le rotte e le restrizioni del provider. |
| La connessione TCP viene stabilita, quindi SMTP restituisce 4xx o 5xx | Utilizzare la risposta SMTP remota per risolvere i problemi relativi a criteri, reputazione o errori del destinatario. |
| La porta 25 è bloccata dal provider di hosting. | Richiedi l'accesso o configura un relay autenticato approvato. |
| Relay accetta il test, ma la posta vecchia rimane in coda | Esamina i log, riprova a inserire il messaggio nella coda una volta, quindi monitora la consegna e le notifiche di errore. |
Utilizzare una breve sequenza di verifica: confermare che il DNS restituisca l'MX o il relay desiderato; confermare che la connessione TCP all'host e alla porta configurati abbia successo; inviare un messaggio di prova controllato; verificare che il destinatario remoto o il relay lo abbia accettato; infine, esaminare la coda dei messaggi differiti e i log per i messaggi originali. Un test di connessione riuscito da solo non dimostra che il destinatario abbia accettato il messaggio e un trasferimento del relay riuscito non garantisce la consegna nella casella di posta in arrivo.
Non "risolvere" un timeout aumentando il timeout di connessione di Postfix. L' smtp_connect_timeoutimpostazione di Postfix controlla per quanto tempo il client SMTP attende per completare una connessione TCP; estenderlo non può risolvere un problema di percorso bloccato e potrebbe far attendere più a lungo i tentativi di consegna. Evita inoltre di eliminare i messaggi in coda o di modificare la durata delle code per nascondere il problema. Se i messaggi si avvicinano alla durata di bounce configurata, informa gli utenti interessati del ritardo nella consegna e conserva le prove della coda durante il ripristino del percorso.
Confronta sei server e collettori syslog gratuiti per Windows e Linux, inclusi strumenti con interfaccia grafica, opzioni open source, funzionalità di ricerca, avvisi e trasporto sicuro.
Scopri cosa fa Microsoft IIS, come funzionano la sua pipeline di richieste e i pool di applicazioni e quando Apache, NGINX o Caddy potrebbero essere più adatti alle tue esigenze di server web.
Diagnostica i picchi di utilizzo della CPU del browser Jitsi Meet e riduci il carico del client controllando i riquadri video, gli effetti della fotocamera, la grafica del browser e le impostazioni dell'host.
Monitora lo stato di salute, il carico della conferenza e il traffico di Jitsi Videobridge con il suo endpoint Prometheus integrato, quindi esplora e visualizza i dati in Grafana.
Configura un dominio personalizzato per Jitsi Meet Docker con DNS, URL pubblico, HTTPS, Let's Encrypt, porte del firewall, impostazioni NAT e verifica end-to-end.
Fix Zimbra Admin Console 404 errors after SSL renewal by checking the correct URL and port, proxy routing, service status, deployed certificates, and logs.
Scopri come diagnosticare e risolvere l'avviso di configurazione di PHP OPcache di Nextcloud controllando l'SAPI PHP attivo, i limiti di dimensionamento, i commenti e le impostazioni di riconvalida.
Risolvere i problemi di migrazione del database Kopano dopo un aggiornamento di MySQL o MariaDB verificando i backup, le versioni del server, le modalità SQL, il set di caratteri, lo stato dello schema e i log.
Collega Nextcloud a LDAP o Active Directory con trasporto sicuro, filtri per utenti e gruppi, attributi di accesso e un'implementazione collaudata.
Risolvi i problemi di notifiche di Element Android sui telefoni senza Google configurando UnifiedPush, le autorizzazioni Android, le impostazioni della batteria ed eseguendo test di verifica affidabili.
