Zusammenfassung

  • RFC 2034 stellt dem Text fast aller SMTP-Antworten der Klassen 2xx, 4xx und 5xx einen Code class.subject.detail voran. Dessen Klasse muss zum primären Antwortcode passen.
  • Ein unterstützender Server sendet den Code auch ohne EHLO des Clients. Weder Anforderung noch Abwahl sind vorgesehen; das Dokument begrenzt diesen Sonderfall ausdrücklich und schafft keinen allgemeinen Vorrang vor Aushandlung.
  • Die Struktur erleichtert Klassifizierung, Wiederholung und lokalisierte Erklärungen. Sie belegt die Erklärung eines Servers in einem Austausch, nicht die wirkliche Ursache, endgültige Zustellung oder das Lesen.

Ein 550 sagt einem Automaten genug, um eine dauerhafte Ablehnung zu erkennen. Für den Betrieb reicht das oft nicht. Eine unbekannte Adresse, verweigertes Weiterleiten und eine Zugriffsrichtlinie verlangen unterschiedliche Abhilfe, können aber denselben groben Code tragen. Wer die Unterscheidung aus freien Sätzen gewinnt, baut Produktstil und Sprache in seine Steuerlogik ein.

RFC 2034, veröffentlicht im Oktober 1996, schob deshalb eine maschinenlesbare Ebene zwischen Code und Erklärung. Der dreistellige SMTP-Code blieb bestehen, ebenso der Text für Menschen. An dessen Anfang kam eine feinere Kennung aus Klasse, Sachgebiet und Detail.

Eine überprüfbare Überlagerung

Die Erweiterung wird mit ENHANCEDSTATUSCODES angekündigt, hat keine Parameter und führt keine neuen Verben ein. Die Klasse ist 2, 4 oder 5; Sachgebiet und Detail bestehen aus jeweils einer bis drei Ziffern. 2xx muss 2.X.X, 4xx 4.X.X und 5xx 5.X.X enthalten.

Damit bleiben grobe Zustandsentscheidung und feine Einordnung widerspruchsfrei. Warteschlangen können Fälle innerhalb einer Klasse trennen, Teams über Produkte hinweg aggregieren, und Oberflächen eine deutsche Erklärung erzeugen, ohne englische Servertexte zu durchsuchen.

Die Übereinstimmung beweist allerdings nur Konsistenz. 550 5.1.1 zeigt, dass der Server eine dauerhafte Zielpostfach-Bedingung erklärt hat. Es prüft weder seine Datenbank noch die Zuständigkeit des Richtliniengebers oder das Ergebnis eines anderen berechtigten Pfades.

Nicht jede SMTP-Zeile gehört dazu

Die Pflicht gilt für 2xx-, 4xx- und 5xx-Zeilen außer der ersten Begrüßung und Antworten auf HELO oder EHLO. 3xx ist ausdrücklich ausgeschlossen. Im Beispiel trägt die Zwischenantwort 354 daher keinen erweiterten Code.

Messung ohne Sitzungskontext führt in die Irre. Ein Test, der hinter jedem SMTP-Code die Erweiterung erwartet, beanstandet korrektes Verhalten. Erst vorheriger Befehl und Position in der Sitzung unterscheiden Ausnahme und Auslassung.

Die Beispielwerte von 2.1.0 bis 5.7.1 zeigen die Struktur im Dialog. Sie schließen keine Beweiskette bis zum Empfänger. Eine Annahme des Nachrichteninhalts beschreibt einen Serverzustand; Postfachablage, Anzeige und Lesen liegen dahinter.

Unaufgeforderte Aktivierung als enges Sondermodell

Der Server fügt die Codes an, auch wenn der Client EHLO nicht benutzt. Es gibt keinen Aktivierungsbefehl und keine Abwahl. Das unterscheidet RFC 2034 von der üblichen Erweiterungsaushandlung.

Kompatibel bleibt die Änderung, weil sie im vorhandenen Textfeld steckt. Ein älterer Client durfte dort ohnehin variable Zeichen erwarten und kann die neue Kennung wie Text behandeln. Die Autoren hielten die damalige Qualität von SMTP-Fehlercodes zudem für so schwach, dass alle Clients von verständlicheren Kategorien profitieren sollten.

Unmittelbar danach wird die Reichweite beschränkt: Der Ansatz sei ein sehr spezieller Fall und dürfe künftige Erweiterungen nicht zu großen Interaktionsänderungen ohne Serverankündigung und Client-Freigabe ermächtigen. Nicht Aushandlung als solche wurde verworfen; eine einzelne Änderung wurde in eine sichere alte Syntax eingekapselt.

Mehrere Zeilen müssen eine Aussage behalten

Bei mehrzeiligen Antworten muss derselbe erweiterte Code am Textanfang jeder Zeile stehen. Das Beispiel wiederholt 5.7.1 in zwei 551-Zeilen. SMTP verlangt zugleich denselben primären Code in allen Zeilen.

Die Wiederholung hält die Kategorie auch bei zeilenweiser Protokollierung fest und verhindert einen Bedeutungswechsel innerhalb einer Antwort. Unterschiedliche Erläuterungen sind möglich, unterschiedliche Ergebnisse nicht.

Mehr Erläuterung vergrößert jedoch die Offenlegung. Die Sicherheitsbetrachtung von RFC 2034 warnt, dass zusätzliche Details mehr über den Server verraten und die Umgehung von Schutzmaßnahmen erleichtern können. Interne Hostnamen, Kontenexistenz, Weiterleitungswege oder Filtergrenzen sind nicht deshalb ungefährlich, weil ein Diagnosefeld Platz bietet.

Gute Antworten verbinden daher eine stabile Kategorie mit sparsamer Erklärung. Sie geben dem Gegenüber genug zum Handeln, aber nicht die interne Entscheidungsarchitektur.

Aussage und Ursache getrennt halten

Ein lokaler Betreiber darf 4.X.X erneut versuchen und 5.X.X nach seiner Regel beenden. Sachgebiet und Detail können Vorfälle an Adressverwaltung, Kapazität, Sicherheit oder Konfiguration verteilen. Zeitreihen können veränderte Serverklassifikation nach einem Release zeigen.

Der Code erklärt aber nicht, warum eine interne Abfrage scheiterte, ob ein Filter korrekt war oder ob der nächste Versuch gleich endet. Auch eine positive Klasse beweist keine endgültige Zustellung, Anzeige oder menschliche Rezeption.

Das RFC-Beispiel erzeugt später eine Benachrichtigung und erwähnt, dass der berichtende MTA erweiterte Codes aus Diagnosefeldern entfernte, um Unübersichtlichkeit zu verringern. Live-Antwort, Warteschlangenprotokoll, spätere Nachricht und UI-Zusammenfassung sind verschiedene Artefakte. Jede Transformation kann Evidenz verlieren.

RFC 5248 schuf später ein IANA-Register gegen Bedeutungsüberschneidungen. Registrierung koordiniert Begriffe; sie zertifiziert keinen Einzelfall. Auch ein registrierter Code kann von fehlerhafter Software dem falschen Ereignis zugeordnet werden.

Belastbare Aufzeichnung verbindet Gegenstelle, Zeit, Befehl, Hauptcode, erweiterten Code, vollständigen Text, Zeilengrenzen, Parserergebnis und lokale Entscheidung. Syntax und Übereinstimmung sind deterministisch prüfbar. Ursache, Legitimität und Endergebnis verlangen unabhängige Beobachtung. RFC 2034 machte eine Aussage lesbar, nicht unfehlbar.

Quellen