Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

RFC 6851: Internet Message Access Protocol (IMAP) - MOVE Extension

Date de publication du RFC : Janvier 2013
Auteur(s) du RFC : A. Gulbrandsen, N. Freed (Oracle)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF imapmove
Première rédaction de cet article le 29 janvier 2013


Le protocole d'accès aux boîtes aux lettres IMAP, normalisé dans le RFC 3501, ne prévoyait pas officiellement de moyen de déplacer un message d'une boîte à une autre. Il fallait que le client IMAP réalise une série de commandes à la place, et le déplacement n'était donc pas atomique. Plusieurs serveurs IMAP avaient mis en œuvre une commande atomique non officielle, MOVE, et ce RFC la normalise.

Avant ce RFC, en effet, la meilleure méthode officielle pour déplacer un message d'une boîte IMAP à une autre était un COPY (copier le message vers la nouvelle boîte), puis STORE (marquer le message comme devant être détruit), suivis d'un EXPUNGE (détruire les messages marqués). Plusieurs logiciels clients avaient ce service, pour que l'utilisateur puisse déplacer un message. Le problème est que ce n'était pas atomique. Par exemple, si le serveur IMAP redémarrait entre le COPY et le STORE, le message était dupliqué, et se retrouvait dans les deux boîtes. Sans même supposer un redémarrage, IMAP permet un accès simultané par plusieurs clients et le second client peut alors voir la boîte dans un état invalide (message copié mais pas encore détruit de l'ancienne boîte). Enfin, certains serveurs ont un mécanisme efficace pour déplacer un message sans copier les données (pensez à un serveur Unix qui stocke chaque message dans son fichier et peut donc faire un rename() facilement) et il était donc souhaitable de permettre son utilisation.

Bref, la section 3 décrit la nouvelle commande, MOVE, qui prend comme argument les numéros des messages à déplacer et le nom de la nouvelle boîte (il y a aussi un UID MOVE qui désigne les messages par leur identificateur, l'UID, et pas par leur numéro dans une séquence). À noter que, comme MOVE prend comme argument un groupe de messages, l'atomicité n'est garantie que pour chaque message (soit il est déplacé, soit il ne l'est pas, il ne peut pas être dupliqué), pas pour le groupe (certains messages peuvent être déplacés et d'autres pas).

Comme toute extension d'IMAP, MOVE est annoncé dans les capacités du serveur, au début de la connexion (les capacités possibles sont dans un registre IANA).

La section 4 décrit les interactions de MOVE avec d'autres extensions IMAP. Par exemple, les quotas du RFC 2087 (MOVE peut réussir là où un COPY aurait échoué, s'il y a un quota actif), ou bien les ACL du RFC 4314 (pour déplacer un message, il faut avoir le droit d'écrire dans la nouvelle boîte, et de détruire dans l'ancienne). Pendant qu'on parle de sécurité, le RFC rappelle aussi (section 6) qu'un MOVE peut avoir des interactions avec certaines politiques de stockage dans les boîtes (par exemple, si l'antispam met les spams dans une boîte nommée SPAM, un MOVE hors de cette boîte n'est pas innocent).

Il parait qu'il existe déjà plusieurs mises en œuvre de MOVE, aussi bien dans des clients que dans des serveurs IMAP. Mais je ne connais pas lesquelles. J'ai testé avec des Courier et des Zimbra récents et ils ne semblent pas avoir cette extension. Pour Dovecot, c'est annoncé pour la 2.2.


Téléchargez le RFC 6851

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)