Échecs de connexion IMAP avec Dovecot : où l’authentification échoue et comment y remédier

Comment l’authentification IMAP de Dovecot fonctionne réellement (et où elle casse)

L’authentification Dovecot est une chaîne de traitement. Votre client parle IMAP au service IMAP. Ce service transmet les identifiants au service d’auth de Dovecot. L’auth consulte un ou plusieurs backends passdb pour vérifier le secret, puis un ou plusieurs backends userdb pour mapper l’utilisateur vers un UID/GID/home/emplacement mail. Ensuite le processus IMAP tente d’ouvrir la boîte aux lettres avec ces identifiants et permissions système de fichiers. Si une étape échoue, l’utilisateur voit la même chose : « Échec de connexion ». C’est pourquoi on ne peut pas dépanner au feeling.

Les étapes à garder en tête

1. Étape réseau/TLS : le client atteint le serveur ; TLS négocie si c’est requis.
2. Étape protocole IMAP : le client envoie LOGIN/AUTHENTICATE ; le serveur propose des mécanismes (PLAIN, LOGIN, SCRAM, OAUTHBEARER, etc.).
3. Étape auth Dovecot : le processus auth (et ses workers) exécute les vérifications passdb.
4. Étape mapping utilisateur : userdb résout UID/GID/home/mail ; des champs supplémentaires optionnels (quota, namespaces, ACL) peuvent être injectés.
5. Étape accès à la boîte : Dovecot ouvre le stockage mail (Maildir, mdbox, sdbox, etc.), acquiert des verrous, lit les index.

Vous recherchez la première étape qui échoue. Tout ce qui suit n’est que dégâts collatéraux.

Un avis utile à adopter : considérez les échecs d’auth comme un problème d’observabilité d’abord, et un problème de configuration ensuite. On ne répare pas ce qu’on ne voit pas.

Une citation pour rester honnête : « L’espoir n’est pas une stratégie. » — Gen. Gordon R. Sullivan

Petite blague #1 : Les bugs d’authentification sont comme les oignons : ils ont des couches, et ils font pleurer quelqu’un. Généralement l’astreinte.

Playbook de diagnostic rapide (vérifications 1re/2e/3e)

Ceci est le chemin le plus court vers la cause racine quand les connexions IMAP échouent. Exécutez-le dans l’ordre. Ne sautez pas d’étapes parce que vous « savez déjà ». C’est comme ça que les incidents passent d’agaçants à légendaires.

Première étape : confirmez ce qui échoue réellement (TLS, auth ou boîte mail)

• Vérifiez les journaux pour la ligne d’erreur canonique (auth failed vs. userdb vs. mail permission).
• Reproduisez avec un chemin client connu bon (doveadm auth test et un contrôle IMAP openssl s_client).

Deuxième étape : isolez le pipeline d’auth Dovecot (passdb/userdb)

• Utilisez doveconf -n pour voir la configuration active (pas ce que vous pensez avoir déployé).
• Testez passdb (vérification du mot de passe) et testez userdb (UID/GID/home/mail).
• Surveillez les échecs des workers (timeouts, permissions de socket d’auth, connectivité SQL/LDAP).

Troisième étape : validez l’accès au stockage en tant qu’utilisateur mappé

• Confirmez l’UID/GID que Dovecot choisit et si cet utilisateur peut lire le stockage mail.
• Recherchez des erreurs de verrou/index qui se déguisent en problèmes de connexion (surtout avec mdbox et des stockages de type NFS).

Si vous exécutez seulement ces trois étapes, vous résoudrez la plupart des tickets « IMAP login failed » avec moins de drame et moins de rituels « redémarrons tout ».

Faits intéressants et contexte historique (court, utile et un peu nerd)

• IMAP précède les stacks modernes d’« identité ». IMAP s’est développé avec une authentification simple par nom d’utilisateur/mot de passe ; ajouter OAuth est un ravalement de façade tardif.
• Dovecot est devenu populaire en partie parce qu’il soigne le stockage mail. La performance et l’intégrité des boîtes mail étaient des différenciateurs majeurs face aux anciens serveurs IMAP.
• CRAM-MD5 existe car les mots de passe en clair faisaient peur dès les années 1990. C’est aussi un rappel que « sécurisé legacy » peut devenir une « responsabilité moderne ».
• STARTTLS sur IMAP (port 143) est historiquement courant en entreprise. Mais TLS implicite sur 993 est opérationnellement plus simple car moins de middleboxes le dégradent.
• L’auth de Dovecot est scindé en processus master/auth/workers. Cette séparation réduit le rayon d’impact : un worker auth qui plante ne devrait pas faire tomber tout le service IMAP.
• Maildir vs mdbox n’est pas qu’une préférence. Cela change le comportement de verrouillage, les motifs d’index et les modes de défaillance (surtout sur stockage réseau).
• « userdb » n’est pas optionnel en pratique. Même si passdb réussit, un mapping userdb incorrect peut faire échouer les connexions ou provoquer des erreurs d’ouverture de mail qui ressemblent à des problèmes d’auth.
• Les discordances UID/GID sont une classique post-migration. Les anciens serveurs et les nouveaux ne sont pas d’accord sur les identifiants numériques, et les maildirs n’en ont rien à faire de vos sentiments.

Tâches pratiques : commandes, sorties attendues et décisions (12+)

Ce sont des tâches éprouvées sur le terrain que vous pouvez lancer sous pression. Chaque item inclut : la commande, ce que la sortie signifie, et la décision à prendre ensuite.

Task 1: Confirm Dovecot is actually running and listening

cr0x@server:~$ systemctl status dovecot
● dovecot.service - Dovecot IMAP/POP3 email server
     Loaded: loaded (/lib/systemd/system/dovecot.service; enabled)
     Active: active (running) since Mon 2026-01-03 09:12:19 UTC; 2h 3min ago
...

Meaning: If it’s not active, you don’t have an “auth problem,” you have a “service is down” problem.

Decision: If inactive/failed, inspect journalctl -u dovecot before restarting. If active, move on.

cr0x@server:~$ ss -lntp | egrep ':143|:993'
LISTEN 0 100 0.0.0.0:143 0.0.0.0:* users:(("dovecot",pid=1123,fd=45))
LISTEN 0 100 0.0.0.0:993 0.0.0.0:* users:(("dovecot",pid=1123,fd=46))

Meaning: Ports are bound. If 993 is missing, TLS-only clients fail. If 143 is missing, STARTTLS deployments fail.

Decision: Match what clients expect. Don’t guess; verify the client config or the last known-good baseline.

Task 2: Read the last 200 Dovecot log lines like a human

cr0x@server:~$ journalctl -u dovecot -n 200 --no-pager
Jan 03 10:58:12 mail dovecot[22144]: imap-login: Disconnected (auth failed, 1 attempts): user=<alice@example.com>, method=PLAIN, rip=203.0.113.50, lip=192.0.2.10, TLS, session=<...>
Jan 03 10:58:14 mail dovecot[22144]: auth: passwd-file(alice@example.com,203.0.113.50): unknown user

Meaning: The IMAP login service reports “auth failed”; the auth service says “unknown user.” That’s not a bad password; that’s a lookup failure.

Decision: Focus on passdb/userdb configuration and identity normalization (usernames, domains), not password hashes.

Task 3: Dump the effective Dovecot config (not the one you think you deployed)

cr0x@server:~$ doveconf -n
auth_mechanisms = plain login
disable_plaintext_auth = yes
mail_location = maildir:/var/vmail/%d/%n/Maildir
passdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
userdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
ssl = required

Meaning: This is the truth Dovecot is running with. doveconf -n shows overrides and resolved values.

Decision: If the config doesn’t match expectations, stop. Fix deployment/config management first; troubleshooting the wrong config is performance art.

Task 4: Test auth without IMAP clients (passdb verification)

cr0x@server:~$ doveadm auth test alice@example.com 'CorrectHorseBatteryStaple'
passdb: alice@example.com auth succeeded
extra fields:
  user=alice@example.com

Meaning: Password verification works. If IMAP still fails, the break is likely TLS, SASL mechanism mismatch, userdb mapping, or mailbox access.

Decision: Run a userdb lookup next, then reproduce via IMAP with debug logs.

cr0x@server:~$ doveadm auth test alice@example.com 'wrongpassword'
passdb: alice@example.com auth failed

Meaning: That’s a real password failure. Now you check hashing, SQL query correctness, or upstream identity provider if applicable.

Decision: Don’t touch filesystem permissions yet. You haven’t earned that detour.

Task 5: Test userdb mapping (UID/GID/home/mail location)

cr0x@server:~$ doveadm user alice@example.com
field	value
uid	vmail
gid	vmail
home	/var/vmail/example.com/alice
mail	maildir:/var/vmail/example.com/alice/Maildir

Meaning: Dovecot knows where the mailbox should live and under which user/group it will access it.

Decision: If UID/GID are missing or wrong, fix userdb query or static mapping. If they look right, validate the filesystem next.

Task 6: Validate SQL connectivity and the exact queries Dovecot runs

cr0x@server:~$ doveadm -Dv auth test alice@example.com 'CorrectHorseBatteryStaple'
...
sql(alice@example.com): query: SELECT username, password FROM users WHERE username = 'alice@example.com'
sql(alice@example.com): result: username=alice@example.com password={BLF-CRYPT}$2y$10$...
passdb: alice@example.com auth succeeded
...
sql(alice@example.com): query: SELECT home, uid, gid FROM users WHERE username = 'alice@example.com'
sql(alice@example.com): result: home=/var/vmail/example.com/alice uid=vmail gid=vmail

Meaning: You can see real queries and results. This is gold when your SQL config “looks right” but isn’t.

Decision: If queries return no rows, fix schema/where clause/username normalization. If they’re slow, check DB latency and indexes.

Task 7: Check auth worker health and timeouts

cr0x@server:~$ journalctl -u dovecot --no-pager | egrep 'auth-worker|timeout|BUG|panic' | tail -n 30
Jan 03 10:41:02 mail dovecot[1128]: auth-worker(21987): Error: sql(alice@example.com): Connection timed out
Jan 03 10:41:02 mail dovecot[1128]: auth: Error: auth-worker exited unexpectedly

Meaning: Your auth failures are downstream of dependency timeouts. The DB/LDAP is the real incident.

Decision: Treat this like a dependency outage: check DB reachability, pool limits, TLS to DB, and network policy.

Task 8: Reproduce an IMAP login manually over TLS to separate protocol/TLS from Dovecot internals

cr0x@server:~$ openssl s_client -connect 127.0.0.1:993 -crlf -quiet
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
a login alice@example.com "CorrectHorseBatteryStaple"
a OK [CAPABILITY IMAP4rev1 SASL-IR ...] Logged in

Meaning: TLS works, and IMAP login succeeds from localhost. If remote users still fail, you likely have firewall/NAT/TLS interception issues or client-side mechanism constraints.

Decision: Compare remote path vs local path. Check certificates, SNI, and whether a load balancer terminates TLS correctly.

cr0x@server:~$ openssl s_client -connect 127.0.0.1:993 -crlf -quiet
* OK Dovecot ready.
a login alice@example.com "wrongpassword"
a NO [AUTHENTICATIONFAILED] Authentication failed.

Meaning: Now you have a clean reproduction of a real auth failure. The logs should line up with this session.

Decision: Enable targeted auth debug and re-test once, not for an hour.

Task 9: Check TLS certificate validity and chain quickly

cr0x@server:~$ openssl s_client -connect mail.example.com:993 -servername mail.example.com -showcerts /dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = mail.example.com
issuer=CN = Example Issuing CA
notBefore=Dec 15 00:00:00 2025 GMT
notAfter=Mar 15 23:59:59 2026 GMT

Meaning: If the cert is expired or wrong CN/SAN, many clients will fail before auth even begins.

Decision: Fix the certificate and chain first. Don’t “work around” TLS failures with plaintext auth in 2026.

Task 10: Verify the auth socket permissions (common when integrating Postfix SASL too)

cr0x@server:~$ ls -l /var/spool/postfix/private/auth
srw-rw---- 1 postfix dovecot 0 Jan  3 10:12 /var/spool/postfix/private/auth

Meaning: Socket exists and is writable by Postfix. Wrong ownership/mode causes SASL auth failures for SMTP, and sometimes people confuse that with IMAP login issues.

Decision: If permissions are wrong, fix service auth { unix_listener ... } and reload Dovecot.

Task 11: Confirm the mapped mailbox path exists and is accessible

cr0x@server:~$ getent passwd vmail
vmail:x:5000:5000::/var/vmail:/usr/sbin/nologin

cr0x@server:~$ sudo -u vmail test -d /var/vmail/example.com/alice/Maildir && echo OK || echo NO
OK

Meaning: The mailbox exists and the runtime user can see it. If this fails, Dovecot may authenticate the password but still refuse the login or error right after.

Decision: Fix ownership/permissions, or fix userdb mapping so Dovecot points to the real location.

Task 12: Look for “looks like auth” but is actually mailbox/index corruption or lock errors

cr0x@server:~$ journalctl -u dovecot --no-pager | egrep 'Permission denied|Corrupted|Mailbox is locked|Index' | tail -n 40
Jan 03 11:02:31 mail dovecot[23102]: imap(alice@example.com): Error: open(/var/vmail/example.com/alice/Maildir/dovecot.index) failed: Permission denied

Meaning: Auth might be fine; mailbox open is failing. Users still experience it as “can’t log in” because the session drops immediately after login or during SELECT INBOX.

Decision: Fix filesystem ACLs/ownership. Then consider rebuilding indexes if needed (carefully).

Task 13: Turn on targeted auth debug (safely) to catch the exact break

cr0x@server:~$ sudo doveconf -n | egrep 'auth_debug|auth_verbose|mail_debug'

cr0x@server:~$ sudo sed -i 's/^#\?auth_verbose.*/auth_verbose = yes/' /etc/dovecot/conf.d/10-logging.conf
cr0x@server:~$ sudo sed -i 's/^#\?auth_debug.*/auth_debug = yes/' /etc/dovecot/conf.d/10-logging.conf
cr0x@server:~$ sudo systemctl reload dovecot

Meaning: You’ve increased auth visibility. Do this briefly in production; it can leak metadata into logs.

Decision: Reproduce once, capture the relevant lines, then turn it back off.

Task 14: Validate PAM behavior when using system users (common on smaller systems)

cr0x@server:~$ doveconf -n | egrep 'passdb|pam'
passdb {
  driver = pam
}

cr0x@server:~$ sudo tail -n 50 /var/log/auth.log
Jan 03 11:11:10 mail dovecot: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser= rhost=203.0.113.50  user=bob

Meaning: PAM is rejecting the login. The failure may be wrong password, locked account, expired password policy, or PAM module order.

Decision: Check account status and PAM stack. Don’t “fix” Dovecot when PAM is doing exactly what it was told.

Où l’auth échoue : modes de défaillance par étape

Étape 1 : Réseau et TLS (les échecs qui ressemblent à « auth »)

Les clients confondent souvent la connectivité et l’authentification en une même erreur visible par l’utilisateur. Votre travail consiste à les séparer.

• Firewall/NAT : certains utilisateurs réussissent, d’autres échouent. Vérifiez les security groups et les listes d’autorisation IP/geo.
• Mismatch de handshake TLS : des clients anciens exigent des chiffres hérités ; les serveurs modernes les refusent. Ou un middlebox intercepte TLS et ré-encrypte avec un certificat différent.
• Mismatch SNI/certificat : les configurations multi-domaines échouent si le client atteint le mauvais nom ou si le proxy ne transmet pas le SNI.

Réparez TLS en premier. Désactiver l’exigence TLS pour « faire entrer les utilisateurs » revient à retirer les freins pour faire aller la voiture plus vite en descente.

Étape 2 : Négociation du mécanisme IMAP

Dovecot annonce les mécanismes via CAPABILITY. Les clients choisissent selon leur politique. Les incompatibilités sont prévisibles :

• disable_plaintext_auth = yes sans TLS : le client tente PLAIN/LOGIN sans chiffrement et se voit refusé.
• Mécanismes retirés : vous avez désactivé LOGIN et le client ne peut pas faire PLAIN avec SASL-IR, ou ne peut pas faire SCRAM. Résultat : « authentication failed » mais en réalité « pas de mécanisme compatible ».
• OAuth/OAUTHBEARER : les clients modernes peuvent tenter OAUTHBEARER en premier ; si votre backend est à moitié configuré, vous verrez des retours confus.

Étape 3 : échec passdb (problèmes d’authentification réels)

passdb est l’endroit où le secret est vérifié. Les échecs sont généralement :

• Utilisateur introuvable : la requête SQL/LDAP ne renvoie aucune ligne. Causes courantes : mauvais filtre, mauvais domaine, format de nom d’utilisateur inattendu, espaces en fin, ou sensibilité à la casse.
• Incompatibilité de hash : mismatch de schéma de hachage (bcrypt vs SHA512-CRYPT), mauvais champ de requête, ou le hachage stocké a été « utilement » réencodé.
• Défaillance de dépendance : timeouts DB, échecs TLS LDAP, problèmes DNS, épuisement des pools de connexions.

Étape 4 : échec userdb (vous êtes authentifié, mais vous ne pouvez pas devenir l’utilisateur)

C’est le tueur silencieux. passdb dit oui, userdb dit « je ne sais pas qui vous êtes », et la session meurt.

• UID/GID manquants : Dovecot ne peut pas déterminer quel utilisateur utiliser, ou utilise des valeurs par défaut qui ne correspondent pas à la propriété des boîtes mail.
• Mauvais home/mail path : userdb pointe vers un chemin inexistant, ou un serveur utilise /var/mail/vhosts tandis qu’un autre utilise /var/vmail.
• Surcharges par-utilisateur mal configurées : vous injectez le champ mail ou des paramètres de namespace par utilisateur et vous cassez accidentellement un sous-ensemble.

Étape 5 : échec d’accès à la boîte (auth réussi, mais la réalité refuse)

Signes classiques : les utilisateurs « se connectent » mais sont immédiatement déconnectés, ou INBOX ne peut pas être sélectionnée, ou seulement certains dossiers fonctionnent.

• Permissions système de fichiers : mauvais UID/GID, absence du bit exécution sur des répertoires, ACL non appliquées, ou refus SELinux/AppArmor.
• Problèmes d’index et de verrou : index corrompus, timeouts de verrou, ou stockage qui n’honore pas le verrouillage POSIX.
• Comportement du plugin quota : avertissements de quota ou échecs sévères empêchant les append ; certains clients interprètent cela comme un « problème de connexion ».

Petite blague #2 : Si vous avez « réparé » IMAP en redémarrant Dovecot, félicitations—vous avez découvert l’équivalent informatique de l’éteindre et le rallumer.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptôme : « Authentication failed » immédiatement pour tous les utilisateurs

Cause racine : backend passdb inaccessible (SQL/LDAP en panne, échec DNS, TLS vers la base cassé), ou les workers d’auth ne peuvent pas se connecter.

Correctif : Confirmez avec doveadm -Dv auth test et les journaux montrant des timeouts. Rétablissez la connectivité DB/LDAP, vérifiez les règles de pare-feu, et vérifiez les identifiants dans dovecot-sql.conf.ext.

2) Symptôme : seuls les utilisateurs distants échouent ; les tests localhost réussissent

Cause racine : interception TLS/proxy mal configuré, mismatch SNI, ou différences de politique réseau (WAF, blocage géographique).

Correctif : Comparez openssl s_client depuis un hôte distant, vérifiez la chaîne de certificats, et assurez-vous que le proxy transmet SNI et ALPN comme attendu.

3) Symptôme : « Unknown user » pour des utilisateurs qui existent

Cause racine : normalisation du nom d’utilisateur erronée : le client envoie alice mais la DB stocke alice@example.com, ou inversement ; ou la suppression/ajout de domaine lors d’une migration.

Correctif : Décidez d’un format canonique de nom d’utilisateur. Mettez à jour auth_username_format de Dovecot et les requêtes SQL/LDAP en conséquence. Vérifiez avec la sortie debug montrant la requête.

4) Symptôme : certains utilisateurs peuvent se connecter ; d’autres non ; le pattern correspond à un domaine

Cause racine : bug de mapping multi-domaine : gestion de %d dans mail_location, ligne de domaine manquante dans la DB, ou mismatch de configuration proxy/virtual host.

Correctif : Exécutez doveadm user user@domain pour les domaines affectés et comparez les chemins home/mail résolus.

5) Symptôme : la connexion réussit, puis déconnexion immédiate ou « Mailbox doesn’t exist »

Cause racine : userdb pointe vers le mauvais chemin de boîte ; ou les permissions du stockage mail empêchent Dovecot de lire les index.

Correctif : Validez les champs via doveadm user, puis testez l’accès aux répertoires avec sudo -u vmail. Corrigez la propriété et les chemins.

6) Symptôme : ça marche un moment, puis l’auth commence à timeout sous charge

Cause racine : saturation des workers d’auth : limites de pool DB, coût de hachage des mots de passe trop élevé, ou latence LDAP. Les workers d’auth de Dovecot font la queue.

Correctif : Mesurez la latence DB, ajoutez des index, ajustez les tailles de pool, et envisagez un cache avec précaution. Augmentez le nombre de workers d’auth seulement après avoir confirmé que le backend peut suivre.

7) Symptôme : « Plaintext authentication disallowed »

Cause racine : disable_plaintext_auth = yes tandis que les clients tentent LOGIN/PLAIN sans TLS, souvent du fait que STARTTLS n’est pas utilisé.

Correctif : Activez TLS implicite sur 993 ou assurez-vous que STARTTLS est activé et que les clients sont configurés pour l’utiliser. Ne relâchez pas la sécurité pour accommoder des clients cassés sans plan.

8) Symptôme : après migration, les mots de passe de tout le monde « ont cessé de fonctionner »

Cause racine : incompatibilité du schéma de hachage, ou le contenu du champ DB a été transformé (tronqué, encodage changé, espaces ajoutés).

Correctif : Confirmez les schémas de hachage supportés par Dovecot et le format stocké. Testez un utilisateur avec doveadm auth test et confirmez que le préfixe du hash retourné correspond au schéma attendu.

Trois mini-récits d’entreprise issus de la production

Incident causé par une mauvaise hypothèse : « C’est juste le mot de passe »

La tempête de tickets a commencé un lundi matin, ce qui est déjà un crime. Un bureau régional ne pouvait plus se connecter à l’IMAP après un « changement de sécurité routine ». Le récit de l’assistance était simple : « les mots de passe ne fonctionnent plus ». La première réponse fut prévisible : réinitialisations, encore des réinitialisations, et quelques réinitialisations exécutives pour faire bonne mesure.

Du côté mail, rien n’était manifestement tombé. Dovecot tournait bien. SQL était joignable. doveadm auth test réussissait pour plusieurs utilisateurs. C’est à ce moment que l’histoire change : ce n’est pas les mots de passe. C’est le chemin client.

Il s’est avéré que le « changement de sécurité routine » était une politique d’inspection TLS poussée sur le proxy sortant de ce bureau. Le proxy re-sig­nait les certificats avec une CA interne que leurs machines Windows faisaient confiance, mais plusieurs clients mobiles non. Ces clients échouaient le handshake TLS et rapportaient « erreur d’authentification » parce que l’UX de l’appli jugeait que c’était suffisamment proche.

La correction n’était pas dans Dovecot. La correction a été : arrêter d’intercepter l’IMAPS, ou déployer la CA sur les appareils qui en ont besoin, et rendre la politique explicite. La leçon importante : si l’IMAP local fonctionne mais que le distant échoue, vous ne déboguez pas l’authentification — vous déboguez le chemin entre l’utilisateur et le port.

Et arrêtez de réinitialiser les mots de passe comme outil de diagnostic. Cela détruit le signal et encourage l’organisation à résoudre des problèmes techniques par rituel.

Optimisation qui s’est retournée contre eux : « Augmentons les workers d’auth »

Un autre environnement avait des échecs de connexion intermittents aux heures de pointe. Les journaux Dovecot montraient des timeouts d’auth en parlant au backend SQL. Quelqu’un a remarqué que Dovecot avait une option configurable pour le nombre de workers d’auth et a décidé d’« augmenter le parallélisme » comme optimisation. Ils ont poussé plus de workers et déclaré victoire après cinq minutes tranquilles.

L’heure de pointe est revenue, et le système s’est effondré plus violemment. Pourquoi ? Parce que la base n’était pas lente à cause d’un manque de concurren-ce, mais à cause de contentions. Plus de workers d’auth = plus de connexions SQL concurrentes = plus de contentions de verrou = requêtes plus lentes = files d’attente d’auth plus longues. Le service d’auth ne s’est pas juste trompé ; il s’est planté bruyamment.

La correction finale fut ennuyeuse mais efficace : ajouter l’index adéquat pour la recherche de nom d’utilisateur, réduire le coût des requêtes, et dimensionner le pool de connexions DB avec intention. Le nombre de workers de Dovecot est revenu à une valeur sensée. Le système s’est stabilisé sans théâtre.

La leçon : si votre backend est le goulot, le parallélisme n’est pas un repas gratuit. C’est une facture avec intérêts.

Pratique ennuyeuse mais correcte qui a sauvé la mise : « On avait un test d’auth connu bon et des journaux »

Une mise à niveau de cluster mail a introduit une régression subtile : un sous-ensemble d’utilisateurs pouvait s’authentifier mais était déconnecté en accédant à INBOX. L’incident aurait pu dégénérer rapidement car le symptôme ressemblait à un échec d’auth pour les applis clients. Mais l’équipe avait une habitude qui paraît ennuyeuse jusqu’au moment où elle sert : une check-list pré-upgrade et post-upgrade avec des tests doveadm et une petite banque de comptes synthétiques.

En quelques minutes, ils ont confirmé que passdb fonctionnait et que le mapping userdb retournait des valeurs correctes. Puis ils ont utilisé un des comptes synthétiques pour se connecter via openssl s_client et ont vu une erreur juste après la connexion : un refus de permission sur un index dans le nouvel emplacement de mail. Cela a réduit le champ aux permissions/organisation du système de fichiers, pas aux identifiants.

La cause racine était une étape manquante dans le déploiement : une routine de création de répertoire exécutée en root avait créé de nouveaux répertoires d’index par utilisateur avec la propriété root. Les utilisateurs existants avaient des répertoires appartenant à vmail, mais les nouveaux chemins étaient root-owned. Classique séparation par propriété.

La correction fut une remise en place ciblée des propriétaires et un hook de déploiement pour créer les répertoires avec le bon UID/GID. Pas de réinitialisations de mot de passe. Pas de redémarrages aléatoires. Juste un diagnostic contrôlé et un changement qui a rendu le système moins fragile.

La leçon : testez les choses ennuyeuses avant de livrer. C’est moins cher qu’un appel d’incident où tout le monde dit « ça marchait hier » comme si c’était un indicateur.

Listes de contrôle / plan étape par étape (ennuyeux volontairement)

Plan étape par étape quand la connexion IMAP échoue

1. Confirmez la portée : un utilisateur, un domaine, un segment réseau, ou global ?
2. Capturez une seule reproduction : heure, nom d’utilisateur, IP source, type de client, et si c’est 993 ou STARTTLS sur 143.
3. Vérifiez les journaux Dovecot en premier : identifiez s’il indique auth failed, unknown user, userdb missing, ou permission denied.
4. Exécutez doveconf -n : vérifiez que vous dépannez la configuration active.
5. Exécutez doveadm auth test : confirmez le comportement passdb indépendamment d’IMAP.
6. Exécutez doveadm user : confirmez le mapping userdb et les champs de localisation mail.
7. Reproduisez via openssl s_client : validez TLS et la négociation des capacités/mécanismes IMAP.
8. Vérifiez les dépendances backend : connectivité SQL/LDAP, timeouts, TLS, identifiants, limites de pool.
9. Vérifiez les permissions système de fichiers en tant qu’utilisateur runtime : home, maildir, et fichiers d’index.
10. Activez brièvement le debug auth ciblé si nécessaire : reproduisez une fois, capturez, désactivez le debug.
11. Corrigez la cause racine : config, backend, ou permissions — pas les symptômes.
12. Vérifiez avec trois chemins : doveadm, IMAPS localhost, IMAPS distant.

Checklist opérationnelle pour les changements qui cassent souvent l’auth

• Renouvellements de certificats TLS : vérifiez les dates notAfter et la chaîne avant le déploiement.
• Changements de schéma DB : vérifiez que les requêtes SQL exactes de Dovecot retournent encore des lignes.
• Changements de format des noms d’utilisateur : décidez d’un format canonique et appliquez-le uniformément.
• Migrations de stockage : vérifiez la propriété UID/GID, et testez l’ouverture de boîtes, pas seulement l’auth.
• Modifications proxy/LB : confirmez SNI, pass-through vs termination, et le logging d’IP source.
• Renforcement de la sécurité : vérifiez auth_mechanisms et la compatibilité client avant de désactiver les méthodes héritées.

FAQ

1) Pourquoi Dovecot indique-t-il « auth failed » quand le vrai problème est TLS ?

Beaucoup de clients assimilent toute défaillance de connexion à « authentification ». Les journaux Dovecot plus un test openssl s_client permettent de séparer les problèmes de handshake TLS des véritables échecs passdb.

2) Quelle est la différence entre passdb et userdb, et pourquoi cela m’importe ?

passdb répond à « ce mot de passe/token est-il valide ? » userdb répond à « vers quel UID/GID/home/mail cet utilisateur est-il mappé ? » Vous avez besoin des deux. La réussite de passdb ne garantit pas que la boîte mail puisse être ouverte.

3) Je peux m’authentifier avec doveadm auth test mais IMAP échoue toujours. Et maintenant ?

Testez TLS et la négociation IMAP via openssl s_client, puis vérifiez doveadm user et les permissions système de fichiers. Ce schéma signifie généralement un mismatch de mécanisme/TLS ou un problème d’accès à la boîte.

4) Que signifie généralement « unknown user » ?

Votre requête passdb n’a renvoyé aucun résultat. Causes courantes : mauvaise clause WHERE SQL, filtre LDAP erroné, format de nom d’utilisateur incorrect (domaine manquant), ou problèmes de casse/espaces.

5) Dois-je activer auth_debug en production ?

Brèvement, pour une reproduction contrôlée, oui. Pas pendant des heures. Cela augmente le volume des logs et peut divulguer des métadonnées sensibles. Activez, reproduisez une fois, capturez, désactivez.

6) Les utilisateurs peuvent se connecter mais certains dossiers échouent ou les clients se déconnectent. Est-ce de l’authentification ?

En général non. C’est un problème d’ouverture de boîte/index/permissions. Recherchez « Permission denied », « Mailbox is locked », et les erreurs d’index dans les journaux.

7) Comment savoir si mon backend SQL est le goulot d’étranglement ?

Les journaux Dovecot montreront des timeouts SQL ou des requêtes lentes avec l’option -Dv. Si les échecs d’auth corrèlent avec des pics de latence DB, traitez cela comme un problème de capacité de dépendance, pas comme un simple réglage de Dovecot.

8) Est-il acceptable d’autoriser l’auth en clair pour calmer les plaintes des utilisateurs ?

Non, pas comme solution. Si vous devez temporairement assouplir les réglages pour débloquer une migration, faites-le avec une durée limitée et un plan de retour arrière. La vraie solution est de garantir le fonctionnement de TLS et la bonne configuration des clients.

9) Comment différencier un mauvais mot de passe d’une incompatibilité de schéma de hash ?

Avec doveadm -Dv auth test vous pouvez voir le hash retourné et si Dovecot reconnaît le préfixe du schéma. Si le schéma est erroné ou si le hash est mal formé, même un mot de passe correct échouera.

Conclusion : étapes pratiques suivantes

Lorsque les connexions IMAP Dovecot échouent, arrêtez d’argumenter sur le symptôme et commencez à localiser la rupture dans la chaîne. Vérifiez les journaux, confirmez la configuration active, testez passdb et userdb indépendamment, validez TLS, puis seulement après explorez les permissions système de fichiers et les index.

Étapes suivantes réalisables aujourd’hui :

• Enregistrez une version runbook du Playbook de diagnostic rapide et des tâches en commandes ci-dessus.
• Créez deux comptes de test synthétiques par domaine et automatisez doveadm auth test plus une connexion IMAPS openssl s_client.
• Mesurez et surveillez la latence d’auth (temps de réponse DB/LDAP, timeouts des workers) pour voir la panne avant les utilisateurs.
• Standardisez le format des noms d’utilisateur et documentez-le comme un contrat d’API — parce que c’en est un.

Faites cela, et la prochaine page « IMAP login failed » deviendra une enquête courte, pas un moment de carrière.