La fonction « vider la file d'attente de courrier Zimbra » demande à Postfix de réessayer d'envoyer les messages en attente. Elle ne supprime pas la file d'attente, ne résout pas les problèmes DNS ou réseau et ne garantit pas que les serveurs distants accepteront chaque message. Un résultat positif est mesurable : la file d'attente ne s'allonge plus, le nombre de messages différés diminue ou est transformé en messages distribués avec succès, et les nouveaux messages peuvent transiter par le MTA.
Suivez les étapes ci-dessous sur le serveur Zimbra en tant qu'administrateur. Les commandes et les chemins d'accès peuvent varier selon les versions de Zimbra. Vérifiez les chemins d'accès aux exécutables sur votre système avant de les exécuter ; veillez à ne pas utiliser par erreur l'installation Postfix fournie avec le système d'exploitation.
1. Vérifiez l'importance du backlog.
Connectez-vous au serveur et accédez au compte Zimbra via la méthode d'administration approuvée de votre site. L'utilitaire de synthèse des files d'attente est généralement installé à l'emplacement indiqué /opt/zimbra/libexec/zmqstat. La documentation Zimbra relative aux files d'attente précise qu'il fournit le nombre de messages en attente, corrompus, différés, actifs et entrants.
sudo /opt/zimbra/libexec/zmqstat
Selon la configuration sudo, exécutez la commande depuis le compte Zimbra ou utilisez la méthode de privilège exacte configurée pour votre serveur. Un exemple de résumé pourrait afficher 240 messages deferred=240et active=3240 messages. Il s'agit de décomptes, et non d'une preuve que 240 messages sont bloqués définitivement. Comparez-les à nouveau après quelques minutes et notez quelle catégorie change.
Ensuite, examinez chaque entrée de la file d'attente. De nombreuses installations récentes utilisent le common/sbinchemin ; les installations plus anciennes peuvent utiliser un autre chemin postfix/sbin. Utilisez le chemin qui existe réellement sur votre serveur.
/opt/zimbra/common/sbin/postqueue -p
Si ce chemin est absent, vérifiez si votre installation le contient /opt/zimbra/postfix/sbin/postqueue, puis remplacez-le par le chemin complet dans les commandes ci-dessous. La documentation de Zimbra décrit le résumé de la file d'attente ainsi que la postqueue -pliste détaillée. Les identifiants de file d'attente peuvent se terminer par un astérisque pour les tentatives de livraison en cours ou par un point d'exclamation pour un message en attente. Consultez la documentation de référence des files d'attente Postfix de Zimbra .
2. Déterminez la raison pour laquelle les messages sont en attente.
Consultez l'ancienneté des messages les plus anciens et leur statut de livraison enregistrés dans le journal Zimbra. Un message différé attend une nouvelle tentative de livraison ; ce délai peut être dû à un serveur distant, une requête DNS, un délai d'attente réseau, une négociation TLS ou un problème de configuration de routage ou de relais local. Le texte exact du statut est plus utile que le nombre de messages dans la file d'attente.
grep -E 'status=(deferred|sent|bounced)|connect to|TLS|SASL|relay=' /var/log/zimbra.log | tail -n 50
Interprétez ces lignes dans leur contexte. Des expirations de connexion répétées vers une destination suggèrent un problème de connectivité ou de serveur distant. Les erreurs de résolution de noms pointent vers le DNS. Un rejet temporaire ou une limitation de débit à distance peut nécessiter d'attendre ou de contacter le fournisseur du destinataire. Les erreurs d'authentification ou TLS peuvent indiquer un problème de configuration locale. Une status=sententrée signifie que le prochain relais de distribution a accepté le message ; cela ne prouve pas que le destinataire l'a lu ni qu'il est arrivé dans sa boîte de réception.
Si la file d'attente s'allonge rapidement, vérifiez si l'expéditeur est à l'origine d'un volume important de messages ou si le compte est compromis avant de réessayer. Le guide de dépannage anti-spam de Zimbra recommande de corréler le contenu de la file d'attente avec l'expéditeur et l'activité d'authentification, puis de bloquer la source avant de supprimer les courriers indésirables. Consultez la procédure d'investigation relative aux files d'attente et au spam de Zimbra .
3. Corrigez la cause avant de demander à Postfix de réessayer.
Utilisez les journaux d'événements pour déterminer si le problème est temporaire ou local. Vérifiez que le serveur dispose d'une résolution de noms fonctionnelle et d'un accès réseau sortant aux destinations de messagerie concernées. Si les journaux indiquent une limitation de débit à distance, évitez d'envoyer des requêtes répétées à ce fournisseur ; les nouvelles tentatives ne peuvent pas contourner sa politique. Si plusieurs domaines rencontrent la même erreur locale, examinez la configuration et l'état du service Zimbra MTA concerné avant de modifier les paramètres.
Les messages marqués comme retenus nécessitent une attention particulière : une simple purge ne permet pas de libérer les messages retenus. Avant toute libération, vérifiez la raison de leur retenue et leur légitimité. Les messages marqués comme corrompus ou rejetés doivent également être traités séparément ; une nouvelle tentative ne transforme pas un rejet définitif en une livraison réussie. Conservez les identifiants de file d'attente et les entrées de journal pertinentes pendant l'investigation.
La documentation de dépannage de Zimbra indique /var/log/zimbra.logque c'est le point de départ principal pour l'investigation des problèmes liés au MTA et répertorie les utilitaires de file d'attente tels que `mta` postqueueet `mta` zmqstat. L'organisation exacte des services et l'emplacement des exécutables dépendent de la version ; consultez donc la documentation de votre version installée avant de redémarrer les services ou de modifier la configuration. Voir les outils de dépannage MTA de Zimbra .
4. Vider la file d'attente Postfix
Une fois que vous avez confirmé la légitimité du courrier en file d'attente et corrigé ou compris la cause du blocage, demandez une nouvelle exécution. Remplacez le chemin d'accès par celui qui existe sur votre serveur :
/opt/zimbra/common/sbin/postqueue -f
Pour une installation utilisant l'ancien chemin d'accès, utilisez /opt/zimbra/postfix/sbin/postqueue -fplutôt la commande `flush`. La documentation de référence de la file d'attente Zimbra postqueue -findique qu'il s'agit de la commande `flush`. Cette requête invite Postfix à tenter de récupérer le courrier en file d'attente ; il ne s'agit pas d'une opération de suppression. Il est possible qu'elle aboutisse sans message de réussite immédiat ; par conséquent, basez-vous sur le nombre de messages en file d'attente et les journaux de distribution ultérieurs plutôt que sur le bref message affiché par la commande.
Il est judicieux de vider le cache réseau après une brève interruption ou la résolution d'un problème de configuration temporaire. Cette opération est peu susceptible d'être utile si le DNS, le routage, le relais, le protocole TLS ou un serveur de réception distant restent indisponibles. Répéter rapidement la commande peut générer du bruit et un trafic de tentatives supplémentaires sans résoudre le problème.
5. Vérifiez le résultat et choisissez l'étape suivante.
Après avoir laissé passer un court intervalle entre les tentatives de livraison, répétez le résumé de la file d'attente et examinez les entrées de journal récentes :
sudo /opt/zimbra/libexec/zmqstat
tail -n 100 /var/log/zimbra.log
Observez plusieurs signes simultanément : une diminution du nombre de messages en attente, la disparition des entrées les plus anciennes dans la file d’attente, de nouveaux status=sentenregistrements pour les destinations concernées et une réduction du nombre de nouveaux messages en attente. Une file d’attente peut rester non vide en fonctionnement normal. Une seule livraison réussie ne garantit pas le bon fonctionnement de tous les domaines destinataires.
- Si le nombre diminue et que les journaux de livraison indiquent une acceptation : continuez la surveillance jusqu’à ce que le carnet de commandes revienne à son niveau normal.
- Si les mêmes messages s'affichent à nouveau : suivez le texte d'erreur répété et réparez le problème sous-jacent lié au DNS, au réseau, au TLS, au relais ou au destinataire.
- Si le nombre continue d'augmenter : recherchez une boucle d'envoi, un envoi massif de courriers indésirables ou un compte compromis, et bloquez les nouveaux courriers indésirables avant de réessayer.
- Si des comptes bloqués ou corrompus subsistent : examinez ces messages séparément ; une purge générale ne constitue pas une action de nettoyage pour ces catégories.
Ne supprimez pas tous les messages simplement pour vider la file d'attente. Si un message est identifié comme indésirable ou non distribuable et que la politique autorise sa suppression, conservez son identifiant de file d'attente et vérifiez-le avant d'appliquer la procédure de gestion correspondante. Zimbra avertit explicitement que la suppression peut affecter les utilisateurs et recommande de consigner les détails de la file d'attente avant de supprimer des messages. Évitez de supprimer directement les fichiers des répertoires de spool de Postfix ; cela contourne la gestion des files d'attente et peut endommager l'état des messages.
Ce qu'une chasse d'eau réussie peut et ne peut pas vous révéler
Une récupération réussie se traduit par une amélioration durable du flux de messages, et non par un simple retour à zéro à un instant T. Postfix peut continuer à mettre en file d'attente les messages destinés à des destinations distantes indisponibles ou qui refusent temporairement les connexions. La commande `flush` déclenche de nouvelles tentatives ; elle ne peut garantir la livraison, libérer les messages retenus intentionnellement, corriger une configuration erronée ni déterminer si le système du destinataire a accepté un message après le transfert SMTP.
Au 6 octobre 2026, les pages du Centre technique Zimbra mentionnées documentent la file d'attente et les commandes de dépannage utilisées ici, mais elles ne fournissent pas de chemin d'accès unique et garanti pour toutes les versions de Zimbra. Vérifiez l'emplacement des fichiers binaires et le comportement des privilèges sur votre serveur avant d'exécuter des commandes, en particulier sur des déploiements anciens ou personnalisés.