Résumé

  • La RFC 1036 liait cancel à la présence locale de l’article visé ; un serveur incapable de l’annuler ne devait pas transmettre la requête à ses voisins.
  • La commande empruntait la diffusion ordinaire des groupes Usenet, tandis que la règle auteur ou administrateur local et la comparaison des en-têtes limitaient son émission.
  • Le texte décrit une règle de spécification bornée, pas la disparition de l’article de tous les serveurs, archives ou copies lues.

Une instruction pouvait circuler sans devenir universelle

Dans Usenet, recevoir une commande ne suffisait pas à lui donner prise sur tout le réseau. La RFC 1036, publiée en décembre 1987 par Mark Horton et Richard Adams, appelle « message de contrôle » un article doté d’un champ Control et destiné aux machines hôtes. Ces messages empruntaient le mécanisme de diffusion des groupes de discussion, comme les nouvelles ordinaires. La commande était donc distribuée, mais pas dotée d’un pouvoir central.

La syntaxe tenait en deux éléments : cancel et un Message-ID. Le serveur ne pouvait annuler le message que si celui-ci figurait sur son système local. Et si ce n’était pas le cas — ou si l’annulation demandée échouait — la RFC disait de ne pas transmettre la demande aux systèmes voisins. Le point d’arrêt se trouvait ainsi au premier endroit où l’action locale ne pouvait être menée à bien.

Ce détail change la lecture de la fonction. Une annulation dans Usenet n’était pas un bouton « supprimer partout ». La RFC décrit ce qu’un hôte doit faire avec l’article qu’il détient, selon une requête admissible. Elle ne donne pas à un serveur le moyen d’effacer une copie distante qu’il ne peut ni localiser ni administrer.

Le message de contrôle restait dans le flux des nouvelles

Le champ Control était facultatif dans le format des articles. Sa présence signalait une instruction destinée au logiciel hôte, non un texte ordinaire pour le lecteur. Le message lui-même circulait selon le mécanisme des groupes Usenet. La RFC laissait aux développeurs et aux administrateurs le choix entre un traitement automatique et une mise en file d’attente ; les messages traités à la main devaient l’être rapidement. Les échecs de contrôle devaient être adressés au compte local usenet, pas à l’expéditeur du message.

Il faut distinguer trois étapes : arrivée de la commande, décision du logiciel local, puis éventuelle action sur la copie détenue. Un serveur pouvait automatiser ou mettre en attente le traitement ; dans les deux cas, il devait retrouver le Message-ID et appliquer la règle d’expéditeur. Le réseau distribuait la demande, mais il ne centralisait ni les états locaux ni les résultats.

L’auteur était identifié par des champs, pas par une signature

La RFC réservait l’envoi d’un cancel à l’auteur de l’article ou à l’administrateur local des nouvelles. Pour comparer les messages, elle appelle « expéditeur vérifié » la valeur du champ Sender ; si ce champ manque, elle retient From. L’expéditeur du cancel devait correspondre à Sender ou From dans l’article d’origine. Le texte accepte aussi que l’expéditeur vérifié du cancel corresponde à un From d’origine qui n’était pas vérifié.

Cette règle est précise, mais sa portée reste celle d’une comparaison d’en-têtes. RFC 822 décrit le rôle de Sender quand la personne ou l’agent qui soumet un message n’est pas son auteur ; RFC 1036 applique ensuite ces champs au cancel. Aucun des deux textes ne transforme ce contrôle en signature numérique ou en preuve moderne de l’identité d’un compte. Le document prescrit une vérification de format, il ne démontre pas qu’elle était impossible à falsifier.

Ce que RFC 1036 a ajouté à RFC 850

La RFC 1036 remplace et actualise RFC 850 pour la version B2.11 du logiciel News. Le texte de 1983 prévoyait déjà qu’un article présent localement puisse être annulé par son auteur ou par un superutilisateur local. En 1987, la fonction est attribuée à l’administrateur local des nouvelles, et une phrase nouvelle encadre l’échec : un serveur incapable d’annuler ne transmet pas la demande.

Ce changement appartient au texte publié. Il ne prouve pas que tous les sites Usenet ont adopté la même version ni à quelle date. La RFC 1036 précise d’ailleurs qu’elle ne spécifie pas une norme Internet. Elle documente le format et quelques règles de transmission d’Usenet, tout en laissant aux hôtes de la latitude pour choisir leur matériel, leur logiciel et le regroupement des nouvelles.

Une action locale ne clôt pas l’histoire des copies

Un hôte peut avoir l’article et traiter une demande admissible. Un autre peut ne pas le trouver, auquel cas il s’arrête. Une archive distincte peut conserver une copie. Le texte règle le comportement du système local dans une situation donnée ; il ne prétend pas que la commande efface les archives, les citations, les index ou ce qu’un lecteur a déjà vu.

On peut déduire de cette limite que la propagation d’une commande devait rester liée à une preuve locale d’action. Mais il s’agit d’une lecture éditoriale : la RFC formule la condition d’arrêt, sans exposer cette justification. Garder les deux plans distincts évite de transformer un mécanisme précis en récit général sur la censure ou l’effacement universel.

Sources et limites

Les sources primaires sont RFC 1036, notamment les sections Control et Cancel, son prédécesseur RFC 850 et RFC 822 pour le champ Sender. Elles établissent le contenu des spécifications, pas leur adoption, le fonctionnement de chaque site, une latence réelle, une authentification cryptographique ou un effacement mondial.