Groupe de travail Réseau

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.

Le présent mémoire définit un type de contenu d’extensions de messagerie Internet multi objets (MIME, Multipurpose Internet Mail Extensions) qui peut être utilisé par un agent de transfert de message (MTA, message transfer agent) ou une passerelle de messagerie électronique pour faire rapport des résultats d’une tentative de livraison d’un message à un ou plusieurs receveurs. Ce type de contenu est destiné à constituer un moyen de remplacement traité par la machine des divers types de notifications d’état de livraison actuellement utilisés dans la messagerie électronique Internet.

Comme de nombreux messages sont envoyés entre l’Internet et d’autres systèmes de messagerie (comme X.400 ou ce qu’on appelle des systèmes fondés sur des "réseau de zone locale") le protocole de notification d’état de livraison (DSN, Delivery Status Notification) est conçu pour être utile dans un environnement de messagerie multi protocoles. À cette fin, le protocole décrit dans le présent mémoire fournit le transport des adresses "étrangères" et des codes d’erreur, en plus de ceux utilisés normalement dans la messagerie Internet. Des attributs supplémentaires peuvent aussi être définis pour prendre en charge le "tunnelage" de notifications étrangères à travers la messagerie Internet.

Table des matières

1. Introduction 2

1.1 Objet 2

1.2 Exigences 2

1.3 Terminologie 3

2. Format d’une notification d’état de livraison 4

2.1 Type de contenu État de livraison de message 5

2.2 Champs DSN par message 6

2.3 Champs DNS par receveur 8

2.4 Champs d’extension 12

3. Exigences de conformité et d’utilisation 12

4. Considérations pour la sécurité 13

4.1 Falsification 13

4.2 Confidentialité 13

4.3 Non répudiation 14

5. Références normatives 14

6. Remerciements 15

Appendice A Récapitulation de la grammaire 15

Appendice B Lignes directrices pour les passerelles DSN 16

Appendice C Lignes directrices pour l’utilisation de DSN par des exploseurs de liste de diffusion 17

Appendice D Formulaires d’enregistrement IANA des types DSN 18

Appendice E Exemples 18

Appendice F Changements par rapport à la RFC1894 21

Adresse des auteurs 22

Déclaration complète de droits de reproduction 22

Le présent mémoire définit un type de contenu d’extensions multi objets de messagerie Internet (MIME, Multipurpose Internet Mail Extension) [RFC2045] pour les notifications d’état de livraison (DSN, Delivery Status Notification). Une DSN peut être utilisée pour notifier à l’envoyeur d’un message une des conditions suivantes : échec de livraison, livraison retardée, livraison réussie, ou transfert d’un message dans un environnement qui peut ne pas prendre en charge les DSN. Le type de contenu "État de livraison de message" défini ici est destiné à être utilisé dans le cadre du type de contenu "multi partie/rapport" défini dans la [RFC3462].

Le présent mémoire ne définit que le format des notifications. Une extension au protocole simple de transfert de message (SMTP, Simple Message Transfer Protocol) [RFC0821] pour la prise en charge complète de telles notifications fait l’objet d’un mémoire distinct [RFC3461].

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].

Les DSN définies dans le présent mémoire sont supposées servir à plusieurs fins :

(a) Informer les observateurs humains de l’état du processus de livraison du message, ainsi que des raisons de tout problème de livraison ou défaillance franche, d’une manière qui soit largement indépendante du langage et des supports humains ;

(b) permettre aux agents d’utilisateur de messagerie de garder trace de l’état de livraison des messages envoyés, en associant les DSN retournées aux transmissions de message antérieures ;

(c) permettre que les exploseurs de liste de diffusion tiennent automatiquement leurs listes d’abonnés lorsque les tentatives de livraison échouent de façon répétée ;

(d) transporter les notifications de livraison et de non livraison résultant de tentatives de livraison de messages à des systèmes de messagerie "étrangers" via une passerelle ;

(e) permettre que des notifications "étrangères" soient tunnelées à travers un système de message à capacité MIME et de revenir dans le système de messagerie d’origine qui a produit la notification originale, ou même à un troisième système de messagerie ;

(f) permettre des indications indépendantes du langage et du support, mais raisonnablement précises des raisons de l’échec de la livraison d’un message ;

(g) fournir des informations suffisantes aux tenanciers distants de MTA (via des "tickets de problème") afin qu’ils puissent comprendre la nature des erreurs rapportées. Ce dispositif est utilisé dans le cas d’échec de livraison d’un message dû au dysfonctionnement d’un MTA distant lorsque l’envoyeur veut rapporter le problème à l’administrateur du MTA distant.

Ces objectifs font peser les contraintes suivantes sur le protocole de notification :

(a) Il doit être lisible par l’homme aussi bien qu’être analysable par la machine ;

(b) il doit fournir assez d’informations pour permettre à l’envoyeur du message (ou à l’agent d’utilisateur) d’associer sans ambiguïté une DSN au message qui a été envoyé et à l’adresse du receveur d’origine pour laquelle la DSN est produite (si une telle information est disponible) même si le message a été transmis à l’adresse d’un autre receveur ;

(c) il doit être capable de préserver la raison du succès ou de l’échec d’une tentative de livraison dans un système de messagerie distant, en utilisant le "langage" (adresses de boîtes aux lettres et codes d’état) de ce système distant ;

(d) il doit aussi être capable de décrire la raison du succès ou de l’échec d’une tentative de livraison, indépendamment de tout langage humain particulier ou du "langage" de tout système de messagerie particulier ;

(e) il doit préserver assez d’informations pour permettre au tenancier d’un MTA distant de comprendre (et si possible, reproduire) les conditions qui ont causé l’échec d’une livraison à ce MTA ;

(f) pour toutes les notifications produites par des systèmes de messagerie étrangers, qui sont traduits par une passerelle de messagerie au format DSN, le DSN doit préserver le "type" des adresses étrangères et des codes d’erreur, afin qu’ils puissent être correctement interprétés par les passerelles.

Une DSN contient un ensemble de champs par message qui identifient le message et la transaction durant laquelle le message a été soumis, ainsi que d’autres champs qui s’appliquent à toutes les tentatives de livraison décrites par la DSN. La DSN comporte aussi un ensemble de champs par receveur pour porter le résultat de la tentative de livraison du message à chacun des receveurs.

Un message peut être transmis à travers plusieurs agents de transfert de message (MTA, message transfer agent) sur son chemin vers un receveur. Pour diverses raisons, les adresses de receveur peuvent être réécrites durant ce processus, de sorte que chaque MTA peut éventuellement voir une adresse de receveur différente. Selon l’objet pour lequel est utilisé une DSN, différents formats d’une adresse de receveur particulière seront nécessaires.

Plusieurs champs de DSN sont définis selon les termes de la vue d’un MTA particulier dans la transmission. Les noms suivants sont alloués aux MTA :

Le MTA d’origine est celui auquel est soumis le message pour livraison, par l’envoyeur du message.

Pour toute DSN, le MTA rapporteur est celui qui fait rapport des résultats de la tentative de livraison décrite dans la DSN.

Si la tentative de livraison décrite est survenue dans un système de messagerie "étranger" (non Internet) et si la DSN a été produite par traduction de l’annonce étrangère au format de DSN, le MTA rapporteur va de plus identifier le MTA "étranger" où la tentative de livraison est intervenue.

Le MTA de provenance est celui d’où le MTA rapporteur a reçu le message, et a accepté la responsabilité de livraison du message.

Si un MTA détermine qu’il doit relayer un message à un ou plusieurs receveurs, mais si le message ne peut pas être transféré à son MTA de "prochain bond", ou si le MTA de "prochain bond" refuse d’accepter la responsabilité de la livraison du message à un ou plusieurs de ses receveurs prévus, le MTA de relais peut avoir besoin de produire une DSN au nom des receveurs pour lesquels le message ne peut pas être livré. Dans ce cas, le MTA de relais est le MTA rapporteur, et le MTA de "prochain bond" est appelé le MTA distant.

+ Idéalement, la DSN va contenir l’adresse de chaque receveur comme elle était spécifiée à l’origine au MTA d’origine par l’envoyeur du message.

Cette version de l’adresse est nécessaire (plutôt qu’une adresse de transmission ou une version modifiée de l’adresse originale) afin que l’envoyeur puisse comparer l’adresse du receveur dans la DSN avec celle des enregistrements de l’envoyeur (par exemple, un carnet d’adresses pour un individu, la liste des abonnés pour une liste de diffusion) et prendre les mesures appropriées.

De même, la DSN pourrait contenir un "identifiant d’enveloppe" qui serait connu à la fois de l’agent d’utilisateur de l’envoyeur et du MTA d’origine au moment de la soumission du message, et qui, si elle est incluse dans la DSN, peut être utilisée par l’envoyeur pour garder trace de quels messages sont ou non à livrer.

+ Si un message était (a) transmis à une adresse différente de celle spécifiée par l’envoyeur, (b) passée par une passerelle à un système de messagerie différent de celui utilisé par l’envoyeur, ou (c) soumis à une réécriture d’adresse durant la transmission, la forme "finale" de l’adresse du receveur (par exemple, celle qui est vue par le MTA rapporteur) sera différente de l’adresse de receveur originale (spécifiée par l’envoyeur). Tout comme l’agent d’utilisateur de l’envoyeur préfère l’adresse originale du receveur, l’adresse "finale" est nécessaire lors d’un rapport de problème au maître de poste du site où a échoué la livraison du message, parce que seule l’adresse du receveur final lui permettra de reproduire les conditions qui ont causé l’échec.

+ Une DSN "échec" devrait contenir les explications les plus précises de l’échec de la livraison qui sont disponibles. Pour faciliter l’interprétation, ces informations devraient avoir un format indépendant du système de transport de messagerie qui a produit la DSN. Cependant, si un code d’erreur étranger est traduit en un format indépendant du transport, des informations peuvent être perdues. Il est donc souhaitable de fournir à la fois un code d’état indépendant du transport et un mécanisme pour faire rapport des codes spécifiques du transport. Selon les circonstances qui ont produit l’échec de livraison, le code spécifique du transport pourrait être obtenu du MTA rapporteur ou du MTA distant.

Comme des valeurs différentes sont nécessaires pour "l’adresse de receveur" et le "code d’état de livraison" selon les circonstances dans lesquelles sera utilisée une DSN, et comme le MTA qui produit la DSN ne peut pas anticiper ces circonstances, le format de DSN décrit ici peut contenir à la fois la forme originale et la forme finale d’une adresse de receveur, et une indication d’état de livraison indépendante du transport ainsi qu’une indication spécifique du transport.

Des champs d’extension peuvent aussi être ajoutés par le MTA rapporteur autant que nécessaire pour fournir des informations supplémentaires à utiliser pour un avis de problème ou pour préserver les informations pour le tunnelage de rapports de livraison étrangère à travers les DSN Internet.

Les MTA d’origine, rapporteur, et distant peuvent exister dans des environnements très différents et utiliser des protocoles de transport, des noms de MTA, des formats d’adresse, et des codes d’état de livraison très dissemblables. Les DSN ne supposent donc pas de format particulier pour les adresses de boîte aux lettres, les noms de MTA, ou les codes d’état spécifiques du transport. Les divers champs de DSN qui portent de telles quantités consistent plutôt en un sous-champ de "type" suivi par un sous-champ dont le contenu est fait de caractères de texte ordinaires, et dont le format est indiqué par le sous-champ "type". Cela permet à une DSN de convoyer ces quantités sans considération du format.

Une DSN est un message MIME avec un type de contenu de niveau supérieur de rapport/multipartie (défini dans la [RFC3462]). Lorsque un contenu rapport/multipartie est utilisé pour transmettre une DSN :

(a) Le paramètre type de rapport du contenu rapport/multipartie est "état de livraison".

(b) Le premier composant du rapport/multipartie contient une explication lisible par l’homme de la DSN, comme décrit dans la [RFC3462].

(c) Le second composant du rapport/multipartie est du type de contenu message/état de livraison, décrit au paragraphe 2.1 du présent document.

(d) Si le message original ou une portion du message est à retourner à l’envoyeur, il apparaît comme troisième composant du rapport/multipartie.

Note : Pour les notifications d’état de livraison passées de systèmes étrangers, les en-têtes du message original peuvent n’être pas disponibles. Dans ce cas, le troisième composant de la DSN peut être omis, ou il peut contenir des en-têtes "simulés" de la RFC822 qui contiennent des informations équivalentes. En particulier, il est très souhaitable de préserver les champs sujet, date, et identifiant de message (ou équivalents) du message original.

La DSN DOIT être adressée (à la fois dans l’en-tête de message et dans l’enveloppe de transport) à l’adresse de retour figurant dans l’enveloppe de transport qui accompagnait le message original pour lequel la DSN a été générée. (Pour un message qui est arrivé via SMTP, l’adresse de retour de l’enveloppe apparaît dans la commande MAIL FROM.)

Le champ From de l’en-tête de message de la DSN DEVRAIT contenir l’adresse d’une personne qui est responsable de la maintenance du système de messagerie au site du MTA rapporteur (par exemple, le maître de poste) de sorte qu’une réponse à la DSN atteigne cette personne. Exception : si une DSN est traduite d’un rapport de livraison étranger, et si la passerelle qui effectue la traduction ne peut pas déterminer l’adresse appropriée, le champ From de la DSN PEUT être l’adresse d’une personne qui est responsable de la maintenance de la passerelle.

L’adresse de l’envoyeur de l’enveloppe de la DSN DEVRAIT être choisie de façon à s’assurer qu’aucun rapport d’état de livraison ne sera produit en réponse à la DSN elle-même, et DOIT être choisie de telle sorte que les DSN ne génèrent pas de message en boucle. Chaque fois qu’une transaction SMTP est utilisée pour envoyer une DSN, la commande MAIL FROM DOIT utiliser une adresse de retour NULLE, par exemple, "MAIL FROM:<>".

Une DSN particulière décrit l’état de livraison pour exactement un message. Cependant, un MTA PEUT rapporter l’état de livraison pour plusieurs receveurs du même message dans une seule DSN. Du fait de la nature du système de transport de messagerie (où la responsabilité de la livraison d’un message à ses receveurs peut être partagée entre plusieurs MTA, et où la livraison à un receveur particulier peut être retardée) plusieurs DSN peuvent quand même être produits en réponse à la soumission d’un seul message.

considérations de codage : le codage "7bit" est suffisant et DOIT être utilisé pour conserver la lisibilité quand il est vu par des lecteurs de messagerie non MIME.

Le type de rapport message/état de livraison à utiliser dans le rapport/multipartie est "état de livraison".

Le corps d’un message/état de livraison consiste en un ou plusieurs "champs" formatés conformément à l’ABNF des "champs" d’en-tête de la RFC822 (voir la [RFC822]). Les champs par message apparaissent en premier, suivis par une ligne blanche. Après les champs par message se trouvent un ou plusieurs groupes de champs par receveur. Chaque groupe de champ par receveur est précédé d’une ligne blanche. En utilisant l’ABNF de la RFC822, la syntaxe du contenu message/état de livraison est la suivante :

contenu-d’état-de-livraison = champs-par-message 1* ( CRLF champs-par-receveur )

Les champs par message sont décrits au paragraphe 2.2. Les champs par receveur sont décrits au paragraphe 2.3.

Comme ces champs sont définis selon les règles de la RFC822, les mêmes conventions s’appliquent pour les lignes de continuation et les commentaires. Les champs Notification peuvent être continués sur plusieurs lignes en commençant chaque ligne supplémentaires par ESPACE ou HTAB. Le texte qui apparaît entre parenthèses est considéré comme un commentaire et ne fait pas partie du contenu de ce champ de notification. Les noms des champs sont insensibles à la casse, de sorte que les noms des champs Notification peuvent être épelés dans toute combinaison de lettres majuscules et minuscules. Les commentaires dans les champs de DSN peuvent utiliser la construction "mot-codé" définie dans la [RFC2047].

Plusieurs champs DSN consistent en un sous-champ "type-", suivi par deux-points, suivi par "*texte". Pour ces champs, le mot clé utilisé dans le sous-champ type-d’adresse, type-de-diagnostic, ou type-de-nom-de-MTA indique le format attendu de l’adresse du code d’état, ou du nom de MTA qui suit.

(a) Un "type-d’adresse" spécifie le format d’une adresse de boîte aux lettres. Par exemple, les adresses de messagerie Internet utilisent le type d’adresse "rfc822".

(b) Un "type-de-diagnostic" spécifie le format d’un code d’état. Par exemple, lorsque un champ DSN contient un code de réponse rapporté via le protocole simple de transfert de messagerie [RFC0821], le type de diagnostic "smtp" est utilisé.

(c) Un "type-de-nom-de-MTA" spécifie le format d’un nom de MTA. Par exemple, pour un serveur SMTP sur un hôte Internet, le nom du MTA est le nom de domaine de cet hôte, et le type de nom de MTA "dns" est utilisé.

Les valeurs pour type-d’adresse, type-de-diagnostic, et type-de-nom-de-MTA sont insensibles à la casse. Donc, les valeurs de type d’adresse de "RFC822" et de "rfc822" sont équivalentes.

L’autorité d’allocations des numéros de l’Internet (IANA) tiendra un registre des types d’adresse, des types de diagnostic, et des types de nom de MTA, ainsi que des descriptions de la signification et des valeurs acceptables de chacun, ou une référence à une ou plusieurs spécifications qui fournissent de telles descriptions. (Les type d’adresse "rfc822", "smtp" type de diagnostic et type de nom de MTA "dns" sont définis dans la [RFC3461].) Les formulaires d’enregistrement pour type-d’adresse, type-de-diagnostic, et type-de-nom-de-MTA sont donnés à l’Appendice D.

L’IANA n’acceptera pas d’enregistrement pour des types d’adresse, type de diagnostic, ou type de nom de MTA qui commencent par "X-". Ces noms de type sont réservés pour des utilisations expérimentales.

Les jetons lexicaux suivants, définis dans la [RFC822], sont utilisés dans la grammaire ABNF pour les DSN : atome, CHAR, commentaire, CR, CRLF, CHIFFRE, LF, espace-blanche-linéaire, ESPACE, texte. Le jeton lexical date-heure est défini dans la [RFC1123].

Certains champs d’une DSN s’appliquent à toutes les tentatives de livraison décrites par cette DSN. Ces champs peuvent apparaître au plus une fois dans toute DSN. Ces champs sont utilisés pour corréler la DSN avec la transaction du message original et à fournir des informations supplémentaires qui peuvent être utiles aux passerelles.

Le champ facultatif Id-d’enveloppe-d’origine contient un "identifiant d’enveloppe" qui identifie de façon univoque la transaction durant laquelle le message a été soumis, et a été (a) spécifié par l’envoyeur et fourni par le MTA de l’envoyeur, ou (b) généré par le MTA de l’envoyeur et rendu disponible à l’envoyeur lorsque le message a été soumis. Son objet est de permettre à l’envoyeur (ou son agent d’utilisateur) d’associer la DSN retournée à la transaction spécifique dans laquelle a été envoyé le message.

Si un tel identifiant d’enveloppe était présent dans l’enveloppe qui accompagnait le message lorsque il est arrivé au MTA rapporteur, il DEVRAIT être fourni dans le champ Id-d’enveloppe-d’origine de toutes les DSN fournies par suite d’une tentative de livrer le message. Sauf quand une DSN est produite par le MTA de l’envoyeur, un MTA NE DOIT PAS fournir ce champ sauf si il y a un champ Identifiant-d’enveloppe dans l’enveloppe qui accompagnait ce message à son arrivée au MTA rapporteur.

champ-identifiant-d’enveloppe-d’origine = "Id-d’enveloppe-d’origine" ":" identifiant d’enveloppe

Il ne peut y avoir au plus qu’un seul champ Id-d’enveloppe-d’origine par DSN.

L’identifiant d’enveloppe est SENSIBLE À LA CASSE. Le DSN DOIT préserver la casse et l’orthographe d’origine de l’identifiant d’enveloppe.

Note : L’Id-d’enveloppe-d’origine N’EST PAS le même que l’identifiant de message de l’en-tête de message. L’identifiant de message identifie le contenu du message, alors que l’identifiant d’enveloppe d’origine identifie la transaction dans laquelle le message est envoyé.

Une DSN décrit les résultats de tentatives de livrer, relayer, ou passer un message à un ou plusieurs receveurs. Dans tous les cas, le MTA-rapporteur est le MTA qui a tenté d’effectuer l’opération de livraison, relais, ou passage décrite dans la DSN. Ce champ est obligatoire.

Noter que si un client SMTP tente de relayer un message à un serveur SMTP et reçoit une réponse d’erreur à une commande RCPT, le client est responsable de la génération de la DSN, et le nom de domaine du client va apparaître dans le champ MTA-rapporteur. (Le nom de domaine du serveur va apparaître dans le champ MTA-distant.)

Noter que le MTA-rapporteur n’est pas nécessairement le MTA qui a réellement produit la DSN. Par exemple, si une tentative de livraison d’un message en dehors de l’Internet résulte en une notification de non livraison qui a été repassée dans la messagerie Internet par une passerelle, le champ MTA-rapporteur de la DSN résultante sera celui du MTA qui a rapporté à l’origine l’échec de livraison, non celui de la passerelle qui a converti la notification étrangère en une DSN. Voir la Figure 2.

(3) le MTA-rapporteur (dans l’environnement du receveur) retourne une notification de non livraison

La portion nom de MTA du champ MTA-rapporteur est formatée conformément aux conventions indiquées par le sous-champ type-de-nom-de-mta. Si un MTA fonctionne comme passerelle entre des environnements de messagerie dissemblables et donc est connu sous plusieurs noms selon l’environnement, le sous-champ nom-de-mta DEVRAIT contenir le nom utilisé par l’environnement duquel le message a été accepté par le MTA-rapporteur.

Parce que l’orthographe exacte d’un nom de MTA peut être significative dans un environnement particulier, les noms de MTA sont SENSIBLES à la casse

Le champ Passerelle-DSN indique le nom de la passerelle ou MTA qui traduit une notification d’état de livraison étrangère (non Internet) en cette DSN. Ce champ DOIT apparaître dans toute DSN qui a été traduite par une passerelle d’un système étranger en format de DSN, et NE DOIT PAS apparaître autrement.

Pour les passerelles vers la messagerie Internet, le type-de-nom-de-MTA va normalement être "dns", et le nom-de-mta sera le nom de domaine Internet de la passerelle.

Le champ facultatif MTA-de-provenance indique le nom du MTA d’où le message a été reçu.

champ-MTA-de-provenance = "MTA-de-provenance" ":" type-de-nom-de-mta";" nom-de-mta

Si le message a été reçu d’un hôte Internet via SMTP, le contenu du sous-champ nom-de-mta DEVRAIT être le nom de domaine Internet fourni dans la commande HELO ou EHLO, et l’adresse réseau utilisée par le client SMTP DEVRAIT être incluse comme commentaire entre parenthèses. (Dans ce cas, le type-de-nom-de-mta sera "dns".)

La portion nom-de-mta du champ MTA-de-provenance est formatée conformément aux conventions indiquées par le sous-champ Type-de-nom-de-MTA.

Comme la casse est significative dans certains systèmes de messagerie, l’orthographe exacte, y compris la casse, du nom du MTA DEVRAIT être préservée.

Le champ facultatif Date-d’arrivée indique la date et l’heure à laquelle le message est arrivé au MTA rapporteur. Si le champ Date-de-dernière-tentative est aussi fourni dans un champ par receveur, cela peut être utilisé pour déterminer l’intervalle entre le moment où le message est arrivé au MTA rapporteur et celui où le rapport a été produit pour ce receveur.

La date et l’heure sont exprimées dans le format 'date-heure' de la RFC822 , tel que modifié par la [RFC1123]. Les zones horaires numériques (format [+/-]HHMM) DOIVENT être utilisées.

Une DSN contient des informations sur les tentatives de livraison d’un message à un ou plusieurs receveurs. Les informations de livraison pour un receveur particulier sont contenues dans un groupe de champs contigus par receveur. Chaque groupe de champs par-receveur est précédé d’une ligne blanche.

Le champ Receveur-d’origine indique l’adresse de receveur originale telle que spécifiée par l’envoyeur du message pour lequel la DSN est produite.

champ-receveur-d’origine = "Receveur-d’origine" ":" type-d’adresse ";" adresse-générique

Le champ type-d’adresse indique le type de l’adresse du receveur original. Si le message a été généré au sein de l’Internet, le champ type-d’adresse va normalement être "rfc822", et l’adresse sera en accord avec la syntaxe spécifiée dans la [RFC822]. La valeur "inconnu" devrait être utilisée si le MTA rapporteur ne peut pas déterminer le type de l’adresse du receveur original à partir de l’enveloppe de message.

Ce champ est facultatif. Il devrait n’être inclus que si l’adresse de receveur spécifiée par l’envoyeur était présente dans l’enveloppe de message, comme avec les extensions SMTP définies dans la [RFC3461]. Cette adresse est la même que celle fournie par l’envoyeur et peut être utilisée pour corréler automatiquement les rapports de DSN et les transactions de message.

Le champ Receveur-final indique le receveur pour lequel cet ensemble de champs par receveur s’applique. Ce champ DOIT être présent dans chaque ensemble de données par receveur.

champ-receveur-final = "Receveur-final" ":" type-d’adresse ";" adresse-générique

Le sous-champ adresse-générique du champ Receveur-final DOIT contenir l’adresse de boîte aux lettres du receveur (à partir de l’enveloppe de transport) comme elle était lorsque le MTA rapporteur a accepté la livraison du message.

L’adresse du receveur final peut différer de l’adresse fournie à l’origine par l’envoyeur, parce que elle peut avoir été transformée durant la transmission et les passages de passerelles en un méli-mélo totalement non reconnaissable. Cependant, en l’absence du champ facultatif Receveur-d’origine, le champ Receveur-final et tout contenu retourné peuvent être les seules informations disponibles avec lesquelles corréler la DSN pour une soumission de message particulière.

Le sous-champ Type-d’adresse indique le type d’adresse attendu par le MTA rapporteur dans ce contexte. Les adresses de receveur obtenues via SMTP vont normalement être du type d’adresse "rfc822".

Note : Le MTA rapporteur n’est pas supposé s’assurer que l’adresse se conforme réellement aux conventions syntaxiques du type d’adresse. Il DOIT plutôt rapporter exactement l’adresse reçue dans l’enveloppe, sauf si cette adresse contient des caractères tels que CR ou LF qui ne sont pas admis dans un champ DSN.

Comme les adresses de boîte aux lettres (y compris celles utilisées dans l’Internet) peuvent être sensibles à la casse, la casse des caractères alphabétiques DOIT être préservée dans l’adresse.

Le champ Action indique l’action effectuée par le MTA-rapporteur par suite de sa tentative de livraison du message à cette adresse de receveur. Ce champ DOIT être présent pour chaque receveur désigné dans la DSN.

La valeur-d’action peut être épelée dans toute combinaison de caractères majuscules et minuscules.

"échec" : indique que le message n’a pas pu être livré au receveur. Le MTA rapporteur a abandonné toute tentative de livrer le message à ce receveur. Aucune autre notification ne devrait être attendue.

"retardé" : indique que le MTA rapporteur a jusqu’à présent été incapable de livrer ou relayer le message, mais il va continuer de tenter de le faire. Des notifications de message supplémentaires peuvent être produites si le message est encore retardé ou si sa livraison réussit, ou si les tentatives de livraison sont abandonnées ultérieurement.

"livré" : indique que la livraison du message est réussie à l’adresse de receveur spécifiée par l’envoyeur, qui inclut la "livraison" à un exploseur de liste de diffusion. Il n’indique pas que le message a été lu. C’est un état terminal et aucune autre DSN n’est à attendre pour ce receveur.

"relayé" : indique que le message a été relayé ou transmis à une passerelle dans un environnement qui n’accepte pas la responsabilité de la génération de DSN sur livraison réussie. Cette valeur-d’action NE DEVRAIT PAS être utilisée sauf si l’envoyeur a demandé la notification des livraisons réussies pour ce receveur.

"expansé" : indique que le message a bien été livré à l’adresse de receveur spécifiée par l’envoyeur, et transmise par le MTA-rapporteur au delà de cette destination à plusieurs adresses de receveur supplémentaires. Une valeur-d’action de "expansé" diffère de "livré" en ce que "expansé" n’est pas un état terminal. D’autres notifications "échec" et/ou "retardé" ultérieures peuvent être fournies.

En utilisant les termes de "liste de diffusion" et de "alias" comme définis dans la [RFC3461], paragraphe 5.2.7 : une valeur-d’action de "expansé" n’est à utiliser que lorsque le message est livré à un "alias" de plusieurs receveurs. Une valeur-d’action de "expansé" NE DEVRAIT PAS être utilisée avec une DSN produite à la livraison d’un message à une "liste de diffusion".

Note sur Action contre Codes d’état : Bien que le champ 'action' puisse sembler redondant avec le champ 'état', ce n’est pas le cas. En particulier, un code d’état "défaillance temporaire" ("4") pourrait être utilisé avec une valeur-d’action de "retardé" ou "échec". Par exemple, on suppose qu’un client SMTP essaye de façon répétée de relayer un message à l’échangeur de messagerie pour un receveur, mais échoue parce que une interrogation d’un serveur de noms de domaines est arrivée à expiration. Après quelques heures, il pourrait produire une DSN "retardé" pour informer l’envoyeur que le message n’a pas encore été livré. Après quelques jours, le MTA pourrait abandonner sa tentative de livraison du message et retourner une DSN "échec". Le code d’état (qui commencerait par un "4" pour indiquer une "défaillance temporaire") serait le même pour les deux DSN.

Un autre exemple pour lequel action et codes d’état peuvent paraître contradictoires : si un MTA ou passerelle de messagerie ne peut pas délivrer un message parce que cela entraînerait une conversion résultant en une perte inacceptable d’informations, il va produire une DSN avec le champ 'Action' de "échec" et un code d’état de 'XXX'. Si le message avait été relayé, mais avec une certaine perte d’informations, il pourrait générer une DSN avec le même code d’état XXX, mais avec un champ Action de "relayé".

Le champ par receveur État contient un code d’état indépendant du transport qui indique l’état de livraison du message à ce receveur. Ce champ DOIT être présent pour chaque tentative de livraison qui est décrite par une DSN. La syntaxe du champ État est :

; Les caractères espace et les commentaires NE SONT PAS admis au sein d’un code d’état, bien qu’un commentaire entre
; parenthèses PUISSE suivre le dernier sous-champ numérique du code d’état. Chaque sous-champ numérique au sein du
; code d’état DOIT être exprimé sans zéros en tête.

Les codes d’état consistent donc en trois champs numériques séparés par des points ".". Le premier sous-champ indique si la tentative de livraison a réussi (2 = succès, 4 = échec temporaire persistent, 5 = échec permanent). Le second sous-champ indique la source probable de toute anomalie de livraison, et le troisième sous-champ note une condition d’erreur précise, si elle est connue.

La valeur associée au champ DSN MTA-distant est une représentation en caractères ASCII imprimables du nom du MTA "distant" qui a rapporté l’état de livraison au MTA "rapporteur".

Note : Le champ MTA-distant préserve les informations "d’à propos" qui avaient été fournies dans des rapports de non livraison préexistants.

Ce champ est facultatif. Il NE DOIT PAS être inclus si aucun MTA distant n’était impliqué dans la tentative de livraison du message à ce receveur.

Pour un receveur en "échec" ou "retardé", le champ Code-de-diagnostic de DSN contient le code de diagnostic réel produit par le transport de messagerie. Comme de tels codes varient d’un transport de messagerie à l’autre, le sous-champ type-de-diagnostic est nécessaire pour spécifier quel type de code de diagnostic est représenté.

champ-code-de-diagnostic = "Code-de-diagnostic" ":" type-de-diagnostic ";" *texte

Note : Les informations dans le champ Code-de-diagnostic peuvent être quelque peu redondantes avec celles provenant du champ État. Le champ État est nécessaire afin que toute DSN, sans considération de son origine, puisse être comprise par tout agent d’utilisateur ou passerelle qui analyse les DSN. Comme le code État va parfois être moins précis que le code de diagnostic du transport réel, le champ Code-de-diagnostic est fourni pour conserver ces dernières informations. De telles informations peuvent être utiles dans un ticket de problème envoyé à l’administrateur du MTA rapporteur, ou lors du tunnelage de rapports de non livraison étrangers à travers des DSN.

Si le code de diagnostic a été obtenu d’un MTA distant durant une tentative de relais du message à ce MTA, le champ MTA-distant devrait être présent. Lors de l’interprétation d’une DSN, la présence d’un champ MTA-distant indique que le code de diagnostic a été produit par le MTA distant. L’absence du champ MTA-distant indique que le code de diagnostic a été produit par le MTA rapporteur.

En plus du code de diagnostic lui-même, une description textuelle supplémentaire du diagnostic PEUT apparaître dans un commentaire entre parenthèses.

Ce champ est facultatif, parce que certains systèmes de messagerie ne fournissent pas d’informations supplémentaires au delà de ce qui est retourné dans les champs 'action' et 'état'. Cependant, ce champ DEVRAIT être inclus si des informations de diagnostic spécifiques du transport sont disponibles.

Le champ Date-de-dernière-tentative donne la date et l’heure de la dernière tentative de relais, de passage, ou de livraison du message (qu’elle soit une réussite ou un échec) par le MTA rapporteur. Ce n’est pas nécessairement la même que la valeur du champ Date de l’en-tête du message utilisé pour transmettre cette notification d’état de livraison : dans les cas où la DSN a été générée par une passerelle, le champ Date dans l’en-tête de message contient l’heure à laquelle la DSN a été envoyée par la passerelle et le champ de DSN Date-de-dernière-tentative contient l’heure à laquelle est survenue la dernière tentative de livraison.

champ-date-de-dernière-tentative = "Date-de-dernière-tentative" ":" date-heure

Ce champ est facultatif. Il NE DOIT PAS être inclus si la date et l’heure réelles de la dernière tentative de livraison ne sont pas disponibles (ce qui peut être le cas si la DSN devait être produite par une passerelle).

La date et l’heure sont exprimées dans le format de la RFC822 'date-heure', comme modifié par la [RFC1123]. Les zones horaires numériques (format [+/-]HHMM) DOIVENT être utilisées.

Le champ "Id-d’enregistrement-final" donne l’Id-d’enregistrement-final du message qui a été utilisé par le mta-final. Cela peut être utile comme indice pour l’entrée d’enregistrement du mta-final pour cette tentative de livraison.

Pour les DSN du type "retardé", le champ Réessai-jusqu’à donne la date après laquelle le MTA rapporteur s’attend à abandonner les tentatives de livraison du message à ce receveur. Le champ Réessai-jusqu’à est facultatif pour les DSN "retard", et NE DOIT PAS apparaître dans les autres DSN.

La date et l’heure sont exprimées dans le format 'date-heure' de la RFC822 , tel que modifié par la [RFC1123]. Les zones horaires numériques (format [+/-]HHMM) DOIVENT être utilisées.

Des champs de DSN supplémentaires par message ou par receveur peuvent être définis à l’avenir par des révisions ou extensions ultérieures à la présente spécification. Les noms de champ d’extension commençant par "X-" ne seront jamais définis comme champs standard ; de tels noms sont réservés pour des utilisations expérimentales. Les noms de champ de DSN qui NE commencent PAS par "X-" DOIVENT être enregistrés auprès de l’autorité d’allocation des numéros de l’Internet (IANA) et publiés dans une RFC.

Les champs d’extension de DSN peuvent être définis pour les raisons suivantes :

(a) Pour permettre que des informations supplémentaires en provenance de rapports d’état de livraison étrangers soient tunnelées à travers des DSN Internet. Les noms de tels champs de DSN devraient commencer par une indication du nom de l’environnement étranger (par exemple, X400-Adresse-de-transmission-physique).

(b) Pour permettre la transmission d’informations de diagnostic qui sont spécifiques d’un protocole particulier de transport de messagerie. Les noms de tels champs de DSN devraient commencer par une indication du transport de messagerie utilisé (par exemple, SMTP-Adresse-de-receveur-distant). De tels champs ne devraient être utilisés que pou les besoins de diagnostic et non par les agents d’utilisateur ou les passerelles de messagerie.

(c) Pour permettre la transmission d’informations de diagnostic qui sont spécifiques d’un agent de transfert de message particulier (MTA). Les noms de tels champs de DSN devraient commencer par une indication de la mise en œuvre de MTA qui a produit la DSN. (par exemple, Foomail-ID-de-file-d’attente).

Les mises en œuvre de MTA sont invitées à fournir des informations adéquates, via les champs d’extension si nécessaire, pour permettre que le tenancier du MTA comprenne la nature des échecs de livraison corrigibles et comment les réparer. Par exemple, si les tentatives de livraison de message sont enregistrées dans un journal d'événements, la DSN pourrait inclure des informations qui permettent au tenancier du MTA de trouver facilement l’entrée du journal pour un échec de tentative de livraison.

Si un développeur de MTA ne souhaite pas enregistrer la signification d’un tel champ d’extension, il peut utiliser à cette fin les champs "X-". Pour éviter des collisions de noms, le nom de la mise en œuvre de MTA devrait suivre le "X-", (par exemple, "X-Foomail-ID-d’enregistrement").

Un MTA ou passerelle se conforme à la présente spécification si il génère des DSN conformément au protocole défini dans le présent mémoire. Pour les MTA et passerelles qui ne prennent pas en charge les demandes de notification positive de livraison (comme dans la [RFC3461]) il est suffisant que les rapports d’échec de livraison utilisent ce protocole.

Une mise en œuvre minimale de la présente spécification a besoin de générer seulement le champ par message MTA-rapporteur, et les champs Receveur-final, Action, et État pour chaque tentative de livraison d’un message à un receveur décrits par la DSN. La génération des autres champs, quand ils sont appropriés, est fortement recommandée.

Les MTA et passerelles NE DOIVENT PAS générer le champ Receveur-d’origine d’une DSN sauf si le protocole de transfert de messagerie fournit l’adresse spécifiée à l’origine par l’envoyeur au moment de la soumission. (Le SMTP ordinaire ne donne pas cette garantie, mais l’extension SMTP définie dans la [RFC3461] permet que de telles informations soient portées dans l’enveloppe si elle est disponible.)

Chaque adresse de receveur spécifiée par l’envoyeur DEVRAIT résulter en au plus une DSN "livré" ou "échec" pour ce receveur. Si une DSN positive est demandée (par exemple, une qui utilise NOTIFY=SUCCES dans SMTP) pour un receveur qui est transmise à plusieurs receveurs d’un "alias" (comme défini dans la [RFC3461], paragraphe 5.2.7) le MTA transmetteur DEVRAIT normalement produire une DSN "expansé" pour le receveur spécifié à l’origine et non propager la demande d’une DSN aux adresses de transmission. Autrement, le MTA transmetteur PEUT relayer la demande d’une DSN à exactement une des adresses de transmission et non propager la demande aux autres.

À l’opposé, la soumission réussie d’un message à un exploseur de liste de diffusion est considérée comme livraison finale du message. À la livraison d’un message à une adresse de receveur correspondant à un exploseur de liste de diffusion, le MTA rapporteur DEVRAIT produire une DSN appropriée exactement comme si l’adresse de receveur était celle d’une boîte aux lettres ordinaire.

Note : Ceci est en fait destiné à rendre les DSN utilisables par les listes de diffusion elles-mêmes. Tout message envoyé à un abonné d’une liste de diffusion devrait avoir son adresse de retour d’enveloppe pointée sur le tenancier de la liste [voir la RFC1123, paragraphe 5.3.7(E)]. Comme les DSN sont envoyées à l’adresse de retour de l’enveloppe, toutes les DSN qui résultent de la livraison aux receveurs d’une liste de diffusion seront envoyées au tenancier de la liste. Le tenancier de la liste peut choisir de traiter mécaniquement les DSN à réception, et donc automatiquement supprimer les adresses invalides de la liste. (Voir à la section 7.)

La présente spécification ne fait pas de restriction sur le traitement des DSN reçues par les agents d’utilisateur ou les listes de distribution.

Les considérations pour la sécurité suivantes s’appliquent à l’utilisation des DSN :

Les DSN peuvent être falsifiées aussi facilement que les messages électroniques ordinaires de l’Internet. Les agents d’utilisateur et les facilités de traitement automatique de messagerie (telles que les exploseurs de liste de distribution de message) qui souhaitent faire un usage automatique des DSN devraient prendre les précautions appropriées pour minimiser les dommages potentiels d’attaques de déni de service.

Les menaces contre la sécurité qui se rapportent à des DSN falsifiées incluent l’envoi de :

(a) une fausse notification de livraison alors que le message n’a pas été délivré au receveur indiqué,

(b) une fausse notification de non livraison alors que le message a en fait été délivré au receveur indiqué,

(e) une notification falsifiée de relais alors que le message est "dans une impasse",

Une autre dimension de la sécurité est la confidentialité. Il peut y avoir des cas où un receveur de message s’auto transmet des messages mais ne souhaite pas divulguer l’adresse à laquelle les messages sont auto transmis. Le désir d’une telle confidentialité sera probablement accru lorsque des "boîtes aux lettres sans fil", comme les pageurs mobiles, seront devenus d’usage courant comme adresses d’auto transmission.

Les auteurs de MTA sont invités à fournir un mécanisme qui permette à l’utilisateur final de préserver la confidentialité d’une adresse de transmission. Selon le degré de confidentialité requis, et la nature de l’environnement auquel le message va être transmis, cela peut être accomplis par un ou plusieurs de :

(a) produire une DSN "relayé" (si une DSN positive était demandée) quand un message est transmis à une adresse de transmission confidentielle, et désactiver les demandes de DSN positives pour le message transmis,

(b) déclarer le message à livrer, en produisant une DSN "livré", en renvoyant le message à l’adresse de transmission confidentielle, et s’arrangeant pour qu’aucune DSN ne soit produite pour le message renvoyé,

(c) omettre les champs "Distant-*" ou extension d’une DSN chaque fois qu’ils pourraient autrement contenir des informations confidentielles (telles que l’adresse de transmission confidentielle),

(d) pour les messages transmis à une adresse confidentielle, régler l’adresse de retour d’enveloppe (par exemple, l’adresse SMTP MAIL FROM) au chemin inverse NUL ("<>") (afin qu’aucune DSN ne soit envoyée d’un MTA aval à l’envoyeur d’origine),

(e) pour les messages transmis à une adresse confidentielle, en désactivant les notifications de livraison pour le message transmis (par exemple, si le MTA du "prochain bond" utilise ESMTP et prend en charge l’extension DSN, en utilisant le paramètre NOTIFY=NEVER sur la commande RCPT), ou

(f) lors de la transmission de messages à une adresse confidentielle, faire que le MTA transmetteur réécrive l’adresse de retour d’enveloppe pour le message transmis et tente de livrer ce message comme si le MTA transmetteur en était l’origine. À la réception de son état de livraison final, le MTA de transmission va produire une DSN à l’envoyeur original.

En général, tout champ facultatif de DSN peut être omis si le site du MTA rapporteur détermine que l’inclusion du champ imposerait une trop grande compromission de la confidentialité du site. Le besoin d’une telle confidentialité doit être mis en balance avec l’utilité des informations omises dans les rapports de problèmes et les DSN passées à des environnements étrangers.

Les mises en œuvre doivent faire attention à ce que de nombreux MTA existants vont envoyer des notifications de non livraison à l’adresse de retour qui est dans l’en-tête de message (plutôt qu’à celle de l’enveloppe) en violation de SMTP et des autres protocoles. Si un message est transmis à travers un tel MTA, aucune action raisonnable de la part du MTA transmetteur ne va empêcher le MTA aval de compromettre l’adresse de transmission. De même, si le MTA du receveur répond automatiquement aux messages sur la base d’une demande dans l’en-tête de message (telle que l’extension d’en-tête non standard, mais largement utilisée, Return-Receipt-To) il va aussi compromettre l’adresse de transmission.

Dans le cadre de la messagerie Internet d’aujourd’hui, les DSN définies dans le présent mémoire fournissent des informations précieuses à l’utilisateur de messagerie ; cependant, même une DSN "échec" ne peut pas être tenue pour garantie qu’un message n’a pas été reçu par le receveur. Même si les DSN ne sont pas activement falsifiées, il existe des conditions dans lesquelles un message peut être délivré en dépit du fait qu’une DSN d’échec a été produite.

Par exemple, une condition de concurrence dans le protocole SMTP permet la duplication des messages si la connexion est abandonnée à la suite de l’achèvement d’une commande DATA, mais avant qu’une réponse soit vue par le client SMTP.

Cela va causer la retransmission du message par le client SMTP, bien que le serveur SMTP l’ait déjà accepté [RFC1047]. Si une de ces tentatives de livraison réussit et si l’autre échoue, une DSN "échec" pourra être produite alors que le message a en fait atteint le receveur.

[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)

[RFC1894] K. Moore, G. Vaudreuil, "Format de message extensible pour les notifications d'état de livraison", janvier 1996. (Obsolète, voir RFC3464) (P.S.)

[RFC2045] N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 1 : Format des corps de message Internet", novembre 1996. (D. S., MàJ par 2184, 2231, 5335.)

[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.)

Les auteurs tiennent à remercier les personnes suivantes de leur révision des premiers projets de la RFC1894, dont le présent document est une révision, et de leurs suggestions d’améliorations : Eric Allman, Harald Alvestrand, Allan Cargille, Jim Conklin, Peter Cowen, Dave Crocker, Roger Fajman, Ned Freed, Marko Kaittola, Steve Kille, John Klensin, John Gardiner Myers, Mark Nahabedian, Julian Onions, Jacob Palme, Jean Charles Roy, et Gregory Sheehan.

Note : Les jetons lexicaux suivants sont définis dans la RFC822 : atome, CHAR, commentaire, CR, CRLF, CHIFFRE, LF, espace-blanche-linéaire, ESPACE, texte. Le jeton lexical date-heure est défini dans la [RFC1123].

contenu-d’état-de-livraison = champs-par-message 1*( CRLF champs-par-receveur )

champ-code-de-diagnostic = "Code-de-diagnostic" ":" type-de-diagnostic ";" *texte

champ-receveur-final = "Receveur-final" ":" type-d’adresse ";" adresse-générique

champ-date-de-dernière-tentative = "Date-de-dernière-tentative" ":" date-heure

champ-identifiant-d’enveloppe-d’origine = "Identifiant-d’enveloppe-d’origine" ":" identifiant-d’enveloppe

champ-receveur-d’origine = "Receveur-d’origine" ":" type-d’adresse ";" adresse-générique

champ-mta-de-provenance = "MTA-de-provenance" ":" type-de-nom-de-mta ";" nom-de-mta

; les caractères espace et les commentaires NE SONT PAS admis au sein d’un code-d’état, bien qu’un commentaire entre
; parenthèses PUISSE suivre le dernier sous-champ numérique du code-d’état. Chaque sous-champ numérique au sein du
; code-d’état DOIT être exprimé sans chiffres zéro en tête.

Note : Cette section fournit des recommandations non obligatoires pour la construction de passerelles de messagerie qui souhaitent fournir des rapports de livraison semi transparents entre l’Internet et un autre système de messagerie électronique. Les exigences spécifiques de passerelle de DSN pour une paire particulière de systèmes de messagerie peuvent être définies par d’autres documents.

Une passerelle de messagerie peut produire une DSN pour convoyer le contenu d’une notification "étrangère" de livraison ou de non livraison sur la messagerie Internet. Lorsque il y a des transpositions appropriées entre les éléments de la notification étrangère et les champs de DSN, les informations peuvent être transmises dans ces champs de DSN. Des informations supplémentaires (telles que celles qui peuvent être utiles dans un ticket de problème ou nécessaires pour tunneler la notification étrangère à travers l’Internet) peuvent être définies dans les champs d’extension de DSN. (De tels champs devraient recevoir des noms qui identifient le protocole de messagerie étranger, par exemple, X400-* pour des éléments de protocole NDN ou DN X.400.)

La passerelle doit tenter de fournir des valeurs raisonnables pour les champs MTA-rapporteur, Receveur-final, Action, et État. Elles seront normalement obtenues en traduisant les valeurs provenant de la notification de livraison ou non livraison distante en son équivalent de style Internet. Cependant, on peut s’attendre à une certaine perte d’informations. Par exemple, l’ensemble des codes d’état définis pour les DSN peut n’être pas adéquat pour convoyer pleinement le code de diagnostic de livraison depuis le système étranger. La passerelle devrait allouer le code le plus précis qui décrit la condition de défaillance, revenant aux codes "génériques" tels que 2.0.0 (succès) 4.0.0 (défaillance temporaire) et 5.0.0 (défaillance permanente) lorsque nécessaire. Le code de diagnostic étranger réel devrait être conservé dans le champ Code-de-diagnostic (avec une valeur de type de diagnostic appropriée) à utiliser sans les tickets de problème ou le tunnelage.

L’adresse de receveur spécifiée par l’envoyeur, et l’identifiant d’enveloppe d’origine, si il est présent dans l’enveloppe de transport étrangère, devrait être préservé dans les champs Receveur-d’origine et ID-d’enveloppe-d’origine.

La passerelle devrait aussi tenter de préserver les adresses de receveur"finales" et les noms de MTA provenant du système étranger. Chaque fois que possible, les éléments du protocole étranger devraient être codés comme des chaînes significatives de caractères ASCII imprimables.

Pour les DSN produites à partir de notifications de livraison ou non livraison étrangères, le nom de la passerelle DOIT apparaître dans le champ Passerelle-DSN de la DSN.

Il est possible de passer des DSN de l’Internet dans un système de messagerie étranger. Le principal objet d’un tel passage est de convoyer des informations d’état de livraison sous une forme utilisable par le système de destination. Un objectif secondaire est de permettre le "tunnelage" des DSN à travers les systèmes de messagerie étrangers, au cas où la DSN pourrait être repassée dans l’Internet.

En général, le receveur de la DSN (par exemple, l’envoyeur du message original) va vouloir savoir, pour chaque receveur : l’approximation la plus proche disponible de l’adresse de receveur original, l’état de livraison (succès, échec, ou défaillance temporaire) et pour les échecs de livraison, un code de diagnostic qui décrive la raison de l’échec.

Si possible, la passerelle devrait tenter de préserver l’adresse du receveur d’origine et l’identifiant d’enveloppe d’origine (s’il est présent) dans le rapport étranger d’état de livraison résultant.

En rapportant un échec de livraisons, si le sous-champ type-de-diagnostic du champ Code-de-diagnostic indique que le code original de diagnostic est compris par l’environnement de destination, les informations du champ Code-de-diagnostic devraient être utilisées. Faute de quoi, les informations dans le champ État devraient être transposées en le code de diagnostic le plus proche disponible utilisé dans l’environnement de destination.

Si il est possible de tunneler une DSN à travers l’environnement de destination, la spécification de passerelle peut définir un moyen de préserver les informations de la DSN dans les rapports d’état de livraison utilisés par cet environnement.

Appendice C Lignes directrices pour l’utilisation de DSN par des exploseurs de liste de diffusion

Cette section ne se rapporte qu’à l’utilisation des DSN par des "listes de diffusion" comme défini dans la [RFC3461], paragraphe 5.2.7.

Les DSN sont conçues pour être utilisées par des exploseurs de liste de diffusion pour leur permettre de détecter et supprimer automatiquement les receveurs pour lesquels la livraison de message échoue de façon répétée.

Lors de la transmission d’un message aux abonnés d’une liste, l’exploseur de liste de diffusion devrait toujours régler l’adresse de retour d’enveloppe (par exemple, l’adresse SMTP MAIL FROM) à pointer sur une adresse spéciale qui est établie pour recevoir les rapports de non livraison. Un exploseur de liste de diffusion "intelligent" peut donc intercepter de tels rapports de non livraison, et si ils sont dans le format DSN, les examiner automatiquement pour déterminer pour quels receveurs la livraison d’un message a échoué ou a été retardée.

Le champ Receveur-d’origine devrait être utilisé si disponible, car il devrait correspondre exactement à l’adresse d’abonné connue de la liste. Si le champ Receveur-d’origine n’est pas disponible, le champ de receveur peut ressembler à la liste des adresses des abonnés. Souvent, cependant, l’abonné de la liste aura transmis sa messagerie à une adresse différente, ou l’adresse peut avoir été soumise à des réécritures, de sorte qu’une heuristique peut être requise pour faire correspondre avec succès une adresse provenant du champ de receveur. Il faut veiller dans ce cas à minimiser la possibilité de fausse correspondance.

La raison d’un échec de livraison peut être obtenue des champs État et Action, et du champ Code-de-diagnostic (si le type d’état est reconnu). Les rapports pour les receveurs avec des valeurs d’action autres que "échec" peuvent généralement être ignorées; en particulier, les abonnés ne devraient pas être retirés d’une liste à cause de rapports "retardé".

En général, presque tous les codes d’état d’échec (même un "permanent") peuvent résulter d’une condition temporaire. Il est donc recommandé qu’un exploseur de liste ne supprime pas un abonné sur la base d’une seule DSN d’échec (sans considération du code d’état) mais seulement en cas de persistance de l’échec de livraison sur une certaine période de temps.

Cependant, certaines sortes de défaillances sont moins probables que d’autres pour avoir été causées par des conditions temporaires, et certaines sortes de défaillances ont plus de chances d’être remarquées et corrigées rapidement que d’autres. Une fois que des codes d’état plus précis auront été définis, il pourra être utile de différencier entre les codes d’état pour décider si il faut supprimer un abonné. Par exemple, sur une liste avec un fort volume de messages, il peut être souhaitable de suspendre temporairement la livraison à une adresse de receveur qui cause des défaillances "temporaires" répétées, plutôt que de simplement supprimer le receveur. La durée de la suspension peut dépendre du type d’erreur. D’un autre côté, un erreur "utilisateur inconnu" qui persiste pendant plusieurs jours pourrait être considérée comme une indication fiable que cette adresse n’est plus valide.

Les formulaires ci-dessous sont à utiliser lors de l’enregistrement d’un nouveau type-d’adresse, type-de-diagnostic, ou type-de-nom-de-MTA auprès le l’autorité d’allocation des numéros de l’Internet (IANA). Chaque élément d’information demandé par un formulaire d’enregistrement peut être satisfait soit en fournissant les informations sur le formulaire lui-même, soit en incluant une référence à une spécification publiée, disponible au public, qui comporte les informations nécessaires. L’IANA PEUT rejeter les enregistrements de type de DSN à cause d’un formulaire d’enregistrement incomplet, de spécifications imprécises, ou de noms de type inappropriés.

Pour enregistrer un type de DSN, complétez le formulaire applicable ci-dessous et envoyez le via un message électronique Internet à <IANA@IANA.ORG>.

Un enregistrement pour un type-d’adresse de DSN DOIT inclure les informations suivantes :

(b) La syntaxe pour les adresses de boîte aux lettres de ce type, spécifiée en utilisant des expressions régulières en BNF, ASN.1, ou autre langage non ambigu.

(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 de les coder comme caractères graphiques US-ASCII dans un champ de DSN Original-Recipient ou Final-Recipient.

(d) [facultatif] Une spécification de la façon dont les adresses de ce type sont à traduire en des adresses de messagerie électronique Internet.

Un enregistrement pour un type d’adresse de DSN DOIT inclure les informations suivantes :

(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.

(d) [facultatif] Une spécification pour transposer les codes de diagnostic de ce type en codes d’état de DSN (comme défini dans la [RFC1894]).

Un enregistrement du type-de-nom-de-MTA de DSN doit comporter les informations suivantes :

(b) Une description de la syntaxe des noms de MTA de ce type, en utilisant la notation en BNF, les expressions régulières, l’ASN.1, ou un autre langage non ambigu.

(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 de la façon dont un nom de MTA de ce type devrait être exprimé comme séquence de caractères graphiques US-ASCII.

Ces exemples sont donnés à titre d’illustration, et ne sont pas considérés comme faisant partie de la spécification du protocole de DSN. Si il y a conflit entre un exemple et la définition du protocole ci-dessus, l’exemple a tort.

De même, l’utilisation de noms de sous-champ type-* ou de champs d’extension dans ces exemples n’est pas à interpréter comme une définition pour ces noms de type ou champs d’extension.

Ces exemples ont été traduits manuellement de messages renvoyés en utilisant les informations disponibles.

Voici une simple DSN produite après l’échec répétées des tentatives de livraison d’un message. Dans ce cas, la DSN est produite par le MTA même d’où le message a été généré.

Le message original a été reçu samedi 2 juillet 1994 à 17:10:28 -0400 de root@localhost

<louisl@larry.slip.umd.edu>... Différée : la connexion avec larry.slip.umd.edu est arrivée à expiration.

Voici une autre DSN produite par le MTA de l’envoyeur, qui contient des détails de plusieurs tentatives de livraison. Certaines d’entre elles ont été détectées localement, et d’autres par un MTA distant.

Code-de-diagnostic : smtp; 550 'arathib@vnet.IBM.COM' n’est pas un utilisateur de passerelle enregistré

Un rapport de livraison généré par le routeur de message (MAILBUS) et passé par PMDF_MR à une DSN. Dans ce cas, la passerelle n’avait pas des informations suffisantes pour fournir une adresse de receveur d’origine.

Adresse invalide - nair_s%DIR-E-NODIRMTCH, Pas d’entrée de répertoire correspondante

Un rapport de retard provenant d’un MTA multi protocole. Noter qu’il n’y a pas de contenu retourné, de sorte qu’il n’apparaît pas de troisième partie de corps dans la DSN.

en dépit de tentatives répétées de livraison durant les dernières 24 heures.

La cause habituelle de ce problème est que le système distant est temporairement indisponible.

La livraison continuera d’être tentée pendant une durée totale de 168 heures, soit 7 jours.

Vous serez informé à l’issu de ce délai si la livraison se révèle impossible.

Prière de rappeler l’identifiant Q-ID dans toute interrogation concernant ce message.

Révision du texte pour le rendre conforme aux vérificateurs d’orthographe et de grammaire.

Mise à jour des références pour pointer sur les derniers documents publiés, changement du schéma d’énumération des références.

Changement du type-de-nom-de-MTA en passerelles dans la messagerie Internet, le type-de-nom-de-MTA de "SMTP" en "dns".

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.

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

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

Keith Moore	Gregory M. Vaudreuil
University of Tennessee	Lucent Technologies
1122 Volunteer Blvd, Suite 203	7291 Williamson Rd
Knoxville TN 37996-3450	Dallas, Tx. 75214
USA	USA
téléphone : +1-865-974-3126	téléphone : +1 214 823 9325
Fax : +1-865-974-8296	mél : GregV@ieee.org
mél : moore@cs.utk.edu