Étude aprofondie de Usenet

/you-z*-nait/ ou /u-ze-nait/ np. m.
[USENET] Autrefois écrit « USENET », mais il n'est pas nécessaire de tout mettre en majuscules, car ce n'est pas un sigle - ? Il paraît que cela veut dire « Unix uSErs NETwork » (© Rheingold)... ou même « USEr's NETwork » (Jargon File 3.0.0). Qui a raison ?
Usenet est le plus gros système décentralisé d'information du monde, tournant sur des machines principalement Unix, mis au point en 1979-80 à l'université de Duke. Les messages, souvent appelés « articles » car ils sont publics, sont publiés dans des newsgroups, ou groupes ou forums, chacun portant sur un sujet particulier. Au total plusieurs centaines de milliers d'articles sont ainsi publiés chaque jour. Malheureusement, il y en a de plus en plus qui sont sans intérêt (spam).

Qu'est-ce que Usenet ?
Un protocole binaire ayant eu les premiers forums de discussion qui ont existé bien longtemps avant Internet

Usenet est le terme générique employé pour parler de ce qu'on nomme le plus souvent ``les forums de discussion'' ou ``News'' (ou, comme les appellent certains magazines, les "infogroupes").

Usenet diffère du courrier électronique parce qu'il permet des discussions de N vers N, et non plus de 1 vers 1 (ou de 1 vers N dans le cas des listes de discussion). Si le courrier électronique est un dialogue, et les listes de diffusion sont une table ronde, Usenet est une série de salles de réunions publiques thématiques ouvertes à tous.

Le terme Usenet englobe tous les espaces publics de discussion "en différé", c'est à dire dans lesquels un intervenant poste un article qui sera lu par tous, et auquel il pourra être répondu plus tard (à l'inverse de l'IRC par exemple) par n'importe qui, qui utilisent le protocole NNTP (Network News Transfer Protocol).

Ces espaces publics, salles de réunions thématiques virtuelles, sont réunis selon différentes langues ou différentes organisations. On parle de "hiérarchies" 1 différentes pour séparer ces ensembles.

Chaque hiérarchie est organisée en forums thématiques. L'usage veut que le nom de chaque forum soit formé de plusieurs mots séparés par des points. Le premier mot est commun à toute la hiérarchie (c'est d'ailleurs le plus souvent le nom donné à la hiérarchie: on parle de la hiérarchie "fr" pour l'ensemble des forums dont le nom commence par "fr.", le second spécifie le cadre général des discussions dans ce forum (social, informatique, artistique ou autre), les mots suivants définissent plus ou moins précisément selon leur numéro d'ordre le thème particulier du forum 2

Un forum dont le nom serait, par exemple, fr.rec.sport.voile.planche fera partie de la hiérarchie "fr" (et sera donc régi par les règles d'usage générales définies pour cette hiérarchie), dans le domaine RECréatif, et traitera plus spécifiquement des SPORTs de VOILE utilisant une PLANCHE, autrement dit de la planche à voile. Une courte description est en général associée à un nom de forum. Pour notre exemple, la description pourrait être "Discussions sur la planche à voile", ce qui ne laissera aucun doute quant au thème abordé par les utilisateurs du forum.

Dans chacun de ces forums se déroulent donc des conversations dont le thème dépend du titre et de la description du forum. Il peut y avoir un grand nombre de discussions séparées les unes des autres à l'intérieur d'un seul et même forum, chacune étant distincte des autres grâce aux titres des articles postés dans cette discussion, et grâce aux références techniques qui sont présentes dans les champs techniques prévus à cet effet dans chaque article 3

Au niveau du forum, tout utilisateur est soit un lecteur passif, qui se contente de suivre les débats, soit un utilisateur actif, qui poste des articles. Ce sont ces articles qui constituent le contenu du forum et qui, lorsqu'ils participent d'une seule conversation, sont regroupés sous forme de [thread/fil/enfilade].

Un article posté dans un forum peut être lu par n'importe qui, à n'importe quel moment sur le serveur tant que la date d'expiration de l'article n'est pas dépassée. Cette "date d'expiration" varie selon les serveurs qui stockent les articles du forum, mais certains systèmes comme https://www.deja.com/ permettent de lire des articles postés depuis plus de 2 ans.

Comment ça fonctionne ?

Côté serveur
* Prenez un ordinateur (nommons-le "1"), et ses utilisateurs.
* Créez sur cette machine un 'tableau noir' sur lequel tout utilisateur peut laisser un message aux autres, et y répondre.
* Ajoutez un second ordinateur doté du même outil, et ses utilisateurs. (Penser à relier le second au premier). Nommons-le "2".
* Développez un protocole d'échange permettant au 'tableau noir' du premier d'envoyer les messages qui sont écrits sur "1" vers "2", et réciproquement.

A ce stade nous disposons de deux "espaces" séparés mais dont le contenu est identique à tout instant, contenu formé par les articles postés indifféremment sur l'un ou sur l'autre.
* Ajoutons une troisième machine, reliée aux deux autres pour former un triangle (avec deux liens, un par machine, donc) et doté du même outil. Nous l'appellerons "3" pour faire preuve d'originalité.

Le protocole développé doit maintenant permettre un échange de messages à trois:

"1" envoie un message à "2".
" 3" envoie un message à "1".

"1" et "2" ont donc reçu chacun un message. Le premier est commun à "1" et "2", le second est commun à "1" et "3". Or nous voulons que tous les messages soient reçus par tous les ordinateurs. Il y a plusieurs solutions:

"2" peut décider d'envoyer le message reçu de "1" à "3". Ou "1" peut décider de renvoyer son message à "3" juste après l'avoir envoyé à "2". De même, "3" peut envoyer son message à "2" comme "1" peut l'envoyer au même "2" à tout instant. Ça fait un bel embrouillamini, il faut mettre des étiquettes aux messages: puisque "2" risque de recevoir un message de "1" à la fois de "3" et de "1", alors il va regarder l'étiquette de chaque message qu'il reçoit, et refuser de recevoir un message dont l'étiquette est déjà présente sur son tableau. "1" et "3" feront de même.

Le protocole une fois bien construit pour éviter les messages en doubles tout en assurant la bonne diffusion desdits messages, ajoutez autant d'ordinateurs que nécessaire pour le nombre de convives envisagé. Vous avez terminé votre NNTP, et Usenet est né.

Côté client

Lorsque votre lecteur de News va se connecter pour la première fois à votre serveur local (en général celui de votre fournisseur d'accès à Internet, le plus couramment nommé news.nom-de-votre-fournisseur.fr), il va lui demander la liste des forums de discussion dont celui-ci dispose: un serveur peut en effet ne recevoir qu'une partie des différentes arborescences (hiérarchies) décrites plus haut, ou seulement certaines parties de certaines hiérarchies.

Vous aurez alors à votre disposition une liste de thèmes, donc de forums, que vous pourrez parcourir au hasard de vos intérêts. Ou bien encore parmi lesquels vous allez faire votre choix et sélectionner uniquement les groupes qui recouvrent vos intérêt, de manière à ce que votre lecteur ne vous présente par la suite que la liste de ces groupes choisis. Cette opération est abusivement appelée 'abonnement' ou 'désabonnement' à un groupe ('subscribe' ou 'unsubscribe'). En réalité il ne s'agit que de constituer la liste des forums dont votre lecteur ira chercher le contenu sur son serveur.

Une fois cette liste établie, lorsque vous ouvrirez l'un de 'vos' groupes, votre lecteur affichera les différentes discussions en cours dans ce groupe. A vous alors d'y participer, en simple lecteur ou en participant actif. En règle générale, il est conseillé, avant d'intervenir activement dans un tel forum, de n'agir qu'en simple lecteur durant un certain temps, variable selon les personnes et les groupes, mais suffisant pour vous faire une idée des thèmes et des débatteurs. Comme lorsqu'on débute en société, il vaut mieux attendre de savoir un peu à qui l'on s'adresse et de quoi l'on cause avant de l'ouvrir: il n'est pas rare par exemple qu'un nouvel utilisateur inattentif poste une question technique sur le fonctionnement de son traitement de texte dans le groupe fr.usenet.logiciels, qui s'il traite bien de logiciels, ne traite que des logiciels en rapport avec Usenet, tels que serveurs ou lecteurs de news.

Si vous décidez d'intervenir, vous pouvez alors soit répondre directement à l'auteur d'un article, s'il s'agit par exemple d'une question technique dont vous connaissez la réponse c'est même conseillé: c'est à l'auteur de la question de poster une synthèse des réponses qu'il aura reçu en public, de façon à éviter que chacun, pensant se rendre utile, poste en X exemplaires la même réponse. Vous pouvez aussi décider de poursuivre en public une discussion, ou d'en lancer une vous-même (voir ci-dessous: Lisibilité). Dans ce cas, il s'agira d'un 'follow-up' et l'article sera posté sur votre serveur puis propagé par ce dernier à tous les serveurs du monde qui hébergent ce même forum sur lequel vous intervenez.

Ce type de règles, en réalité relevant le plus souvent de la simple courtoisie mais qui tiennent aussi compte de la spécificité d'un espace de débats ouvert à tous, il s'agit par exemple pour les plus élémentaires:

Lisibilité

Choisissez un sujet précis et concis lorsque vous ouvrez une discussion. Limitez la taille de vos lignes à 70 caractères de manière à ce que votre texte puisse être décalé à droite sous forme de citation par celui qui vous répondra sans que cette citation ne déborde des 80 caractères qui limitent bon nombre de terminaux. Faites le plus possible attention à votre orthographe, puisque vous vous exprimez en public. Lorsque vous citez un article ne citez que les quelques lignes auxquelles vous répondez plutôt que l'article en entier...

Utilité

Souvenez-vous que, contrairement au courrier électronique, un article posté sur Usenet sera potentiellement lu par un nombre considérable de personnes. N'entretenez pas de conversations privées dans un groupe public (le courrier électronique est fait pour ça). Évitez de réagir trop violemment, ce qui ne peut que dégénérer en engueulades (flame-war) publiques et inutiles. Éviter de poser une question qui à l'évidence aura déjà été posée des centaines de fois sur ce groupe, parce que trop générique. Il existe pour chaque groupe une FAQ (Foire Aux Questions), document reprenant ces questions par trop habituelles et y répondant (voir Terminologie).

Courtoisie

Ne publiez pas en public un message reçu en privé sans l'accord de son auteur. Même s'il vous semble que votre article est particulièrement important, ne le postez pas dans chacun des groupes que vous lisez: il ne correspondrait sûrement par à la charte de chacun de ces groupes. Lorsque vous voulez malgré tout poster un article identique dans plusieurs groupes (pas plus de 3 ou 4, en tout état de cause, au delà ce serait considéré comme un abus des ressources du réseau), utilisez un "cross-post" (voir Terminologie) plutôt que de poster l'article séparément dans chacun des groupes (multi-post), et ajoutez un champ "Followup-To" pour que la discussion qu'engendrera votre article n'ait lieu que dans un seul groupe, le plus adéquat.

Ce savoir-vivre a peu à peu acquis une réalité tangible, et ces règles sont réunies sous le nom de 'nétiquette', dont une grande partie traite des règles de comportement à utiliser sur Usenet. Un tel média ouvert à tous est en effet un écosystème fragile qui ne peut fonctionner bien que si chacun y met un peu du sien. En particulier, depuis peu, on peut trouver pour presque chaque forum francophone une "charte", initialement rédigée lors de la création du forum, et qui rappelle les règles en usage sur ce forum précis. Ces chartes sont postées régulièrement deux fois par semaine sur chacun des forums francophone ainsi que dans le forum fr.usenet.reponses: il vous sera donc facile de la trouver et de la lire avant tout autre chose lorsque vous découvrirez un forum parlant d'un thème qui vous concerne. Ces chartes sont aussi disponibles sur un site Web qui les regroupe toutes: https://www.usenet-fr.news.eu.org/. Vous y trouverez aussi différents documents, tels que la 'nétiquette', en rapport avec le bon usage d'Usenet.

Un article

Désossage d'un article typique:

Path: jussieu.fr!freenix!ecole.fr!not-for-mail
From: Dave Null <dave@nowhere.fr>
Newsgroups: fr.usenet.divers
Subject: Re: Cours Usenet
Date: 22 Jun 1999 18:30:00 +0200
Organization: Ecole Ouverte
Lines: 10
Message-ID: <85n1xqkpbz.fsf@serveur.ecole.fr>
References: <7kri05$etv$1@serveur.ecole.fr>
NNTP-Posting-Host: news.ecole.fr
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
NNTP-Posting-Date: 22 Jun 1999 18:30:00 GMT

"Olivier Ricou" <ricou@ecole.fr> disait:

> Ce cours est trop long.

C'est vrai, mais on essaye d'aborder Usenet dans un peu tous ses aspects
sans pour autant négliger d'entrer dans le détail, alors c'est long,
forcément.

--
Dave Null

4

On voit qu'avant l'article proprement dit, un certain nombre de champs techniques sont présents. Certains servent à identifier l'auteur, l'heure, la date, l'organisation et le format du contenu. Ces champs seront utilisés par le logiciel de lecture pour présenter l'article. D'autres sont utilisés par les serveurs, pour retransmettre ou pour stocker l'article dans la base des articles courants.

Le champ 'Path' est utilisé par le serveur. Il indique que l'article a été posté sur le serveur "ecole.fr". Que ce serveur l'a envoyé au serveur "freenix" qui lui-même l'a envoyé au serveur "jussieu.fr", serveur sur lequel on a lu l'article ainsi présenté. Ce champ aura une autre valeur sur un autre serveur, qui l'aura reçu par d'autres voies. Le serveur qui reçoit un article peut se baser sur ce champ pour éviter de proposer cet article aux serveurs par lesquels il est déjà passé, même s'il dispose d'une voie directe vers ces serveurs.

Le champ 'From' est l'adresse e-mail de l'auteur de l'article. Il ne sert qu'aux outils de lecture des news et à leurs utilisateurs pour identifier l'auteur d'un article. Certains utilisent, pour éviter l'abondance de courriers publicitaires, une adresse maquillée. Mon opinion est que non seulement c'est inutile (un spammeur dispose de bien des moyens pour connaitre votre adresse, pas seulement sur Usenet) et qu'il est plus efficace de lutter contre le spam plutôt que de se contenter d'essayer de s'en protéger, mais qu'en plus c'est une technique assez discourtoise: les outils de lecture des News permettent de répondre en privé via le courrier électronique. En maquillant votre adresse, vous risquez surtout de voir une réponse privée ne jamais arriver parce que votre correspondant ne se sera pas aperçu dudit maquillage, ou, dans le cas ou vous indiquez clairement un tel maquillage, de contraindre un correspondant à éditer manuellement l'adresse pour pouvoir vous répondre, ce qui prend du temps et comporte des risques d'erreur manuelle. Ne comptez pas sur moi pour faire autant d'efforts: si vous voulez une réponse c'est à vous de simplifier le travail de ceux qui voudront bien vous aider. Et si vous êtes spammés pour avoir utilisé en public votre adresse, rejoignez ceux qui luttent contre le spam (un bon site anglophone traitant du spam est https://spam.abuse.net/spam/).

Le champ 'Newsgroups' est utilisé par le serveur pour plusieurs raisons.

Lorsque le serveur reçoit l'article, il le stocke physiquement là où il pourra le retrouver lorsqu'un client lui demandera les articles du ou des forums indiqués. 5 Le nom du ou des forums correspond donc souvent à un répertoire particulier sur le disque dur du serveur.

Lorsque le serveur a stocké l'article, il va le proposer à tous ses voisins (du moins à ceux qui n'apparaissent pas dans le champ 'Path') à condition que l'administrateur des voisins aient demandé à l'administrateur du serveur local de lui envoyer les articles du forum (ou d'un des forums) en question.

Pour la hiérarchie francophone, en règle générale, les serveurs s'échangent tous les forums. Mais ça n'a rien d'obligatoire.

Le champ 'Subject' permet au client Usenet de présenter l'article avant sa lecture. En association avec le champ 'References', il permet aussi au client de regrouper les articles d'une même discussion sous une forme plus agréable à lire.

Les champs 'Date, Organization et Lines' sont utilisés par les clients et n'ont pas besoin d'être expliqués.

Le champ 'Message-ID' est l'étiquette de ce message. Elle est unique à cet article et permet de le retrouver via les différents moteurs de recherche si nécessaire. C'est aussi cette étiquette qui va être présentée aux serveurs voisins (peers) qui diront s'ils ont déjà reçu l'article par d'autres voies ou s'ils l'acceptent.

Le champ 'References' est utilisé par le client. Il fournit l'étiquette de l'article auquel celui-ci répond. Il peut y avoir plusieurs étiquettes: si un article est une réponse à une réponse, on aura alors les Messages-ID de ces deux articles en référence. Ce champ permet au lecteur de news de présenter une discussion sous une forme arborescente, plus facile à suivre.

Les champ 'NNTP-Posting-Host' et 'NNTP-Posting-Date' indiquent nom du serveur sur lequel l'article a été posté et la date à laquelle il a été posté. C'est le serveur qui ajoute ces champs, qui ne sont pas modifiables par un utilisateur.

Les champs 'Mime-Version', 'Content-Type' et 'Content-Transfer-Encoding' permettent au lecteur Usenet de savoir dans quel format l'article a été écrit. Dans la hiérarchie fr, le seul format autorisé est le texte seul, sans autre codage que le codage 8 bits Iso-Latin (iso-8859-1 ou iso-8859-15 pour les plus modernes). Veillez à régler votre lecteur de news pour qu'il utilise ce format (et donc ni le Quoted-Printable, ni le HTML, ni aucun autre format propriétaire, ni aucun attachements - y compris les VCARD) avant de poster dans fr.*.

Le contenu de l'article commence après la première ligne vide suivant les champs techniques.

Lorsqu'on répond à un autre article, comme c'est le cas ci-dessus, il est d'usage de citer ce à quoi on répond (les symboles '> ' commençant une ligne indiquent une citation). Les clients de lecture Usenet savent présenter les lignes de ce type dans une forme différente pour indiquer qu'il s'agit d'un simple rappel de l'article auquel on répond. Il ne sert à rien de citer à nouveau l'article en entier: il suffit de citer la ou les 2 ou 3 lignes qui suscitent une réaction de votre part. Ceux qui voudront lire l'article auquel vous répondez en entier iront le lire directement. En aucun cas les citations ne doivent être plus longues que le texte de votre réponse: c'est une bonne règle à appliquer. Caricaturalement (mais hélas on voit trop souvent de telles caricatures) le pire article possible est un article qui cite entièrement les 200 lignes d'un article précédent auquel est ajouté une ligne disant "Moi aussi".

En règle générale, et contrairement à ce à quoi certains outils vous poussent, il est bien vu de citer ce à quoi on répond avant d'y répondre. Ca peut vous sembler naturel, comme à moi, mais ça va mieux en le disant.

A la suite de votre article, votre client va ajouter une signature qui vous est propre. A vous de configurer votre outil pour que cette signature soit courte (jamais plus de 4 lignes, de préférence 1 ou 2) et représentative. Votre nom peut suffire, ou une citation que vous appréciez particulièrement.

La signature est signalée par une ligne spéciale, ajoutée normalement par votre lecteur de news et qui contient exactement les caractères '- ' (notez l'espace) suivis d'un retour chariot. Les outils de lecture reconnaissent cette ligne et vous présentent la signature sous une forme différente du contenu original ou des citations. De même lorsque vous répondez à un article, les outils bien conçus ne laisseront pas la signature précédente dans les citations possibles (il est inutile de citer une signature).

Si votre outil ne permet pas de faire tout ce qui est indiqué dans ce chapitre, ou s'il le fait mal, changez d'outil.

Aspects sociaux

La 'sociologie' d'Usenet présuppose qu'il existe une société. Pour ma part, je considère dans la suite qu'une organisation humaine dotée de principes presque invariants (disons constitutionnels), de règles de vie en commun et d'usages établis par le temps (disons une culture) et concernant un ensemble humain dont le nombre dépasse de loin le microcosme peut être appelé une 'société', et qu'on peut tenter d'en analyser le fonctionnement.

Ce qui est d'autant plus aisé que ce fonctionnement fait l'objet de nombreux débats, souvent animés, ce qui prouve si besoin était l'existence réelle de la 'société Usenet" (car quel humain s'intéresserait au fonctionnement et aux règles d'un système dont il ne se considérerait pas comme membre, ou 'citoyen'?).

Pour pousser encore l'analogie avec les groupes humains réunis par des organisations plus 'physiques', on doit aussi considérer que différentes histoires ont conduit à différentes structures, dont les usages, les rites et le règlements sont différents les uns des autres. On retrouve sous l'aspect sociologique les différentiations techniques qu'on a nommé jusque là des 'hiérarchies'.

L'analyse qui suit concerne plus spécifiquement la hiérarchie 'fr', à ce jour la hiérarchie francophone la mieux distribuée, la plus active, et la plus ancienne aussi.

Qui est le chef d'Usenet

C'est un classique. Aussi étrange que cette question puisse sembler lorsqu'on connaît un peu Usenet, j'affirme qu'il s'agit d'une des premières questions posées par tous les responsables associatifs et/ou politiques auxquels j'ai parlé d'Usenet durant ces dernières années. Le plus souvent, elle est posée sous les formes plus modérées "Qui est responsable de tout ça" ou "A qui appartient Usenet" ou encore "Qui fournit ce service".

Cette dernière forme est sans doute la plus adaptée au média, mais le fait que cette question soit si importante pour ceux qu'on nomme en général des "acteurs de la vie publique" n'est pas innocent. Il n'est pas si facile d'imaginer qu'un tel outil existe sans qu'une autorité unique ne soit derrière, quelque part, lorsqu'on a connu dans le passé aucun autre phénomène de cette envergure. La question revient d'ailleurs, mais moins souvent (parce que son existence est moins souvent remise en question et qu'on néglige donc de s'inquiéter du nom du responsable, probablement) au sujet d'Internet.

Usenet est un service proposé par une communauté de personnes, physiques ou morales, qui ont passé entre elles des accords permettant la diffusion des articles sur tous leurs serveurs. N'importe qui peut faire partie de cette communauté (il suffit d'ouvrir un serveur, ce qui ne demande que quelques connaissances techniques et fort peu d'argent: un budget de moins de 2000 francs par an, communications comprises, est suffisant pour transporter la hiérarchie fr).

A ce titre, Usenet "appartient", au moins physiquement, à cet ensemble de personnes. Mais ce n'est pas parce qu'on possède une feuille blanche destinée à recevoir les écrits de n'importe qui qu'on possède ces écrits, à fortiori lorsque la possession de cette feuille est partagée par un grand nombre de personnes.

S'il est certain que les administrateurs des différents serveurs de news ont un certain pouvoir sur leur propre serveur, leur permettant par exemple de choisir si ce serveur recevra ou non les article d'un forum particulier, il n'existe pas d'autorité centrale sur Usenet.

La création d'un forum, par exemple, ne relève de l'autorité de personne: il s'agit d'un processus selon lequel, après que n'importe quel utilisateur aie relevé et formalisé un besoin, une discussion va s'engager sur l'existence de ce besoin, sur le sujet du nouveau forum et sa place dans l'arborescence. Cette discussion, qui se tient dans un forum prévu pour (fr.usenet.forums.evolution pour la hiérarchie francophone) mais dont l'annonce est postée (AAD: Appel à Discussion) dans les forums les plus concernés, est ouverte à tous, et chacun peut donner son avis, participer à la rédaction de la charte, s'opposer à l'utilité du groupe, etc. Lorsque la plupart des intervenants sont d'accord pour estimer qu'un consensus a été atteint, un vote est lancé, et le groupe est créé à l'issue de ce vote s'il est positif.

Pour ce faire, un "message de contrôle" est posté, dont le but est de demander à tous les administrateurs des serveurs qui le recevront de créer ce groupe. Cette création peut être soit automatisée au niveau du serveur (qui pourra authentifier la demande grâce à une signature PGP), soit faite manuellement par l'administrateur. Un tel article peut être posté par n'importe qui, mais il va de soi que les administrateurs des serveurs de news préfèrent ne créer que ceux qui ont passé avec succès l'étape du vote.

Il existe cependant une hiérarchie mondiale particulière (alt.*) dans laquelle n'importe qui peut créer un groupe sans en passer par un vote. Cette hiérarchie comporte donc des groupes plus ou moins fantaisistes et n'est que rarement transportée entièrement par les différents serveurs de news. Elle a notamment été exclue de nombreux serveurs universitaires depuis quelques années, eut égard aux contenus illégaux qu'elle permet trop aisément de diffuser.

De même, n'importe qui peut poster un "message de contrôle" (cancel) qui aura pour effet d'effacer un article de tous les serveurs qui le reçoivent. Cette spécificité permet donc à n'importe qui d'effacer n'importe quoi, à tout instant. Si Usenet n'est pas devenu un vaste champ de bataille sur lequel chacun efface les articles de ses contradicteurs, c'est sans doute parce que l'être humain n'est pas si mauvais qu'on le pense, ou parce que la plupart des utilisateurs ignorent ou préfèrent ignorer leur pouvoir: à chacun d'entre nous ne se faire sa propre opinion sur ce point.

La liste des abus potentiels est longue. Outre les abus 'techniques' décrits ci-dessus, il faut savoir qu'on évalue à près de la moitié du trafic le nombre de cancels envoyés pour effacer les articles qui ne respectent pas les chartes (articles identiques postés dans tous les forums existants, articles binaires postés dans des forums dans lesquels ils sont interdits etc.). Dans ce cadre, le remède est devenu équivalent au mal, voire pire. La technique tente d'y répondre, grâce à des outils comme cleanfeed dont le but est de rejeter à la source (au niveau de chaque serveur qui va alors refuser les articles de ses clients s'ils sont manifestement hors limites) les pollutions les plus évidentes.

On notera toutefois qu'il existe des processus de régulation apparemment méta sociaux qui interviennent pour punir les abus les plus flagrants. La plainte au fournisseur de service, lorsqu'un utilisateur s'estime victime d'un abus (spam, insultes à répétition...) est souvent prise en compte par le fournisseur du vilain, qui demandera à son client de cesser ses abus.

Cette méthode (et les autres techniques consistant à faire pression sur celui qui fournit la connectivité du 'délinquant') est un recours à une entité à priori extérieure à la société. En pratique pourtant, le recours aboutit d'une manière ou d'une autre à l'administrateur d'un serveur de news, soit parce que ce dernier aura l'autorité suffisante pour intervenir auprès de son client, soit parce que son patron lui demandera pourquoi il reçoit des plaintes et ce qu'il doit en penser. Dans ce cas là le patron saura le plus souvent faire la part du feu, entre les représailles possibles de la société Usenet contre son entreprise et la perte potentielle d'un client.

Dans ce cadre, on s'aperçoit qu'en fait la société Usenet est en fait assez forte pour faire pression sur une entité extérieure lorsqu'un ressortissant de cette entité agit mal au sein d'Usenet. Ce n'est donc pas un recours à une autorité externe, mais bel et bien la démonstration d'un rapport de force entre deux sociétés. Usenet se défend des agressions sans attaquer l'agresseur, mais en menaçant celui dont il dépend. Somme toute une forme de guerre économique tout à fait moderne. On peut citer comme forme de dissuasion ultime la menace d'UDP (Usenet Death Penalty), très rarement utilisée, qui consiste à refuser (par des cancels systématiques qui peuvent être ignorés par ceux qui le désirent) tous les articles postés depuis un serveur dont le propriétaire ignore totalement les requêtes qui lui sont adressées.

La hiérarchie des hiérarchies

Usenet est donc une société sans dirigeants. Mais cette société connaît quand même une certaine forme de hiérarchie et de promotion sociale. On n'y côtoie pas que des égaux.

D'abord, on l'a vu, ceux qui fournissent le service (les administrateurs des serveurs de news, pour résumer) ont des moyens d'action dont les autres utilisateurs ne disposent pas nécessairement. Mais ces moyens s'appliquent la plupart du temps à leurs seuls utilisateurs, qui disposent à leur tour de moyens de pressions sur leur fournisseur en dehors du cadre de la 'société Usenet'. De ce point de vue, on peut penser qu'il existe un équilibre.

Équilibre d'autant plus grand que les administrateurs ne souhaitant pas, pour des raisons évidentes, avoir la moindre responsabilité légale quant au contenu des forums dont ils permettent l'existence ont tendance, de manière raisonnée ou non, à n'utiliser leur pouvoir que de manière très prudente: une démonstration de force de leur part risquant de démontrer d'abord qu'ils ont des moyens d'action quant au contenus, ce que la Justice risquerait de considérer à leur détriment en cas de poursuites légales. On peut voir là une des raisons qui ont conduit à un fonctionnement qui présente un aspect plus ou moins démocratique: les administrateurs préférant laisser à leurs utilisateurs le pouvoir de choisir ce qui sera ou non transporté, et n'intervenant que lorsqu'un de ces choix risquerait de poser des problèmes légaux évidents (ce qui n'est à ce jour jamais arrivé sur fr).

Il est donc plus que rare qu'un administrateur soit considéré différemment, dans le strict cadre d'Usenet, de n'importe quel autre utilisateur. La hiérarchie sociale, si elle existe, n'est pas là.

Longtemps (et c'est toujours un conseil de bon aloi) il a été conseillé aux nouveaux venus sur Usenet de ne rien poster dans les forums qu'ils lisaient avant d'avoir passé "un certain temps", dans un ordre de grandeur variant autour du mois, à lire seulement. Ce conseil reposait surtout sur le simple savoir-vivre: il n'est pas d'usage en société d'intervenir dans une discussion sans écouter d'abord ce que disent ceux qui ont entamé ladite discussion sans vous. Quand quelqu'un qui n'écoutait pas rebondit sur un mot lancé un peu plus fort pour donner son avis, en général, il tombe à plat.

Il m'apparaît que ce conseil a d'autres raisons d'être, non moins valables, et en particulier le fait qu'en écoutant d'abord, on apprend beaucoup sur ceux qui vont devenir ses interlocuteurs, en plus de savoir de quoi on cause.

Il est utile, en effet, de remarquer que les articles de tel intervenant sont généralement considérés par tous comme étant de haute valeur. En général on le remarque au moins en constatant que les avis du monsieur terminent le débat en cours: c'est la marque la plus évidente. Mais il en existe d'autres aisément identifiables (les 'mitou' (me too) qui suivent, ou les remerciements, par exemple).

Il est utile aussi bien de savoir qui est le petit rigolo du groupe, qui préfère rire de tout et ne prend rien au sérieux. Ça permet d'éviter de tomber dans un "troll" (ce mot désigne tout à la fois l'auteur et le contenu d'un article dont l'objet est de pure provocation).

Et petit à petit, d'abord à l'intérieur de chaque forum, puis souvent à l'intérieur de toute la hiérarchie (car aucun humain équilibré ne s'intéresse qu'à un seul sujet, si ?) on s'apercevra que certains avis sont plus respectés que d'autres lorsque des débats sont en cours. Voire même que certains avis ont une valeur décisionnelle à eux seuls lorsqu'ils sont émis par une personne unanimement respectée (pour ce qu'elle a fait dans le passé pour la communauté, par exemple).

Voilà la hiérarchie des hiérarchies: basée sur une espèce de méritocratie, ou comme je préfère la nommer de 'respectocratie'. Plus une personne aura accumulé le respect d'autrui, plus son opinion ou son apport technique aura de valeur.

Et en général, sauf à vouloir se faire instantanément beaucoup d'ennemis, il vaut mieux réfléchir à deux fois avant de contredire ces gens. Mais c'est aussi une façon parfois habile de se faire soi-même une réputation, même négative, rapidement. Certains excellent à ce jeu-là, comme dans toute société.

Les règles technico/sociales

Nous avons vu dans la première partie qu'il n'y avait pas de "chef d'Usenet". Le processus conduisant à la création d'un groupe permet à chacun de donner son avis et de voter pour ou contre cette création. Bien entendu, puisque personne n'est nommé pour s'assurer que chaque nouveau groupe s'insère plus ou moins bien dans une hiérarchie dont on souhaite la cohérence, toute personne qui souhaite disposer d'un forum dédié au thème qui le concerne est à même de proposer le nom qu'il veut donner à "son" forum: l'étape du vote étant supposée trier le bon grain de l'ivraie.

Pour qu'un nouveau forum "passe" l'étape du vote, il fallait jusqu'en 1997 qu'au moins 30 votes soient positifs, et qu'il y ait moins de la moitié des votes négatifs. Avec de telles règles, le nombre d'utilisateurs d'Usenet grandissant, il devint évident que tout nouveau forum proposé serait adopté, quelle que soit son sujet, son public, ou la place choisie pour le créer. Ce fut le cas lorsqu'on vit près de 50 personnes, votant depuis moins de 10 laboratoires de biologie différents, voter comme un seul homme la création d'un forum dédié aux canaux-ioniques, thème dont nul n'ignore l'intérêt qu'il présente pour la majorité de la population et en particulier pour celui qui avait demandé la création de ce forum. La règle fut donc transformée pour devenir "80 OUI DE PLUS QUE DE NON et 3 FOIS PLUS DE OUI QUE DE NON".

Il est à noter, que le mot "vote" est chargé d'un poids très lourd dans nos pays démocratiques, poids qui fait qu'on préfèrera parler, sur Usenet de "scrutin" ou de "sondage" pour ce qui n'existe que dans cette 'société' là.

Le "vote" en question mesure en effet deux choses distinctes, à la manière d'un sondage dans lequel deux questions seraient posées qui s'excluraient mutuellement (si on répond OUI à la première, on ne peut répondre à la seconde, et inversement). Le système OUI/NON sur Usenet correspond dans la réalité à deux questions séparées qui sont:

1.
Souhaitez vous la création de ce forum, soit parce que son thème vous intéresse (et donc que vous y participez) soit parce que sa création aidera à désengorger un forum que vous utilisez ?

2.
Pensez-vous que la création de ce forum est une mauvaise idée pour l'organisation générale de la hiérarchie, soit parce que son thème est trop spécifique, ou pas assez, soit parce que sa création risquerait de porter tort à un forum que vous utilisez ?

On voit que ces deux questions, si elles sont antinomiques, ne sont pas un simple choix OUI/NON comme le laissent supposer à la fois le mot "vote" et le système de vote lui-même: en réalité le vote NON correspond à un OUI à la seconde question, et pas à un vote NON à la première. Cette ambiguïté pose souvent des problèmes lorsqu'un vote échoue, les votants OUI ne comprenant pas les raisons pour lesquelles le poids des NON est plus important. Il est pourtant normal que la cohérence globale de la hiérarchie soit considérée comme plus importante que la création d'un forum particulier, et ce système à fait ses preuves depuis longtemps.

Le cas particulier du forum sur les canaux ioniques nous montre à l'évidence la faiblesse principale d'Usenet: si chacun est à même de comprendre son fonctionnement et les raisons qui devraient conduire à n'y créer que des forums intéressant une bonne partie de la population, alors nul ne proposera, ni ne fera passer en force la création d'un forum qui ne concernera qu'une population déjà bien identifiée et localisée, qui aura plutôt intérêt à utiliser une liste de discussion. Mais puisqu'il n'y existe aucune autorité centrale, nul ne peut empêcher les dérives, quelles que soient les règles de création que se choisiront les quelques personnes qui se préoccupent du média dans son ensemble.

A l'opposé, il faut comprendre que c'est justement cette faiblesse qui fait la force du média: tout média public, sur lequel un intervenant est à même d'être lu ou écouté par un grand nombre de gens, est, lorsqu'il repose sur une structure centralisée et un pouvoir quelconque, soumis au minimum à une autocensure: l'autorité centrale risquant d'être tenu pour responsable des propos tenus sur le média dont il a la charge, il va logiquement se mettre à faire des choix non seulement quant aux thèmes abordés, mais aussi sur le contenu des émission ou des articles. Si aucune autorité centrale n'est identifiable, si nul ne peut ni imposer les thèmes ni choisir les contenus, alors le seul responsable d'un propos tenu en public est celui qui tient ces propos, et nulle censure ne peut lui être imposée par quelqu'un d'autre.

Usenet, parce qu'il ne connaît aucune espèce d'autorité centrale, acquiert donc des spécificités toutes différentes de tous les autres médias, y compris de ceux qui utilisent aussi l'infrastructure d'Internet.

* La diffusion des articles par inondation (tout serveur retransmet à tous ses pairs l'information qu'il reçoit de l'un d'entre eux) interdit de facto toute censure préalable d'un contenu puisque ce contenu ne dépend d'aucun lien particulier pour être diffusé partout.

Parallèlement, le fait que le procédé de diffusion ne repose pas sur la demande mais sur l'offre systématique impose une charge au réseau qui implique que les forums ainsi distribués fassent l'objet d'un intérêt suffisant en tout point du réseau ainsi inondé. C'est la raison d'être principale de la procédure, considérée comme trop complexe par beaucoup de ceux qui ignorent cet aspect, de création d'un nouveau forum.

* La gestion d'une hiérarchie organisée nécessite un travail certain, de réflexion, de rédaction, d'aide. Tout ce travail est basé, en l'absence de tout financement global, sur le volontariat et le bénévolat de ceux qui se sentent suffisamment concernés par l'existence du média. Le réseau des serveurs de Usenet est structuré de façon à empêcher tout lieu de pouvoir, ce qui interdit que ces bénévoles s'approprient de facto un pouvoir autre que celui que le reste des utilisateurs veut bien leur déléguer.

C'est un avantage et un inconvénient. Le bénévolat se soucie peu des capacités réelles des personnes, par exemple. Et le risque de voir se constituer une caste de ceux qui s'investissent dans la gestion d'une hiérarchie et qui prennent les décisions pour les autres est très réel: dans les faits, pour intervenir dans le processus de décision, il faut connaître les règles, l'histoire et les positions "politiques" des différents intervenants. Un tel travail nécessite du temps, dont chacun ne dispose pas obligatoirement. Un autre risque est de voir un petit groupe de personnes organisées et décidées prendre place au centre des lieux de décision communs, et profiter du fait que, proportionnellement au nombre des utilisateurs, ceux qui s'intéressent à la hiérarchie au point de débattre et de voter son développement sont peu nombreux pour imposer un point de vue qui ne prendra en compte que ses propres bénéfices, et s'approprier le bien commun.

Mais l'équilibre est solide, et repose en définitive sur le fait qu'au delà des utilisateurs, ceux qui gèrent des serveurs disposent toujours d'un "droit de veto" sur toute décision qui irait contre l'intérêt du plus grand nombre, intérêt bien compris par ces gestionnaires, puisque c'est eux qui sont en position de juger du coût de toute décision. Eux-mêmes n'ayant aucun intérêt à imposer une décision qui risquerait de les transformer de facto en responsables de tout ou partie du contenu de la hiérarchie, au delà du rôle de simples transporteurs. Leurs veto pour ne pas leur imposer de responsabilité légale ne doivent donc reposer que sur des aspects purement technique, les décisions "politiques" étant réservées aux utilisateurs, et la responsabilité légale diluée au point de ne plus reposer que sur l'auteur de chaque article.

Sauf sur les forums modérés

Un type particulier de forum se situe à la limite du lieu d'expression public ouvert à tous, il s'agit du forum modéré.

Le forum modéré (et décidé comme tel lors de la discussion, et du vote, qui précèdent son existence) fonctionne, pour le lecteur, de la même façon que le forum moyen. La différence n'apparaît que lorsqu'on souhaite poster un article sur un tel forum: le serveur sur lequel l'article est envoyé va, au lieu de stocker l'article et de le diffuser, envoyer l'article, par courrier électronique, à un "modérateur" (lui aussi nommé lors de la création du forum).

C'est ce "modérateur", et lui seul, qui pourra rendre public l'article, en le postant avec une ligne spéciale ("Approved:" suivi de l'adresse e-mail du modérateur) ajoutée au header de l'article. Sa décision, dans la très grande majorité des cas, repose uniquement sur l'adéquation entre le contenu de l'article et la charte du forum auquel l'article est destiné. Les articles n'ayant aucun rapport avec cette charte seront, avec droit, rejetés. Ceux qui ne respectent pas entièrement ladite charte pourront faire l'objet d'un dialogue entre le modérateur et l'auteur de l'article, si c'est le choix du modérateur.

Il faut revenir sur quelques points qui viennent à l'esprit: il ne s'agit en aucun cas de censure: Usenet dispose de suffisamment de forums non modérés pour qu'un article, quel qu'il soit, puisse être posté en public. Le modérateur, dans ses choix, ne fait qu'appliquer une règle décidée par ceux qui ont voulu le forum qu'il modère, et rien d'autre. Sa décision ne concerne donc que le contenu de ce forum particulier.

Cette décision n'est (normalement) jamais motivée par le contenu idéologique d'un article (On peut d'ailleurs noter que, jusqu'à ce jour, aucun forum à thème idéologique n'est modéré sur la hiérarchie francophone. Il ne s'agit pas là d'une règle, mais du résultat des différents débats qui ont eu lieu lorsque de telles propositions ont été faites).. Si l'article respecte la charte du forum, il sera posté, même s'il ne correspond pas aux opinions du modérateur: il ne s'agit donc pas non plus de décision éditoriale, mais seulement de décision quant à la forme d'un article particulier et quant à son adéquation au thème du forum.

La modération n'est donc ni une censure ni une décision éditoriale. On pourrait plutôt la comparer avec le jury de lecture qui valide (ou non) la publication d'un article scientifique dans les journaux spécialisés. Le terme même de "modérateur" est à prendre plus comme une traduction littérale du terme anglo-saxon "moderator" qui indique plutôt celui qui, lors d'un débat, distribue le temps de parole que celui qui souhaite "modérer" les propos des intervenants.

Notons enfin l'apparition récente de trois nouveaux types de forums modérés, dits "rétro-modérés", "auto-modérés" et "robot-modérés". Le premier type permet à chacun d'y poster ce que bon lui semble sans en passer par la décision à priori d'un modérateur, mais fait l'objet d'une surveillance régulière qui conduit le modérateur à effacer, après coup, tout article qui ne respecte pas le thème du forum. Le modérateur doit rendre compte de tout effacement dans un forum spécialisé (et lui-même "auto-modéré": toute personne qui y poste doit "approuver" elle-même son propre article) : fr.usenet.abus.rapports. Le dernier ("robot"modéré") est laissé à la charge d'un logiciel, qui se charge de valider les articles qui lui sont soumis par e-mail, comme un modérateur humain, lorsque ceux-ci respectent une forme précisée dans la charte. Ce type de forum n'est donc pas à l'abri des articles hors thème, aucun logiciel n'étant capable de juger d'un tel point.

Aspect technique

NNTP et UUCP
Usenet préexiste à Internet. En fait, Usenet étant un média asynchrone, il est à même d'utiliser n'importe quel moyen de transport permettant à un ordinateur de lire des fichiers écrits sur un autre. Et presque tous les moyens de transports possibles, jusqu'au transport de bandes en voiture, ont été utilisés pour transporter Usenet.

Mais les méthodes purement informatiques sont plus rapides et plus simples. Je pense qu'UUCP a été le premier des protocoles utilisés avant qu'Internet et NNTP n'arrivent à ce qu'on connaît aujourd'hui.

UUCP (Unix to Unix Copy Protocol) est simple d'emploi et ne nécessite rien de plus qu'un modem et un contact disposant lui aussi d'un modem. Aucune couche réseau n'est nécessaire en dehors de la seule liaison physique. Le principe est rudimentairemais solide: on se connecte à heure fixe sur un autre serveur, et on transfère sur ce serveur tout ce qu'on a stocké localement depuis la dernière connexion. A l'inverse, on reçoit tout ce que cet autre serveur a reçu depuis notre dernière visite.

Une "carte", largement distribuée et signalant, pour chaque machine du 'réseau virtuel' ainsi constitué les fréquences d'appel et le nom des machines appelée permet à un programme assez simple de reconstituer la 'route' la plus courte entre deux machines. Ces cartes ont une raison d'être lorsqu'on souhaite faire parvenir un message à un ordinateur particulier. Dans le cadre d'Usenet et de sa procédure d'inondation, elles sont inutiles.

Il est intéressant de savoir cependant que ces cartes existent toujours, et qu'il faudrait peu d'efforts pour reconstituer un réseau tombé en désuétude mais toujours prêt à prendre le relais en cas de besoin. Mais UUCP sur TCP est encore aujourd'hui assez souvent utilisé.

INN
INN est resté longtemps le logiciel (libre) le plus utilisé pour gérer un serveur Usenet. Il est capable d'échanger des articles avec ses partenaires en UUCP comme en NNTP, et dans le cas des serveurs qui ne disposent que de connexions temporaires à Internet (dial-up), UUCP est une solution qui coûte moins cher que n'importe quel autre moyen de transport plus moderne (voir annexe).

L'installation d'INN est cependant assez complexe, mais grâce aux distributions récentes de Linux on peut 'monter' son propre serveur sans grandes difficultés (la plus grande part de la complexité d'INN étant la phase de configuration spécifique à chaque système d'exploitation avant compilation, on profitera pour une fois sans état d'âme des distributions binaires prévues pour s'adapter directement à un système donné).

Phase pratique: configuration d'INN sur une machine Linux/Debian.

Après l'installation du package ('apt-get install inn' sur une Debian récente) et la réponse aux quelques questions qui vous seront posées par le script d'installation, il reste vraiment très peu de travail pour finaliser un serveur fonctionnel. Le détail d'une installation de ce genre suit, mais je ne saurais trop vous conseiller de vous familiariser d'abord avec INN en lisant entièrement la documentation ('zcat /usr/doc/inn/inn-Install.ms.gz | nroff -ms' sur une Debian) et la FAQ en cas de problème (/usr/doc/inn/INN-faq*).

Le script d'installation va modifier le fichier /etc/news/inn.conf. Pour ça, il va vous demander de décrire:

* votre organisation (quelques mots suffisent: ce sera l'organisation utilisée par défaut lorsqu'un client postera sur votre serveur sans spécifier sa propre organisation)

* le nom de votre serveur (sans importance réelle)

* le path de votre serveur: cette valeur est celle qu'INN ajoutera au champ technique 'Path' des articles qu'il traitera. Cette valeur permettra aux serveurs qui enverront des articles au votre d'éviter de vous proposer des articles qui sont déjà passé par votre serveur. Il doit donc être assez spécifique pour éviter que deux serveurs utilisent le même identifiant et soient confondus dans la diffusion des articles. Le nom FQDN de votre machine, ou celui de votre domaine si votre serveur est le seul serveur de news de ce domaine, est souvent un bon choix: il est unique.

* le domaine dont proviendront les articles postés localement.

Le script va ensuite lancer le démon innd. Votre serveur est déjà fonctionnel mais ne dispose que d'un forum de test local, et ne reçoit ni n'émet d'articles vers l'extérieur.

Restent à configurer les quelques fichiers installés dans le répertoire /etc/news. Je n'aborde que ceux dont la configuration est nécessaire à l'établissement d'un feed bidirectionnel (de votre serveur vers un serveur peer, et de ce serveur vers le votre).

ATTENTION: toutes les configurations qui suivent doivent être faites sous l'identité de 'news' (su - news).

/var/lib/news/active et /var/lib/news/newsgroups
Il vous faudra la liste des forums que vous allez recevoir. Pour obtenir la liste complète au jour le jour de tous les forums existants officiellement, vous pouvez aller sur ftp://ftp.isc.org/pub/usenet/CONFIG/ récupérer un fichier 'active' et un fichier 'newsgroups' à jour. Contentez-vous de les copier dans /var/lib/news/. Si vous laissez le fichier active complet, votre serveur proposera à ses utilisateurs locaux la liste de tous les forums existants. Si vous ne souhaitez en proposer qu'une partie (la hiérarchie fr par exemple) éditez ce fichier pour ne conserver que les forums que vous allez recevoir de vos feeds.

/etc/news/hosts.nntp
Ce fichier contient la liste des serveurs qui ont l'autorisation de vous envoyer des articles. Il est possible de subordonner cet accès en écriture à la fourniture d'un mot de passe, mais cette option n'est que très rarement utilisée. ATTENTION: ce fichier est remplacé par le fichier 'incoming.conf' dans les versions d'INN supérieures à 2.0 (ce qui n'est pas encore le cas de l'INN fourni dans la Debian par défaut). La syntaxe utilisée pour incoming.conf est proche de cette qu'on utilise dans innfeed.conf (voir plus bas) et donc toute différente de celle utilisée pour hosts.nntp.

La première chose à faire est donc d'indiquer dans hosts.nntp le nom du ou des serveurs (un par ligne) qui vont vous envoyer des articles, dans le cas où vous serez feedés via NNTP.

ATTENTION: si vous êtes feedés par UUCP (ou si vous utilisez une méthode quelconque mettant en jeu l'appel de 'rnews' pour remplir vos forums locaux), il n'y a pas besoin de toucher à hosts.nntp. Laissez le vide.

/etc/news/newsfeeds
C'est dans ce fichier que vous devez décrire ce que vous allez émettre, et vers qui vous allez émettre. Entrer dans les détails de la configuration ici prendrait trop de place, je vous renvoie aux nombreux exemples contenus dans le fichier fourni par la Debian. Si vous allez envoyer vos articles par NNTP directement, préférez la solution 'innfeed' à tout autre choix possible:

* décommentez la ligne qui commence par 'innfeed!'.

* ajoutez une ligne pour chaque serveur vers lequel vous allez envoyer vos articles, de la forme:

Nom.Du.Serveur/path-exclude:fr.*:Tm:innfeed!

Ou 'Nom.Du.Serveur' va correspondre à une entrée du fichier innfeed.conf et où 'path-exclude' doit être la chaîne ajoutée dans le champ technique Path: par le serveur en question. 'fr.*' signifie que vous allez envoyer à ce serveur tous les articles postés localement (ou reçus via un autre serveur) dans la hiérarchie fr. 'Tm:innfeed!' indique à INN qu'il doit utiliser le programme innfeed pour envoyer ses articles.

* configurez le serveur (peer) en question dans le fichier /etc/news/innfeed.conf (si ce fichier n'existe pas, installez innfeed: <apt-get install innfeed>):

peer Nom.Du.Serveur {
ip-name: Nom.Du.Serveur
}

doit être ajouté.

Ce type de configuration nécessite une connexion permanente. Dans le cas ou vous utilisez une connexion de type dialup, préférez la solution UUCP:

* ajoutez une ligne pour chaque serveur vers lequel vous allez envoyer vos articles, de la forme:

Nom.Du.Serveur/path-exclude:fr.*:Tf:

Ou 'Nom.Du.Serveur' va correspondre à une entrée du fichier send-uucp.cf et où 'path-exclude' doit être la chaîne ajoutée dans le champ technique Path: par le serveur en question. 'fr.*' signifie que vous allez envoyer à ce serveur tous les articles postés localement (ou reçus via un autre serveur) dans la hiérarchie fr. 'Tf:' indique à INN qu'il doit stocker les articles à envoyer dans un fichier. Ce fichier sera lu et exploité par une entrée dans la crontab de l'utilisateur 'news' (crontab -e).

* décommentez dans la crontab de l'utilisateur 'news' (crontab e pour éditer la crontab avec l'éditeur défini par $EDITOR dans votre environnement) la ligne qui appelle
/usr/lib/news/bin/send-uucp.pl.

* éditez /etc/news/send-uucp.cf et ajoutez une ligne pour le système UUCP du serveur vers lequel vous voulez envoyer les articles. Ceci suppose que vous avez déjà configuré UUCP pour que votre machine puisse appeller ce serveur. Il va de soit qu'il faudra que votre fournisseur fasse l'inverse de ce qui est ici décrit de son côté pour que vous receviez ses articles.

/etc/news/nnrp.access
Ce fichier décrit quelles machines pourront accéder à votre serveur en tant que clients (NNRP). Ajoutez une ligne de la forme: *.yourdomain.com:RP:::*

Où 'yourdomain.com' doit être remplacé par le nom de domaine de votre réseau local. Si vous n'avez pas de reverse DNS configuré pour ce réseau, indiquez directement la classe d'adresse de votre réseau en lieu et place de '*.yourdomain.com'.

C'est tout. Jetez un oeil sur les fichiers 'organization' et 'expire.ctl' pour modifier les paramètres par défaut si nécessaire, puis toujours sous l'identité de 'news' tapez

</usr/lib/news/bin/ctlinnd reload "" "">

pour relancer INN avec votre nouvelle configuration.

Terminologie

Cancel: Annulation d'un article. L'annulation est normalement réservée à celui qui a émis l'article original. Elle s'effectue en envoyant un message spécial (message de contrôle) sur Usenet. Ces messages ne sont pas destinés à être lus mais à être traités automatiquement par les machines faisant transiter les articles de Usenet. Par curiosité, on pourra aller consulter le groupe "control.cancel" pour voir des messages de cancels.

Cross-Post: Consiste à envoyer un article en une seule fois dans plusieurs groupes simultanément. Si vous désirez envoyer un article dans plusieurs groupes c'est la technique qu'il convient d'employer. S'oppose à "Multi-Poster", qu'il ne faut jamais faire.

FAQ (Frequently Answer Questions) (ou Foire Aux Questions en français): Document répondant aux questions les plus fréquemment posées dans tel ou tel forum. Il est bien vu, et même fortement recommandé, qu'une personne à la recherche d'informations sur un sujet ait préalablement recherché si une FAQ existait, et si oui l'ai lu, avant de poser une question dans un groupe. Les FAQ en langue française sont régulièrement postées dans le groupe "fr.usenet.reponses", groupe auquel vous feriez bien de souscrire si vous faites vos premiers pas sur Usenet ("news.answers" regroupe quant à lui l'ensemble des FAQ en langue anglaise), tout comme vous devriez commencer par lire fr.bienvenue.

Flame (Flame wars): Articles agressifs et généralement sans aucun intérêt. Ne participez pas vous même à ce genre de discussions (laissez-les moi!).

Message-ID: C'est l'étiquette qui identifie un article. Tout article posté sur Usenet possède un Message-ID unique, automatiquement généré par l'outil qui permet d'écrire sur le serveur local. Cet identificateur est utilisé par les logiciels lorsque vous répondez à un article pour indiquer à quel article il est répondu, permettant ainsi de classer les articles par fils de discussion (threads).

Modération: Un groupe est dit modéré lorsque les articles doivent être préalablement agrée par une ou plusieurs personnes (le ou les modérateurs) avant parution dans le groupe. Le rôle du modérateur est de vérifier la conformité des articles qui lui sont soumis (processus automatique) à la charte du groupe, puis d'envoyer les articles conformes dans le groupe. Seul le modérateur a le droit d'écrire dans le groupe.

Multi-Post: Envoyer un même article plusieurs fois dans des groupes différents. Un envoi du même article est effectué pour chaque groupe concerné. À ne jamais faire. Utilisez plutôt le "cross-post" si vous devez envoyer un article qui concerne plusieurs groupes. Un article "multi-posté" génère autant d'articles qu'il y a de groupes destinataires, au contraire d'un article "cross-posté" qui ne génère qu'un seul article sur le serveur de news.

NNTP (Network News Transfer Protocol): Le protocole qui relie les serveurs entre eux. Pour que deux serveurs soient reliés, il faut un accord entre chacun des deux administrateurs de ces serveurs, qui seront appelés entre eux des 'feeds'. Dans notre exemple "1","2" sont des 'feeds' de "3", "2" et "3" sont des 'feeds' de "1" et ainsi de suite.

'Lecteur de news': C'est l'outil dont vous vous servez pour lire et écrire dans un forum, qui à l'instar du 'lecteur de mail' permet de taper un article puis de le poster sur son serveur local.

Serveur de 'news': le 'tableau noir' d'un réseau local sur lequel tout utilisateur de ce réseau peut écrire directement. Dans un second temps, l'article posté localement sur ce serveur sera proposé, par ce serveur, à tous les serveurs avec lesquels il est relié, et qui l'accepteront s'ils ne l'ont pas encore reçu.

Spam: Abus consistant à envoyer un article dans un nombre de groupes exagérés (non défini mais un nombre de 5 est généralement considéré comme un maximum). Circonstances aggravantes si l'article est "multi-posté" plutôt que "cruciposté".

Thread: Fil de discussion à l'intérieur d'un groupe. Un fil de discussion est initié par un article original, abordant un nouveau sujet, auquel il est répondu. L'ensemble de ces articles, original et réponses, constitue le fil de discussion ou thread.

Usenet: Ensemble des réseaux, des machines et surtout des personnes permettant une communication publique, électronique, d'essence universelle qui s'appuie sur l'Internet (mais n'est pas limité à l'Internet). Ce terme générique peut être employé dans de multiples sens. Usenet c'est une communauté de personnes (les lecteurs, les rédacteurs, les administrateurs des serveurs) mais c'est aussi l'ensemble des machines qui véhiculent les articles.

Annexes

Ce petit calcul a été fait en 1995. Il est toujours d'actualité: la vitesse des modems a augmenté, mais ça vaut aussi bien pour UUCP que pour PPP/NNTP.

L'objet de ce calcul est de démontrer qu'il revient moins cher, dans tous les cas, de disposer de son propre serveur que de se connecter par téléphone sur le serveur de son fournisseur d'accès. Ce calcul ne concerne que les liaisons téléphoniques, et n'est plus de mise dans le cas d'une liaison permanente ou forfaitaire.

A 14400 bauds:

Les article ont été compressés par UUCP pour arriver à une taille de 16520 octets. Une petite règle de 3 maintenant.

A raison d'une moyenne constatée de 1253 octets par article, pour mille articles nous aurions 210s en UUCP contre 590s en PPP/NNTP à quoi j'ajoute le temps de connexion de 30s. Soit:

Temps de connexion pour 1000: 4mn 9mn40s

Ceci pour 1000 articles. Il est donc évident que pour une personne qui souhaite récupérer un groupe complet, UUCP n'est pas dépassé. 1er point.

Maintenant partons du principe que l'utilisateur ne souhaite lire que certains sujet qu'il aura pu choisir à partir d'une liste rapatriée auparavant. J'ôte donc de mes 40 articles tout ce qui n'est pas dans les headers: résultat 21093 octets (si, si).

temps de connexion physique pour la liste: 30s
temps de transferts estimé pour 1000 headers moyens (527325 octets): 248.3s
(on est loin de la "minute et demie", désolé, ce sont les chiffres)
[coupure]
temps de connexion physique pour les articles choisis: 30s
temps de connexion pour mes 40 articles (soit 4% des articles du groupe
seulement, ce qui à mon sens est un peu bas, compte tenu du fait que si on
s'intéresse à un groupe, le ratio sera plus proche des 50%, mais admettons):
23.6s

total pour PPP/NNTP: 331.9s soit 5mn32s. A rapprocher pour ceux qui ne suivent pas des 4mn pour 1000 articles en UUCP.

On aura donc passé plus de temps "on-line" pour rapatrier les 40 articles intéressants que pour rapatrier les 1000 articles. UUCP n'est pas dépassé pour une lecture sélective, 2ème point.

Pour résumer, donc, ce qui compte c'est que déjà rien que les en-têtes représentent près d'un tiers de la totalité du trafic d'un groupe, ce qui diminue fortement l'intérêt de l'off-line, et qu'en y ajoutant le temps de sélection on dépasse le temps total nécessaire pour ramener le groupe entier en UUCP. Énervant, non?