Lire un bounce

Module 6: Bounces et résolution de problèmes · Temps de lecture : 11 minutes

Objectif pédagogique : après cette leçon, vous saurez décortiquer un message d'erreur de non-remise (un bounce) : quel serveur a donné l'erreur, pour quelle adresse, ce que signifie le code, et s'il s'agit d'un problème temporaire ou définitif.

Notions clés : bounce, Mailer-Daemon, delivery status notification (DSN, RFC 3464), Reporting-MTA, Remote-MTA, Final-Recipient, Action (failed, delayed), Status, Diagnostic-Code, Will-Retry-Until, code de réponse (RFC 5321), code de statut étendu X.Y.Z (RFC 3463), message de retard, backscatter

Qu'est-ce qu'un bounce ?

Si un serveur de messagerie ne peut pas remettre un e-mail, il renvoie un message à l'expéditeur. C'est ce qu'on appelle un bounce (ou : non-delivery report, NDR). Il provient d'un expéditeur du type Mailer-Daemon@..., MAILER-DAEMON ou Mail Delivery System, avec un objet du type :

• Mail delivery failed: returning message to sender
• Undelivered Mail Returned to Sender
• Delivery Status Notification (Failure)
• Warning: message ... delayed 24 hours (ceci n'est pas un bounce mais un message de retard, voir plus loin)

Beaucoup de personnes jettent immédiatement ce genre de message, ou sont déconcertées par le texte en anglais. C'est dommage, car un bounce indique presque toujours précisément ce qui ne va pas. Il suffit de savoir où regarder.

Un bounce a toujours un expéditeur d'enveloppe vide (Return-Path: <>). C'est volontaire : un bounce sur un bounce pourrait sinon créer une boucle sans fin (RFC 5321).

Qui a refusé le message ?

Un e-mail passe par au moins deux serveurs : celui de votre fournisseur et celui du destinataire. Un bounce peut survenir dans deux situations :

1. Le serveur destinataire refuse le message pendant la conversation SMTP (leçon 1.2), par exemple après RCPT TO (adresse inconnue) ou après le contenu (spam ou DMARC). Votre propre serveur reçoit ce refus et en fait un bounce pour vous. L'erreur provient alors du destinataire, le bounce de votre propre serveur.
2. Votre propre serveur abandonne, par exemple parce que le destinataire était injoignable pendant plusieurs jours, ou parce que vous avez atteint vous-même une limite.

Cette distinction est importante : dans le premier cas, vous devez savoir ce qui n'a pas convenu au destinataire, dans le second cas, le problème se situe plus près de chez vous.

La partie lisible

En haut figure un texte destiné aux humains. Il varie selon le logiciel de messagerie, mais contient presque toujours les mêmes éléments :

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  pieter.devries@example.net
    host mx1.example.net [198.51.100.20]
    SMTP error from remote mail server after RCPT TO:<pieter.devries@example.net>:
    550 5.1.1 <pieter.devries@example.net>: Recipient address rejected: User unknown

Lisez-le ainsi :

La partie machine : le DSN

Sous le texte figure généralement une partie destinée aux programmes, la delivery status notification (RFC 3464). Elle est toujours construite de la même façon, ce qui la rend facile à lire :

Reporting-MTA: dns; mail.hosting.example

Action: failed
Final-Recipient: rfc822;pieter.devries@example.net
Status: 5.1.1
Remote-MTA: dns; mx1.example.net
Diagnostic-Code: smtp; 550 5.1.1 <pieter.devries@example.net>: Recipient address rejected: User unknown

Tout en bas figure l'e-mail original, ou seulement ses en-têtes. Vous y voyez de quel message il s'agissait, ainsi que l'adresse d'expéditeur et le Return-Path utilisés. C'est parfois la clé de la solution (voir le cas DMARC dans l'exercice).

Lire les codes

Il existe deux types de codes, et ils figurent presque toujours tous les deux dans un bounce.

Le code de réponse (RFC 5321) : trois chiffres, comme 550 ou 451. Le premier chiffre est le plus important :

Le code de statut étendu (RFC 3463) : trois nombres séparés par des points, comme 5.1.1 ou 4.7.500. Le premier nombre est à nouveau 2, 4 ou 5. Le deuxième nombre indique où se situe le problème :

Le troisième nombre est la raison précise. Les grands destinataires utilisent leurs propres numéros pour cela, comme Gmail avec 5.7.25 à 5.7.30 et Microsoft avec 4.7.500 et 5.7.509. Ils figurent dans leur propre documentation (leçon 6.2).

Règle empirique : le code qui commence par 5 et dont le chiffre du milieu est 7 (5.7.x) est presque toujours une question de politique : authentification, réputation ou spam. Renvoyer le message ne sert à rien dans ce cas ; il faut changer quelque chose.

Différé n'est pas encore un échec

En cas d'erreur temporaire (4xx), votre serveur conserve le message et réessaie. La RFC 5321 recommande de persévérer pendant au moins quatre à cinq jours, avec au moins une demi-heure entre les tentatives. Beaucoup de serveurs envoient après quelques heures ou après un jour un message de retard :

Action: delayed
Status: 4.7.500
Diagnostic-Code: smtp; 451 4.7.500 Server busy. Please try again later from [203.0.113.25].
Will-Retry-Until: Thu, 12 Nov 2026 08:58:40 +0100

Cela signifie : ne renvoyez pas le message, le serveur essaie encore lui-même. Si vous le renvoyez tout de même, le destinataire risque de le recevoir deux fois. Si finalement cela échoue avant Will-Retry-Until, un véritable bounce arrivera tout de même, souvent avec 4.4.7 (message expiré dans la file d'attente).

Faux bounces : le backscatter

Recevez-vous soudain des dizaines de bounces pour des e-mails que vous n'avez jamais envoyés ? Regardez alors dans l'e-mail original tout en bas. Si vous y voyez un expéditeur de votre domaine, mais un serveur et un texte que vous ne connaissez pas, c'est qu'un spammeur a utilisé votre adresse comme expéditeur. Les destinataires renvoient leurs bounces vers vous. C'est ce qu'on appelle le backscatter.

Votre boîte mail n'est généralement pas piratée dans ce cas (voir la leçon 3.4 pour la différence). Ce qui aide : une politique DMARC qui se durcit progressivement (leçon 4.4), afin que les destinataires refusent les messages falsifiés avant même qu'un bounce ne se produise. Vérifiez tout de même dans vos messages envoyés et auprès de votre fournisseur que rien n'a réellement été envoyé depuis votre boîte mail.

En pratique : voici à quoi cela ressemble

Chez WebOké, outre le bounce, vous voyez aussi dans Suivi des e-mails de DirectAdmin ce que le serveur a fait d'un message : Livré, Différé ou Échec, avec la réponse du serveur destinataire. D'autres panneaux disposent souvent d'un journal de messagerie comparable ou d'un « suivi des messages » ; chez Microsoft 365, cela s'appelle par exemple le suivi des messages. Il est utile d'y regarder d'abord si vous n'avez pas reçu de bounce, ou si quelqu'un vous dit que votre e-mail n'est pas arrivé.

Résumé

• Un bounce provient de Mailer-Daemon et a un Return-Path vide. Lisez-le, il indique presque toujours précisément ce qui ne va pas.
• Regardez d'abord qui a donné l'erreur (SMTP error from remote mail server = le destinataire) et pour quelle adresse.
• Dans la partie machine : Action, Status, Remote-MTA et surtout Diagnostic-Code.
• Premier chiffre : 4 = temporaire, 5 = définitif. Deuxième nombre : 1 adresse, 2 boîte mail, 3 système, 4 routage, 5 protocole, 6 contenu, 7 politique.
• Message de retard (delayed) : ne renvoyez pas le message. Bounces pour des messages que vous n'avez pas envoyés : backscatter.

Quiz

Exercice

Exercice Z6.1 : Analyser trois bounces. Vous recevez trois exemples de bounces (bounce-1.txt, bounce-2.txt et bounce-3.txt). Indiquez pour chaque bounce : l'adresse concernée par l'échec, le serveur qui a donné l'erreur (Remote-MTA), le code de statut, s'il s'agit d'un problème temporaire ou définitif, et ce que l'expéditeur doit faire (à choisir dans une liste). Le programme vérifie avec une clé fixe et donne une explication pour chaque champ.

Pour aller plus loin

Les étapes décrites dans ces articles s'appliquent aux panneaux de WebOké ; chez d'autres fournisseurs, le fonctionnement est comparable.

• Échec de la livraison du courrier : comment lire le message d'erreur et ce que signifient les codes
• Message d'erreur : 550 5.5.0 Requested action not taken: mailbox unavailable
• Vérifier qu'un e-mail est bien arrivé avec Email Tracking dans DirectAdmin
• Guide DirectAdmin 9.3: Suivi des e-mails : où est passé mon message ?
• RFC 3464 (structure d'un DSN), RFC 3463 (codes de statut étendus), RFC 5321 paragraphe 4.2 (codes de réponse) et 4.5.4.1 (nouvelles tentatives)