Résumé

  • Chaque agent Netnews ajoutait son identité au début de Path ; le relais le plus récent apparaissait donc à gauche d’une trace qui grandissait à rebours.
  • Avant d’envoyer un article, un serveur pouvait écarter un voisin déjà nommé, tandis que la base d’historique fondée sur Message-ID restait chargée de rejeter le véritable doublon.
  • Les séparateurs et diagnostics exprimaient des degrés de connaissance : !! signalait une vérification adjacente, ! n’en promettait aucune, et not-for-mail n’était pas un relais.

Deux mémoires pour deux moments

Un serveur B reçoit un article de A. Il l’accepte, puis examine les voisins auxquels il pourrait le transmettre. S’il le renvoie immédiatement à A, ce dernier reconnaîtra le Message-ID et le rejettera. La boucle ne durera pas, mais la liaison aura transporté un objet dont l’issue était connue d’avance.

La première mémoire appartient donc à l’article en circulation : Path énumère les agents déjà traversés. La seconde appartient au serveur : sa base d’historique conserve les Message-ID déjà vus. La première évite une transmission avant qu’elle ne commence ; la seconde garantit que la répétition revenue par une autre branche ne sera pas admise comme un article neuf.

RFC 1036 formule précisément cette complémentarité. Le suivi local des Message-ID suffit à arrêter une boucle. Le champ Path réduit en plus le trafic redondant, notamment le retour immédiat de B vers A. Il ne faut donc ni raconter Path comme l’identité de l’article, ni présenter l’historique comme une optimisation de lien. Ils interviennent à des frontières différentes.

La chronologie se lisait de droite à gauche

Le geste technique était simple : chaque système qui recevait puis traitait l’article ajoutait son propre nom à gauche. La trace A!X!Y!Z devenait B!A!X!Y!Z chez B. Le dernier relais était le premier élément visible ; l’injection ancienne restait vers la droite.

RFC 850 décrivait déjà ce mécanisme en 1983. Il acceptait plusieurs ponctuations, héritage d’un monde où les chemins UUCP écrits avec des points d’exclamation pouvaient ressembler à des adresses acheminées manuellement. Mais le texte posait aussitôt la limite : la ligne Path ne servait pas aux réponses et ne devait pas être prise pour une adresse postale.

La ressemblance a longtemps survécu à la fonction. Un chemin d’articles n’était pas nécessairement un chemin de courriel ; un nom reconnu entre deux relais de nouvelles pouvait être inconnu d’un logiciel de messagerie. Une suite qui réussissait parfois à acheminer une réponse ne gagnait pas pour autant ce pouvoir dans le protocole.

RFC 1849 éclaire l’étape intermédiaire. Ce document historique, publié en 2010 à partir d’un projet largement utilisé au début des années 1990, ne doit pas servir de spécification actuelle. Il montre cependant la pratique stabilisée : des noms de relais séparés par !, chaque relais ajoutant le sien et s’interdisant d’envoyer vers un voisin déjà inscrit.

Son explication économique est décisive. Même si le serveur de retour rejetait le doublon grâce au Message-ID, l’absence d’un Path cohérent pouvait faire parcourir deux fois chaque liaison. Une erreur de nom ne détruisait pas nécessairement la convergence ; elle consommait la capacité avant que le mécanisme correctif ne puisse agir.

Le dernier mot n’était pas une machine visitée

L’extrémité droite de l’ancien champ contenait parfois une partie locale héritée de l’adresse de l’expéditeur. Elle ne faisait pas partie de la liste des relais. Un analyseur qui range tous les segments séparés par ! dans une seule collection de serveurs peut donc supprimer à tort une destination légitime portant le même nom.

RFC 5536 formalise la différence entre path-list et tail-entry. La valeur finale peut être not-for-mail. Ce n’est ni un message d’erreur ni le nom d’un site : c’est une façon très lisible de fermer l’ancienne ambiguïté postale.

La leçon dépasse la syntaxe. Un identifiant ne possède pas le même sens partout où il apparaît. Dans la liste, il peut justifier l’exclusion d’un voisin. Après le diagnostic POSTED, ou dans la queue finale, la même chaîne n’est pas une preuve de passage et ne doit pas gouverner ce choix.

NNTP transportait, l’article conservait sa propre histoire

RFC 977 normalisa en 1986 l’échange, la consultation et la publication d’articles sur un flux fiable comme TCP. RFC 3977 remplaça ce contrat en 2006. Ces protocoles expliquent comment deux programmes se parlent ; ils ne transforment pas Path en liste de connexions TCP.

L’architecture actuelle de RFC 5537 sépare explicitement Netnews de son transport sous-jacent. Un article et son Path peuvent survivre à plusieurs sessions, passer par des composants distincts d’un même serveur ou franchir une passerelle. Les noms inscrits sont ceux d’agents applicatifs, pas ceux des routeurs IP rencontrés par les paquets.

Path n’ordonne donc pas la prochaine route. Le relais possède déjà sa topologie de voisins et ses règles de groupes et de distributions. Le champ fournit une raison négative et circonscrite : ne pas proposer cet article à ce voisin, car son identité figure déjà dans la trace pertinente.

Le protocole a préféré montrer le doute

Les textes de 2009 donnent au champ un vocabulaire plus honnête que l’ancien alignement de noms. Un agent choisit une identité, de préférence un nom de domaine complet, ou une autre chaîne dont l’unicité est garantie dans le cercle de relais concerné. Ses voisins doivent connaître cette identité et ses alias, sans quoi la comparaison utile devient impossible.

Deux points d’exclamation consécutifs indiquent que l’agent situé à gauche a vérifié, à sa satisfaction, l’identité placée à droite. Un seul ! ne porte pas cette affirmation. Il ne s’agit pas de deux degrés typographiques d’une même signature, mais de deux contrats différents.

POSTED situe l’injection. MISMATCH constate que l’identité attendue depuis la connexion ne correspond pas à celle annoncée en tête. SEEN consigne la source observée quand l’agent ne veut ou ne peut pas la valider comme identité Path. L’attente peut provenir d’une identité d’authentification du pair ou de son adresse IP.

Chaque annotation reste donc celle d’un observateur adjacent. Une discordance peut révéler une usurpation, mais aussi un alias oublié, une migration, un proxy ou une casse incohérente. Même une suite de !! n’est pas une signature de bout en bout : chaque relais ne parle que de son voisin et de ses propres critères.

RFC 5537 recommande d’ailleurs de n’accepter les articles que d’agents de confiance afin de limiter la falsification de Path et d’Injection-Info. Si le champ se suffisait comme preuve, cette relation extérieure ne serait pas nécessaire.

Une absence ne donnait aucune autorisation

La règle moderne demande de ne pas relayer vers un agent dont l’identité, ou un alias connu, apparaît déjà dans la liste—hors queue finale et hors emplacement réservé à la source de POSTED. Elle ne dit pas qu’un voisin absent doit recevoir l’article.

L’intérêt du groupe, la Distribution, la validité de l’article, la relation de confiance, la capacité et la politique locale restent des tests indépendants. L’historique Message-ID reste nécessaire pour les copies venues d’un autre côté et pour les pairs qui n’appliquent pas l’optimisation. Les passerelles ont besoin de défenses supplémentaires, car une conversion peut perdre les propriétés utilisées par Netnews et réinjecter l’objet.

Path fut durable précisément parce qu’il ne prétendait pas résoudre ces autres questions. Il donnait aux opérateurs assez de mémoire partagée pour éviter le retour le plus évident, tout en laissant l’admission, le stockage, l’identité de l’article et la confiance dans d’autres couches.

Les RFC établissent ce contrat historique. Elles ne mesurent ni l’usage contemporain de ces diagnostics, ni la configuration d’un fournisseur, ni l’exactitude d’une trace particulière. Pour cela, il faut les journaux de connexion, les décisions de transfert, l’historique local et la preuve de stockage.