Zusammenfassung

  • Eric Allmans Bericht von 1994 zufolge endete die wesentliche Sendmail-Entwicklung nach Februar 1987 und begann im Juli 1991 erneut, nachdem sich Varianten von Anbietern und externen Mitwirkenden gebildet hatten.
  • Allman nannte mehrere Gründe für seine Rückkehr: Änderungen bei Berkeley, auseinanderlaufende Versionen und SMTP-Erweiterungen, die seiner Einschätzung nach die meisten Implementierungen nicht erreichten.
  • Sendmail 8.6.6 unterstützte einige Erweiterungen, andere nur eingeschränkt. Die öffentliche Version machte diese Grenze überprüfbar, belegte aber weder breite Nutzung noch vollständige Normkonformität.

Aus einer langen Pause wurde ein Versionsproblem

Sendmail gehörte zur Unix-Umgebung von Berkeley, bevor es zum Unternehmensprodukt oder zum Symbol in Debatten über die Ökonomie offener Software wurde. Die Biografie der Internet Hall of Fame berichtet, dass Eric Allman delivermail und Sendmail an der University of California, Berkeley, während seiner Arbeit an INGRES entwickelte; beide wurden mit BSD verteilt. Das erklärt, weshalb öffentlicher Quellcode wichtig war: Systembauer konnten den Mailrouter untersuchen und in ihrer eigenen Umgebung kompilieren.

Allmans Aufsatz von 1994, „Changes in Sendmail Version 8“, beschreibt die folgende Pause genauer. Die wesentliche Arbeit an Sendmail kam nach Februar 1987 praktisch zum Erliegen; aktiv weitergearbeitet wurde wieder ab Juli 1991. Andere leisteten in der Zwischenzeit minimale Unterstützung, während Anbieter und externe Mitwirkende eigene Varianten schufen. Allman führte mehrere Gründe für die Rückkehr an: Berkeley brauchte Änderungen für seine Subdomain-Struktur und für 4.4BSD; er hatte Bryan Costales’ Sendmail-Buch begutachtet; auseinanderlaufende Versionen sollten zusammengeführt werden; und die SMTP-Standards hatten sich geändert.

Das war ein Bündel von Motiven, keine Geschichte mit einem einzigen Auslöser. Der Code musste zu einer neuen BSD-Version passen, Zweige zusammenführen und auf die Protokollentwicklung reagieren. Allman schrieb, IDA-Sendmail sei von Konfigurationsdateien zu einer umfangreichen Patch-Sammlung gewachsen und bei Menschen weit verbreitet gewesen, die den Quellcode selbst kompilierten. Er erklärte auch, weder die IDA-Gruppe noch die meisten Anbieter hätten die neueren SMTP-Klarstellungen und Erweiterungen übernommen. Das ist Allmans Rückblick von 1994, keine unabhängige Erhebung zu jedem Anbieter oder jeder Installation.

Die Unterscheidung ist wichtig. Ein Standard kann veröffentlicht sein, während die tatsächlich ausgeführte Software ältere Annahmen beibehält. Ist die Implementierung nicht öffentlich, stark verzweigt oder schwer zu beziehen, fehlt Betreibern womöglich ein praktikabler Weg vom Dokument zu einem prüfbaren Ersatz. Eine öffentliche Version kann die Lücke verkleinern, indem sie Änderungen und Einschränkungen sichtbar macht. Sie kann Anbieter jedoch nicht zur Auslieferung, Administratoren nicht zur Installation und entfernte Mailserver nicht zur Annahme zwingen.

Version 8 machte die Grenze sichtbar

Allman nutzt Sendmail 8.6.6, um zu zeigen, dass Unterstützung keine Ja-Nein-Eigenschaft ist. Der Aufsatz nennt grundlegendes ESMTP gemäß RFC 1425, die Nachrichtengrößen-Erweiterung aus RFC 1427 und eine eingeschränkte Unterstützung des BODY-Parameters aus RFC 1426. Außerdem heißt es, diese Version habe 8BITMIME nicht angekündigt und Nachrichten für einen nicht 8-Bit-fähigen SMTP-Partner nicht korrekt umgewandelt.

Das ist genauer als die pauschale Aussage, „Sendmail 8 unterstützte die neuen SMTP-Standards“. Die Fähigkeiten werden einer konkreten Version zugeordnet. RFC 1425 definiert den ESMTP-Fähigkeitsaustausch über EHLO, RFC 1427 SIZE und RFC 1426 die BODY-Erweiterung, die später mit 8BITMIME verbunden wurde. Was der Partner ankündigt, was der Absender auswählt und wie der Empfänger verarbeitet, beeinflusst die Übertragung. Der Aufsatz belegt nicht, wann Installationen aktualisierten oder wie häufig diese Fälle im Produktivbetrieb auftraten.

Eine separate Änderungsseite zu Sendmail Version 8 bezeichnet die Software als „bedingt konform“ mit RFC 1123 und listet erfüllte Anforderungen sowie Vorbehalte auf. Sie verweist auf spätere Erweiterungs-RFCs als der Aufsatz von 1994. Beide Quellen dürfen daher nicht zu einer einzigen Funktionsliste vermischt werden. Zusammengenommen zeigen sie, dass eine Konformitätsaussage Version, Normtext und Ausnahmen nennen muss.

Allmans Beitrag bestand also nicht nur darin, eine neue Hauptversion zu veröffentlichen. Sein Aufsatz machte die Implementierungsgrenze lesbar: welche Erweiterung vorhanden war, welche nur teilweise unterstützt wurde und wo die Umwandlung noch scheiterte. Auch der Sprung auf die Versionsnummer 8 hatte einen nüchternen Grund: Dateien in der 4.4BSD-Distribution waren bereits mit 8.1 nummeriert. Das bedeutete nicht, dass alle Protokollprobleme gelöst waren.

Öffentlicher Quellcode gab Betreibern ein prüfbares Objekt

Heng Lus Note 65 liefert eine hilfreiche redaktionelle Perspektive: Ein veröffentlichter Standard und laufender Code beantworten unterschiedliche Fragen. Die Note ist kein Beleg für Allmans Motive oder die Sendmail-Geschichte. Hier ist die Unterscheidung praktisch. Ein Standard beschreibt, was Systeme leisten sollen; eine Quellversion ermöglicht die Prüfung einer Implementierung; ein Test und ein realer Austausch zeigen, was ein bestimmtes Systempaar tatsächlich tat.

Öffentlicher Code verteilt zugleich die Wartungsarbeit. Maintainer können eine gemeinsame Änderung veröffentlichen, Anbieter Patches übernehmen und Betreiber lokales Verhalten mit dem verfügbaren Quellcode vergleichen. Konfigurationsabweichungen, private Patches und alte Pakete können die Unterschiede dennoch fortschreiben. Veröffentlichung eröffnet eine Möglichkeit zur Prüfung und Reparatur; sie beseitigt nicht die Wartungskosten.

Die Schlussfolgerung muss begrenzt bleiben. In Allmans Darstellung vergrößerte die Sendmail-Pause die Distanz zwischen den fortentwickelten SMTP-Dokumenten und den für viele Nutzer verfügbaren Implementierungen. Version 8 lieferte einen öffentlichen Vergleichspunkt und übernahm einige neuere Erweiterungen; das Beispiel 8.6.6 hält zugleich klare Grenzen fest. Weder ein Standard noch ein öffentlicher Quellcode beweist eine universelle Einführung. Entscheidend ist, ob Betreiber die genaue Version bestimmen, ihr Verhalten testen und bei Lücken einen gepflegten Weg wählen können.

Quellen