E-mail « Adresse destinataire refusée » : pourquoi des utilisateurs valides rebondissent encore

Ce que signifie réellement « Adresse destinataire refusée »

Lorsque vous voyez « Adresse destinataire refusée », vous ne voyez pas une unique erreur standardisée. Vous voyez l’interprétation de l’expéditeur d’un refus survenu pendant la conversation SMTP — le plus souvent en réponse à la commande RCPT TO:.

En termes simples : le côté récepteur (votre côté, ou celui d’un tiers) a refusé le destinataire lors de l’étape d’enveloppe, avant que le corps du message ne soit accepté. C’est pourquoi les expéditeurs aiment cette pratique : rejeter tôt économise la bande passante et le stockage. C’est aussi pourquoi vous recevez le ticket en colère : l’expéditeur pense que vous avez dit que l’adresse est mauvaise.

Codes d’état SMTP typiques que vous verrez

• 550 5.1.1 — utilisateur inconnu / boîte non disponible (ou prétendument).
• 550 5.1.0 / 5.7.1 — rejet de politique qui peut être mal étiqueté comme « adresse refusée ».
• 551 / 553 — souvent « non local » ou problèmes de syntaxe/politique d’adresse.
• 450 / 451 / 4.7.1 — rejet temporaire (greylisting, limitation de débit, délai d’attente du backend). Ceux-ci apparaissent parfois comme « destinataire refusé » dans les interfaces car les UI ne sont pas vos amies.

Point clé : « Adresse destinataire refusée » ne signifie pas forcément que l’utilisateur n’existe pas. Cela signifie que le système récepteur a refusé d’accepter le courrier pour ce destinataire à ce moment, pour une raison. De nombreux systèmes choisissent par défaut de faire des rejets à l’étape du destinataire comme endroit pratique pour appliquer des politiques.

Une citation qui devrait figurer sur le bureau de tout ingénieur mail : Idée paraphrasée : « L’espoir n’est pas une stratégie. » — attribuée à de nombreux spécialistes de la fiabilité, mais l’idée est un principe d’exploitation solide. En termes de mail : cessez d’espérer que c’est « juste passager ». Prouvez où le rejet a lieu.

Où le rejet se produit dans SMTP (et pourquoi c’est important)

SMTP est conversationnel. Cela compte car chaque étape dispose de réglages différents, de journaux différents et de conséquences différentes.

Étapes pertinentes de la conversation

1. Connect / banner : votre edge dit bonjour. La négociation TLS peut avoir lieu. C’est ici que la réputation IP peut vous empêcher d’aller plus loin avant même d’atteindre les destinataires.
2. EHLO/HELO : capacités. Les moteurs de politique appliquent parfois des vérifications HELO ou exigent TLS avant de poursuivre.
3. MAIL FROM: : expéditeur d’enveloppe. Les décisions SPF/DMARC d’alignement peuvent influencer l’acceptation ultérieure, parfois incorrectement différées jusqu’au RCPT.
4. RCPT TO: : l’adresse du destinataire. C’est l’endroit habituel du « destinataire refusé ». Les vérifications d’existence du destinataire, les recherches dans l’annuaire, le routage vers les serveurs de boîtes aux lettres en aval et les règles de filtrage des destinataires s’exécutent tous ici.
5. DATA : corps du message. Analyse du contenu, limites de taille, contrôles anti-malware. Si vous rejetez ici, la sémantique du rebond peut paraître très différente.

Si le rejet se produit au moment du RCPT, vous devez vous attendre à aucune copie du message de votre côté (sauf si vous journalisez ou l’enregistrez volontairement). Cela signifie que vous déboguez à l’aide des journaux et des traces, pas par recherche dans la boîte mail.

Et oui, il est possible de rejeter au RCPT parce que votre magasin de boîtes aux lettres en backend est lent ou indisponible. Les systèmes font cela pour éviter d’accepter du courrier qu’ils ne peuvent pas livrer. Le mail est un protocole de store-and-forward, mais beaucoup de déploiements réels se comportent comme un service RPC synchrone.

Blague n°1 : SMTP est le seul protocole où « 550 » peut signifier « utilisateur inexistant » et aussi « j’ai une mauvaise journée, ne me demandez pas pourquoi. »

Faits et historique intéressants (court, utile)

• Fait 1 : SMTP précède les systèmes d’identité modernes ; il a été conçu pour des réseaux coopératifs, pas pour des écosystèmes adverses de spam. Beaucoup de problèmes « adresse destinataire refusée » sont des adaptations de politique sur un protocole ancien.
• Fait 2 : L’idée de rejeter au moment du RCPT est devenue populaire parce qu’accepter le DATA pour du spam est coûteux — bande passante, CPU pour l’analyse et I/O disque.
• Fait 3 : Les « attaques de récolte d’annuaire » (directory harvest attacks) ont poussé les admins à désactiver la vérification des destinataires ou à mentir avec des échecs génériques, ce qui embrouille ensuite les expéditeurs légitimes.
• Fait 4 : Le greylisting (rejets temporaires 4xx) était une technique anti-spam précoce qui exploitait le fait que les MTAs conformes réessaient. Il cause toujours des plaintes « utilisateur valide rebondi » quand les expéditeurs ne réessayent pas correctement.
• Fait 5 : Les boîtes « catch-all » étaient autrefois un filet de sécurité courant. Beaucoup d’organisations les ont supprimées pour réduire le spam, augmentant la fréquence des rebonds 5xx.
• Fait 6 : Les DNSBL (listes noires DNS) sont opérationnellement efficaces mais peuvent créer des faux positifs qui se manifestent comme des rejets de destinataire selon l’endroit où les vérifications sont appliquées.
• Fait 7 : Certains MTAs implémentent des « callouts destinataire » (vérifier les destinataires en interrogeant des systèmes en aval). Des callouts mal configurés peuvent transformer une lenteur transitoire du backend en « utilisateur inconnu ».
• Fait 8 : Les adresses e-mail internationalisées existent (SMTPUTF8), mais beaucoup de systèmes les gèrent encore mal. Les utilisateurs avec des parties locales non ASCII peuvent être « valides » en interne et rejetés en externe.
• Fait 9 : Les grands fournisseurs utilisent de plus en plus des limites de débit et la détection d’anomalies qui peuvent rejeter au RCPT comme signal d’abus, et non comme affirmation d’existence du destinataire.

Taxonomie des modes de défaillance « utilisateur valide mais rebond »

1) Le destinataire existe, mais pas sur ce serveur

Le routage du courrier est brutalement littéral. Si le MX pointe vers le mauvais endroit, ou si une passerelle pense être autoritaire pour un domaine alors qu’elle ne l’est pas, le destinataire peut être « inconnu » parce que le mauvais serveur est interrogé.

Causes courantes :

• Les enregistrements MX ont changé mais ne se sont pas propagés, ou sont mis en cache incorrectement.
• Split-brain : des résolveurs différents voient des réponses MX différentes.
• Multiples chemins entrants (filtre cloud + on-prem) avec des règles de validation des destinataires incohérentes.
• Une liste « relay domains » / « local domains » obsolète sur le MTA d’edge.

2) La validation du destinataire dépend d’une recherche d’annuaire qui échoue

Au moment du RCPT, votre edge peut consulter LDAP/AD, SQL, une API ou une table plate. Si cette recherche expire ou renvoie une erreur, certaines configurations échouent en fermé (reject) et d’autres en ouvert (accept and queue).

Le mode fail-closed est plus sûr face à la charge spam. C’est aussi la manière de créer un incident de haute priorité pour une panne d’annuaire qui serait autrement « juste un ralentissement de connexion ».

3) Une boîte valide existe, mais l’alias n’existe pas

Les utilisateurs adorent les alias. Le commercial en particulier. Si vous supprimez un alias, l’utilisateur existe toujours mais le mail vers l’alias est légitimement invalide. L’expéditeur insistera qu’il est valide parce que ça a marché une fois. Et il disait vrai. Ça a marché une fois.

Cela arrive aussi avec le plus-addressing, le subaddressing et les « variations avec point ». Certains systèmes les acceptent ; d’autres normalisent ; d’autres rejettent.

4) Le magasin de boîtes en arrière-plan est en panne ou surchargé ; l’edge refuse tôt

Si votre edge valide les destinataires en contactant le serveur de boîtes (LMTP, proxy, callout), alors la latence du stockage peut se traduire par un rejet SMTP du destinataire. C’est là que l’ingénieur stockage s’amuse à 3 h du matin en se demandant « pourquoi suis-je ici ? ».

Si les métadonnées des boîtes de réception résident sur un stockage en réseau et que ce stockage est malheureux — pics de latence, pool presque plein, corruption de métadonnées ou pépin NFS — vos vérifications de destinataire peuvent échouer et vous refuserez des utilisateurs parfaitement valides.

5) Règles anti-spam/anti-abus trop zélées

Les moteurs de politique rejettent parfois au RCPT parce que c’est peu coûteux. Mais quand vous branchez de la logique de contenu ou de réputation au RCPT, les textes d’erreur peuvent être trompeurs. « Adresse destinataire refusée » devient l’enveloppe générique pour « votre IP semble douteuse » ou « vous envoyez trop vite ».

6) Le côté expéditeur est cassé (et vous êtes quand même accusés)

Certains expéditeurs ne réessayeront pas sur 4xx. Certains réécrivent l’enveloppe. Certains envoient des commandes malformées. Certains font du batching de destinataires qui déclenche vos limites par connexion. Et certains systèmes affichent à l’utilisateur un « adresse refusée » générique quel que soit l’événement réel.

Blague n°2 : Si vous vous sentez inutile, souvenez-vous qu’il existe des clients mail qui cachent le code d’état SMTP « pour simplifier les choses ».

Playbook de diagnostic rapide

Quand vous êtes sous pression, vous n’avez pas besoin d’un cours. Vous devez trouver le goulot rapidement et agir.

Première étape : classer le rebond avec le véritable code SMTP

• Si c’est un 5xx, c’est un rejet dur. Supposez un problème de configuration/politique jusqu’à preuve du contraire.
• Si c’est un 4xx, c’est un rejet temporaire. Supposez de la limitation, du greylisting ou une panne/latence du backend.
• Si l’interface de rebond n’affiche pas les codes, exigez les en-têtes bruts du rebond ou la transcription SMTP. Pas de transcript, pas de certitude.

Deuxième étape : confirmer le routage du courrier (DNS et propriété de l’edge)

• Vérifiez les MX depuis plusieurs résolveurs.
• Confirmez que l’hôte qui rejette est bien le vôtre (ou celui de votre fournisseur) et non une passerelle obsolète.
• Vérifiez que le domaine est configuré de façon cohérente sur tous les sauts entrants.

Troisième étape : reproduire avec une session SMTP contre le même edge

• Utilisez openssl s_client pour STARTTLS et envoyez un RCPT TO manuel.
• Comparez le comportement pour un utilisateur connu valide vs l’utilisateur « en rebond ».
• Recherchez les différences : mappage d’alias, sensibilité à la casse, subaddressing, variantes de domaine.

Quatrième étape : lire les journaux du récepteur au point de rejet

• Trouvez la raison exacte du rejet dans les logs du MTA (pas la paraphrase du rebond).
• Identifiez si le rejet provient de : maps de destinataires, LDAP, service de politique, filtre anti-spam ou d’un callout en aval.

Cinquième étape : décider d’ouvrir temporairement en cas d’échec

Si les annuaires/backends sont instables et que vous avez de la capacité de file d’attente, envisagez d’accepter et de mettre en file d’attente le courrier plutôt que de rejeter au RCPT. Cela vous donne du temps et protège le trafic métier. Cela augmente aussi l’apport de spam. C’est un compromis adulte — prenez cette décision en connaissance de cause.

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

Voici des tâches pratiques à exécuter pendant un incident. Chacune inclut une commande réaliste, une sortie d’exemple, ce que cela signifie et la décision à prendre. Utilisez-les comme des outils, pas comme des rituels.

Task 1: Inspecter le rebond pour obtenir le vrai statut SMTP

cr0x@server:~$ grep -E "Status:|Diagnostic-Code:|Final-Recipient:" -n bounce.eml
12:Final-Recipient: rfc822; user@example.com
13:Action: failed
14:Status: 5.1.1
15:Diagnostic-Code: smtp; 550 5.1.1 <user@example.com>: Recipient address rejected: User unknown in virtual mailbox table

Signification : Il s’agit d’un rejet dur à l’étape du destinataire, et le texte indique un problème de mappage local de destinataires (« virtual mailbox table »).

Décision : Écartez les théories spam/réputation. Allez directement vérifier la configuration des recherches de destinataires et les maps.

Task 2: Confirmer les enregistrements MX du domaine

cr0x@server:~$ dig +short MX example.com
10 mx1.mailgw.example.net.
20 mx2.mailgw.example.net.

Signification : Le courrier entrant doit arriver vers ces passerelles.

Décision : Si l’hôte qui rejette n’est pas l’un de ceux-ci, vous pouvez déboguer une passerelle décommissionnée ou ombre, ou l’expéditeur utilise un DNS mis en cache/incorrect.

Task 3: Vérifier la résolution MX depuis un résolveur différent (chasse au split-brain)

cr0x@server:~$ dig @1.1.1.1 +short MX example.com
10 mx1.mailgw.example.net.
20 mx2.mailgw.example.net.

Signification : Le résolveur public est d’accord. Bon signe.

Décision : Si les résolveurs internes sont en désaccord, corrigez la mise en cache/le transfert DNS interne avant de toucher aux configs mail.

Task 4: Vérifier l’identité du serveur qui rejette et le nom TLS

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.mailgw.example.net:25 -servername mx1.mailgw.example.net </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer
subject=CN = mx1.mailgw.example.net
issuer=CN = Example Internal Issuing CA

Signification : Vous parlez à la passerelle attendue, et le certificat correspond.

Décision : Poursuivez avec un test SMTP en direct contre le même point de terminaison.

Task 5: Reproduire manuellement le rejet RCPT via SMTP

cr0x@server:~$ printf "EHLO test.example.net\r\nMAIL FROM:<probe@test.example.net>\r\nRCPT TO:<user@example.com>\r\nQUIT\r\n" | nc -w 5 mx1.mailgw.example.net 25
220 mx1.mailgw.example.net ESMTP Postfix
250-mx1.mailgw.example.net
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 8BITMIME
250 2.1.0 Ok
550 5.1.1 <user@example.com>: Recipient address rejected: User unknown in virtual mailbox table
221 2.0.0 Bye

Signification : La passerelle elle-même rejette le destinataire avant DATA. Ce n’est pas une analyse de contenu en aval.

Décision : Examinez les maps Postfix virtual mailbox, les maps d’alias, les maps LDAP ou la délégation de politique.

Task 6: Vérifier si l’adresse est présente dans les maps Postfix

cr0x@server:~$ postmap -q "user@example.com" /etc/postfix/virtual_mailbox_maps
mailboxes/example.com/user/

Signification : La map contient une entrée et se résout en un chemin de boîte aux lettres.

Décision : Si le test SMTP rejette toujours, la passerelle peut ne pas utiliser cette map (mauvaise config), ou vous interrogez le mauvais fichier/type.

Task 7: Confirmer quelles maps Postfix utilise réellement

cr0x@server:~$ postconf -n | egrep "virtual_mailbox_maps|virtual_alias_maps|relay_domains|mydestination|smtpd_recipient_restrictions"
mydestination = localhost
relay_domains = example.com
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unknown_recipient, reject_unlisted_recipient
virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps
virtual_mailbox_maps = ldap:/etc/postfix/ldap/virtual_mailbox_maps.cf

Signification : La validation du destinataire est appliquée (reject_unlisted_recipient) et la map de boîtes est basée sur LDAP, pas sur hash.

Décision : Arrêtez d’éditer /etc/postfix/virtual_mailbox_maps. Corrigez la recherche LDAP, les identifiants, le base DN, le filtre ou la connectivité.

Task 8: Tester la recherche LDAP directement (le contrôle « l’annuaire ment-il ? »)

cr0x@server:~$ ldapsearch -x -H ldap://ldap1.example.net -b "ou=People,dc=example,dc=net" "(mail=user@example.com)" dn mail
dn: uid=user,ou=People,dc=example,dc=net
mail: user@example.com

Signification : LDAP contient l’adresse.

Décision : Si Postfix rejette toujours, le problème est dans la configuration de la map LDAP (filtre décalé, nom d’attribut, permissions du bind DN) ou dans des échecs LDAP intermittents.

Task 9: Vérifier les logs Postfix pour la raison spécifique du rejet

cr0x@server:~$ sudo grep -R "reject: RCPT from" /var/log/mail.log | tail -n 5
Jan 04 09:42:11 mx1 postfix/smtpd[28411]: NOQUEUE: reject: RCPT from sender-gw.remote.net[203.0.113.77]: 550 5.1.1 <user@example.com>: Recipient address rejected: User unknown in virtual mailbox table; from=<sender@remote.net> to=<user@example.com> proto=ESMTP helo=<sender-gw.remote.net>

Signification : Le rejet se produit dans smtpd avec « NOQUEUE » (jamais accepté). C’est une décision de politique à la porte d’entrée.

Décision : Concentrez-vous sur les listings/lookup de destinataires et les restrictions ; ne perdez pas de temps à chercher le message dans la file.

Task 10: Valider le fichier de map LDAP que Postfix utilise

cr0x@server:~$ sudo sed -n '1,120p' /etc/postfix/ldap/virtual_mailbox_maps.cf
server_host = ldap1.example.net
search_base = ou=People,dc=example,dc=net
query_filter = (mail=%s)
result_attribute = mail
bind = yes
bind_dn = cn=postfix,dc=example,dc=net

Signification : Cette map retourne l’attribut mail. C’est acceptable pour des vérifications d’existence, mais pas toujours pour le routage de boîte aux lettres.

Décision : Si Postfix attend une destination/chemin de boîte et que vous retournez l’e-mail lui-même, vous pouvez obtenir « unknown in virtual mailbox table ». Alignez result_attribute avec la façon dont vous délivrez (par ex. un attribut chemin maildir), ou utilisez des maps séparées pour existence vs destination.

Task 11: Vérifier les timeouts backend se faisant passer pour « utilisateur inconnu »

cr0x@server:~$ sudo journalctl -u postfix -S "10 min ago" | egrep -i "timeout|ldap|defer|reject" | tail -n 20
Jan 04 09:40:02 mx1 postfix/ldap[28122]: warning: ldap_search: Timeout
Jan 04 09:40:02 mx1 postfix/smtpd[28115]: NOQUEUE: reject: RCPT from sender-gw.remote.net[203.0.113.77]: 450 4.1.1 <user@example.com>: Recipient address rejected: temporary lookup failure; from=<sender@remote.net> to=<user@example.com> proto=ESMTP helo=<sender-gw.remote.net>

Signification : La recherche LDAP a expiré ; le rejet est temporaire (4xx). Certains expéditeurs continueront d’afficher cela comme un « rebond ».

Décision : Traitez cela comme une violation d’un SLO de dépendance : corrigez la latence/connectivité LDAP. Envisagez le fail-open ou la mise en cache pour les vérifications d’existence des destinataires.

Task 12: Vérifier si vous faites du greylisting ou du rate limiting au RCPT

cr0x@server:~$ sudo grep -R "greylist\|rate\|policyd\|postscreen" /var/log/mail.log | tail -n 10
Jan 04 09:41:09 mx1 postfix/smtpd[28307]: warning: unknown[203.0.113.77]: SASL LOGIN authentication failed: authentication failure
Jan 04 09:41:12 mx1 postfix/smtpd[28411]: NOQUEUE: reject: RCPT from sender-gw.remote.net[203.0.113.77]: 451 4.7.1 Service unavailable - try again later; from=<sender@remote.net> to=<user@example.com> proto=ESMTP helo=<sender-gw.remote.net>

Signification : Le rejet est 451 4.7.1 : temporaire, probablement une porte de politique (greylisting, abus, ou problème d’auth).

Décision : Si l’expéditeur est légitime et urgent, mettez temporairement en liste blanche leurs IP d’envoi pendant que vous ajustez la politique et vérifiez leur comportement de retry.

Task 13: Vérifier que le domaine est traité comme local/relay correctement

cr0x@server:~$ postconf -n | egrep "mydestination|virtual_mailbox_domains|relay_domains"
mydestination = localhost
relay_domains = example.com, example.org
virtual_mailbox_domains = example.com

Signification : Le domaine apparaît à la fois comme relay et virtual mailbox domain. C’est suspect ; cela peut changer les recherches utilisées.

Décision : Clarifiez l’architecture : soit vous hébergez les boîtes (virtual mailbox domains), soit vous relayez vers un downstream (relay_domains). Une configuration mixte conduit souvent à des rejets « utilisateur valide » sur un chemin.

Task 14: Confirmer que la boîte existe sur le magasin backing storage

cr0x@server:~$ sudo ls -ld /var/vmail/example.com/user
drwx------ 12 vmail vmail 4096 Jan  4 09:10 /var/vmail/example.com/user

Signification : Le maildir existe sur disque. Bien.

Décision : Si les vérifications de destinataire échouent toujours, le problème n’est pas « dossier de boîte manquant » mais probablement mappage/lookup ou permissions/contexte SELinux.

Task 15: Vérifier la santé du stockage et les conditions « presque plein » qui poussent les systèmes mail à refuser des destinataires

cr0x@server:~$ df -h /var/vmail
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       2.0T  1.9T   80G  96% /var/vmail

Signification : Volume mail à 96% d’utilisation. Beaucoup de MTAs et agents de livraison commencent à échouer de façon étrange sous forte utilisation, et certaines couches de politique rejettent tôt pour éviter des explosions de file.

Décision : Lancez immédiatement un soulagement de capacité : étendez, nettoyez ou déplacez des boîtes. Ne tentez pas d’ajuster les erreurs SMTP pendant que le stockage crie famine.

Task 16: Vérifier la pression sur la file d’attente (si vous acceptez puis différez la livraison)

cr0x@server:~$ mailq | tail -n 5
-- 2435 Kbytes in 512 Requests.

Signification : File modérée. Si ce nombre monte en flèche, vous pouvez accepter du courrier mais échouer en aval, ce qui peut pousser des admins à « rejeter temporairement » les destinataires et créer des rebonds par erreur.

Décision : Si la file croît sans contrôle, corrigez la livraison en aval d’abord ; envisagez d’augmenter temporairement les ressources de file ou de limiter l’entrée au lieu de renvoyer durement des utilisateurs valides.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Ils ont migré le filtrage entrant vers une passerelle de sécurité e-mail cloud. Fenêtre de changement propre, plan de rollback, tests passés. L’équipe a supposé que la validation des destinataires serait identique à l’ancien edge on-prem parce que « c’est juste du forwarding de mail ».

Le lundi matin, un sous-ensemble d’utilisateurs a commencé à rebondir pour des expéditeurs externes avec « 550 5.1.1 user unknown ». En interne, tout semblait normal : les utilisateurs pouvaient s’envoyer des e-mails entre eux et recevoir de quelques partenaires. Cela paraissait aléatoire, ce qui annonce une longue journée.

La mauvaise hypothèse était subtile : l’ancien edge acceptait le courrier pour tous les destinataires et laissait la couche boîte décider de ce qui était valide. La nouvelle gateway faisait la validation des destinataires au moment du RCPT en synchronisant un flux d’annuaire. La mise à jour du flux avait du retard. Les alias nouvellement créés et les listes de distribution n’étaient pas encore présents, donc la gateway les rejetait comme inconnus.

La correction immédiate fut opérationnelle, non philosophique : augmenter la fréquence de synchronisation de l’annuaire, et désactiver temporairement le rejet strict des destinataires pour certains motifs d’adresse pendant que la synchronisation se stabilisait. La correction à plus long terme fut de gouvernance : tout changement d’identité qui affecte des adresses e-mail doit être traité comme une configuration de production, avec garanties de propagation et observabilité.

Tout le monde a appris la même leçon qu’on apprend toujours, mais encore : « forwarder du courrier » est un mythe. Chaque saut est un point d’application de politique. Si vous ne savez pas quel saut est autoritaire pour l’existence d’un destinataire, vous n’avez pas un système mail — vous avez un générateur de rebonds.

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

Une grande organisation se faisait inonder de spam et de tentatives de récolte d’annuaire. Quelqu’un a proposé une optimisation : rejeter immédiatement les destinataires inconnus à l’edge, avant l’analyse du contenu. Cela économiserait CPU et disque. Correct en principe, désastreux en détail.

Ils ont implémenté la vérification des destinataires en faisant des callouts en direct depuis l’edge vers les serveurs de boîtes. Les serveurs de boîtes reposaient sur un cluster de stockage occupé qui avait occasionnellement des pics de latence durant des opérations de snapshot. La plupart des utilisateurs ne remarquaient rien car la livraison pouvait être retardée et rattraper son retard. Mais avec des callouts au moment du RCPT, un pic de 300 ms se transformait en timeout SMTP puis en rejets.

Soudain, pendant les fenêtres de snapshot, l’edge commençait à rejeter des destinataires valides comme « inconnus ». Les expéditeurs externes voyaient des échecs durs. En interne, le monitoring montrait « serveurs de boîtes OK » parce que les serveurs étaient up, juste lents. Les graphiques de stockage montraient le pic, mais personne n’y reliait le comportement SMTP jusqu’à ce qu’un SRE rejoue la transcription SMTP.

La solution n’a pas été de désactiver la protection anti-spam. La solution a été d’arrêter d’utiliser des vérifications synchrones de dépendance backend pour l’existence des destinataires. Ils sont passés à un annuaire de destinataires mis en cache sur l’edge avec une obsolescence bornée, et ont configuré des timeouts pour échouer en ouvert sur les erreurs de lookup tout en limitant le débit des expéditeurs suspects. Ils ont aussi coordonné le timing des snapshots de stockage avec les pics d’activité mail. Aligner les opérations. Grand retour sur investissement.

L’optimisation est excellente, mais seulement quand vous comprenez le nouveau mode de défaillance que vous achetez. Ici, ils ont troqué « charge spam » contre « couplage production ». En mail, le couplage est là où la fiabilité meurt.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe finance s’est plainte que des factures envoyées à un employé particulier rebondissaient avec « adresse destinataire refusée ». L’employé était définitivement réel. Tout le monde s’attendait à une autre journée d’archéologie mail.

L’équipe mail avait une pratique ennuyeuse : chaque rejet SMTP entrant était journalisé avec un code de raison structuré provenant du moteur de politique, et ces logs étaient consultables par destinataire et IP d’envoi. Rien de fancy. Juste une journalisation disciplinée et une conservation.

Ils ont interrogé les logs et constaté que la même IP d’expéditeur avait déclenché une règle de limitation après un pic de messages vers plusieurs destinataires. Le moteur de politique rejetait au RCPT avec un 451 4.7.1, mais le système de l’expéditeur l’a traduit en un rebond dur pour l’utilisateur. La formulation « destinataire refusé » était un mensonge de l’UI.

Parce qu’ils avaient l’heure exacte, le nom de la règle et le code SMTP, ils ont pu effectuer une correction ciblée : mettre temporairement en liste blanche l’IP de l’expéditeur et demander au partenaire d’ajuster son comportement de retry. Pas de chamboulement de config. Pas de changements DNS spéculatifs. Incident clos rapidement, et l’équipe a paru magique — malgré le fait qu’elle soit surtout compétente de manière très peu glamour.

L’observabilité n’est pas glamour, mais c’est la différence entre un incident et un roman policier. En production, on veut des incidents, pas des romans.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom : « 550 5.1.1 user unknown » pour un utilisateur qui existe

Cause racine : L’edge effectue une validation stricte des destinataires contre un annuaire/map obsolète ou défaillant.

Correction : Vérifiez quelle map est autoritaire (postconf -n), testez la recherche directement, corrigez la synchronisation/les timeouts LDAP. Envisagez la mise en cache et le fail-open pour les échecs de lookup.

2) Symptom : Rebonds seulement depuis certains expéditeurs externes

Cause racine : Routage fractionné (différentes cibles MX), expéditeur qui met en cache un ancien MX, ou partenaire utilisant un chemin de passerelle spécifique appliquant des politiques de destinataire différentes.

Correction : Comparez les noms d’hôte/IP qui rejettent à travers les rebonds. Alignez la politique destinataire sur toutes les passerelles entrantes. Assurez-vous que les anciennes passerelles renvoient « domaine non géré » clair plutôt que « utilisateur inconnu ».

3) Symptom : Seuls les alias rebondissent ; l’adresse principale fonctionne

Cause racine : Map d’alias manquante, alias supprimé, ou alias non inclus dans le flux d’annuaire utilisé par l’edge.

Correction : Réajoutez l’alias ou corrigez la synchronisation des alias. Si vous l’avez supprimé volontairement, communiquez et mettez en place une redirection contrôlée ou une période d’auto-réponse plutôt qu’un rebond dur.

4) Symptom : Destinataires aléatoires rebondissent en heures de pointe

Cause racine : La vérification des destinataires dépend de la latence backend (LDAP, callouts serveur de boîtes, stockage). Les timeouts causent des rejets.

Correction : Augmentez la résilience : cache local, timeouts appropriés/plus longs, fail-open pour erreurs transitoires, et séparez les throttles anti-spam des vérifications d’existence.

5) Symptom : « Adresse destinataire refusée » mais le code SMTP est 5.7.1

Cause racine : Rejet de politique (réputation, authent, TLS requis, expéditeur bloqué) présenté avec un texte trompeur par l’UI de l’expéditeur ou une gateway.

Correction : Utilisez les logs/transcript. Si c’est une politique, ajustez la politique. Ne perdez pas de temps à valider la boîte aux lettres.

6) Symptom : Les nouvelles recrues rebondissent pendant quelques heures après création

Cause racine : Délai de propagation identité→mail (synchronisation d’annuaire, politique d’adresse, synchronisation gateway cloud). L’edge rejette tant que les données ne sont pas arrivées.

Correction : Raccourcissez l’intervalle de sync, publiez des SLO de propagation attendus, et envisagez d’accepter et de mettre en file d’attente le courrier pour les destinataires inconnus pendant cette fenêtre si l’impact métier est élevé.

7) Symptom : Seules les adresses internationalisées rebondissent en externe

Cause racine : Incompatibilité de gestion SMTPUTF8/IDN ; la gateway ou l’expéditeur ne prend pas en charge les parties locales en UTF-8 ou attend un domaine en punycode.

Correction : Assurez la prise en charge SMTPUTF8 de bout en bout ou évitez les parties locales non ASCII pour les adresses externes. Pour les domaines, confirmez une configuration IDN cohérente.

8) Symptom : L’utilisateur existe, mais le mail rebondit après déplacement/migration de boîte

Cause racine : L’attribut de routage mail (targetAddress, table de routage mail, ou map de transport interne) n’a pas été mis à jour partout ; certaines passerelles pointent encore vers l’ancien stockage.

Correction : Auditez les attributs de routage, assurez-vous que l’ancien store renvoie des déferrals temporaires (4xx) plutôt que des 5xx durant la migration, et maintenez les redirections/relays jusqu’à ce que la bascule soit entièrement cohérente.

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

Étape par étape : gérer un ticket « utilisateur valide rebondi » comme un adulte

1. Obtenir le rebond brut. Demandez les en-têtes complets et la ligne diagnostique SMTP. Les captures d’écran sont de la décoration.
2. Extraire : code SMTP, hôte qui rejette, horodatage, destinataire, expéditeur d’enveloppe, IP d’envoi si présente.
3. Confirmer le routage : enregistrements MX, et si l’hôte qui rejette est sur le chemin entrant attendu.
4. Reproduire : session SMTP manuelle vers l’hôte qui rejette ; testez le destinataire signalé et un destinataire témoin.
5. Lire les logs : trouver l’entrée NOQUEUE: reject et le module (smtpd, policy, ldap, postscreen).
6. Identifier la porte : maps de destinataires, annuaire, moteur de politique, limitation, callout, ou routage en aval.
7. Corriger la porte : entrée de map, sync d’alias, réglage des timeouts, whitelist, santé du backend, ou correction DNS/routage.
8. Décider d’un contournement temporaire : fail-open pour les lookups, accept-and-queue temporaire, ou whitelist partenaire.
9. Vérifier avec le même test de reproduction. N’attendez pas qu’un partenaire « réessaye plus tard » sans preuve.
10. Consigner la classe d’incident. Si vous ne pouvez pas le catégoriser la prochaine fois, vous ne l’avez pas vraiment réparé.

Checklist : choix d’architecture qui réduisent ces incidents

• Choisir où l’existence du destinataire est appliquée : edge vs couche boîte. Soyez explicite.
• Si vous appliquez à l’edge, mettez en cache avec une fenêtre d’obsolescence définie et surveillez la santé de la sync.
• Séparer « utilisateur inconnu » de « rejet de politique » dans les logs et dans les réponses SMTP (les codes d’état améliorés aident).
• Privilégier le 4xx pour les défaillances de dépendance (timeout LDAP, timeout callout boîte). Le 5xx doit signifier « ça ne fonctionnera jamais ».
• Garder les chemins entrants cohérents (multiples MX, gateways cloud, edges régionaux). Même logique destinataire partout.
• Instrumenter et conserver les logs de rejet suffisamment longtemps pour recouper les timelines métier.
• Le monitoring de capacité stockage est du monitoring e-mail si vos métadonnées et livraisons dépendent de ce stockage.

Checklist : ce qu’il ne faut pas faire (parce que ça donne l’impression d’être productif)

• Ne pas « vider le DNS » comme premier réflexe. Vérifiez d’abord les réponses DNS et le comportement de cache.
• Ne pas désactiver la validation des destinataires globalement en panique sans considérer l’impact spam.
• Ne pas éditer des fichiers de map que Postfix n’utilise pas (vérifiez postconf -n avant de toucher quoi que ce soit).
• Ne pas traiter les 4xx comme non-problème ; certains expéditeurs ne réessaieront pas, et vous gérerez quand même la panne.
• Ne pas accepter le courrier aveuglément si vous ne pouvez pas mettre en file en toute sécurité (disque quasi plein, file déjà explosive).

FAQ

1) Si l’utilisateur peut se connecter, pourquoi l’e-mail dit « utilisateur inconnu » ?

Parce que l’identité de connexion et l’identité de routage du mail sont des systèmes différents. L’edge peut valider contre une vue d’annuaire différente, une sync obsolète ou un attribut différent (primaire vs alias).

2) « Adresse destinataire refusée » est-ce toujours de notre faute ?

Non. Cela peut venir d’un expéditeur qui ne réessaie pas sur 4xx, d’un expéditeur utilisant un MX obsolète, ou d’une UI qui paraphrase chaque rejet comme un problème d’adresse. Votre travail est de prouver où le rejet a eu lieu et pourquoi.

3) Devons-nous rejeter les destinataires inconnus à l’edge ?

Généralement oui pour contrôler le spam, mais uniquement si vous pouvez le faire de manière fiable : recherches d’annuaire rapides, cache et comportement sensé sur les échecs de dépendance. Sinon vous échangez le spam contre des rebonds auto-infligés.

4) Quelle est la différence entre rejeter au RCPT et après DATA ?

Le rejet au moment du RCPT a lieu avant d’accepter le corps du message ; c’est moins coûteux et évite la mise en file. Le rejet après DATA vous donne plus de contexte (analyse du contenu), mais vous avez déjà accepté plus de travail et vous devrez peut-être générer des DSN selon le comportement.

5) Pourquoi certains rebonds affichent 550 alors que le vrai problème est la limitation de débit ?

Certaines gateways utilisent des codes 5xx génériques pour plusieurs rejets de politique, et certains logiciels expéditeurs compressent plusieurs erreurs en « adresse refusée ». Utilisez toujours le code d’état enrichi et le texte diagnostic exact des logs.

6) Des problèmes de stockage peuvent-ils vraiment causer « destinataire refusé » ?

Oui. Si la vérification du destinataire dépend de métadonnées de boîte sur le disque ou d’un callout vers un serveur de boîtes lent à cause de la latence stockage, l’edge peut expirer et rejeter le destinataire.

7) Quelle est l’atténuation temporaire la plus sûre pendant une panne d’annuaire ?

Si vous avez de la capacité de file : échouer en ouvert sur les erreurs de lookup d’annuaire (accepter le mail, différer la livraison) tout en limitant le débit par IP et en appliquant des contrôles anti-abus basiques. Si vous n’avez pas de capacité de file, il faudra peut-être renvoyer un 4xx.

8) Pourquoi cela n’arrive-t-il que pour les nouveaux comptes ?

Délai de propagation : la boîte existe dans un système, mais la liste de destinataires de l’edge (ou la sync gateway cloud) n’est pas encore à jour. Corrigez la pipeline de sync et publiez les SLO attendus pour que « ça marche deux heures plus tard » ne soit pas votre plan opérationnel.

9) Notre partenaire insiste avoir reçu un rebond dur, mais nous voyons des 451 temporaires. Qui a raison ?

Les deux. Vous avez renvoyé un échec temporaire ; leur système a choisi de le traiter comme permanent (ou leur UI l’a fait). Si c’est un partenaire important, demandez-lui de confirmer le comportement de retry et envisagez une whitelist ciblée.

10) Comment empêcher des messages d’erreur trompeurs ?

Vous ne pouvez pas contrôler les UI des expéditeurs, mais vous pouvez contrôler vos réponses SMTP. Utilisez des codes d’état améliorés précis et incluez une courte raison qui mappe à une clé de runbook interne (« policy:rate-limit », « lookup:ldap-timeout »).

Conclusion : prochaines étapes réellement exploitables

« Adresse destinataire refusée » n’est pas un diagnostic. C’est un symptôme d’une décision prise au moment du destinataire SMTP — souvent par une couche de politique qui cherche à être efficace. Votre travail est de trouver la porte exacte et décider si elle doit être stricte, mise en cache ou temporairement permissive.

Faites ceci ensuite :

1. Standardisez la capture des rebonds : exigez le code SMTP, l’hôte qui rejette et l’horodatage.
2. Rendez explicite la validation des destinataires : quel saut est autoritaire, et que se passe-t-il quand les lookups échouent.
3. Instrumentez les raisons de rejet avec des logs structurés et conservez-les suffisamment longtemps pour recouper les timelines métier.
4. Auditez les dépendances : latence LDAP, callouts serveur de boîtes en backend, capacité de stockage. Si elles peuvent rejeter des destinataires, elles font partie de votre SLO entrant.
5. Exercez le playbook de diagnostic rapide une fois quand vous n’êtes pas en feu. Votre futur vous sera moins grognon.