Résumé

  • RFC 5256 rend le tri et le groupement reproductibles, mais le résultat demeure une projection bornée par la recherche, l’algorithme, la collation, les en-têtes disponibles et l’état courant de la boîte.
  • Une relation affichée peut provenir d’une référence déclarée, d’un ancêtre fictif créé pour combler un manque ou d’une fusion par objet ; elle ne prouve ni l’intention de répondre, ni l’ascendance complète, ni la conservation ou la remise.

La chronologie apparente est arrivée avant le dossier

Dans un dossier d’incident, sept messages apparaissaient sous une même racine. L’image semblait résoudre la question de responsabilité : une demande, une réponse, quatre validations et une clôture. Pourtant, le filtre excluait les messages antérieurs à une date. L’arbre ne représentait pas la boîte ; il représentait le résultat d’une requête sur la boîte.

La commande THREAD commence par une recherche. Elle n’extrait pas une conversation qui existerait déjà comme objet certifié. Elle prend les messages qui satisfont les critères, interprète les chaînes selon le jeu de caractères demandé, puis applique un algorithme. Modifier le filtre peut faire disparaître un parent ou séparer des branches sans changer aucun octet des messages conservés.

Il faut donc distinguer trois réalités. Les messages et les métadonnées du serveur forment la couche d’enregistrement. La recherche, le décodage, la normalisation et la construction de l’arbre forment la couche de transformation. Les retraits, les traits et le mot « conversation » appartiennent à la couche de présentation. L’interface peut les rapprocher pour aider le lecteur ; elle ne peut pas transférer à la présentation une autorité que les enregistrements n’ont jamais donnée.

Plusieurs mandats se rencontrent dans une seule vue

Le client choisit les critères, le jeu de caractères et l’algorithme. Le serveur choisit l’instant de la boîte qu’il traite, lit les en-têtes et exécute les règles. L’expéditeur ou son logiciel a créé Message-ID, References et In-Reply-To. L’application dessine enfin le résultat.

Chaque acteur peut respecter le protocole et produire malgré tout une conclusion trompeuse. Une fausse valeur References: correctement traitée devient une branche très nette. Un parent absent peut avoir été filtré, supprimé ou n’avoir jamais été reçu. Le dessin ne tranche pas entre ces scénarios.

La question d’agence n’est donc pas « qui possède le fil ? », mais « qui a décidé chaque transformation, et qui supporte le coût si la vue devient une conclusion officielle ? ». Une organisation ne devrait pas laisser le propriétaire de l’interface certifier seul le sens du dossier.

ORDEREDSUBJECT assume qu’il regroupe des objets

RFC 5256 qualifie ORDEREDSUBJECT de « poor man's threading ». Il extrait un objet de base selon une procédure fixe, rassemble les messages dont cet objet est identique et les ordonne par date d’envoi. Le premier devient la racine ; tous les suivants sont ses enfants directs et restent frères entre eux. Il n’y a pas de petits-enfants.

Ce modèle ne prétend donc pas reconstruire des réponses. Il produit des groupes thématiques. C’est utile lorsque les références sont absentes, mais deux messages indépendants portant le même objet peuvent se rejoindre. Une vraie discussion dont l’objet change peut se scinder.

Même l’objet de base est un résultat. Les mots encodés sont décodés, les espaces sont comprimés, des préfixes de réponse, enveloppes de transfert, suffixes et blocs reconnus sont retirés. La même procédure est obligatoire en mode connecté et déconnecté pour éviter deux affichages concurrents. Cette uniformité prouve l’application d’une règle, pas la justesse sémantique de chaque suppression. Le RFC avertit qu’un texte significatif peut être pris pour un artefact.

REFERENCES fabrique une structure exploitable à partir de déclarations imparfaites

REFERENCES utilise les Message-ID de References, puis, dans les cas définis, le premier identifiant valide de In-Reply-To. Il normalise des écritures équivalentes et refuse une liaison qui créerait une boucle.

Les entrées réelles exigent davantage. Un message sans identifiant valide reçoit un identifiant unique créé pour le calcul. Lorsque plusieurs messages portent le même Message-ID, seul le premier selon le plus petit numéro de séquence le conserve ; les autres reçoivent des identifiants artificiels. Lorsqu’un identifiant cité n’existe pas dans l’ensemble, le serveur crée un message factice pour tenir sa place.

L’algorithme élague ensuite ces nœuds. Un factice sans enfant disparaît. Un factice avec enfants peut être supprimé et ses enfants remontés. Un factice structurel peut rester au sommet si la promotion déformerait l’arbre. Les liens conflictuels issus de références tronquées sont conservés ou rompus selon des règles précises.

Ce travail est une résolution déterministe, non une récupération historique. Le nœud factice n’est pas un courriel retrouvé. La remontée d’un enfant ne prouve pas l’absence d’intermédiaire. L’identifiant créé ne devient pas l’identité authentifiée d’un expéditeur.

L’objet peut encore réunir des racines sans lien direct

Après la première construction par identifiants, REFERENCES compare l’objet de base des racines. Des fils portant le même objet peuvent être fusionnés. Selon leur forme, un message non-réponse peut devenir représentant ou un nouveau parent factice peut contenir deux branches.

Une ligne à l’écran peut donc correspondre à une référence directe, à une chaîne d’identifiants, ou à une fusion de racines par objet. Si le système ne conserve pas la provenance de l’arête, le lecteur ne peut plus distinguer une déclaration d’en-tête d’un rapprochement de présentation.

Le RFC reconnaît lui-même qu’une fausse donnée References: peut incorporer un fil dans un autre. La normalisation évite que des guillemets différents produisent un faux échec de correspondance ; elle n’authentifie pas l’auteur de l’en-tête et ne valide pas son récit.

Le tri par date mélange des horloges

SORT recherche d’abord, puis applique les critères dans leur ordre de priorité. Les chaînes suivent la collation active. Lorsque tous les critères explicites sont égaux, le numéro de séquence de la boîte sert de critère implicite. Ainsi, REVERSE SUBJECT n’est pas le renversement intégral du résultat SUBJECT : le dernier départage ne s’inverse pas.

Le critère DATE part du champ Date:, normalisé en UTC. Des valeurs invalides reçoivent les substitutions prévues. Si aucune date d’envoi n’est exploitable, INTERNALDATE est utilisée. Une seule liste peut donc réunir une heure déclarée par l’auteur, une valeur corrigée par convention et une date tenue par le serveur.

RFC 5957 ajoute plus tard un tri par nom d’affichage. Il décode le nom complet s’il existe, sinon revient vers la boîte et l’hôte, mais refuse de deviner un nom de famille dépendant de la langue. C’est la bonne limite : un ordre doit déclarer sa clé, non se présenter comme l’ordre naturel des personnes.

Une vue vivante ne devient pas un registre historique

Les variantes UID sont préférables aux numéros de séquence volatils, mais l’UID doit rester attaché à la boîte et à son UIDVALIDITY. RFC 5267 maintient des résultats de recherche ou de tri quand la boîte évolue ; RFC 5182 permet de réutiliser un résultat sauvegardé. Ces fonctions améliorent l’efficacité. Elles ne créent pas un journal immuable.

Pour une décision sensible, il faut conserver l’état ou le jeton de la boîte, la requête, le jeu de caractères, l’algorithme, la collation, les capacités et la version du serveur, UIDVALIDITY et UID, les en-têtes bruts, les identifiants normalisés, la règle de chaque arête, les créations et promotions factices, les fusions par objet, les critères de départage, le hachage du résultat et la version de rendu.

La formulation finale doit respecter cette frontière. « Dans cet instantané, la vue RFC 5256 place B sous A » est vérifiable. « B a été écrit pour répondre à A » réclame d’autres preuves. « Le destinataire a lu et accepté A » appartient à une autre chaîne d’événements.

Sources