Résumé

  • DELE ne retire pas immédiatement un message : il le marque dans l’état TRANSACTION, sous verrou exclusif. RSET enlève toutes ces marques avant la sortie normale.
  • Seul QUIT émis par le client depuis TRANSACTION ouvre l’état UPDATE. Une coupure anormale interdit toute suppression, mais UPDATE peut néanmoins n’en réussir qu’une partie.

Le téléphone raccroché ne devait pas valoir consentement

Un ordinateur familial appelle un serveur, télécharge sa boîte et demande que les originaux soient supprimés. Trois réponses positives arrivent. Puis la ligne tombe au moment où le dernier message devait être écrit sur le disque local. Si chaque demande avait déjà détruit sa cible, la panne qui empêchait la conservation locale aurait aussi supprimé la copie distante.

POP3 refuse cette coïncidence. Pendant la phase de travail, DELE exprime une intention : le message devient indisponible pour les commandes suivantes de cette session, mais reste physiquement dans le maildrop. RSET peut annuler l’ensemble des intentions. QUIT est la frontière explicite après laquelle le serveur tente enfin de les réaliser.

Le choix est conservateur sans être mystique. Le serveur sait qu’il a envoyé des octets ; il ne sait pas que le client les a stockés durablement. La fin normale constitue un signal partagé, imparfait mais observable, qu’une disparition silencieuse de la connexion ne peut imiter.

Les premiers POP séparaient déjà réception et perte de la copie

En octobre 1984, RFC 918 proposait RETR pour lire sans effacer et RDEL pour lire avec intention d’effacement. Le client recevait les données puis envoyait RCVD; la suppression n’était tentée qu’après cet accusé. RSET devait interrompre la transaction et libérer correctement la boîte.

La révision POP2, RFC 937, allait plus loin. ACKD confirmait la bonne réception et marquait le message. Le changement réel attendait la libération de la boîte, à la fin de la session ou lors d’une nouvelle sélection.

Ces commandes ont disparu, pas le problème. Sur un réseau intermittent, « le serveur a envoyé » et « le destinataire possède désormais une copie sûre » sont deux événements différents. L’histoire de POP est en partie celle d’une frontière de mieux en mieux formulée entre eux.

Trois états ont donné une forme au délai

RFC 1081, premier texte POP3 en novembre 1988, organise la session en AUTHORIZATION, TRANSACTION et UPDATE. Après authentification, le serveur ouvre le maildrop et prend un verrou exclusif. Le client consulte, récupère et marque dans TRANSACTION. QUIT conduit à UPDATE : le serveur tente les retraits, libère le verrou et ferme TCP.

Cette séparation distribue les pouvoirs. AUTHORIZATION vérifie l’accès. TRANSACTION maintient une vue stable et réversible. UPDATE exerce l’effet irréversible. Un QUIT avant authentification termine simplement la session : il ne peut ouvrir UPDATE puisqu’aucune transaction sur la boîte n’existe.

La numérotation confirme le caractère local de cette vue. Les numéros sont attribués à l’ouverture. Après DELE, les autres commandes considèrent le message comme supprimé, bien que le stockage le conserve encore. Le protocole distingue ainsi l’état logique de la session de l’état physique qui ne changera qu’à la sortie.

RSET était une fonction normale, pas une réparation exceptionnelle

RSET fait partie du noyau obligatoire. Il retire toutes les marques de suppression en TRANSACTION. Un client peut donc revenir sur une décision si le disque local manque de place, si une récupération échoue ou si une politique de conservation a changé. Il n’a pas à émettre l’inverse de chaque commande une par une.

Le verrou exclusif protège cet intervalle de réflexion. RFC 1725 précise qu’il empêche, lorsque nécessaire, la modification ou le retrait des messages avant UPDATE. Sans ce contexte stable, les numéros vus par le client et les marques gardées par le serveur pourraient désigner un ensemble mouvant.

Ce n’est pourtant pas un gestionnaire de transactions général. POP3 n’offre ni consensus distribué, ni annulation après UPDATE, ni journal universel. Il définit une seule zone de réversibilité, étroite et intelligible.

La rupture anormale ferme sans mettre à jour

Les premières versions de POP3 décrivaient le parcours normal plus clairement que la panne. RFC 1725 annonce justement une clarification du comportement sur connexion rompue. Sa règle est nette : toute fin autre qu’un QUIT du client n’entre pas dans UPDATE et ne doit retirer aucun message. Même l’expiration du délai d’inactivité ferme TCP sans effacement.

RFC 1939, devenu STD 53 en 1996, conserve cette obligation et en explique la raison : après une terminaison anormale, le client n’a peut-être pas reçu ou enregistré correctement les messages.

Il ne s’agit pas de prouver l’état du disque client. Une session rompue peut avoir livré toutes ses données; une fin normale ne garantit pas une sauvegarde parfaite. Le protocole choisit le meilleur signal commun disponible et favorise l’erreur réparable. Un doublon au prochain téléchargement est gênant. La disparition de la seule copie ne l’est pas seulement : elle est irréversible.

La frontière de validation n’offrait pas l’atomicité

Appeler QUIT un « commit » aide à comprendre le passage, mais devient faux si l’on importe toutes les garanties d’une base de données. Dans UPDATE, RFC 1939 ordonne au serveur de retirer les messages marqués. En cas de pénurie de ressources ou d’autre erreur, certains, tous ou aucun peuvent effectivement disparaître. Aucun message non marqué ne peut être touché. Le verrou est ensuite libéré et la connexion fermée, succès ou échec.

La frontière est donc ferme avant l’action et imparfaite pendant l’action. Avant QUIT, les marques sont annulables et une rupture les rend inoffensives. Après QUIT, le résultat peut être partiel. Si la dernière réponse se perd, le client ignore aussi quelle fraction a réussi.

Cette franchise est une qualité du protocole. Des serveurs simples et des stockages divers ne pouvaient pas tous promettre un changement tout-ou-rien. La spécification préfère décrire une incertitude récupérable plutôt que baptiser « atomique » un effet qu’elle ne maîtrise pas.

Les politiques ultérieures ont respecté le même passage

Avec le temps, les clients ont laissé davantage de messages sur le serveur. RFC 2449 a défini la capacité EXPIRE pour annoncer la rétention. EXPIRE NEVER indique l’absence de suppression par cette politique; EXPIRE 0 autorise le serveur à considérer comme implicitement marqués les messages récupérés avec succès—mais lorsque la session entre dans UPDATE.

Même une politique plus stricte s’accroche donc à la frontière existante. Elle peut modifier l’ensemble des intentions, pas transformer une coupure en ordre final.

Dire adieu, c’était transférer une autorité limitée

La fin d’un protocole n’est pas toujours une formule de politesse. Ici, elle porte l’autorité destructive. Le client choisit quand ses demandes réversibles peuvent devenir des tentatives physiques. Le serveur demeure responsable du résultat réel. Le réseau peut interrompre les deux, mais son silence ne reçoit jamais le droit de décider à leur place.

Le dispositif tient en cinq verbes : marquer, éventuellement réinitialiser, quitter explicitement, tenter de retirer, avouer l’échec partiel. Sa sobriété explique sa durée. La suppression n’était réelle qu’au moment de l’adieu, et même alors POP3 ne promettait pas que le monde changerait d’un seul bloc.

Sources et limites

La filiation historique provient de RFC 918 et RFC 937. La machine POP3 apparaît dans RFC 1081, puis se poursuit dans RFC 1225 et RFC 1460. RFC 1725 formalise la connexion rompue; RFC 1939 fixe la règle actuelle et l’échec partiel; RFC 2449 décrit EXPIRE. Ces textes ne démontrent ni le déploiement actuel, ni le mécanisme de stockage d’un produit, ni une suppression atomique ou exactement une fois.