Network Working Group T

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître 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 MIME qui peut être utilisé par un agent d’utilisateur de messagerie (MUA, mail user agent) ou une passerelle de messagerie électronique pour faire rapport de la disposition d’un message après qu’il a été livré avec succès à un receveur. Ce type de contenu est destiné à être traitable par la machine. Des en-têtes de message supplémentaires sont aussi définis pour permettre que des notifications de disposition de message (MDN, Message Disposition Notification) soient demandées par l’envoyeur d’un message. Le but est d’étendre la messagerie Internet à la prise en charge de fonctionnalités qu’on trouve souvent dans d’autres systèmes de messagerie, comme X.400 et les systèmes propriétaires "fondés sur les LAN", qu’on appelle souvent des "récépissés de lectures", des "accusés de réception", ou des "notifications de réception". L’intention est de faire cela tout en respectant les soucis de confidentialité, qui ont souvent été exprimés lorsque de telles fonctions ont été discutées dans le passé.

Parce que de nombreux messages sont envoyés entre l’Internet et d’autres systèmes de messagerie (comme X.400 ou les systèmes propriétaires "fondés sur le LAN") le protocole MDN 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 assure le transport des adresses "étrangères", en plus de celles normalement utilisées 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 2

2. Demande de notifications de disposition de message 3

2.1 En-tête Disposition-Notification-To 3

2.2 En-tête Disposition-Notification-Options 4

2.3 En-tête Original-Recipient 4

2.4 Utilisation avec le type de contenu Message/Partial 5

3. Format d’une notification de disposition de message 5

3.1 Type de contenu message/disposition-notification 6

3.2 Champs de message/disposition-notification 7

3.3 Champs d’extension 9

4. Chronologie des événements 10

5. Exigences de conformité et d’utilisation 10

6. Considérations pour la sécurité 10

6.1 Falsification 10

6.2 Confidentialité 11

6.3 Non répudiation 11

6.4 Bombardement de messages 11

7. Récapitulation de la grammaire 11

8. Lignes directrices pour les passerelles de MDN 13

8.1 Passerelle d’autres systèmes de messagerie vers MDN 13

8.2 Passerelle de MDN vers d’autres systèmes de messagerie 13

8.3 Passerelle de demandes MDN vers d’autres systèmes de messagerie 13

9. Exemple 14

10. Considérations pour l’IANA 14

10.1 Noms des paramètres d’en-tête Disposition-Notification-Options 15

10.2 Noms de modificateur de disposition 15

10.3 Noms de champ d’extension de MDN 15

11. Remerciements 15

12. Références 15

12.1 Références normatives 15

12.2 Référence pour information 16

Appendice A Changements par rapport à la RFC 2298 16

Adresse des auteurs 16

Déclaration complète de droits de reproduction 16

Le présent mémoire définit un type de contenu selon la [RFC2046] pour les notifications de disposition de message (MDN, message disposition notification). Une MDN peut être utilisée pour notifier à l’envoyeur d’un message toute condition qui peut survenir après une livraison réussie, comme l’affichage du contenu du message, l’impression du message, la suppression (sans affichage) du message, ou le refus du receveur de fournir des MDN. Le type de contenu "message/disposition-notification" défini ici est destiné à être utilisé dans le cadre du type de contenu "multipart/report" défini dans la [RFC3462].

Le présent mémoire définit le format de la notifications et les en-têtes de la [RFC2822] utilisés pour les demander.

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

(a) informer le lecteur humain de la disposition des messages après la livraison réussie, d’une manière largement indépendante du langage humain ;

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

(c) transporter les demandes de notification de disposition et les notifications de disposition entre la messagerie Internet et les systèmes de messagerie "étrangers" via une passerelle ;

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

(e) permettre de livrer des indications sur la disposition d’un message indépendantes du langage, mais raisonnablement précises.

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

(a) Il doit être lisible par l’homme, et doit être analysable par la machine.

(b) Il doit fournir assez d’informations pour permettre à l’envoyeur du message (ou son agent d’utilisateur) d’associer sans ambiguïté une MDN au message envoyé et à l’adresse du receveur original pour lequel la MDN a été produite (si une telle information est disponible) même si le message a été transmis à une autre adresse de receveur.

(c) Il doit aussi être capable de décrire la disposition d’un message indépendamment de tout langage humain particulier ou de la terminologie de tout système de messagerie particulier.

(d) La spécification doit être extensible afin de s’accommoder de futures exigences.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans la [RFC 2119].

Toutes les descriptions de syntaxe utilisent l’ABNF spécifié par la [RFC2822], dans laquelle des jetons lexicaux (utilisés ci-dessous) sont définis : "atome", "CRLF", "mailbox", "msg-id", et "texte". Les jetons lexicaux suivants sont définis dans la définition de l’en-tête Content-Type dans la [RFC2045] : "attribut" et "valeur".

Les notifications de disposition de message sont demandées en incluant un en-tête Disposition-Notification-To dans le message. D’autres informations à utiliser par le MUA du receveur pour générer la MDN peuvent être fournies en incluant aussi les en-têtes Original-Recipient et/ou Disposition-Notification-Options dans le message.

Une demande à l’agent d’utilisateur receveur de produire des notifications de disposition de message est faite en plaçant un en-tête Disposition-Notification-To dans le message. La syntaxe de l’en-tête est ;

La présence d’un en-tête Disposition-Notification-To dans un message est simplement une demande de MDN. Les agents d’utilisateur des receveurs sont toujours libres d’ignorer en silence une telle demande. Autrement, un refus explicite de la demande d’informations sur la disposition du message peut être envoyée en utilisant la disposition "denied" (refus) dans une MDN.

Une MDN NE DOIT PAS elle-même avoir un en-tête Disposition-Notification-To. Une MDN NE DOIT PAS être générée en réponse à une MDN.

Un agent d’utilisateur NE DOIT PAS produire plus d’une MDN au nom de chaque receveur particulier. C’est-à-dire que une fois qu’une MDN a été produite au nom d’un receveur, aucune autre MDN ne peut être produite au nom de ce receveur, même si une autre disposition est effectuée sur le message. Cependant, si un message est transmis, une MDN peut avoir été produite pour le receveur qui fait cette transmission et le receveur du message transmis peut aussi causer la génération d’une MDN.

Bien que les normes de l’Internet ne spécifient normalement pas le comportement des interfaces d’utilisateur, il est fortement recommandé que l’agent d’utilisateur obtienne le consentement de l’utilisateur avant d’envoyer une MDN. Ce consentement pourrait être obtenu pour chaque message au moyen d’une sorte d’invite ou de boîte de dialogue, ou globalement par l’établissement d’une préférence de l’utilisateur. L’utilisateur pourrait aussi indiquer globalement que les MDN ne sont jamais à envoyer ou qu’une MSN "denied" est toujours envoyée en réponse à une demande de MDN.

Les MDN NE DEVRAIENT PAS être envoyées automatiquement si l’adresse dans l’en-tête Disposition-Notification-To diffère de l’adresse dans l’en-tête Return-Path (voir la [RFC2822]). Dans ce cas, une confirmation de l’usager DEVRAIT être obtenue, si possible. Si il n’est pas possible d’obtenir le consentement (par exemple, parce que l’usager n’est pas en ligne à ce moment) une MDN NE DEVRAIT alors PAS être envoyée.

La confirmation de l’usager DEVRAIT être obtenue (ou aucune MDN envoyée) si il n’y a pas d’en-tête Return-Path dans le message, ou si il y a plus d’une adresse distincte dans l’en-tête Disposition-Notification-To.

La comparaison des adresses devrait être faite en utilisant seulement la portion addr-spec (partie-locale "@" domaine) à l’exclusion de toute phrase et chemin. La comparaison DOIT être sensible à la casse pour la partie locale et insensible à la casse pour la partie domaine.

Si le message contient plus d’un en-tête Return-Path, la mise en œuvre peut en prendre un pour la comparaison, ou traiter la situation comme un échec de la comparaison.

La raison pour ne pas envoyer automatiquement une MDN si la comparaison échoue ou si plus d’une adresse est spécifiée est de réduire les possibilités de messages en boucle et que les MDN soient utilisées pour des bombardements de messages.

Un message qui contient un en-tête Disposition-Notification-To DEVRAIT aussi contenir un en-tête Identifiant de message, comme spécifié dans la [RFC2822]. Cela va permettre une corrélation automatique des MDN avec leur message d’origine par les agents d’utilisateur.

Si la demande de notifications de disposition de message est désirée pour certains receveurs et pas pour d’autres, deux copies du message devraient être envoyées, une avec un en-tête Disposition-Notification-To et l’autre sans. Beaucoup des autres en-têtes du message (par exemple, To, Cc) seront les mêmes dans les deux copies. Les receveurs déterminent dans leurs enveloppes de message respectives pour lesquelles les notifications de disposition de message sont demandées et pour lesquelles elles ne le sont pas. Si c’est désiré, l’en-tête Identifiant de message peut être le même dans les deux copies du message. Noter qu’il y a d’autres situations (par exemple, Bcc) dans lesquelles il est nécessaire d’envoyer plusieurs copies d’un message avec des en-têtes légèrement différents. La combinaison de telles situations et le besoin de demander des MDN pour un sous-ensemble de tous les receveurs peut résulter en ce que plus de deux copies d’un message sont envoyées, certaines avec un en-tête Disposition-Notification-To et d’autres sans.

Les messages envoyés aux groupes de nouvelles NE DEVRAIENT PAS avoir un en-tête Disposition-Notification-To.

Des futures extensions à la présente spécification pourront exiger que des informations soient fournies au MUA du receveur pour un contrôle supplémentaire sur la façon dont sont générées les MDN et quelles MDN sont générées. L’en-tête Disposition-Notification-Options fournit un mécanisme extensible pour de telles informations. La syntaxe de cet en-tête est la suivante :

Disposition-Notification-Options = "Disposition-Notification-Options" ":" disposition-notification-parameters

Une importance de "exigé" indique que l’interprétation du paramètre est nécessaire pour la génération appropriée d’une MDN en réponse à cette demande. Si un MUA ne comprend pas la signification du paramètre, il NE DOIT PAS générer une MDN avec un type de disposition autre que "échec" en réponse à la demande. Une importance de "facultatif" indique qu’un MUA qui ne comprend pas la signification de ce paramètre PEUT de toutes façons générer une MDN en réponse, en ignorant la valeur du paramètre.

Aucun paramètre n’est défini dans la présente spécification. Des paramètres peuvent être définis à l’avenir dans des révisions ou extensions ultérieures à la présente spécification. Des noms d’attributs de paramètre commençant par "X-" ne seront jamais définis comme noms standard ; de tels noms sont réservés pour des utilisations expérimentales. Les noms de paramètre de MDN qui ne commencent pas par "X-" DOIVENT être enregistrés auprès de l’autorité d’allocation des numéros de l’Internet (IANA, Internet Assigned Numbers Authority) et décrits dans une RFC en cours de normalisation ou une RFC expérimentale approuvée par l’IESG. (Voir à la Section 10 le formulaire d’enregistrement.)

Si un paramètre exigé n’est pas compris, ou s’il contient certaines sortes d’erreurs, le MUA receveur DEVRAIT produire une MDN avec un type de disposition de "échec" (voir le paragraphe 3.2.6) et inclure un champ Échec (voir le paragraphe 3.2.7) qui décrit plus avant le problème. Les MDN avec le type de disposition de "échec" et un champ "Échec" PEUVENT aussi être générées lorsque d’autres types d’erreurs sont détectées dans les paramètres d’un en-tête Disposition-Notification-Options.

Cependant, une MDN avec un type de disposition de "échec" NE DOIT PAS être générée si l’usager a indiqué une préférence pour que les MDN ne soient pas envoyées. Si le consentement de l’usager devait être exigé pour que soit envoyée une MDN d’un autre type de disposition, le consentement de l’usager DEVRAIT aussi être obtenu avant d’envoyer une MDN avec un type de disposition de "échec".

Comme les adresses de messagerie électronique peuvent être réécrites alors que le message est en transit, il est utile que l’adresse du receveur original soit rendue disponible par le MTA de livraison. Le MTA de livraison peut être capable d’obtenir cette information du paramètre ORCPT de la commande SMTP RCPT TO, comme défini dans la [RFC2821] et la [RFC3461].

La [RFC3461] est amendée comme suit : si les informations ORCPT sont disponibles, le MTA de livraison DEVRAIT insérer un en-tête Original-Recipient au début du message (avec l’en-tête Return-Path). Le MTA de livraison PEUT supprimer tout autre en-tête Original-Recipient qui surviendrait dans le message. La syntaxe de cet en-tête est la suivante :

original-recipient-header = "Original-Recipient" ":" address-type ";" generic-address

Les jetons address-type et generic-address sont comme spécifié dans la description du champ Original-Recipient au paragraphe 3.2.3.

La raison du transport des informations sur le receveur original et de leur retour dans la MDN est de permettre une corrélation automatique des MDN avec le message d’origine par receveur.

L’utilisation des en-têtes Disposition-Notification-To, Disposition-Notification-Options, et Original-Recipient avec le type de contenu MIME message/partial ([RFC2046]) exige une définition plus précise.

Lorsque un message est segmenté en deux fragments message/partial ou plus, les trois en-têtes mentionnés au paragraphe précédent DEVRAIENT être placés dans le message "interne" ou "enclos" (en utilisant les termes de la [RFC2046]). Ces en-têtes NE DEVRAIENT être utilisés dans les en-têtes d’aucun des fragments eux-mêmes.

Lorsque les différents fragments message/partial sont rassemblés, on applique ce qui suit : si ces en-têtes surviennent avec d’autres en-têtes d’un fragment de message message/partial, ils appartiennent à une MDN qui sera générée pour le fragment ; si ces en-têtes surviennent dans les en-têtes du message "interne" ou "enclos" (en utilisant les termes de la [RFC2046]) ils appartiennent à une MDN qui sera générée pour le message réassemblé. Le paragraphe 5.2.2.1 de la [RFC2046]) est amendé pour spécifier que, en plus des en-têtes spécifiés ici, les trois en-têtes décrits dans la présente spécification sont à ajouter, dans l’ordre, aux en-têtes du message réassemblé. Aucune occurrence des trois en-têtes définis ici dans les en-têtes du message englobant initial ne doit être copiée dans le message réassemblé.

Une notification de disposition de message est un message MIME avec un type de contenu de niveau supérieur de multipart/report (défini dans la [RFC3462]). Lorsque un contenu multipart/report est utilisé pour transmettre une MDN :

(a) Le paramètre Type de rapport du contenu multipart/report est "disposition-notification".

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

(c) Le second composant du multipart/report a le type de contenu message/disposition-notification, décrit au paragraphe 3.1 du présent document.

(d) Si le message d’origine ou une portion du message doit être retourné à l’envoyeur, il apparaît comme le troisième composant du multipart/report. La décision de retourner ou non le message ou une partie du message appartient au MUA qui génère la MDN. Cependant, dans le cas d’un message chiffré qui demande une MDN, le texte du message chiffré DOIT être retourné, si il est retourné, seulement sous sa forme chiffrée originale.

Note : Pour les notifications de disposition de message relayées de systèmes étrangers, les en-têtes du message d’origine peuvent n’être pas disponibles. Dans ce cas, le troisième composant de la MDN peut être omis, ou il peut contenir des en-têtes "simulés" [RFC2822] qui contiennent des informations équivalentes. En particulier, il est très souhaitable de préserver les champs de sujet et de date du message original.

La MDN DOIT être adressée (à la fois dans l’en-tête de message et dans l’enveloppe de transport) à la ou aux adresses provenant de l’en-tête Disposition-Notification-To du message d’origine pour lequel la MDN est générée.

Le champ From de l’en-tête de message de la MDN DOIT contenir l’adresse de la personne pour laquelle est produite la notification de disposition de message.

L’adresse de l’envoyeur de l’enveloppe (c’est-à-dire, SMTP MAIL FROM) de la MDN DOIT être nulle (<>), spécifiant qu’aucun message de notification d’état de livraison ou autre message indiquant la réussite ou l’échec de la livraison n’est à envoyer en réponse à une MDN.

Une notification de disposition de message NE DOIT PAS elle-même demander une MDN. C’est à dire, elle NE DOIT PAS contenir un en-tête Disposition-Notification-To.

L’en-tête Identifiant de message (s’il est présent) pour une MDN DOIT être différent de l’identifiant de message du message pour lequel la MDN est produite.

Une MDN particulière décrit la disposition d’exactement un message pour exactement un receveur. Plusieurs MDN peuvent être générées par suite d’une soumission de message, une par receveur. Cependant, du fait des circonstances décrites au paragraphe 2.1, les MDN peuvent n’être pas générées pour certains receveurs pour lesquels les MDN ont été demandées.

Considérations de codage : Le codage "7bit" est suffisant et DOIT être utilisé pour conserver la lisibilité lorsque vu par des lecteurs de messagerie non MIME.

Le type de rapport message/disposition-notification à utiliser dans le multipart/report est "disposition-notification".

Le corps d’un message/disposition-notification consiste en un ou plusieurs "champs" formatés selon l’ABNF des "champs" d’en-tête de la [RFC2822]. La syntaxe du contenu de message/disposition-notification est la suivante :

Comme ces champs sont définis conformément aux règles de la RFC2822], les mêmes conventions s’appliquent pour les lignes de continuation et les commentaires. Les champs de notification peuvent se continuer sur plusieurs lignes en commençant chaque ligne supplémentaire par un caractère SPACE (espace) ou HTAB (tabulation horizontale). Le texte qui apparaît entre parenthèses est considéré comme un commentaire qui ne fait pas partie du contenu de ce champ de notification. Les noms de champs sont insensibles à la casse, de sorte que les noms de champs de notification peuvent être épelés dans toute combinaison de majuscules et minuscules. Les commentaires dans les champs de notification peuvent utiliser la construction "encoded-word" définie dans la [RFC2047].

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

(a) Un "address-type" 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 "MTA-name-type" spécifie le format d’un nom d’agent de transfert de messagerie. Par exemple, pour un serveur SMTP sur un hôte Internet, le nom de MTA est le nom de domaine de cet hôte, et le type de nom de MTA de "dns" est utilisé.

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

L’Autorité d’allocation des numéros de l’Internet (IANA, Internet Assigned Numbers Authority) tient un registre des valeurs de address-type et de mta-name-type, avec les descriptions de la signification de chacune, ou une référence à une ou plusieurs spécifications qui fournissent de telles descriptions. (Le type d’adresse "rfc822" est défini dans la [RFC3461].) Les formulaires d’enregistrement pour les types d’adresse et les types de nom de MTA apparaissent dans la [RFC3464].

Une MDN décrit la disposition d’un message après sa livraison à un receveur. Dans tous les cas, l’agent d’utilisateur qui fait rapport (reporting-UA) est le MUA qui a effectué la disposition décrite dans la MDN. Ce champ est facultatif, mais recommandé. Pour les agents d’utilisateur de messagerie Internet, il est recommandé que ce champ contienne à la fois le nom DNS de l’instance de MUA qui a généré la MDN, et le nom du produit. Par exemple,

Si le MUA rapporteur consiste en plus d’un composant (par exemple, un programme de base et des instructions de connexion) cela peut être indiqué en incluant une liste des noms de produit.

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

Pour les passerelles d’entrée dans la messagerie Internet, le MTA-name-type va normalement être "smtp", et le mta-name sera le nom de domaine Internet de la passerelle.

Le champ Original-Recipient indique l’adresse du receveur d’origine comme spécifiée par l’envoyeur du message pour lequel la MDN est produite. Pour les messages de la messagerie Internet, la valeur du champ Original-Recipient est obtenue de l’en-tête Original-Recipient du message pour lequel la MDN est générée. Si il n’y a pas d‘en-tête Original-Recipient dans le message, le champ Original-Recipient DOIT alors être omis, sauf si la même information est fiablement disponible d’une autre façon. Si il y a un en-tête Original-Recipient dans le message original (ou si les informations sur le receveur d’origine sont disponibles de façon fiable par d’autres moyens) le champ Original-Recipient doit alors être fourni. Si il y a plus d’en en-tête Original-Recipient dans le message, le MUA peut choisir celui qu’il va utiliser, ou agir comme si aucun en-tête Original-Recipient n’était présent.

original-recipient-field = "Original-Recipient" ":" address-type ";" generic-address

Le champ address-type indique le type de l’adresse du receveur d’origine. Si le message a été généré dans l’Internet, le champ address-type va normalement être "rfc822", et l’adresse se conformera à la syntaxe spécifiée dans la [RFC2822]. La valeur "inconnu" devrait être utilisée si le MUA rapporteur ne peut pas déterminer le type de l’adresse du receveur d’origine à partir de l’enveloppe du message.

Cette adresse est la même que celle fournie par l’envoyeur et peut être utilisée pour corréler automatiquement les rapports de MDN avec les messages d’origine receveur par receveur.

Le champ Final-Recipient indique le receveur pour lequel la MDN est produite. Ce champ DOIT être présent.

Le sous-champ Generic-Address du champ Final-Recipient DOIT contenir l’adresse de la boîte aux lettres du receveur (à partir de l’en-tête From de la MDN) comme elle était lorsque la MDN a été générée par le MUA.

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 franchissements de passerelles en une mixture totalement méconnaissable. Cependant, en l’absence du champ facultatif Original-Recipient, le champ Final-Recipient et tout contenu retourné peuvent être les seules informations disponibles avec lesquelles corréler la MDN avec un receveur de message particulier.

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 avoir le type d’adresse "rfc822".

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 de l’adresse DOIT être préservée.

Le champ Original-Message-ID indique l’identifiant de message du message pour lequel la MDN est produite. Il est obtenu de l’en-tête Message-ID du message pour lequel la MDN est produite. Ce champ DOIT être présent si le message d’origine contenait un en-tête Message-ID. La syntaxe de ce champ est la suivante :

Le champ Disposition indique l’action effectuée par le MUA rapporteur au nom de l’utilisateur. Ce champ DOIT être présent.

disposition-field = "Disposition" ":" disposition-mode ";" type-de-disposition [ "/" disposition-modificateur *( "," disposition-modificateur ) ]

Le disposition-mode, type-de-disposition, et disposition-modificateur peuvent être épelés dans toute combinaison de caractères majuscules et minuscules.

"action-manuelle" La disposition décrite par le type de disposition est le résultat d’une instruction explicite de l’utilisateur plutôt que d’une sorte d’action effectuée automatiquement.

"action-automatique" La disposition décrite par le type de disposition est le résultat d’une action automatique, plutôt que d’une instruction explicite de l’utilisateur pour ce message.

"action-manuelle" et "action-automatique" s’excluent mutuellement. L’un ou l’autre DOIT être spécifié.

"MDN-envoyée-manuellement" L’usager donne explicitement la permission d’envoi de cette MDN particulière.

"MDN-envoyée-automatiquement" La MDN a été envoyée parce que le MUA avait été configuré antérieurement à faire automatiquement ainsi.

"MDN-envoyé-manuellement" et "MDN-envoyé-automatiquement" s’excluent mutuellement. L’un ou l’autre DOIT être spécifié.

"affiché" Le message a été affiché par le MUA pour quelqu’un qui lit la boîte aux lettres du receveur. Il n’est pas garanti que le contenu ait été lu ou compris.

"supprimé" Le message a été supprimé. Le receveur peut ou non avoir vu le message. Le receveur peut "dé-supprimer" le message ultérieurement et le lire.

Des modificateurs de disposition pourront être définis à l’avenir par des révisions ou extensions ultérieures de la présente spécification. Les noms de valeur de disposition commençant pas "X-" ne seront jamais définis comme valeurs standard ; de tels noms sont réservés pour les utilisations expérimentales. Les noms de valeur de disposition de MDN qui NE commencent PAS par "X-" DOIVENT être enregistrés auprès de l’IANA et décrits dans une RFC en cours de normalisation ou expérimentale approuvée par l’IESG. (Voir à la Section 10 un formulaire d’enregistrement.) Les MDN qui ont des noms de modificateur de disposition non compris par le MUA receveur PEUVENT être ignorées en silence ou placées dans la boîte aux lettres de l’utilisateur sans interprétation particulière. Elles NE DOIVENT PAS causer l’envoi d’un message d’erreur à l’envoyeur de la MDN.

Si un développeur de MUA ne souhaite pas enregistrer la signification de telles extensions de modificateur de disposition, des modificateurs "X-" peuvent être utilisés à cette fin. Pour éviter les collisions de noms, le nom de la mise en œuvre de MUA devrait suivre le schéma "X-", (par exemple, "X-Foomail-").

Il n’est pas exigé qu’un MUA soit capable de générer toutes les valeurs possibles du champ Disposition.

Un agent d’utilisateur NE DOIT PAS produire plus d’une MDN au nom de chaque receveur particulier. C’est-à-dire qu’une fois qu’une MDN a été produite au nom d’un receveur, aucune autre MDN ne peut être produite au nom de ce receveur, même si une autre disposition est effectuée sur le message. Cependant, si un message est transmis, une MDN "d’expédition" peut être produite pour le receveur qui fait la transmission et le receveur du message transmis peut aussi causer la génération d’une MDN.

Les champs Échec, Erreur, et Avertissement sont utilisés pour fournir des informations supplémentaires sous la forme de messages textuels lorsque le type de disposition "échec", le modificateur de disposition "erreur", et/ou le modificateur de disposition "avertissement" apparaissent. Leur syntaxe est la suivante :

Des champs de MDN supplémentaires peuvent être définis à l’avenir par des révisions ou extensions ultérieures de la présente spécification. Les noms des champs d’extension qui commencent par "X-" ne seront jamais définis comme champs standard ; de tels noms sont réservés pour une utilisation expérimentale. Les noms de champ MDN qui NE commencent PAS par "X-" DOIVENT être enregistrés auprès de l’IANA et décrits dans une RFC en cours de normalisation ou une RFC expérimentale approuvée par l’IESG. (Voir le formulaire d’enregistrement à la Section 10.)

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

(a) Pour permettre que des information supplémentaires provenant de rapports de disposition étrangers soient tunnelés à travers les MDN de l’Internet. Les noms de tels champs de MDN 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 spécifiques d’un agent d’utilisateur de messagerie (MUA) particulier. Le nom de tels champs de MDN devrait commencer par une indication de la mise en œuvre de MUA qui a produit la MDN (par exemple, Foomail-information).

Si un développeur d’application ne souhaite pas enregistrer la signification de tels champs d’extension, les champs "X-" peuvent être utilisés à cette fin. Pour éviter des collisions de noms, le nom de l’application mise en œuvre devrait suivre le schéma "X-", (par exemple, "X-Foomail-Log-ID" ou "X-Foomail-EDI-info").

La chronologie suivante montre lorsque les divers événements prennent place dans le traitement d’un message et la génération des MDN :

-- Le MUA passe le message au MTA (receveur original des informations transmises).

-- Le MTA final livre le message au MUA (en générant éventuellement une DSN).

-- Le MUA effectue le traitement automatique et génère les types de disposition de MDN correspondantes ("expédié", "traité", "supprimé", "refusé", ou "échec" avec les modes de disposition "action-automatique" et "MDN-envoyée-automatiquement").

-- L’usager choisit un message et demande qu’une certaine action soit effectué sur lui.

-- Le MUA effectue l’action demandée et, avec la permission de l’utilisateur, envoie une MDN appropriée (type de disposition "affiché", "expédié", "traité", "supprimé", "refusé", ou "échec", avec le mode de disposition "action-manuelle" et "MDN-envoyée-manuellement" ou "MDN-envoyée-automatiquement").

-- L’usager effectue éventuellement d’autres actions sur le message, mais aucune autre MDN n’est générée.

Un MUA ou passerelle sera conforme à la présente spécification si il génère des MDN selon le protocole défini dans le présent mémoire. Il n’est pas nécessaire qu’il soit capable de générer toutes les valeurs possibles du champ Disposition.

Les MUA et les passerelles NE DOIVENT PAS générer le champ Original-Recipient d’une MDN sauf si les protocoles de messagerie fournissent l’adresse spécifiée à l’origine par l’envoyeur au moment de la soumission. Le SMTP ordinaire ne garantit pas cela, mais l’extension à SMTP définie dans la [RFC3461] permet que de telles informations soient portées dans l’enveloppe si elles sont disponibles. L’en-tête Receveur-d’origine défini dans le présent document donne un moyen pour que le MTA passe l’adresse du receveur original au MUA.

Chaque adresse de receveur spécifiée par l’envoyeur peut résulter en plus d’une MDN. Si une MDN est demandée pour un receveur qui est transmis sur plusieurs receveurs d’un "alias" (comme défini au paragraphe 6.2.7.3 de la [RFC3461]) chacun des receveurs peut produire une MDN.

La réussite de la distribution d’un message à un exploseur de liste de diffusion DEVRAIT être considérée comme la disposition finale du message. Un exploseur de liste de diffusion PEUT produire une MDN avec un type de disposition de "traité" et les modes de disposition de "action-automatique" et "MDN-envoyée-automatiquement" qui indiquent que le message a été transmis à la liste. Dans ce cas, la demande de MDN n’est pas propagée aux membres de la liste.

Autrement, l’exploseur de liste de diffusion PEUT ne produire aucune MDN et propager la demande de MDN à tous les membres de la liste. Ce comportement n’est pas recommandé sauf pour de petites listes étroitement liées, car cela peut causer la génération d’un grand nombre de MDN et peut causer la divulgations d’abonnés à la liste qui auraient voulu que leur adhésion reste confidentielle. L’exploseur de liste de diffusion PEUT aussi diriger les MDN sur lui-même, les corréler, et produire un rapport à l’envoyeur d’origine du message.

La présente spécification ne met aucune restriction au traitement des MDN reçues par les agents d’utilisateur ou les listes de diffusion.

Les considérations pour la sécurité suivantes s’appliquent lors de l’utilisation des MDN:

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

Les menaces pour la sécurité qui se rapportent à la falsification de MDN incluent l’envoi de :

(a) notification de disposition falsifiée alors que la disposition indiquée du message ne s’est en fait pas produite,

Une autre dimension de la sécurité est la confidentialité. Il peut y avoir des cas où le receveur d’un message ne souhaite pas que la disposition des messages qui lui sont adressés soit connue, il craint que l’envoi de MDN puisse révéler d’autres informations sensibles (par exemple, quand le message a été lu). Dans cette situation, il est acceptable que le MUA produise des MDN "refusé" ou d’ignorer en silence les demandes de MDN.

Si l’en-tête Disposition-Notification-To est passé non modifié lorsque un message est distribué aux abonnés à une liste de diffusion, les abonnés à la liste peuvent être révélés à l’envoyeur du message d’origine par la génération des MDN.

Les en-têtes du message original retournés dans la partie 3 du multipart/report pourraient révéler des informations confidentielles sur les noms d’hôtes et ou la topologie d’un réseau derrière un pare-feu.

Une MDN non chiffrée pourrait révéler des informations confidentielles sur un message non chiffré, en particulier si tout ou partie du message original est retourné dans la partie 3 du multipart/report. Les MDN chiffrées ne sont pas définies dans la présente spécification.

En général, tout champ facultatif de MDN peut être omis si le site ou l’usager du MUA rapporteur détermine que l’inclusion du champ imposera 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 MDN.

Dans certains cas, quelqu’un qui a accès au flux de messages peut utiliser le mécanisme de demande de MDN pour surveiller les habitudes de lecture des messages par une cible. Si la cible est connue pour générer des rapports de MDN, on peut ajouter un champ disposition-notification-to contenant l’enveloppe de l’adresse avec une route de source. La route de source est ignorée dans la comparaison de sorte que les adresses vont toujours correspondre. Mais si la route de source est respectée lorsque la notification est envoyée, cela peut diriger le message sur une autre destination. Ce risque peut être minimisé en supprimant l’envoi automatique des MDN.

Les MDN ne fournissent pas de non répudiation avec preuve de livraison. Dans le cadre de la messagerie Internet d’aujourd’hui, les MDN définies dans le présent document fournissent des information précieuses à l’utilisateur de la messagerie ; cependant, les MDN ne peuvent pas constituer une garantie qu’un message a été vu ou non par le receveur. Même si les MDN ne sont pas activement falsifiés, elles peuvent être perdues dans le transit. Le receveur peut outrepasser d’une certaine manière le mécanisme de production des MDN.

Le mécanisme de demande de MDN introduit une façon supplémentaire de bombarder une boîte aux lettres avec des messages. La notification de demande de MDN donne une adresse à laquelle devraient être envoyées les MDN. Il est possible à un agent agresseur d’envoyer un ensemble éventuellement grand de messages à des receveurs tiers sans soupçons avec une adresse falsifiée de "disposition-notification-to:". Un traitement automatique, ou simpliste de telles demandes va résulter en une inondations de notifications de MDN à la cible de l’attaque. Une telle attaque pourrait submerger la capacité de la boîte aux lettres visée et lui dénier le service.

Pour cette raison, les MDN NE DEVRAIENT PAS être envoyées automatiquement lorsque l’adresse "disposition-notification-to:" est différente de l’adresse MAIL FROM de l’enveloppe. Voir un exposé plus complet au paragraphe 2.1.

Note : Les jetons lexicaux suivants sont définis dans la [RFC2822] : atome, CRLF, mailbox, msg-id, texte. Les définitions des attributs et valeurs sont dans la définition de l’en-tête Content-Type dans la [RFC2045].

Disposition-Notification-Options = "Disposition-Notification-Options" ":" disposition-notification-parameters

original-recipient-header = "Original-Recipient" ":" address-type ";" generic-address

original-recipient-field = "Original-Recipient" ":" address-type ";" generic-address

disposition-field = "Disposition" ":" disposition-mode ";" disposition-type [ "/" disposition-modifier *( "," disposition-modifier ) ]

Note : Cette section fait des recommandations non obligatoires pour la construction de passerelles de messagerie qui souhaitent fournir des notifications de disposition semi transparentes entre l’Internet et un autre système de messagerie électronique. Les exigences spécifiques de passerelle MDN 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 MDN pour convoyer le contenu d’une notification de disposition "étrangère" sur la messagerie Internet. Lorsque il y a des transpositions appropriées pour les éléments de la notification étrangère dans les champs de MDN, les informations peuvent être transmises dans ces champs de MDN. Des informations supplémentaires (comme celles qui pourraient être nécessaires pour tunneler la notification étrangère à travers l’Internet) peuvent être définie dans les champs d’extension de la MDN. (De tels champs devraient recevoir des noms qui identifient le protocole de messagerie étrangère, par exemple, X400-* pour les éléments de protocole X.400).

La passerelle doit tenter de fournir des valeurs raisonnables pour les champs UA rapporteur, Receveur final, et Disposition. Elles seront normalement obtenues en traduisant les valeurs de la notification étrangère en leur équivalent en style Internet. Cependant, on peut s’attendre à certaines pertes d’information.

L’adresse de receveur spécifiée par l’envoyeur et l’identifiant de message d’origine, si elles sont présentes dans la notification étrangère, devraient être préservées dans les champs Original-Recipient et Original-Message-ID.

La passerelle devrait aussi tenter de préserver l’adresse du receveur "final" donnée dans le système étranger. Chaque fois que possible, les éléments du protocole étranger devraient être codés comme des chaînes ASCII imprimables ayant une signification.

Pour les MDN produites à partir de notifications de disposition étrangères, le nom de la passerelle DOIT apparaître dans le champ MDN-Gateway de la MDN.

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

En général, le receveur de la MDN (c’est-à-dire, l’envoyeur du message d’origine) va vouloir savoir, pour chaque receveur, la plus proche approximation disponible de l’adresse du receveur original, et la disposition (affiché, imprimé, etc.).

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

Si il est possible de tunneler une MDN à travers l’environnement de destination, la spécification de la passerelle peut définir un moyen de préserver les informations de la MDN dans le rapport de disposition utilisé par cet environnement.

Par l’utilisation d’en en-tête de demande séparé de disposition-notification-to, la présente spécification offre une fonctionnalité plus riche que la plupart, sinon tous, les autres systèmes de messagerie électronique. Dans la plupart des autres systèmes de messagerie électronique, le receveur de la notification est identique à l’envoyeur du message tel qu’indiqué dans l’adresse "from". Il y a deux cas intéressants lors du passage dans de tels systèmes:

1) Si l’adresse dans l’en-tête disposition-notification-to est identique à l’adresse du "MAIL FROM" SMTP, le comportement attendu va se produire, même si les informations du disposition-notification-to sont perdues. Les systèmes devraient propager la demande de MDN.

2) Si l’adresse dans l’en-tête disposition-notification-to est différente de celle du "MAIL FROM" SMTP, le passage dans un système étranger sans une adresse de notification séparée va résulter en un comportement imprévu. Ceci est particulièrement important lorsque le message arrive via un logiciel d’expansion de liste de diffusion qui peut spécifiquement remplacer l’adresse "MAIL FROM" SMTP par une autre adresse. Dans un tel cas, la demande de MDN ne devrait pas être passée et devrait être abandonnée en silence. Ceci est cohérent avec les autres formes de non prise en charge de MDN.

Note : Cet exemple n’est fourni qu’à titre d’illustration, et n’est pas considéré comme faisant partie de la spécification du protocole de MDN. Si l’exemple est en conflit avec la définition du protocole ci-dessus, c’est l’exemple qui est faux.

De même, l’utilisation des noms de sous-champs *-type ou de champs d’extension dans cet exemple n’est pas à prendre comme une définition pour ces noms de type ou de champs d’extension.

C’est une MDN produite après qu’un message a été affiché chez l’utilisateur d’un agent d’utilisateur de messagerie Internet.

Content-Type: multipart/report; report-type=disposition-notification; boundary="RAA14128.773615765/example.com"

Le message envoyé le 19 septembre 1995 à 13:30:00 (EDT) -0400 à Joe Recipient <Joe_Recipient@example.com> avec l’objet "Premier projet de rapport" a été affiché. Il n’est pas garanti que le message ait été lu ou compris.

Le présent document spécifie trois types de paramètres qui doivent être enregistrés auprès de l’IANA.

Les formulaires ci-dessous sont à utiliser lors de l’enregistrement d’un nouveau nom de paramètre pour l’en-tête Disposition-Notification-Options, d’un nouveau nom de modificateur de disposition, ou d’un nouveau champ d’extension de MDN. Chaque élément d’information exigé par un formulaire d’enregistrement peut être rempli 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 à cause de formulaires d’enregistrement incomplets ou de spécifications incomplètes.

Pour enregistrer, compléter le formulaire applicable suivant et l’envoyer par message électronique à <IANA@IANA.ORG>.

Un enregistrement pour un nom de paramètre d’en-tête de Disposition-Notification-Options DOIT inclure les informations suivantes :

(b) La syntaxe des valeurs du paramètre, spécifiée en utilisant le BNF, l’ABNF, des expressions régulières, ou un autre langage non ambigu.

(c) Si les valeurs du paramètre 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 en-tête Disposition-Notification-Options.

(d) Une référence à une RFC en cours de normalisation ou à une RFC expérimentale approuvée par l’IESG qui décrit la sémantique des valeurs du paramètre.

Un enregistrement pour un nom de modificateur de disposition (utilisé dans le champ Disposition d’un message/disposition-notification) DOIT inclure les informations suivantes:

(b) Une référence à une RFC en cours de normalisation ou à une RFC expérimentale approuvée par l’IESG qui décrit la sémantique du modificateur de disposition.

Un enregistrement pour un nom de champ d’extension de MDN DOIT inclure les informations suivantes :

(b) La syntaxe des valeurs d’extension, spécifiées en utilisant le BNF, l’ABNF, des expressions régulières, ou un autre langage non ambigu.

(c) Si les valeurs de champ d’extension ne sont pas composées entièrement de caractères graphiques tirés du répertoire US-ASCII, une spécification de la façon dont elles doivent être codées comme caractères graphiques US-ASCII dans un en-tête Disposition-Notification-Options.

(d) Une référence à une RFC en cours de normalisation ou à une RFC expérimentale approuvée par l’IESG qui décrit la sémantique du champ d’extension.

Le présent document est une version mise à jour du document écrit à l’origine par Roger Fajman. Sa contributions à la définition des notifications de disposition de message a été très appréciée.

La RFC 2298 se fondait sur le document de notifications d’état de livraison [RFC3464] de Keith Moore et Greg Vaudreuil. Des contributions ont été faites par les membres du groupe de travail Reception de l’IETF, incluant Harald Alvestrand, Ian Bell, Urs Eppenberger, Claus Andri Faerber, Ned Freed, Jim Galvin, Carl Hage, Mike Lake, Keith Moore, Paul Overell, Pete Resnick, et Chuck Shih.

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

[RFC2634] P. Hoffman, éd., "Services de sécurité améliorés pour S/MIME", juin 1999. (MàJ par RFC5035) (P.S.)

Les dispositions "refusé", et "échec" ont été retirées du document pour refléter le manque de mise en œuvre ou d’usage pour l’instant.

Les modificateurs de disposition "warning" (avertissement), "superseded" (remplacé), "expired" (expiré), "mailbox-terminated" (boîte aux lettres close) n’ont pas connu de réelle mise en œuvre. Ils ont été supprimés du présent document. Le modificateur d’extension, non encore utilisé à ce jour, a été conservé pour une extension future.

Un nettoyage rédactionnel général incluant l’orthographe, la grammaire, et la cohérence de l’usage des termes.

Le document a un BNF modifié pour les options de notification de disposition pour éliminer le besoin de valeurs fictives lorsque elles n’étaient pas nécessaires par ailleurs.

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org.

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

Groupe de travail Réseau	T. Hansen, éd., AT&T Laboratories
Request for Comments : 3798	G. Vaudreuil, éd., Lucent Technologies
RFC rendue obsolète : 2298	mai 2004
RFC mises à jour : 3461, 2046
Catégorie : En cours de normalisation	Traduction Claude Brière de L’Isle

Tony Hansen	Gregory M. Vaudreuil
AT&T Laboratories	Lucent Technologies
Middletown, NJ 07748	7291 Williamson Rd
USA	Dallas, TX 75214
téléphone : +1-732-420-8934	USA
mél : tony+rfc3798@maillennium.att.com	téléphone : +1 214 823 9325
	mél : GregV@ieee.org