Résumé

  • Les états y, n et m de LIST ACTIVE décrivaient le traitement ordinaire des contributions sur un serveur, pas les droits personnels du client connecté.
  • Un client interdit pouvait être refusé dans un groupe y, tandis qu'un client doté d'un privilège particulier pouvait éventuellement publier dans un groupe n.
  • La liste, l'authentification, l'autorisation locale, l'acceptation de l'article et sa visibilité finale formaient des preuves distinctes.

Deux réponses vraies à deux questions différentes

Le cas le plus coûteux commence par une interface rassurante. Le logiciel lit y, active le bouton de composition et laisse l'utilisateur préparer un long message. Il ne demande POST qu'à la fin. Le serveur répond alors 440, avant même de réclamer le corps de l'article.

La liste n'était pas nécessairement périmée. Elle répondait à « comment ce groupe traite-t-il normalement les publications ? ». La réponse 440 répondait à « ce client peut-il publier maintenant ? ». Transformer la première réponse en seconde est une erreur de portée.

Le cas inverse interdit de considérer n comme un verdict universel. RFC 3977 prévoit qu'un client disposant de privilèges spéciaux, dont la nature reste hors de la norme, puisse publier dans un groupe marqué n. L'état garde sa valeur : il décrit la règle habituelle, sans prétendre recenser toutes les exceptions.

L'indépendance figurait déjà dans RFC 977

En 1986, RFC 977 définissait la réponse LIST avec quatre champs : nom du groupe, dernier numéro connu, premier numéro et indicateur y ou n. Cette représentation compacte permettait de parcourir de nombreux groupes sans interroger chacun d'eux.

Le texte ajoutait immédiatement une réserve décisive. Un serveur pouvait interdire la publication à un client même si la liste déclarait le groupe ouvert. L'indicateur existait notamment pour distinguer les groupes ordinaires des groupes modérés ou de type digest. Il était indépendant de l'autorisation de publication accordée au client par le serveur.

La décision personnelle se trouvait dans l'échange POST. 340 invitait à transmettre l'article ; 440 signalait une interdiction pour une raison dépendant de l'installation. Le message d'accueil donnait lui aussi une indication sur les facultés de ce client, sans supprimer la décision du commandement réel.

Cette séparation ancienne évitait d'étendre une table de description en système global de droits. Le groupe avait une politique de base ; la connexion avait une identité et des permissions.

Ce que LIST ACTIVE promet, et rien de plus

RFC 3977 a nommé la variante LIST ACTIVE. Sans filtre, elle contient tous les groupes que le client est autorisé à sélectionner avec GROUP. Ce n'est donc pas un registre mondial d'Usenet, mais une vue locale offerte par un serveur à une connexion.

Chaque ligne fournit le nom, les repères haut et bas des numéros d'articles, puis l'état courant du groupe sur ce serveur. Les valeurs usuelles sont y pour publication permise, n pour publication non permise et m pour transfert vers le modérateur. Une valeur inconnue ne fournit aucune information exploitable ; le client ne doit pas lui inventer un sens.

La norme précise ensuite que l'état indique seulement la manière dont les contributions sont normalement traitées. Il n'est pas nécessairement personnalisé. L'interdiction visant un client s'applique aussi aux groupes y; un privilège particulier peut créer l'exception opposée dans un groupe n.

Le mot « normalement » n'affaiblit pas la donnée. Il la rend honnête. Un seul tableau peut résumer le fonctionnement des groupes sans recopier toutes les règles de comptes, d'adresses sources, de protection du transport ou d'administration locale.

La commande réelle produisait sa propre trace

Sous RFC 3977, POST se déroule en deux décisions. Avant le corps, le serveur répond 340 ou 440. Après réception du texte, il répond 240 ou 441. Un refus préalable protège le brouillon d'une transmission inutile ; un échec final indique que le contenu a traversé la liaison mais n'a pas été accepté.

Même 240 ne prouve pas que l'article est déjà lisible. Une modération, un traitement ou une transmission ultérieure peut rester nécessaire. Le client doit vérifier la disponibilité séparément. Une pastille unique « publication possible » efface donc au moins quatre états : politique du groupe, permission de soumettre, acceptation de l'article et exposition aux lecteurs.

Cette distinction devient une question de confidentialité lorsque le corps contient une information sensible. Envoyer le texte en se fondant seulement sur y, puis découvrir l'absence de droit, crée une divulgation irréversible que la bonne interprétation du protocole aurait évitée.

Une identité reconnue n'obtenait pas tout

RFC 4643 a formalisé AUTHINFO. La réponse 480 indique qu'une authentification et/ou une autorisation est nécessaire pour la commande ou la ressource. Après authentification, le serveur peut présenter d'autres capacités, car l'état de la session a changé.

Mais une authentification réussie n'accorde pas un passe-partout. La norme autorise le serveur à refuser encore une partie ou la totalité des ressources avec 502. L'authentification établit un principal ; la politique du site attribue les droits de ce principal.

Ainsi, la ligne LIST ACTIVE, le résultat AUTHINFO et la réponse à la commande sont trois preuves non substituables. Un cache indexé uniquement par le nom du groupe et son état ignore les changements d'identité, de TLS, de serveur ou de politique.

m indiquait un parcours, pas une personne légitime

L'état m annonce le transfert vers un modérateur. Il ne prouve ni l'identité de ce modérateur ni l'approbation future. RFC 5537 sépare les agents de composition, d'injection, de relais, de service, de lecture et le rôle du modérateur, car chacun contrôle une étape différente.

Un autre article de Sofia Ren traite déjà le champ Approved et l'autorité de modération. Ici, m sert seulement à montrer que la liste décrit un chemin ordinaire. Le droit de soumettre ne prouve pas l'auteur, l'acceptation ne garantit pas le relais, et le relais ne garantit pas la visibilité.

Des noms séparés pour des pouvoirs séparés

Le registre IANA des paramètres NNTP enregistre séparément LIST, POST, AUTHINFO et READER. Il ne mesure pas leur déploiement actuel, mais empêche que découverte, soumission, identité et lecture soient confondues dans un même signal de protocole.

La leçon dépasse Usenet. Un index est utile parce qu'il condense une politique générale. Il devient dangereux lorsqu'une interface le présente comme une décision individuelle. Le feu était bien vert, mais il éclairait le groupe, pas votre autorisation.

Sources