Zusammenfassung

  • RFC 1425 führte EHLO als gemeinsamen Entdeckungspunkt für SMTP-Erweiterungen ein. Die erfolgreiche Antwort galt für genau eine Sitzung und durfte nicht für die nächste zwischengespeichert werden.
  • Ein alter Server sollte EHLO ablehnen, Verbindung und Zustand bewahren und anschließend HELO zulassen. RFC 1651 beschrieb später Server, die stattdessen trennten oder den zweiten Gruß verweigerten.
  • Registrierung, Sitzungsanzeige, ausführbarer Rückweg, angenommener Befehl, abgeschlossene Mail-Transaktion und Zustellung sind getrennte Nachweise.

SMTP sollte wachsen, ohne dass jeder Mailserver gleichzeitig umgestellt werden musste.

Das Protokoll war gerade wegen seines kleinen Dialogs erfolgreich: Verbindung, Begrüßung, HELO, Umschlag und Inhalt. Anfang 1993 drohten neue Funktionen jedoch jeweils eigene Aushandlungen mitzubringen und die gemeinsame Sprache in Sonderfälle zu zerlegen.

RFC 1425 schuf einen schmalen Rahmen. Ein erweiterter Client begann mit EHLO; der Server nannte registrierte Schlüsselwörter und mögliche Parameter; das Verhalten jeder Erweiterung blieb in deren eigener RFC. Vereinheitlicht wurde der Entdeckungspunkt, nicht die Einführung.

Die Fähigkeit endete mit der Sitzung

Benötigte der Client Informationen über Erweiterungen, musste er zu Beginn jeder SMTP-Sitzung EHLO senden. Die Antwort einer früheren Sitzung durfte er nicht zwischenspeichern.

Damit wurde eine alte Beobachtung nicht zum dauerhaften Merkmal eines Hosts. Hinter demselben Namen konnten Prozess, Konfiguration, Route oder Wartungszustand wechseln. Die Erklärung musste in dem Kanal erfolgen, der die spätere Aktion tragen sollte.

Eine erfolgreiche 250-Antwort bedeutete zugleich Anfangszustand: keine laufende Mail-Transaktion, geleerte Zustandstabellen und Puffer. Die Folgezeilen enthielten Schlüsselwörter. Öffentliche Namen ohne X gehörten zu registrierten Erweiterungen; X kennzeichnete nach damaliger Konvention lokale Vereinbarungen.

Diese Liste war kein Leistungsnachweis. Der Client musste eine Erweiterung auswählen, deren Befehl oder Parameter senden und eine eigene Antwort erhalten.

RFC 1426 zeigt die Stufen: 8BITMIME in der EHLO-Antwort sehen, danach BODY=8BITMIME mit MAIL FROM anfordern und erst nach Annahme DATA übertragen. Die Acht-Bit-Mechanik gehört nicht zur These dieses Artikels. Entscheidend ist die Trennung von Anzeige und Nutzung.

Der gezeichnete Rückweg setzte lebenden Zustand voraus

Neue Clients mussten weiterhin mit Servern nach RFC 821 sprechen. RFC 1425 erwartete, dass ein solcher Server EHLO nicht erkennt, einen Fehler meldet, aber den Kanal offenhält. Danach konnte der Client zurücksetzen oder HELO senden und im alten SMTP fortfahren.

Die Ablehnung war keine Pflichtverletzung. Beide Seiten fielen auf die kleinere gemeinsame Regelmenge zurück.

Der Pfeil im Diagramm verbarg jedoch Ausführungsbedingungen. Die Verbindung musste offen bleiben. Der unbekannte Befehl durfte den internen Zustand nicht beschädigen. RSET oder HELO mussten in einem Zustand eintreffen, der sie noch verstand.

Der Standard konnte gültiges Verhalten definieren. Er konnte dessen Existenz im installierten Code nicht beweisen.

RFC 1651 schrieb die Betriebsrealität zurück

Im Juli 1994 ersetzte RFC 1651 RFC 1425 und ergänzte einen Abschnitt über fehlerhaft implementierte Server.

Bekannte Systeme schlossen den SMTP-Kanal beim Empfang von EHLO, teils vor, teils nach einer Antwort. Das widersprach RFC 821, wonach die normale Trennung erst nach QUIT folgen sollte. Der Verweis auf diese Regel hielt aber keinen Socket offen.

Der Client musste den Kanal selbst beobachten. Nach einer Trennung sollte er entscheiden, ob die Aufgabe ohne Erweiterungen möglich war. Dann konnte er eine neue Verbindung öffnen und HELO verwenden. Diese Verbindung war keine Fortsetzung, sondern ein neuer Versuch mit eigener Zeit, eigenem Zustand und eigenem Ergebnis.

Andere Server blieben verbunden, akzeptierten nach abgelehntem EHLO aber kein HELO. Ein vorgeschaltetes RSET half manchmal. Viele Implementierungen antworteten darauf wiederum mit 503 Bad sequence of commands; RFC 1651 erlaubte, diesen Fehler in genau diesem Wiederherstellungsfall zu ignorieren.

RFC 1869 behielt den Abschnitt 1995 bei. Die Abweichung aus dem Betrieb war Teil des Standardgedächtnisses geworden.

Das ist keine Nutzlosigkeit von Standards. Die Revision trennte Sollzustand und beobachteten Bestand und ließ laufende Implementierungen die Beschreibung der Übergangsrisiken korrigieren.

„Rückfall erfolgreich“ löscht Versuchskanten

Eine einzige Statuszeile kann mehrere Verbindungen verbergen.

Verbindungsaufbau, 220, EHLO, Antwort oder Trennung, RSET, HELO, Umschlagannahme, DATA, Übernahme durch ein Relay und Zustellung sind eigene Ereignisse. Erfolg auf dem zweiten Kanal macht den ersten nicht kontinuierlich. Ein angekündigtes Schlüsselwort beweist nicht die Annahme seines Befehls. Inhaltsannahme beweist keine Zustellung oder Lektüre.

Darum war das Cache-Verbot grundlegend. Fähigkeit war kein dauerhaftes Inventarattribut eines Hostnamens. Sie war eine Aussage in einer Sitzung. Mit dem Kanal endete ihr Kontext.

Die dünne Schicht verschob die Kosten

RFC 1425 warnte, Protokolle mit wenigen Optionen tendierten zur Allgegenwart, solche mit vielen zur Unübersichtlichkeit. Der gemeinsame Entdeckungspunkt blieb klein, die Einzelmechanismen wurden getrennt spezifiziert.

Alte Server brauchten keinen Stichtagswechsel. Dafür übernahm der reichweitenorientierte Client Mehrzeilenauswertung, veraltete Fähigkeiten, Trennung, Neuverbindung und Ausnahmezustände.

Das Register gab Namen eine gemeinsame Bedeutung, startete aber keine Software. Server entschieden lokal über Erweiterungen; Clients über den aktuell angekündigten kompatiblen Weg. Annahme blieb freiwillig, Interoperabilität musste ausgeführt werden.

Das Diagramm eröffnet die Prüfung. Erst die Sitzungsspur belegt den Pfeil.