Échecs d’authentification SASL Postfix : pièges de configuration et ordre de correction

octobre 14, 2025 • février 3, 2026 • Lecture : 28 min • Views: 7

Cet article vous a aidé ?

Vous déployez un serveur de messagerie qui « fonctionne à peu près », jusqu’au moment où les utilisateurs appuient sur Envoyer et que leur client se prend en pleine figure 535 5.7.8 Authentication credentials invalid. Ou pire : c’est intermittent, seulement pour certains clients, seulement après une mise à jour, seulement le mardi. Pendant ce temps, vos journaux ressemblent à une lettre de rançon écrite par un comité.

Les échecs SASL avec Postfix ne résultent que rarement d’« un seul mauvais réglage ». Le plus souvent c’est une chaîne : l’état TLS détermine si AUTH est annoncé, les permissions sur le socket décident si Postfix peut interroger un démon d’authentification, et un seul test trompeur peut vous convaincre que la mauvaise couche est en cause. Résoudre cela rapidement, c’est une question d’ordre : validez l’écoute, puis TLS, puis la tuyauterie SASL, puis l’authentification utilisateur, puis la politique. À chaque fois.

Plan de diagnostic rapide

Ceci est le playbook « je suis d’astreinte et la caféine n’est pas un système de monitoring ». L’objectif est de localiser le goulot d’étranglement : réseau/écoute, verrou TLS, tuyauterie SASL, backend d’identifiants, ou restrictions de politique.

1er point : confirmez que vous testez le bon service et le bon port

Vérifier : Authentifiez-vous sur submission (587) ou smtps (465), et non sur le port 25 ?
Pourquoi : Beaucoup de déploiements désactivent volontairement AUTH sur le port 25 pour éviter de transformer le MX en point d’attaque par force brute.
Décision : Si vous utilisez le port 25, arrêtez. Changez le client pour 587/465 et retestez.

2e point : vérifiez que AUTH est annoncé dans l’état TLS utilisé par le client

Vérifier : Le serveur annonce-t-il AUTH seulement après STARTTLS ? Ou jamais ?
Pourquoi : smtpd_tls_auth_only = yes est courant et correct, mais il fausse les tests qui ne font pas de STARTTLS.
Décision : Si AUTH n’apparaît qu’après STARTTLS, assurez-vous que les clients sont configurés pour STARTTLS ou TLS implicite sur le port 465.

3e point : identifiez quel fournisseur SASL est utilisé (Dovecot vs Cyrus vs saslauthd)

Vérifier : Postfix est-il configuré avec smtpd_sasl_type = dovecot ou cyrus ?
Pourquoi : Les messages d’erreur se recoupent, mais la tuyauterie est différente : Dovecot utilise un socket UNIX ; Cyrus utilise souvent saslauthd ou sa propre base.
Décision : Si le mauvais fournisseur est configuré, corrigez cela avant de toucher aux mots de passe, PAM, LDAP, ou quoi que ce soit « lié aux utilisateurs ».

4e point : prouvez que Postfix peut atteindre le socket/daemon d’auth

Vérifier : Chemin du socket, permissions, SELinux/AppArmor, problèmes de chroot.
Décision : Si Postfix ne peut pas se connecter, ne perdez pas de temps sur les identifiants. Réparez d’abord la connectivité et les permissions.

5e point : validez directement le backend d’identifiants

Vérifier : Dovecot peut-il authentifier l’utilisateur ? saslauthd peut-il authentifier via PAM/LDAP ?
Décision : Si le backend échoue, réparez le backend ; Postfix n’est que le messager (et il est blâmé pour tout).

6e point : confirmez que la politique ne rejette pas « authentifié mais non autorisé »

Vérifier : smtpd_sender_login_maps, restrictions sur les destinataires, restrictions de relais, politiques milter SPF/DMARC.
Décision : Si AUTH réussit mais que le mail est encore rejeté, vous avez un blocage de politique, pas un échec d’authentification.

Un modèle mental pour la production : qui authentifie qui

Postfix est un serveur SMTP et un gestionnaire de file d’attente. Il ne souhaite pas être votre fournisseur d’identité. Lorsque vous activez SMTP AUTH, Postfix délègue l’authentification à une couche SASL. Cette couche SASL délègue à son tour à quelque chose qui valide réellement les identifiants : une base de données, LDAP, PAM, SQL, la passdb/userdb de Dovecot, etc.

En pratique il existe deux formes courantes :

Forme A : Postfix + Dovecot SASL (le plus courant sur Linux moderne)

Postfix exécute le service SMTP (submission/smtps).
Postfix demande à Dovecot d’authentifier via un socket UNIX (service auth de Dovecot).
Dovecot vérifie les identifiants en utilisant sa passdb/userdb configurée (SQL, LDAP, fichier passwd, PAM, etc.).

Modes d’échec typiques : mauvais chemin de socket, permissions, décalage chroot, auth Dovecot mal configurée, incompatibilité de mécanismes (PLAIN/LOGIN), verrou TLS, ou client sur le mauvais port.

Forme B : Postfix + Cyrus SASL (+ saslauthd ou auxprop)

Postfix charge les plugins Cyrus SASL.
Cyrus SASL interroge saslauthd ou son propre backend auxprop.
saslpasswd2 ou PAM/LDAP décide si les identifiants sont corrects.

Modes d’échec typiques : paquets Cyrus SASL manquants, no mechanism available, saslauthd arrêté, pwcheck_method erroné, permissions de socket incorrectes, ou nom de service incohérent.

Quel que soit le modèle, SMTP AUTH pose deux questions distinctes :

Le client et le serveur peuvent-ils négocier un mécanisme AUTH ? (Capacités, exigences TLS, mécanismes supportés)
Le fournisseur d’authentification peut-il valider l’utilisateur ? (Correction du backend, mot de passe, état du compte)

Beaucoup d’incidents surviennent parce que les équipes sautent la question 1 et commencent à « réinitialiser des mots de passe » comme s’il s’agissait d’un rituel.

Faits et contexte exploitables

SMTP AUTH ne faisait pas partie du SMTP original. Il est arrivé plus tard comme extension (ESMTP), parce que l’Internet primitif supposait la confiance à l’intérieur des réseaux.
Le port 587 (submission) existe pour une raison. Il sépare la soumission de courrier utilisateur (avec AUTH) du relais MTA-à-MTA sur le port 25.
Le port 465 est revenu en usage. Il avait été « déprécié » mais est maintenant largement utilisé pour le TLS implicite (« smtps »), car les clients préfèrent la simplicité.
Postfix garde volontairement l’auth externe. C’est un choix de conception : moins de composants sensibles à la sécurité à l’intérieur de Postfix, mises à jour plus faciles et séparation des responsabilités plus saine.
SASL est un cadre, pas un unique démon. C’est pour cela que « SASL est cassé » est rarement exploitable ; il faut nommer le fournisseur et le backend.
L’annonce d’AUTH dépend de TLS et des restrictions. Avec des réglages courants, le serveur peut masquer AUTH jusqu’à ce que STARTTLS soit effectué, ce qui fait mentir les tests naïfs.
Dans Dovecot, le socket d’auth est un service avec des permissions. Si le socket existe mais que Postfix ne peut pas y accéder, vous obtenez des échecs qui ressemblent à un « mauvais mot de passe ».
Le chroot importe encore en 2026. Postfix peut exécuter certains services en chroot ; un chemin de socket en dehors du chroot devient « introuvable » même s’il existe.
Une incompatibilité de chiffrement TLS « anonyme » peut se manifester par « AUTH non proposé ». Si la négociation TLS échoue, vous n’atteindrez peut-être jamais le point où AUTH est annoncé.

Une citation, parce que les personnes fiabilité râlaient à ce sujet avant que ce soit à la mode :

« L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan

Ordre de correction (faites ceci, pas des intuitions)

Si vous modifiez les réglages au hasard, vous « réparerez » trois fois et vous n’aurez toujours pas compris pourquoi ça a cassé. Utilisez un ordre qui isole les couches et vous empêche de courir après des fantômes.

0) Geler la scène

Avant d’éditer quoi que ce soit, capturez : configurations actuelles, versions des paquets, et journaux représentatifs. Les bugs SMTP AUTH aiment disparaître sous le bruit de la reconfiguration.

1) Identifiez le point d’entrée exact : service, port et nom d’hôte

Le client atteint-il l’hôte prévu (frontend de submission vs MX) ? Est-il sur le bon port ? Y a-t-il un load balancer qui termine STARTTLS ? Vous seriez surpris de voir à quel point « AUTH échoue » est souvent en réalité « vous êtes connecté au pool MX qui n’a pas AUTH par politique ».

2) Confirmez la négociation des capacités (EHLO → STARTTLS → EHLO → AUTH)

Ne déboguez pas SASL avant de savoir si AUTH est même offert. Si AUTH n’est pas offert, c’est généralement l’un des cas suivants :

Mauvais service/port
smtpd_sasl_auth_enable non activé pour ce service
TLS requis (smtpd_tls_auth_only) mais vous n’utilisez pas STARTTLS
Des restrictions masquent AUTH
Fournisseur SASL mal configuré empêche l’énumération des mécanismes

3) Verrouillez la correction TLS

Réparez TLS avant l’auth. Si TLS échoue, certains clients n’essaieront même pas AUTH. D’autres essaieront et divulgueront des identifiants si vous autorisez accidentellement AUTH en clair. Vous ne voulez pas ça ni dans votre conscience ni dans vos journaux d’audit.

4) Confirmez le câblage du fournisseur SASL (Dovecot ou Cyrus)

C’est là que la plupart des migrations « ça marchait sur l’ancien serveur » tombent en panne. Postfix a besoin du bon type SASL et des bons sockets/paramètres. Si vous utilisez Dovecot, traitez le socket d’auth comme un endpoint API : le chemin, les permissions et le protocole doivent correspondre.

5) Validez l’auth backend hors SMTP

Testez l’auth de Dovecot directement (ou saslauthd) pour isoler les identifiants et la configuration du backend. Si l’auth backend échoue, Postfix ne pourra rien faire par la pensée positive.

6) Appliquez la politique délibérément après que AUTH fonctionne

Une fois AUTH réussi, appliquez vos règles : les utilisateurs authentifiés peuvent relayer ; les non authentifiés non ; restrictions d’expéditeur ; limites de débit. Si vous faites la politique avant, vous confondrez « auth échoué » avec « auth réussi mais non autorisé ».

Petite blague #1 : Le débogage SMTP AUTH, c’est comme la plomberie : la fuite n’est jamais là où la flaque est.

Tâches pratiques : commandes, sorties, décisions

Voici les tâches que j’exécute réellement en production. Chacune inclut : la commande, ce que signifie la sortie, et la décision suivante. Exécutez-les sur le serveur que vous croyez gérer la submission, pas « quelque part à côté ».

Tâche 1 : Confirmer que Postfix tourne et quels services sont activés

cr0x@server:~$ systemctl status postfix --no-pager
● postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/lib/systemd/system/postfix.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2026-01-02 09:12:44 UTC; 3h 18min ago
       Docs: man:postfix(1)
   Main PID: 1221 (master)
      Tasks: 5 (limit: 18996)
     Memory: 28.4M
        CPU: 2.114s
     CGroup: /system.slice/postfix.service
             ├─1221 /usr/lib/postfix/sbin/master -w
             ├─1230 pickup -l -t unix -u
             ├─1231 qmgr -l -t unix -u
             ├─1302 smtpd -n smtp -t inet -u -c
             └─1303 tlsmgr -t unix -u

Ce que cela signifie : Le processus master tourne ; il y a au moins un smtpd. Mais vous ne savez toujours pas si submission (587) est activé.

Décision : Vérifiez les écouteurs et master.cf ensuite.

Tâche 2 : Vérifier que le serveur écoute sur les bons ports (25/587/465)

cr0x@server:~$ sudo ss -lntp | egrep ':(25|465|587)\s'
LISTEN 0      100          0.0.0.0:25       0.0.0.0:*    users:(("master",pid=1221,fd=13))
LISTEN 0      100          0.0.0.0:587      0.0.0.0:*    users:(("master",pid=1221,fd=16))
LISTEN 0      100          0.0.0.0:465      0.0.0.0:*    users:(("master",pid=1221,fd=18))

Ce que cela signifie : Postfix écoute sur 587 et 465. Bien. Si 587/465 manquaient, votre problème n’est pas SASL ; c’est l’activation du service ou le pare-feu.

Décision : Si 587/465 n’écoutent pas, corrigez master.cf et le pare-feu avant de toucher SASL.

Tâche 3 : Confirmer comment submission est défini dans master.cf

cr0x@server:~$ sudo postconf -Mf | egrep '^(submission|smtps)\b'
submission inet n       -       y       -       -       smtpd
smtps     inet  n       -       y       -       -       smtpd

Ce que cela signifie : Les services existent. Mais les overrides (comme -o smtpd_sasl_auth_enable=yes) peuvent ou non être présents.

Décision : Affichez le stanza complet du service et vérifiez les overrides SASL/TLS.

Tâche 4 : Montrer les paramètres Postfix effectifs liés à SASL/TLS

cr0x@server:~$ sudo postconf -n | egrep '^(smtpd_sasl|smtpd_tls|broken_sasl_auth_clients|smtpd_recipient_restrictions|smtpd_relay_restrictions|smtpd_sender_login_maps|smtpd_sasl_security_options|smtpd_sasl_path|smtpd_sasl_type)\b'
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
broken_sasl_auth_clients = yes
smtpd_relay_restrictions = permit_mynetworks,permit_sasl_authenticated,defer_unauth_destination

Ce que cela signifie : Postfix est configuré pour utiliser Dovecot SASL via private/auth. AUTH ne sera offert qu’après TLS à cause de smtpd_tls_auth_only=yes. Le relais est autorisé pour les utilisateurs authentifiés.

Décision : Vos tests doivent utiliser STARTTLS (587) ou TLS implicite (465). Ensuite : prouvez que AUTH est annoncé après TLS.

Tâche 5 : Sondez les capacités sans TLS (attendez-vous à ce qu’AUTH soit masqué)

cr0x@server:~$ printf 'EHLO test\r\nQUIT\r\n' | nc -w 3 127.0.0.1 587
220 mail01.example.net ESMTP Postfix
250-mail01.example.net
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 SMTPUTF8
221 2.0.0 Bye

Ce que cela signifie : Aucun AUTH annoncé. C’est cohérent avec smtpd_tls_auth_only=yes.

Décision : Testez avec STARTTLS et EHLO à nouveau.

Tâche 6 : Sondez les capacités avec STARTTLS (AUTH devrait apparaître maintenant)

cr0x@server:~$ openssl s_client -starttls smtp -crlf -connect 127.0.0.1:587 </dev/null
CONNECTED(00000003)
depth=2 C=US O=Example CA CN=Example Root CA
verify return:1
depth=1 C=US O=Example CA CN=Example Issuing CA
verify return:1
depth=0 CN=mail01.example.net
verify return:1
---
250-mail01.example.net
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 SMTPUTF8

Ce que cela signifie : STARTTLS fonctionne, et les mécanismes AUTH sont annoncés. Si votre client affirme « le serveur ne supporte pas l’authentification », il n’utilise pas TLS ou est sur le mauvais port/hôte.

Décision : Si AUTH n’est pas annoncé même après STARTTLS, passez à la tuyauterie du fournisseur SASL (socket/daemon/mécanismes).

Tâche 7 : Envoyer un test AUTH réel avec swaks (meilleur rapport efficacité/coût)

cr0x@server:~$ swaks --server 127.0.0.1 --port 587 --tls --auth LOGIN --auth-user alice@example.net --auth-password 'nottherightpassword' --quit-after AUTH
=== Trying 127.0.0.1:587...
=== Connected to 127.0.0.1.
<--  220 mail01.example.net ESMTP Postfix
 --> EHLO client.example
<--  250-mail01.example.net
<--  250-STARTTLS
 --> STARTTLS
<--  220 2.0.0 Ready to start TLS
=== TLS started with cipher TLS_AES_256_GCM_SHA384
 --> EHLO client.example
<--  250-AUTH PLAIN LOGIN
 --> AUTH LOGIN
<--  334 VXNlcm5hbWU6
 --> YWxpY2VAZXhhbXBsZS5uZXQ=
<--  334 UGFzc3dvcmQ6
 --> bm90dGhlcmlnaHRwYXNzd29yZA==
<--  535 5.7.8 Error: authentication failed: authentication failure

Ce que cela signifie : Vous avez reçu un 535 clair. Ce n’est pas une panne de tuyauterie SASL ; c’est le backend d’identifiants ou les règles d’auth Dovecot. Si au lieu de cela vous voyez 454 4.7.0 Temporary authentication failure, pensez disponibilité du socket/daemon.

Décision : Avec un 535 stable, testez le backend d’auth directement (Dovecot). Avec un 454, vérifiez les permissions du socket / la santé du daemon.

Tâche 8 : Inspecter les lignes de log Postfix liées à l’échec

cr0x@server:~$ sudo journalctl -u postfix -S "10 min ago" --no-pager | egrep -i 'sasl|auth|warning|fatal' | tail -n 30
Jan 03 10:41:12 mail01 postfix/smtpd[18422]: warning: SASL authentication failure: Password verification failed
Jan 03 10:41:12 mail01 postfix/smtpd[18422]: warning: unknown[127.0.0.1]: SASL LOGIN authentication failed: authentication failure

Ce que cela signifie : Postfix a atteint la couche SASL et a reçu un « vérification du mot de passe échouée ». Ce n’est pas un socket manquant. C’est un problème de backend d’auth ou d’identifiants.

Décision : Passez aux logs et tests d’auth Dovecot.

Tâche 9 : Confirmer que le socket d’auth Dovecot est là où Postfix l’attend

cr0x@server:~$ sudo doveconf -n | egrep '^(service auth|  unix_listener|    mode|    user|    group|auth_mechanisms)'
auth_mechanisms = plain login
service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
}

Ce que cela signifie : C’est la référence pour Dovecot+Postfix : le socket vit sous /var/spool/postfix/private pour que Postfix chrooté y accède ; il appartient à postfix ; le mode permet l’accès.

Décision : Si votre socket est ailleurs (comme /run/dovecot/auth-client), soit déplacez-le, soit ajustez le comportement chroot de Postfix. Ne faites pas « chmod 777 » sur quoi que ce soit.

Tâche 10 : Vérifier que le socket existe et que les permissions sont correctes

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

Ce que cela signifie : Il existe, c’est un socket, et postfix peut y accéder.

Décision : S’il manque : Dovecot n’est pas en cours, chemin erroné, ou listener non configuré. Si les permissions sont incorrectes : corrigez dans la config Dovecot et rechargez Dovecot.

Tâche 11 : Tester l’auth Dovecot directement (contourner Postfix)

cr0x@server:~$ sudo doveadm auth test alice@example.net 'nottherightpassword'
passdb: alice@example.net auth failed
extra fields:
  user=alice@example.net

Ce que cela signifie : Le backend dit non. C’est cohérent avec le 535. Si cela échoue aussi avec des identifiants corrects, votre configuration passdb est mauvaise (SQL/LDAP/PAM), ou le compte est désactivé, ou vous utilisez un format de nom d’utilisateur erroné.

Décision : Corrigez la passdb/userdb Dovecot ou les données du compte. Ne touchez pas à Postfix tant que l’auth Dovecot ne passe pas.

Tâche 12 : Consulter les logs d’auth Dovecot pour la vraie raison

cr0x@server:~$ sudo journalctl -u dovecot -S "10 min ago" --no-pager | egrep -i 'auth|passdb|userdb|pam|ldap' | tail -n 40
Jan 03 10:41:12 mail01 dovecot[903]: auth: passwd-file(alice@example.net): Password mismatch
Jan 03 10:41:12 mail01 dovecot[903]: auth: Error: passwd-file: Cannot open file /etc/dovecot/users: Permission denied

Ce que cela signifie : Maintenant on avance : Dovecot ne peut pas lire son passwd-file. Postfix ne mentait pas ; il manquait juste le contexte.

Décision : Corrigez les permissions/possessions/labels SELinux du fichier /etc/dovecot/users ou configurez Dovecot pour lire depuis un backend approprié.

Tâche 13 : Vérifier le piège de chroot Postfix (chemin du socket dans /var/spool/postfix)

cr0x@server:~$ sudo postconf -n | egrep '^(queue_directory|daemon_directory|command_directory)\b'
queue_directory = /var/spool/postfix
daemon_directory = /usr/lib/postfix/sbin
command_directory = /usr/sbin

Ce que cela signifie : La file Postfix est dans /var/spool/postfix. Beaucoup de distributions chrootent certains services là. Si votre socket Dovecot est en dehors de cet arbre, Postfix peut ne pas le voir.

Décision : Préférez le socket Dovecot sous /var/spool/postfix/private/ comme montré plus haut.

Tâche 14 : Si vous utilisez Cyrus SASL, lister les mécanismes disponibles et repérer « no mechanism available »

cr0x@server:~$ sudo saslpluginviewer -c
Installed and properly configured SASL (Cyrus SASL) mechanisms are:
  PLAIN
  LOGIN

Ce que cela signifie : Les mécanismes existent. Si cette liste est vide, Postfix loguera souvent no mechanism available et les clients verront AUTH échouer ou disparaître.

Décision : Installez les paquets de mécanismes Cyrus nécessaires et confirmez le nom de service (souvent dans /etc/postfix/sasl/smtpd.conf).

Tâche 15 : Confirmer que saslauthd tourne et est joignable (chemin Cyrus)

cr0x@server:~$ systemctl status saslauthd --no-pager
● saslauthd.service - SASL authentication daemon
     Loaded: loaded (/lib/systemd/system/saslauthd.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2026-01-02 09:10:01 UTC; 3h 21min ago
   Main PID: 991 (saslauthd)
      Tasks: 5 (limit: 18996)
     Memory: 4.7M
        CPU: 1.221s
     CGroup: /system.slice/saslauthd.service
             ├─991 /usr/sbin/saslauthd -a pam -m /var/run/saslauthd
             ├─992 /usr/sbin/saslauthd -a pam -m /var/run/saslauthd
             └─993 /usr/sbin/saslauthd -a pam -m /var/run/saslauthd

Ce que cela signifie : Il est actif et utilise PAM avec le répertoire de sockets /var/run/saslauthd.

Décision : Si Postfix ne peut pas lui parler, vérifiez que l’utilisateur postfix appartient au groupe adéquat (souvent sasl) et que les permissions du socket permettent l’accès.

Tâche 16 : Identifier « AUTH fonctionne mais relais refusé » vs « AUTH échoué »

cr0x@server:~$ swaks --server 127.0.0.1 --port 587 --tls --auth LOGIN --auth-user alice@example.net --auth-password 'correctpassword' --to bob@external.example --from alice@example.net
...
<--  235 2.7.0 Authentication successful
...
<--  554 5.7.1 <bob@external.example>: Relay access denied

Ce que cela signifie : AUTH a réussi (235) mais le relais est refusé. C’est de l’autorisation/politique. Les gens lisent souvent ça comme « auth cassé ». Ce n’est pas le cas.

Décision : Revoyez smtpd_relay_restrictions et assurez-vous que permit_sasl_authenticated est au bon endroit pour le service submission, et non écrasé accidentellement.

Petite blague #2 : Chaque fois que quelqu’un dit « c’est juste du mail », un démon SMTP engendre un autre fichier de log.

Trois mini-histoires d’entreprise issues du terrain

Mini-histoire 1 : L’incident causé par une fausse hypothèse

Le contexte : une entreprise de taille moyenne avec un environnement hybride. Ils avaient un serveur de submission Postfix pour les clients, et un pool MX séparé pour le courrier entrant. Le DNS et le nommage étaient propres : smtp.example.net pour la submission, mx1/mx2 pour l’entrée. Sur le papier, personne ne devrait les confondre.

Puis un nouveau profil MDM a été déployé pour les appareils mobiles. Quelqu’un a mal saisi le nom du serveur et a mis le nom d’hôte du MX. Les hôtes MX avaient le port 25 ouvert (logique) et TLS activé (évident), mais ils étaient configurés pour ne jamais annoncer AUTH sur le port 25. C’est normal et sensé : le port 25 est la porte d’entrée de l’Internet, pas celle de vos employés.

En quelques minutes, des tickets d’assistance ont afflué : « mot de passe rejeté ». Les ingénieurs ont récupéré les logs Postfix du serveur de submission et n’ont rien vu. Ils ont extrait les logs du MX et trouvé beaucoup de connexions, aucune tentative d’AUTH, et des clients se plaignant d’authentification. La première hypothèse de l’équipe fut « SASL est en panne ». Ils ont redémarré Dovecot sur le serveur de submission. Puis Postfix. Puis tout ce qui était à portée de bras.

Rien n’a changé, car rien n’était cassé sur le serveur de submission. La mauvaise hypothèse était que le trafic arrivait où l’équipe le pensait. Une fois qu’ils ont confirmé par capture de paquets et par les logs du MX que les clients se connectaient au MX, la correction fut embarrassante de simplicité : mettre à jour le profil MDM pour pointer sur smtp.example.net et exiger le port 587.

Deux leçons sont restées : d’abord, vérifiez toujours l’hôte et le port cibles avant de déboguer. Ensuite, « AUTH non offert » n’est pas la même chose que « AUTH échoué ». C’est fréquemment « vous êtes à la mauvaise porte ».

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre équipe voulait durcir la sécurité et réduire la surface d’attaque. Bonne intention. Ils ont décidé d’imposer TLS partout, et ont mis smtpd_tls_security_level=encrypt globalement. Ils ont aussi activé smtpd_tls_auth_only=yes. Pris isolément, les deux sont raisonnables.

Le retour de bâton est venu d’un détail : ils avaient un job de monitoring interne et quelques applications legacy qui envoyaient du courrier au service de submission sans support STARTTLS. Ces applis étaient sur un VLAN « de confiance », et historiquement le service de submission autorisait les connexions en clair depuis ce sous-réseau. Pas idéal, mais cela fonctionnait et le risque était limité. Le changement a transformé le « risque limité » en « panne complète », et personne n’avait inventorié ces clients legacy parce que leurs propriétaires avaient changé d’équipe trois fois.

Les symptômes étaient confus. Certains clients fonctionnaient (MUA modernes). D’autres échouaient avec des messages qui ressemblaient à des échecs d’auth ou des échecs de poignée de main selon la bibliothèque. L’ingénieur d’astreinte s’est concentré sur SASL parce que « l’envoi de mail échoue » prend souvent cette étiquette.

Le bon diagnostic était la négociation des capacités. Ces applis legacy n’atteignaient jamais AUTH ; elles ne pouvaient pas établir TLS. La correction n’était pas d’affaiblir TLS globalement. C’était d’appliquer la politique par service : garder la submission stricte, mais fournir un relais interne séparé avec des restrictions réseau explicites et sans AUTH, ou obliger ces applis à utiliser un relais local qui gère TLS en amont.

Résultat : la sécurité s’est améliorée, mais seulement après un douloureux rappel que resserrer la vis sur des systèmes en production sans inventaire client n’est que de l’art performance.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Une société proche de la finance avait une plate-forme mail où « ennuyeux » était un compliment. Ils gardaient un runbook qui insistait sur une chose avant de toucher aux configs : reproduire avec swaks et capturer la transcription SMTP complète. Pas d’exception. Les gens levaient les yeux au ciel jusqu’au jour où ils ne l’ont pas fait.

Un vendredi, après une mise à jour système de routine, AUTH a commencé à échouer pour un sous-ensemble d’utilisateurs, mais seulement lorsqu’ils se connectaient via un VIP particulier. La suspicion immédiate fut un problème de load balancer, un mismatch de certificat, ou un socket SASL cassé. L’ingénieur d’astreinte a suivi le runbook, exécuté swaks contre chaque backend et contre le VIP, et comparé les transcriptions côte à côte.

La transcription montra qu’un backend n’annonçait que AUTH PLAIN tandis que les autres annonçaient AUTH PLAIN LOGIN. Certains clients essayaient LOGIN en premier, puis abandonnaient si LOGIN manquait. Ce n’était pas théorique ; c’était un vieux client mobile déployé en masse.

La cause racine fut une dérive partielle de configuration : un nœud avait un réglage Dovecot auth_mechanisms différent à cause d’un run d’automatisation échoué quelques semaines plus tôt. La mise à jour OS a simplement déclenché un reload qui a rendu la dérive visible.

La pratique ennuyeuse — toujours capturer et comparer la transcription SMTP — a transformé une panne potentiellement longue en une correction simple « rendre les nœuds cohérents ». Personne n’a écrit de mail de victoire. Tout le monde est rentré chez soi.

Erreurs courantes : symptôme → cause → correction

Voici les modes de défaillance qui se répètent dans les environnements. Si vous reconnaissez le symptôme, ne partez pas en freestyle. Suivez la correction dans l’ordre.

1) Symptom : « Le serveur ne prend pas en charge l’authentification » (UI du client)

Cause racine : Vous êtes sur le port 25, ou AUTH est masqué jusqu’à STARTTLS, ou vous touchez le MX au lieu de la submission.

Correction : Utilisez le port 587 avec STARTTLS ou le port 465 avec TLS implicite. Vérifiez qu’AUTH apparaît seulement après STARTTLS avec openssl s_client -starttls smtp. Confirmez le nom d’hôte et le routage du VIP.

2) Symptom : AUTH disparaît après activation des réglages TLS

Cause racine : Échec de la poignée de main TLS, donc le second EHLO n’arrive jamais ; ou la politique TLS exige le chiffrement mais votre sonde ne fait pas STARTTLS.

Correction : Corrigez certificats/chaîne, définissez correctement smtpd_tls_cert_file/key_file, et retestez avec STARTTLS. Ne testez pas en clair et concluez que SASL est cassé.

3) Symptom : `454 4.7.0 Temporary authentication failure`

Cause racine : Postfix ne peut pas atteindre le fournisseur SASL (socket Dovecot manquant/permission refusée) ou le fournisseur est down.

Correction : Pour Dovecot, assurez-vous que le socket service auth existe sous /var/spool/postfix/private/auth, bonne possession/mode, et que Dovecot tourne. Pour Cyrus, assurez-vous que saslauthd tourne et est accessible.

4) Symptom : `535 5.7.8 Authentication credentials invalid`

Cause racine : Mauvais mot de passe, mauvais format de nom d’utilisateur, mismatch de backend, ou compte désactivé/locké.

Correction : Testez avec doveadm auth test (ou les outils saslauthd) en utilisant exactement le nom d’utilisateur envoyé par le client. Corrigez le backend. Évitez de « réparer » Postfix.

5) Symptom : Logs Postfix `warning: SASL: Connect to private/auth failed: No such file or directory`

Cause racine : Chemin du socket mismatch ou problème de chroot. Postfix attend private/auth relatif à son répertoire de queue ; Dovecot a placé le socket ailleurs.

Correction : Configurez le socket d’auth Dovecot sous /var/spool/postfix/private/auth et définissez les permissions correctes. Ou ajustez smtpd_sasl_path de Postfix pour correspondre, mais préférez la disposition standard.

6) Symptom : Logs Postfix `no mechanism available`

Cause racine : Plugins Cyrus SASL non installés, ou mécanismes Dovecot non activés.

Correction : Installez les paquets de mécanismes pour Cyrus, ou définissez Dovecot auth_mechanisms = plain login. Confirmez avec la liste des mécanismes et la sortie EHLO post-STARTTLS.

7) Symptom : AUTH réussi mais les messages sont rejetés comme relais refusé

Cause racine : Politique d’autorisation : permit_sasl_authenticated manquant/écrasé sur le service submission, ou restrictions de relais incorrectes.

Correction : Placez permit_sasl_authenticated dans smtpd_relay_restrictions (ou les restrictions appropriées pour votre version de Postfix) pour la submission. Vérifiez avec un envoi swaks.

8) Symptom : Fonctionne pour certains utilisateurs, échoue pour d’autres (même client)

Cause racine : Incohérence du backend (lag de réplication, sources d’auth multiples), normalisation du nom d’utilisateur, ou politique par utilisateur comme smtpd_sender_login_maps.

Correction : Validez séparément l’authentification et l’autorisation. Vérifiez le comportement de smtpd_sender_login_maps et la lookup passdb/userdb de Dovecot pour chaque utilisateur.

Listes de contrôle / plan étape par étape

Checklist A : Faire apparaître AUTH de façon fiable sur submission (587)

Assurez-vous que le service submission est activé dans master.cf et écoute sur 587.
Définissez des overrides par service pour submission (recommandé) :
- smtpd_tls_security_level=encrypt (ou may si nécessaire, en sachant pourquoi)
- smtpd_sasl_auth_enable=yes
- smtpd_tls_auth_only=yes
Vérifiez que STARTTLS fonctionne et que la chaîne de certificats est saine.
Vérifiez que l’EHLO après STARTTLS annonce AUTH PLAIN LOGIN (ou les mécanismes voulus).

Checklist B : Câblage Dovecot SASL qui ne se dégrade pas avec le temps

Dans Postfix :
- smtpd_sasl_type = dovecot
- smtpd_sasl_path = private/auth
Dans Dovecot :
- auth_mechanisms = plain login (sauf si vous savez avoir besoin d’autres)
- service auth { unix_listener /var/spool/postfix/private/auth { user=postfix group=postfix mode=0660 } }
Confirmez que le socket existe et est accessible.
Utilisez doveadm auth test pour un utilisateur connu bon avant de tester SMTP AUTH.

Checklist C : Câblage Cyrus SASL (si vous insistez)

Confirmez que des mécanismes existent (saslpluginviewer non vide).
Confirmez que saslauthd tourne et utilise le backend voulu (PAM/LDAP/etc.).
Assurez-vous que Postfix peut accéder au répertoire de sockets saslauthd (adhésion au groupe/permissions).
Confirmez que la config de service Cyrus SASL (souvent /etc/postfix/sasl/smtpd.conf) correspond au pwcheck_method désiré.

Plan étape par étape « ordre de correction » à suivre pendant une panne

Reproduire avec swaks contre le nom d’hôte/port exact que les utilisateurs atteignent. Sauvegardez la transcription.
Vérifier l’écoute avec ss -lntp. Si rien n’écoute, réparez cela d’abord.
Vérifier les capacités EHLO avant et après TLS. Si AUTH n’apparaît pas post-TLS, ne touchez pas aux mots de passe.
Confirmer les réglages du fournisseur SASL (postconf -n). Décidez Dovecot vs Cyrus ; supprimez l’ambiguïté.
Valider la joignabilité du socket/daemon (existence du socket, permissions, chroot, politique MAC).
Valider l’auth backend directement (doveadm auth test ou outillage saslauthd).
Ensuite seulement peaufinez les restrictions de politique et les sender login maps.
Retester avec swaks, puis retester avec un client réel.

FAQ

1) Dois-je activer SMTP AUTH sur le port 25 ?

Généralement non. Gardez le port 25 pour le trafic MTA-à-MTA. Mettez AUTH sur 587/465. Si vous devez activer AUTH sur 25 pour un cas particulier, isolez-le par IP et appliquez des limites de débit strictes.

2) Pourquoi AUTH n’apparaît-il qu’après STARTTLS ?

Parce que smtpd_tls_auth_only=yes dit à Postfix d’annoncer AUTH seulement après que le chiffrement soit actif. Cela empêche que des identifiants soient proposés en clair. Si votre test ne fait pas STARTTLS, vous conclurez à tort qu’AUTH est désactivé.

3) Quelle est la différence entre 465 et 587 pour les clients ?

587 est la submission avec STARTTLS (connexion en clair, puis upgrade). 465 est TLS implicite dès le premier octet. Opérationnellement les deux peuvent convenir ; beaucoup d’environnements exécutent les deux parce que le comportement des clients est imprévisible.

4) Je vois `535`. Est-ce toujours un mauvais mot de passe ?

C’est un rejet des identifiants à un certain niveau, mais pas toujours le mot de passe de l’humain. Ça peut être le mauvais format d’utilisateur, une lookup backend qui échoue, un compte verrouillé, ou une base d’auth incohérente entre nœuds. Testez avec doveadm auth test (ou la vérification native du backend) pour être sûr.

5) Je vois `454 4.7.0 Temporary authentication failure`. Qu’est-ce que ça implique ?

Cela indique généralement de la tuyauterie : Postfix ne peut pas parler au fournisseur d’auth, ou le fournisseur ne peut pas atteindre son backend. Pensez socket manquant, permission refusée, daemon arrêté, problèmes chroot/SELinux. Ce n’est que rarement « l’utilisateur a mal tapé son mot de passe ».

6) L’auth Dovecot fonctionne, mais SMTP AUTH échoue toujours. Comment est-ce possible ?

Causes courantes : Postfix pointe vers le mauvais chemin de socket, Postfix est chrooté et ne voit pas le socket, permissions erronées pour l’utilisateur postfix, ou des overrides du service submission différents des valeurs par défaut de main.cf. Validez smtpd_sasl_type, smtpd_sasl_path, et l’existence de /var/spool/postfix/private/auth.

7) Pourquoi certains clients échouent quand LOGIN n’est pas proposé ?

Certains clients anciens ne gèrent pas correctement la négociation des mécanismes. Si vous n’offrez que PLAIN, ils peuvent ne pas l’essayer (alors que PLAIN sur TLS est acceptable). Si vous avez besoin d’une large compatibilité, proposez PLAIN et LOGIN sur TLS.

8) Faut-il encore utiliser « broken_sasl_auth_clients » ?

Parfois. Il existe pour des clients bogués qui ne suivent pas parfaitement la spec. Si vous n’en avez pas besoin, vous pouvez le retirer, mais ne l’enlevez pas en plein incident à moins d’avoir reproduit une panne liée à ce réglage.

9) Comment distinguer « AUTH échoué » de « AUTH réussi mais non autorisé à envoyer en tant que cette adresse » ?

Cherchez d’abord 235 Authentication successful. Si vous obtenez 235 puis des rejets comme relay denied ou sender access denied, vous êtes dans le domaine de l’autorisation/politique : smtpd_sender_login_maps, restrictions, ou milters.

10) Dois-je préférer Dovecot SASL ou Cyrus SASL ?

Si vous exécutez déjà Dovecot pour IMAP/POP, utilisez Dovecot SASL. Moins de composants, moins de surprises de paquets/plugins, et le modèle socket est simple. Cyrus SASL peut convenir, mais il est plus facile de construire une pile fragile par erreur.

Prochaines étapes à déployer

Les échecs d’auth SASL Postfix se résolvent rapidement quand vous arrêtez de deviner et commencez à isoler les couches. Traitez cela comme n’importe quelle chaîne de dépendances en production : vérifiez le point d’entrée, confirmez la négociation, validez la tuyauterie d’auth, puis validez le backend, puis appliquez la politique.

Étapes pratiques :

Capturez une transcription swaks connue bonne pour votre environnement et conservez-la dans le runbook comme référence.
Standardisez sur un seul fournisseur SASL (Dovecot si vous l’exécutez) et un seul chemin de socket (/var/spool/postfix/private/auth).
Rendez la politique de submission explicite dans les overrides de master.cf pour que les mises à jour n’« aident » pas à changer le comportement.
Ajoutez une vérification de monitoring qui confirme : STARTTLS fonctionne, AUTH est annoncé après TLS, et une authentification synthétique réussit pour un compte de test.