External Sender Identification

Die Abwehr von Phishing ist eine kontinuierliche Herausforderung an Firmen. Anwender sind leider nicht immer erfahren genug, solche Attacken zu erkennen. Viele Firmen haben daher über Transportregeln schon eine Art "Disclaimer" an eingehende Mails addiert. Diese Funktion kommt nun auch direkt in Exchange und Outlook.

Beachten Sie dazu auch die Seite Cloud Notification Mails und Externe Mails kennzeichnen. Auch einige Mails von Systemdiensten ihres Tenants werden als "Extern" gekennzeichnet

Transport-Regel vs. Systemintegriert

Schon in der Vergangenheit habe ich bei verschiedenen Firmen mit Transportregel gearbeitet, um externe Mails zu kennzeichnen. Wir haben wahlweise im Betreff etwas angehängt aber meist wurde in die Mail an den Anfang dann ein "EXTERNAL" in der ein oder anderen Form addiert. Solche Änderungen im Body haben gleich mehrere unschöne Nachteile:

  • Digitale Signatur
    Wenn die eingehende Mail digital signiert ist und kein Signaturgateway davor die Signatur prüft aber dann entfernt oder neu signiert, dann verändert eine Transport-Regel den Body. Die Signatur wird ungültig und der Anwender sieht eine Fehlermeldung.
  • Reply-Kette
    Oft entwickelt sich aus einer Mail eine ganze Kette von Antworten (Thread). Die Anwender müssten dann die eingefügten Warnungen immer wieder entfernen, damit sie nicht im zitierten Abschnitt widerholt werden

Es ist daher schon sinnvoll, wenn ein Mailclient andere Informationen heranzieht, um den Status entsprechend anzuzeigen. Die Meldung kann sichtbar aber nicht störend angezeigt werden und stört nicht weiter die Verarbeitung.

Wenn ihr Tenant später schon "External"-Kennzeichnungen unterstützt, dann sollten Sie die Anwender informieren und dann die Transportregeln wieder deaktivieren.

Clients

Ich war natürlich neugierig, wie sich die Darstellung auf dem Client ändert. Dazu sollten Sie wissen, dass nicht alle Outlook-Versionen damit zurecht kommen. Microsoft schreibt dazu

Use the Set-ExternalInOutlook cmdlet to modify the configuration of external sender identification that's available in supported versions of Outlook.
Quelle: https://docs.microsoft.com/de-de/powershell/module/exchange/set-externalinoutlook

Leider listet Microsoft nicht weiter, welche Versionen von Outlook hier "kompatibel" sind. Allerdings gibt es schon erste "Bilder", die eine entsprechende Anzeige in Outlook Web App, Outlook for IOS und Outlook for Android zeigen. In Outlook WebApp ist die Funktion schon mal vorhanden, dass hier die Nachricht als "Extern" gekennzeichnet wird. in meinem Outlook 365 Version 2103 Build 13901.20148 Click to Run ist die Information noch nicht zu sehen.

Client Aussehen

Outlook on the Web

Outlook 365 Windows

Outlook 365 Version 2103 Build 13901.20148 zeigt noch keine entsprechende Information

Outlook for IOS

Bei Outlook IOS ist mittlerweile auch das "Extern" vor der Mailadresse zu sehen.

Outlook for Android

Bild fehlt noch

Ich bin mal gespannt, wann vielleicht auch andere Programme diese Informationen in der Mail auswerten können oder sogar ein Standard draus werten könnte.

Einstellung per EXO PowerShell

Aktuell ist diese Funktion standardmäßig ausgeschaltet.

PS C:\> Get-ExternalInOutlook | fl enabled,AllowList

Enabled    : False
AllowList  : {}

Der einfachste Weg ist eine generelle Aktivierung:

Achtung: Wenn Sie heute schon mit Transportregeln zur Kennzeichnung externer Mails arbeiten, dann sollten Sie die Umsetzung abstimmen um Doppelkennzeichnungen zu verhindern.

Set-ExternalInOutlook `
   -Enabled $true

Nun gibt es natürlich Domains, die aus Sicht des Exchange Online Tenants zwar extern sind aber dennoch "vertrauenswürdig" sind. Diese Domains oder sogar einzelne Mailadressen können Sie per "Allowlisting" addieren. Allerdings ist das Feld auf maximal 30 Einträge und 1 kByte beschränkt.

In meinem Test-Tenant funktionierten nicht alle Parameter, wie ich mir das gewünscht hätte. Die Tests wurden mit folgender Konfiguration durchgeführt:

PS C:\ > Get-OrganizationConfig | fl *version
 
ObjectVersion               : 16500
PreviousAdminDisplayVersion : 0.10 (14.0.100.0)
RBACConfigurationVersion    : 0.1 (15.20.3933.31)
AdminDisplayVersion         : 0.20 (15.20.3933.31)
ForestConfigVersion         :
ExchangeVersion             : 0.1 (8.0.535.0)

Bei einem Tenant mit einem älteren Stand gab es die Probleme nicht. Kontrollieren Sie im Moment also immer ihre Einstellungen.

Aufruf, Ergebnis Status Ergebnis

Ausgangssituation (Default)

PS C:\ > Get-ExternalInOutlook | fl enabled,allowlist
Enabled    : False
AllowList  : {}

Das waren die Ausgangswerte in meinem Tenant

Aktivieren mit einer Domain

PS C:\ > set-ExternalInOutlook -Enabled $true -AllowList 'nospamproxy.de'
PS C:\ > Get-ExternalInOutlook | fl enabled,allowlist
Enabled    : True
AllowList  : {}

Das Flag "enabled" wird aktiviert aber die AllowList ist leer geblieben.

Konfiguration mit ADD

PS C:\> Set-ExternalInOutlook -Enabled $true -AllowList @{add="netatwork.de"}
PS C:\> Get-ExternalInOutlook | fl enabled,allowlist
Enabled   : True
AllowList : {netatwork.de }

Wenn ich die Domains mit "ADD" eintrage, dann funktioniert es

Addieren einer weiteren Domain

PS C:\> Set-ExternalInOutlook -Enabled $true -AllowList @{add="nospamproxy.de"}
PS C:\> Get-ExternalInOutlook | fl enabled,allowlist
Enabled   : TrueAllowList : {netatwork.de, nospamproxy.de}

Das hat auch problemlos funktioniert

Domain setzen

PS C:\> Set-ExternalInOutlook -Enabled $true -AllowList "msxfaq.de","msxfaq.org"
PS C:\> Get-ExternalInOutlook | fl enabled,allowlist
Enabled   : True
AllowList : {netatwork.de, nospamproxy.de, msxfaq.de, msxfaq.org}

Überraschung: meine Domains wurden addiert und haben die bestehende Liste nicht überschrieben.

Setzen mit einer Domain ohne Anführungsstriche

PS C:\> Set-ExternalInOutlook -Enabled $true -AllowList carius.de
PS C:\> Get-ExternalInOutlook | fl enabled,allowlist
Enabled   : True
AllowList : {netatwork.de, nospamproxy.de, msxfaq.de, msxfaq.org}

Auch hier hätte ich erwartet dass die Liste überschrieben wird

Einzeldomain löschen

PS C:\> Set-ExternalInOutlook -Enabled $true -AllowList @{remove="msxfaq.de"}
PS C:\> Get-ExternalInOutlook | fl enabled,allowlist

Enabled   : True
AllowList : {netatwork.de, nospamproxy.de, msxfaq.org}

Das hat dann aber wieder funktioniert.

Domainliste leeren

Set-ExternalInOutlook -Enabled $true -AllowList $null
Set-ExternalInOutlook -Enabled $true -AllowList “”

Beide Versuche haben die Liste nicht geleert

Ich gehe aber davon aus, dass Microsoft dies bald gelöst hat. Sie können also schon die Werte richtig setzen, wenn Sie denn die richtige Parameter nutzen.

Die Änderungen können angeblich 24-48 Stunden dauern. Ich vermute, dass die Änderungen im Tenant durch eine Replikation auf die "Ege-Server" weltweit übertragen werden, anhand der die Klassifizierung erfolgt.

Header

Wenn Outlook diese "Externe Mail" entsprechen kennzeichnet, dann sollte irgendwo im Header auch etwas zu finden sein. Ich habe in der ersten Mail nur folgende Header identifiziert, die etwas damit zu tun haben könnten. Das ist leider keine qualifizierte Aussage.

X-MS-Exchange-Organization-MessageDirectionality: Incoming
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEnX-MS-Exchange-CrossTenant-FromEntityHeader: Internet

Zumal diese "Exchange Header" durch die Header Firewall geschützt sind, d.h. ich kann sie von außen eingehend gar nicht setzen.

Insofern können Sie nur Exchange Online die Kennzeichnung überlassen.

Ich gehe aber schon davon aus, dass die Funktion durch den Transport umgesetzt wird. Denkbar wäre zwar auch die Ablage der Konfiguration für den Client, aber dann müsste Microsoft bei jeder Mail vom Client die Information über "interne Domains" und die "AllowList" übermitteln.

Sonderfälle

Natürlich gibt es neben dem "ein Absender - ein Empfänger" noch weitere Kombinationen.

Fall Ergebnis

Thread beginnt mit einer intern gesendeten Mail an an interne und externe Empfänger und ein externer Empfänger antwortet

Der komplette Thread wird als "Extern" angezeigt

Externe Mail über Exchange Online Protection und Exchange Hybrid an On-Premises Postfach

Noch zu prüfen

Mail von On-Premises über Hybrid Connector zum Online User, wobei die From-Domain nicht in der AllowList steht

Noch zu prüfen

Mail von einer externen Domain aus der AllowList, die nicht per SPF/DKIM geprüft werden kann

Noch zu prüfen

Nachträgliche Änderung der AllowList. Ändert sich dann die Klassifizierung?

Noch zu prüfen

Die Checks musste ich wegen Hafnium noch etwas zurückstellen. Zudem sind noch nicht alle meine Test-Tenants umgestellt.

Einschätzung

Auch wenn es nach einer Kleinigkeit aussieht, finde ich den Ansatz von Microsoft sehr gut, externe und damit nicht verifizierte Mails zu kennzeichnen. Als Administrator sollten Sie aber darauf achten, dass nur solche Domains auf die AllowList kommen, die auch korrekt per SPF, DKMIM und DMARC eine Verifizierung des Absenders zulassen und nicht zugelassende Quellen per "REJECT-Policy" auch unterbinden. Alternativ können Sie in Exchange auch einen "Partner Connector" zu diesen Domänen einrichten, die z.B. TLS erzwingen.

Vergessen Sie aber nicht, ihre Anwender über diese neue Funktion zu Informieren. Nur dann funktioniert der Schutz, wenn die Anwender das "Extern" zu deuten wissen und entsprechend sensibel damit umgehen.

Weitere Links