Groupe de travail Réseau	A. Melnikov, ACI Worldwide/MessagingDirect
Request for Comments : 3503 	mars 2003
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Profil de disposition de message (MDN) pour le protocole d'accès au message Internet (IMAP)

Statut de ce mémoire
Le présent document spécifie un protocole en cours de normalisation de l’Internet 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 "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la 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 (2003). Tous droits réservés.

Résumé
La facilité de notification de disposition de message (MDN, Message Disposition Notification) définie dans la [RFC2298] donne un moyen pour qu'un message puisse demander que le traitement du message par le receveur fasse l'objet d'un accusé de réception, ainsi que le format à utiliser pour cet accusé de réception. Cependant, elle ne décrit pas comment les divers agents d'utilisateur de messagerie (MUA, Mail User Agent) devraient traiter la génération des MDN dans l'environnement du protocole d'accès au message Internet (IMAP4, Internet Message Access Protocol).

Le présent document décrit comment traiter les MDN dans cet environnement et donne des lignes directrices pour les mises en œuvre de IMAP4 qui veulent ajouter la prise en charge de MDN à leurs produits.
Table des matières
1. Conventions utilisées dans ce document	1
2. Introduction et vue d'ensemble	2
3. Comportement du client	2
3.1 Comportement du client à réception d'un message	3
3.2 Comportement du client lors de la copie d'un message	3
3.3 Comportement du client à l'envoi d'un message	3
3.4 Comportement du client pour sauvegarder un message temporaire	3
4. Comportement du serveur	3
4.1 Serveur qui prend en charge des mots clés arbitraires	3
4.2 Serveur qui prend en charge seulement le mot clé $MDNSent	4
4.3 Interaction avec l'extension ACL IMAP	4
5. Exemples	4
6. Considérations sur la sécurité	5
7. Syntaxe formelle	5
8. Remerciements	5
9. Références normatives	5
10. Adresse de l'auteur	5
11. Déclaration complète de droits de reproduction	6

 	1.	Conventions utilisées dans ce document

"C:" et "S:" dans les exemples montrent les lignes envoyées respectivement par le client et le serveur.

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

 	2.	Introduction et vue d'ensemble

Le présent mémoire définit un mot clé supplémentaire de messagerie électronique [RFC3501] qui permet à plusieurs agents d'utilisateur de messagerie électronique (MUA, Mail User Agent) de savoir si une notification de réception demandée a été envoyée.

La notification de disposition de message [RFC2298] n'exige pas de prise en charge particulière de IMAP dans le cas où un utilisateur a accès à la mémorisation de messagerie à partir d'un seul ordinateur et a utilisé un seul MUA. Dans ce cas, le MUA se comporte comme décrit dans la [RFC2298], c'est-à-dire, le MUA effectue un traitement automatique et génère les MDN correspondantes, il effectue l'action demandée et, avec la permission de l'utilisateur, envoie les MDN appropriées. Le MUA ne va pas envoyer de MDN deux fois parce que le MUA garde trace des notifications envoyées dans une configuration locale. Cependant, cela ne fonctionne pas quand IMAP est utilisé pour accéder à la même mémorisation de messagerie à partir de différentes localisations, ou utilise des MUA différents.

Le présent document définit un nouveau mot clé de messagerie électronique d'utilisation particulière, $MDNSent, qui doit être utilisé par les MUA. Il ne définit aucune nouvelle commande ou réponse pour IMAP, mais décrit une technique que les MUA devraient utiliser pour réaliser l'interopérabilité.

Quand un client ouvre une boîte aux lettres pour la première fois, il vérifie que le serveur est capable de mémoriser le mot clé $MDNSent en examinant le code de réponse PERMANENTFLAGS. Pour prendre en charge MDN dans IMAP, un serveur DOIT soit prendre en charge le mot clé $MDNSent, soit des mots clés de message arbitraires.

 	3.	Comportement du client

L'utilisation de IMAP exige quelques étapes supplémentaires dans le traitement de la messagerie du côté du client. La chronologie suivante modifie celle de la Section 4 de la [RFC2298].

-- L'utilisateur compose le message.

-- L'utilisateur dit au MUA d'envoyer le message.

-- Le MUA passe le message au MSA (avec les informations originales de receveur). Le MUA [facultativement] sauvegarde le message dans un classeur pour les messages envoyés avec le fanion $MDNSent établi.

-- Le MSA envoie le message au MTA.

-- Le MTA final reçoit le message.

--Le MTA final livre le message au MUA (éventuellement en générant une notification de l'état de livraison (DSN, Delivery Status Notification).

-- Le MUA s'enregistre auprès du serveur IMAP, ouvre la boîte aux lettres, vérifie si la boîte aux lettres peut mémoriser le mot clé $MDNSent en examinant la réponse PERMANENTFLAGS.

-- Le MUA effectue le traitement  automatique et génère les MDN correspondantes de type de disposition ("distribué", "traité", "supprimé", "refusé" ou "échec" avec les modes de disposition "action automatique" et "MDN envoyée automatiquement") pour les messages qui n'ont pas de mot clé $MDNSent, ou le fanion \Brouillon établi. (*)

-- Le MUA établit le mot clé $MDNSent pour chaque message qui exige l'envoi d'une MDN automatique, que la MDN ait été envoyée ou non.

-- Le MUA affiche une liste des messages à l'utilisateur.

-- L'utilisateur choisit un message et demande qu'une action soit effectuée sur lui.

-- Le MUA effectue l'action demandée et, avec la permission de l'utilisateur, envoie la MDN du type de disposition approprié ("affiché", "distribué", "traité", "supprimé", "refusé" ou "échec" avec le mode de disposition "action manuelle" et "MDN envoyée manuellement" ou "MDN envoyée automatiquement"). Si la MDN générée est sauvegardée dans une boîte aux lettres avec la commande APPEND, le client DOIT spécifier le mot clé $MDNSent dans le APPEND.

-- Le MUA établit le mot clé $MDNSent pour tous les messages pour lesquels l'utilisateur a confirmé la distribution de disposition (ou a explicitement interdit de le faire).

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

(*) Note : Le MUA NE DOIT PAS utiliser le fanion \Récent comme indicateur qu'il devrait envoyer une MDN, parce que conformément à la [RFC3501], "Si plusieurs connexions ont la même boîte aux lettres choisie simultanément, il n'est pas défini laquelle de ces connexions va voir les messages nouvellement arrivés avec le fanion \Récent établi et laquelle va les voir sans ce fanion établi". Donc, utiliser \Récent comme indicateur va causer un comportement de client imprévisible avec des serveurs IMAP4 différents. Cependant, le client PEUT utiliser le fanion \Vu comme un des indicateurs que MDN ne doit pas être envoyé. Le client NE DOIT PAS utiliser d'autre fanion standard, comme \Brouillon ou \Répondu, pour indique que la MDN a été envoyée précédemment, parce que ils ont une signification différente bien connue. En tous cas, en présence du mot clé $MDNSent, le client DOIT ignorer tous les autres fanions ou mots clés pour les besoins de la génération d'une MDN et NE DOIT PAS envoyer la MDN.

Quand le client ouvre une boîte aux lettres pour la première fois, il doit vérifier que le serveur prend en charge le mot clé $MDNSent, ou des mots clés de message arbitraires en examinant le code de réponse PERMANENTFLAGS.

Le client NE DOIT PAS essayer d'établir le mot clé $MDNSent si le serveur est incapable de le mémoriser de façon permanente.

Le client DOIT être prêt à ne rien recevoir du serveur par suite de STORE $MDNSent quand le serveur annonce la prise en charge de mots clés arbitraires, parce que le serveur peut limiter le nombre de mots clés de message qu'il peut mémoriser dans une boîte aux lettres particulière. Un client NE DEVRAIT PAS envoyer de MDN si il ne réussit pas à mémoriser le mot clé $MDNSent.

Une fois établi le mot clé $MDNSent, il NE DOIT PAS être défait par un client. Le client PEUT établir le mot clé $MDNSent quand un utilisateur refuse d'envoyer la notification. Cela interdit à tous les autres MUA d'envoyer une MDN pour ce message.

 	3.1	Comportement du client à réception d'un message
Le client NE DOIT PAS envoyer de MDN si un message a le mot clé $MDNSent établi. Il NE DOIT PAS non plus envoyer de MDN si un message a le fanion \Brouillon, parce que certains clients utilisent ce fanion pour marquer un message comme incomplet.

Voir la chronologie de la Section 3 sur les détails du comportement de client à réception d'un message.

 	3.2	Comportement du client lors de la copie d'un message
Le client DEVRAIT vérifier que $MDNSent est préservé lors d'une opération de COPY. De plus, quand un message est copié entre des serveurs avec la commande APPEND, le client DOIT régler le mot clé $MDNSent correctement.

 	3.3	Comportement du client à l'envoi d'un message
Quand il sauvegarde un message envoyé dans un classeur, le client DOIT établir le mot clé $MDNSent pour empêcher un autre client d'envoyer une MDN pour le message.

 	3.4	Comportement du client pour sauvegarder un message temporaire
Quand il sauvegarde un message non terminé dans un classeur quelconque, le client DOIT établir le mot clé $MDNSent pour empêcher un autre client d'envoyer une MDN pour le message.

 	4.	Comportement du serveur

Les mises en œuvre de serveur qui veulent suivre la présente spécification doivent s'assurer que leur serveur se conforme au paragraphe 4.1 ou 4.2. Si le serveur prend aussi en charge l'extension IMAP [RFC2086], il DOIT aussi se conformer au paragraphe 4.3.

 	4.1	Serveur qui prend en charge des mots clés arbitraires
Aucun changement n'est exigé du serveur pour le rendre compatible avec l'extension décrite dans le présent document si il prend en charge les mots clés arbitraires.

 	4.2	Serveur qui prend en charge seulement le mot clé $MDNSent
Les serveurs qui prennent en charge seulement le mot clé $MDNSent DOIVENT le préserver dans l'opération COPY. Il est aussi attendu qu'un serveur qui prend en charge SEARCH <flag> prenne aussi en charge le SEARCH KEYWORD $MDNSent.

 	4.3	Interaction avec l'extension ACL IMAP
Tout serveur qui se conforme aux paragraphes 4.1 ou 4.2 et prend aussi en charge l'extension IMAP [RFC2086], DEVRAIT préserver le mot clé $MDNSent sur COPY même si le client n'a pas de droit d'écriture ('w'). Cela va empêcher la génération d'une MDN dupliquée pour le même message. Noter que le serveur DOIT quand même vérifier si le client a le droit d'effectuer l'opération COPY sur un message conformément à la [RFC2086].

 	5.	Exemples

1) Le MUA ouvre une boîte aux lettres pour la première fois.
a) Le serveur prend en charge la mémorisation de mots clés arbitraires.

   C: a100 select INBOX
   S: * FLAGS (\Flagged \Draft \Deleted \Seen)
   S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen \*)]
   S: * 5 EXISTS
   S: * 3 RECENT
   S: * OK [UIDVALIDITY 894294713]
   S: a100 OK [READ-WRITE] Completed

b) Le serveur prend en charge la mémorisation du mot clé $MDNSent.

   C: a100 select INBOX
   S: * FLAGS (\Flagged \Draft \Deleted \Seen $MDNSent)
   S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen $MDNSent)]
   S: * 5 EXISTS
   S: * 3 RECENT
   S: * OK [UIDVALIDITY 894294713]
   S: a100 OK [READ-WRITE] Completed

2) Le MUA établit avec succès le mot clé $MDNSent.

   C: a200 STORE 4 +FLAGS ($MDNSent)
   S: * 4 FETCH (FLAGS (\Flagged \Seen $MDNSent))
   S: * FLAGS ($MDNSent \Flagged \Deleted \Draft \Seen)
   S: * OK [PERMANENTFLAGS ($MDNSent \Flagged \Deleted \Draft \Seen \*)]
   S: a200 OK STORE completed

3) Le serveur refuse de mémoriser le mot clé $MDNSent.

   C: a200 STORE 4 +FLAGS ($MDNSent)
   S: a200 NO STORE échec : pas d'espace restant pour mémoriser le mot clé $MDNSent.

4) Tous les clients et serveurs DOIVENT traiter le mot clé $MDNSent comme insensible à la casse dans toutes les opérations, comme déclaré dans la [RFC3501].

   C: a300 FETCH 1:* FLAGS
   S: * 1 FETCH (FLAGS (\Seen))
   S: * 2 FETCH (FLAGS (\Answered \Seen $MdnSENt))
   S: * 3 FETCH (FLAGS ())
   S: * 4 FETCH (FLAGS (\Flagged \Seen $MdnSENT))
   S: * 5 FETCH (FLAGS ($MDNSent))
   S: * 6 FETCH (FLAGS (\Recent))
   S: a300 OK FETCH completed
   C: a400 SEARCH KEYWORDS $mdnsent
   S: * SEARCH 2 4 5
   S: a400 OK SEARCH completed

 	6.	Considérations sur la sécurité

IL n'y a aucun problème connu de sécurité avec cette extension, qui ne se trouve dans la [RFC2298] et/ou la [RFC3501].

Le paragraphe 4.3 change les exigences de vérification d'ACL sur un serveur IMAP qui met en œuvre l'extension IMAP [RFC2086].

 	7.	Syntaxe formelle

La spécification de syntaxe suivante utilise la notation de format Backus-Naur augmenté (ABNF) spécifiée dans la [RFC0822], telle que modifiée par la [RFC3501]. Les non terminaux référencés, mais non définis ci-dessous, sont comme définis par la [RFC3501].

Sauf notation contraire, tous les caractères alphabétiques sont insensibles à la casse. L'utilisation de caractères majuscules ou minuscules pour définir les chaînes de jetons sont seulement pour faciliter la lecture. Les mises en œuvre DOIVENT accepter ces chaînes de façon insensible à la casse.

flag_keyword  ::= "$MDNSent" / other_keywords

other_keywords  ::= atome

 	8.	Remerciements

Le présent document est le produit de discussions qui ont eu lieu sur la liste de diffusion IMAP. Des remerciements particuliers sont dus à Cyrus Daboo et Randall Gellens qui on relu le document.

Merci à mon père qui m'a aidé à devenir qui je suis. Tu me manques terriblement.

 	9.	Références normatives

[RFC2086]	J. Myers, "Extension IMAP4 ACL", janvier 1997. (Obsolète, voir RFC4314) (P.S.)

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

[RFC2298]	R. Fajman, "Format de message extensible pour les notifications de disposition de message", mars 1998. (Obsolète, voir RFC3798) (P.S.)

[RFC3501]	M. Crispin, "Protocole d'accès au message Internet - version 4rev1", mars 2003. (P.S. ; MàJ par RFC4466, 4469, 4551, 5032, 5182, 7817, 8314, 8437, 8474)

 	10.	Adresse de l'auteur

Alexey Melnikov
ACI Worldwide/MessagingDirect
59 Clarendon Road
Watford, Hertfordshire
United Kingdom, WD17 1FQ

téléphone : +44 1923 81 2877
mél : mel@messagingdirect.com 

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

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

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus 11.	Adresse des auteurs
sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations contenues sont fournis 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 encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

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