Résumé

  • Dans RFC 2180, une suppression réussie pouvait retirer le nom d’une boîte tout en laissant les sessions déjà sélectionnées continuer à l’utiliser.
  • Les réponses OK, NO, BYE, les résultats partiels et les valeurs de forme NIL décrivaient des étapes différentes ; le client devait réconcilier l’état au lieu de supposer une vision globale immédiate.

Un nom absent n’était pas encore une donnée absente

RFC 2180 part d’une scène très concrète. Deux clients ont sélectionné FOO. Le premier demande sa suppression. Le serveur peut refuser parce que la boîte est occupée. Il peut aussi accepter, masquer FOO aux nouveaux clients et conserver une copie « fantôme » jusqu’à la fermeture de la dernière session. Ou il peut accepter puis expulser les autres clients avec BYE.

Ces choix ne racontent pas la même opération. Le refus préserve la continuité, au risque de rendre une boîte très fréquentée pratiquement indestructible. La conservation fantôme permet au travail en cours de finir, mais retarde l’effacement et bloque le recyclage immédiat du nom. La déconnexion rend la suppression plus nette, au prix de la session.

Le renommage montre une autre séparation. Si seul l’attribut de nom change, une session qui avait déjà sélectionné la boîte peut continuer un FETCH, qui ne cite pas son ancien nom. Un APPEND FOO échoue, éventuellement avec l’indication NEWNAME. Le répertoire et le contenu ont évolué selon deux rythmes.

La sécurité se trouve précisément dans cet intervalle. Le RFC avertit que la conservation fantôme peut être indésirable lorsqu’une boîte contient des informations offensantes ou sensibles dont on souhaite supprimer immédiatement l’accès. Le protocole n’autorise donc pas à traduire automatiquement « nom supprimé » par « accès révoqué partout ».

L’EXPUNGE était réel avant de pouvoir être annoncé

Les numéros de séquence IMAP sont des positions courantes. Après l’expunge d’un message, les positions suivantes se décalent. Or RFC 2060 ne permet pas d’envoyer une réponse EXPUNGE au milieu de certaines réponses à FETCH, STORE ou SEARCH. Un client peut donc travailler avec une carte devenue ancienne sans avoir encore reçu l’événement qui l’explique.

RFC 2180 admet plusieurs réactions. Le serveur peut garder le message expungé assez longtemps pour satisfaire un FETCH. Il peut renvoyer seulement les messages encore présents puis conclure par NO. Il peut associer des données normales aux messages survivants, des réponses de forme NIL aux messages disparus, puis terminer par OK. Il peut enfin refuser l’expunge tant que la boîte a plusieurs lecteurs.

La réponse NIL rend l’incertitude visible. Une liste de drapeaux vide peut être une vraie valeur vide ou le substitut d’un message disparu. Le client qui doit trancher émet NOOP, provoque l’envoi des EXPUNGE en attente, corrige sa carte et décide s’il faut relancer la commande.

Même un STORE.SILENT suivi de OK ne dit pas que chaque numéro demandé existait encore. Il peut seulement confirmer que tous les messages non expungés de l’ensemble ont été modifiés. La réussite porte sur le travail encore exécutable, pas sur l’intégrité historique de l’ensemble initial.

Une seule commande pouvait recevoir une référence stable

COPY bénéficie d’une règle bornée. Les numéros de séquence sont interprétés au début de la commande. S’ils changent avant sa fin, une copie réussie doit néanmoins contenir les messages identifiés au départ. Si la commande échoue, le serveur doit restaurer la boîte de destination.

Ce gel ne transforme pas la boîte en photographie. Il stabilise le sens d’une commande pendant son exécution. La commande suivante peut rencontrer un autre état, et les autres sessions peuvent déjà avoir une autre carte.

Une pratique historique, pas un certificat contemporain

La notice du RFC Editor classe RFC 2180 comme document informatif. Il précise qu’il ne définit pas la conformité et n’énumère pas tous les comportements valides ; RFC 2060 reste la référence. Il consigne des pratiques de certains serveurs et des comportements jugés raisonnables par la liste IMAP.

Il ne prouve donc ni le comportement d’un service actuel, ni un taux de déploiement, ni une faiblesse d’un produit nommé. Son apport historique est l’allocation des responsabilités : la souplesse du serveur n’est interopérable que si le client implémente l’ensemble des réponses permises.

RFC 2177 a ensuite rendu les mises à jour non sollicitées plus immédiates grâce à IDLE. RFC 7162 a ajouté les mod-sequences, VANISHED et QRESYNC. Ces mécanismes réduisent le coût de la réconciliation ; ils ne font pas d’un OK la preuve d’une réalité simultanément commune.

La leçon reste nette : l’achèvement d’une commande, la présence d’un nom, l’accès d’une session et la destruction des octets sont quatre constats. Un protocole robuste ne les confond pas, et un client robuste ne les déduit pas les uns des autres.