SMTP Return Path expliqué

Le Return-Path (parfois appelé Reverse-Path ou Envelope-FROM - tous ces termes peuvent être utilisés de manière interchangeable) est la valeur utilisée pendant la session SMTP.

Seul le serveur de messagerie du destinataire est censé ajouter un en-tête Return-Path en haut de l'e-mail. Celui-ci enregistre l'expéditeur réel du Return-Path pendant la session SMTP. Tous les rebonds (bounces) qui se produisent au cours de la session SMTP doivent renvoyer à la valeur Return-Path. Certains serveurs peuvent accepter tous les courriels et les mettre en file d'attente localement jusqu'à ce qu'ils aient un thread libre pour les livrer à la boîte aux lettres du destinataire. Si le destinataire n'existe pas, il doit le renvoyer à la valeur Return-Path enregistrée.

Remarque : tous les serveurs de messagerie ne respectent pas cette règle. Certains serveurs de messagerie renverront le message à l'adresse FROM.

En termes plus simples, lorsqu'un courriel n'arrive pas à sa destination prévue, le Return-Path indique où les reçus de non-livraison - ou messages de rebond (bounce messages) - doivent être envoyés. Le Return-Path peut également être appelé adresse de rebond (bounce address), chemin inverse (reverse path), envelope From, MAIL FROM (et bien d'autres encore).

L'en-tête Return-Path est ajouté par le serveur de courrier récepteur et non par l'expéditeur. Vous pouvez écrire l'adresse de votre choix à l'intérieur de l'enveloppe, mais pour la distribuer, vous devez l'apporter au bureau de poste et leur montrer votre carte d'identité, et le bureau de poste met alors cette adresse sur l'enveloppe avant de l'envoyer. En d'autres termes, l'en-tête Return-Path est aussi fiable que les contrôles effectués par le serveur SMTP récepteur, alors que les autres peuvent être facilement usurpés.

"MAIL FROM" est simplement la façon techniquement correcte de dire Return-Path ; c'est la même chose.

Le Return-Path est visible dans le courrier livré sous la forme d'un champ d'en-tête Return-Path inséré par l'agent de livraison du courrier SMTP (mail delivery agent - MDA) (qui est généralement associé à un agent de transfert du courrier, ou MTA). Le MDA copie simplement le chemin inverse de la commande SMTP MAIL FROM dans le champ Return-Path. Le MDA supprime également les faux champs d'en-tête Return-Path insérés par d'autres MTA ; ce champ d'en-tête est généralement garanti comme reflétant le dernier chemin inverse vu dans la commande MAIL FROM.

Les Non-Delivery Receipts (NDR) sont une fonction de base du SMTP. Dès qu'un MTA a accepté un courrier pour le transférer ou le distribuer, il ne peut pas le supprimer silencieusement ("drop") ; il doit créer et envoyer un message de rebond à l'expéditeur si le transfert ou la distribution a échoué.

À propos des messages de rebond (bounce messages)

Un message de rebond (bounce message) ou simplement "rebond" (bounce) est un message automatisé provenant d'un système de courrier électronique, informant l'expéditeur d'un message précédent que ce dernier n'a pas été remis (ou qu'un autre problème de remise est survenu). On dit que le message original a "rebondi".

Ce retour peut être immédiat ou, si le système d'envoi peut réessayer, il peut arriver plusieurs jours plus tard après la fin de ces réessais.

Les termes plus formels pour désigner le message de rebond incluent "Rapport de non-livraison" (Non-Delivery Report) ou "Justificatif de non-livraison" (Non-Delivery Receipt - NDR), message de "Notification d'état de livraison" (Delivery Status Notification - DSN),  ou "Notification de non-livraison" (Non-Delivery Notification - NDN).

Classification

Bien que le SMTP soit une technologie mature, comptant plus de trente ans, l'architecture est de plus en plus sollicitée par la charge normale et non sollicitée. Les systèmes de courrier électronique ont été améliorés avec des systèmes de réputation liés à l'expéditeur réel du courrier électronique, avec l'idée que les serveurs de courrier électronique du destinataire rejettent le courrier électronique lorsqu'un faux expéditeur est utilisé dans le protocole. [Par conséquent, deux types de rebonds ont été créés : les rebonds durs (hard bounces) et les rebonds mous (soft bounces), qui affectent tous deux la réputation IP de l'expéditeur, car les fournisseurs de services de courrier électronique (ESP) considèrent le taux de rebond total comme un facteur de décision lorsqu'ils dirigent le courrier électronique vers la boîte de réception d'un utilisateur. En bref, le taux de rebond total est calculé comme la somme du taux de rebond dur et du taux de rebond mou.

Rebonds durs

Les hard bounces sont permanents et ont un score plus élevé en termes de dommage IP de l'expéditeur. Ils se produisent lorsque le serveur de messagerie de l'expéditeur détermine qu'il y a une forte probabilité que le destinataire soit indisponible et qu'il le reste. Les rebonds durs se produisent notamment lorsque le destinataire du courrier électronique se trouve dans l'une des situations suivantes : identifiant incorrect/domaine incorrect (comme une faute de frappe dans l'adresse électronique ou dans le domaine) ou son serveur n'accepte plus les courriers électroniques. Dans ce cas, la suppression des adresses électroniques qui rebondissent est obligatoire.

Rebonds mous

Les soft bounces sont temporaires. Un message rebondi qui subit un soft bounce peut être réacheminé à un autre moment. Les soft bounces se produisent lorsque le destinataire de l'e-mail a soit une boîte de réception pleine et donc pas d'espace pour stocker un autre e-mail, soit une limite sur la taille des e-mails qu'il est autorisé à recevoir. D'autres situations dans lesquelles un soft bounce apparaît sont un blocage mis en place sur le courriel du destinataire pour marquer un certain expéditeur comme un expéditeur de "spam", ou pour mettre un certain expéditeur sur liste noire. En outre, une suspension temporaire du courrier électronique du destinataire ou une erreur temporaire sur le serveur sont également des causes de soft bounce.

Dans tous les cas, le soft bounce est envoyé lorsque les erreurs en question sont temporaires, du moins, lorsqu’elles peuvent être corrigées par le destinataire ou son serveur.

Le format de rapport des messages administratifs est défini par la RFC 6522. Une "Notification de l'état de la livraison" (Delivery Status Notification - DSN) peut être un message MIME multipart/report composé de trois parties :

1. une explication lisible par l'homme ;
2. un message/delivery-status analysable par la machine, une liste de lignes "name : type ; value" qui énonce plusieurs champs possibles ; et :
3. le message original, ou une partie de celui-ci, en tant qu'entité de type message/rfc822.

La deuxième partie d'un DSN est également très lisible. Il est essentiel de comprendre quel MTA joue quel rôle. Le Reporting-MTA est responsable de la composition et de l'envoi du DSN.

Lorsqu'un Remote-MTA rejette un message au cours d'une transaction SMTP, un champ Diagnostic-Code de type smtp peut être utilisé pour signaler cette valeur. Notez qu'en plus de la valeur numérique à 3 chiffres, la réponse SMTP contient elle-même une partie lisible par l'homme. L'information :

Remote-MTA: dns; smtp.store.example [192.0.2.3]
Diagnostic-Code: smtp; 550 No such user here

est parfois rapportée comme, par exemple :

while talking to smtp.store.example [192.0.2.3]
>>> RCPT TO:<nonexistinguser@store.example>
<<< 550 No such user here

Les MTA impliqués dans un rejet sont nommés en fonction du point de vue du MTA déclarant. Les noms des MTA sont souvent de type dns.

En savoir plus : https://en.wikipedia.org/wiki/Bounce_message