Résumé

  • Dans la RFC 1460, les messages recevaient des numéros de position quand le serveur ouvrait la boîte. LAST gardait seulement le plus grand numéro accédé, une frontière incapable de représenter une histoire discontinue ou plusieurs mémoires de client.
  • La RFC 1725 supprima LAST et ajouta UIDL. L’identifiant fourni par le serveur persistait entre les sessions dans une seule boîte, laissant au client le soin de mémoriser chaque élément sans transformer POP3 en gestionnaire complet de courrier distant.

Une frontière est une compression séduisante. Si LAST répond 7, le client peut considérer que les messages 8 et suivants n’ont pas encore été consultés. Il n’a besoin de conserver ni liste ni état local détaillé. Le serveur résume le passé par un seul nombre.

Mais le résumé n’est exact que si l’histoire forme un préfixe continu. Supposons que le client ait récupéré les messages 1, 2 et 4, mais pas le 3. Une valeur maximale de 4 efface le trou. Si un second ordinateur utilise le même compte, sa propre histoire ne coïncide pas nécessairement avec celle que le serveur a résumée. Si un message ancien disparaît, les positions suivantes changent.

POP3 était pourtant conçu précisément pour des machines qui n’étaient pas toujours reliées au réseau. Une station de travail peu dotée se connectait à un serveur qui conservait sa boîte, téléchargeait le courrier, puis se déconnectait. Le modèle ordinaire était simple : récupérer puis supprimer.

L’option « laisser les messages sur le serveur » changeait la question. À la prochaine connexion, le client ne devait pas seulement savoir où se trouvait un message dans la liste actuelle. Il devait reconnaître l’entité déjà enregistrée pendant une session antérieure.

La commande UIDL fournit ce pont temporel. Elle associait un numéro utile maintenant à un identifiant destiné à durer après la fermeture de la connexion.

Le numéro naissait à l’ouverture de la boîte

La RFC 1460, publiée en juin 1993, indiquait qu’après avoir découpé la boîte en messages, le serveur donnait le numéro 1 au premier, 2 au deuxième et n au nième. Le document employait alors l’expression « message-id », mais la valeur était une position décimale, pas l’en-tête global Message-ID d’un courrier.

La commande LAST renvoyait le plus grand numéro accédé lors des transactions précédentes. RETR ou DELE appliqué à une position plus élevée avançait cette valeur. RSET annulait les marques de suppression et remettait aussi le plus grand numéro à zéro.

Cette interaction montre la nature de l’état. LAST ne nommait pas les messages ; il mémorisait jusqu’où une progression avait été observée sous un certain ordre. Un reset pouvait l’effacer. Une seule valeur devait servir à toutes les formes d’accès. Les éléments au-dessous de la frontière étaient implicitement homogènes, même si l’usage réel ne l’était pas.

La RFC 1725 rendit la transition explicite dans la liste de ses modifications de novembre 1994 : elle retira LAST et ajouta la commande facultative UIDL. Le texte n’affirme pas que l’une fut l’unique cause de l’autre. Il montre cependant un changement de modèle : un repère global disparut au profit d’une identité fournie pour chaque message.

Deux colonnes portaient deux temporalités

UIDL accepte éventuellement un numéro de message. Avec cet argument, le serveur rend le numéro actuel et l’identifiant unique correspondant. Sans argument, il donne une réponse multiligne pour chaque message de la boîte qui n’est pas marqué comme supprimé.

Le numéro reste l’opérande de la transaction présente. Le client l’utilise pour RETR ou DELE. L’identifiant permet de comparer cette ligne avec son registre local après une déconnexion.

La RFC 1939 définit l’identifiant comme une chaîne arbitraire choisie par le serveur, longue d’un à soixante-dix caractères imprimables. Il distingue un message dans une boîte donnée et persiste entre les sessions. Cette persistance est obligatoire même si la session précédente s’est terminée sans entrer dans l’état UPDATE.

Cette précision protège un cas ordinaire de réseau imparfait. Le client peut avoir reçu et stocké un message, puis perdre la connexion avant QUIT. POP3 interdit alors au serveur de supprimer les messages marqués, puisque l’échec ne valide pas UPDATE. Le message réapparaît à la session suivante. Si son UID changeait parce que la fermeture fut anormale, le client pourrait le télécharger de nouveau ou appliquer une politique destructive à partir d’une mémoire devenue fausse.

Le serveur ne devrait pas réutiliser l’identifiant dans la même boîte tant que l’entité qui le porte existe. La règle empêche qu’un nouvel élément se présente comme un ancien aux yeux du registre client.

Un identifiant unique pouvait encore désigner deux copies identiques

Le mot « unique » reste strictement borné. La RFC 1939 préfère que le serveur stocke des identifiants attribués arbitrairement, mais lui permet de les calculer comme une empreinte du message. Elle exige alors que les clients sachent gérer deux copies identiques possédant le même UID dans une seule boîte.

L’identifiant ne garantit donc pas une ligne physique unique. Un client qui transforme immédiatement son registre en dictionnaire « un UID, un objet » peut éliminer silencieusement une copie réelle. Il doit conserver la multiplicité actuelle de la liste en plus de la reconnaissance temporelle.

L’UID n’est pas non plus mondial. La même chaîne dans une autre boîte ou sur un autre serveur n’a aucune relation spécifiée. Elle ne prouve ni l’auteur, ni le destinataire, ni la livraison, ni l’intégrité cryptographique. Elle n’est pas interchangeable avec l’en-tête Message-ID.

La portée réduite est la force du mécanisme. Le serveur n’a pas besoin de prétendre posséder une identité universelle. Il fournit seulement assez de continuité pour que ce client reconnaisse les entités de cette boîte entre deux visites.

Persister ne voulait pas dire conserver indéfiniment

La durée de l’identifiant et la durée de stockage sont différentes. La RFC 1939 avertit que les messages déjà lus peuvent s’accumuler sans limite lorsque les clients les laissent sur le serveur. Un opérateur peut imposer quota et politique de rétention, y compris supprimer des messages en dehors des commandes POP3.

Un UID ancien n’est donc pas un reçu de garde. S’il disparaît, le client doit distinguer suppression par un autre acteur, expiration locale, réponse incomplète et erreur de session. L’engagement de persistance vaut pendant l’existence de l’entité, pas comme obligation de garder l’entité.

La RFC 2449 ajouta ensuite CAPA. Jusqu’alors, les fonctions facultatives devaient être découvertes par tentative ou réglage manuel. La capacité UIDL annonce que la commande est disponible. Elle ne mesure ni la qualité de l’espace d’identifiants ni la durée de conservation.

Le même document introduisit EXPIRE pour signaler une rétention minimale, zéro ou NEVER. Même EXPIRE ne donne pas l’heure exacte de disparition d’un message précis : le serveur peut commencer son calcul à l’arrivée, lors de la première liste, après RETR ou selon une autre règle.

Disponibilité de la commande, identité d’une entité et politique de stockage restèrent ainsi trois preuves séparées.

La simplicité du serveur avait un prix à la périphérie

La philosophie déclarée de POP3 consistait à mettre l’intelligence dans le client plutôt que dans le serveur. UIDL suivait ce partage. Le serveur conservait un token stable et la boîte actuelle ; le client décidait ce que « déjà vu » signifiait pour cet utilisateur et gardait cette mémoire.

L’avantage était un serveur simple et des clients autonomes. Le coût apparaissait lors d’une perte de base locale, d’une migration qui régénérait les UID ou d’une restauration de boîte. Tout le courrier retenu pouvait sembler nouveau. Une optimisation devenait une tempête de téléchargements ou, pire, une suppression fondée sur une reconnaissance erronée.

UIDL ne synchronisa pas une boîte complète. Il remplaça une frontière qui oubliait les trous par une série d’identités assez stables pour que le client conserve sa propre histoire. Le numéro appartenait à la visite. L’identifiant survivait assez longtemps pour relier les visites.

Sources