Zusammenfassung

  • RFC 5248 schuf drei verwaltete Tabellen für erweiterte SMTP-Statuscodes und verband Zuweisungen mit Spezifikationen, Antragstellern und Änderungsverantwortlichen.
  • Diese Ordnung verhindert Namenskollisionen. Sie prüft weder die Diagnose eines Servers noch die Auslegung eines Clients, die Wiederholungslogik einer Queue oder das spätere Schicksal der Nachricht.

Ein Wörterbuch ist noch kein Tatbericht

In einer Zustellkette sprechen verschiedene Systeme zu verschiedenen Zeiten. Ein Server gibt eine Antwort. Ein Client deutet sie. Eine Queue entscheidet über den nächsten Versuch. Ein weiterer Server nimmt die Nachricht vielleicht an. Ein Postfach oder eine Anwendung trifft später eine eigene Entscheidung. Der Statuscode gehört zunächst nur zu einem dieser Übergänge.

RFC 3463 hatte dafür einen erweiterbaren Namensraum geschaffen, aber kein ausdrückliches Verfahren, neue Werte zu registrieren und nachzuverfolgen. Als widersprüchliche Definitionen auftraten, setzte RFC 5248 als BCP 138 eine öffentliche Verwaltung ein. Zugleich aktualisierte er Dokumente wie RFC 4468 und RFC 4954, die bereits Werte beigesteuert hatten.

Das Register löst damit ein Koordinationsproblem. Es kann zeigen, welche öffentliche Bedeutung belegt ist, auf welche Spezifikation sie verweist und wer Änderungen kontrolliert. Es beobachtet nicht, ob ein bestimmter Server den richtigen Test ausgeführt oder ein bestimmter Empfänger die Nachricht erhalten hat. Registriert ist die Sprache, nicht der Vorfall.

Drei Tabellen verteilen semantische Zuständigkeit

Die Schreibweise besteht aus Klasse, Subjekt und Detail. RFC 5248 führt dafür getrennte Tabellen: Klassen-Untercodes, Subjekt-Untercodes und aufgezählte Statuscodes. Beim aufgezählten Code bilden Subjekt und Detail eine Zuweisung; die Klasse bleibt als Platzhalter offen, weil dieselbe Bedingung nach Maßgabe ihrer Spezifikation mit mehreren Klassen vorkommen kann.

Ein Eintrag enthält Code, Kurzfassung oder Beispieltext, Beschreibung, Referenz samt Standardstatus, Antragsteller und Änderungsverantwortlichen. Aufgezählte Einträge nennen außerdem einen zugeordneten dreistelligen SMTP-Basisstatus. Die Felder machen die Herkunft einer Bedeutung prüfbar. Sie sagen nicht, dass eine konkrete Implementierung der Herkunft korrekt gefolgt ist.

Der Basisstatus ist ausdrücklich nicht exklusiv. Ein genannter dreistelliger Code schließt andere Kombinationen nicht aus. Das Feld darf Any oder Not given lauten. Wer daraus eine eindeutige Validierungstabelle baut, fügt eine Beschränkung hinzu, die das Register gerade nicht macht.

Auch Ungewissheit ist vorgesehen. X.0.0 ist der einzige undefinierte Code und gilt, wenn nur die Antwortklasse bekannt ist. Er füllt eine Wissenslücke nicht mit einer Ursache, sondern hält die Lücke sichtbar. Für forensische Daten ist das eine wichtige Eigenschaft.

Begutachtet wird die Definition

Neue Werte unterliegen Specification Required. RFC 5248 verlangt, dass auch nicht normative Spezifikationen leicht verfügbar sind, und nennt als Hauptzweck die Vermeidung von Verwechslung und Kollision statt unnötiger Hürden. Der heutige Rahmen in RFC 8126 verbindet eine dauerhaft öffentlich verfügbare Spezifikation mit der Prüfung durch benannte Fachleute. Sie betrachten Klarheit, Stabilität und technische Qualität.

Das ist keine Abnahme laufender Mailsoftware. Die Fachleute untersuchen keine Produktionsqueue, reproduzieren nicht den Fehler eines Empfängers und zertifizieren weder Parser noch Wiederholungsplan. Eine ausgezeichnet definierte Zuweisung kann von einem Server falsch gewählt werden. Eine reale Störung kann unter einem zu allgemeinen Code erscheinen.

Auch Änderungen haben begrenzte Träger. Ein Standard-Eintrag wird normalerweise durch Aktualisierung des Standards geändert. Ein nicht normativer Eintrag liegt bei seinem benannten Controller. Gewöhnliche Korrekturen betreffen Kurzbeschreibung oder Referenz, nicht die heimliche Umwidmung von Nummer und Beispieltext. Die IESG kann ausnahmsweise eingreifen, um Konflikte aufzulösen.

Die Erstausstattung des Registers war bewusst nicht homogen. Sie übernahm Werte aus veröffentlichten RFCs und solche, die in der Praxis ohne veröffentlichte Spezifikation benutzt wurden. Mehrere Sicherheitswerte kamen unter IESG-Kontrolle hinzu. „Trust Relationship Required“ wurde von einer früheren Verwendung von X.7.8 nach X.7.14 verschoben. Das Register kann die semantische Adresse korrigieren. Es beweist weder die Migration jeder Implementierung noch die nachträgliche Bedeutung jedes alten Logs.

Die Klasse ist Handlungsrahmen, keine Prophezeiung

RFC 3463 beschreibt Klasse 2 als Erfolg in einer Zustellstatusmeldung. Klasse 4 bezeichnet einen anhaltenden vorübergehenden Fehler, bei dem ein späterer Versuch gelingen kann. Klasse 5 bezeichnet einen dauerhaften Fehler, der üblicherweise eine Änderung der Nachricht oder des Ziels verlangt.

Diese Semantik macht automatisches Verhalten interoperabel, friert aber die Zukunft nicht ein. RFC 5321 verlangt, dass der SMTP-Client nach dem Antwortcode und nicht nach dem Erläuterungstext handelt. 4yz erlaubt einen späteren Versuch unter passenden Bedingungen. 5yz verbietet, exakt dieselbe Anfrage unverändert zu wiederholen. Zugleich kann selbst ein als dauerhaft erscheinender Zustand später behoben werden.

Eine verantwortliche Queue braucht deshalb die zeitliche Umgebung: Nachrichten- und Empfängerkennung, Versuchszahl, verstrichene Zeit, antwortenden Server, Route, Konfiguration und spätere Antwort. 4.x.x garantiert keinen Erfolg. 5.x.x garantiert keine ewige Unveränderlichkeit. Der Code begründet eine begrenzte nächste Reaktion, nicht das Endergebnis.

RFC 2034 legt die Übertragung erweiterter Codes in SMTP-Antworten fest. RFC 5248 regelt das gemeinsame Vokabular. Dazwischen und danach liegen Emissionslogik, Parser, Speicherung, Richtlinienentscheidung, weitere Übergabe, Zielannahme und Postfachverarbeitung. Ein einziges Statusfeld kann diese Flächen nicht wahrheitsgetreu zusammenfassen.

Mehr Einzelheiten können ein Sicherheitsleck sein

RFC 5248 warnt, dass erweiterte Codes interne Implementierungsdetails preisgeben können. Bei der Authentisierung kann die Unterscheidung zwischen unbekanntem Benutzer und falschem Passwort einem Angreifer die Erkundung vorhandener Konten ermöglichen. Spezifikationen sollen deshalb festlegen, wann Serversoftware Details einschränkt.

Eine allgemeinere öffentliche Antwort kann also neben einer genaueren internen Diagnose richtig sein. Ein Evidenzsystem sollte beide Werte und die Offenlegungsregel aufbewahren. Weniger öffentliche Präzision ist nicht automatisch schlechte Diagnose; mehr öffentliche Präzision ist nicht automatisch mehr Wahrheit. Ursache, Genauigkeit und Offenlegung haben getrennte Verantwortliche.

Die Belegkette darf keine Stufen überspringen

Zuerst lässt sich feststellen, dass ein Code syntaktisch lesbar ist. Danach, dass die beobachtete Registerversion seine Zuweisung enthält. Dann liegt weiterhin nur eine Aussage der Implementierung vor: Sie behauptet die registrierte Bedingung. Erst die Verträglichkeit mit der Basisantwort, der erhaltene Transaktionskontext sowie Server- und Queue-Belege können diese Aussage stützen.

Höher liegen Handlung und Wirkung: Hat die Richtlinie die richtige Nachricht und den richtigen Empfänger behandelt? Fand eine spätere Übertragung statt? Nahm das Ziel an? Was tat das Postfach? Erreichte der Inhalt eine Person oder einen Geschäftsprozess? Keine untere Quittung erbt die Autorität einer oberen.

Lu Hengs Trennung von laufendem Code und Realitätsebenen hilft hier. Das Register koordiniert ein Symbol. Die Implementierung wendet es an. Telemetrie beobachtet Übergänge. Die Organisation entscheidet. Gute Governance verknüpft diese Ebenen, ohne aus dem öffentlichen Namen eine Ersatzbeobachtung zu machen.

Quellen