Groupe de travail Réseau	K. Moore, University of Tennessee	
Request for Comments : 3461	janvier 2003	
RFC rendue obsolète : 1891		
Catégorie : En cours de normalisation	Traduction Claude Brière de L’Isle	

Extension de service du protocole simple de transfert de messagerie (SMTP) pour les notifications d'état de livraison (DSN)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.
(La présente traduction incorpore les errata 269 et 686)

Notice de Copyright
Copyright (C) The Internet Society (2003). Tous droits réservés.

Résumé
Le présent mémoire définit une extension au service du protocole simple de transfert de messagerie (SMTP, Simple Mail Transfer Protocol) qui permet au client SMTP de spécifier (a) que les notifications d’état de livraison (DSN, Delivery Status Notification) devraient être générées dans certaines conditions, (b) si de telles notifications devraient retourner le contenu du message, et (c) des informations supplémentaires, à retourner avec une DSN, qui permettent à l’envoyeur d’identifier à la fois le ou les receveurs pour lesquels la DSN a été produite, et la transaction dans laquelle le message original était envoyé.

Terminologie
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

Table des matières
1. Introduction	2
2. Cadre pour l’extension Notification d’état de livraison	2
3. Extension de service Notification d’état de livraison	3
4. Paramètres supplémentaires pour les commandes RCPT et MAIL	3
4.1 Paramètre NOTIFY de la commande RCPT ESMTP	4
4.2 Paramètre ORCPT de la commande RCPT ESMTP	4
4.3 Paramètre RET de la commande MAIL ESMTP	5
4.4 Paramètre ENVID de la commande MAIL ESMTP	5
4.5 Restrictions à l’utilisation du paramètre Notification d’état de livraison	6
5. Exigences de conformité	6
5.1 Interactions avec le protocole SMTP	6
5.2 Traitement des messages reçus via SMTP	7
5.3 Traitement des messages provenant d’autres sources	11
5.4 Limites de mise en œuvre	11
6. Format des notifications de livraison	11
6.1 Enveloppe SMTP à utiliser avec les notifications d’état de livraison	11
6.2 Contenu de la DSN	11
6.3 Champs de l’état de livraison de message	12
7. Remerciements	13
8. Considérations pour la sécurité	13
9. Appendice Définitions des noms de type	13
9.1 Type d’adresse "rfc822"	13
9.2 Type de diagnostic "smtp"	14
9.3 Type de nom de MTA "dns"	14
10. Appendice Exemple	15
10.1 Soumission	15
10.2 Relais à Example.COM	15
10.3 Relais à Ivory.EDU	16
10.4 Relais à Bombs.AF.MIL	16
10.5 Transmission de George@Tax-ME.GOV à Sam@Boondoggle.GOV	17
10.6 DSN "livrée" à Bob@Example.COM	17
10.7 Éched de DSN pour Carol@Ivory.EDU	18
10.8 DSN relayée pour Dana@Ivory.EDU	19
10.9 Échec de notification pour Sam@Boondoggle.GOV	19
11. Appendice Changements depuis la RFC1891	20
12. Références	20
12.1 Références normatives	20
12.2 Références pour information	20
13. Adresse de l’auteur	21
14. Déclaration complète de droits de reproduction	21

1.	Introduction

Le protocole SMTP [RFC0821] exige qu’un serveur SMTP fournisse des notification d’échec de livraison, si il détermine qu’un message ne peut pas être livré à un ou plusieurs receveurs. Traditionnellement, de telles notifications consistent en un message ordinaire de messagerie Internet (format défini par la [RFC0822]) envoyé à l’adresse d’envoyeur de l’enveloppe (l’argument de la commande SMTP MAIL) contenant une explication de l’erreur et au moins les en-têtes du message défaillant.

L’expérience des grandes listes de distribution de messagerie [RFC1211] indique que de tels messages sont souvent insuffisants pour diagnostiquer les problèmes, ou même pour déterminer à quel hôte ou pour quels receveurs est survenu un problème. De plus, l’absence d’un format normalisé pour les notifications de livraison dans la messagerie Internet rend difficile d’échanger de telles notifications avec les autres systèmes de traitement de message.

Cette expérience a montré la nécessité d’un service de notification d’état de livraison pour la messagerie électronique Internet, qui :
(a)	soit fiable, en ce sens que toute demande DSN sera soit honorée au moment de la livraison finale, soit résultera en une réponse qui indique que la demande ne peut pas être honorée,
(b)	lorsque sont demandées des notifications à la fois de succès et d’échec, fournir une indication non ambiguë et non contradictoire de ce que la livraison d’un message à un receveur a réussi ou échoué,
(c)	soit stable, en ce qu’un échec de tentative de livraison d’une DSN ne devrait jamais résulter en la transmission d’une autre DSN sur le réseau,
(d)	préserve des informations suffisantes pour permettre à l’envoyeur d’identifier la transaction de messagerie et l’adresse du receveur qui a causé la notification, même quand le message est transmis ou passé à des environnements étrangers, 
(e)	fasse des interfaces acceptables avec des systèmes de messagerie non SMTP et non fondés sur la RFC822, de telle sorte que les notifications retournées des systèmes de messagerie étrangers puissent être utiles aux utilisateurs de l’Internet, et que les demandes de notification provenant des environnements étrangers puissent être honorés. Parmi les exigences impliquées par ces objectifs figure la capacité à demander le non retour des contenus, et la capacité de spécifier si des notifications de livraison positives, des notifications de livraison négatives, les deux, ou ni l’une ni l’autre, devraient être produites.

Pour essayer de fournir un tel service, le présent mémoire utilise le mécanisme défini dans la [RFC0821] pour définir une extension au protocole SMTP. En utilisant ce mécanisme, un client SMTP peut demander qu’un serveur SMTP produise ou non une notification d’état de livraison (DSN, Delivery Status Notification) sous certaines conditions. Le format d’une DSN est défini dans la [RFC3464].

2.	Cadre pour l’extension Notification d’état de livraison

L’extension de service suivante est donc définie :
(1)	Le nom de l’extension de service SMTP est "Notification d’état de livraison";
(2)	La valeur du mot clé EHLO associé à cette extension est "DSN", dont la signification est définie à la section 3 du présent mémoire ;
(3)	Aucun paramètre n’est admis avec cette valeur de mot clé EHLO ;
(4)	Deux paramètres facultatifs sont ajoutés à la commande RCPT, et deux paramètres facultatifs sont ajoutés à la commande MAIL :
Un paramètre facultatif pour la commande RCPT, utilisant le mot clé esmtp "NOTIFY", (pour spécifier les conditions dans lesquelles une notification d’état de livraison devrait être générée) est défini au paragraphe 5.1,
Un paramètre facultatif pour la commande RCPT, utilisant le mot clé esmtp "ORCPT", (utilisé pour convoyer l’adresse du receveur "original" (spécifiée par l’envoyeur)) est défini au paragraphe 5.2.
Un paramètre facultatif pour la commande MAIL, utilisant le mot clé esmtp "RET", (pour demander que les DSN contenant une indication d’échec de livraison retournent soit le contenu entier d’un message, soit seulement les en-têtes du message) est défini au paragraphe 5.3.
Un paramètre facultatif pour la commande MAIL, utilisant le mot clé esmtp "ENVID", (utilisé pour propager un identifiant pour l’enveloppe de transmission de ce message, qui est aussi connu de l’envoyeur et va, s’il est présent, être retourné dans toutes les DSN produites pour cette transmission) est défini au paragraphe 4.4.
(5)	Aucun verbe SMTP supplémentaire n’est défini par cette extension.

Le reste de ce mémoire spécifie comment la prise en charge de l’extension affecte le comportement d’un agent de transfert de message.

3.	Extension de service Notification d’état de livraison

Un client SMTP qui souhaite demander une DSN pour un message peut produire la commande EHLO pour débuter une session SMTP, pour déterminer si le serveur prend en charge une des diverses extensions de service. Si le serveur répond à la commande EHLO par le code 250, et si la réponse comporte le mot clé EHLO de DSN, alors l’extension de notification d’état de livraison (comme décrite dans le présent mémoire) est prise en charge.

Normalement, lorsque un serveur SMTP retourne un code de réponse positif (2xx) en réponse à une commande RCPT, il signifie qu’il accepte la responsabilité de la livraison du message au receveur désigné, ou de l’envoi d’une notification à l’envoyeur du message indiquant l’échec de la livraison. Cependant, un serveur SMTP étendu ("ESMTP") qui met en œuvre cette extension de service va accepter un paramètre NOTIFY facultatif avec la commande RCPT. S’il est présent, le paramètre NOTIFY altère les conditions de génération des notifications d’état de livraison par défaut (ne produire les notifications qu’en cas d’échec) spécifiées dans la [RFC0821]. Le client ESMTP peut aussi demander (via le paramètre RET) si le contenu entier du message d’origine devrait être retourné (plutôt que juste les en-têtes de ce message) avec la DSN.

En général, un serveur ESMTP qui met en œuvre cette extension de service va propager les demandes de notification d’état de livraison lorsque il relaye la messagerie aux autres MTA fondés sur SMTP qui prennent aussi en charge cette extension, et faire "au mieux" pour assurer que de telles demandes sont honorées lorsque les messages sont passés dans d’autres environnements.

Afin que les notifications d’état de livraison soient significatives pour l’envoyeur, les serveurs ESMTP qui prennent en charge cette extension, devraient propager les informations suivantes pour les utiliser lors de la génération de DSN à tout autre MTA utilisé pour relayer le message :
(a)	Pour chaque receveur, une copie de l’adresse du receveur original, telle qu’utilisée par l’envoyeur du message.
Cette adresse n’a pas besoin d'être la même que la boite aux lettres spécifiée dans la commande RCPT. Par exemple, si un message était à l’origine adressé à A@B.C et qu’il est ensuite transmis à A@D.E, après qu’une telle transmission a eu lieu, la commande RCPT va spécifier une boite aux lettres de A@D.E. Cependant, l’adresse du receveur original reste A@B.C.
Aussi, si le message généré dans un environnement qui n’utilise pas le style des adresses Internet usager@domaine, et a traversé une passerelle pour arriver dans SMTP, l’adresse originale du receveur sera préservée sous la forme originale de l’adresse du receveur.
(b)	Pour la transaction SMTP toute entière, une chaîne d’identification d’enveloppe, qui peut être utilisée par l’envoyeur pour associer toute notification d’état de livraison à la transaction utilisée pour envoyer le message d’origine.

4.	Paramètres supplémentaires pour les commandes RCPT et MAIL

Les commandes RCPT et MAIL étendues sont produites par un client lorsque il souhaite demander une DSN de la part du serveur, sous certaines conditions, pour un receveur particulier. Les commandes RCPT et MAIL étendues sont identiques aux commandes RCPT et MAIL définies dans la [RFC0821], excepté qu’un ou plusieurs des paramètres suivants apparaissent dans l’adresse, respectivement de l’envoyeur ou du receveur. La syntaxe générale pour les commandes SMTP étendues est définie dans la [RFC0821].

Note : Bien que l’ABNF de la RFC822 soit utilisé pour décrire la syntaxe de ces paramètres, ils ne sont pas, dans le langage du présent document, "des corps de champ structuré". Donc, bien que des parenthèses PUISSENT apparaître au sein d’une valeur vide, elles ne sont pas reconnues comme délimiteurs de commentaire.

La syntaxe de "valeur-vide" dans la [RFC0821] ne permet pas que SP, "=", les caractères de contrôle, ou les caractères qui sortent de la gamme ASCII traditionnelle de 1 à 127 en décimal soient transmis dans une valeur-esmtp. Comme les paramètres ENVID et ORCPT peuvent avoir besoin de convoyer des valeurs qui sortent de cette gamme, les valeurs-esmtp pour ces paramètres sont codées comme "xtext". La définition formelle de "xtext" est la suivante :

xtext = *( xchar / hexchar )

xchar = tout ASCII CHAR entre "!" (33) et "~" (126) inclus, excepté "+" et "=".

; les "hexchar" sont destinés à coder les octets qui ne peuvent pas apparaître comme caractères ASCII au sein d’une valeur-esmtp.

hexchar = ASCII "+" immédiatement suivi de deux chiffres hexadécimaux en majuscule

Lorsque on code une séquence d’octet comme xtext :
+	Tout CHAR ASCII entre "!" et "~" inclus, excepté "+" et "=", PEUT être codé comme lui-même. (Un CHAR dans cette gamme PEUT à la place être codé comme "hexchar", à la discrétion de la mise en œuvre.)
+	Les CHAR ASCII qui sortent de la gamme ci-dessus doivent être codés comme "hexchar".

4.1	Paramètre NOTIFY de la commande RCPT ESMTP

Une commande RCPT produite par un client peut contenir le mot clé esmtp "NOTIFY" facultatif, pour spécifier les conditions dans lesquelles le serveur SMTP devrait générer des DSN pour ce receveur. Si le mot clé esmtp NOTIFY est utilisé, il DOIT avoir une valeur esmtp associée, formatée conformément aux règles suivantes, en utilisant l’ABNF de la RFC822 :

notifier-valeur-esmtp = "NEVER" / 1#notifier-liste-element

notifier-liste-element = "SUCCES" / "ECHEC" / "RETARD"

Notes :
a.	Plusieurs notifier-liste-element, séparés par des virgules, PEUVENT apparaître dans un paramètre NOTIFY ; cependant, le mot clé NEVER DOIT apparaître par lui-même.
b.	Tout mot clé NEVER, SUCCES, ECHEC, ou RETARD peut être épelé sous toute combinaison de majuscules et minuscules.

La significations des valeurs du paramètre NOTIFY est généralement la suivante :
+	Une valeur de paramètre NOTIFY de "NEVER" demande que, sous aucune condition, une DSN ne soit retournée à l’envoyeur.
+	Une valeur de paramètre NOTIFY contenant le mot clé "SUCCES" ou "ECHEC" demande qu’une DSN soit produite respectivement à réussite de livraison ou à échec de livraison.
+	Une valeur de paramètre NOTIFY contenant le mot clé "RETARD" indique la volonté de l’envoyeur de recevoir des DSN "retardées". Des DSN retardées peuvent être produites si la livraison d’un message a été retardée d’une durée inhabituelle (comme déterminé par le MTA où le message est retardé) mais l’état de livraison final (que ce soit réussite ou échec) ne peut pas être déterminé. L’absence du mot clé RETARD dans un paramètre NOTIFY demande qu’une DSN "retardée" NE SOIT produite sous aucun prétexte.

Les règles réelles qui gouvernent l’interprétation du paramètre NOTIFY sont à la section 6.

Pour la compatibilité avec les clients SMTP qui n’utilisent pas la facilité NOTIFY, l’absence d’un paramètre NOTIFY dans une commande RCPT peut être interprétée soit comme NOTIFY=ECHEC, soit comme NOTIFY=ECHEC,RETARD.

4.2	Paramètre ORCPT de la commande RCPT ESMTP

Le mot clé esmtp ORCPT de la commande RCPT est utilisé pour spécifier une adresse "originale" du receveur qui correspond au receveur réel auquel le message est à livrer. Si le mot clé esmtp ORCPT est utilisé, il DOIT avoir une valeur esmtp associée qui consiste en l’adresse originale du receveur, codée selon les règles ci-dessous. L’ABNF pour le paramètre ORCPT est :

orcpt-parameter = "ORCPT=" adresse-originale-du-receveur

adresse-originale-du-receveur = type-d’adresse ";" xtext

type-d’adresse = atome

La portion "type-d’adresse" DOIT être un type d’adresse de messagerie électronique enregistré par l’IANA (comme défini dans la [RFC3464]) alors que la portion "xtext" contient une représentation codée de l’adresse originale du receveur en utilisant les règles de la section 4 du présent document. Le paramètre ORCPT entier PEUT faire jusqu’à 500 caractères.

Quand on soumet initialement un message via SMTP, si le paramètre ORCPT est utilisé, il DOIT contenir la même adresse que celle de RCPT TO (à la différence de l’adresse RCPT TO, le paramètre ORCPT sera codé comme xtext). De même, lorsque une liste de diffusion soumet un message via SMTP à distribuer aux abonnés de la liste, si ORCPT est utilisé, le paramètre ORCPT DOIT correspondre à la nouvelle adresse RCPT TO de chaque receveur, et non à l’adresse spécifiée par l’envoyeur original du message.)

La portion "type-d’adresse" de l’adresse originale du receveur est utilisée pour indiquer le "type" de l’adresse qui apparaît dans la valeur du paramètre ORCPT. Cependant, l’adresse associée au mot clé ORCPT N’EST PAS obligée de se conformer aux règles de syntaxe de "type-d’adresse".

Idéalement, la portion "xtext" de l’adresse originale du receveur devrait contenir une forme codée de la même séquence de caractères que celle que l’envoyeur a utilisé pour la spécifier au receveur. Cependant, pour un message passé d’un environnement (tel que X.400) dans lequel une adresse de receveur n’est pas une simple chaîne de caractères imprimables, la représentation de l’adresse du receveur doit être définie par une spécification de passage entre les DSN et cet environnement.

Du fait des limitations du format de notification d’état de livraison, la valeur de l’adresse originale du receveur avant de la coder comme "xtext" DOIT consister entièrement en caractères imprimables (graphiques et espaces) du répertoire US-ASCII [ANSI]. Si un type-d’adresse est défini pour des adresses qui utilisent des caractère qui sortent de ce répertoire, la spécification de ce type-d’adresse DOIT définir les moyens de codage de ces adresses en caractères US-ASCII imprimables lorsque ils sont codés comme xtext.

4.3	Paramètre RET de la commande MAIL ESMTP

Le mot clé esmtp RET sur la commande MAIL étendue spécifie si le message devrait ou non être inclus dans une DSN d’échec produite pour cette transmission de message. Si mot clé esmtp RET est utilisé, il DOIT avoir une valeur esmtp associée, qui est un des mots clés suivants :

FULL demande que le message entier soit retourné dans toute notification d’état de livraison "échec" produite pour ce receveur.

HDRS demande que seuls les en-têtes du message soient retournés.

Les mots clés FULL et HDRS peuvent être épelés dans toute combinaison de lettres majuscules et minuscules.

Si aucun paramètre RET n’est fourni, le MTA PEUT retourner soit les en-têtes du message, soit le message entier pour toute DSN contenant une indication d’échec de livraison.

Noter que le paramètre RET ne s’applique qu’aux DSN qui indiquent l’échec de livraison pour au moins un receveur. Si une DSN ne contient pas d’indication d’échec de livraison, seuls les en-têtes du message devraient être retournés.

4.4	Paramètre ENVID de la commande MAIL ESMTP

Le mot clé esmtp ENVID de la commande SMTP MAIL est utilisé pour spécifier un "identifiant d’enveloppe" à transmettre avec le message et inclus dans toutes les DSN produites pour tout receveur désigné dans cette transaction SMTP. L’objet de l’identifiant d’enveloppe est de permettre que l’envoyeur d’un message identifie la transaction pour laquelle a été produite la DSN.

L’ABNF pour le paramètre ENVID est :

paramètre-envid = "ENVID =" xtext

Le mot clé esmtp ENVID DOIT avoir une valeur esmtp associée. Aucune signification n’est affectée par le système de messagerie à la présence ou l’absence de ce paramètre ou à toute valeur esmtp associée à ce paramètre ; l’information n’est utilisée que par l’envoyeur ou par son agent d’utilisateur. Le paramètre ENVID PEUT faire jusqu’à 100 caractères.

Du fait des limitations du format de notification d’état de livraison, la valeur du paramètre ENVID avant son codage comme "xtext" DOIT consister entièrement en caractères imprimables (graphiques et espaces) du répertoire US-ASCII [ANSI].

4.5	Restrictions à l’utilisation du paramètre Notification d’état de livraison
Les paramètres RET et ENVID NE DOIVENT PAS apparaître plus d’une fois chacun dans une seule commande MAIL. Si plus d’un de ces paramètres apparaît dans une commande MAIL, le serveur ESMTP DEVRAIT répondre par "501 erreur de syntaxe dans les paramètres ou arguments".

Les paramètres  NOTIFY et ORCPT NE DOIVENT PAS apparaître plus d’une fois chacun dans une commande RCPT. Si plus d’un de ces paramètres apparaît dans une commande RCPT, le serveur ESMTP DEVRAIT répondre par "501 erreur de syntaxe dans les paramètres ou arguments".

5.	Exigences de conformité

Le protocole simple de transfert de messagerie (SMTP, Simple Mail Transfer Protocol) est utilisé par les agents de transfert de message (MTA, Message Transfer Agent) lorsque ils acceptent,de  relayer, ou d’envoyer par une passerelle, de la messagerie, ainsi que par les agents d’utilisateur (UA, User Agent) lorsque ils soumettent des messages au système de transport de messagerie. L’extension DSN à SMTP peut être utilisée pour permettre aux UA de convoyer les demandes de l’envoyeur sur le moment où des DSN devraient être produites. Un UA qui prétend être conforme à la présente spécification doit satisfaire à certaines exigences qui sont décrites ci-dessous.

Normalement, un agent de transfert de message (MTA) qui prend en charge SMTP va assumer à des moments différents, à la fois le rôle d’un client SMTP et d’un serveur SMTP, et peut aussi effectuer la livraison locale, le passage à des environnements étrangers, la transmission et l’expansion de liste de diffusion. Un MTA qui, quand il agit comme serveur SMTP, produit le mot clé DSN en réponse à la commande EHLO, DOIT obéir aux règles ci-dessous pour un "client SMTP conforme" lorsque il agit comme client, et pour un "serveur SMTP conforme" lorsque il agit comme serveur. Le terme de "MTA conforme" se réfère à un MTA qui se conforme à la présente spécification, indépendamment de son rôle de client ou de serveur.

5.1	Interactions avec le protocole SMTP

Les règles suivantes s’appliquent aux transactions SMTP dans lesquelles est utilisé un des mots clé ENVID, NOTIFY, RET, ou ORCPT:

(a)	Si un client SMTP produit une commande MAIL contenant un paramètre ENVID et une valeur esmtp associée valides et/ou un paramètre RET et une valeur esmtp associée valides, un serveur SMTP conforme DOIT retourner le même code de réponse qu’il retournerait à la même commande MAIL sans les paramètres RET et/ou ENVID. Un serveur SMTP conforme NE DOIT PAS refuser une commande MAIL sur la base de l’absence ou présence de paramètres ENVID ou RET valides, ou de leur valeur esmtp associée.

Cependant, si la valeur esmtp associée n’est pas valide (c’est-à-dire, contient des caractères illégaux) ou si il y a plus d’un paramètre RET ou ENVID dans une commande MAIL particulière, le serveur DOIT produire le code 501 avec un message approprié(par exemple, "erreur de syntaxe dans les paramètres").

(b)	Si un client SMTP produit une commande RCPT contenant un paramètre ORCPT et/ou NOTIFY valides, un serveur SMTP conforme DOIT retourner la même réponse que celle qu’il aurait retournée à la même commande RCPT sans ces paramètres NOTIFY et/ou ORCPT. Un serveur SMTP conforme NE DOIT PAS refuser une commande RCPT sur la base de la présence ou l’absence d’un de ces paramètres.

Cependant, si une des valeurs esmtp associées n’est pas valide, ou si il y a plus d’un de ces paramètres dans une commande RCPT particulière, le serveur DEVRAIT produire la réponse "501 erreur de syntaxe dans les paramètres".

5.2	Traitement des messages reçus via SMTP

Cette section décrit comment un MTA conforme devrait traiter tout les messages reçus via SMTP.

Note : Une DSN NE DOIT PAS être retournée à l’envoyeur pour un message pour lequel d’adresse de retour provenant de la commande SMTP MAIL était NULLE ("<>") même si l’adresse de l’envoyeur est disponible d’autres sources (par exemple, l’en-tête du message). Cependant, le MTA qui autrement produirait une DSN DEVRAIT informer le maître de poste local des échecs de livraison par quelque mécanisme approprié qui ne va pas lui-même résulter en la production de DSN.

Discussion : La RFC 1123, section 5.3.3 exige que les notifications d’erreur soient envoyées avec une adresse de retour NULLE ("chemin inverse"). Cela crée une situation intéressante lorsque un message arrive avec une ou plusieurs adresses de receveur non fonctionnelles en plus d’une adresse de retour non fonctionnelle. Lorsque échoue la livraison à une des adresses de receveur, le MTA va tenter d’envoyer une notification de non livraison à l’adresse de retour, réglant l’adresse de retour sur la notification à NULLE. Lorsque la livraison de cette notification échoue, le MTA qui tente de livrer cette notification voit une adresse de retour NULLE. Si ce MTA n’a personne à informer de la situation, le message d’origine sera perdu en silence. De plus, une adresse de retour non fonctionnelle est souvent l’indication d’un problème de configuration au MTA de l’envoyeur. Le rapport de la condition au maître de poste local peut aider à accélérer la correction de telles erreurs.

5.2.1	Relais des messages avec les autres serveurs SMTP conformes
Les règles suivantes gouvernent le comportement d’un MTA conforme, lors du relais d’un message qui a été reçu via le protocole SMTP, à un serveur SMTP qui prend en charge l’extension de service de notification d’état de livraison :

(a)	Tout paramètre ENVID inclus dans la commande MAIL lorsque un message a été reçu, DOIT aussi apparaître sur la commande MAIL avec laquelle le message est relayé, avec la même valeur esmtp associée. Si aucun paramètre ENVID n’était inclus dans la commande MAIL lorsque le message a été reçu, le paramètre ENVID NE DOIT PAS être fourni lorsque le message est relayé.

(b)	Tout paramètre RET inclus dans la commande MAIL lorsque un message a été reçu, DOIT aussi apparaître sur la commande MAIL avec laquelle le message est relayé, avec la même valeur esmtp associée. Si aucun paramètre RET n’était inclus dans la commande MAIL lorsque le message a été reçu, le paramètre RET NE DOIT PAS être fourni lorsque le message est relayé.

(c)	Si le paramètre NOTIFY a été fourni pour un receveur lorsque le message a été reçu, la commande RCPT produite lorsque le message est relayé DOIT aussi contenir le paramètre NOTIFY avec sa valeur esmtp associée. Si le paramètre NOTIFY n’était pas fourni pour un receveur lorsque le message est reçu, le paramètre NOTIFY NE DOIT PAS être fourni pour ce receveur lorsque le message est relayé.

(d)	Si un paramètre ORCPT était présent dans la commande RCPT pour un receveur lorsque le message a été reçu, un paramètre ORCPT avec une adresse originale de receveur identique DOIT apparaître dans la commande RCPT produite pour ce receveur lors du relais du message. (Par exemple, le MTA NE DOIT donc PAS changer la casse des caractères alphabétiques dans un paramètre ORCPT.)

Si aucun paramètre ORCPT n’était présent dans la commande RCPT lorsque le message a été reçu, un paramètre ORCPT PEUT être ajouté à la commande RCPT lorsque le message est relayé. Si un paramètre ORCPT est ajouté par le MTA relais, il DOIT contenir l’adresse du receveur provenant de la commande RCPT utilisée lorsque le message a été reçu par ce MTA.

5.2.2	Relais des messages aux serveurs SMTP non conformes
Les règles suivantes gouvernent le comportement d’un MTA conforme (dans le rôle de client) lors du relais d’un message qui a été reçu via le protocole SMTP, à un serveur SMTP qui ne prend pas en charge l’extension de service de notification d’état de livraison :

(a)	Les paramètres ENVID, NOTIFY, RET, ou ORCPT NE DOIVENT PAS être produits lors du relais du message.

(b)	Si le paramètre NOTIFY a été fourni pour un receveur, avec une valeur esmtp contenant le mot clé SUCCES, et si le serveur SMTP retourne un code de réponse de succès (2xx) en réponse à la commande RCPT, le client DOIT produire une DSN "relayé" pour ce receveur.

(c)	Si le paramètre NOTIFY a été fourni pour un receveur avec une valeur esmtp contenant le mot clé ECHEC, et si le serveur SMTP retourne un code de réponse d’échec permanent (5xx) en réponse à la commande RCPT, le client DOIT produire une DSN "échec" pour ce receveur.

(d)	Si le paramètre NOTIFY a été fourni pour un receveur avec une valeur esmtp de NEVER, le client NE DOIT PAS produire une DSN pour ce receveur, sans considération du code de réponse retourné par le serveur SMTP. Cependant, si le serveur a retourné un code de réponse d’échec (5xx) le client PEUT informer le maître de poste local de l’échec de livraison via un mécanisme approprié qui ne va pas résulter lui-même en la génération de DSN.
Lors d’une tentative de relais d’un message à un serveur SMTP qui ne prend pas en charge cette extension, et si NOTIFY=NEVER a été spécifié pour certains receveurs de ce message, un client SMTP conforme PEUT relayer le message pour les receveurs dans une transaction SMTP distincte, en utilisant un chemin inverse vide dans la commande MAIL. Cela va empêcher les DSN d’être produites pour ces receveurs par les MTA qui se conforment à la [RFC0821].

(e)	Si un paramètre NOTIFY n’a pas été fourni pour un receveur, et si le serveur SMTP retourne un code de réponse de réussite (2xx) en réponse à une commande RCPT, le client NE DOIT PAS produire de DSN pour ce receveur.

(f)	Si un paramètre NOTIFY n’a pas été fourni pour un receveur, et si le serveur SMTP retourne un code de réponse d’échec permanent (5xx) en réponse à une commande RCPT, le client DOIT produire une DSN "échec" pour ce receveur.

5.2.3	Livraison locale des messages
Les règles suivantes gouvernent le comportement d’un MTA conforme lors de la réussite de livraison d’un message qui a été reçu via le protocole SMTP, à la boîte aux lettres d’un receveur local :

"livraison" signifie que le message a été placé dans la boîte aux lettres du receveur. Pour les messages qui sont transmis à une boîte aux lettres pour restitution ultérieure via IMAP [RFC2060], POP [RFC1939] ou un protocole d’accès au message similaire, la "livraison" survient lorsque le message est rendu disponible au service IMAP (POP, etc.) plutôt que lorsque le message est récupéré par l’agent d’utilisateur du receveur.

De même, pour une adresse de receveur qui correspond à un exploseur de liste de diffusion, la "livraison" survient lorsque le message est rendu disponible à cet exploseur de liste, même si l’exploseur de liste pourrait refuser de livrer ce message aux receveurs de la liste.

(a)	Si le paramètre NOTIFY a été fourni pour ce receveur, avec une valeur esmtp contenant le mot clé SUCCES, le MTA DOIT produire une DSN "livré" pour ce receveur.

(b)	Si le paramètre NOTIFY qui a été fourni pour ce receveur ne contenait pas le mot clé SUCCES, le MTA NE DOIT PAS produire une DSN pour ce receveur.

(c)	Si le paramètre NOTIFY n’a pas été fourni pour ce receveur, le MTA NE DOIT PAS produire une DSN.

5.2.4	Passage d’un message dans un environnement étranger
Les règles suivantes gouvernent le comportement d’un MTA conforme, lorsque il passe un message qui a été reçu via le protocole SMTP, dans un environnement étranger (non SMTP) :

(a)	Si l’environnement étranger est capable de produire des notifications appropriées dans les conditions demandées par le paramètre NOTIFY, et si le MTA conforme peut assurer que toute notification ainsi produite sera traduite en une DSN et livrée à l’envoyeur d’origine, alors le MTA DEVRAIT passer le message dans l’environnement étranger, en demandant une notification sous les conditions désirées, sans produire lui-même de DSN.

(b)	Si un paramètre NOTIFY a été fourni avec le mot clé SUCCES, mais si l’environnement de destination ne peut pas retourner une notification appropriée lors de la réussite de la livraison, le MTA DEVRAIT produire une DSN "relayée" pour ce receveur.

(c)	Si un paramètre NOTIFY a été fourni avec un mot clé esmtp de NEVER, une DSN NE DOIT PAS être produite. Si possible, le MTA DEVRAIT indiquer à l’environnement de destination de ne pas produire de notifications de livraison pour ce receveur.

(d)	Si le paramètre NOTIFY n’a pas été fourni pour un receveur particulier, une DSN NE DEVRAIT PAS être produite par la passerelle. La passerelle DEVRAIT tenter de s’assurer que la notification appropriée sera fournie par l’environnement de messagerie étranger si un éventuel échec de livraison survenait, et qu’aucune notification ne sera produite en cas de réussite de la livraison.

(e)	Lors du passage d’un message dans un environnement étranger, les conditions de retour de contenu spécifiées par tout paramètre RET ne constituent pas une obligation ; cependant, le MTA DEVRAIT tenter d’honorer la demande en utilisant tout mécanisme existant dans l’environnement étranger.

5.2.5	Retards de livraison
Si un MTA conforme reçoit un message via le protocole SMTP, et si il est incapable de livrer ou relayer le message à un ou plusieurs receveurs pendant une durée étendue (à déterminer par le MTA) il PEUT produire une DSN "retardé" pour ces receveurs, sous réserve des conditions suivantes :

(a)	Si le paramètre NOTIFY a été fourni pour un receveur et si sa valeur incluait le mot clé RETARD, une DSN "retardé" PEUT être produite.

(b)	Si le paramètre NOTIFY n’était pas fourni pour un receveur, une DSN "retardé" PEUT être produite.

(c)	Si le paramètre NOTIFY a été fourni et si il ne contient pas le mot clé RETARD, une DSN "retardé" NE DOIT PAS être produite.

Note : Bien que les notifications de retard soient courantes dans la messagerie électronique actuelle, un MTA conforme n’est jamais obligé de produire des DSN "retardé". Le mot clé RETARD du paramètre NOTIFY est fourni pour permettre au client SMTP de demander spécifiquement (en omettant le paramètre RETARD) que des DSN "retardé" NE SOIENT PAS produites.

5.2.6	Défaillance d’un MTA conforme à livrer un message
Les règles suivantes gouvernent le comportement d’un MTA conforme qui a reçu un message via le protocole SMTP, et est incapable de livrer un message à un receveur spécifié dans la transaction SMTP:

(a)	Si un paramètre NOTIFY a été fourni pour le receveur avec un mot clé esmtp qui contient la valeur ECHEC, une DSN "échec" DOIT être produite par le MTA.

(b)	Si un paramètre NOTIFY a été fourni pour le receveur et si il ne contient pas la valeur ECHEC, une DSN NE DOIT PAS être produite pour ce receveur. Cependant, le MTA PEUT informer le maître de poste local de l’échec de livraison via un mécanisme approprié qui ne résulte pas lui-même en une génération de DSN.

(c)	Si aucun paramètre NOTIFY n’a été fourni pour le receveur, une DSN "échec" DOIT être produite.

Note : Certains MTA sont connus pour transmettre des messages non délivrables au maître de poste local ou à une boîte aux lettres "lettre morte". Cela est encore considéré comme un échec de livraison, et ne diminue pas l’exigence de produire une DSN "échec" dans les conditions définies plus loin dans le présent mémoire. Si une DSN est produite pour un tel receveur, la valeur Action DOIT être "échec".

5.2.7	Transmission, alias, et listes de diffusion
La livraison d’un message à une adresse de messagerie électronique locale cause habituellement la mémorisation du message dans la boîte aux lettres du receveur. Cependant, les MTA fournissent couramment une facilité par laquelle une adresse de messagerie locale peut être désignée comme un "alias" ou une "liste de diffusion" ; la livraison à cette adresse cause alors la transmission du message à chacune des adresses (locales ou distantes) des receveurs associés à l’alias ou à la liste. Il est aussi courant de permettre à un utilisateur de "transmettre" facultativement sa messagerie à une ou plusieurs adresses de remplacement. Si ce dispositif est activé, ses messages sont redistribués à ces adresses au lieu d’être déposés dans sa boîte aux lettres.

Suivant l’exemple de la [RFC1123] (paragraphe 5.3.6) le présent document définit les différences entre un "alias" et une "liste de diffusion" comme suit : lors de la transmission d’un message aux adresses associées à un "alias", l’adresse de retour d’enveloppe (par exemple, SMTP MAIL FROM) reste intacte. Cependant, lors de la transmission d’un message aux adresses associées à une "liste de diffusion", l’adresse de retour d’enveloppe est changée en celle de l’administrateur de la liste de diffusion. Cela est cause que les DSN et autres rapports de non livraison résultant de la livraison aux membres de la liste sont envoyés à l’administrateur de la liste plutôt qu’à l’envoyeur du message d’origine.

Le traitement de la DSN pour les alias et les listes de diffusion est le suivant :

5.2.7.1	Listes de diffusion
Lorsque un message est livré à une adresse de soumission de liste (c’est-à-dire, placée dans la boite aux lettres de la liste pour la messagerie entrante, ou acceptée par le processus qui redistribue les messages aux abonnés de la liste) cela est considéré comme livraison finale pour le message d’origine. Si le paramètre NOTIFY pour l’adresse de soumission de liste contenait le mot clé SUCCES, une DSN "livré" DOIT être retournée à l’envoyeur du message d’origine.

Note : Certaines listes de diffusion sont capables de rejeter les soumissions de message sur la base du contenu du message, de l’adresse de l’envoyeur, ou de certains autres critères. Alors que l’interface entre une telle liste de diffusion et son MTA n’est pas très bien définie, il est important que les DSN NE SOIENT PAS produites à la fois par le MTA (pour rapporter la réussite de la livraison à la liste) et par la liste (pour rapporter le rejet du message en utilisant une DSN "échec").

Cependant, même si une DSN "livré" était produite par le MTA, une liste de diffusion qui rejette une soumission de message PEUT notifier à l’envoyeur que le message a été rejeté en utilisant un message ordinaire au lieu d’une DSN.

Chaque fois qu’un message est redistribué à une liste de diffusion,
(a)	L’adresse de retour d’enveloppe est réécrite pour pointer sur le tenancier de la liste. Cette adresse PEUT être celle d’un processus qui reconnaît les DSN et les traite automatiquement, mais DOIT transmettre les messages non reconnus à la personne responsable de la liste.
(b)	Les paramètres ENVID, NOTIFY, RET, et ORCPT qui accompagnent le message redistribué NE DOIVENT PAS être déduits de ceux du message d’origine.
(c)	Les paramètres NOTIFY et RET PEUVENT être spécifiés par le maître de poste local ou par l’administrateur de la liste. Si les paramètres ORCPT sont fournis durant la redistribution aux abonnés de la liste, ils DEVRAIENT contenir les adresses des abonnés de la liste dans le format utilisé par la liste de diffusion.

5.2.7.2	Alias d’un seul receveur
Dans des circonstances normales, quand un message arrive pour un "alias" qui a une seule adresse de transmission, une DSN NE DEVRAIT PAS être produite. Tout paramètre ENVID, NOTIFY, RET, ou ORCPT DEVRAIT être propagé avec le message comme si il était redistribué à l’adresse de transmission.

5.2.7.3	Alias de plusieurs receveurs
Un "alias" avec plusieurs adresses de receveur peut être traitée d’une des façons suivantes :
(a)	Tout paramètre ENVID, NOTIFY, RET, ou ORCPT N’EST PAS propagé lors du relais du message à l’une des adresses de transmission. Si le paramètre NOTIFY pour l’alias contenait le mot clé SUCCES, le MTA produit une DSN "relayé". (En effet, le MTA traite le message comme si il était relayé dans un environnement qui ne prend pas en charge les DSN.)
(b)	Tout paramètre ENVID, NOTIFY, RET, ou ORCPT (ou les demandes équivalentes si le message vient d’une passerelle) est propagé à EXACTEMENT une des adresses de transmission. Aucune DSN n’est produite. (Ceci est approprié lorsque un alias est utilisé pour transmettre un message à un programme de "vacances" auto répondeur en plus de la boîte aux lettres locale.)
(c)	Tout paramètre ENVID, RET, ou ORCPT est propagé à toutes les adresses de transmission associées à cet alias. Le paramètre NOTIFY est propagé aux adresses de transmission, excepté que tout mot clé SUCCES est retiré. Si le paramètre NOTIFY original pour l’alias contenait le mot clé SUCCES, une DSN "expansée" est produite pour l’alias. Si le paramètre NOTIFY pour l’alias ne contenait pas le mot clé SUCCES, aucune DSN n’est produite pour l’alias.

5.2.7.4	Adresses de transmission confidentielles
Si on désire conserver la confidentialité de l’adresse de transmission d’un receveur, la transmission peut être traitée comme si c’était une liste de diffusion. Une DSN sera produite, si c’est approprié, à la "livraison" à l’adresse du receveur spécifiée par l’envoyeur. Lorsque le message est transmis, il va avoir une nouvelle adresse de retour d’enveloppe. Aucune des DSN qui résultent de l’échec de livraison du message transmis ne sera retournée à l’envoyeur d’origine du message et donc n’exposera pas l’adresse de transmission du receveur.

5.2.8	DSN qui décrivent la livraison à plusieurs receveurs
Une seule DSN peut décrire les tentatives de livraison d’un message à plusieurs receveurs de ce message. Si une DSN est produite pour certains receveurs dans une transaction SMTP et non pour d’autres conformément aux règles exposées plus haut, la DSN NE DEVRAIT PAS contenir d’informations pour les receveurs pour lesquels les DSN n’auraient par ailleurs pas été produites.

5.3	Traitement des messages provenant d’autres sources

Pour les messages dont l’origine est un usager "local" (quoi que cela veuille dire) les spécifications sous lesquelles les DSN devraient être générées peuvent être communiquées au MTA via tout protocole sur lequel on s’est mis d’accord entre le composeur de messagerie de l’envoyeur (l’agent d’utilisateur) et le MTA. Le MTA local peut alors soit relayer le message, soit produire les notifications d’état de livraison appropriées. Cependant, si de telles demandes sont transmises au sein du message lui-même (par exemple dans les en-têtes de message) les demandes DOIVENT être retirées du message avant sa transmission via SMTP.

Pour les messages passés de sources non SMTP et relayés ensuite par SMTP, la passerelle DEVRAIT, en utilisant les extensions SMTP décrites ici, tenter de fournir les conditions de rapport de livraison attendues par l’environnement de messagerie source. Si c’est approprié, toute les DSN retournées à l’environnement de source DEVRAIENT être traduites dans le format attendu dans cet environnement.

5.4	Limites de mise en œuvre

Un MTA conforme DOIT accepter les paramètres ESMTP d’au moins les tailles suivantes :
(a)	 paramètre ENVID : 100 caractères.
(b)	 paramètre NOTIFY : 28 caractères.
(c)	 paramètre ORCPT : 500 caractères.
(d)	 paramètre RET : 8 caractères.

Les tailles maximum pour les paramètres ENVID et ORCPT sont destinées à être adéquates pour la transmission des identifiants d’enveloppe "étrangers" et des adresses de receveur originales. Cependant, les agents d’utilisateur qui utilisent SMTP comme protocole de soumission de message NE DEVRAIENT PAS générer des paramètres ENVID de plus de 38 caractères.

Un MTA conforme DOIT être capable d’accepter les lignes de commande SMTP qui font au moins 1036 caractères (530 caractères pour les paramètres ORCPT et NOTIFY de la commande RCPT, en plus des 512 caractères requis par la [RFC0821]). Si d’autres extensions SMTP sont prises en charge par le MTA, il DOIT être capable d’accepter une ligne de commande assez grande pour chaque commande SMTP et toute combinaison de paramètres ESMTP qui peut être utilisée avec cette commande.

6.	Format des notifications de livraison

Le format des notifications d’état de livraison est défini dans la [RFC3464], qui utilise le cadre défini dans la [RFC3462]. Les notifications d’état de livraison sont à retourner à l’envoyeur du message d’origine selon les modalités suivante.

6.1	Enveloppe SMTP à utiliser avec les notifications d’état de livraison

L’adresse de l’envoyeur de la DSN (dans la commande MAIL SMTP) DOIT être un chemin inverse nul ("<>") comme exigé par le paragraphe 5.3.3 de la [RFC1123]. L’adresse de receveur de la DSN (dans la commande RCPT) est copiée de la commande MAIL qui accompagnait le message pour lequel la DSN est produite. Lors de la transmission d’une DSN via SMTP, le paramètre RET NE DOIT PAS être utilisé. Le paramètre NOTIFY PEUT être utilisé, mais sa valeur DOIT être NEVER. Le paramètre ENVID (avec la génération d’un nouvel identifiant d’enveloppe) et/ou le paramètre ORCPT PEUT être utilisé.

6.2	Contenu de la DSN

Une DSN est transmise comme un message MIME avec un type de contenu de niveau supérieur de multiparties/rapport (comme défini dans la [RFC3464]).

Le type de contenu multiparties/rapport peut être utilisé pour une des diverses sortes de rapports générés par le système de messagerie. Lorsque multiparties/rapport est utilisé pour convoyer une DSN, le paramètre type de rapport du type de contenu multiparties/rapport est "état de livraison".

Comme décrit dans la [RFC3462], le premier composant d’un type de contenu multiparties/rapport est une explication lisible par l’homme du rapport. Pour une DSN, le second composant du multiparties/rapport est du type de contenu message/état-de-livraison (défini dans la [RFC3464]). Le troisième composant du multiparties/rapport consiste en le message d’origine ou en certaines de ses portions. Lorsque la valeur du paramètre RET est FULL, le message entier DEVRAIT être retourné pour toute DSN qui porte une notification d’échec de livraison. (Cependant, si la longueur du message est supérieure à une certaine longueur spécifiée par la mise en œuvre, le MTA PEUT retourner seulement les en-têtes même si le paramètre RET spécifiait FULL.) Si une DSN ne contient pas de notification d’échec de livraison, le MTA DEVRAIT retourner seulement les en-têtes.

Le troisième composant doit avoir une étiquette de type de contenu appropriée. Les problèmes qui concernent le choix du type de contenu sont exposés dans la [RFC3462].

6.3	Champs de l’état de livraison de message

Le type de contenu message/état-de-livraison définit un certain nombre de champs, avec des spécifications générales pour leur contenu. Les exigences suivantes pour toutes les DSN générées en réponse à un message reçu au moyen du protocole SMTP par un serveur SMTP conforme, s’ajoutent aux exigences définies dans la [RFC3464] pour le type de contenu message/état-de-livraison.

Lorsque il génère une DSN pour un message qui a été reçu via le protocole SMTP, un MTA conforme va générer les champs suivants de la partie de corps du message/état-de-livraison :

(a)	Si un paramètre ENVID était présent sur la commande MAIL, un champ Identifiant d’enveloppe d’origine DOIT être fourni, et la valeur associée au paramètre ENVID doit apparaître dans ce champ. Si le message a été reçu via SMTP sans paramètre ENVID, le champ Identifiant d’enveloppe d’origine NE DOIT PAS être fourni.

Comme le paramètre ENVID est codé comme xtext, mais que l’en-tête Identifiant d’enveloppe d’origine n’est PAS codé comme xtext, le MTA doit décoder le codage xtext lorsque il copie la valeur de ENVID dans le champ Identifiant d’enveloppe d’origine.

(b)	Le champ MTA-rapporteur DOIT être rempli. Si le MTA rapporteur peut déterminer son nom de domaine Internet pleinement qualifié, le sous-champ Type de nom de MTA DOIT être "dns", et le champ DOIT contenir le nom de domaine pleinement qualifié du MTA rapporteur. Si le nom de domaine Internet pleinement qualifié du MTA rapporteur n’est pas connu (par exemple, pour un serveur SMTP qui n’est pas directement connecté à l’Internet) le champ MTA rapporteur peut contenir toute chaîne d’identification du MTA, Cependant, dans ce cas, le sous champ Type de nom de MTA NE DOIT PAS être "dns". Une valeur de sous-champ Type de nom de MTA de "nom-d’hôte-local-x" est suggérée.

(c)	Les autres champs par message comme défini dans la [RFC3464] PEUVENT être fournis comme approprié.

(d)	Si le paramètre ORCPT a été fourni pour ce receveur, le champ Receveur d’origine DOIT être rempli, avec la valeur tirée du paramètre ORCPT. Si aucun paramètre ORCPT n’a été fourni pour ce receveur, le champ Receveur d’origine NE DOIT PAS apparaître.

(e)	Le champ Receveur-final DOIT être fourni. Il DOIT contenir l’adresse du receveur à partir de l’enveloppe du message. Si le message a été reçu via SMTP, le type d’adresse sera "rfc822".

(f)	Le champ Action DOIT être fourni.

(g)	Le champ État DOIT être fourni, en utilisant un code d’état de la [RFC3463]. Si il n’y a pas de code spécifique qui décrive convenablement un échec de livraison, 4.0.0 (échec temporaire) ou 5.0.0 (échec permanent) DOIT être utilisé.

(h)	Pour les DSN résultant de tentatives de relayer un message à un ou plusieurs receveurs via SMTP, le champ MTA distant DOIT être rempli pour chacun de ces receveurs. Les sous-champs Type de nom de MTA de ces champs MTA distant seront "dns".

(i)	Pour les DSN qui résultent de tentatives de relayer un message à un ou plusieurs receveurs via SMTP, le champ Code de diagnostic DOIT être fourni pour chacun de ces receveurs. Le sous-champ Type de diagnostic sera "smtp". Voir au paragraphe 9.2 la description du code de diagnostic "smtp".

(j)	Pour les DSN qui résultent de tentatives de relayer un message à un ou plusieurs receveurs via SMTP, un champ d’extension Receveur SMTP distant PEUT être fourni pour chaque receveur, contenant l’adresse de ce receveur qui a été présentée au serveur SMTP distant.

(k)	Les autres champs par receveur définis dans la [RFC3464] PEUVENT apparaître, lorsque c’est approprié.

7.	Remerciements

Les auteurs souhaitent remercier Eric Allman, Harald Alvestrand, Jim Conklin, Bryan Costales, Peter Cowen, Dave Crocker, Roger Fajman, Ned Freed, Marko Kaittola, Steve Kille, John Klensin, Anastasios Kotsikonas, John Gardiner Myers, Julian Onions, Jacob Palme, Marshall Rose, Greg Vaudreuil, et Klaus Weide de leurs suggestions pour l’amélioration de ce document.

8.	Considérations pour la sécurité

L’extension SMTP décrite dans le présent document ne change pas la nature fondamentale du service SMTP et donc ne crée en et par elle-même aucun nouveau risque pour la sécurité. Elle ajoute cependant nécessairement de la complexité aux mises en œuvre, et avec l’ajout de complexité vient un risque accru d’erreurs de mise en œuvre.

Les mécanismes ad hoc précédents de notification de livraison produisaient parfois une tempête de réceptions due à des interactions non anticipées avec un logiciel d’expansion de liste de diffusion. Dans la présente spécification, la notification de la réussite de la livraison est conçue avec soin pour que, si elle est correctement mise en œuvre, elle ne puisse pas interagir de cette façon avec un exploseur de liste.

La section des considérations pour la sécurité de la [RFC3462] décrit les questions de sécurité associées avec les objets multiparties/rapport en général et la section des considérations pour la sécurité de la [RFC3464] décrit en particulier les questions de sécurité avec les DSN.

9.	Appendice	Définitions des noms de type

Les noms de type suivants sont définis pour être utilisés dans les champs de DSN générées par les MTA conformes fondés sur SMTP.

9.1	Type d’adresse "rfc822"

Le type d’adresse "rfc822" est à utiliser lors de rapports d’adresse Internet de messagerie électronique dans les champs Receveur-d’origine et Receveur-final de DSN.

(a)	Nom du type d’adresse : rfc822

(b)	Syntaxe des adresses de messagerie électronique :

Les adresses  de boîte aux lettres RFC822 sont généralement supposées être de la forme
[chemin] addr-spec

où "chemin" et "addr-spec" sont définis dans la [RFC0822], et les portions "domaine" de "chemin" et de "addr-spec" sont tous deux des noms de domaine pleinement qualifiés qui sont enregistrés dans le DNS. Cependant, un MTA NE DOIT PAS modifier une adresse obtenue de l’enveloppe du message pour la forcer à se conformer aux règles de syntaxe.

(c)	Si les adresses de ce type ne sont pas composées entièrement de caractères graphiques du répertoire US-ASCII, une spécification de la façon dont ils sont à coder comme caractères graphiques US-ASCII dans un champ Receveur d’origine ou Receveur final de DSN.

Les adresses RFC822 consistent entièrement de caractères graphiques du répertoire US-ASCII, de sorte qu’aucune traduction n’est nécessaire.

9.2	Type de diagnostic "smtp"

Le type de diagnostic "smtp" est à utiliser lors du rapport des codes de réponse SMTP dans les champs Code de diagnostic de DSN.

(a)	Nom du type de diagnostic : SMTP

(b)	Une description de la syntaxe à utiliser pour exprimer les codes de diagnostic de ce type comme caractères graphiques du répertoire US-ASCII.

Un code de diagnostic SMTP est de la forme
*( 3*CHIFFRE "-" *texte ) 3*CHIFFRE ESPACE *texte

Pour une réponse SMTP d’une seule ligne à une commande SMTP, le code de diagnostic DEVRAIT être une transcription exacte de la réponse. Pour les réponses SMTP multi lignes, il est nécessaire d’insérer une ESPACE avant chaque ligne après la première. Par exemple, une réponse SMTP de :

550 – boîte aux lettres indisponible
550 – l’usager est parti sans laisser d’adresse de transmission

pourrait apparaître comme suit dans un champ Code-de-diagnostic de DSN :

Code-de-diagnostic : smtp ; 550 - Boîte aux lettres indisponible 550 l’usager est parti sans laisser d’adresse de transmission

(c)	Une liste de codes de diagnostic valides de ce type et la signification de chaque code.

Les codes de réponse SMTP sont actuellement définis dans la [RFC0821] et la [RFC1123]. Des codes supplémentaires peuvent être définis par d’autres RFC.

9.3	Type de nom de MTA "dns"

Le type de nom de MTA "dns" devrait être utilisé dans le champ MTA-rapporteur. Un nom de MTA de type "dns" est un nom de domaine pleinement qualifié. Le nom doit être enregistré dans le DNS, et l’adresse MaitreDePoste@{nom-de-mta} doit être valide.

(a)	nom de type-de-nom-de-MTA : dns

(b)  Une description de la syntaxe des noms de MTA de ce type, utilisant le BNF, des expressions régulières, l’ASN.1, ou d’autres langages non ambigus.

Les noms de MTA du type "dns" DEVRAIENT être des noms de domaine Internet valides. Si de tels noms de domaine ne sont pas disponibles, un domaine-littéral contenant l’adresse de protocole internet est acceptable. De tels noms de domaine se conforment généralement à la syntaxe suivante :

domaine = domaine-réel / domaine-littéral

domaine-réel = sous-domaine *("." sous-domaine)

sous-domaine = atome

domaine-littéral = "[" 1*3CHIFFRE 3("." 1*3CHIFFRE) "]"

où "atome" et "CHIFFRE" sont définis dans la [RFC0822].

(c)	Si les noms de MTA de ce type ne consistent pas entièrement en caractères graphiques du répertoire US-ASCII, une spécification dont le nom d’un MTA de ce type devrait être exprimé comme séquence de caractères graphique US-ASCII.

Les noms de MTA de type "dns" consistent entièrement en caractères graphiques US-ASCII, de sorte qu’aucune traduction n’est nécessaire.

10.	Appendice	Exemple

Cet exemple retrace le flux d’un seul message adressé à plusieurs receveurs. Le message est envoyé par Alice@Example.ORG à Bob@Example.COM, Carol@Ivory.EDU, Dana@Ivory.EDU, Eric@Bombs.AF.MIL, Fred@Bombs.AF.MIL, et George@Tax-ME.GOV, avec diverses options par receveur. Le message est bien délivré à Bob, Dana (via une passerelle), à Eric, et à Fred. La livraison échoue pour Carol et George.

Note: Les règles de formatage pour les RFC exigent qu’aucune ligne ne fasse plus de 72 caractères. Donc, dans les exemples qui suivent, certaines commandes SMTP qui font plus de 72 caractères sont imprimées sur deux lignes, dont la première se termine par "\". Dans une transaction SMTP réelle, une telle commande serait envoyée sur une seule ligne (c’est-à-dire, sans CRLF incorporés) et sans le caractère "\" qui apparaît dans ces exemples.

10.1	Soumission

L’agent d’utilisateur d’Alice envoie le message au serveur SMTP à Example.ORG. Noter que bien que cet exemple utilise SMTP comme protocole de soumission de messagerie, d’autres protocoles pourraient aussi être utilisés.

   <<< 220 Example.ORG serveur SMTP présent
   >>> EHLO Example.ORG
   <<< 250-Example.ORG
   <<< 250-DSN
   <<< 250-EXPN
   <<< 250 SIZE
   >>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159
   <<< 250 <Alice@Example.ORG> envoyeur ok
   >>> RCPT TO:<Bob@Example.COM> NOTIFY=SUCCESS \
       ORCPT=rfc822;Bob@Example.COM
   <<< 250 <Bob@Example.COM> receveur ok
   >>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \
       ORCPT=rfc822;Carol@Ivory.EDU
   <<< 250 <Carol@Ivory.EDU> receveur ok
   >>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \
       ORCPT=rfc822;Dana@Ivory.EDU
   <<< 250 <Dana@Ivory.EDU> receveur ok
   >>> RCPT TO:<Eric@Bombs.AF.MIL> NOTIFY=FAILURE \
       ORCPT=rfc822;Eric@Bombs.AF.MIL
   <<< 250 <Eric@Bombs.AF.MIL> receveur ok
   >>> RCPT TO:<Fred@Bombs.AF.MIL> NOTIFY=NEVER
   <<< 250 <Fred@Bombs.AF.MIL> receveur ok
   >>> RCPT TO:<George@Tax-ME.GOV> NOTIFY=FAILURE \
        ORCPT=rfc822;George@Tax-ME.GOV
   <<< 250 <George@Tax-ME.GOV> receveur ok
   >>> DATA
   <<< 354 okay, message envoyé
   >>> (le message vient ici)
   >>> .
   <<< 250 message accepté
   >>> QUIT
   <<< 221 au revoir

10.2	Relais à Example.COM

Le SMTP à Example.ORG relaye alors le message à Example.COM. (Pour les besoins de cet exemple, mail.Example.COM est le principal échangeur de messagerie pour Example.COM).

   <<< 220 mail.Example.COM dit bonjour
   >>> EHLO Example.ORG
   <<< 250-mail.Example.COM
   <<< 250 DSN
   >>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159
   <<< 250 envoyeur okay
   >>> RCPT TO:<Bob@Example.COM> NOTIFY=SUCCESS \
       ORCPT=rfc822;Bob@Example.COM
   <<< 250 receveur okay
   >>> DATA
   <<< 354 message envoyé
   >>> (le message vient ici)
   >>> .
   <<< 250 message reçu
   >>> QUIT
   <<< 221 bcnu

10.3	Relais à Ivory.EDU

Le SMTP à Example.ORG relaye le message à Ivory.EDU, qui (cela se trouve comme cela) est une passerelle vers un système de messagerie fondé sur un LAN qui accepte la messagerie SMTP et prend en charge l’extension DSN.

   <<< 220 Ivory.EDU ici la passerelle pour FooMail(tm)
   >>> EHLO Example.ORG
   <<< 250-Ivory.EDU
   <<< 250 DSN
   >>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159
   <<< 250 ok
   >>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \
       ORCPT=rfc822;Carol@Ivory.EDU
   <<< 550 erreur – pas de tel receveur
   >>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \
       ORCPT=rfc822;Dana@Ivory.EDU
   <<< 250 receveur ok
   >>> DATA
   <<< 354 message envoyé, se termine par '.'
   >>> (le message vient ici)
   >>> .
   <<< 250 message reçu
   >>> QUIT
   <<< 221 au revoir

Noter que comme Ivory.EDU a refusé d’accepter le message pour Carol@Ivory.EDU, et que l’envoyeur a spécifié NOTIFY=FAILURE, l’envoyeur-SMTP (dans ce cas, Example.ORG) doit générer une DSN.

10.4	Relais à Bombs.AF.MIL

Le SMTP à Example.ORG relaye le message à Bombs.AF.MIL, qui ne prend pas en charge l’extension SMTP. Parce que l’envoyeur a spécifié NOTIFY=NEVER pour le receveur Fred@Bombs.AF.MIL, le SMTP à Example.ORG choisit d’envoyer le message pour ce receveur dans une transaction distincte avec un chemin inverse de <>.

   <<< 220-Bombs.AF.MIL rapport d’activité.
   <<< 220 La messagerie électronique ne doit être utilisée que pour des affaires officielles.
   >>> EHLO Example.ORG
   <<< 502 commande non mise en œuvre
   >>> RSET
   <<< 250 redémarrage
   >>> HELO Example.ORG
   <<< 250 Bombs.AF.MIL
   >>> MAIL FROM:<Alice@Example.ORG>
   <<< 250 ok
   >>> RCPT TO:<Eric@Bombs.AF.MIL>
   <<< 250 ok
   >>> DATA
   <<< 354 message envoyé
   >>> (le message vient ici)
   >>> .
   <<< 250 message accepté
   >>> MAIL FROM:<>
   <<< 250 ok
   >>> RCPT TO:<Fred@Bombs.AF.MIL>
   <<< 250 ok
   >>> DATA
   <<< 354 message envoyé
   >>> (le message vient ici)
   >>> .
   <<< 250 message accepté
   >>> QUIT
   <<< 221 Bombs.AF.MIL ferme la connexion

10.5	Transmission de George@Tax-ME.GOV à Sam@Boondoggle.GOV

Le SMTP à Example.ORG relaye le message à Tax-ME.GOV. (Cette étape n’est pas montrée.) Le MTA Tax-ME.GOV transmet alors le message à Sam@Boondoggle.GOV (c’est de qui figure ci-dessous). Tax-ME.GOV et Example.ORG prennent tous deux en charge l’extension DSN de SMTP. Noter que RET, ENVID, et ORCPT conservent tous leurs valeurs d’origine.

   <<< 220 BoonDoggle.GOV dit bonjour
   >>> EHLO Example.ORG
   <<< 250-mail.Example.COM
   <<< 250 DSN
   >>> MAIL FROM:<Alice@Example.ORG> RET=HDRS ENVID=QQ314159
   <<< 250 envoyeur okay
   >>> RCPT TO:<Sam@Boondoggle.GOV> NOTIFY=SUCCES \
       ORCPT=rfc822;George@Tax-ME.GOV
   <<< 250 receveur okay
   >>> DATA
   <<< 354 message envoyé
   >>> (le message vient ici)
   >>> .
   <<< 250 message reçu
   >>> QUIT
   <<< 221 bcnu

10.6	DSN "livrée" à Bob@Example.COM

Le MTA mail.Example.COM réussit à livrer le message à Bob@Example.COM. Comme l’envoyeur a spécifié NOTIFY=SUCCESS, mail.Example.COM produit la DSN suivante, et l’envoie à Alice@Example.ORG.

   To: Alice@Example.ORG
   From: postmaster@mail.Example.COM
   Subject: Notification de livraison (réussie) pour Bob@Example.COM
   Type de contenu : multiparties/rapport; type de rapport =état de livraison ; limite=abcde
   MIME-Version: 1.0

   --abcde
   type de contenu : texte/clair ; charset=us-ascii

   Votre message (id QQ314159) a bien été livré à Bob@Example.COM.

   --abcde
   type de contenu : message/état de livraison

   MTA rapporteur : dns; mail.Example.COM
   ID d’enveloppe d’origine : QQ314159

   Receveur d’origine : rfc822;Bob@Example.COM
   Receveur final : rfc822;Bob@Example.COM
   Action : livré
   Status: 2.0.0

   --abcde
   type de contenu : message/rfc822

   (les en-têtes du message retourné viennent ici)

   --abcde--

10.7	Éched de DSN pour Carol@Ivory.EDU

Parce que la livraison à Carol a échoué et que l’envoyeur a spécifié NOTIFY=FAILURE pour Carol@Ivory.EDU, le MTA Example.ORG (le client SMTP auquel l’échec a été rapporté via SMTP) produit la DSN suivante.

   To: Alice@Example.ORG
   From: postmaster@Example.ORG
   Subject: Notification de livraison (échec) pour Carol@Ivory.EDU
   Content-Type: multiparties/rapport; type de rapport = état de livraison; limite=bcdef
   MIME-Version: 1.0

      --bcdef
     type de contenu : texte/clair ; charset=us-ascii

      Votre message (id QQ314159) n’a pas pu être livré à Carol@Ivory.EDU.

Une transcription de la session suit :

   (tout en parlant à Ivory.EDU)
   >>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE
   <<< 550 erreur - ce receveur n’existe pas

   --bcdef
   type de contenu : message/état de livraison

   MTA rapporteur : dns; Example.ORG
   ID d’enveloppe d’origine : QQ314159

   Receveur d’origine : rfc822;Carol@Ivory.EDU
   Receveur final : rfc822;Carol@Ivory.EDU
   Receveur SMTP distant : Carol@Ivory.EDU
   Code de diagnostic : smtp; 550 error - no such receveur
   Action : échec
   Status : 5.0.0

   --bcdef
     type de contenu : message/rfc822

   (les en-têtes du message retourné viennent ici)

   --bcdef--

10.8	DSN relayée pour Dana@Ivory.EDU

Bien que la passerelle de messagerie Ivory.EDU prenne en charge l’extension DSN de SMTP, le système de messagerie de LAN rattaché à son autre côté ne génère pas de confirmation positive de livraison. Donc Ivory.EDU produit une DSN "relayé" :

   To: Alice@Example.ORG
   From: postmaster@Ivory.EDU
   Subject: message relayé pour Dana@Ivory.EDU
   type de contenu : multiparties/rapport ; type de rapport = état de livraison ; limite = cdefg
   MIME-Version : 1.0

   --cdefg
  type de contenu : texte/clair; charset=us-ascii

Votre message (adressé à Dana@Ivory.EDU) a été relayé avec succès à :
      ymail!Dana
par la passerelle FooMail à Ivory.EDU.
Malheureusement, le système de messagerie distant n’assure pas la confirmation de la livraison réelle. Sauf en cas d’échec de la livraison à ymail!Dana, ceci sera la seule notification d’état de livraison envoyée.

   --cdefg
  type de contenu : message/delivery-status

   MTA rapporteur : dns; Ivory.EDU
   ID d’enveloppe d’origine : QQ314159

   Receveur d’origine : rfc822;Dana@Ivory.EDU
   Receveur final : rfc822;Dana@Ivory.EDU
   Action : relayé
   Status : 2.0.0

   --cdefg
  type de contenu : message/rfc822

   (les en-têtes du message retourné viennent ici)

   --cdefg--

10.9	Échec de notification pour Sam@Boondoggle.GOV

Le message adressé à l’origine à George@Tax-ME.GOV a été transmis à Sam@Boondoggle.GOV, mais le MTA pour Boondoggle.GOV a été incapable de délivrer le message à cause d’un manque d’espace disque dans la boîte aux lettres de Sam. Après avoir essayé pendant plusieurs jours, Boondoggle.GOV a retourné la DSN suivante :

   To: Alice@Example.ORG
   From: Postmaster@Boondoggle.GOV
   Subject: Échec de livraison pour Sam@Boondoggle.GOV
   type de contenu : multiparties/rapport ; type de rapport = état de livraison ; limite =defgh
   MIME-Version: 1.0

   --defgh
Votre message, adressé à l’origine à George@Tax-ME.GOV, et transmis de là à Sam@Boondoggle.GOV n’a pas pu être délivré, pour la raison suivante :
   erreur d’écriture à la boîte aux lettres, quota de disque excédé

   --defgh
  type de contenu : message/état de livraison

   MTA rapporteur : Boondoggle.GOV
   ID d’enveloppe d’origine : QQ314159

   Receveur d’origine : rfc822;George@Tax-ME.GOV
   Receveur final : rfc822;Sam@Boondoggle.GOV
   Action : échec
   Status : 4.2.2 (quota de disque excédé)

   --defgh
   type de contenu : message/rfc822

   (les en-têtes du message retourné viennent ici)

   --defgh--

11.	Appendice	Changements depuis la RFC1891

-	Mise à jour de l’adresse de l’auteur !
-	Dans les exemples, changement de Pure-Heart.ORG et de Big-Bucks.COM en Example.ORG et Example.COM, respectivement. Depuis la publication de la RFC1891, les deux domaines ont été enregistrés.
-	Précision que les paramètres ENVID et ORCPT doivent consister entièrement en caractères US-ASCII avant d’être codés comme xtext.
-	Une section Considérations pour la sécurité a été ajoutée.

12.	Références
12.1	Références normatives

[ANSI]	ANSI X3.4-1986 "Coded Character Set - 7-Bit American Standard Code for Information Interchange".
[RFC0821]	J. Postel, "Protocole simple de transfert de messagerie", STD 10, août 1982.

[RFC0822]	D. Crocker, "Norme pour le format des messages de texte de l'ARPA-Internet", STD 11, août 1982. (Obsolète, remplacée par la RFC5322)

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC3462]	G. Vaudreuil, "Type de contenu Multipart/Report pour les rapports des messages administratifs du système de messagerie", janvier 2003. (Remplacée par RFC6522, STD73)

[RFC3463]	G. Vaudreuil, "Codes d'état améliorés du système de messagerie", janvier 2003. (MàJ par RFC3886, RFC4468, RFC4865, RFC4954, RFC5248) (D.S.)

[RFC3464]	K. Moore, G. Vaudreuil, "Format extensible de message pour les notifications d'état de livraison", janvier 2003. (MàJ par RFC4865, RFC5337) (D.S.)

12.2	Références pour information

[RFC1123]	R. Braden, éditeur, "Exigences pour les hôtes Internet – Application et prise en charge", STD 3, octobre 1989.

[RFC1211]	A. Westine et J. Postel, "Problèmes de la maintenance de grosses listes de diffusion", mars 1991. (Info)

[RFC1939]	J. Myers, M. Rose, "Protocole Post Office - version 3", mai 1996. (MàJ par RFC1957, RFC2449) (STD0053)

[RFC2060]	M. Crispin, "Protocole d'accès au message Internet - version 4rev1", décembre 1996. (Remplace RFC1730) (Obsolète, voir RFC3501) (P.S.)

13.	Adresse de l’auteur

Keith Moore
University of Tennessee
1122 Volunteer Blvd, Suite 203
Knoxville, TN 37996-3450
USA

mél : moore@cs.utk.edu 

14.	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2003). Tous droits réservés.

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus de normes pour Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

Remerciement
Le financement de la fonction d’édition des RFC est actuellement fourni par la Internet Society.