Résumé

  • Le RFC 1429 décrit DISTRIBUTE, le service de LISTSERV sur BITNET qui acheminait une seule copie sur les liaisons très sollicitées lorsque la topologie permettait de regrouper les destinations. Son auteur évaluait alors le trafic à deux à six millions de messages par jour.
  • Avant de confier une liste au réseau, il fallait vérifier le serveur choisi, la compatibilité des courriels et un fichier « Master nodes » vieux de deux mois au maximum. Au-delà de 10 000 destinataires quotidiens, l'auteur demandait de consulter l'administrateur local.

Qui accepte le dix-millième destinataire supplémentaire ? Ce n'est pas une question de syntaxe. Dans le RFC 1429 de février 1993, Eric Thomas conseillait de demander l'accord de l'administrateur LISTSERV avant d'envoyer à un serveur une charge de plus de 10 000 destinataires par jour. Certains établissements pouvaient limiter les grosses distributions aux heures creuses. Le réseau avait une capacité, mais le droit d'en consommer une part importante restait local.

La technique expliquait l'intérêt de cette négociation. Plutôt que de faire expédier par chaque propriétaire de liste une copie à chaque adresse, le service DISTRIBUTE recevait un message et sa liste de destinataires. Il regroupait les routes quand ses informations topologiques le permettaient, afin qu'une copie traverse une liaison chargée avant d'être dédoublée plus près des lecteurs. Thomas indiquait que le système transportait alors deux à six millions de messages par jour. Il attribuait aux destinataires BITNET raisonnablement connectés un délai typique de cinq à quinze minutes.

Le choix du premier serveur pouvait pourtant gâcher le calcul. Le RFC prend l'exemple d'une liste majoritairement américaine envoyée depuis la Californie vers un serveur suédois : ce détour imposerait de traverser l'Atlantique pour entrer dans le système de distribution. Un établissement pouvait aussi afficher une liaison IP T1 tout en restant raccordé à BITNET par une ligne louée de 9,6 kilobits. Il fallait choisir un point d'entrée proche du public et vérifier sa connectivité BITNET réelle.

Une fois ce serveur trouvé, sa carte devait suivre les changements du réseau. L'auteur fixait un contrôle précis : son fichier « Master nodes » ne devait pas dater de plus de deux mois. Quelques sites laissaient vieillir leurs tables faute de personnel. Or la décision d'acheminer une seule copie sur un lien dépendait précisément de ces tables. Le raccourci n'était rapide que si le chemin décrit ressemblait encore au chemin exploité.

Le paquet de distribution voyageait commodément par SMTP. Son enveloppe MAIL FROM devait indiquer une personne capable de traiter un échec d'acheminement vers le serveur. Dans le message remis à LISTSERV, le champ RFC822 From recevait ensuite les avis de problèmes et les rebonds. Mettre l'adresse de soumission de la liste à cet endroit pouvait réinjecter les erreurs dans la liste et produire une boucle. La même opération comportait donc deux responsabilités à deux moments différents.

Le format était concret : carte JOB, commande DISTRIBUTE MAIL, destinataires signalés BSMTP, puis en-tête et corps du message. ECHO=NO supprimait le rapport d'utilisation en production. DEBUG=YES montrait les routes prévues sans livrer le message ; TRACE=YES les montrait en livrant. Le RFC imprimait un essai où trois destinataires partaient vers le site UGA et deux étaient remis localement. C'était un plan de distribution contrôlable avant d'engager toute la liste.

Pour l'Internet, Thomas distinguait les destinations accessibles près de leur organisation, auxquelles il attribuait typiquement cinq à vingt minutes, et celles privées d'information topologique, plus lentes. Ces valeurs étaient les chiffres publiés par l'auteur en 1993. Le point durable est ailleurs : l'économie d'une copie dépendait du fichier que quelqu'un mettait à jour, de la liaison qu'un site pouvait supporter et du consentement de l'administrateur qui recevait le travail.