← RFC Reference

RFC 3461 : Extension SMTP de notification d'état de livraison

Pourquoi cela existe

Le SMTP basique (RFC 5321) vous garantit uniquement d'être informé des défaillances — le serveur destinataire génère un message de retour si la livraison échoue finalement. Mais les expéditeurs ont souvent besoin de plus :

• Une confirmation positive qu'un message a été livré à la boîte aux lettres du destinataire
• Des notifications de délai quand un message est coincé dans une file d'attente
• Un rapport sélectif — notifier uniquement en cas d'échec, ou uniquement en cas de succès
• Un suivi au niveau de l'enveloppe en utilisant un identifiant opaque que l'expéditeur peut corréler à la soumission d'origine

Sans cette extension, les expéditeurs sont aveugles : le silence pourrait signifier une livraison réussie ou un message perdu. RFC 3461 ajoute des paramètres SMTP qui permettent au MTA d'origine de demander explicitement des notifications d'état de livraison (DSN) et de contrôler leur contenu.

Comment cela fonctionne

L'extension DSN est négociée lors de la poignée de main SMTP EHLO. Quand le serveur destinataire annonce DSN, l'expéditeur peut utiliser deux nouveaux ensembles de paramètres :

Paramètres MAIL FROM

• RET=FULL ou RET=HDRS — contrôle si les messages DSN incluent le corps complet du message d'origine ou seulement les en-têtes. HDRS est recommandé pour les grands messages.
• ENVID=value — un identifiant d'enveloppe (jusqu'à 100 caractères codés en xtext) qui sera retourné dans tout DSN, permettant à l'expéditeur de corréler la notification au message d'origine.

Paramètres RCPT TO

• NOTIFY=conditions — une liste séparée par des virgules de : SUCCESS, FAILURE, DELAY, ou la valeur spéciale NEVER. Cela contrôle quand un DSN est généré.
• ORCPT=type;address — l'adresse du destinataire d'origine (avant toute expansion d'alias ou réacheminement), afin que le DSN puisse signaler l'adresse que l'expéditeur avait réellement l'intention d'utiliser.

Exemple de session SMTP

EHLO sender.example.com
250-mail.example.org Hello
250-SIZE 52428800
250-DSN
250 STARTTLS

; Demander DSN avec ID d'enveloppe, retourner les en-têtes uniquement en cas de rebond
MAIL FROM:<alice@sender.example.com> RET=HDRS ENVID=msg-20260311-0042
250 OK

; Notifier en cas de succès ou d'échec, préserver le destinataire d'origine
RCPT TO:<bob@example.org> NOTIFY=SUCCESS,FAILURE ORCPT=rfc822;bob@example.org
250 Accepted

; Supprimer tous les DSN pour ce destinataire
RCPT TO:<bcc-copy@archive.example.com> NOTIFY=NEVER
250 Accepted

DATA
354 Start mail input
[message content]
.
250 OK

Détails techniques clés

Valeurs NOTIFY

Si NOTIFY est omis, le comportement par défaut est équivalent à NOTIFY=FAILURE — vous êtes uniquement notifié en cas d'échec permanent.

Codage ENVID

La valeur ENVID utilise le codage xtext : les caractères ASCII imprimables passent inchangés, mais + et = (et les caractères en dehors de la plage ASCII imprimable) sont codés comme +XX où XX est la valeur hexadécimale. Cela maintient le paramètre sûr pour le transport SMTP.

Comportement de relais

Les MTA intermédiaires qui supportent DSN doivent propager les paramètres DSN lors du relais. Si un MTA intermédiaire ne supporte pas DSN, il doit quand même générer les messages de retour appropriés selon les règles SMTP standard, bien que les contrôles DSN affinés seront perdus.

Erreurs courantes

• Combiner NEVER avec d'autres valeurs. NOTIFY=NEVER,FAILURE est invalide. NEVER doit apparaître seul.
• Utiliser des paramètres DSN sans vérifier EHLO. Si le serveur n'annonce pas DSN, l'inclusion de ces paramètres causera une erreur de syntaxe (code 501).
• S'attendre à DSN de tous les serveurs. Le support DSN est optionnel. De nombreux grands fournisseurs de boîtes aux lettres ne l'annoncent pas, ce qui signifie que vous ne pouvez pas forcer Gmail ou Outlook à vous envoyer des notifications de succès.
• Utiliser RET=FULL pour les grands messages. Cela cause l'inclusion du message d'origine complet (y compris les pièces jointes) dans le DSN, ce qui peut atteindre les limites de taille ou gaspiller de la bande passante.
• Oublier ORCPT lors du réacheminement. Si votre serveur étend des alias ou réachemine du courrier, l'omission d'ORCPT signifie que le DSN signalera l'adresse finale, pas celle utilisée par l'expéditeur.

Impact sur la livrabilité

Le support DSN est une infrastructure critique pour l'envoi de courrier électronique professionnel :

• Traitement des rebonds. La gestion programmatique des rebonds repose sur DSN pour identifier quel destinataire a échoué et pourquoi. Le paramètre ENVID vous permet de corréler les rebonds à des campagnes ou transactions spécifiques.
• Hygiène des listes. NOTIFY=FAILURE (par défaut) garantit que vous apprenez les adresses invalides. La suppression rapide des adresses qui rebondissent protège votre réputation d'expéditeur.
• Suppression du trafic inutile. Utilisez NOTIFY=NEVER pour les copies en copie cachée ou les adresses d'archive où vous n'avez pas besoin de confirmation de livraison.
• Sensibilisation aux délais. NOTIFY=DELAY vous alerte sur les problèmes de livraison avant qu'ils ne deviennent des défaillances permanentes, vous donnant le temps d'enquêter.

Related RFCs