TreatMessagesAsInternal
Auf dieser Seite möchte ich auf eine Einstellung des Exchange Online Inbound OnPremises Connector eingehen, die nicht im Exchange Admin Center sondern nur der Exchange Online PowerShell sichtbar und änderbar ist.
Beachte dazu auch die Seite X-MS-Exchange-Organization-AuthAs und X-MS-Exchange-CrossTenant-Id
Vertrauen
Im Grunde ist erst einmal bei Exchange Online eingelieferte Mail eine "nicht vertrauenswürdige" Mail. Eine Ausnahme sind natürlich die Mails, die von authentifizierten Benutzern per Outlook (MAPI/HTTP), OWA, Graph, EWS, IMAP, SMTP mit Auth etc. Exchange klassifiziert jede Mails nach einem klaren Schema:
- "Originating"
Die Mail kommt von einem eigenen verifizierten Absender. Das ist in der Regel ein OnPremises Postfach oder ein Exchange Online Postfach. Für den Exchange Online Transport ist der Absender auf jeden Fall in der eigenen Domain UND authentifiziert, so dass Exchange den als "internal" bei Transportregeln OOF-Meldungen, Namensauflösung etc. akzeptiert und auch den Versand in Internet an externe Empfänger erlaubt. - "Incoming"
Alle anderen Mails gelten als "Eingehend" von nicht vertrauenswürdigen Absendern. Das ist meist eine Verbindung aus dem Internet aber eben auch interne Scanner, Skripte, Webseiten.
Eine Nachrichten kann über mehrere Wege als "Originating" eingestuft werden:
- Angemeldeter Benutzer
Der einfachste Fall ist ein Benutzerkonto mit Postfach, welches eine Mail einliefert. Exchange erzwingt dann als Absender eine Mailadresse, die der Benutzer hat oder als Stellvertreter/SendAs nutzen darf. - OnPremises: Receive Connector mit "Externally Secured"
- Exchange Online: OnPremises Inbound
Connector
Wobei hier die Einstellungen zu "CloudServicesMailEnabled" oder eben mit "TreatMessagesAsInternal" betrachtet werden.
Die Information wird in der SMTP-Nachricht als Header mitgegeben. Damit diese Information niemand fälschen kann, gibt es eine "Header Firewall", die diese "X-MSExchange-*"-Felder nur übernimmt, wenn die Übertragung zwischen Exchange Server der gleichen Umgebung oder zwischen einer Hybrid-Bereitstellung erfolgt.
Ist das wichtig?
Wenn Sie nun vorschnell meinen, dass es doch nicht wichtig ist, solange die Mail im Postfach ankommt, dann möchte ich sie auf folgende Dinge hinweisen, die ohne eine Klassifizierung interner Absender als "Originating" nicht funktionieren.
- Anzeige des Absenders
Ob eine Mail als "Anonym" oder "Authentifiziert" ankommt, können Sie sehr einfach in Outlook oder OWA erkennen. Betrachten Sie einfach einmal genau die Absenderadresse an. Wenn hinter dem Displaynamen eine SMTP-Adresse steht, dann war die Mail anonym. Wenn die Mail authentifiziert eingeliefert wurde, dann ersetzt Exchange den Displaynamen anhand des Empfängerobjekts im Verzeichnisdienst:
Daher sollten Sie beim Exchange Hybrid Mode mit ADSync auch immer darauf achten, dass alle Empfänger sichtbar sind, da ansonsten Exchange sonst auch die Mail auf anonym zurückstuft und möglicherweise sogar als Spam/Phishing in den Junk-EMail-Ordner einsortiert. - Transportregeln
Als Exchange Administrator können Sie auf dem Server mit Transportregeln nach "External/Internal" beim Absender bzw. Empfänger unterscheiden. Das funktioniert nur, wenn die Mail auch korrekt klassifiziert wurde.
- OOF
Anwender können ebenfalls über die Automatischen Antworten bei einer Abwesenheit unterschiedliche Rückmeldungen geben. So können interne Absender eine detailliertere und Internet-Absender eine allgemein gehaltene Meldung erhalten.
- Internet-Versand und Routing
Zuletzt hat die Klassifizierung auch einen Einfluss auf das Mailrouting. Wenn Sie einen SendConnector/Outbound-Connector für eine Domain "*" anlegen, dann wird dieser wohl nur genutzt, wenn der Absender von "intern" kommt. Damit ist Exchange Online z.B. kein "Offenes Relay" und Loops werden zumindest erschwert.
Das sind die vier Punkte, die jeder Administrator im Blick haben sollte, wenn er unterschiedliches interne Mailsysteme miteinander verbindet.
- Office 365 Message Attribution
https://techcommunity.microsoft.com/blog/exchange/office-365-message-attribution/749143 - Demystifying and troubleshooting hybrid
mail flow: when is a message internal?
https://techcommunity.microsoft.com/blog/exchange/demystifying-and-troubleshooting-hybrid-mail-flow-when-is-a-message-internal/1420838
Eigenschaft erkennen
Ob eine Mail authentifiziert oder anonym ist, können Sie in dem SMTP-Header zur Mail sehen. Relevant ist dabei das Feld "X-MS-Exchange-Organization-AuthAs" oder X-MS-Exchange-Organization-MessageDirectionality, welche den Status der Mails wiedergeben. Bislang habe ich folgende Werte gesehen. Die beiden möglichen Werte sind:
# Anonyme Mail X-MS-Exchange-Organization-MessageDirectionality: Incoming X-MS-Exchange-Organization-AuthAs: Anonymous # Authentifizierte Mails X-MS-Exchange-Organization-MessageDirectionality: Originating X-MS-Exchange-Organization-AuthAs: Internal
Wer die Header weiter betrachtet, kann noch zwei weitere Header entdecken, die sehr ähnlich sind.
# Anonyme Mail X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet # Authentische Mail X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: TreatMessagesAsInternal-BE1PEPF0000056B.DEUP281.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
Die "X-MS-Exchange-CrossTenant--*"-Header enthalten die Werte die vorher in den "X-MS-Exchange-Organization-"-Headern gestanden haben, wenn die Mail zu einer anderen Exchange Organisation über einen entsprechenden Connector übertragen werden.
Wenn ich eine Mail ohne irgendwelche Header per TELNET an einen Tenant sende, dann finde ich aber auch "X-MS-Exchange-CrossTenant"-Felder. Es gibt also noch andere Quellen.
Wenn die Verbindung "vertrauenswürdig" ist, dann werden die Werte übernommen. Microsoft hat das hier auch dokumentiert:
Quelle: Set-InboundConnector - CloudServicesMailEnabled
https://learn.microsoft.com/de-de/powershell/module/exchange/set-inboundconnector?view=exchange-ps#-cloudservicesmailenabled
Das bedeutet aber nicht automatisch, dass eine Mail, die z.B. OnPremises anonym eingeliefert wird mit der Übertragung über einen Hybrid-Connector in Exchange Online damit auch zu "authentifiziert" gewandelt wird.
- X-MS-Exchange-Organization-AuthAs
- X-MS-Exchange-CrossTenant-Id
-
Set-InboundConnector - CloudServicesMailEnabled
https://learn.microsoft.com/de-de/powershell/module/exchange/set-inboundconnector?view=exchange-ps#-cloudservicesmailenabled
OnPremises-Connector und TreatMessagesAsInternal
Kommen wir nun zu dem Schalter, dem diese Seite eigentlich gewidmet ist und den ich bei der Arbeit zu Linux Exchange Hybrid genauer untersucht habe. Dort hatte ich die Aufgabenstellung zu lösen, dass ein Exchange Online Tenant ohne lokalen Exchange Server mit einem lokalen Linux-basierten Mailsystem verbunden werden sollte und die Mails des Linux-Systems als "vertrauenswürdig", quasi wie "intern" betrachtet werden sollten.
Natürlich müssen Sie bei so einer Konfiguration 100% sicher sein, dass von diesem Linux-System dann auch nur verifizierte Mails eingeliefert werden. Es darf also NIE NIE NIE eine Mail aus dem Internet mit einer internen Absenderdomain hier auftauchen.
Die Online-Hilfe schreibt aber nun dazu:
Quelle: Set-InboundConnector - TreatNessagesAsInternal
https://learn.microsoft.com/de-de/powershell/module/exchange/set-inboundconnector?view=exchange-ps#-treatmessagesasinternal
Die Konfiguration mit "TreatMessageAsInternal" geht nur per PowerShell:
New-InboundConnector ` -Name "OnPrem2EXO" ` -ConnectorType OnPremise ` -TreatMessagesAsInternal:$true ` -RestrictDomainsToIPAddresses $true ` -SenderIPAddresses "217.91.247.140" ` -SenderDomains "*"
Bei der Einrichtung eines neuen Connectors zeigt Exchange Online noch eine weitere Warnung an:
Der "Vertrauenslevel" wird nur für Mails gewährt, die als Absender eine "Accepted Domain" des Tenant haben. Kommen über den gleichen Connector Mails aus dem Internet an, dann bleibt das eine "Internet Mail"
Im Exchange Admin Center sind die Einstellungen zu sehen aber die Konfiguration von "-TreatMessagesAsInternal:$true `" ist nicht sichtbar.
Dennoch finden ich diese Beschreibung sehr elektrisierend, da Sie mir nicht nur mein Problem beim einer Einlieferung eines anderen Mailsystems hilft, sondern auch eine Hybrid-Bereitstellung mit einem 3rd-Party-Relay in einer DMZ helfen könnte.
Auswirkungen
Ich habe in meinem Exchange Online Tenant also einen "OnPremises Inbound Connector" angelegt, der auf meine IP-Adresse gebunden war. Danach habe ich einige Mails per TELNET einfach an den Exchange Online Server gesendet und als Absender sowohl ein existierendes Konto im Exchange Online Tenant, ein nicht existierendes Konto mit einer Domain des Tenants und ein ganz externes Konto genutzt. Interessant sind dann der X-MS-Exchange-Organization-AuthAs, die Anzeige aber auch die SPF-Antwort.
Szenario | Gültige Absenderadresse im Tenant | Ungültiger Absender mit Domain des Tenant | Externer Absender |
---|---|---|---|
Beschreibung |
Ich habe eine Mail von extern mit der passenden Source-IP-Adresse an den Tenant gesendet, bei dem die Absenderadresse in der GAL vorhanden war. Exchange Online hat den Anzeigename aus der GAL übernommen und den Anzeigenamen aus dem Mail-Header nicht angezeigt |
Ich habe eine Mail von extern mit der passenden Source-IP-Adresse an den Tenant gesendet, bei dem die Absenderadresse nicht in der GAL vorhanden war. Exchange Online hat den Anzeigenamen aus dem Mail-Header angezeigt. |
Ich habe eine Mail von extern mit der passenden Source-IP-Adresse an den Tenant gesendet, bei dem die Absenderadresse nicht aus einer "Accepted Domain" war. Exchange Online hat die Mail als extern klassifiziert. |
Anzeige in OWA |
![]() |
![]() |
![]() |
From |
GAL-Lookup |
P2-From ohne Anzeige der SMTP-Adresse |
P2-From mit Anzeige der SMTP-Andresse |
SPF-Ergebnis |
Fail |
Fail |
Fail |
X-MS-Exchange-Organization-MessageDirectionality |
Originating |
Originating |
Originating |
X-MS-Exchange-Organization-AuthAs |
Internal |
Internal |
Anonymous |
X-MS-Exchange-CrossTenant-AuthAs |
Internal |
Internal |
Anonymous |
X-MS-Exchange-CrossTenant-FromEntityHeader |
HybridOnPrem |
HybridOnPrem |
HybridOnPrem |
Die Tabelle zeigt mit folgendes:
- Absenderdomain zählt für AuthAs
Der On-Premises Inbound Connector setzt die vier relevanten Felder auf "vertrauenswürdig", wenn ich mit einer Absenderdomain ankommen, die zum Tenant gehört - From-Anzeige
Wenn die Absenderadresse in der GAL gefunden wird, ersetzt Exchange den angezeigten Namen durch den Displaynamen aus der GAL
Wenn die Absenderadresse zwar aus der Domain ist aber nicht in der GAL gefunden wird, dann nutzt der den Displaynamen aus dem Header-From aber zeigt keine SMTP-Adresse an.
Bei Absendern aus externen Domains nutzt er den Absender aus dem Header-From und zeigt die SMTP-Adresse an - SPF Fail aber keine Reaktion
Obwohl alle drei Mails einen SPF-Fail haben, wird keine Mail in die Quarantäne verschoben. Das kann aber eine Momentaufnahmen sein und könnte sich auch ändern.
Um den Fall mit den "ungültigen" Adressen aus der Tenant-Domain noch etwas genauer zu verstehen, habe ich zwei Mails gesendet, in denen einmal der Envelope-from (P1) und einmal der Header-From (P2) ungültig war:
Eingabe | Anzeige |
---|---|
Hier ist die Absenderadresse
im Umschlag (P1) korrekt
aber die "from:"-Adresse in
der Mail, die der User
normalerweise sieht nicht.![]() |
Der Anwender sieht hier den
"Anzeigename" des P2-From
und nicht den Envelope. Die
Anzeige zeigt aber nicht
zusätzlich die falsche
SMTP-Adresse an.![]() |
Hier ist der Userpart im
Umschlag (P1) falsch. Ein
SPF-Check passt aber der
Absender ist nicht bekannt.
Allerdings enthält nun P2
eine korrekte Adresse aber
mit abweichendem
Displayname.![]() |
Das empfangende Exchange
System löst anhand der
SMTP-Adresse aus dem
"FROM"-Header den Absender
auf und zeigt den
Displaynamen aus der
Exchange GAL an.![]() |
Exchange Online wertet aus einer eingehenden Mail über den OnPremise Connector mit aktiviertem TreatMessagesAsInternal nur die Absender Adresse aus dem Header der Mail aus.
Wenn die SMTP-Adresse im Header falsch ist, dann wird der Anzeigename aus dem Header (FCADMIN1) angezeigt.
- Set-InboundConnector - TreatNessagesAsInternal
https://learn.microsoft.com/de-de/powershell/module/exchange/set-inboundconnector?view=exchange-ps#-treatmessagesasinternal
Weitere Links
- AcceptCloudServicesMail und CloudServicesMailEnabled
- OnPremises Connector
- X-MS-Exchange-CrossTenant-Id
- Linux Exchange Hybrid
- X-OriginatorOrg
- XOORG und Exchange
- Exchange Hybrid Absicherung
- Hybrid Mail Routing
- Linux Exchange Hybrid
- X-MS-Exchange-Organization-AuthAs
- Set up connectors to route mail between
Microsoft 365 or Office 365 and your own
email servers
https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/set-up-connectors-to-route-mail - Mail flow best practices for Exchange
Online, Microsoft 365, and Office 365 (overview)
https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/mail-flow-best-practices - Transport routing in Exchange hybrid
deployments
https://learn.microsoft.com/en-us/exchange/transport-routing - Demystifying and troubleshooting hybrid
mail flow: when is a message internal?
https://techcommunity.microsoft.com/blog/exchange/demystifying-and-troubleshooting-hybrid-mail-flow-when-is-a-message-internal/1420838