Résumé

  • L’option SAVE de RFC 5182 place un résultat dans une variable unique. Une nouvelle commande SAVE remplace la précédente ; elle ne crée ni nom, ni version, ni instantané supplémentaire.
  • La preuve exploitable doit relier chaque consommateur de $ à son producteur, à la boîte sélectionnée, à UIDVALIDITY et à l’ordre reçu. L’ordre des réponses ne suffit pas à reconstruire cette autorité.

L’équipe de conformité avait préparé deux sélections. La première visait les messages soumis à conservation. La seconde repérait ceux qui pouvaient être purgés. Pour gagner un aller-retour, le client envoya les deux recherches avec RETURN (SAVE), puis une opération sur $. Les journaux montrèrent deux recherches terminées et une commande finale réussie. Ils ne dirent pas quel ensemble avait autorisé cette dernière.

Dans RFC 5182, la réponse n’est pas négociable : le second SAVE reçu remplace le premier. Il n’existe pas de $1 et de $2. Le marqueur ne porte pas le nom du contrôle, ne retient pas le texte de la requête et ne fabrique pas un objet durable. Il désigne la valeur courante d’une seule variable interne.

Ce cas est une construction analytique, pas le récit d’un fournisseur précis. Il montre néanmoins pourquoi l’économie de protocole ne doit pas devenir une économie de preuve.

Une optimisation ne crée pas un dossier

Avant SEARCHRES, un serveur renvoyait la liste des messages trouvés ; le client la décodait, la reformatait puis la renvoyait pour FETCH, STORE, COPY, SEARCH ou UID EXPUNGE. RFC 5182 évite ce trajet. Le serveur annonce SEARCHRES, doit prendre en charge ESEARCH, et conserve localement le résultat demandé avec SAVE.

Le bénéfice est concret : moins de bande passante, moins de latence, moins de transformation côté client et davantage de possibilités d’optimisation côté serveur. En l’absence d’une autre option de résultat, SAVE supprime même la réponse SEARCH qui aurait exposé la liste. Le client peut donc exploiter un ensemble qu’il n’a jamais reçu.

Cette sobriété est le contrat. La variable ne contient pas nécessairement la requête, son motif métier, l’identité de l’opérateur ou une échéance. Le standard n’exige pas qu’elle survive à la connexion. Lui donner dans une interface le nom « recherche enregistrée » ajoute une promesse que le protocole n’a pas faite.

Une application peut créer cette promesse, à condition de la posséder elle-même : identifiant immuable, critères, portée, heure, auteur, version et résultat attendu. $ reste alors un moyen d’exécution, non la source d’autorité.

L’ordre reçu est le registre réel

Une commande SAVE suivie d’une commande utilisant $ crée une dépendance directe. Le serveur doit respecter l’ordre de réception. Il peut paralléliser ou substituer les critères dans son moteur interne lorsque le résultat observable reste équivalent, mais il ne peut pas faire consommer une valeur antérieure à la production attendue.

RFC 5182 permet aussi d’envoyer un SAVE puis plusieurs consommateurs. COPY et STORE peuvent ainsi viser le même ensemble, selon l’ordre prévu. Le graphe est encore lisible : un producteur, plusieurs utilisations liées.

Deux producteurs changent la topologie. La deuxième recherche SAVE remplace toujours la première. Des tags différents permettent d’associer les réponses à leurs commandes ; ils ne nomment pas deux variables de résultats. Si l’audit reconstruit le scénario à partir de l’heure d’arrivée des réponses plutôt qu’à partir des commandes reçues et de leurs dépendances, il peut attribuer le dernier effet au mauvais mandat.

RFC 5267 éclaire le contraste. CONTEXT peut établir des contextes d’actualisation identifiés par un tag, publier leurs changements et annuler ces mises à jour. SEARCHRES ne promet rien de tel. Un emplacement « dernier résultat » ne devient pas un catalogue de contextes parce que le produit envoie plusieurs opérations en parallèle.

La sélection de boîte délimite la mémoire

Après un SELECT ou EXAMINE réussi, la variable redevient vide. Une nouvelle valeur UIDVALIDITY pendant l’ouverture de la boîte la vide aussi. Le couple boîte–UIDVALIDITY définit une génération d’identité ; transporter silencieusement $ au-delà ferait parler des identifiants dans un autre monde.

EXPUNGE agit sans nouveau SAVE. Un message supprimé quitte automatiquement l’ensemble. Lorsque le serveur conserve des numéros de séquence, il doit réajuster ceux qui suivent, car les positions changent après l’expunge. L’ensemble n’est donc pas un instantané immobile. Il suit certains événements de la boîte.

Le contexte de la commande consommatrice détermine en outre si $ est lu comme numéros de séquence ou comme UID. Une recherche ordinaire peut alimenter UID FETCH ; une UID SEARCH peut alimenter FETCH. Le type n’est pas scellé par la commande productrice.

Un registre sérieux conserve donc la connexion, la boîte, UIDVALIDITY, le tag et les critères du producteur, les options de retour, l’ordre reçu, les expunges et changements de sélection, puis la forme de chaque consommateur. Sans cette chaîne, le caractère $ n’identifie aucun ensemble de façon vérifiable.

L’échec ferme la case

Toutes les erreurs ne produisent pas le même changement d’état. Une recherche répondant BAD ne touche pas la variable. Une recherche sans SAVE, qu’elle réussisse ou réponde NO, ne la touche pas non plus. En revanche, une recherche avec SAVE qui répond NO vide la variable.

Ce choix empêche le résultat ancien de survivre derrière l’apparence d’une mise à jour échouée. L’exemple de RFC 5182 utilise un jeu de caractères non pris en charge : après l’échec, le client doit refaire la recherche antérieure s’il veut reconstruire la série. Continuer comme si le premier ensemble était encore disponible serait précisément l’ambiguïté que la règle évite.

Le serveur peut aussi refuser de mémoriser sous pression de ressources. Il répond NO avec NOTSAVED et vide la variable. Le RFC relie cette possibilité au coût d’état et au risque de déni de service entre connexions. L’annonce de SEARCHRES ne vaut donc ni réservation de mémoire ni assurance que chaque SAVE sera accepté.

La réaction sûre n’est pas de poursuivre aveuglément avec $, ni de réutiliser mentalement l’ancienne population. Elle consiste à arrêter la chaîne, enregistrer l’échec, puis recalculer explicitement sous une nouvelle identité d’opération.

OK peut vouloir dire « rien »

Le vide est une valeur valide. Une recherche ne trouve aucun message ; SELECT ou UIDVALIDITY remet l’état à zéro ; un SAVE échoue ; le dernier membre est expungé. Les commandes recevant un ensemble doivent traiter $ vide comme un ensemble qui ne correspond à rien, pas comme une erreur de syntaxe.

Ainsi, FETCH $ peut ne produire aucune réponse FETCH et se terminer par OK. COPY peut répondre OK en n’ayant rien copié. Le serveur a bien exécuté la commande. Le contrôle métier, lui, n’a peut-être atteint aucune cible.

Il faut distinguer quatre réalités : la population visée par la règle, la population calculée par SEARCH, celle réellement placée dans la variable, et celle encore présente puis affectée lors du consommateur. Un rapport « commande réussie » ne répond qu’à la dernière question de protocole, pas aux trois précédentes.

Dans une rétention, un gel juridique ou une automatisation de sécurité, cette différence est décisive. L’absence d’erreur de transport ne clôt pas l’obligation. La clôture exige une réconciliation et une explication de chaque écart.

Les options changent la population enregistrée

Le mot SAVE ne signifie pas toujours « tous les résultats ». Avec ESEARCH, SAVE MIN ne garde que le minimum ; SAVE MAX le maximum ; SAVE MIN MAX un ou deux messages. Dès que ALL ou COUNT est demandé, RFC 5182 exige de garder tous les messages trouvés, même si un calcul de COUNT aurait pu éviter de matérialiser la liste.

RFC 9394 ajoute PARTIAL : sans ALL, $ reçoit la fenêtre partielle et, selon la combinaison, les extrêmes. RFC 9738 impose qu’une recherche coupée par MESSAGELIMIT enregistre l’ensemble tronqué. BTW a déjà consacré une analyse à cette frontière de complétude. Ici, le point est différent : même sans troncature, la valeur dépend des options exactes et ne peut pas être déduite de l’intitulé humain de la recherche.

Un responsable ne devrait donc jamais approuver « appliquer la politique au résultat sauvegardé ». Il devrait voir : critères, options, cardinalité attendue, cardinalité stockée, mutations et effet constaté.

Rendre l’autorité locale explicite

IANA enregistre SEARCHRES et RFC 9051 reprend son mécanisme dans IMAP4rev2. Cette reconnaissance permet l’interopérabilité. Elle ne démontre ni déploiement, ni conformité d’un client, ni disponibilité de ressources, ni résultat de conservation.

Pour un usage sensible, l’organisation doit créer son propre objet de preuve. Celui-ci reçoit un identifiant durable, fige la requête et sa portée, lie boîte et UIDVALIDITY, enregistre l’ordre des commandes, les remises à zéro, les expunges, les options et les effets. $ peut alors accélérer le trajet sans devenir le titre de propriété de la décision.

Le bon test de gouvernance tient en deux questions : pouvons-nous prouver pourquoi chaque message touché faisait partie du mandat ? Pouvons-nous expliquer chaque message visé qui ne l’a pas été ? Si le journal répond seulement « SAVE puis OK », le protocole a été correctement utilisé mais la réalité métier n’a pas été conservée.

Sources

  1. RFC 5182 — HTML
  2. RFC 5182 — texte brut
  3. Page d’information RFC Editor
  4. Page du document IETF Datatracker
  5. Historique IETF Datatracker
  6. Références IETF Datatracker
  7. Errata de RFC 5182
  8. RFC 9051 — IMAP4rev2
  9. Page d’information de RFC 9051
  10. RFC 4731 — ESEARCH
  11. RFC 4466 — ABNF IMAP consolidée
  12. RFC 4315 — UIDPLUS
  13. RFC 3501 — IMAP4rev1
  14. RFC 5267 — IMAP CONTEXT
  15. RFC 9738 — MESSAGELIMIT
  16. RFC 9394 — PARTIAL
  17. Registre IANA des capacités IMAP
  18. Heng Lu — les couches de réalité
  19. Heng Lu — spécification initiale minimale et adoption volontaire
  20. Heng Lu — la primauté du code en fonctionnement