Résumé

  • UIDPLUS a ajouté aux succès d’APPEND et de COPY les références attribuées dans la boîte de destination : sa valeur UIDVALIDITY et les nouveaux UID, seuls ou mis en correspondance dans l’ordre.
  • Cette preuve restait volontairement bornée. Elle pouvait être omise pour protéger une boîte non consultable ou un magasin UIDNOTSTICKY, et UID EXPUNGE ne supprimait que les messages à la fois visés par UID et déjà marqués \Deleted.

Une suppression devait conserver son auteur

Le courrier partagé rend visibles des conflits qu’un poste isolé masque. Un utilisateur peut marquer un message sans vouloir que son collègue le supprime tout de suite. Un client déconnecté peut revenir avec une intention ancienne alors que la boîte a changé. Les numéros de séquence, recalculés lorsque des messages disparaissent, sont impropres à porter longtemps cette intention.

Les UID donnent une référence plus stable, mais la commande classique EXPUNGE reste large : elle retire définitivement tous les messages marqués \Deleted dans la boîte sélectionnée. UID EXPUNGE ajoute un second critère. Pour disparaître, un message doit porter la marque et appartenir à l’ensemble d’UID fourni. L’un sans l’autre ne suffit pas.

Cette intersection paraît modeste. Elle sépare pourtant la décision « ce message peut être supprimé » de la décision « je termine maintenant la suppression de cet ensemble ». Elle permet au client qui se resynchronise de ne pas transformer automatiquement les marques posées par d’autres en actes irréversibles.

Avant cette commande, le repli conseillé consistait à enlever provisoirement \Deleted des messages à préserver, lancer EXPUNGE, puis remettre les marques. Le résultat pouvait être correct, mais il exigeait de modifier davantage d’état partagé. UID EXPUNGE inscrivait directement la limite dans la requête.

Le succès d’APPEND ne nommait pas son produit

Le même problème existait du côté de la création. APPEND place un nouveau message dans une boîte choisie par le serveur. Le client pouvait recevoir un OK tout en ignorant l’UID attribué. Il savait que l’objet avait été créé, mais pas comment le retrouver sans nouvelle exploration.

APPENDUID a transformé la réponse finale en reçu exploitable. Le code fournit l’UIDVALIDITY de la boîte de destination et l’UID créé. Le client peut donc relier son opération locale en attente à une référence distante sans relire toute la boîte ni comparer plusieurs messages similaires.

Il faut conserver les deux nombres avec leur contexte. Un UID n’est pas un nom Internet universel. Il n’a de sens qu’avec le serveur, le nom de boîte et la génération UIDVALIDITY. Lorsque cette génération change, l’ancien UID ne peut pas être traité comme une adresse encore sûre.

Avec plusieurs messages ajoutés par une même commande, APPENDUID peut rendre un ensemble ordonné. Le premier UID correspond au premier message soumis, et ainsi de suite. L’ensemble ne peut ni employer * ni inclure des identifiants étrangers à l’opération. La réponse est donc contrôlable par le client qui connaît sa liste d’entrée.

COPYUID documentait une transformation de noms

COPY ne déplace pas un UID d’une boîte à l’autre. Il crée des exemplaires dans une autre portée, où le serveur leur attribue de nouveaux UID. COPYUID décrit cette transformation : UIDVALIDITY de la destination, ensemble source, ensemble destination.

Les deux ensembles doivent compter le même nombre d’éléments. Leur position fait foi. Le premier UID source correspond au premier UID destination, même si les valeurs ne se ressemblent pas et ne se suivent pas. C’est une relation produite par une commande, pas une ressemblance déduite après coup.

Les numéros de séquence auraient fourni une fondation fragile. Une suppression concurrente peut renuméroter les messages visibles pendant COPY. Les UID restent les références de la commande et la réponse n’a pas le droit d’ajouter des messages étrangers. La correspondance résiste ainsi au changement d’ordre de présentation.

Elle ne résout pas tout. RFC 8474 souligne qu’un autre client, absent lors de COPY ou MOVE, ne peut pas reconstruire cette identité entre boîtes à partir de COPYUID. Les ObjectID ont été définis pour un besoin plus large. Le reçu UIDPLUS reste la preuve remise à l’auteur de l’opération.

Une information exacte pouvait être interdite

Un compte peut avoir le droit de déposer ou copier du courrier vers une boîte sans pouvoir la sélectionner ni l’examiner. Lui rendre UIDVALIDITY et un UID révélerait des informations internes malgré cette séparation de droits. RFC 4315 demande alors au serveur de ne pas envoyer APPENDUID ou COPYUID.

La réponse peut aussi manquer lorsque la destination est UIDNOTSTICKY. Dans un tel magasin, la persistance des UID entre sessions n’est pas garantie. Le standard déconseille cette architecture, mais préfère signaler sa faiblesse plutôt que produire un reçu qui semble durable.

L’absence du code ne transforme pas un OK en échec. Si le client possède ensuite les droits nécessaires, il peut sélectionner la destination et rechercher un marqueur unique qu’il avait placé dans le message. Ce détour mesure la différence entre trois questions : l’opération a-t-elle réussi, puis-je observer la boîte, et le nom attribué va-t-il persister ?

MOVE révélait l’importance de l’ordre

MOVE crée une copie de destination puis retire l’original. Pour UID MOVE, un serveur UIDPLUS devrait communiquer COPYUID. Mais si les réponses EXPUNGE arrivent avant la correspondance, les numéros de séquence source se déplacent avant que le client puisse rattacher les nouveaux noms aux anciens.

RFC 6851 a donc conseillé un OK non étiqueté contenant COPYUID avant les annonces de suppression. IMAP4rev2 a intégré cette discipline. Il ne suffit pas que chaque information soit vraie : elle doit parvenir tant que l’état requis pour l’interpréter reste intelligible.

De l’optimisation à la règle du protocole

RFC 2359 présentait UIDPLUS en 1998 comme une optimisation pour les clients déconnectés. RFC 4315 l’a remplacé en 2005, a précisé les omissions légitimes et introduit UIDNOTSTICKY. L’IANA conserve la capacité dans son registre, et RFC 9051 a incorporé ses mécanismes au cœur d’IMAP4rev2.

Ce parcours montre comment une optimisation devient une discipline de preuve. Le serveur ne promet pas davantage que ce qu’il sait : un résultat de commande, des références dans une génération déterminée et, pour la suppression, une portée explicite. La force du reçu vient de sa juridiction limitée.

Sources et limites

La première définition est RFC 2359, remplacée par RFC 4315. Le contexte IMAP4rev1 se trouve dans RFC 3501, MOVE dans RFC 6851, la limite interclient dans RFC 8474 et l’intégration IMAP4rev2 dans RFC 9051. Le registre IANA confirme la capacité. Ces textes ne mesurent pas son déploiement et ne font pas d’un UID une identité globale.