Exchange Online und NDRs

Wer Mails sendet, muss auch mit Unzustellbarkeiten zurecht kommen. Aber kaum ein Anwender kann mit den teils kryptischen Meldungen etwas anfangen. Zum Glück sind die meisten Fehlernummern halbwegs normiert. Office 365 hat aber noch mehr darauf gemacht. Es analysiert den NDR und bereitet ihn für den Anwender möglichst ansprechend auf. Hier mal ein Beispiel eines NDR; den jemand beim Versand an meine Adresse in seinem Tenant bekommen hat. Da die Mail ziemlich "lang" ist, habe ich sie schon in vier Abschnitte aufgeteilt:

Teil 1: Anwenderfreundliche Information

Der erste Teil ist der, den ein Anwender zuerst liest. Hier generiert Office 365 eine Beschreibung, die sich an Endanwender richtet und ihm Hinweise auf den Fehler geben soll. Eine Art Laufbalken zeigt, wie weit die Mail gekommen ist. DAS Bild hier stimmt aber schon nicht ganz, denn wie sie später sehen werden, war die Mail schon drauf und dran Office 365 zu verlassen:

In vielen Fällen ist diese Erläuterung schon ausreichend. In meinem Fall aber nicht, denn ich bin sicher, dass mein Postfach fehlerfrei funktioniert. Wobei der hier als Link angegebene Error Code 5.1.1 natürlich nicht passt

Teil 2: Hinweise für den Administrator

Daher muss ich ein Stück weiter schauen, wo Microsoft erneut einen eigenen Text bereitstellt, der sich aber nun an den Administrator oder qualifizierten Helpdesk richtet. Hier sehen Sie das erste mal den realen Fehlercode "554 5.4.6" und Microsoft beschreibt, was die Ursachen sein könnten.

Am Ende steht hier nun auch der korrekte Link auf die weiterführenden Informationen zum Fehler 5.4.6. Nur passt der hier halt auch noch nicht, da es sich nicht um eine Loop handelt.

Teil 3: Hops im Detail

Wem das noch nicht reicht, kann nun weiter gehen und bekommt noch mehr Details. Der Anteil an "Prosa" nimmt ab und die IP-Adressen und Hostnamen kommen zum Vorschein. Eine schöne Tabelle liefert hier die Stationen und auch die Error-Details sind nun ausführlich, dass der Administrator nicht nur den Fehlercode 550 5.4.6 sieht, sondern auch den Text, den der andere Mailserver mitgeliefert hat und den Namen des Mailservers.

Jetzt wird mir schon einmal klar, dass Office 365 versucht hat die Mail an den Mailserver von Net at Work zu senden und dieser die Mails als "Loop" erkannt hat. Ich bin mit aber sicher, dass es keinen Loop gab und die Liste der Stationen zeigt das auch nicht.

Teil 4: Vollständiger Header

Hinter dem dritten Teil wird nun auch noch der komplette Header mit ausgegeben. Das ist für eine detaillierte Fehersuche hoch hilfreich. Dies hier ist nur eine Teilmenge.

Ursache

Wer nun genau aufgepasst hat, sollte im Teil 3 gesehen haben, dass dort der tatsächliche Fehler zu sehen ist. Ein Server von Microsoft versuchte die Mail zum Mailserver von Net at Work zu senden und wurde abgelehnt, weil Net at Work eine "Loop" erkannt haben will:

Anhand der Header sieht man allerdings, dass Office 365 diese Fehlermeldung falsch interpretiert und für den Anwender daraus ein "User not Found" macht.

Und natürlich gibt es mich. Also wollte ich wissen, warum mail.netatwork.de die Mail ablehnt. Daher war ein Blick auf den Mailserver "mail.netatwork.de". Die Analyse-Funktion von NoSpamProxy braucht sich nicht hinter den "schönen Mails" von Office 365 zu verstecken. Auf der Suche nach der Mail anhand des Absenders bzw. Betreff habe ich aber schon etwas erstaunt geschaut, dass ich zwei Treffer hatte.

Die Details zeigen, dass der absendende Server unterschiedlich ist.

Ich frage mich natürlich, warum Office 365 die Mail von zwei unterschiedlichen Servern im Abstand von 5 Sekunden sendet. Absender, Empfänger, Betreff aber sogar die MessageID sind identisch. das linke Bild zeigt die erfolgreiche Zustellung der Mail innerhalb von 8 Sekunden. Erst eine Analyse auf dem TCP-Stack hat gezeigt, dass Office 365 die Mail zwar zugestellt, aber dann die Verbindung doch abgebaut hat. NoSpamProxy prüft schon während des Empfangs der Mail, ob diese Schadcode enthält, als Spam klassifiziert wird oder sonst wie besser nicht angenommen werden sollte. Diese Prüfung braucht eben ein paar Sekunden aber diese Zeit scheint Office 365 sich nicht zu nehmen und beendet die Verbindung. NoSpamProxy hat die Mail aber schon aber das "200 accepted for delivery" kann er nicht mehr absenden oder Office 365 interessiert das nicht mehr. Die erste Mail wurde daher lokal zugestellt.

Aber es dauert gerade mal 5 Sekunden, bis die Mail von einem anderen System noch mal auf die Reise geschickt wird. Das rechte Bild zeigt dies und diesmal ist NoSpamProxy nicht mehr happy. Aus seiner Sicht hat NoSpamProxy die Mail ja schon bekommt und verarbeitet und wird daher als "Loop" angesehen. Und da die Mail ja nicht am Ziel angekommen ist, muss das System entweder selbst eine Unzustellbarkeit erzeugen oder mit einem SMTP-Fehler die Mail ablehnen, so dass das einliefernde System den NDR generiert.

In dem Fall habe ich aber die Mail bekommen und NoSpamProxy hat die zweite Mail, die Office 365 unterbestimmten Umständen sendet zurecht als Dublette erkannt. Irgendwie haben beide Systeme ja Recht aber der Absender wird nur mit einem Fragezeichen auf der Stirn seinen Helpdesk ungläubig anschauen.

Ich habe aus NoSpamProxy beide Mails, die empfangene und auch die abgelehnte Mails extrahieren können und mal nebeneinander gestellt

Es ist gut zu sehen, dass die zweite Mail weiter unten und weiter oben einen Header addiert hat aber im Kern die gleiche Mail ist.

Eine weitere Analyse hat aber ergeben, dass der Fehler doch nicht ein besonderes verhalten bei Exchange Online ist, sondern eine übereifrige Loop-Erkennung. Die oben als Beispiel aufgeführte Mail wurde tatsächlich an mich zweimal versendet aber völlig zurecht. Der Absender hat mir die Mail einmal direkt und einmal über einen Verteiler in einem anderen Tenant gesendet so dass die gleiche Mail zweimal von Office 365 an mein Gateway gekommen ist. Leider hat der Versand über die Mailingliste weder den Absender noch die MeEssageID geändert, so dass es für das Zielsystem eine Dublette gewesen ist. Aber auch das wäre noch kein Problem, da NoSpamProxy Dubletten einfach schluckt. Problematisch war hier der kurze Zeitabstand, so dass NoSpamProxy die ausgehende Mail noch übermittelt hat, während die gleiche Mail auf der anderen Seite schon wieder einkommt. Das kann doch nur eine Fehlkonfiguration in Form eines IP-"Loopback" sein. Insofern hat Jeder seinen Teil dazu beigetragen, dass in der Kombination die Mail irrtümlich als Loop erkannt, und von Office 365 als "Empfänger ungültig" abgelehnt wurde.

Es wäre mal interessant zu wissen, ab wann solche "aufbereiteten NDRs" auch in Exchange On Premise Einzug halten.

Weitere Links