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.

Hinweis: Das Bild zeigt eine andere Mail, die aber mit dem gleichen Fehler abgelehnt wurde.

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.

Die Story wird sicher weitergehen. Wir analysieren weiter das Verhalten, wie und wann Office 365 eine Mail ein zweites mal versendet und wie die Loop-Erkennung vielleichtr technisch noch besser werden kann. Vielleicht sollten wir einfach einen Header addieren, auf den geprüft wird und zur Sicherheit die HopCounts als letzter Schutz zählen, auch wenn eine Loop dann viel später abgebrochen wird. Dennoch seltsam, dass Office 365 eine Verbindung nach so kurzer Zeit abbricht und wenige Sekunden später von einem anderen Server erneut versucht. Das erinnert mich an die Funktion Transport Cache

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

Weitere Links