Remediați o acumulare de cozi de e-mail Zimbra: Eliminați în siguranță Postfix și verificați livrarea

O golire a cozii de mail Zimbra solicită Postfix să reîncerce mesajele din coadă. Nu șterge coada, nu repară o problemă DNS sau de rețea și nu garantează că serverele la distanță vor accepta fiecare mesaj. Un rezultat util este măsurabil: coada nu mai crește, mesajele amânate scad sau se transformă în livrări reușite, iar noile mesaje pot fi transferate prin MTA.

Urmați pașii de mai jos pe serverul Zimbra ca administrator. Comenzile și căile pot diferi între versiunile de Zimbra. Verificați căile executabile de pe gazdă înainte de a le rula; nu utilizați accidental instalarea separată Postfix a sistemului de operare.

1. Verificați cât de mare este restanța

Conectați-vă la server și comutați la contul Zimbra utilizând metoda administrativă aprobată de site-ul dvs. Utilitarul de sumarizare a cozii este instalat de obicei la /opt/zimbra/libexec/zmqstat. Documentația cozii Zimbra arată că acesta raportează numărul de mesaje reținute, corupte, amânate, active și primite.

sudo /opt/zimbra/libexec/zmqstat

În funcție de configurația sudo, executați comanda din contul Zimbra sau utilizați metoda de privilegii exactă configurată pentru serverul dvs. Un exemplu de rezumat ar putea afișa deferred=240și active=3. Acestea sunt numărătoare, nu dovada că 240 de mesaje sunt blocate permanent. Comparați-le din nou după câteva minute și observați ce categorie se schimbă.

Apoi, inspectați intrările individuale din coadă. Multe instalări actuale utilizează common/sbincalea; instalările mai vechi pot utiliza postfix/sbin. Folosiți calea care există efectiv pe serverul dvs.

/opt/zimbra/common/sbin/postqueue -p

Dacă acea cale lipsește, verificați dacă instalarea dvs. are /opt/zimbra/postfix/sbin/postqueue, apoi înlocuiți acea cale completă în comenzile de mai jos. Documentația Zimbra descrie atât rezumatul cozii, cât și postqueue -plista detaliată. ID-urile cozii pot avea un asterisc la sfârșit pentru încercările de livrare active sau un semn de exclamare pentru un mesaj reținut. Consultați referința cozii Postfix a Zimbra .

2. Găsiți motivul pentru care mesajele sunt în așteptare

Verificați vechimea celor mai vechi mesaje și starea livrării înregistrată în jurnalul Zimbra. Un mesaj amânat așteaptă o altă încercare de livrare; poate fi întârziat de un server la distanță, o căutare DNS, o expirare a rețelei, negociere TLS sau o problemă de configurare a rutării locale sau a retransmiterii. Textul exact al stării este mai util decât numărul de mesaje din coadă în sine.

grep -E 'status=(deferred|sent|bounced)|connect to|TLS|SASL|relay=' /var/log/zimbra.log | tail -n 50

Interpretați aceste rânduri în context. Expirările repetate ale conexiunilor către o destinație sugerează o problemă de conectivitate sau de server la distanță. Erorile de rezoluție a numelui indică DNS. O respingere temporară la distanță sau o limită de rată poate necesita așteptarea sau contactarea furnizorului destinatarului. Erorile de autentificare sau TLS pot indica o problemă de configurare locală. O status=sentintrare înseamnă că următorul hop de livrare a acceptat mesajul; nu stabilește că destinatarul l-a citit sau că acesta a ajuns în inbox.

Dacă coada se extinde rapid, căutați un expeditor cu volum mare de mesaje sau un cont compromis înainte de a reîncerca în mod repetat. Ghidul de depanare antispam de la Zimbra recomandă corelarea conținutului cozii cu expeditorul și activitatea de autentificare, apoi izolarea sursei înainte de ștergerea mesajelor nedorite. Consultați pașii de investigare a cozii și a spamului de la Zimbra .

3. Remediați cauza înainte de a cere Postfix să încerce din nou

Folosește dovezile din jurnal pentru a decide dacă problema este tranzitorie sau locală. Verifică dacă serverul are o rezoluție de nume funcțională și acces la rețeaua de ieșire către destinațiile de e-mail afectate. Dacă jurnalul indică un răspuns de limitare la distanță, evită declanșarea de ștergeri repetate la furnizorul respectiv; reîncercările nu pot suprascrie politica acestuia. Dacă mai multe domenii eșuează cu aceeași eroare locală, inspectează configurația Zimbra MTA relevantă și starea de sănătate a serviciului înainte de a modifica setările.

Mesajele marcate ca reținute necesită o atenție specială: o ștergere normală nu este o comandă de eliberare a mesajelor reținute. Verificați de ce au fost reținute și dacă sunt legitime înainte de a le elibera. Mesajele marcate ca corupte sau returnate necesită, de asemenea, o gestionare separată; reîncercarea nu transformă o respingere permanentă într-o livrare reușită. Păstrați ID-urile cozii și intrările relevante din jurnal în timpul investigării.

Materialul de depanare Zimbra îl identifică /var/log/zimbra.logca loc principal pentru investigarea problemelor MTA și listează utilitarele cozii, cum ar fi postqueueși zmqstat. Aspectul exact al serviciilor și locațiile executabile depind de versiune, așadar verificați documentația versiunii instalate înainte de a reporni serviciile sau de a edita configurația. Consultați instrumentele de depanare MTA Zimbra .

4. Goliți coada Postfix

După ce ați confirmat că e-mailul pus în coadă este legitim și ați corectat sau ați înțeles condiția de blocare, solicitați rularea unei cozi. Înlocuiți calea existentă pe server:

/opt/zimbra/common/sbin/postqueue -f

Pentru o instalare care folosește calea mai veche, utilizați /opt/zimbra/postfix/sbin/postqueue -fîn schimb. Documentele de referință ale cozii Zimbra postqueue -fsunt comanda flush. Cererea solicită Postfix să încerce e-mailurile din coadă; nu este o operațiune de ștergere. Este posibil să returneze comanda fără un mesaj dramatic de succes, așadar judecați rezultatul pe baza numărului de cozi ulterioare și a jurnalelor de livrare, mai degrabă decât pe baza scurtei ieșiri a comenzii.

O golire a datelor este rezonabilă după o scurtă întrerupere a rețelei sau după corectarea unei probleme temporare de configurare. Este puțin probabil să ajute atâta timp cât DNS, rutare, retransmisie, TLS sau un server de recepție la distanță rămân indisponibile. Repetarea rapidă a comenzii poate crea zgomot și trafic suplimentar de reîncercare fără a remedia eroarea.

5. Verificați rezultatul și alegeți pasul următor

După ce aștepți un scurt interval pentru încercările de livrare, repetați rezumatul cozii și inspectați intrările recente din jurnal:

sudo /opt/zimbra/libexec/zmqstat
tail -n 100 /var/log/zimbra.log

Căutați mai multe semne împreună: numărătoare amânate cu tendință descendentă, dispariția intrărilor mai vechi din coadă, status=sentînregistrări noi pentru destinațiile afectate și mai puține mesaje amânate recent. O coadă poate rămâne negoală în timpul funcționării normale. O singură livrare reușită nu arată că fiecare domeniu al destinatarului este sănătos.

• Dacă numărul scade și jurnalele de livrare arată acceptarea: continuați monitorizarea până când restanțele revin la nivelul normal.
• Dacă aceleași mesaje apar din nou: urmați textul de eroare repetat și reparați problema subiacentă de DNS, rețea, TLS, retransmisie sau la nivelul destinatarului.
• Dacă numărul continuă să crească: investigați o buclă de trimitere, un e-mail în bloc sau un cont compromis și izolați e-mailurile noi nedorite înainte de a încerca din nou.
• Dacă există contoare reținute sau corupte: examinați acele mesaje separat; o golire generală nu este o acțiune de curățare pentru acele categorii.

Nu ștergeți toate mesajele doar pentru a goli coada. Dacă se confirmă că un anumit mesaj este nedorit sau nelivrabil, iar politica permite eliminarea, păstrați ID-ul cozii sale și verificați-l înainte de a utiliza procedura de gestionare a cozii corespunzătoare. Zimbra avertizează în mod explicit că ștergerea poate afecta utilizatorii și recomandă înregistrarea detaliilor cozii înainte de eliminarea mesajelor. Evitați ștergerea fișierelor direct din directoarele spool Postfix; aceasta ocolește gestionarea cozii și poate afecta starea e-mailului.

Ce poate și ce nu îți poate spune o culoare de culoare reușită

O recuperare reușită reprezintă o îmbunătățire susținută a fluxului de mesaje, nu doar un număr zero la un moment dat. Postfix poate continua să pună e-mailurile în coadă pentru destinații îndepărtate care nu sunt disponibile sau resping temporar conexiunile. Comanda flush inițiază reîncercări; nu poate garanta livrarea, elibera mesajele reținute intenționat, corecta configurația greșită sau determina dacă sistemul unui destinatar a acceptat un mesaj dincolo de transferul SMTP.

Începând cu 6 octombrie 2026, paginile Centrului Tehnic Zimbra citate documentează comenzile de coadă și de depanare utilizate aici, dar nu oferă o singură cale curentă garantată pentru fiecare versiune de Zimbra. Confirmați locațiile binare și comportamentul privilegiilor pe propriul server înainte de a executa comenzi, în special pe implementări mai vechi sau personalizate.