Si Zimbra signale une erreur connect to mx.example.net[203.0.113.25]:25: Connection timed out, cela signifie généralement que le message a atteint la file d'attente de messagerie Zimbra, mais que le serveur n'a pas encore établi de connexion TCP avec le serveur de messagerie du domaine destinataire. Commencez par vérifier la file d'attente, le DNS et le chemin réseau sortant. Ne modifiez pas les délais d'attente de Postfix et n'effectuez pas de vidage répété de la file d'attente tant que vous n'avez pas identifié le serveur bloquant la connexion.
Un délai d'attente dépassé est différent d'un rejet SMTP. Un rejet tel que « 550 » signifie qu'un serveur distant a répondu et refusé le message ; « Délai de connexion dépassé » signifie que la tentative de connexion n'a pas reçu de réponse dans les délais impartis. La cause peut être un pare-feu local, la politique de messagerie sortante d'un fournisseur de cloud ou d'hébergement, le routage, une destination inaccessible, ou plus rarement un problème de DNS ou de famille d'adresses.
Zimbra utilise son MTA pour acheminer les messages sortants. Lorsqu'un destinataire se trouve en dehors de votre organisation, le MTA recherche le serveur de messagerie de ce domaine et s'y connecte via SMTP. Le guide d'administration Daffodil de Zimbra indique que les messages non distribués sont placés dans la file d'attente différée, où une nouvelle tentative de distribution est effectuée. L'entrée dans la file d'attente et le journal de messagerie identifient la destination et l'erreur ; ils constituent donc les meilleurs éléments de départ.
Dans un flux de messagerie classique, les serveurs de messagerie publics échangent des courriels via le port TCP 25. Le port 587 est généralement utilisé par les clients de messagerie authentifiés pour envoyer des messages à un relais sortant. Le basculement du chemin de relais de Zimbra vers le port 587 n'est possible que si vous disposez d'un service de relais autorisé configuré à cet effet ; il ne remplace pas systématiquement la réception du courrier Internet sur le port 25.
Vérifiez la file d'attente différée avant d'apporter des modifications. Sur l'hôte Zimbra MTA, exécutez les commandes d'administration avec le zimbracompte :
su - zimbra
postqueue -pRecherchez les messages d'expiration de délai répétés et notez le domaine du destinataire, le nom d'hôte MX cible et l'adresse IP résolue. Dans la console d'administration Zimbra, ouvrez Surveillance → Files d'attente de messagerie et examinez la file d'attente différée par type d'erreur et domaine du destinataire. L'intitulé exact du menu peut varier selon la version et l'édition de Zimbra.
Si les échecs se concentrent autour d'un même domaine destinataire ou d'une même adresse MX, la destination est peut-être temporairement inaccessible ou votre serveur filtre les connexions. Si plusieurs domaines sans lien entre eux rencontrent le même délai d'attente sur le port 25, suspectez en premier lieu le chemin de sortie du serveur Zimbra, la politique de votre fournisseur d'accès ou votre pare-feu. Notez les horodatages et quelques destinations représentatives ; ne communiquez ni le contenu des messages ni vos identifiants lorsque vous demandez de l'aide.
Interrogez les enregistrements MX du domaine destinataire auprès du serveur Zimbra. Remplacez example.netpar un domaine qui ne fonctionne pas :
dig MX example.net +shortUtilisez le nom d'hôte MX renvoyé pour rechercher ses adresses :
dig A mx.example.net +short
dig AAAA mx.example.net +shortUn domaine peut avoir plusieurs serveurs MX. Vérifiez les noms d'hôtes réels renvoyés par le DNS plutôt que de supposer que le serveur du site web du destinataire accepte le courrier électronique. Si le DNS ne renvoie aucune cible MX utilisable, examinez la configuration DNS faisant autorité pour ce domaine du destinataire ; n'ajoutez pas d'enregistrement MX fictif sur votre serveur Zimbra.
Ensuite, testez une connexion TCP. Si ncelle est installée, utilisez :
nc -vz -w 10 mx.example.net 25Ou utilisez telnet mx.example.net 25-le s'il est disponible. Une connexion TCP réussie devrait générer un message de confirmation ; un serveur SMTP peut alors afficher un message d'accueil. Un délai d'attente dépassé indique que la négociation TCP n'a pas abouti. Un résultat « connexion refusée » est différent : l'hôte distant a répondu, mais n'a pas accepté la connexion à cette adresse et sur ce port.
Répétez le test pour chaque cible MX et, si possible, testez les chemins IPv4 et IPv6. Si le nom d'hôte est résolu en une adresse IPv6 mais que le serveur ne dispose d'aucune route IPv6 fonctionnelle, une tentative IPv6 peut échouer tandis que l'IPv4 fonctionne. Vérifiez la route et les journaux avant de modifier les paramètres de famille d'adresses de Postfix ; toute modification doit être spécifique à la version et au déploiement.
Vérifiez la politique de pare-feu du serveur sans la modifier au préalable. Sur les systèmes utilisant UFW :
sudo ufw status verboseUFW gère le trafic entrant et sortant. Si la politique de trafic sortant est restrictive, vérifiez les règles numérotées et assurez-vous que les connexions TCP au port distant 25 sont bloquées. N'ajoutez une règle d'autorisation de trafic sortant spécifique que si elle correspond à votre politique de sécurité et que le serveur est autorisé à envoyer des e-mails directement.
Le pare-feu de votre hôte peut autoriser la connexion tandis qu'un pare-feu en amont, un contrôle de sécurité du cloud, une liste de contrôle d'accès réseau (ACL) ou la politique de votre fournisseur d'hébergement la bloque. Demandez à votre fournisseur si le trafic TCP/25 sortant est autorisé dans ce cas précis, si une restriction au niveau du compte s'applique et si une procédure de validation ou de vérification est disponible. Les politiques variant selon le fournisseur, le compte, la région et le produit, un contrôle réussi du pare-feu local ne garantit pas que l'accès à Internet est autorisé.
Si vous gérez un pare-feu réseau, vérifiez ses règles de sortie et ses journaux pour l'adresse IP source du serveur Zimbra, l'adresse IP MX de destination, le protocole TCP et le port de destination 25. Une capture de paquets peut aider un administrateur expérimenté à distinguer les paquets SYN non traités des réponses bloquées au retour, mais ne capturez que les en-têtes pertinents et protégez les données opérationnelles. N'ouvrez pas le port 25 en entrée pour résoudre les délais d'attente en sortie ; il s'agit de flux de trafic distincts.
Si votre fournisseur d'accès ne prend pas en charge le protocole SMTP sortant direct, utilisez un relais SMTP autorisé. Renseignez-vous auprès de l'opérateur du relais sur son nom d'hôte, son port, les exigences TLS, la méthode d'authentification, les domaines d'expéditeur autorisés et les éventuelles exigences de liste blanche d'adresses IP. Configurez le relais via la méthode d'administration Zimbra compatible avec votre version ou suivez la procédure de modification Zimbra de votre organisation. Le guide de l'administrateur Zimbra précise qu'un relais doit être configuré lorsque la distribution basée sur le DNS n'est pas activée.
De nombreux fournisseurs proposent l'authentification sur le port 587 avec STARTTLS, mais la documentation du relais fait foi. Un relais peut exiger le port 465, une liste blanche d'adresses IP ou un connecteur spécifique au fournisseur. Ne présumez pas que le port 587 est ouvert ni que n'importe quel serveur SMTP public peut servir de relais. Conservez vos identifiants dans la configuration protégée recommandée, limitez leur accès et ne mentionnez jamais le mot de passe du relais dans un ticket d'assistance ou dans l'historique de votre session.
Après avoir configuré le relais, envoyez un message de test contrôlé à une boîte mail que vous gérez. Vérifiez dans le journal de messagerie Zimbra que la connexion s'établit bien avec le serveur relais et le port attendu, que l'authentification TLS réussit le cas échéant et que le relais accepte le message. En cas d'erreur SMTP, recherchez la cause du problème : il pourrait s'agir d'un problème d'authentification, de politique d'expéditeur, de TLS ou d'autorisation du relais, et non d'un délai d'attente dépassé sur le port 25.
Une fois la cause première corrigée et un test direct vers la destination ou le relais concluant, demandez une nouvelle tentative de livraison des messages en attente. Depuis le compte Zimbra, postqueue -fdemandez à Postfix de tenter la livraison des messages en attente.
su - zimbra
postqueue -fCette opération peut déclencher des tentatives de livraison pour de nombreux messages ; évitez donc de la répéter pendant une interruption de service. Vous pouvez également utiliser les commandes de file d'attente de la console d'administration, lorsqu'elles sont disponibles. Zimbra indique que la vidange de la file d'attente tente de livrer les messages des files d'attente différées, entrantes et actives. Vérifiez ensuite quelques messages et assurez-vous que le nombre de messages différés diminue et que les journaux indiquent une livraison réussie ou une nouvelle réponse SMTP exploitable.
| Observation | Probablement un prochain contrôle |
|---|---|
| Le domaine de destination a expiré. | Tester chaque hôte MX ; vérifier l’accessibilité de la destination et le filtrage distant. |
| De nombreux domaines expirent sur le port 25 | Vérifiez les règles de pare-feu sortantes, les routes et les restrictions du fournisseur. |
| La connexion TCP s'établit, puis SMTP renvoie un code 4xx ou 5xx. | Utilisez la réponse SMTP distante pour résoudre les problèmes liés aux politiques, à la réputation ou aux destinataires. |
| Le port 25 est bloqué par le fournisseur d'accès. | Demander l'accès ou configurer un relais authentifié approuvé. |
| Relay accepte le test, mais les anciens courriels restent en file d'attente. | Consultez les journaux, réessayez une fois la file d'attente, puis surveillez la livraison et les notifications de rejet. |
Utilisez une courte séquence de vérification : vérifiez que le DNS renvoie bien le serveur MX ou le relais attendu ; vérifiez qu’une connexion TCP est établie avec l’hôte et le port configurés ; envoyez un message de test contrôlé ; vérifiez que le serveur distant ou le relais l’a bien reçu ; puis consultez la file d’attente et les journaux des messages différés pour retrouver les messages originaux. Un test de connexion réussi ne prouve pas à lui seul que le destinataire a accepté le message, et un transfert réussi par un relais ne garantit pas la réception dans la boîte de réception.
Ne tentez pas de résoudre un problème de délai d'attente en augmentant le délai de connexion de Postfix. Ce smtp_connect_timeoutparamètre détermine la durée pendant laquelle le client SMTP attend d'établir une connexion TCP ; l'allonger ne permettra pas de rétablir le fonctionnement d'une route bloquée et risque d'allonger les délais de livraison. Évitez également de supprimer les messages en file d'attente ou de modifier leur durée de vie pour masquer le problème. Si des messages approchent de la durée de vie de rebond configurée, informez les utilisateurs concernés que la livraison est retardée et conservez les données de la file d'attente pendant la restauration de la route.
Comparez 10 outils de balayage ping pour une découverte rapide du réseau local, une analyse multiplateforme et la gestion des adresses IP. Découvrez ce qu'un balayage peut – et ne peut pas – vous révéler.
Comparez six outils de gestion de réseau pour la surveillance des performances, notamment la couverture SNMP, la cartographie, les alertes, les modèles de déploiement et les compromis en matière de coûts.
Comparez sept moniteurs de ping gratuits et open source, allant des suites réseau complètes aux sondes de latence ciblées, et choisissez celui qui convient le mieux à vos besoins en matière de disponibilité, de perte de paquets et d'historique.
Comparez les meilleurs analyseurs Wi-Fi pour Windows, iPhone et Android, incluant des outils pour la congestion des canaux, la couverture du signal, les cartes thermiques et le dépannage réseau.
Découvrez ce que signifie la QoS dans le domaine des réseaux, comment les marquages DSCP et les files d'attente de trafic priorisent la voix, la vidéo et les applications professionnelles, et ce que la QoS ne peut pas corriger.
Comparez les logiciels serveurs SFTP fiables pour Windows et Linux, notamment OpenSSH, Bitvise, SolarWinds et SFTPGo. Trouvez la solution idéale pour vos besoins en matière de sécurité et de transfert de fichiers.
Comparez sept outils de gestion d'adresses IP pour la découverte de sous-réseaux, la coordination DNS et DHCP, l'inventaire réseau et l'IPAM open source.
Mettez en place une surveillance réseau pratique avec une couverture claire des périphériques, des indicateurs de performance utiles, des alertes exploitables et une comparaison de SolarWinds NPM, PRTG et OpManager.
Comparez les outils d'analyse réseau pour la découverte rapide des périphériques, les analyses IP multiplateformes et la gestion des identités et des accès IP (IPAM) d'entreprise, avec des conseils pour adapter chaque option à votre réseau.
Utilisez l'option --traceroute de Nmap pour associer les sauts à un hôte autorisé, comprendre les résultats des sauts et du RTT, et résoudre les problèmes de réponses manquantes sans sur-analyse.
