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.

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.

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.

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.

Weitere Links