Source: https://once-email.com/fr/blog/corecomponent Livraison et authentification · 22 mai 2025Mis à jour 23 août 2026 # Postfix vs Dovecot : rôles différents dans la réception des e-mails Situez Postfix, Dovecot, LMTP, la file et IMAP dans le trajet entrant, puis localisez une panne à partir de preuves. [Équipe d’ingénierie Once Email, Once Email author Équipe d’ingénierie Once Email]() Relu par Relecture technique Once Email Ce que ce guide vous aide à faire Déterminer si une panne entrante relève de SMTP, de la file, du stockage ou de l’accès IMAP. Guide de l’article Pourquoi cet article mérite votre attention **Analyse originale** Le guide suit un message de l’acceptation SMTP à la file, à la livraison LMTP, au stockage et à l’accès IMAP, puis attribue chaque signal à la composante réellement responsable. **Contexte des tendances** Postfix et Dovecot restent souvent associés, mais les conteneurs et panneaux masquent la frontière entre transfert, livraison finale et accès à la boîte, ce qui favorise les mauvais diagnostics. **Valeur pratique** Les opérateurs disposent d’un tableau de décision et d’un ordre de vérification séparant rejet SMTP, report en file, erreur d’écriture et problème IMAP sans journaliser de contenu sensible. Postfix et Dovecot sont souvent installés ensemble, mais n’ont pas la même fonction. Dans un système récepteur courant, **Postfix accepte SMTP et gère la file**, tandis que **Dovecot assure la livraison finale ou expose la boîte avec LMTP et IMAP**. Un service actif ne prouve pas le bon fonctionnement du parcours complet. Cette page est une carte de diagnostic, pas une recette de production. DNS, TLS, validation des destinataires, lutte contre les abus, permissions, sauvegardes, supervision et restrictions de relais exigent une conception dédiée. Once Email reçoit seulement les messages et ne fournit ni envoi SMTP, ni réponse, ni transfert, ni envoi massif. ## [Comparaison rapide]() | Question | Postfix | Dovecot | | --- | --- | --- | | Rôle réseau principal | Reçoit ou envoie par SMTP | Offre IMAP/POP3 et peut recevoir par LMTP | | Possède la file | Oui | Non | | Accepte le destinataire SMTP | Généralement Postfix avec ses tables et règles | Peut fournir des données utilisateurs selon l’architecture | | Écrit dans la boîte finale | Localement ou en déléguant | LMTP Dovecot peut livrer finalement | | Permet au client de lire | Non | Oui, généralement via IMAP | « Postfix ou Dovecot » est donc rarement un choix de produit. Pour une boîte hébergée, il faut savoir où s’arrête une responsabilité et où commence la suivante. ## [Suivre un message entrant]() L’[architecture officielle Postfix]() montre le courrier réseau entrant par ` smtpd `, passant par cleanup et arrivant dans une file. Le gestionnaire sélectionne ensuite un agent. Quatre points de contrôle apparaissent : 1. **Connexion SMTP :** le serveur distant atteint Postfix et négocie la transaction. 2. **Acceptation :** Postfix accepte ou rejette le destinataire d’enveloppe selon tables et règles. 3. **File et transfert :** le message accepté part vers local, virtual, pipe ou LMTP. 4. **Accès :** après livraison, Dovecot autorise un client à lister et lire par IMAP. Un ` 250 ` SMTP ne signifie pas que le message est visible. Postfix peut accepter puis reporter pour cause LMTP, quota ou stockage. Inversement, le fichier peut exister mais rester invisible à cause de l’authentification IMAP, d’un index, d’un espace de noms ou de permissions. ## [LMTP relie les responsabilités]() LMTP constitue une frontière courante. Postfix conserve SMTP et la file, puis appelle Dovecot pour la livraison finale. Le [guide LMTP de Dovecot]() présente un socket Unix protégé dans le spool Postfix. Ce socket n’est pas qu’un chemin copié. Propriétaire, groupe, mode, emplacement chroot et disponibilité forment un contrat. Si Postfix ne peut pas le joindre, le comportement attendu est généralement un élément reporté, pas une boîte présentée comme vide. Après acceptation LMTP, quota et stockage deviennent les preuves prioritaires. Ne rendez pas le socket accessible en écriture à tous. Identifiez le compte de service nécessaire et accordez le minimum. N’exposez pas LMTP publiquement sans architecture explicite d’authentification et de transport protégé. ## [Diagnostiquer à partir des preuves]() | Preuve observée | Première frontière à examiner | | --- | --- | | Connexion impossible au port 25 | DNS, pare-feu, TLS ou ` smtpd ` Postfix | | Destinataire rejeté avant le corps | Tables et règles Postfix, éventuellement annuaire consulté | | SMTP accepte, message toujours deferred | File Postfix et transport sélectionné | | Socket LMTP absent ou permission refusée | Liaison Postfix–Dovecot et permissions | | LMTP signale quota ou écriture impossible | Livraison Dovecot et stockage | | Fichier présent, mais absent d’IMAP | Authentification, namespace, index et droits Dovecot | Utilisez un marqueur unique et une fenêtre limitée. Conservez l’ID de file, la classe SMTP, le résultat LMTP et un résultat de boîte expurgé. Adresse réelle, code, jeton, objet, corps, nom de pièce jointe et URL complète ne doivent pas entrer dans des journaux partagés ou l’analytique. ## [Constituer une trace à quatre champs avant toute modification]() Pour un seul message de test autorisé, conservez quatre faits expurgés. Ensemble, ils indiquent si acceptation, file, remise finale et visibilité concernent la même transaction : | Point | Conserver | Ce que cela prouve | | --- | --- | --- | | Acceptation SMTP | Heure, classe de statut étendu et ID de file abrégé | Postfix a accepté la transaction, pas nécessairement la remise finale | | Résultat de file | Même ID abrégé, transport et état delivered/deferred | Postfix a choisi un transport et terminé ou retenu la remise | | Résultat LMTP | Succès ou classe d’erreur sans destinataire ni contenu | LMTP Dovecot a accepté la remise finale ou renvoyé une cause bornée | | Visibilité | Compteurs avant/après et résultat de lecture applicatif | Le stockage a changé et le vrai chemin de lecture voit ou non le résultat | Commencez en lecture seule. ` postqueue -p ` liste la file ; filtrez localement sur l’ID abrégé sans exporter toute la file. ` doveadm mailbox status -u TEST_USER "messages unseen" INBOX ` consulte les compteurs avec une identité de test autorisée uniquement. Les références officielles des [outils de file Postfix]() et de [l’état de boîte Dovecot]() définissent ces observations. Sans concordance de l’heure et du marqueur expurgé, elles ne prouvent pas qu’il s’agit du même message. ## [Erreurs de catégorie et ordre sûr]() Installer Dovecot ne crée pas d’écoute SMTP ; installer Postfix ne fournit pas de boîte IMAP. SPF, DKIM et DMARC appartiennent à une autre couche : authentification et alignement, pas accès. Consultez le [guide SPF, DKIM et DMARC]() . Une file vide ne prouve pas la réussite : le message a pu rebondir, expirer, être supprimé par une règle explicite ou être déjà parti. Une boîte vide ne prouve pas l’absence : requête échouée, client hors ligne ou autre namespace restent possibles. Séparez « aucun résultat », « échec temporaire » et « vide confirmé ». Vérifiez le point SMTP, envoyez un seul test autorisé, relevez l’acceptation Postfix, suivez file et livraison, confirmez la boîte Dovecot puis lisez-la par le même chemin IMAP que l’application. Supprimez la boîte de test et ne gardez que des preuves expurgées. Redémarrer les deux services avant observation détruit les repères temporels et la file sans expliquer la cause. ## Guides associés Comment lire les en-têtes reçus et tracer un chemin de livraison d'e-mails Suivez les champs d'en-tête Reçus dans le bon ordre, comparez les horodatages en toute sécurité et reconnaissez les limites des noms d'hôte, des adresses IP et des données de trace non fiables. [Comment lire les en-têtes reçus et tracer un chemin de livraison d'e-mails]() Comment utiliser une API de messagerie temporaire sans créer de tests instables Une conception pratique pour les tests d'API de messagerie temporaire : isolez chaque exécution, interrogez avec interruption, identifiez le bon message, protégez les secrets et faites toujours le ménage. [Comment utiliser une API de messagerie temporaire sans créer de tests instables]() L'e-mail de vérification n'arrive pas ? Une liste de contrôle de dépannage sécurisé Gérez les erreurs d'adresse, les retards des expéditeurs, les tentatives, le filtrage et les limites des boîtes aux lettres sans demander de codes à plusieurs reprises ni affaiblir la sécurité du compte. [L'e-mail de vérification n'arrive pas ? Une liste de contrôle de dépannage sécurisé]() ## Outils e-mail axés sur la confidentialité Analyseur d’en-têtes d’e-mail Explique les étapes de livraison et résume SPF, DKIM et DMARC sans garantir une authenticité absolue. [Analyseur d’en-têtes d’e-mail]() [Télécharger de nombreuses pièces jointes et les extraire localement avec UnpackFlow Utilisez un dossier dédié, vérifiez chaque téléchargement puis traitez les archives multiparties ou imbriquées avec list, plan, run ou start.]() [Combien de temps dure un e-mail temporaire ? Plan avant son expiration Comprenez les choix à vie, la suppression et le remplacement du Once Email, puis décidez quoi sauvegarder et quand un compte a besoin d'une adresse de récupération permanente.]()