Ein erweiterter Statuscode ist ein strukturierter Hinweis und kein vollständiger Vorfallbericht. „5.7.1“ kann die Untersuchung auf Sicherheit oder Richtlinien eingrenzen, kann jedoch nicht den Richtlinieneigentümer, die betroffene Route oder die korrekte Konfigurationsänderung selbstständig identifizieren. Bewahren Sie die vollständige Diagnose während der Fehlerbehebung neben dem Code auf.
Lesen Sie alle drei Komponenten
RFC 3463 definiert erweiterte Statuscodes mit Klassen-, Betreff- und Detailkomponenten. Die Klasse unterscheidet Erfolg, anhaltendes vorübergehendes Scheitern und dauerhaftes Scheitern. Betreffkategorien unterscheiden Bereiche wie Adressierung, Postfachstatus, Routing und Sicherheit oder Richtlinien. Das Detail grenzt den Zustand innerhalb dieses Themas ein. Die gewöhnliche dreistellige SMTP Antwort bleibt Teil des Beweismittels. RFC 3463.
Behandeln Sie die endgültige Zahl nicht als globale Fehlerkennung. Die Bedeutung hängt vom vollständigen erweiterten Code und der entsprechenden Registrierungs- oder Anbieterdokumentation ab. Ein empfangendes System kann auch ohne erweiterten Code nützliche Prosa zurückgeben. Wenn die Basisklasse und die erweiterte Klasse inkonsistent erscheinen, behalten Sie die genauen Bytes bei und untersuchen Sie das Anbieterverhalten, anstatt das Protokoll stillschweigend neu zu schreiben.
Trennen Sie SMTP Antworten von Zustellberichten
Während eines Gesprächs erfolgt eine SMTP Antwort. Eine Zustellungsstatusbenachrichtigung kann später über Ergebnisse berichten und mehrere Empfänger beschreiben. RFC 3464 definiert Felder wie „Endempfänger“, „Aktion“, „Status“, „Remote-MTA“ und „Diagnosecode“. Lesen Sie die Blöcke pro Empfänger unabhängig voneinander. Ein einziger Fehler beweist nicht, dass jeder Empfänger gescheitert ist. RFC 3464 Abschnitt 2.
Aktion und Status beantworten unterschiedliche Fragen. Aktion: fehlgeschlagen bedeutet die Meldung MTA hat Versuche für diesen Empfänger gestoppt. Status: 4.2.2 kann die vorübergehende Ursache für ein volles Postfach immer noch beschreiben, nachdem die Wiederholungsversuche erschöpft sind; fehlgeschlagen und ein 4.xx-Status ist in einem DSN gültig, keine inkonsistente SMTP Antwort. Beispielsweise wird ein abgelaufener Artikel mit diesen Feldern nicht automatisch fortgesetzt, nur weil die Kapazität wiederhergestellt ist. Überprüfen Sie die tatsächliche Warteschlange, bevor Sie einen Ersatz autorisieren. Sehen RFC 3464 Abschnitt 2.3.3.
Ein für Menschen lesbarer Bounce-Betreff ist für die Triage nützlich, kann aber die entscheidenden Felder weglassen. Besorgen Sie sich nach Möglichkeit den maschinenlesbaren Bericht oder das Versandprotokoll. Halten Sie den Berichtsserver vom Remote-Server getrennt und unterscheiden Sie den Zeitstempel eines Berichts vom Zeitstempel des fehlgeschlagenen SMTP Befehls.
Lesen Sie einen hypothetischen Empfängerblock
Angenommen, ein Sendeprotokoll zeichnet RCPT TO für missing@example.test auf, gefolgt von 550 5.1.1. Ein beispielhafter DSN-Empfängerblock könnte Final-Recipient: rfc822; missing@example.test , Aktion: fehlgeschlagen, Status: 5.1.1, Remote-MTA: dns; mx.example .test und Diagnose-Code: smtp; 550 5.1.1 Kein solcher Benutzer. Hierbei handelt es sich um erfundene Feldwerte, nicht um eine ausgeführte Transaktion oder einen vollständigen MIME Bericht.
Die fehlgeschlagene Aktion ist für diesen Empfänger endgültig, während die Diagnose auf eine Adressierung hinweist. Es wird nicht festgestellt, warum die Adresse nicht verfügbar ist oder was mit anderen Empfängern passiert ist. Erhalten Sie diese Antworten aus ihren eigenen Blöcken und vertrauenswürdigen Protokollen. „Endempfänger“, „Aktion“ und „Status“ sind Pflichtfelder pro Empfänger. Remote-MTA und Diagnostic-Code sind bedingt oder optional. Ihr Fehlen ist keine Erlaubnis, einen abweisenden Host- oder Fehlertext zu erfinden.
Für unbekannte registrierte Details konsultieren Sie die aktuelle Erweitertes IANA Statusregister und die zitierte Spezifikation, dann die aktuelle Erklärung des Anbieters. RFC 3463 liefert das Framework, keine vollständige Liste aller späteren Codes.
Verwandeln Sie den Code in eine überprüfbare Hypothese
Bestätigen Sie für einen Adressierungscode die beabsichtigte Adresse und das Verhalten des Empfangssystems. Überprüfen Sie für einen Routing-Code den fehlgeschlagenen nächsten Hop und die Routenkonfiguration. Identifizieren Sie für einen Sicherheits- oder Richtliniencode die genannte Anforderung und ihren Eigentümer. Vermeiden Sie es, mit einer bevorzugten DNS Änderung zu beginnen und dann jede Antwort als Unterstützung dafür zu interpretieren.
Notieren Sie eine Hypothese, die Beweise, die sie vorhersagt, und den kleinsten autorisierten Test. Eine korrigierte Nachricht sollte mit dem Original auf der entsprechenden Route und Empfängerklasse verglichen werden. Bewahren Sie ein widersprüchliches Ergebnis als nützlichen Beweis auf, anstatt es in die ursprüngliche Erklärung zu zwingen. Eskalationspakete sollten Zeitstempel, genaue Antwort, betroffenen Umfang und bereits getestete Änderungen enthalten, wobei Nachrichteninhalte und personenbezogene Daten auf ein Minimum beschränkt werden sollten. Eine Codesuche ist der Beginn einer Diagnose, nicht ihr Abschluss.
Erstellen Sie ein nützliches Eskalationspaket
- Identität: Behalten Sie die Nachrichten- und Warteschlangen-IDs, den Empfänger des fehlgeschlagenen Umschlags und den betroffenen Bereich bei.
- Zeitleiste: Einreichung, Fehlversuch und Eingang des Berichts separat erfassen.
- Diagnose: Geben Sie die genaue SMTP Antwort, die Befehlsstufe und die DSN-Felder pro Empfänger an.
- Eigentum: Unterscheiden Sie das meldende System vom ablehnenden System, jeweils mit Nachweisen.
- Nächster Schritt: Geben Sie einen nachweisbaren Grund, die kleinste autorisierte Prüfung und etwaige widersprüchliche Beweise an. Persönliche Daten minimieren.