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