Résumé

  • Une annulation Usenet était elle-même un article de contrôle, propagé par le réseau de nouvelles et visant un autre article grâce à son Message-ID.
  • Le retrait n’était jamais universel : chaque agent serveur appliquait ses règles, pouvait ignorer la demande ou mémoriser une préannulation reçue avant l’original.
  • Cancel-Lock et Cancel-Key ont ensuite ajouté une preuve cryptographique préparée dès la publication, sans garantir l’identité civile, l’intégrité complète ni l’effacement de toutes les copies.

Un verbe central dans un réseau sans centre

« Annuler » évoque une opération unique : une commande atteint la base principale, l’état change, les lecteurs voient le résultat. Usenet ne possédait ni base principale ni administrateur souverain. Des sites autonomes conservaient leurs propres spools et échangeaient des articles selon leurs liens et leurs politiques.

L’annulation devait donc emprunter le réseau qu’elle cherchait à corriger. Le RFC 850 décrivait en 1983 les messages de contrôle comme des messages distribués par le même mécanisme que les nouvelles ordinaires. Il laissait aussi aux responsables locaux le choix entre exécution automatique et examen humain. La norme coordonnait la forme de la demande ; elle ne transférerait jamais la maîtrise de chaque disque à son émetteur.

Cette nuance explique la scène des trois serveurs. Là où l’article existe et où la politique l’autorise, il devient indisponible. Là où l’autorisation paraît insuffisante, il reste visible. Là où l’annulation précède l’original, le serveur peut retenir une information négative. Il n’existe pas un instant mondial auquel « le message est annulé ». Il existe une série de décisions portant sur des copies locales.

Le Message-ID répondait à « quoi ? », pas à « au nom de qui ? »

La syntaxe historique cancel <message ID> avait une qualité essentielle : elle nommait la même entité logique malgré la dispersion de ses copies. Le RFC 1036, en 1987, maintenait cette cible et précisait l’effet local. Il demandait même à un système incapable d’annuler de ne pas relayer la demande à ses voisins.

Un Message-ID stabilise la référence. Il ne constitue ni un titre de propriété ni une signature. Les premières règles autorisaient l’auteur ou un superutilisateur local et comparaient les champs Sender ou From du message de contrôle avec ceux de l’article visé. C’était une convention pratique entre sites coopérants, pas une authentification robuste. Copier une adresse dans un en-tête ne prouve pas que son titulaire a approuvé l’opération.

Le RFC 5537 a tiré la conséquence de cette faiblesse. Il a supprimé l’obligation de cette comparaison, jugée dépourvue de sécurité et incitant à dissimuler certaines informations. L’architecture de base ne lui a pas substitué une identité mondiale. Un site pouvait recourir à une méthode locale, non normalisée ou humaine, et n’était jamais obligé d’exécuter un article de contrôle.

Il s’agit moins d’une lacune que d’un aveu institutionnel. Une fédération ouverte peut partager un vocabulaire de retrait sans accepter une autorité unique sur tous ses exemplaires. La norme a préféré exposer la décision locale plutôt que d’appeler « authentification » une égalité de chaînes de caractères.

La préannulation empêchait une résurrection locale

Un réseau distribué n’impose pas un ordre d’arrivée identique. L’annulation peut suivre une route plus rapide, tandis que l’article original attend dans une file. Lorsque le contrôle arrive le premier, retirer un objet absent ne suffit pas : il faut se souvenir de son identité.

Le RFC 5537 prévoit cette préannulation. L’agent serveur peut enregistrer le Message-ID visé puis rejeter l’original s’il apparaît plus tard. Ce petit état négatif ressemble à une pierre tombale : il maintient l’effet d’un événement antérieur face à une réplique retardée.

Sa portée reste pourtant locale. Un autre site peut ne jamais recevoir l’annulation, oublier trop tôt sa préannulation ou refuser ce mécanisme. Utiliser des groupes de nouvelles voisins de ceux de l’original augmente les chances d’atteindre les mêmes serveurs, sans les rendre identiques. Dans un groupe modéré, les règles du champ Approved ajoutent encore une condition.

Le remplacement par Supersedes conserve la même frontière. Le RFC 5536 définit ce champ qui désigne un article antérieur ; le RFC 5537 demande d’appliquer au retrait les mêmes contrôles d’autorisation qu’à une annulation. Publier une nouvelle version ne prouve donc pas, à lui seul, le droit de faire disparaître l’ancienne.

Le plan de contrôle pouvait servir la correction ou l’attaque

Tout mécanisme capable de soustraire un texte à la lecture devient une cible. Une annulation forgée pouvait censurer un article légitime. Une automatisation très large pouvait combattre le spam, mais aussi imposer une politique que d’autres sites ne partageaient pas.

Le RFC 2635 mentionne les cancelbots parmi les réactions opérationnelles aux publications répétées ou massivement croisées. Ce document éclaire la pression qui a produit ces outils. Il ne leur confère aucune compétence universelle : chaque demande rencontrait encore les règles de chaque serveur.

Le RFC 5537 constate que de nombreux sites ont ignoré cancel et Supersedes à cause des abus et de la difficulté d’authentifier l’émetteur. Ce refus réduisait la capacité de corriger ou de modérer ; l’exécution automatique augmentait le risque de suppression frauduleuse. Usenet ne pouvait éliminer ce compromis par la seule syntaxe.

Une serrure placée avant que la clé ne soit présentée

Le RFC 8315, publié en 2018, apporte une réponse cryptographique délimitée. Lors de la préparation de l’article original, un acteur peut y placer un Cancel-Lock, valeur de hachage construite à partir d’un secret qu’elle ne révèle pas. Plus tard, l’annulation ou l’article doté de Supersedes présente un Cancel-Key. L’agent participant vérifie que la clé correspond à l’un des verrous déjà présents.

La preuve est préengagée. Elle ne dépend plus seulement d’un From recopiable après coup. L’auteur, l’agent de publication, le modérateur ou l’agent d’injection peuvent chacun disposer d’un chemin de retrait. Les relais situés après l’injection ne doivent pas modifier les verrous. En présence de plusieurs verrous, la connaissance du secret correspondant à l’un d’eux peut suffire selon la procédure.

Cette construction démontre une proposition précise : le demandeur connaît un élément lié à une autorisation de retrait préparée pour cet article. Elle ne démontre pas que tous les champs sont intacts. Le RFC 8315 avertit que Cancel-Lock n’assure pas l’intégrité générale de l’article. La preuve n’établit pas non plus une identité civile, n’oblige pas le serveur à agir et n’atteint pas les dépôts qui ne participent pas.

Le registre IANA des paramètres Netnews coordonne les noms et statuts des algorithmes. SHA-256 est l’algorithme obligatoire du RFC 8315 ; le registre distingue aussi SHA-512, MD5 devenu obsolète et SHA-1 d’usage limité. Une inscription au registre ne mesure ni le déploiement actuel ni le taux de succès des retraits.

Le reçu raisonnable s’arrête au serveur qui le produit

Une annulation comporte plusieurs événements qu’une interface pourrait confondre : création de la demande, propagation, réception, validation de la preuve, application de la politique et changement de disponibilité. Une confirmation de chacune de ces étapes ne prouve que cette étape.

Même un serveur ayant validé Cancel-Key ne parle que de son jugement. Même un serveur ayant retiré sa copie ne parle que de son spool. Une archive, une passerelle, un autre pair ou un lecteur ayant sauvegardé le texte restent hors de cette autorité. Des champs exprimant un souhait d’archivage ou de distribution ne peuvent imposer une politique à toutes les machines d’un protocole ouvert.

La leçon d’Usenet est donc une discipline de langage autant qu’une architecture. Il faut distinguer la demande de retrait, sa preuve, son exécution et la disparition observable. « Cet agent ne sert plus cet article » est vérifiable. « Le réseau a oublié » est une promesse que la fédération n’a jamais été construite pour tenir.

Sources