Usenet : fonctionnement, NNTP, hiérarchies et binaires

D’où vient Usenet et ce qu’il en reste

En 1979, Tom Truscott et Jim Ellis, étudiants à Duke University, relient deux machines Unix par UUCP, c'est-à-dire par appel modem, pour s'échanger des messages. Le logiciel A News est diffusé publiquement en 1980. Usenet est donc antérieur à la généralisation de TCP/IP : le réseau n'a jamais eu besoin d'Internet pour exister, il a simplement fini par circuler dessus quand NNTP est apparu en 1986.

Le principe n'a pas bougé depuis. Il n'existe aucun serveur central. Vous vous connectez à un serveur, celui de votre fournisseur d'accès autrefois, celui d'un fournisseur spécialisé aujourd'hui, et ce serveur possède sa propre copie des articles qu'il a reçus de ses voisins. Deux serveurs peuvent très bien avoir des contenus différents pour le même groupe : rétention plus courte, article jamais reçu, retrait après plainte.

Deux Usenet cohabitent en pratique. Le Usenet texte, celui des hiérarchies Big 8 et des hiérarchies nationales comme fr.*, tourne au ralenti mais reste accessible gratuitement (news.eternal-september.org demande une simple inscription). Le Usenet binaire est devenu un marché commercial : abonnement mensuel, dizaines de connexions SSL simultanées, rétention affichée en milliers de jours.

Un repère utile pour situer l'époque : Google Groups, qui hébergeait l'archive rachetée à DejaNews et remontant à mai 1981, a cessé de relayer le contenu Usenet le 22 février 2024. Les anciens messages restent consultables, mais plus rien n'y est publié ni reçu depuis cette date.

• 1979 : premiers échanges par UUCP entre Duke et l'Université de Caroline du Nord
• 1986 : NNTP est spécifié dans la RFC 977 par Brian Kantor et Phil Lapsley
• 1986-1987 : le Great Renaming réorganise les groupes en grandes hiérarchies, la Big 8 actuelle en descend
• 1987 : création de la hiérarchie alt.*, hors du processus de vote officiel
• septembre 1993 : AOL ouvre Usenet à ses abonnés, l'épisode surnommé Eternal September
• avril 1994 : le message publicitaire Green Card de Canter et Siegel, premier spam massif du réseau
• 2001 : l'encodage yEnc rend le transport de fichiers binaires nettement moins coûteux
• février 2024 : Google Groups coupe la publication et la réception du contenu Usenet

NNTP en clair : ports, session type et codes de réponse

NNTP est un protocole texte, ligne par ligne, très proche de SMTP dans son esprit. Vous pouvez donc l'inspecter à la main. La commande suivante ouvre une session chiffrée sur le port dédié : openssl s_client -connect news.exemple.net:563 -crlf. Répondez ensuite CAPABILITIES pour voir ce que le serveur accepte (le serveur répond 101 puis liste ses extensions).

Le point de sécurité à retenir tient en une ligne : l'authentification AUTHINFO USER puis AUTHINFO PASS, définie par la RFC 4643, transmet le mot de passe en clair. Sur le port 119 sans TLS, il circule tel quel, et les noms de groupes que vous ouvrez sont visibles de n'importe quel équipement sur le trajet. La RFC 8143 (2017) tranche : TLS implicite sur 563, et STARTTLS sur 119 seulement en dépannage.

Voici à quoi ressemble un échange réel après connexion.

Sur les gros groupes binaires, télécharger l'index des en-têtes avec OVER ou XOVER peut représenter plusieurs centaines de mégaoctets. La RFC 8054 (2017) ajoute pour cela une extension COMPRESS DEFLATE, que la plupart des fournisseurs commerciaux implémentent et qui divise très largement ce volume.

• 200 news.exemple.net InterNetNews NNRP server ready (posting ok)
• AUTHINFO USER moncompte
• 381 Enter passphrase
• AUTHINFO PASS ***********
• 281 Authentication accepted
• GROUP fr.comp.reseaux.ip
• 211 3820 118442 122261 fr.comp.reseaux.ip
• ARTICLE 122261
• 220 122261 article retrieved

Port	Usage	Chiffrement	Référence
119	Lecture, publication, transit entre serveurs	Aucun par défaut, STARTTLS possible	RFC 3977, RFC 4642
563	NNTPS, port dédié aux lecteurs	TLS dès l'ouverture de la connexion	RFC 4642, RFC 8143
433	NNSP, alimentation serveur à serveur	Aucun	Assignation IANA, très peu déployée

Comment un article se propage de serveur en serveur

Quand vous publiez, votre serveur attribue à l'article un Message-ID unique de la forme <8f1k9d2ta$1@news.exemple.net>. Cet identifiant est la clé de tout le système. Chaque serveur tient un fichier d'historique : si un voisin lui propose un Message-ID qu'il a déjà, il refuse l'article et la copie s'arrête là. C'est ce qui évite qu'un message tourne indéfiniment dans un réseau maillé.

Le second garde-fou est l'en-tête Path, décrit dans la RFC 5537. Chaque serveur traversé ajoute son nom en tête, ce qui donne par exemple Path: news.exemple.net!feeder.fournisseur.net!not-for-mail. Un serveur ne proposera jamais un article à un voisin déjà présent dans ce Path. Lisez-le de droite à gauche pour reconstituer le trajet.

Deux modes de transfert coexistent. IHAVE, historique, demande au voisin s'il veut l'article avant de l'envoyer, ce qui coûte un aller-retour par message. Le mode streaming CHECK/TAKETHIS de la RFC 4644 permet d'envoyer sans attendre, indispensable dès qu'un flux dépasse quelques millions d'articles par jour.

Il existe aussi des messages de contrôle : cancel pour supprimer un article, newgroup et rmgroup pour créer ou retirer un groupe, checkgroups pour resynchroniser une hiérarchie. Comme forger un cancel est trivial, la quasi-totalité des serveurs ignorent aujourd'hui les cancel non signés, et la Big 8 signe ses messages de contrôle en PGP, vérifiés côté serveur par l'outil pgpverify livré avec INN.

Enfin, chaque serveur décide seul de sa durée de conservation. Sur INN, elle se règle groupe par groupe dans expire.ctl. Un article encore lisible chez un fournisseur peut avoir disparu chez un autre depuis des mois, sans que personne ait rien supprimé volontairement.

Les binaires : yEnc, NZB, PAR2 et l’erreur 430

Un article Usenet transporte du texte, pas des octets bruts. Pour y faire passer un fichier, il faut l'encoder, et le choix de l'encodage se paie directement en bande passante. uuencode gonfle un fichier d'environ 35 %, base64 d'environ 33 %. yEnc, publié en 2001 par Jürgen Helbing, n'échappe que quelques octets critiques (NUL, LF, CR et le signe égal) et retombe autour de 1 à 2 % de surcoût. Ce seul changement a rendu le transport de gros fichiers viable.

Un fichier de plusieurs gigaoctets ne part pas en un bloc : il est découpé, souvent en archive RAR multivolume, puis chaque volume est réparti sur des milliers d'articles de quelques centaines de kilooctets. Retrouver ces articles en parcourant le groupe serait absurde. D'où le fichier NZB, un simple XML apparu au début des années 2000 chez Newzbin, qui liste les Message-ID de tous les articles composant le lot. Le client (SABnzbd, NZBGet) les demande directement avec ARTICLE , sans jamais lire l'index du groupe.

Reste le problème des trous. Un article peut manquer parce qu'il a expiré, parce qu'il n'a jamais été propagé jusqu'à ce serveur, ou parce qu'il a été retiré après une plainte. Le serveur répond alors 430 No such article, et le téléchargement est incomplet. Les fichiers de parité PAR2, fondés sur un code de Reed-Solomon, servent exactement à ça : un jeu de parité à 10 % permet de reconstruire jusqu'à environ 10 % de blocs perdus.

Sur la rétention, prudence avec les chiffres affichés. Les fournisseurs annoncent couramment plus de 5 000 jours, soit largement plus de dix ans. C'est un argument commercial qu'aucun utilisateur ne peut vérifier de l'extérieur : ce que vous constatez réellement, c'est la disponibilité d'un article donné sur le backbone qu'utilise votre fournisseur, à un instant donné.

• Encodage : yEnc, environ 1 à 2 % de surcoût contre 33 % pour base64
• Découpage : archive RAR multivolume, puis un article par tranche
• Index : fichier NZB listant les Message-ID, lu par SABnzbd ou NZBGet
• Réparation : jeu PAR2 dimensionné en pourcentage du lot, typiquement 10 %
• Symptôme d'un trou : réponse NNTP 430, suivie d'un basculement sur un compte de secours

Usenet, NNTP, BitTorrent : ce que votre adresse IP y laisse

Première confusion à lever : Usenet et NNTP ne désignent pas la même chose. Usenet est le réseau et l'ensemble des règles qui le régissent, format des articles compris (RFC 5536 et RFC 5537, publiées en 2009, qui remplacent la vieille RFC 1036 de 1987). NNTP est le protocole de transport (RFC 3977). Une entreprise peut monter un serveur NNTP interne sans jamais toucher à Usenet, et Usenet a fonctionné pendant sept ans sur UUCP avant que NNTP n'existe.

Deuxième confusion, plus courante : Usenet n'est pas du pair à pair. Vous n'ouvrez pas de connexion vers d'autres utilisateurs et personne ne se connecte à vous. Le trafic est un simple flux client-serveur en TCP, généralement une vingtaine de connexions simultanées vers le même hôte pour saturer le lien. Aucun autre abonné ne voit votre adresse IP, contrairement à un swarm BitTorrent où elle est publique par construction. En revanche votre fournisseur, lui, la connaît et la journalise.

Le point que beaucoup d'utilisateurs découvrent trop tard concerne la publication, pas le téléchargement. Quand vous postez, de nombreux serveurs ajoutent votre adresse IP dans l'en-tête de l'article, sous la forme moderne Injection-Info: news.exemple.net; posting-host="203.0.113.42" ou sous l'ancienne forme NNTP-Posting-Host:. Cet en-tête part avec le message, se propage sur tous les serveurs et se retrouve dans les archives publiques. Affichez les en-têtes complets d'un de vos propres messages avant de considérer Usenet comme anonyme.

Troisième différence, avec les forums web : il n'existe ni compte central, ni base unique, ni modération globale. Un groupe modéré fonctionne par redirection des envois vers l'adresse d'un modérateur qui réinjecte les messages approuvés. Partout ailleurs, la seule modération réelle est celle que votre serveur applique à ce qu'il accepte de recevoir et de conserver.

Questions fréquentes

Faut-il payer pour accéder à Usenet ?

Pour le texte, non. Des serveurs comme news.eternal-september.org donnent un accès gratuit aux hiérarchies Big 8 et nationales après une inscription, et certains fournisseurs d'accès historiques proposent encore un serveur maison. Pour les binaires, oui : la rétention longue, les connexions simultanées et la bande passante impliquent un abonnement mensuel chez un fournisseur commercial, parfois complété par un compte de secours facturé au volume pour combler les articles manquants.

Quelle différence exacte entre Usenet et NNTP ?

NNTP est le protocole qui transporte les articles entre un lecteur et un serveur, ou entre deux serveurs (RFC 3977, ports 119 et 563). Usenet est le réseau lui-même : l'ensemble des serveurs qui s'échangent ces articles, les hiérarchies de groupes et le format des messages défini par les RFC 5536 et 5537. On peut utiliser NNTP sur un serveur privé sans être relié à Usenet.

Un VPN change-t-il quelque chose sur Usenet ?

Moins qu'on ne le croit. Sur le port 563, la connexion est déjà chiffrée en TLS, donc votre opérateur voit seulement que vous parlez à un serveur de news, pas ce que vous y faites. Un VPN masque cette destination à l'opérateur et remplace votre IP par celle du VPN vis-à-vis du fournisseur Usenet. Il ne change rien au fait que le fournisseur associe une activité à un compte payant nominatif.

Pourquoi mon téléchargement s’arrête sur une erreur article not found ?

Le serveur répond 430 : le Message-ID demandé par le NZB n'existe pas dans sa base. Trois causes possibles, l'expiration liée à la rétention du serveur, un défaut de propagation à l'époque de la publication, ou un retrait après plainte. Le client tente alors le même Message-ID sur un fournisseur secondaire, puis reconstruit les blocs manquants avec les fichiers PAR2 si le jeu de parité est suffisant.

Peut-on encore lire les archives des années 1980 ?

Oui, en partie. L'archive UTZOO, sauvegardée à l'Université de Toronto, couvre février 1981 à juin 1991 et est consultable sur archive.org. L'archive reprise par Google auprès de DejaNews remonte à mai 1981 et reste accessible en lecture dans Google Groups, même si le service ne relaie plus le contenu Usenet depuis février 2024. Aucune de ces archives n'est complète : ce sont des collectes partielles, pas un registre officiel.

Testez vos connaissances

À lire aussi

certificat ssl · client email · bande passante · confidentialite en ligne