NDR Tracking

Diese Seite beschreibt Ansätze, um von Exchange erstelle Unzustellbarkeitsberichte (NDR) zur Verbesserung der Zustellung auszuwerten. Die Seite ist eine Folge von DBEB mit Hybrid.

Einleitung

Wenn A eine Mail per SMTP an B sendet, dann kann es passieren, dass dabei etwas schief läuft und die Mail nicht ankommt. Es gibt mehrere Gründe und einige davon sind:

  • Zieladresse nicht mehr vorhanden
    Mitarbeiter verlassen das Unternehmen oder den Dienst und das Postfach wird gelöscht.
  • Der Absender vertippt sich einfach
    Nicht immer wird eine Mailadresse korrekt abgeschrieben, in einem Formular eingegeben oder per Telefon übermittelt.
  • Postfach voll/nicht berechtigt
    Auch dies kann die Zustellung an einen Empfänger unterbinden. So sind Exchange Verteiler normalerweise nur für "authentifizierte Benutzer" erreichbar.
  • Ausfall eines Servers
    Auch bei der Übertragung liegt eine Mail nach dem Empfang und vor der Weiterleitung temporär auf einem Server, der genau dann ausfallen kann. Hier gibt es dann keinerlei Hinweis. Exchange schützt sich vor diesem Risiko mittels E2010 Transport Cache
  • Ablehnung bei Spamverdacht/Compliance
    Gute Spamfilter wie NoSpamProxy und andere Produkte analysieren die Mail schon beim Empfang und ehe am Ende der Übertragung das Zielsystem kein "2xx OK" meldet, hat der Absender weiter die Verantwortung. Hier kann auch ein 4xx-Fehler kommen, so dass der aktuelle Host einen NDR erzeugt.

Unzustellbarkeiten gehören daher einfach zum Mailverkehr dazu aber sie sollten gering sein. Hier müssen Sie noch zwischen dem internen Verkehr und externer Kommunikation unterscheiden. Wenn Benutzer in einer Firma untereinander kommunizieren und dazu das Adressbuch nutzen, dann sind Fehladressierungen sehr gut zu vermeiden. Unzustellbarkeiten passieren dann nur bei einer Antwort auf eine alte Mail, deren Absender das Unternehmen verlassen hat oder manuelle Adresseingaben. Es gibt aber auch externe Absender aus dem Internet aber auch von eigenen Systemen, die per SMTP Mails an hinterlegte Mailadressen einliefern und nicht deren Gültigkeit vorab prüfen können.

Umgang mit Exit-Prozessen

Hier stellen sich dann essentielle Fragen, wenn eine Mailadresse in einer Firma wegfallen soll:

  • Mailadresse löschen und ablehnen oder NDR
    Hier stehen Sie dann vor der Wahl, ob sie diese Mails an ungültige Empfänger direkt ablehnen, so dass das einliefernde System darauf reagieren muss oder sie nehmen die Mail an und generieren dann selbst eine Unzustellbarkeit. Im ersten Fall verlagern Sie die Reaktion auf den Absender, der hoffentlich seine NDR-Rückläufer auch verarbeitet. Das ist bei Menschen der Regelfall aber bei vielen anderen Diensten eher nicht. Wenn Sie die Mail annehmen, dann können Sie zumindest in ihrem System den NDR analysieren. Darum geht es in der Folge auf dieser Seite
  • Empfänger mit OOF/AutoAnswer versehen
    Sie müssen eine inaktive Mailadresse nicht sofort löschen. Vielleicht möchten Sie für einige Tage oder Wochen sie weiter erreichbar halten und den Absender freundlich über das Ende dieser Adresse informieren. Das funktioniert mit OOF-Meldungen sehr gut, wenn der Absender diese auch liest und darauf reagiert. Es hilft nicht, wenn der Absender eine Maschine ist oder ein Mensch die OOF-Meldung ohne weitere zu lesen direkt löscht. Datenschutzrechtlich liest natürlich niemand die Mail aber Sie kommen auch erst einmal nicht an den Inhalt heran oder sie bezahlen weiter Lizenzen um das Postfach zu erhalten
  • Mailadresse umleiten, CatchAll
    Sie können die Adresse einem anderen Postfach zuschlagen oder eine Weiterleitung einrichten, welches sich dauerhaft oder für eine gewisse Zeit darum kümmert, dass ein Nachfolger die Mails bekommt und die notwendigen Änderungen veranlasst. Problemtisch ist dies für die verbotenen "privaten Mails", die aber immer noch ankommen könnten. Datenschutz ist ein Thema hier, denn viele Anwender trennen nicht konsequent zwischen Privat und Geschäftlich und nutzen ihr Geschäftskonto.

Es ist letztlich egal, für welchen Weg sie sich entscheiden, denn alle haben ihr Vorteile und Einschränkungen. Sie können die Varianten auch kombinieren, z.B. indem Sie eine Mail für einige Zeit an den Nachfolger umleiten, damit dieser die Absender informiert oder eine automatische Regel dies tut bis sie in einer zweiten Stufe dann die Mail löschen.

Solange die Mails noch empfangen und zugestellt werden, sollten Sie vielleicht dennoch eine Liste der Mailadressen führen, die in naher Zukunft entfallen und beim Tracking diese nachverfolgen.

Letztlich haben Sie die Wahl zwischen Pech und Cholera. Wenn Sie ungültige Empfänger direkt ablehnen, haben Sie weniger NDRs aber sehen auch nicht mehr, was verloren gegangen ist. Wenn Sie aber auch Mails an unbekannte Empfänger annehmen, dann

NDR Varianten

Es gibt aber noch einige weitere Fälle, in denen ein NDR erzeugt und von ihnen als Betreiber analysiert werden kann, sollte oder sogar muss. Schließlich kann eine wichtige Mail ansonsten unbemerkt unterschlagen werden.

Szenario Beschreibung

extern eingehend abgelehnt

Ein externer Absender versucht einen Empfänger in ihrer Domain zu erreichen, den es aber nicht mehr gibt. Wenn der Spamfilter die Empfänger prüft, dann wird der die Mail schon auf dem SMTP-Level mit einem 500er-Fehler ablehnen. Der Versuch der Mail erscheint also nicht in dem normalen Messagetrackinglog ihres Spamfilters und erst recht nicht auf dem internen Mailserver. Natürlich sollte der Mailserver das Absenders einen NDR an seinen Absender generieren. Dazu muss dieser die Mail aber auch lesen. Häufige Fehler, die ich hier schon gesehen habe:

  • Ein Webformular auf einer Webseite sendet Mails an einen Mitarbeiter, der nicht mehr da ist. Die Rücksendeadresse funktioniert nicht.
  • In ehemaliger Mitarbeiter ist als Kontakt bei einem Lieferantensystem eingetragen um Bestätigungen zu bekommen
  • Automatische Prozesse/Skripte senden Mails an Adressen, die es nicht mehr gibt.

Sie können solche Probleme einfach verhindern, wenn als Empfänger nur generische Adressen (Info/Vertrieb/support etc) genutzt werden, die dann eine SharedMailbox oder ein Verteiler sind. Aber bitte nie persönlichen Adressen eintragen, wenn eigentlich eine Funktion gewünscht wird. Aber es passiert und wenn Sie solche Events nicht auswerten, dann verlieren sie wichtige Mails. Da hilft es auch nicht viel, wenn der Absender die Zustellung nicht beweisen kann.

intern ausgehend abgelehnt

Ein interner Absender versucht einen Nachricht an einen externen Empfänger zu senden und die wird schon vom Spamfilter abgelehnt. Sie finden den Eintrag im Messagetracking des Mailservers aber wenn der Spamfilter diese Mails nicht protokolliert, dann ist eine Fehlersuche knifflig. Häufige Fälle:

  • Ungültige Empfängeradresse, z.B. falsche Formatierung der Empfänger (UTF-8-Umlaute o.ä.)
  • Direktversand von Drucker, Skript o.ä.
    Wenn Sie nachträglich z.B. Relay-Beschränkungen einbauen, dann könne es sein, dass eine früher mögliche Funktion nun nicht mehr funktioniert.
  • Beim Versand über einen ausgehenden Filter kann die Mail als Spam erkannt und geblockt werden.

Solange der Absender ein Postfach ist, der seine Rückmeldungen auch liest und darauf reagiert, ist das Risiko gering. Was passiert aber mit einem Skript, Prozess o.ä. der gar keine gültige Absenderadresse nutzt.

NDR von intern nach extern

Nicht immer lehnt der Spamfilter ab. Manchmal kommt die Mail fast bis zum Ziel, ehe Sie von dort als Unzustellbar quittiert wird. Der interne Server sendet dann einen NDR mit der Absenderadresse "<>" an den Absender zurück, der dann darauf reagieren kann, wenn er es denn tut. Was ich hier schon gesehen habe.

  • Eine Buchungsplattform im Internet sendet Mails an eine ausgeschiedene Mitarbeiterin
  • AzureAD sendet Rechnungen an eine alternative Adresse, die es nicht mehr gibt
  • DevOps sendet Nachrichten nicht nicht mehr gültige Personen
  • Abrechnungsplattform sendet Mails an Mitarbeiter der Buchhaltung statt an einen Alias
  • Eine USV meldet per Mail eine Störung an eine nicht mehr gültige Mailadresse aber nutzt eine externe Adresse als Absender, wodurch ein NDR von ihrem System an die externe Adresse geht. (NDR-Backscatter)

Das sind nur ein paar reale Beispiele, bei denen eine Protokollierung und Verarbeitung von NDRs wichtig ist, weil die Gegenseite natürlich die "Einlieferung" nachweisen kann.

NDR von extern nach intern

Zuletzt gibt es noch Mails, die ihre Mitarbeiter erfolgreich über den Spamfilter bis ins Ziel zugestellt haben aber an der letzten Station durch einen NDR als fehlerhaft gemeldet werden. Wenn ihre Absender aber ein automatischer Prozess ist, der die Rückmeldungen nicht verarbeitet, dann korrigiert niemand den falschen Eintrag und eine vermutlich erwünschte Kommunikation kommt nicht zustande.

Es gibt also durchaus berechtigte Gründe, hier nicht auf die Intelligenz und Zuverlässigkeit von Administratoren und Benutzern zu vertrauen, sondern auch NDRs zu analysieren.

Das finale Ziel sollte eine "0-Fehler-Strategie" sein, die sie aber wohl nie erreichen werden. Aber Fehler kann man beheben, damit sie sich nicht wiederholen.

Wie können wir das aber nun auswerten?

On Premises: NDRs auswerten

Wenn Sie aber die Mail direkt löschen UND den Empfang an ungültige Adressen nicht unterbinden, dann erstellen Mailsystem entsprechende Unzustellbarkeiten. Diese können Sie sehr einfach und schnell einsammeln, da Exchange On Premises dazu extra eine EventID "DSN" (Delivery Status Notification) hat, unter der alle Arten von Quittungen protokolliert werden. Hier bietet es sich dann an, diese Meldungen einzusammeln. Eine einzelne Zeile sieht dann z.B. so aus:

Get-MessageTrackingLog -resultsize 1 -Eventid DSN `
| fl recipients,MessageSubject,MessageInfo

Recipients      : {info@ups.msxfaq.local}
MessageSubject  : Undeliverable: UPS: The power is off.
MessageInfo     : '<invalid@msxfaq.de>:<550 5.1.10 RESOLVER.ADR.RecipientNotFound; 
                   Recipient not found by SMTP address lookup>'

In "Recipients" steht der originale Absender drin und in "MessageSubject" der Betreff. Wichtig ist die "MessageInfo", da hier die nicht mehr erreichbare Zieladresse und der Fehlercode samt Textbeschreibung enthalten ist. Von hier sind es nur noch ein paar Minuten zu einem PowerShell-Script, welches nun alle DSN-Meldungen einsammeln und die 5xx-Fehler extrahiert.

get-ndrdata.ps1

Das Skript erlaubt eine Filterung des Zeitraums und baut dann ein Powershell Objekt zur Ausgabe zusammen, indem der Absender und Empfänger der Mail extrahiert und dann ausgegeben wird.

Das ist dann einfach weiter zu verarbeiten, z.B. als Webseite oder als tägliche Info-Mail an ein Ticketsystem. Wer mag, kann dann die Absender informieren oder irrtümlich gelöschte Adressen wieder zuweisen oder die Konfiguration von internen Absendern und Prozessen korrigieren.

On Premises: Perfmon

Wenn Sie nur an den Kennzahlen interessiert sind, dann können Sie auch die Windows Performance Counter heranziehen:

Dies ist nur ein Auszug. Es gibt die DSN-Counter auch bei Submission und Transport.

\MSExchange Delivery DSN(*)\Alertable failure DSNs within the last hour
\MSExchange Delivery DSN(*)\Delay DSNs
\MSExchange Delivery DSN(*)\Delayed DSNs within the last hour
\MSExchange Delivery DSN(*)\Delivered DSNs
\MSExchange Delivery DSN(*)\Expanded DSNs
\MSExchange Delivery DSN(*)\Failure DSNs Total
\MSExchange Delivery DSN(*)\Failure DSNs within the last hour
\MSExchange Delivery DSN(*)\NDRs generated for catch-all recipients.
\MSExchange Delivery DSN(*)\Relay DSNs
\MSExchange Submission DSN(*)\Alertable failure DSNs within the last hour
\MSExchange Submission DSN(*)\Delay DSNs
\MSExchange Submission DSN(*)\Delayed DSNs within the last hour
\MSExchange Submission DSN(*)\Delivered DSNs
\MSExchange Submission DSN(*)\Expanded DSNs
\MSExchange Submission DSN(*)\Failure DSNs Total
\MSExchange Submission DSN(*)\Failure DSNs within the last hour
\MSExchange Submission DSN(*)\NDRs generated for catch-all recipients.
\MSExchange Submission DSN(*)\Relay DSNs
\MSExchangeTransport DSN(*)\Alertable failure DSNs within the last hour
\MSExchangeTransport DSN(*)\Delay DSNs
\MSExchangeTransport DSN(*)\Delayed DSNs within the last hour
\MSExchangeTransport DSN(*)\Delivered DSNs
\MSExchangeTransport DSN(*)\Expanded DSNs
\MSExchangeTransport DSN(*)\Failure DSNs Total
\MSExchangeTransport DSN(*)\Failure DSNs within the last hour
\MSExchangeTransport DSN(*)\NDRs generated for catch-all recipients.
\MSExchangeTransport DSN(*)\Relay DSNs

Sie sehen hier absolute Werte und die Summer über die letzte Stunde aber kein Details über den Absender und Empfänger.

Exchange Online: NDR-Report

In Exchange Online können Sie zwar auch ein Nachrichtentracking per PowerShell ausführen aber eleganter ist hier das Webportal, wo Microsoft schon vorgefertigte Übersichten und Listen anbietet.


https://admin.exchange.microsoft.com/#/

Die Reports auf https://admin.exchange.microsoft.com/#/reports/nondeliverydetails  liefern weitere Details zu den einzelnen Mail.

Über die Details zu einem Fehler können Sie die Nachrichten samt Details anzeigen.

Sie sehen hier aber nur NDRs, die auch Exchange erstellt hat. Wenn Mails an ungültige Empfänger an der Außengrenze direkt abgelehnt werden, dann erstellt der andere Server

Weitere Links