Zusammenfassung

  • Nach einer PIPELINING-Anzeige in einer erfolgreichen EHLO-Antwort durfte der Client Befehlsgruppen senden, ohne jede Antwort abzuwarten; die Entscheidungen blieben trotzdem getrennt.
  • Der Zeitgewinn hing von Positionszählung, Zustandsgrenzen, korrekten Mehrzeilern, TCP-Flusskontrolle und der Zusage des Servers ab, empfangene Eingabe niemals zu verlieren.

Die Leerlaufzeit war die Last

SMTP arbeitet gewöhnlich als Frage und Antwort: Begrüßung, warten; Absender, warten; Empfänger, warten; Bitte um Datenbeginn, wieder warten. RFC 2920 beschrieb, wie diese Umlaufzeit auf Verbindungen mit hoher Latenz die gesamte Sitzung beherrschen konnte.

Pipelining ließ mehrere bekannte Befehle loslaufen, bevor die erste Antwort zurückkehrte. Der Server beurteilte weiterhin jeden einzeln. Gespart wurde die Stille, nicht die Entscheidung.

Im Gegenzug lagen mehrere Absichten gleichzeitig offen. Im Lockstep-Modus gehört die nächste Antwort zur einzigen Frage. In einer Gruppe muss ein exaktes Register ihre Zugehörigkeit sichern.

Laufender Code verlangte eine ausdrückliche Fähigkeit

TCP ordnet Bytes, doch reale Server konnten vorausgesendete Zeilen nicht automatisch sicher behandeln. RFC 2920 nennt Verbindungsübergaben, bei denen ein Prozess bereits gelesene Bytes verlor, das Leeren des TCP-Eingangs nach einem fehlgeschlagenen Befehl und falsche Verknüpfungen zwischen dem letzten RCPT TO und der Entscheidung über DATA.

Deshalb musste der Client EHLO senden und eine 250-Antwort mit PIPELINING erhalten. Das IANA-Register für SMTP-Erweiterungen führt das parameterlose Schlüsselwort weiterhin mit RFC 2920.

Es nennt weder Gruppengröße noch Geschwindigkeit oder Zustellgarantie. Der Server erklärt eine Verhaltensfähigkeit; der Client entscheidet lokal, ob und wie weit er sie nutzt.

Zustandswechsel beendeten die Gruppe

RSET, Absenderbefehle und RCPT TO dürfen innerhalb einer Gruppe stehen. EHLO, DATA, VRFY, EXPN, TURN, QUIT und NOOP müssen sie abschließen, weil ihr Erfolg oder Scheitern den nächsten Client-Schritt verändert. NOOP kann deshalb als Synchronisationspunkt dienen.

Mehrere Empfänger lassen sich parallel vorschlagen und später getrennt bewerten. Der Client darf jedoch nicht so handeln, als sei die Datenphase schon geöffnet. Spätere Erweiterungen können eigene Grenzen festlegen; Schweigen schafft keine Erlaubnis.

Position bestimmte den Eigentümer einer Antwort

Ein konstruiertes Beispiel sendet einen Absender, drei Empfänger und DATA: fünf Antworten sind offen. Codes können sich wiederholen, Texte variieren. RFC 2920 verbietet ausdrücklich, damit die Zuordnung zu erraten.

Der Client zählt jede eigenständige Antwort und verbindet sie mit der Position der ausgegebenen Befehle. Er prüft alle. Selbst wenn kein Empfänger akzeptiert wurde, darf er die Ablehnung von DATA nicht voraussetzen. Nimmt der Server DATA irrtümlich an, soll der Client nur den abschließenden Punkt senden und keine Nachricht ohne Empfänger.

Mehrzeilige Antworten tragen in Zwischenzeilen einen Bindestrich nach dem Code; die letzte Zeile nicht. Wer Zeilen als getrennte Antworten zählt, verschiebt jede spätere Entscheidung. Der Inhalt erklärt das Ergebnis erst, nachdem die Position seinen Besitzer festgelegt hat.

Geordnete Bytes verhinderten keinen Stillstand

Ein nichtblockierender Client kann Antworten lesen, während eine frühere Sendung noch aussteht. Ein blockierender Client muss sicherstellen, dass die ganze Gruppe in das TCP-Fenster passt. Sonst wartet er auf das Ende seines Schreibens, während der Server darauf wartet, dass seine Antworten gelesen werden.

RFC 2920 erwähnte historisch ein meist, aber nicht immer, 4K Oktett großes Fenster. Das ist kein universeller Gegenwartswert. Dauerhaft gilt: an die echte Flusskontrolle anpassen oder gleichzeitig lesen und schreiben.

PIPELINING erhöht die Menge unbestätigter Absicht. Nebenläufigkeit liefert Durchsatz; eine nachweisbare Grenze erhält Fortschritt.

Der Server durfte Eingabe nie ausradieren

Ein anbietender Server antwortet in Empfangsreihenfolge, unterstellt keine künftigen Befehle und sendet wartende Antworten, sobald sein lokaler TCP-Eingang leer ist. Unter keinen Umständen darf er Eingabe leeren oder verlieren.

Ein abgelehnter Empfänger erteilt keine Befugnis, nachfolgende Bytes zu löschen. Ein Prozesswechsel macht vorgelesene Daten nicht bedeutungslos. Der Puffer enthält bereits geäußerte Client-Absicht.

Einige normale Antworten dürfen gemeinsam gesendet werden, nicht aber Antworten auf gruppenabschließende oder unbekannte Befehle. Effizienz darf den Punkt nicht verbergen, an dem der Client seinen Zustand anpassen muss.

Drei RFCs, dieselbe schmale Regel

RFC 1854 führte die Erweiterung 1995 ein. RFC 2197 ersetzte ihn 1997 und bezeichnete die Änderungen als rein redaktionell. RFC 2920 wurde 2000 STD 60. RFC 5321 beschreibt SMTP weiterhin als absichtlich schrittweise, sofern eine beiderseits vereinbarte Erweiterung wie diese den Dialog nicht ändert.

PIPELINING authentifiziert niemanden, akzeptiert keinen Absender oder Empfänger, reserviert keinen Speicher, stellt keine Nachricht zu und beweist keine Unterstützung am nächsten Relay. Es erlaubt nur begrenzte Parallelität in dieser Sitzung.

Der historische Erfolg lag in dieser Begrenzung: Wartezeit wurde dort optional, wo beide laufenden Programme die für korrekten Zustand nötigen Belege erhalten konnten.

Quellen und Grenzen

Die Normgeschichte liefern RFC 1854, RFC 2197 und RFC 2920. RFC 5321 bildet den SMTP-Rahmen, IANA den aktuellen Eintrag. Gegenwärtige Verbreitung, Produktvorgaben, Leistungsgewinne und Fehlerquoten werden nicht gemessen.