Type de support Multipart/Report pour le rapport de messages administratifs de système de messagerie

RésuméLe type de support multipart/report des extensions multi-objet de messagerie Internet (MIME, Multipurpose Internet Mail Extensions) est une "famille" générale ou type de "conteneur" pour les rapports de messagerie électronique de toutes sortes. Bien que le présent mémoire ne définisse que l’utilisation du type de support multipart/report par rapport aux rapports d’état de livraison, les programmes de traitement de messagerie tireront parti du fait qu’un seul type de support soit utilisé pour toutes les sortes de rapports.

Le présent mémoire rend obsolète la RFC3462 "Type de contenu Multipart/Report pour faire rapport des messages administratifs de systèmes de messagerie", et marque la RFC3462 et ses prédécesseurs comme "Historique".

Statut du présent mémoire

Ceci est un document Internet en cours de normalisation.

Le présent document a été produit par l’équipe d’ingénierie de l’Internet (IETF, Internet Engineering Task Force). Il représente le consensus de la communauté de l’IETF. Il a subi une révision publique et sa publication a été approuvée par le groupe de pilotage de l’ingénierie de l’Internet (IESG, Internet Engineering Steering Group). Des informations complémentaires sur les normes de l’Internet sont disponibles à la Section 2 de la RFC5741.

Des informations sur le statut actuel du présent document, les errata, et comment fournir des retours sur lui peuvent être obtenues à http://www.rfc-editor.org/info/rfc6522.

Notice de droits de reproduction

Copyright (c) 2012 IETF Trust et la personne identifiée comme auteur du document. Tous droits réservés.

Le présent document est soumis aux dispositions légales du BCP 78 et de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication du présent document. Prière de se reporter attentivement à ces documents, car ils décrivent les droits et restrictions à l’égard de ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD tel que décrit dans la Section 4.e des disposition légales et sont fournis sans garantie, comme décrit dans la licence BSD simplifiée.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiés ou rendue publiquement disponibles avant le 10 novembre 2008. La ou les personnes qui contrôlent les droits de reproduction de tout ou partie de ce matériel peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de tels matériels en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériels, le présent document ne peut pas être modifié en dehors des processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors des processus de normalisation de l’IETF, excepté pour le formater pour publication comme RFC ou pour le traduire dans des langages autres que l’anglais.

Table des Matières

1. Introduction

2. Conventions du document

3. Type de support Multipart/Report

4. Type de support text/rfc822-headers

5. Enregistrement de nouveaux types de rapport

6. Considérations relatives à l’IANA

7. Considérations pour la séurité

8. Références

8.1 Références normatives

8.2 Références pour information

Appendice A. Remerciements

1. Introduction

La [RFC3462] et ses antécédents déclaraient le type de support multipart/report à utiliser au sein de la construction de la [RFC2045] pour créer un conteneur pour les rapports administratifs de systèmes de messagerie de diverses sortes.

L’expérience pratique a montré que l’exigence générale que l’utilisation d’un type de support soit restreinte au type MIME le plus externe d’un message est trop restrictive et constitue une entrave à des choses comme la transmission de plusieurs rapports administratifs au sein d’une seul conteneur de message global. En particulier, il empêche de transmettre un rapport au titre d’un autre message MIME multi-parties.

Le présent mémoire supprime cette contrainte. Aucun autre changement n’est fait à part certaines modifications rédactionnelles. D’autres mémoires pourront mettre à jour d’autres documents pour établir ou préciser les contraintes sur l’utilisation de multipart/report dans les contextes où ils sont nécessaires.

Le présent mémoire rend obsolète la RFC3462. La RFC3462 et son antécédent, la RFC1892, ont été déclarées "Historique".

2. Conventions du document

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la [RFC2119].

3. Type de support Multipart/Report

Le type de support MIME multipart/report est une "famille" générale ou type de "conteneur" pour les rapports de messagerie électronique de toutes sortes. Bien que le présent mémoire ne définisse que l’utilisation du type de support multipart/report par rapport aux rapports d’état de livraison, les programmes de traitement de messagerie tireront parti de l’utilisation d’un seul type de support pour toutes les sortes de rapports.

Selon la [RFC4288], le type de support multipart/report est défini comme suit :

Nom du type : multipart

Nom du sous-type : report

Paramètres exigés : boundary, report-type

Paramètres facultatifs : aucun

Considérations de codage : 7bit DEVRAIT toujours être adéquat

Considérations de sécurité : voir la Section 7 de la [RFC6522]

Considérations d’interopérabilité : voir la Section 1 de la [RFC6522]

Spécification publiée : [RFC6522]

Applications qui utilisent ce type de support : Agents de transfert de messagerie, Agents d’utilisateur de messagerie, modules de détection et de rapport de pourriels, modules de détection de virus, et modules d’authentification de message.

Informations supplémentaires :

Numéros magiques : Non applicable (N/A)

Extensions de fichier : N/A

Codes de type de fichier Macintosh : N/A

Adresse personnelle et de messagerie du contact pour informations complémentaires : Murray S. Kucherawy à <msk@cloudmark.com>

Usage de destination : commun

Restrictions d’usage : aucune ; cependant, d’autres applications qui enregistrent des types de rapport PEUVENT établir de telles restrictions.

Auteur : Murray S. Kucherawy < msk@cloudmark.com >

Contrôleur des changements : IESG

La syntaxe de multipart/report est identique à celle du type de contenu multipart/mixed défini dans la [RFC2045]. Le paramètre report-type identifie le type de rapport. Le paramètre est le sous-type MIME de la seconde partie de corps de multipart/report. (Voir la Section 5.)

Le type de support multipart/report contient deux ou trois sous-parties , dans l’ordre suivant :

1. (EXIGÉ) La première partie de corps contient un message lisible par l’homme. L’objet de ce message est de fournir une description facilement compréhensible de la ou des conditions qui ont causé la génération du rapport, pour un lecteur humain qui pourrait n’avoir pas d’agent d’utilisateur capable d’interpréter la seconde section du multipart/report. Le texte de la première section peut utiliser tout type de support, jeu de caractères, ou langage MIME enregistré par l’IANA. Lorsque une description de l’erreur est désirée dans plusieurs langages ou plusieurs supports, une construction multipart/alternative PEUT être utilisée. Cette partie de corps PEUT aussi être utilisée pour envoyer des informations détaillées qui ne peuvent pas être facilement formatées dans la second partie du corps.

2. (EXIGÉ) Une partie de corps analysable par la machine qui fait mention de l’événement de traitement du message dont il est fait rapport. L’objet de cette partie de corps est de fournir une description lisible par la machine de la ou des conditions qui ont causé la génération du rapport, ainsi que les détails absents de la première partie de corps qui pourraient être utiles pour des experts humains. Une partie de corps initial, message d’état de livraison, est définie dans la [RFC3464].

3. (FACULTATIF) Une partie de corps contenant le message retourné ou une portion de celui-ci. Ces informations pourraient être utiles pour aider les experts humains à diagnostiquer les problèmes. (Bien qu’elle puisse aussi être utile pour permettre à l’envoyeur pour identifier le message à propos duquel le rapport a été produit, on espère que l’identifiant d’enveloppe et l’adresse du receveur d’origine retournés dans la partie de corps du message/rapport vont remplacer l’utilisation traditionnelle du contenu retourné à cette fin.)

Le retour du contenu peut être un gaspillage de la bande passante du réseau et diverses stratégies de mise en œuvre peuvent être utilisées. Généralement, l’envoyeur a besoin de choisir la stratégie appropriée et d’informer le receveur du niveau exigé de contenu retourné nécessaire. En l’absence d’une demande explicite du niveau de retour du contenu comme celui fourni dans la [RFC3461], l’agent qui a généré le rapport du service de livraison DEVRAIT retourner tout le contenu du message.

Lorsque des données à 8 bits ou binaires non codées en format à 7 bits sont à retourner, et qu’il n’est pas garanti que le chemin de retour est capable de 8 bits ou binaire, deux options sont disponibles. Le message original PEUT être recodé en un message MIME légal à 7 bits ou le type de support text/rfc822-headers PEUT être utilisé pour ne retourner que les en-têtes du message original.

4. Type de support text/rfc822-headers

Le type de support text/rfc822-headers fournit un mécanisme pour étiqueter et ne retourner que l’en-tête de la [RFC5322] d’un message défaillant. L’en-tête n’est pas le message complet et NE DEVRAIT PAS être retourné en utilisant le type de support message/rfc822 défini dans la [RFC2046]. L’en-tête retourné est utile pour identifier le message défaillant et pour faire des diagnostics sur la base des champs d’en-tête reçus.

Le type de support text/rfc822-headers est défini comme suit :

Nom du type : text

Nom du sous-type : rfc822-headers

Paramètres exigés : Aucun

Paramètres facultatifs : Aucun

Considérations de codage : 7 bits sont suffisants pour les en-têtes de messagerie normaux, cependant, si les en-têtes sont cassés ou étendus et exigent un codage pour en faire un contenu à 7 bits légal, ils PEUVENT être codés avec des caractères imprimables entre guillemets comme défini dans la [RFC2045].

Considérations pour la sécurité : Voir la Section 7 de la [RFC6522].

Considérations d’interopérabilité : Aucune

Spécification publiée : [RFC6522]

Applications qui utilisent ce type de support : Agents de transfert de messagerie, Agents d’utilisateur de messagerie, modules de détection et de rapport de pourriels, modules de détection de virus, et modules d’authentification de message.

Informations supplémentaires :

Numéros magiques : Non applicable (N/A)

Extensions de fichier : N/A

Codes de type de fichier Macintosh : N/A

Adresse personnelle et de messagerie à contacter pour d’autres informations : Murray S. Kucherawy à < msk@cloudmark.com >

Utilisation prévue : courante

Restrictions d’usage : aucune

Auteur : Murray S. Kucherawy <msk@cloudmark.com>

Contrôleur des changements : IESG

La partie de corps text/rfc822-headers DEVRAIT contenir tous les champs d’en-tête de messagerie provenant du message qui a causé le rapport. L’en-tête comporte tous les champs d’en-tête avant la première ligne blanche dans le message. Cela inclut les champs MIME-Version et description de contenu MIME.

5. Enregistrement de nouveaux types de rapport

L’enregistrement de nouveaux types de support pour les besoins de la création d’un nouveau format de rapport DEVRAIT noter dans la section Utilisation prévue d’un enregistrement de type que le type enregistré convient pour l’utilisation comme type de rapport (c’est-à-dire, la seconde partie de corps) dans le contexte de la présente spécification.

6. Considérations relatives à l’IANA

L’IANA a mis à jour le registre des types de support pour indiquer que le présent mémoire contient la définition actuelle des types de support multipart/report et text/rfc822-headers, rendant obsolète la [RFC3462].

7. Considérations pour la sécurité

L’utilisation automatisée de types de rapport sans authentification soulève plusieurs problèmes de sécurité. Falsifier des rapports négatifs présente l’opportunité d’attaques de déni de service lorsque les rapports sont utilisés pour la maintenance automatisée de répertoires ou de listes de diffusion. Falsifier des rapports positifs peut être cause que l’envoyeur croit à tort qu’un message a été livré alors qu’il ne l’a pas été.

Une signature couvrant la structure multipart/report toute entière pourrait être utilisée pour empêcher de telle falsifications ; un tel schéma de signature sort néanmoins du domaine d’application du présent document.

8. Références

8.1 Références normatives

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

[RFC2046] N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 2 : Types de support", novembre 1996. (D. S., MàJ par 2646, 3798, 5147.)

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

[RFC4288] N. Freed et J. Klensin, "Spécifications du type de support et procédures d'enregistrement", BCP 13, décembre 2005.

[RFC5322] P. Resnick, éd., "Format du message Internet", octobre 2008. (Remplace RFC2822) (MàJ RFC4021) (D.S.)

8.2 Références pour information

[RFC3461] K. Moore, "Extension de service du protocole simple de transfert de messagerie (SMTP) pour les notifications d'état de livraison (DSN)", janvier 2003. (MàJ par RFC3798, RFC3885, RFC5337) (D.S.)

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

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

Appendice A. Remerciements

L’auteur tient à remercier Dave Crocker, Frank Ellermann, Ned Freed, Randall Gellens, Alexey Melnikov, et Keith Moore de leurs apports à cette mise à jour.

Merci aussi à Gregory M. Vaudreuil, le créateur original de ce type de support.

Adresse de l’auteur

MurrPEUT S. Kucherawy (éditeur)

Cloudmark

128 King St., 2nd Floor

San Francisco, CA 94107

US

téléphone : +1 415 946 3800

mél : msk@cloudmark.com