Résumé

  • Avec RESERVE, RFC 3656 retirait un nom de l’espace disponible, sans pour autant déclarer la boîte prête pour les clients.
  • La réponse MAILBOX décrivait l’état actif, après création locale et ACTIVATE. La séquence était recommandée, mais reposait sur des participants coopératifs plutôt que sur une précondition imposée par le serveur.

D’abord le nom, ensuite la boîte

Un groupe de serveurs de messagerie doit répondre à deux questions différentes : quel serveur détient ce nom, et la boîte peut-elle être utilisée maintenant ? RFC 3656, protocole expérimental publié en décembre 2003, distinguait ces deux réponses. MUPDATE proposait un espace de noms commun aux serveurs IMAP et POP3 tout en répartissant la responsabilité de distribution.

La création typique commençait par RESERVE. Le client demandait au maître de retenir un nom à un emplacement donné. Après le retour OK, il créait la boîte localement puis envoyait ACTIVATE, avec le nom, l’emplacement et l’ACL. L’activation réussie rendait l’enregistrement actif. L’emplacement aidait à orienter le client vers le serveur qui stockait la boîte ; l’ACL décrivait ses droits d’accès.

Les réponses marquaient nettement la différence. RESERVE signifie que le nom n’est plus disponible pour un autre demandeur, mais RFC 3656 précise que la boîte n’est pas nécessairement accessible aux clients à ce moment-là. MAILBOX désigne, lui, une entrée prête à être utilisée. Confondre ces messages transforme un verrou d’espace de noms en faux signal de disponibilité : l’objet local peut ne pas encore exister, ou sa création peut ne pas être terminée.

L’atomicité reposait sur une discipline commune

MUPDATE décrivait un maître unique détenant la base faisant autorité, ainsi que des esclaves qui en recevaient les mises à jour. Les recherches pouvaient passer par l’un ou l’autre ; les changements de base étaient dirigés vers le maître. La création traversait donc deux surfaces : le registre distribué des noms et le stockage local des boîtes. Le protocole les coordonnait sans les réunir dans une transaction atomique unique.

Le vocabulaire normatif rend cette limite visible. Les nouvelles boîtes SHOULD être réservées avant activation, car le modèle suppose que les participants authentifiés coopèrent pour préserver l’atomicité. Pourtant ACTIVATE n’exige pas de réservation préalable. La spécification autorise ce cas pour faciliter la synchronisation avec l’emplacement réel des boîtes. Un participant qui ignore la convention de verrouillage peut donc contribuer à une base incohérente. La base ne peut pas déduire une transaction locale qui ne lui a jamais été signalée.

DEACTIVATE faisait passer un nom actif à l’état réservé ; il ne supprimait pas le nom de l’espace de noms. RFC 3656 avertissait aussi que les ACL connues pouvaient être perdues lors de ce changement. Pendant une migration ou une création interrompue, le nom peut rester revendiqué sans boîte active annoncée. L’emplacement enregistré ne prouve pas qu’un client s’est connecté ni qu’il a lu un message.

Le OK d’une réplique avait une limite

Après UPDATE, l’esclave recevait une liste initiale, puis les changements ultérieurs. Le maître devait transmettre une modification dans les 30 secondes suivant son apparition. L’esclave pouvait envoyer NOOP ; après UPDATE, la réponse OK devait attendre que toutes les mises à jour en attente au moment du NOOP lui aient été envoyées. C’était un point de synchronisation borné, pas la promesse que la base resterait à jour après la réponse.

Cette confirmation reste utile mais étroite : elle établit que le flux en attente a été transmis à cette réplique à un instant précis. Elle ne prouve ni la réception d’une modification ultérieure, ni le bon état du stockage local, ni l’accès d’un utilisateur. RFC 3656 est expérimental ; il documente un contrat de coordination proposé, pas les déploiements actuels ou une disponibilité mesurée.

Sources