Résumé

  • Approved nomme les personnes ou entités ayant autorisé la publication d’un article Netnews. Il ne remplace pas l’auteur et n’authentifie pas, à lui seul, la boîte indiquée.
  • Dès qu’un proto-article vise un groupe modéré sans porter ce champ, l’agent d’injection doit transmettre l’ensemble au modérateur du premier groupe modéré de la liste, ou le rejeter. Le groupe non modéré n’est pas servi en avance.
  • Plusieurs modérateurs peuvent se succéder. Le dernier ajoute le champ et répond de tous les accords requis ; l’agent d’injection vérifie par un moyen extérieur que le retour provient bien d’un canal autorisé.

La partie libre n’était pas publiée avant la partie modérée

Un auteur choisit trois groupes : un forum technique ouvert et deux groupes modérés. Son proto-article ne contient pas Approved. Une logique de distribution naïve créerait aussitôt une copie publique dans le premier groupe et placerait les deux autres en attente.

L’architecture Netnews retient au contraire l’objet entier. L’agent d’injection le transmet au modérateur du groupe modéré le plus à gauche dans Newsgroups. S’il ne sait pas le faire, il rejette la soumission. Tant que la chaîne éditoriale n’est pas terminée, aucune destination n’a reçu un article injecté.

Le premier modérateur peut donner son accord puis envoyer le proto-article au suivant. Une fois tous les groupes modérés couverts, le dernier responsable ajoute Approved et renvoie l’article à l’injection. L’unique publication atteint alors les trois groupes.

Cette suspension commune évite un état irréversible où un contenu est déjà public alors que l’une de ses destinations n’a pas encore consenti.

Dès 1987, le modérateur n’effaçait pas l’auteur

La RFC 1036 exigeait une ligne Approved pour tout message publié dans un groupe modéré. Le modérateur devait l’ajouter avec son adresse de courrier. Certains messages de contrôle utilisaient aussi ce champ.

L’adresse ne remplaçait pas From. Le texte conservait son auteur, tandis qu’une seconde identité portait la responsabilité d’une décision de publication. Une personne pouvait donc écrire sans disposer du droit d’entrer directement dans le groupe ; une autre pouvait approuver sans devenir l’auteur du texte.

Le dispositif ne cherchait pas une identité unique plus puissante. Il préservait deux attributions incompatibles avec une seule case : origine intellectuelle et autorité éditoriale.

Le statut m annonçait un traitement ordinaire

La RFC 3977 permet au client de consulter l’état local des groupes avec LIST ACTIVE. y signifie normalement que la publication est permise, n qu’elle ne l’est pas et m que les soumissions seront transmises au modérateur.

Ce statut n’est pas nécessairement personnalisé. Un client interdit de publication ne reçoit pas un droit grâce à y, et un client doté d’un privilège particulier peut connaître un traitement différent dans un groupe marqué n.

m décrit donc le chemin habituel sur ce serveur. Il ne désigne pas le modérateur, ne certifie aucun compte et ne préjuge pas de l’issue éditoriale. C’est une annonce de routage institutionnel, pas un jeton individuel.

Une liste de boîtes exprimait la conclusion

La RFC 5536 définit Approved comme une mailbox-list. Les adresses, accompagnées éventuellement de noms complets, indiquent les personnes ou entités ayant approuvé la publication. Les articles modérés et les messages de contrôle de groupe sont ses usages principaux.

Le pluriel permet de conserver plusieurs autorités, notamment lorsqu’un crosspost traverse plusieurs groupes modérés. Pourtant la grammaire ne dépasse pas l’attribution déclarée. Elle ne prouve ni que la boîte existe, ni que son propriétaire a examiné l’article, ni qu’il occupe encore la fonction, ni que chaque serveur lui fait confiance.

Une syntaxe correcte facilite le transport de la décision. Elle ne transforme pas la décision en preuve cryptographique.

L’identité précédait l’injection, pas la publication

La RFC 5537 place la bifurcation dans les devoirs de l’agent d’injection. Lorsqu’un groupe modéré est présent sans Approved, l’agent doit transmettre ou rejeter. Il ajoute d’abord Message-ID et Date s’ils manquent, puis effectue le transfert avant les champs ordinaires de trace d’injection.

Le proto-article possède ainsi assez d’identité pour traverser l’examen sans se multiplier, mais il n’est pas encore présenté comme une nouvelle injectée. Il peut voyager dans un objet application/news-transmission, sous forme de courriel portant les champs Netnews, ou par un magasin partagé qui le conserve sans l’injecter.

Le groupe modéré le plus à gauche fournit un premier destinataire déterministe. Cette priorité de traitement ne lui donne aucune souveraineté sur les autres groupes.

Le dernier modérateur assumait le collectif

S’il reste des groupes modérés non approuvés, les responsables peuvent se coordonner ou transmettre le proto-article avec une indication intermédiaire. Quand tous les accords sont réunis, un modérateur ajoute enfin Approved, s’identifie et mentionne, dans la mesure du possible, les autres approbateurs.

La RFC lui attribue alors une responsabilité précise : s’assurer que les modérateurs de tous les groupes concernés ont approuvé l’article. Le champ visible est donc la conclusion condensée d’une chaîne, non son journal complet.

Il ne révèle pas les critères employés, les négociations, les modifications ou les preuves examinées. Les modérateurs peuvent modifier le corps et les en-têtes, mais la recommandation de limiter les changements rappelle qu’ils risquent d’invalider les signatures du déposant ou des modérateurs précédents.

Un imposteur pouvait produire un champ impeccable

La section de sécurité de la RFC 5537 avertit qu’un déposant malveillant peut ajouter Approved pour contourner la modération. Une adresse bien formée n’empêche aucune usurpation.

L’agent d’injection devrait donc vérifier que l’article approuvé est injecté par le modérateur, grâce aux informations d’authentification du transport sous-jacent ou à un mécanisme convenu avec lui. Le document constate qu’il n’existait pas de méthode normalisée pour authentifier l’approbation des groupes modérés.

Deux preuves différentes se complètent. L’article transporte « voici qui est déclaré approbateur ». La frontière locale établit « cet objet revient effectivement par le canal de ce modérateur ». Sans le champ, l’attribution disparaît en aval ; sans le canal, l’attribution peut être fabriquée.

IANA a enregistré un vocabulaire, pas une liste de confiance

Le registre IANA des champs de message classe Approved comme champ Netnews standard lié à la RFC 5536. Il stabilise le nom et la référence commune.

Il ne nomme aucun modérateur, ne vérifie aucune boîte et n’oblige pas les opérateurs à reconnaître une autorité. Les sources ne permettent pas non plus de déduire la pratique des fournisseurs actuels. La déclaration circule ; la confiance reste administrée.

L’autorité éditoriale voyageait sans devenir la plume

Le mérite de Approved fut de rendre une décision de modération portable tout en laissant intacte la qualité d’auteur. Les relais pouvaient conserver le nom des responsables de l’admission, sans attribuer le texte à ceux qui l’avaient autorisé.

Mais la portabilité n’apportait pas sa propre sécurité. Le champ n’ouvrait la porte que parce que l’agent d’injection avait déjà défini, hors de l’article, le canal et l’autorité qu’il accepterait.

L’histoire tient dans cette double séparation : approuver n’est pas écrire, et afficher une identité n’est pas l’authentifier. L’auteur produit, le modérateur autorise une destination, l’agent d’injection décide si l’autorité revendiquée mérite l’accès au réseau.