Lo svuotamento della coda di posta di Zimbra richiede a Postfix di ritentare la consegna dei messaggi in coda. Non cancella la coda, non risolve problemi DNS o di rete, né garantisce che i server remoti accettino ogni messaggio. Il risultato utile è misurabile: la coda non cresce più, i messaggi in sospeso diminuiscono o vengono recapitati con successo e la nuova posta può transitare attraverso l'MTA.
Segui i passaggi seguenti sul server Zimbra come amministratore. I comandi e i percorsi possono variare a seconda della versione di Zimbra. Verifica i percorsi degli eseguibili sul tuo host prima di eseguirli; fai attenzione a non utilizzare accidentalmente l'installazione separata di Postfix del sistema operativo.
Connettiti al server e passa all'account Zimbra utilizzando il metodo amministrativo approvato dal tuo sito. L'utilità di riepilogo della coda viene solitamente installata in /opt/zimbra/libexec/zmqstat. La documentazione di Zimbra relativa alla coda mostra che essa riporta i conteggi per i messaggi in sospeso, corrotti, differiti, attivi e in arrivo.
sudo /opt/zimbra/libexec/zmqstatA seconda della configurazione di sudo, esegui il comando dall'account Zimbra o utilizza il metodo con i privilegi esatti configurato per il tuo server. Un riepilogo di esempio potrebbe mostrare deferred=240e active=3. Questi sono conteggi, non la prova che 240 messaggi siano bloccati in modo permanente. Confrontali di nuovo dopo qualche minuto e prendi nota di quale categoria cambia.
Successivamente, esamina le singole voci della coda. Molte installazioni attuali utilizzano il common/sbinpercorso; le installazioni più vecchie potrebbero utilizzare postfix/sbin. Utilizza il percorso effettivamente presente sul tuo server.
/opt/zimbra/common/sbin/postqueue -pSe quel percorso non è presente, verifica se la tua installazione lo include /opt/zimbra/postfix/sbin/postqueue, quindi sostituisci il percorso completo nei comandi seguenti. La documentazione di Zimbra descrive sia il riepilogo della coda che l' postqueue -pelenco dettagliato. Gli ID delle code possono avere un asterisco finale per i tentativi di consegna attivi o un punto esclamativo per un messaggio in sospeso. Consulta il riferimento alle code Postfix di Zimbra .
Esamina l'età dei messaggi più vecchi e lo stato di consegna registrato nel log di Zimbra. Un messaggio differito è in attesa di un nuovo tentativo di consegna; il ritardo può essere dovuto a un server remoto, una ricerca DNS, un timeout di rete, una negoziazione TLS o un problema di configurazione di routing o relay locale. Il testo esatto dello stato è più utile del solo conteggio in coda.
grep -E 'status=(deferred|sent|bounced)|connect to|TLS|SASL|relay=' /var/log/zimbra.log | tail -n 50Interpreta queste righe nel contesto. Ripetuti timeout di connessione verso una destinazione suggeriscono un problema di connettività o del server remoto. Gli errori di risoluzione dei nomi indicano un problema con il DNS. Un rifiuto temporaneo remoto o un limite di velocità potrebbero richiedere di attendere o di contattare il provider del destinatario. Gli errori di autenticazione o TLS potrebbero indicare un problema di configurazione locale. Una status=sentvoce indica che il successivo nodo di consegna ha accettato il messaggio; non stabilisce che il destinatario lo abbia letto o che abbia raggiunto la posta in arrivo.
Se la coda si allunga rapidamente, prima di riprovare ripetutamente, cerca un mittente con un volume elevato di messaggi o un account compromesso. La guida di Zimbra per la risoluzione dei problemi antispam consiglia di correlare il contenuto della coda con l'attività del mittente e di autenticazione, quindi di isolare la fonte prima di eliminare la posta indesiderata. Consulta le procedure di Zimbra per la gestione della coda e l'analisi dello spam .
Utilizza i log per stabilire se il problema è temporaneo o locale. Verifica che il server disponga di una risoluzione dei nomi funzionante e di un accesso di rete in uscita corretto verso le destinazioni di posta interessate. Se il log indica una risposta di limitazione della velocità da remoto, evita di inviare ripetutamente richieste di invio a quel provider; i tentativi di invio non possono ignorare le sue policy. Se diversi domini presentano lo stesso errore locale, controlla la configurazione e lo stato del servizio Zimbra MTA prima di modificare le impostazioni.
I messaggi contrassegnati come bloccati richiedono un'attenzione particolare: un normale svuotamento della coda non è un comando per rilasciare la posta bloccata. Prima di rilasciarli, è necessario verificare il motivo del blocco e la legittimità dei messaggi. Anche i messaggi contrassegnati come danneggiati o non recapitati richiedono una gestione separata; un nuovo tentativo di consegna non trasforma un rifiuto permanente in una consegna riuscita. Durante le indagini, conservare gli ID della coda e le relative voci di registro.
Il materiale di risoluzione dei problemi di Zimbra identifica /var/log/zimbra.logcome punto di partenza principale per indagare sui problemi dell'MTA ed elenca le utilità di coda come postqueuee zmqstat. La struttura esatta dei servizi e la posizione degli eseguibili dipendono dalla versione, quindi consultare la documentazione della versione installata prima di riavviare i servizi o modificare la configurazione. Vedere gli strumenti di risoluzione dei problemi dell'MTA di Zimbra .
Dopo aver verificato la legittimità della posta in coda e aver corretto o compreso la causa del blocco, richiedere l'esecuzione della coda. Sostituire il percorso con quello presente sul server:
/opt/zimbra/common/sbin/postqueue -fPer un'installazione che utilizza il percorso precedente, utilizzare /opt/zimbra/postfix/sbin/postqueue -finvece. I documenti di riferimento della coda Zimbra postqueue -fsono il comando flush. La richiesta spinge Postfix a provare la posta in coda; non è un'operazione di eliminazione. Potrebbe restituire un risultato senza un messaggio di successo evidente, quindi valutare il risultato dai successivi conteggi della coda e dai log di consegna piuttosto che dal breve output del comando.
Un'operazione di svuotamento della cache è consigliabile dopo una breve interruzione di rete o dopo la correzione di un problema di configurazione temporaneo. È improbabile che sia utile se DNS, routing, relay, TLS o un server di ricezione remoto rimangono non disponibili. Ripetere rapidamente il comando può generare rumore e traffico di retry aggiuntivo senza risolvere il problema.
Dopo aver atteso un breve intervallo per i tentativi di consegna, ripetere il riepilogo della coda e controllare le voci di registro recenti:
sudo /opt/zimbra/libexec/zmqstat
tail -n 100 /var/log/zimbra.logCerca insieme diversi segnali: un trend decrescente nel numero di messaggi differiti, la scomparsa delle voci più vecchie della coda, la creazione di nuovi status=sentrecord per le destinazioni interessate e un numero inferiore di messaggi differiti di recente. Una coda può rimanere non vuota durante il normale funzionamento. Una singola consegna andata a buon fine non garantisce che tutti i domini dei destinatari siano integri.
Non eliminare tutti i messaggi solo per svuotare la coda. Se un messaggio specifico risulta indesiderato o non recapitabile e la policy ne consente la rimozione, conserva il suo ID di coda e rivedilo prima di utilizzare la procedura di gestione della coda corrispondente. Zimbra avverte esplicitamente che la cancellazione può avere ripercussioni sugli utenti e raccomanda di registrare i dettagli della coda prima di rimuovere i messaggi. Evita di eliminare i file direttamente dalle directory di spool di Postfix; in questo modo si aggira la gestione della coda e si può danneggiare lo stato della posta.
Un ripristino riuscito si verifica quando il flusso dei messaggi migliora in modo duraturo, non semplicemente quando il conteggio dei messaggi è pari a zero in un dato istante. Postfix può continuare a mettere in coda la posta per destinazioni remote non disponibili o che rifiutano temporaneamente le connessioni. Il comando flush avvia i tentativi di consegna; non può garantire la consegna, rilasciare i messaggi intenzionalmente trattenuti, correggere configurazioni errate o determinare se il sistema del destinatario ha accettato un messaggio dopo il passaggio SMTP.
Al 6 ottobre 2026, le pagine del Centro assistenza tecnica di Zimbra citate documentano la coda e i comandi di risoluzione dei problemi utilizzati, ma non forniscono un percorso univoco e garantito per tutte le versioni di Zimbra. Prima di eseguire i comandi, soprattutto su installazioni precedenti o personalizzate, verificare la posizione dei file binari e il comportamento dei privilegi sul proprio server.
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.
Risolvi l'avviso di Nextcloud relativo agli indici del database mancanti utilizzando il comando ufficiale occ. Prima di procedere, esegui un backup, visualizza in anteprima le modifiche, avvia la riparazione e verifica il risultato.
