Résumé

  • Avec RFC 9738, un serveur IMAP peut terminer par OK après n’avoir traité que la tranche de messages aux UID les plus élevés ; le code MESSAGELIMIT indique la limite atteinte et le dernier UID traité.
  • COPY et MULTIAPPEND restent atomiques et n’exécutent rien au-delà de la limite, alors que FETCH, SEARCH, STORE, MOVE ou UID EXPUNGE peuvent produire des résultats ou des effets partiels réels.
  • La valeur annoncée organise la coopération entre client et serveur ; elle ne prouve ni une application stricte immédiate, ni l’adoption par tous les clients, ni l’exhaustivité de la boîte.

Le scénario de la semaine d’absence vient du cœur même des considérations d’interopérabilité de RFC 9738. Une liste de diffusion active produit environ quinze cents messages. La limite annoncée est de mille. Un ancien client, ignorant l’extension, ne récupère que les mille messages les plus récents et se comporte comme si le serveur était cassé — ou, pire, comme si la vue était complète.

Le danger n’est pas un paquet mal formé. Il est une apparence plausible. Les mille derniers messages forment une chronologie cohérente. Les compteurs peuvent s’additionner. L’interface peut afficher « synchronisé ». Seule la limite de traitement révèle que cinq cents messages n’ont pas encore été examinés.

La limite porte sur une invocation

MESSAGELIMIT=N fixe le nombre maximal de messages qu’une commande peut traiter à la fois : SEARCH, FETCH, STORE, COPY, MOVE et leurs variantes UID, mais aussi APPEND et UID EXPUNGE. SAVELIMIT=N est une annonce plus étroite pour les familles COPY et APPEND. RFC 9738 recommande de ne pas annoncer une valeur inférieure à mille.

N ne décrit pas la taille de la boîte. Ce n’est ni un quota, ni une durée de rétention, ni une taille maximale de message. Pour SEARCH, la limite porte sur le nombre de messages parcourus, pas sur le nombre de réponses qui satisfont le critère. Si mille messages sont lus et que douze correspondent, les douze résultats ne permettent pas de conclure que les messages plus anciens ont été testés.

Lorsqu’il renvoie MESSAGELIMIT, le serveur doit progresser des UID les plus élevés vers les plus faibles. La valeur finale facultative est le plus faible UID traité pendant cette invocation. Elle fournit une couture pour reprendre. Elle n’est pas un instantané, un total ou un engagement sur l’existence future de ce message.

La génération de la boîte compte également. Un UID n’a de sens durable que dans le contexte de la boîte sélectionnée et de son UIDVALIDITY. Une reprise conservée après un changement de génération ne continue pas le même travail : elle applique un ancien repère à un nouvel espace d’identifiants.

Le succès est local au travail effectué

Un FETCH peut renvoyer mille réponses puis terminer avec OK [MESSAGELIMIT 1000 23221]. Le serveur n’a pas menti. Les mille réponses sont les résultats réussis de la commande. Le client n’a pas pour autant épuisé sa demande.

SEARCH suit la même logique. Le résultat contient les correspondances trouvées dans la tranche examinée. STORE peut déjà avoir modifié les indicateurs de mille messages. MOVE peut avoir copié puis supprimé cette tranche de la boîte source. UID EXPUNGE peut avoir définitivement retiré les messages marqués \Deleted dans cette portion.

Ces effets imposent une reprise adaptée à chaque commande. Pour UID STORE, la nouvelle plage doit exclure le plus faible UID déjà traité. UID MOVE peut répéter le même ensemble, car les messages déplacés ne sont plus dans la source. MOVE avec numéros de séquence doit recalculer sa cible : les expunges ont changé les positions. UID EXPUNGE peut reprendre avec le même paramètre UID jusqu’à la disparition du code de limite ou jusqu’à un échec explicite.

Une bibliothèque qui transforme tout cela en un bouton générique « réessayer » perd la sémantique qui protège la boîte. Répéter trop largement peut rejouer une action ; reprendre trop bas peut sauter un intervalle ; traiter un numéro de séquence comme un UID peut viser un autre message.

Le signal de limite ne se trouve pas toujours dans la dernière ligne. Si EXPUNGEISSUED doit aussi être communiqué, ce code occupe le OK étiqueté et MESSAGELIMIT apparaît dans un NO non étiqueté. Lire seulement le statut final revient à jeter le reçu d’incomplétude tout en conservant le mot rassurant.

L’atomicité empêche de généraliser

COPY et UID COPY ne laissent pas de moitié de copie. Leur contrat est atomique. Si l’ensemble dépasse la capacité acceptée, le serveur renvoie NO [MESSAGELIMIT …] et ne copie aucun message. MULTIAPPEND obéit à la même exigence : un groupe trop grand n’ajoute rien.

MOVE n’offre pas cette garantie globale. Une tranche peut avoir changé les deux boîtes avant le retour de la limite. STORE et UID EXPUNGE ont eux aussi des effets partiels. Le même code de réponse doit donc être interprété avec le type d’opération. « La commande a dépassé N » n’est pas une description suffisante de ce qui s’est produit.

Trois catégories doivent rester distinctes : refus atomique sans effet ; succès partiel avec effet et reprise ; opération exemptée de cette limite. EXPUNGE, CLOSE et STATUS UNSEEN ne doivent pas être limités par ce mécanisme. Leur portée entière reste préservée, sans que leur succès puisse attester ce qui se passe ensuite sur disque, dans le cache du client ou devant le lecteur.

L’extension PARTIAL de RFC 9394 trace encore une autre frontière. Un client qui demande explicitement une page PARTIAL supérieure à N reçoit un refus et aucun travail. Sans cette page explicite, un FETCH comparable peut recevoir une tranche implicite et un OK partiel. Une page demandée et une coupe imposée ne sont donc pas deux écritures du même contrat.

Un résultat sauvegardé peut sauvegarder l’oubli

SEARCHRES permet de placer le résultat d’une recherche dans $. Si SEARCH atteint MESSAGELIMIT, le serveur doit également tronquer ce résultat sauvegardé. $ désigne alors une population valide mais partielle.

Le problème se déplace. Une commande ultérieure utilisant $ peut être totalement conforme et pourtant travailler sur une sélection incomplète. Le transcript ultérieur ne contient plus forcément le code qui expliquait la lacune. Sans provenance, la variable acquiert une apparence d’autorité qu’elle n’a jamais reçue.

Il faut donc associer au résultat sauvegardé la boîte, UIDVALIDITY, la requête d’origine, la valeur de limite, le plus faible UID atteint, l’heure et l’état « reprise requise ». Un simple identifiant de cache ne suffit pas.

UIDAFTER et UIDBEFORE, également définis par RFC 9738, facilitent la fabrication d’une plage suivante. Ils ne figent pas les arrivées nouvelles, ne ressuscitent pas les UID supprimés et ne réparent pas un changement de génération. Ce sont des critères de recherche, non une transaction couvrant la durée du travail.

L’annonce peut précéder la contrainte

Le passage le plus honnête de RFC 9738 concerne la migration. Imposer brutalement la limite abandonnerait les anciens clients sur les grandes boîtes. Ils compteraient faux, rateraient des messages anciens ou verraient COPY échouer sans savoir comment reprendre.

Le texte propose donc une adoption progressive. Le serveur peut d’abord annoncer MESSAGELIMIT sans l’appliquer. Les clients compatibles se disciplinent déjà et réduisent la charge ; les autres continuent de fonctionner. Plus tard, le serveur peut annoncer mille comme limite souple tout en n’interrompant réellement qu’à dix mille. Il peut journaliser les dépassements pour observer la compréhension des clients avant de resserrer le seuil.

La chaîne de caractères dans CAPABILITY n’est ainsi pas une mesure d’adoption. Elle décrit ce qu’un client informé devrait respecter. La réalité opérationnelle dépend du comportement des clients, du seuil effectivement appliqué et de l’observation de la compatibilité.

Cette souplesse exige deux métriques. La limite annoncée appartient au contrat public de la session ; le seuil dur appartient à l’exécution du serveur. Les fusionner rend impossible de distinguer un client compatible, un ancien client encore toléré et un serveur passé à l’application stricte.

Fermer l’intention initiale

Une opération couvrant toute une boîte doit conserver son intention jusqu’au rapprochement final. Pour chaque passage, il faut garder : boîte et UIDVALIDITY, ensemble demandé, commande exacte, capacité observée, classe atomique ou partielle, UID retournés, effets constatés, réponses non étiquetées, statut final, limite et UID bas.

La fin ne consiste pas seulement à recevoir une invocation sans MESSAGELIMIT. Il faut rapprocher la population visée, les messages effectivement examinés ou modifiés, ceux qui ont disparu pendant la série et ceux qui sont arrivés hors du périmètre initial. Le reste non expliqué doit rester un reste, pas devenir zéro par commodité.

Les outils voisins ne doivent pas être fondus en une seule notion de lot. UIDBATCHES prépare des plages bornées. PARTIAL demande une page déterminée. MESSAGELIMIT décrit une borne rencontrée pendant l’exécution. SEARCHRES mémorise une population. Chacun répond à une étape différente.

RFC 9738 apporte une discipline plus utile qu’un nouveau voyant vert : il permet au serveur de dire précisément « ce travail a réussi, cette tranche a été touchée, le reste n’a pas encore été couvert ». Le plus faible UID doit voyager avec le résultat jusqu’à la fermeture. Sans lui, une boîte plausible peut cacher le début de la semaine.

Sources