Résumé

  • La réponse positive à DELE validait une intention limitée à la transaction en cours. Le message restait présent et RSET pouvait encore lever toutes les marques.
  • Seul QUIT émis depuis l’état TRANSACTION conduisait à UPDATE. Une rupture, un processus mort ou l’expiration d’inactivité ne valait pas autorisation de supprimer.
  • UPDATE n’était pas un commit atomique : RFC 1939 admettait qu’une pénurie de ressources laisse supprimés certains messages marqués et conserve les autres.

Le mot « supprimé » précédait l’acte

POP3 présente un piège de lecture presque parfait. Le client envoie DELE 4; le serveur répond que le message 4 est supprimé. Pourtant, RFC 1081 distinguait dès 1988 la réponse à la commande et l’effet irréversible.

Après authentification, le serveur ouvrait le maildrop, obtenait au besoin un verrou d’accès exclusif et numérotait la vue courante. DELE désignait l’une de ces positions. La réponse positive faisait entrer le numéro dans l’ensemble marqué : toute nouvelle commande visant ce numéro devait échouer. Elle ne retirait pas encore l’objet du stockage.

Cette réserve rendait RSET possible. Tant que la session restait en TRANSACTION, le client pouvait demander la levée de toutes les marques. On ne restaure pas ici un message effacé ; on retire une intention avant son exécution.

Le protocole séparait donc trois choses que l’interface pouvait confondre : le numéro utilisable dans la vue ouverte, la marque destructive attachée à cette vue, puis l’effacement réel. Le premier +OK ne prouvait que la deuxième.

Le verrou protégeait le sens des numéros

Le verrou du maildrop n’était pas une formalité d’authentification. Il empêchait que des messages soient modifiés ou retirés avant UPDATE, afin que les positions utilisées par LIST, RETR et DELE conservent leur objet pendant la conversation.

Cette cohérence restait locale à la session. À la reconnexion, la boîte pouvait avoir changé et les numéros étaient réattribués. Le verrou ne transformait pas la position 4 en identité durable, ne garantissait pas la conservation indéfinie du courrier et n’effaçait pas les politiques du site.

La répartition des responsabilités était cependant nette. Le client savait si sa copie locale avait été écrite de façon sûre. Le serveur savait quels objets existaient dans le maildrop et possédait le moyen matériel de les retirer. Le protocole laissait le client préparer un ensemble destructif, mais obligeait cet ensemble à franchir une limite explicite avant de produire ses effets.

RFC 1225 puis RFC 1460 ont conservé cette séquence : marquer, éventuellement réinitialiser, entrer dans UPDATE par QUIT, retirer, libérer le verrou, répondre et fermer.

La disparition de la connexion ne donnait aucun mandat

RFC 1725 a formulé en 1994 la garantie qui rend le mécanisme utile : si la session se termine autrement que par un QUIT envoyé par le client, elle n’entre pas dans UPDATE et le serveur ne doit retirer aucun message. Même l’autologout pour inactivité ferme sans réponse et sans suppression.

Cette règle protège une asymétrie concrète. Le serveur peut avoir fini d’émettre les octets d’un message alors que le client ne les a pas encore rendus durables. Une écriture locale peut échouer après la réception réseau. Si une coupure suffisait à déclencher la destruction, l’incident qui empêche de confirmer la copie deviendrait aussi celui qui détruit l’original récupérable.

POP3 exigeait donc un acte dans sa propre grammaire. Un EOF TCP ne remplaçait pas QUIT; un délai expiré ne signifiait pas consentement; le silence ne choisissait pas l’état suivant.

La différence entre QUIT en AUTHORIZATION et en TRANSACTION le montre encore. Dans le premier état, il termine simplement la session. Dans le second, il ouvre UPDATE, parce qu’un maildrop verrouillé et un ensemble de marques existent alors. Le même mot n’exerce pas la même autorité hors de son contexte.

UPDATE bornait l’effet sans promettre le tout-ou-rien

RFC 1939 a ajouté une franchise décisive. Pendant UPDATE, le serveur tente de retirer les messages marqués. Une erreur, notamment un manque de ressources, peut laisser supprimés certains d’entre eux, ou aucun. Le serveur peut répondre -ERR some deleted messages not removed. Il ne peut en aucun cas enlever un message non marqué.

Le périmètre est strict, l’issue ne l’est pas. QUIT ressemble à une demande de commit, mais le protocole ne garantit pas l’atomicité d’une base de données. Trois marques peuvent produire deux retraits et un survivant. Après réussite ou échec, le verrou est libéré et la connexion fermée.

Une deuxième incertitude apparaît si la réponse finale se perd. Le serveur peut avoir exécuté l’effacement avant que le client ne voie +OK; il peut aussi avoir échoué en partie ou ne jamais être entré dans UPDATE. La fermeture TCP ne permet pas de choisir entre ces branches.

Il faut rouvrir le maildrop et réconcilier son état. Un identifiant UIDL, s’il est disponible, aide à reconnaître ce qui subsiste, mais il n’explique pas la cause d’une absence. Un autre client ou une politique de conservation peuvent avoir agi. Répéter aveuglément DELE 4 serait particulièrement dangereux : la nouvelle vue peut attribuer le numéro 4 à un autre message.

EXPIRE pouvait ajouter des marques, pas déplacer l’irréversibilité

RFC 2449 a introduit CAPA et la capacité EXPIRE. Avec EXPIRE 0, le site indique que le courrier ne peut pas rester sur le serveur. Lors de l’entrée dans UPDATE, celui-ci peut considérer chaque message récupéré par RETR comme implicitement marqué par DELE.

Le moment est essentiel. RETR n’efface toujours pas immédiatement. La politique agrandit l’ensemble autorisé au passage dans UPDATE; elle ne transforme ni la réception du corps ni la perte de la connexion en ordre de suppression.

Le registre de services de l’IANA conserve pop3 au port 110. Cette inscription maintient un nom de rendez-vous. Elle ne prouve ni l’usage contemporain, ni la conformité d’un serveur, ni la sécurité du transport.

L’enseignement historique de POP3 tient moins à sa simplicité qu’à la précision de ses preuves. Marqué ne voulait pas dire retiré. Interrompu ne voulait pas dire validé. UPDATE ne voulait pas dire atomique. Et une absence constatée plus tard ne disait pas, à elle seule, qui avait supprimé quoi.

Sources