Résumé
- Dès le RFC 733, l’hôte qui produisait l’identifiant devait en garantir l’unicité. Une révision recevait un nouvel ID, tandis que l’ajout d’une trace de transport ne changeait pas nécessairement l’identité initiale.
In-Reply-ToetReferencesont transformé l’identifiant en arête d’un graphe de conversation. Netnews en a fait une mémoire locale : un serveur écartait tout ID déjà vu et empêchait ainsi la diffusion cyclique.- Le nom n’était ni une signature ni une empreinte du contenu. Netnews assimilait deux articles de même ID malgré des corps différents ; un ID prévisible pouvait donc être préempté et bloquer l’article attendu.
Des octets nouveaux, mais pas un nouveau message
Lorsqu’un courrier entre dans la chaîne de transport, le relais suivant peut préfixer un champ Received. La représentation stockée n’est plus identique à celle de départ. Pourtant, le relais n’a pas révisé le propos de l’auteur ; le Message-ID original demeure.
Si l’auteur modifie au contraire ce qu’il entend communiquer et publie cette révision comme une nouvelle version, un autre identifiant s’impose, même si une seule phrase diffère. Le RFC 733, en 1977, dessinait déjà cette limite : un identifiant vise une seule version ou instanciation d’un message, et chaque révision ultérieure doit en recevoir un nouveau. L’hôte générateur garantit l’unicité.
Le RFC 822 reprit cette règle en 1982. La valeur devait être lisible par les machines, sans devoir signifier quoi que ce soit pour une personne. Ce n’est ni un résumé de sujet ni un nom d’auteur, mais une poignée stable pour une version déclarée.
Fabriquer un nom mondial à partir d’une responsabilité locale
Le RFC 5322 exige que le msg-id soit mondialement unique et que son générateur le garantisse. Il ne crée pourtant aucun bureau chargé d’attribuer un numéro à chaque courrier.
La recommandation partage l’espace. À droite de @, un identifiant de domaine fournit un périmètre distinct ; à gauche, le générateur place une valeur qu’il sait garder unique dans ce périmètre, par exemple le temps associé à un compteur ou à un élément propre au processus. Un domaine globalement différenciable et une comptabilité locale suffisent à composer un nom mondial.
La ressemblance avec une adresse ne doit pas tromper. La partie droite ne constitue pas une boîte aux lettres, n’a pas à se résoudre aujourd’hui et ne prouve ni la maîtrise du domaine ni l’identité de l’auteur. La partie gauche n’offre pas davantage une sémantique commerciale à deviner.
Le même RFC explique que l’identité dépend du sens voulu. Des champs de trace ou de réexpédition peuvent modifier la syntaxe sans créer un nouveau message. C’est l’intention de l’émetteur — même message ou autre message — qui commande le changement d’ID, non une différence d’octets. Message-ID n’est donc ni une somme de contrôle ni l’identifiant d’une transaction d’enveloppe SMTP.
Une réponse devint une relation transportable
In-Reply-To contient l’ID du message parent. References reprend les ancêtres déjà déclarés par ce parent et ajoute son propre ID. Un logiciel peut reconstituer une conversation malgré des routes et des heures d’arrivée différentes.
Cette fonction ne vient pas seulement des clients de messagerie récents. Le RFC 850, consacré à Usenet en 1983, imposait qu’un follow-up prolonge la liste References de l’article précédent. Il en donnait le but : regrouper les articles en conversations et permettre au lecteur d’écarter un échange entier sans quitter le groupe. Le RFC 1036 conserva la construction.
Le graphe n’est pas une preuve. Le RFC 5322 note que beaucoup de logiciels remontent la chaîne en supposant un parent unique ; la construction à plusieurs parents n’est pas entièrement définie. References déclare une ascendance, mais n’authentifie ni les auteurs ni la compréhension du texte antérieur.
Chaque serveur transforma le nom en mémoire
Dans la diffusion entre pairs d’Usenet, le même article peut revenir par plusieurs voisins. Tout retransmettre à chaque arrivée entretiendrait un cycle. Le RFC 1036 décrit donc l’historique local : chaque hôte mémorise les articles vus par Message-ID et rejette immédiatement une nouvelle arrivée du même ID. Path évite en plus certaines transmissions inutiles, mais l’historique suffit à rompre la boucle.
La convergence ne dépend d’aucun serveur maître. Chaque site compare un nom à sa propre mémoire et conclut qu’il a déjà admis cet article logique. La référence qui reliait une conversation humaine devient aussi la clé d’une déduplication distribuée.
Quand le même nom prima sur des corps différents
Le RFC 5536 rend le compromis explicite : Netnews traite deux articles de même Message-ID comme un seul, quelles que soient les différences dans leurs en-têtes ou leurs corps. Il restreint la syntaxe, borne la longueur et exige la conservation de la casse afin qu’une comparaison simple d’octets suffise. L’unicité doit traverser les protocoles, notamment le courrier et Netnews.
Cette efficacité donne un pouvoir à la collision. Un attaquant qui prédit l’ID d’un futur article peut publier d’abord un autre objet portant ce nom ; le véritable article risque ensuite d’être refusé comme déjà vu. Le RFC 5536 recommande donc des ID imprévisibles. Ce n’est pas une empreinte de contenu qui a échoué : il n’y en avait pas. C’est la première inscription dans un registre distribué de noms.
Ce que le nom n’a jamais attesté
Message-ID résout la référence, pas la confiance. Il ne signe pas le corps, n’authentifie pas From, ne nomme pas la transaction SMTP, ne prouve pas la lecture et ne garantit pas l’égalité des octets. Un même ID peut cacher une collision ; deux ID peuvent porter le même texte.
La sobriété explique la longévité du mécanisme. L’origine nomme. Le transport ajoute des traces sans renommer. Le logiciel de courrier crée les relations. Le serveur de nouvelles garde son historique local. La preuve cryptographique reste une autre couche.
Sources et limites
La chaîne repose sur les RFC 733, RFC 822, RFC 850, RFC 1036, RFC 2822, RFC 5322 et RFC 5536. Ils établissent les contrats et les risques reconnus, non les taux actuels de collision, les algorithmes des fournisseurs, le déploiement mondial ou la durée des historiques.
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
