Résumé

  • Selon le récit publié par Eric Allman en 1994, le développement majeur de Sendmail s’est arrêté après février 1987 et a repris en juillet 1991, après la multiplication de variantes chez les éditeurs et les contributeurs.
  • Allman a donné plusieurs motifs à son retour : les changements de Berkeley, la divergence des versions et des extensions SMTP qu’il estimait absentes de la plupart des implémentations.
  • Sendmail 8.6.6 prenait en charge certaines extensions sans en couvrir d’autres. Une version publique rendait cette limite vérifiable, mais ne prouvait ni son adoption ni une conformité complète.

Une longue pause est devenue un problème de versions

Sendmail faisait déjà partie de l’environnement Unix de Berkeley avant de devenir un produit commercial ou un symbole dans les débats sur l’économie du logiciel libre. La biographie de l’Internet Hall of Fame indique qu’Eric Allman a développé delivermail et Sendmail à l’Université de Californie à Berkeley, alors qu’il travaillait sur INGRES, et que les deux logiciels ont été distribués avec BSD. Ce contexte éclaire l’importance du code public : les constructeurs de systèmes pouvaient examiner et compiler le routeur de courrier dans leur propre environnement.

Dans son article de 1994, « Changes in Sendmail Version 8 », Allman situe plus précisément la suite. Le travail majeur sur Sendmail s’est pratiquement interrompu après février 1987, puis a repris activement en juillet 1991. D’autres personnes ont assuré un soutien minimal entre-temps, tandis que des éditeurs et des contributeurs extérieurs produisaient des variantes. Allman cite plusieurs raisons à son retour : Berkeley avait besoin d’évolutions pour sa structure de sous-domaines et pour 4.4BSD ; il avait relu le livre Sendmail de Bryan Costales ; il fallait réunifier des versions divergentes ; enfin, les normes SMTP avaient changé.

Il s’agit d’un ensemble de motifs, pas d’un récit de conversion autour d’un seul déclencheur. Le code devait accompagner une nouvelle version de BSD, réconcilier des branches et répondre aux évolutions du protocole. Allman explique que IDA-Sendmail, parti de fichiers de configuration, était devenu un ensemble conséquent de correctifs, largement utilisé par ceux qui compilaient eux-mêmes les sources. Il ajoute que le groupe IDA et la plupart des éditeurs n’intégraient pas les clarifications et extensions SMTP récentes. C’est son constat rétrospectif de 1994, pas un recensement indépendant de chaque éditeur ou installation.

La distinction est essentielle. Une norme peut être publiée alors que le logiciel réellement exploité conserve des hypothèses plus anciennes. Si l’implémentation est privée, fragmentée ou difficile à obtenir, l’opérateur n’a parfois aucun chemin praticable entre le document normatif et une version de remplacement qu’il peut tester. Une version publique peut réduire cet écart en rendant les changements et les limites visibles. Elle ne peut obliger un éditeur à livrer ces changements, un administrateur à installer la version ou un serveur distant à l’accepter.

La version 8 rendait la limite visible

L’article prend Sendmail 8.6.6 en exemple pour montrer que la prise en charge n’est pas binaire. Il indique que cette version fournissait l’ESMTP de base défini par le RFC 1425, l’extension SIZE du RFC 1427 et une prise en charge limitée du paramètre BODY du RFC 1426. Il précise aussi que 8BITMIME n’était pas annoncé et que la conversion d’un message pour un serveur SMTP dépourvu du transport 8 bits n’était pas correctement gérée.

Ces détails sont plus précis que l’affirmation générale « Sendmail 8 prenait en charge les nouvelles normes SMTP ». Ils associent des capacités à une version. Le RFC 1425 définit l’échange ESMTP fondé sur EHLO ; le RFC 1427 traite de la taille des messages ; le RFC 1426 définit l’extension BODY ensuite associée à 8BITMIME. Les capacités annoncées par le serveur distant, le choix de l’expéditeur et le comportement du destinataire influent tous sur le transfert. L’article ne dit pas quand les installations ont effectué la mise à niveau ni à quelle fréquence ces cas se présentaient en production.

Une autre page consacrée aux changements de Sendmail Version 8 décrit le logiciel comme « conditionnellement conforme » au RFC 1123 et énumère les exigences satisfaites ainsi que les réserves restantes. Elle cite des numéros de RFC d’extensions plus récents que ceux de l’article de 1994. Il ne faut donc pas fusionner les deux documents en une seule liste de fonctionnalités. Ensemble, ils montrent qu’une mention de conformité doit préciser la version, le texte normatif et les exceptions.

L’apport d’Allman n’était donc pas simplement de publier une version majeure. Son article rendait l’interface de l’implémentation lisible : quelle extension était présente, laquelle restait partielle et où la conversion échouait encore. Le saut de numérotation à 8 avait une explication plus prosaïque : les fichiers de la distribution 4.4BSD portaient déjà le numéro 8.1. Il ne signifiait pas que tous les problèmes de protocole étaient résolus.

Le code public donnait aux opérateurs un objet vérifiable

La note 65 de Heng Lu fournit un angle éditorial utile : une norme publiée et un code exécuté ne répondent pas à la même question. Cette note ne constitue pas une preuve des motivations d’Allman ni de l’histoire de Sendmail. Appliquée ici, la distinction est pratique. Une norme décrit ce que les systèmes doivent pouvoir faire ; une version source permet d’examiner une implémentation ; un test et un échange en production montrent ce qu’une paire de systèmes donnée a réellement fait.

Le code public redistribue aussi le travail. Les mainteneurs peuvent publier un changement commun, les éditeurs peuvent porter des correctifs, et les opérateurs comparer leur comportement local à la source publiée. Mais les écarts de configuration, les correctifs privés et les anciens paquets peuvent survivre à la publication. Le code public ouvre une possibilité d’examen et de réparation ; il ne supprime pas le coût de maintenance.

La conclusion doit rester circonscrite. Dans le récit d’Allman, l’interruption de Sendmail a élargi l’écart entre les documents SMTP en évolution et les implémentations accessibles à de nombreux utilisateurs. La version 8 a fourni un point de comparaison public et intégré certaines extensions récentes, tout en conservant, comme le montre 8.6.6, des limites explicites. Ni une norme ni une publication ne prouvent un déploiement universel. La question utile est de savoir si l’opérateur peut identifier la version exacte, tester son comportement et choisir une voie de maintenance lorsque le logiciel est insuffisant.

Sources