Read-Forwardingrules

Benutzer können in ihrem Postfach über Regeln Mails automatisch weiterleiten. Dieses Skript liest diese Regeln aus einer Liste von Postfächern aus, um gezielt nach Weiterleitungen und Umleitungen zu suchen und diese zu berichten.

Warum brauch ich das?

Die Standard-Konfiguration von Exchange ist derart, dass Weiterleitungen oder Umleitungen an interne Empfänger erlaubt sind aber Weiterleitungen und Umleitungen an externe Domänen geblockt werden. Ein Administrator kann solche externen Weiterleitungen natürlich pro Ziel-Domäne oder Global zulassen. Davon rate ich aber ab. Häufig kommt man aber in Umgebungen, wo genau so eine aufgeweichte Konfiguration vorliegt. Dann stellt sich schon die Frage, wer diese Konfiguration denn nutzt. Aus Datenschutzüberlegungen sollten automatische Weiterleitungen an andere externe Adressen nicht erlaubt sein und selbst Weiterleitungen an interne alternative Empfänger eher die Ausnahme sein.

  • Weiterleitungen
    Die Mail von A an B wird durch eine Weiterleitung umgeschrieben mit B als Absender und C als Empfänger. Die Mail wird also verändert und eine SMIME/PGP-Signatur wird z.B. ungültig
  • Umleitung
    Die Mail von A an B wird an C gesendet, wobei der Absender A unverändert übernommen wird. Problematisch ist hier, wenn A eine externe Adresse ist und die Server von B eben nicht mit dieser Domain senden dürfen. Siehe auch Spam und UCE - Filter: SPF, SenderID

Ob eine automatische Weiterleitung nach Extern überhaupt erlaubt ist, legen Sie bei den "Remote Domains" in Exchange fest, die Sie wie folgt auslesen können

[PS] C:\>get-remotedomain | ft domainname,autoforwardenabled -AutoSize

DomainName                    AutoForwardEnabled
----------                    ------------------
*.fax                                       True
*                                          False
netatwork.de                                True
nospamproxy.de                             False

Dieses Beispiel zeigt, dass der Default "*" keine automatische Weiterleitung erlaubt aber sowohl zum Faxserver als auch zu netatwork.de die Anwender meiner Demo-Umgebung durchaus eine Weiterleitung einrichten könnten. Wenn ich das wieder abschalten wollte, dann sollte ich schon wissen, wer eine Weiterleitung eingetragen hat

Nicht berücksichtig werden hier administrativ gesetzte Weiterleitungen und Umleitungen über das Feld TargetAddress oder über "MailContacts" und "MailUser", d.h. AD-Objekte, die aus Sicht von Exchange nur ein bekanntes Ziel in einer anderen Umgebung, z.B. einem befreundeten Mailsystem, repräsentieren.

Der Scope dieses Script liegt ganz klar auf den durch Anwender selbst konfigurierbaren Regeln im eigenen Postfach.

Funktionsweise

Das Skript nutzt im wesentlichen das Commandlet "Get-Inboxrule", welches seit Exchange 2010 in der Exchange PowerShell verfügbar ist. Es erwartet eine Übergabe der Postfächer als Mailboxliste durch die Pipeline, die es dann sequentiell abarbeitet. Die gefundenen Regeln werden darauf überprüft, ob Sie Aktionen in den Feldern "RedirectTo" und "ForwardTo" haben. Diese Regeln werden dann genauer analysiert um die Empfänger zu ermitteln.

Die Ausgabe erfolgt als Objekt mit folgenden Feldern. Dabei wird für jeden Empfänger einer Regel ein eigenes Object erstellt:

  • PrimarySmtpAddress
    Die primäre SMTP-Adresse des Postfachs, in dem diese Regel enthalten ist
  • Rulename
    Der "Name" der Regel, wie sie der Anwender sieht
  • Typ
    Diese Spalte kann den Wert "redirectto" oder "forwardto" einnehmen und spezifiziert, ob der Empfänger die Mail als Weiterleitung oder Umleitung erhält
  • Routingtype
    Hier steht in der Regel SMTP oder EX drin. Der Eintrag EX ist ein Hinweis, dass der Empfänger intern im lokalen Active Directory gepflegt ist Die Destination ist dann meist der LegacyExchangeDN. Ein SMTP ist in der Regel der Hinweis auf einen externen Empfänger, der manuell eingegeben wurde. Es kann aber auch ein interne Empfänger sein. SMTp ist also keine Garantie für einen externen Empfänger und EX kann durchaus auf einen Mail-Contact verweisen.
  • Destination
    Hier steht dann die Zieladresse des finalen Empfängers. Bei internen Empfänger, die im lokalen Active Directory als Exchange-Objekt vorliegen taucht hier wieder der LegacyExchangeDN auf, der schon lange obsolet sein sollte. Externe Empfänger dürften mit der SMTP-Adresse erscheinen.

In der PowerShell ist es natürlich ein Leichtes diese Information mit "| export-csv <dateiname>" in eine Datei umzuleiten oder durch andere Skripte weiter zu verarbeiten.

Das Skript

Nun fehlt ihnen nur noch das Skript, um in ihrer Umgebung eine entsprechende Auswertung zu fahren.

Für die Auswertung der Regeln sind entsprechende Berechtigungen in Exchange erforderlich. Ich weise aber deutlich darauf hin, dass die Information über Regeln und Weiterleitungen aus meiner Sicht ein Eingriff sind, über dessen datenschutzrechtlichen Auswirkungen Sie sich klar sein müssen. Selbst wenn Sie solche Auswertungen erstellen können, bedeutet dies nicht, dass Sie das auch dürfen. Auch was danach mit den Daten passiert, ist ggfls. abzustimmen

Daher kann es sinnvoll sein, die volle Auswertung des Skript zu verändern. Wer nur wissen will, an welche Zieldomänen überhaupt Weiterleitungen geschaltet sind, der muss weder den Namen der Regel noch das Postfach oder die vollständige Zieladresse kennen. Hier würde es reichen die Domänen zu erfassen.

Hier das Skript
get-forwardingrules.20181011.ps1.txt
Nach dem Download sollten Sie die Erweiterung TXT entfernen und in den Eigenschaften das Skript "freigeben" (Entfernen der Kennzeichnung Internet-Zone)

Die Performance hängt natürlich stark von ihrer Workstation und den Servern ab. Schließlich muss das Skript zuerst alle Postfächer einsammeln und dann sich mit jedem Postfach verbinden und die Regeln abrufen. Ich habe nun nicht per Fiddler genau nachgeschaut aber ich tippe drauf, dass das Backend per EWS sich mit dem Postfach verbindet. Also 1-2 Postfächer pro Sekunden scheinen ein passabler wert zu sein, so dass Sie ca. 3000-6000 Postfächer pro Stunde auswerten können. Diese Performance ist zwar nicht sehr schnell aber das Skript wird ja eher selten manuell gestartet. Daher habe ich keine parallele Verarbeitung eingebaut.

Aufruf

Das Skript erwartet die Postfächer über die Pipeline. Der Aufruf für alle Postfächer ihrer Organisation lautet daher

Get-Mailbox `
   -IgnoreDefaultScope `
   -resultsize unlimited `
| .\read-forwardingrules `
| export-csv `
   -path .\forwardingrules.csv `
   -notypeinformation `
   -encoding unicode

Die Ausführung sollte durch einen Exchange Administrator in einer Exchange PowerShell unter Überwachung erfolgen. Ich habe das Skript nicht um Funktionen erweitert, um Eventlogs und Performancecounter zu schreiben, Fehler besonders abzufangen oder einen automatisierten Betrieb zu erlauben. Es ist nicht digital signiert, d.h. schauen Sie auf jeden Fall erst einmal hinein, dass es nicht verändert wurde.

Dafür bekommt der Administrator dann auch etwas Farbe zu sehen. Für jede übergebene Mailbox wird die Anzahl der Regeln ausgegeben und für jede Regel ein Punkt. Wenn es in der Regel entsprechende Einträge für Weiterleitungen oder Umleitungen gibt, dann sehen Sie ein "R = Redirect" oder "F = Forward".

In der CSV-Datei finden sich dann Daten in der folgenden Form:

"PrimarySmtpAddress","Rulename","typ","Routingtype","destination"
"user1@msxfaq.net","test4ward2","redirectto","SMTP","user1@netatwork.de"
"user1@msxfaq.net","test4ward2","redirectto","SMTP","user2@netatwork.de"
"user1@msxfaq.net","test4ward2","redirectto","EX","/o=MSXFAQ/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=user2"
"user1@msxfaq.net","test4ward1","forwardto","SMTP","frak@carius.de"
"user2@msxfaq.net","Regel1","forwardto","SMTP","extern@msxfaq.de"
"user3@msxfaq.net","Meine Regel","forwardto","EX","/o=MSXFAQ/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=user4"

Das ist natürlich nur ein Beispiel. Einer Auswertung per Excel oder auch Power Bi steht damit nichts mehr im Wege. Interessant sind besonders Weiterleitungen nach extern, die durch eine Veränderung der Policies bei den Remote-Domains gestört werden könnten.

Ergebnisse einsetzen

Diese Auswertung haben Sie ja nicht einfach mal so gemacht. Wenn Sie zuerst einmal alle Zeilen nutzen, die eine SMTP-Adresse als Ziel haben und dort dann die Domains entfernen, die sie selbst heute schon nutzen, dann können Sie sehr schnell die hoffentlich wenigen Zeilen extrahieren, die Weiterleitungen nach extern darstellen. Diese Mitarbeiter oder Funktionspostfächer müssen Sie entsprechend umstellen oder darauf hinweisen, wenn Sie die automatische Weiterleitung nach extern auf den Domains oder global wieder abschalten wollen.

Ich habe bei anderen Einsätzen aber auch gesehen, dass eine Auswertung nach "Anzahl der Weiterleitungsregeln pro Postfach" durchaus Potential für Optimierungen aufzeigen kann. Jede Weiterleitung ist ja zumindest eine Verdopplung, wenn nicht gleich eine Vervielfachung der Mail, die auch wieder zu speichern, zu übertragen und zu lesen sind. Arbeitszeit ist hier eher der Kostenfaktor. Es gibt aber mit SharePoint, Shared-Mailboxen, Teams, Flows, CRM etc. ganz andere leistungsstarke Möglichkeiten, die eine Mailverarbeitung erlauben.

Das bleibt aber ihnen selbst überlassen.

Weitere Links