Das Symptom
Im Posteingang liegt eine Nachricht von Mail Delivery Subsystem, postmaster
oder Mailer-Daemon. Darin steht ein Absatz Englisch, ein eingerückter Block mit
kryptischen Zeilen und irgendwo darin eine Zahl. Die naheliegende Reaktion ist,
die Mail einfach noch einmal zu schicken — manchmal klappt das, manchmal kommt
derselbe Rückläufer zurück, und in beiden Fällen weiß hinterher niemand, warum.
Besonders unangenehm wird es bei Rundmails: Von zweihundert Empfängern melden
sich sieben mit einem Rückläufer, und die Frage lautet, welche davon man
austragen muss und welche nur einen schlechten Tag hatten.
Die „Layer 8“-Wahrheit
Der Rückläufer ist kein Rätsel, sondern ein ausgefülltes Formular. Man muss nur
wissen, welches Feld welche Frage beantwortet — und die wichtigste Antwort steckt
in einer einzigen Ziffer. SMTP arbeitet mit dreistelligen Antwortcodes, und die
erste Stelle entscheidet über das weitere Vorgehen: Eine 4 heißt vorübergehend
gescheitert, die Handlung darf erneut verlangt werden. Eine 5 heißt dauerhaft
gescheitert, dieselbe Anforderung soll nicht wiederholt werden. Der Standard
liefert dazu eine bemerkenswert nüchterne Faustregel: Eine Antwort gehört in die
4er-Klasse, wenn sie beim identischen Wiederholen erfolgreich sein kann, ohne
dass sich am Befehl oder an den Eigenschaften der beiden Seiten etwas ändert. Ist
irgendeine Änderung nötig, ist es eine 5.
Daneben steht seit über zwanzig Jahren ein zweiter, feinerer Code — der
dreiteilige aus Klasse, Betreff und Detail, also etwa 5.1.1 oder 4.2.2. Er
existiert, weil die rund zwölf brauchbaren SMTP-Codes für Zustellberichte hoffnungslos
überladen waren: Jeder einzelne musste mehrere verschiedene Fehlerlagen abdecken.
Die erste Zahl wiederholt die Aussage der ersten SMTP-Ziffer, die zweite benennt
die wahrscheinliche Quelle des Problems, die dritte den genauen Fehler. Praktisch
ist vor allem die mittlere: Sie sagt, in wessen Zuständigkeit der Fall fällt —
Adresse, Postfach, Zielsystem, Netz, Protokoll, Inhalt oder Richtlinie. Wer
5.7.1 liest, weiß sofort, dass es keine Tippfehler-Frage ist, sondern eine
Richtlinienentscheidung des Empfängers. Wer 4.2.2 liest, weiß, dass jemandes
Postfach voll ist und ihm niemand außerhalb dieses Postfachs helfen kann.
Diese Seite erklärt bewusst keine einzelne Ursache. Warum ein Empfänger nach
Richtlinie ablehnt, warum eine Weiterleitung die Beglaubigung zerlegt, warum der
eigene Anschluss gar nicht erst senden darf — das sind eigene Geschichten. Hier
geht es um den Schritt davor, den fast alle überspringen: erst herauszufinden,
welche Sorte Problem überhaupt vorliegt. Denn die beiden häufigsten Fehler auf
Schicht 8 sind exakt gegenläufig. Der eine schickt bei einer 4 sofort alles neu
und produziert Dubletten, obwohl der eigene Server ohnehin weiter zustellt —
mindestens eine halbe Stunde Abstand zwischen zwei Versuchen und vier bis fünf
Tage Geduld sind im Standard vorgesehen, nicht Faulheit des Providers. Der andere
schickt bei einer 5 jede Woche erneut an eine Adresse, die es nachweislich nicht
gibt, und wundert sich, dass der Ruf des eigenen Mailservers sinkt. Eine Ziffer
lesen kostet zehn Sekunden. Beide Fehler kosten deutlich mehr.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.Den Rückläufer im Original öffnen, nicht die Zusammenfassung des Mailprogramms
Mailprogramme zeigen gern nur einen freundlichen Satz und verstecken die Technik. Gebraucht wird die Quelltextansicht der Rückläufer-Nachricht. Nach RFC 3464 enthält ein maschinenlesbarer Zustellbericht je Empfänger drei aussagekräftige Felder: Action mit einem der Werte failed, delayed, delivered, relayed oder expanded — failed bedeutet laut RFC, dass die Nachricht nicht zugestellt werden konnte und das meldende System alle weiteren Versuche aufgegeben hat, delayed dagegen, dass es bislang nicht zustellen konnte, es aber weiter versuchen wird. Dazu Status mit dem erweiterten Statuscode und Diagnostic-Code mit dem tatsächlichen Diagnosecode, den der Transportweg ausgegeben hat. Bei einem verzögerten Bericht darf zusätzlich Will-Retry-Until stehen: das Datum, nach dem das meldende System alle Zustellversuche aufzugeben gedenkt.
2.Die erste Ziffer bestimmen — das ist die eigentliche Frage
Alles andere ist Feinheit. Steht am Anfang der dreistelligen Zahl eine 4, ist die Nachricht noch nicht verloren; steht dort eine 5, ist sie es. RFC 5321 macht diese Ziffer ausdrücklich zum tragenden Teil: Ein SMTP-Client MUSS seine Handlungen allein nach dem Antwortcode richten und nicht nach dem Text, und für unbekannte Codes MUSS er sich ausschließlich nach der ersten Ziffer richten. Wenn also der Anbieter einen Code sendet, der in keiner Liste steht, ist die erste Ziffer trotzdem verbindlich. Typische 4er sind 421 (Dienst nicht verfügbar, die Übertragung wird geschlossen), 450 (Postfach nicht verfügbar, etwa belegt oder aus Richtliniengründen vorübergehend gesperrt) und 452 (unzureichender Systemspeicher). Typische 5er sind 550 (Postfach nicht verfügbar, etwa nicht gefunden, kein Zugriff, oder der Befehl wurde aus Richtliniengründen abgelehnt), 552 (Speicherzuteilung überschritten) und 554 (Transaktion fehlgeschlagen).
3.Den erweiterten Statuscode zerlegen und die Zuständigkeit ablesen
Der Code wird von links nach rechts gelesen: Klasse, dann Betreff, dann Detail. 5.1.1 ist zum Beispiel laut RFC 3463 eine dauerhafte Ablehnung wegen der Adressierung mit dem Detail Bad destination mailbox address, also: Das in der Adresse angegebene Postfach existiert nicht — bei Internet-Adressen ist der Teil links vom Klammeraffen ungültig, und dieser Code ist nur für dauerhafte Fehler brauchbar. 4.2.2 ist dagegen Mailbox full: Das Postfach ist voll, weil eine Mengenbeschränkung oder die physische Kapazität erschöpft ist; der RFC hält dazu fest, dass dieser Code als vorübergehender Dauerfehler benutzt werden sollte, weil der Empfänger Nachrichten löschen kann, um Platz zu schaffen. Kennt man das Detail nicht, hilft der RFC weiter: Ein Client MUSS die Klasse erkennen und melden, auch wenn die nachfolgenden Teile unbekannt sind, und sollte die allgemeine Fehlerbeschreibung des Betreffs melden, wenn das Detail nicht erkannt wird.
4.Bei einer 4 am Anfang: die Warteschlange ansehen, statt die Mail noch einmal zu schicken
Ein 4er-Rückläufer mit der Angabe delayed ist keine Aufforderung, irgendetwas zu tun — der eigene Server arbeitet bereits daran. Erneut abzuschicken erzeugt nur eine zweite Kopie in derselben Warteschlange. Die folgenden Befehle gelten für Postfix: Der erste zeigt die Warteschlange mit dem Grund je Nachricht, der zweite gibt eine wartende Nachricht samt Kopfzeilen aus, der dritte stößt einen sofortigen Zustellversuch für die gesamte Warteschlange an. Der Befehl mailq ist bei Postfix gleichbedeutend mit postqueue -p.
postqueue -p
postcat -q QUEUE-ID
postqueue -f
5.Bei einer 5 am Anfang: die Ursache beheben oder die Adresse aus dem Verteiler nehmen
Ein 5er ist eine Aussage über die Nachricht oder das Ziel, nicht über den Zeitpunkt. RFC 3463 formuliert die Konsequenz unmissverständlich: Für eine erfolgreiche Zustellung muss die Nachricht oder das Ziel geändert werden. Bei 5.1.1 oder 5.1.2 heißt das Adresse korrigieren oder streichen; bei 5.2.3 oder 5.3.4 die Nachricht verkleinern; bei 5.7.x liegt es an einer Richtlinie des Empfängers — dort führt der Weg über die Absenderbeglaubigung, nicht über einen weiteren Sendeversuch. Wichtig für Verteilerlisten: Eine Adresse, die dauerhaft ablehnt, gehört ausgetragen. Sie jede Woche erneut anzuschreiben schadet dem Ruf des eigenen Servers und ändert am Ergebnis nichts.
6.Nachsehen, was der Gegenserver im Protokoll wirklich gesagt hat
Der Rückläufer ist eine Übersetzung; das Protokoll des eigenen Servers enthält den Originalsatz der Gegenstelle samt Antwortcode. Der erste Befehl durchsucht das klassische Mailprotokoll nach abgewiesenen Nachrichten, der zweite zeigt dasselbe auf Systemen mit journald. Dort steht die Zeile, auf die es ankommt — inklusive des Textes hinter dem Code, den der Standard zwar als für den Menschen bestimmt bezeichnet, der aber oft die einzige konkrete Auskunft enthält.
grep -i 'status=bounced' /var/log/mail.log
journalctl -u postfix.service --since "1 hour ago"
7.Den Fall einordnen, in dem gar kein Rückläufer kommt
Auch das ist geregelt. RFC 5321 hält fest: Nimmt der empfangende Server eine Nachricht an, indem er auf DATA mit 250 OK antwortet, übernimmt er die Verantwortung für Zustellung oder Weiterleitung und MUSS sie ernst nehmen — er DARF die Nachricht nicht aus nichtigen Gründen verlieren. Scheitert die Zustellung nach der Annahme, MUSS er eine Benachrichtigung erstellen und versenden, und zwar mit einem leeren Rückweg. Und genau daraus folgt die Ausnahme: Ist der Rückweg der ursprünglichen Nachricht selbst leer, DARF der Server keine Benachrichtigung senden. Rückläufer über Rückläufer gibt es also bewusst nicht — sie würden Schleifen erzeugen. Bleibt eine Benachrichtigung trotzdem aus, obwohl der Rückweg gesetzt war, wurde die Nachricht entweder stillschweigend verworfen oder der Rückläufer selbst als Spam einsortiert.