Format de message extensible pour les réponses de suivi de message

Statut de ce mémoire

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.

Notice de copyright

Copyright (C) The Internet Society (2004).

Résumé

On s’attend à ce que le suivi de message (Message Tracking) soit utilisé pour déterminer sur demande l’état de la messagerie non livrée. Le suivi est utilisé en conjonction avec les notifications de livraison de message (DSN, Delivery Status Notification) et les notifications de disposition de message (MDN, Message Disposition Notification) ; généralement, une demande de suivi de message ne va être produite que lorsque une DSN ou MDN n’a pas été reçue dans un délai raisonnable.

Le présent mémoire définit un type de contenu MIME pour l’état de suivi de message dans le même esprit que celui de la RFC3464, "Format de message extensible pour les notifications d’état de livraison de message". Il sera produit sur demande comme décrit dans le "Protocole d’interrogation de suivi de message". Le présent mémoire ne définit que le format des informations d’état. Une extension à SMTP pour étiqueter les messages pour un suivi ultérieur et demander l’état du suivi est défini dans un mémoire distinct

1. Introduction

On suppose que le suivi de message sera utilisé pour déterminer sur demande l’état des messages électroniques non livrés. Le suivi est utilisé en conjonction avec les notifications d’état de livraison (DSN, Delivery Status Notification) [RFC3461] et les notifications de disposition de message (MDN, Message Disposition Notification) [RFC3798] ; généralement, une demande de suivi de message ne sera produite que lorsque une DSN ou MDN n’a pas été reçue dans un délai raisonnable.

Le présent mémoire définit un type de contenu MIME [RFC2045] pour l’état de suivi de message dans le même esprit que celui de la RFC3464, "Format de message extensible pour les notifications d’état de livraison" [RFC3464]. Il est destiné à être produit à la demande, comme décrit dans le "protocole d’interrogation de suivi de message" [RFC3887]. Le présent mémoire ne définit que le format des informations d’état. Une extension à SMTP [RFC1869] pour étiqueter les messages pour un suivi ultérieur et demander l’état du suivi est défini dans un autre mémoire [RFC3885].

2. Autres documents et conformité

Le modèle utilisé pour le suivi de message est décrit dans la [RFC3888].

Le suivi de message est destiné à être utilisé comme mécanisme de "dernier recours". Normalement, les notifications d’état de livraison (DSN, Delivery Status Notification) [RFC3461] et les notifications de disposition de message (MDN, Message Disposition Notification) [RFC3798] vont fournir le principal état de livraison. C’est seulement si aucune réponse n’est reçue de l’un et l’autre de ces mécanismes que le suivi de message sera utilisé.

Le présent document se fonde sur la [RFC3464]. Les paragraphes 1.3 (Terminologie), 2.1.1 (Conventions générales pour les champs DSN), 2.1.2 (sous-champs "*-type"), et 2.1.3 (Jetons lexicaux importés de la RFC822) de la [RFC3464] sont inclus par référence dans le présent document. D’autres sections sont aussi incorporées comme décrit ci-dessous.

La notation de la syntaxe de ce document se conforme à la [RFC2234].

Les jetons lexicaux suivants, définis dans la [RFC2822], sont utilisés dans la grammaire ABNF pour les MTSN : atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text. Le jeton lexical date-time est défini dans la [RFC1123].

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

3. Format d’une notification d’état de suivi de message

Une notification d’état de suivi de message (MTSN, Message Tracking Status Notification) est destinée à être retournée comme corps d’une demande de suivi de message [RFC3887]. Le corps réel DOIT être un multipart/related [RFC2387] avec un paramètre de type de "message/tracking-status" ; chaque sous-partie DOIT être du type "message/tracking-status" comme on le décrit ici. Le corps multipart/related peut inclure plusieurs parties message/tracking-status si un serveur du protocole d’interrogation de suivi de message (MTQP, Message Tracking Query Proocol) enchaîne les demandes pour les passer au serveur suivant ; voir la [RFC3888] et la [RFC3887] pour plus d’informations sur le chaînage.

3.1 Type de contenu d’état de suivi de message

Le type de contenu d’état de suivi de message est défini comme suit :

Nom de type MIME : message

Nom de sous-type MIME : tracking-status

Paramètres facultatifs : aucun

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

Considérations pour la sécurité : voir la section 4 de ce mémoire.

Le corps d’un état de suivi de message est modélisé d’après la [RFC3464]. Ce corps consiste en un ou plusieurs "champs" formatés conformément à l’ABNF des champs d’en-tête de la [RFC2822]. Les champs par message apparaissent en premier, suivis par une ligne blanche. À la suite des champs par message sont un ou plusieurs groupes de champs par receveur. Chaque groupe de champs par receveur est précédé d’une ligne blanche. Noter qu’il y aura une ligne blanche entre le champ par receveur final et la limite MIME, car un CRLF est nécessaire pour terminer le champ, et un second est nécessaire pour introduire la limite MIME. Formellement, la syntaxe du contenu d’état de suivi de message est le suivant :

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

Les champs par message sont décrits au paragraphe 3.2. Les champs par receveur sont décrits au paragraphe 3.3.

3.1.1 Conventions générales pour les champs MTSN

Le paragraphe 2.1.1 (Conventions générales pour les champs de DSN) de la [RFC3464] est inclus ici par référence. Notamment, la définition de xtext est identique à celle de ce document.

3.1.2 Sous champs *-type

Le paragraphe 2.1.2 (Sous-champs *-type) de la [RFC3464] est inclus ici par référence. Notamment, les définitions de type d’adresse (address-type), type de diagnostic (diagnostic-type), et de type de nom de MTA (MTA-name) sont identiques à celles de la RFC3464.

3.2 Champs MTSN par message

Certains champs d’une MTSN s’appliquent à toutes les adresses dans une seule enveloppe. Ces champs peuvent apparaître au plus une fois dans une MTSN. Ces champs sont utilisés pour corréler la MTSN avec la transaction de message d’origine et fournir des informations supplémentaires qui pourront être utiles aux passerelles.

champs par message =

champ identifiant d’enveloppe d’origine CRLF

champ mta rapporteur CRLF

champ date d’arrivée CRLF

*( champ d’extension CRLF )

3.2.1 Champ Identifiant d’enveloppe d’origine

Le champ Identifiant d’enveloppe d’origine (Original-Envelope-Id) est défini au paragraphe 2.2.1 de la [RFC3464]. Ce champ est EXIGÉ.

3.2.2 Champ MTA rapporteur

Le champ MTA rapporteur (Reporting-MTA) est défini comme au paragraphe 2.2.2 de la [RFC3464]. Ce champ est EXIGÉ.

3.2.3 Champ Date d’arrivée

Le champ Date d’arrivée (Arrival-Date) est défini comme au paragraphe 2.2.5 de la [RFC3464]. Ce champ est EXIGÉ.

3.3 Champs par receveur MTSN

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

La syntaxe du groupe de champs par receveur est la suivante :

champs par receveur =

champ receveur d’origine CRLF

champ receveur final CRLF

champ action CRLF

champ état CRLF

[ champ mta distant CRLF ]

[ champ date de dernière tentative CRLF ]

[ champ réessais jusqu’à CRLF ]

*( champ d’extension CRLF )

3.3.1 Champ Receveur d’origine

Le champ Receveur d’origine est défini au paragraphe 2.3.1 de la [RFC3464]. Ce champ est EXIGÉ.

3.3.2 Champ Receveur final

Le champ exigé Receveur final est défini comme au paragraphe 2.3.2 de la [RFC3464]. Ce champ est EXIGÉ.

3.3.3 Champ Action

Le champ exigé 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 MTSN. La syntaxe est comme défini dans la RFC3464. Ce champ est EXIGÉ.

Les actions valides sont :

échec (failed) Le message n’a pas pu être délivré. Si les DSN ont été activées, une DSN "failed" aurait déjà dû avoir été retournée.

retardé (delayed) Le message est actuellement en attente dans la file d’attende du MTA pour une livraison ultérieure. Cette action signifie essentiellement "le message est localisé ; et il est ici".

livré (delivered) Le message a bien été livré au receveur final. Cela inclut la "livraison" à un exploseur de liste de diffusion. Cela n’indique pas que le message a été lu. Aucune autre information n’est disponible ; en particulier, l’agent de suivi NE DEVRAIT PAS tenter d’autres demandes de suivi "vers l’aval".

développé (expanded) 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. Cependant, ces adresses supplémentaires ne peuvent faire l’objet de suivi, et l’agent de suivi NE DEVRAIT PAS tenter d’autres demandes de suivi "vers l’aval".

relayé (relayed) Le message a bien été livré dans un environnement qui ne prend pas en charge le suivi de t message. Aucune autre information n’est disponible ; en particulier, l’agent de suivi NE DEVRAIT PAS tenter d’autres demandes de suivi "vers l’aval".

transféré (transferred) Le message a été transféré à un autre MTA conforme au suivi de message (MTRK, Message Tracking). L’agent de suivi DEVRAIT tenter d’autres demandes de suivi "vers l’aval" sauf si ces informations ont déjà été données dans une réponse de chaînage.

opaque Le message peut ou non avoir été vu par ce système. Aucune autre information n’est disponible ni en vue.

Il peut y avoir une certaine confusion entre le moment où utiliser "étendu" ou "livré". Chaque fois que possible, "étendu" devrait être utilisé lorsque le MTA sait que le message sera envoyé à plusieurs adresses. Cependant, dans certains cas, la livraison survient sur un programme qui, à l’insu du MTA, cause l’expansion de la liste de diffusion ; dans le cas extrême, la livraison peut être à une vraie boîte aux lettres qui a comme effet collatéral l’expansion de la liste. Si le MTA ne peut pas s’assurer que cette livraison va causer l’expansion de la liste, il devrait régler l’action à "livré".

3.3.4 Champ État

Le champ État (Status) est défini comme dans la RFC3464. Un nouveau code est ajouté à la [RFC3463], "Codes d’état de système de messagerie améliorée" :

X.1.9 Message relayé à un messageur non conforme"

L’adresse de boîte aux lettres spécifiée était valide, mais le message a été relayé à un système qui ne parle pas ce protocole ; aucune autre information ne pourra être fournie.

A 2.1.9 Le champ État DOIT être utilisé exclusivement avec un champ Action "relayé". Ce champ est EXIGÉ.

3.3.5 Champ MTA distant

Le champ MTA distant (Remote-MTA) est défini comme au paragraphe 2.3.5 de la [RFC3464]. Ce champ NE DOIT PAS être inclus si aucune tentative de livraison n’a été faite ou si le champ Action a la valeur de "opaque". Si la livraison est à un agent autre qu’un MTA (par exemple, un agent de livraison local) ce champ PEUT alors être inclus, en donnant le nom de l’hôte sur lequel cet agent a été contacté.

3.3.6 Champ Date de dernière tentative

Le champ Date de la dernière tentative (Last-attempt-Date) est comme défini au paragraphe 2.3.7 de la [RFC3464]. Ce champ est EXIGÉ si une tentative de livraison a été faite et si le champ Action n’a pas la valeur "opaque", auquel cas il va spécifier quand a été faite la dernière tentative de livraison de ce message à un autre MTA ou à un autre agent de livraison. Ce champ NE DOIT PAS être inclus si aucune tentative de livraison n’a été faite.

3.3.7 Champ Réessai jusqu’à

Le champ Réessai jusqu’à (Will-Retry-Until) est défini comme au paragraphe 2.3.9 de la [RFC3464]. Si le message n’est pas dans la file d’attente locale ou si le champ Action a la valeur "opaque", le champ Réessai jusqu’à NE DOIT PAS être inclus ; autrement, ce champ DEVRAIT être inclus.

3.4 Champs d’extension

De futurs champs d’extension pourront être définis comme indiqué au paragraphe 2.4 de la [RFC3464].

3.5 Interaction entre les MTA et les LDA

Un message qui a été livré à un agent de livraison local (LDA, Local Delivery Agent) qui comprend le suivi de message (en particulier, un LDA qui parle LMTP [RFC2033] qui prend en charge l’extension de MTRK) DEVRAIT passer la demande de suivi au LDA. Dans ce cas, le champ Action pour l’échange MTA->LDA va ressembler à un transfert à un MTA conforme ; c’est-à-dire qu’un état de suivi de "transféré d" sera produit.

4. Considérations sur la sécurité

4.1 Falsification

Des serveurs malveillants peuvent tenter de subvertir le suivi de message et retourner de fausses informations. Il peut en résulter un détournement ou une mauvaise interprétation des résultats.

4.2 Confidentialité

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 augmenté lorsque des "boîtes aux lettre sans fil", comme des téléphones portables, seront plus largement utilisés 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 un message sera transmis, cela pourrait être réalisé par une ou plusieurs des actions suivantes :

(a) répondre par un état de suivi de "relayé" lorsque un message est transmis à une adresse de transmission confidentielle, et en désactivant les autres demandes de suivi de message.

(b) déclarer que le message est livré, en produisant un état de suivi de "livré", en renvoyant le message à l’adresse de transmission confidentielle, et en désactivant les autres demandes de suivi de message.

Les algorithmes de suivi NE DOIVENT PAS permettre le suivi à travers les expansions de liste. Lorsque un message est livré à une liste, une demande de suivi DOIT répondre par un état de suivi de "développé " et NE DOIT PAS afficher le contenu de la liste.

5. Considérations relatives à l’IANA

L’IANA a enregistré l’extension SMTP définie à la Section 3.

6. Remerciements

Plusieurs individus ont commenté et amélioré le présent document, parmi lesquels Tony Hansen, Philip Hazel, Alexey Melnikov, Lyndon Nerenberg, Chris Newman, Gregory Neil Shapiro, et Dan Wing.

7. Références

7.1 Références normatives

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

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

[RFC2234] D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", novembre 1997. (Obsolète, voir RFC5234)

[RFC2387] E. Levinson, "Type de contenu MIME Multiparti/Relatif", août 1998. (P.S.)

[RFC2822] P. Resnick, "Format de message Internet", avril 2001. (Remplace la RFC0822, STD 11, Remplacée par RFC5322)

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

[RFC3885] E. Allman, T. Hansen, "Extension de service SMTP pour le suivi de message", septembre 2004. (P.S.)

[RFC3887] T. Hansen, "Protocole d'interrogation de suivi de message", septembre 2004. (P.S.)

[RFC3888] T. Hansen, "Modèle et exigences du suivi de message", septembre 2004. (Information)

7.2 Références pour information

[RFC1869] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "Extensions de service à SMTP", novembre 1995. (Obsolète, voir RFC5321, STD0010)

[RFC2033] J. Myers; "Protocole de transfert de messagerie locale", octobre 1996. (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, RFC6533) (D.S.)

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

[RFC3798] T. Hansen et G. Vaudreuil, éd., "Notification de disposition de message", mai 2004. (MàJ par RFC5337, RFC6533) (D.S.)

8. Adresses de l’auteur

Eric Allman

Sendmail, Inc.

6425 Christie Ave, 4th Floor

Emeryville, CA 94608

U.S.A.

téléphone : +1 510 594 5501

Fax: +1 510 594 5429

mél : eric@Sendmail.com

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

Copyright (C) The Internet Society (2004).

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.

Propriété intellectuelle

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.

Remerciement

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