X-OriginatorOrg

Diese Seite beschreibt die Möglichkeiten den individuellen Tenant bei eingehenden Mails von Exchange Online zu unterscheinden. Diese Funktion ist für 3rd Party Dienste aber auch eingehende Spamfilter wichtig.

Problemstellung

Immer mehr Firmen nutzen Microsoft 365 und Exchange Online und jede direkt von Exchange Online versendete Mail kommt von einem großen Pool von Exchange Servern.

Bei meiner letzten Zählung waren das schon ca. eine halbe Million IPv4-Adressen.

Es gibt aber keinen Exchange Server pro Domain oder Firma und alle Exchange Server melden sich nach extern mit einem HELO <servername>.outbound.protection.outlook.com. Hier ist kein Rückschluss auf einen Tenant möglich. Zudem unterstützt und nutzt Exchange Online auch TLS und weist sich mit dem Zertifikat "mail.protection.outlook.com" gegenüber dem Zielsystem aus. Auch hier gibt es keine Möglichkeit den Tenant zu ermitteln. Warum das wichtig ist?

Szenario Beschreibung

 

Hybrid

Der erste Anwendungsfall ist gleich bei Microsoft zu suchen. Wenn sie Exchange Online und On-Premises parallel nutzen, dann richtigen Sie den Hybrid-Mode ein, bei dem auch eine SMTP-Kopplung erfolgt. Ihr On-Premises Exchange Server "vertraut" dabei der Exchange Online-Welt und nutzt dazu eine Logik, indem es das Zertifikat "mail.protection.outlook.com" einbezieht und die XOORG-Information mit den Accepted Domains vergleicht.

Damit kann sich zwar kein anderer böser Server als "Exchange Online" ausgeben aber ein anderer Tenant könnte sich eine Hintertür in ihre Umgebung konfigurieren und wurde auch von Microsoft schon thematisiert:

 

3rd Party Relay

 Wenn Sie z.B. NoSpamProxy oder ein anderes System vor Office 365 schalten und die Exchange Online alle Mails immer über dieses System versendet, dann darf das System ja auch nicht "jedem Office 365 Tenant" vertrauen. Sie glauben gar nicht, wie schnell ein Mailserver im Internet "gefunden" wird und ein böser Nutzer könnte aus seinem Tenant dann auch ihren Service nutzen. Eine Absicherung anhand der Microsoft IP-Adressen oder des Zertifikats reicht nicht aus.

 

Hosted Service

Das gleiche gilt natürlich, wenn ein Anbieter (NoSpamProxy Cloud) für viele aber nicht alle Tenants einen Service anbietet und unterschiedliche Konfigurationen anzuwenden sind. Erschwerend kommt dabei hinzu, dass eine Mail ja von einem Tenant zu einem anderen Tenant gehen kann und das System einmal die Mail als "eingehend von einem Kunden oder NichtKunden " und ausgehend zu einem anderen Kunden/NichtKunden einstufen muss.

 

Es ist also schon wichtig, dass ein Mailserver eine Nachricht die von Exchange Online kommt, auch etwas genauer zuordnen kann. Wir sprechen hier aber immer noch von einer "Inbound Attribution" einer Mail von Office 356 an ein anderes System

In die Gegenrichtung muss Exchange Online genauso eine Analyse starten, wie Arindam Thonker in seinem sehr lesenswerten Blog beschreibt.

Der Abschnitt mit der Entscheidungslogik steht am Ende der Seite und man sieht gut, dass Exchange Online eingehend das Zertifikat mit der MailFrom-Adresse oder die Source-IP mit der RCPTTO-Adresse verbindet, um den dazugehörigen Tenant zu bewerten. Office 365 hat es aber einfacher, weil die meisten Kunden eigene und unterschiedliche Mailserver haben. Interessant wird es hier, wenn zwei Hoster aufeinandertreffen.

Kriterien

Es gibt nun mehrere Möglichkeiten, anhand ein Service eine eigehende Mail mit einem Kunden über den Quell-Tenant verbinden kann. Leider ist das Naheliegende nicht immer richtig.

Kriterium Bewertung

Envelope: MAIL FROM

Mein erster Gedanke war, einfach die Absenderadresse zu verwenden. Microsoft sagt ja, dass ein Tenant nur mit einer Mailadresse einer Domain senden kann, die als "Accepted Domain" in Exchange Online eingetragen und verifiziert wurde. Damit sollte ich ja sicher sein. Leider habe ich schnell festgestellt, dass das nicht unbedingt stimmen muss, denn es gibt da ein paar Sonderfälle:

  • NDR
    Normalerweise lehnt Exchange Online Mails an ungültige Empfänger direkt ab. Aber es gibt Fälle, bei denen Exchange Online die Mail angenommen hat und dann natürlich einen NDR erstellen muss. Ein NDR hat aber einen "MAIL From:<>" Envelope. Das ist in SMTP so spezifiziert, damit auf eine Systemmeldung wie eine Quittung nicht wieder eine Automatische Antwort o.ä. erfolgt.
  • Umleitung
    Sie können in Exchange Online einen Kontakt anlegen, so dass Mails an diesen Kontakt an eine andere externe Adresse gesendet werden. Ich nutze das z.B. gerne um Druckermeldungen (Out of Toner) oder Monitoring-Meldungen an einen Dienstleister zu routen. Das ist ein "Weiterleiten", bei dem der Absender ersetzt wird, sondern der originale Absender bleibt erhalten.
  • Verteiler/Mailinglist
    Sie können in Exchange Online einen Verteile anlegen, der sowohl "anonym" erreichbar ist als auch einen "MailContact" als Mitglied hat. MailUser sind nicht möglich. Eine Mail von extern an den Verteiler wird von Exchange Online an alle Mitglieder gesendet, wobei die Absenderadresse unverändert bleibt.

Das sind nur drei Beispiele, die aber zeigen, dass ein "MAIL FROM" der "Kundendomain" zwar alle Mails des Kunden erkennen würde aber andere Mails falsch zugeordnet würden. Die Umleitung kann natürlich auch den Fallerwischen, dass der Kunde über einen anderen Tenant die Mails an die eigene Domain versendet und das Gateway dann die eigentlich eingehende Mail anhand des Mailfrom als ausgehend ansieht.

Envelope: XOORG

Es gibt verschiedene Quellen, dass Exchange Online beim MAIL FROM zusätzlich ein XOORG-Attribut mit der realen Domain des Absenders mitliefert. Damit könnte der Exchange Online Tenant sehr gut ermittelt werden.

Die Herausforderung dabei ist, dass der empfangende Mailserver auf ein eingehendes "EHLO" auch das Verb "XOORG" mitliefern und zudem beim Empfang des MAIL FROM auch das angehängte XOORG verarbeiten muss. Das geht nur mit einem entsprechenden angepassten MTA. XOORG ist kein Standardwerb sondern eine Microsoft Erweiterung.

Header: X-MS-Exchange-Crosstenant-Id

Exchange Online addiert aber weitere Felder im Header. So konnten Sie bis ca. September 2022 das Feld "X-MS-Exchange-Crosstenant-Id" im Header finden, in dem die TenantID, also die GUID des Tenants, hinterlegt war.

X-MS-Exchange-CrossTenant-id: 3c6855ff-e39f-4d09-a473-33807598ce4b

Damit konnte man sehr zuverlässig den Tenant unabhängig von den SMTP-Domains zuordnen. Es wurde auch immer nur der letzte Tenant geliefert wenn z.B. eine Mailingliste oder ein Verteiler die Nachrichten erneut gesendet hat

Leider hat Microsoft dieses von Anfang an als "intern" klassifizierten Header aus Sicherheitsgründen bei Mails nach extern entfernt.

Header: X-OriginatorOrg

Analog zu "X-MS-Exchange-CrossTenant-id" gibt es im Header eine Mail von Exchange Online noch das Feld "X-OriginatorOrg", welche die Domain des Absenders enthält.

X-OriginatorOrg: msxfaqlab.onmicrosoft.com

Damit sollte ich auch den Tenant erkennen können. Bei einem Check mit einem Verteiler konnte ich auch bestätigen, dass das Feld die Domain des Tenants mit der Verteilerliste enthält.

Nach meiner aktuellen Einschätzung ist daher "X-OriginatorOrg" der beste Kandidat um einen Tenant eindeutig und einfach zu erkennen. Alternativ könnte noch die XOORG-Option genutzt werden, wozu sie natürlich einen "passenden" SMTP-Service bereitstellen müssten. 

X-OriginatorOrg-Quellen

Ehe Sie aber ein Feld nutzen, welches vielleicht wie "X-MS-Exchange-Crosstenant-Id" erst da und dann wieder weg ist, habe ich mich auf Quellensuche nach diesem Feld begeben und doch einige Treffer direkt bei Microsoft gefunden:

Zum gibt es einen Hinweis darauf in einem sehenswerten Video von Arindam Thokder über Exchange Hybrid.

Establishing Exchange Hybrid Mailflow
https://www.youtube.com/watch?v=1i_SO6nKe0o&t=605s

Er erklärt z.B., welche Felder im Header eine Mail beim Hybrid Mailflow beibehalten werden.


Quelle: Establishing Exchange Hybrid Mailflow https://www.youtube.com/watch?v=1i_SO6nKe0o&t=605s

Ein zweiter Hinweis kommt aus dem folgenden Artikel:

Wenn ihr MX-Record in die Cloud verweist und eingehende Mails nur über EXO ihren On-Premises Server erreichen sollen, dann könnte theoretisch dennoch ein Spammer den MX-Record ignorieren und von einem andren Tenant direkt ihren Mailserver ansprechen. Da hilft auch keine Firewall, die eingehende Verbindungen auf die Exchange Online IP-Adressen beschränkt. Wer diese Hintertür abdichten will, kann dies anhand des Microsoft Artikels mit einer Transportregel auf dem lokalen Exchange Server tun:


Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/advanced-office-365-routing-locking-down-exchange-On-Premises/ba-p/609238 

Im September 2022 fand zudem die öffentliche und kostenfreie MEC 2022 (https://mecairlift.event.microsoft.com/home) als virtuelle Konferenz statt, in der es auch eine interessante Folie zu dem Thema gab:

Das sind schon deutliche Hinweise, dass dieser Header beständig ist und als Kriterium zur Erkennung des einliefernden Tenants genutzt werden kann. Aber sie sollten natürlich sicherstellen, dass die Mails mit dem Header wirklich von Exchange Online gekommen sind. Dafür ist dann doch wieder die Source-IP relevant, um die Erreichbarkeit ihres internen Exchange Servers zu beschränken.

Verifikation

Ehe ich mich auf das Feld "X-OriginatorOrg" stürzen würde, sind ein paar Überprüfungen erforderlich, wann dieses Feld mit welchem Wert gefüllt ist und dann das Feld vielleicht überschrieben oder entfernt wird. Es ist ja eigentlich nur ein SMTP-Header, der von jedem SMTP-Server addiert und verändert werden könnte. Daher habe ich einen Office 365 Tenant mit Exchange Online und ein POP3/IMAP4-Postfach bei einem anderen Provider genutzt, um ein paar Mails zu senden. Eingehend zu Exchange Online habe ich die Mails per Telnet von der statischen Net at Work IP-Adresse samt dem Header eingeliefert.

TELNET uclabor-de.mail.protection.outlook.com 25
HELO netatwork.de
MAIL FROM:<absender@netatwork.de>
RCPT TO:<user2@uclabor.de>
DATA
Subject: Test x-originator
X-OriginatorOrg: carius.de

Test
.

Ich habe für X-OriginatorOrg absichtlich wieder eine andere Domain genutzt, um auch Fälschungen zu simulieren. Zuletzt habe ich noch Mails über einen Verteiler von Extern nach Extern gesendet

Richtung Absender Connector Empfänger Status Beschreibung

Intern

Tenant1

<intern>

Tenant1

<Leer>

Das Feld wird anscheinend nicht addiert, wenn eine Mail innerhalb des gleichen Tenants versendet wird. Es eignet sich also weniger für interne Transportregeln

Ausgehend

Tenant1

Default

Extern

Gesetzt

Das Feld enthält die Domain des Absenders.

Ausgehend

Tenant1

Partner

Extern

Gesetzt

Das Feld enthält die Domain des Absenders.

Ausgehend

Tenant1

OnPrem

Extern

Gesetzt

Das Feld enthält die Domain des Absenders.

Eingehend

Extern

Default

Tenant1

<Leer>

Das extern mitgelieferte Feld wird von Exchange Online entfernt

Eingehend

Extern

Partner

Tenant1

<Leer>

Das extern mitgelieferte Feld wird von Exchange Online entfernt

Eingehend

Extern

OnPrem

Tenant1

<Leer>

Das extern mitgelieferte Feld wird von Exchange Online entfernt

Ausgehend

ExternRelay

Default

Extern

<defaultDomain>

Der weiterleitende Tenant setzt das Feld auf die Default Domain.

Ausgehend

ExternRelay

Partner

Extern

<defaultDomain>

Der weiterleitende Tenant setzt das Feld auf die Default Domain.

Ausgehend

ExternRelay

OnPrem

Extern

<defaultDomain>

Der weiterleitende Tenant setzt das Feld auf die Default Domain.

Alle Ergebnisse vom Stand Sep 2022. Als Kurzfassung können wir festhalten:

  • Eingehend wird entfernt, Intern nicht addiert
    Bei einer Mail an Exchange Online wird das Feld immer entfernt, selbst wenn Sie über ein "Hybrid"-Connector kommt. Wir können den Header daher nicht innerhalb von Exchange Online nutzen und ein Spammer kann das Feld auch nicht fälschen. Hier wirkt wohl die Exchange Firewall
  • Ausgehende mit Domain des Senders
    Das Feld wird bei allen Mails gesetzt, die den Tenant verlassen. Es egal, ob dabei der Default Send Connector, ein Partner-Connector oder ein Exchange On-Prem (Hybrid) Connector genutzt wird.
    Dabei ist der Wert die Domain des Absenders und nicht die "<tenantname>.onmicrosoft.com" oder "Exchange Default Domain"
  • Default Domain des Tenant bei einer Umleitung/Weiterleitung
    Wenn Sie eine Mail von Tenant1 an einen Verteiler in Tenant2 senden, der die Mail dann zu Tenant3 sendet, wird das Feld X-OriginatorOrg auf die DefaultDomain des Tenant2 gesetzt

Das Feld kann übrigens nicht durch einen Anwender gesetzt oder per SMTP-Einlieferung gefälscht werden. Das Feld X-OriginatorOrg wird von Exchange Online auf jede ausgehende Mails geschrieben und eingehend entfernt

Exchange On-Premises

Ein lokaler Exchange Server setzt aktuell (Sep 2022) das Feld "X-OriginatorOrg" noch nicht. Aber er hat durchaus Code zur Behandlung dieses Feldes. Meine Testserie hat ergeben

Test Ergebnis Beschreibung

Anonyme SMTP-Zustellung an Exchange 2016 mit gesetztem X-OriginatorOrg

Exchange 2016 entfernt den Header

Exchange erlaubt es einem anonymen Absender nicht das Spoofing dieses Felds. Es ist dabei egal, ob die Mail direkt zu einem Exchange Hub/Transport oder einen Exchange Edge Server gesendet wird. Im Pipeline-Trace können Sie dies sogar erkennen.

„Ignored X-OriginatorOrg header value 'msxfaqlab.onmicrosoft.com' because 
session capabilities do not allow it”

Hybrid SMTP-Zustellung an Exchange 2016 mit gesetztem X-OriginatorOrg

Header des Tenants bleibt

Der von Exchange Online gesetzte Header wird von Exchange 2016 übernommen und ist beim Client einsehbar.

Benutzer sendet von 2016 nach extern

Kein Header addiert

Wenn ein Exchange 2016 Postfach eine Mail versendet, wird der Header durch Exchange 2016 nicht addiert.

Anonym SMTP über Ex2016 Hybrid an ein EXO-Postfach

Tenant-Header wird addiert.

Im Postfach des Cloud ist das Feld X-OriginatorOrg mit der Domain des Absenders gefüllt.

Ich habe noch nicht geprüft, ob nun Exchange 2016 den Header addiert oder EXO anhand des Inbound Connectors dies tut.

Exchange On-Premises hat hier eine "Header-Firewall", die insbesondere beim Hybrid-Mode natürlich sicherstellen will, dass dieser Inhalt nicht gefälscht ist. Daher prüft Exchange On-Premises einmal die Domain, welches es von Exchange Online im Rahmen eines XOORG mitbekommt. Zudem prüft Exchange On-Premises wohl das Client Zertifikat des einliefernden Mailservers, ob dieses auf "protection.mail.outlook.com" lautet bzw. im Rahmen der Konfiguration als AcceptCloudServicesMail und CloudServicesMailEnabled hinterlegt ist.

Diese Prüfung machen aber andere Mailserver normalerweise nicht. Es betrifft sie also nur, wenn der Header wieder bei einem Exchange Server/Edge Server landet.

Wenn Sie also Exchange Online ohne einen lokalen Exchange Server nutzen und eingehende Mails zuverlässig dem eigenen Tenant zuordnen wollen, dann müssen Sie STARTTLS anbieten und könne dem Header X-OriginatorOrg nur vertrauen, wenn die Verbindung per MTLS mit dem Office365-Zertifikat abgesichert wurde.

Verwendung

Das Feld "X-OriginatorOrg" wird von Exchange Online auf die Domain des Absenders oder die Default Domain aus dem Quelltenant gesetzt. Wenn Sie als Empfänger prüfen, ob der einliefernde Server such per STARTLS mit einem Clientzertifikat "protecion.mail.outlook.com" identifiziert, dann haben Sie eine perfekte eindeutige Identifikation des Absender-Tenants.

Damit eignet sich das Feld vortrefflich zum Routing von Mails in vorgelagerten Systemen. Stellen Sie sich einen gehosteten Spamfilter wie "NoSpamProxy Cloud" vor, der von vielen Exchange Online Tenants genutzt wird. Natürlich muss jeder Administrator einen Send-Connector für das ausgehende Mailrouting über NoSpamProxy einrichten aber alle Tenants nutzen dabei das gleiche Exchange Online Zertifikat und die gleichen IP-Adressen. Der Betreiber des gehosteten Spamdienst kann diese beide Informationen nicht auswerten, um den individuellen Tenant zu erkennen.

Er könnte natürlich die "MAIL FROM"-Adresse nutzen, um den Tenant zu identifizieren aber das funktioniert bei Umleitungen/Weiterleitungen schon nicht mehr. Auch ist es für den Spamfilter schon ein Unterschied, ob er eine Mail von "intern nach extern" oder in der Gegenrichtung verarbeitet. Wenn aber zwei Tenants beide z.B. NoSpamProxy nutzen, dann muss die Instanz einmal die Mail als "Ausgehend" erkennen und den Regeln unterwerfen aber darf auch wieder als "eingehend", da die empfangende Firma auch eigene Regeln nutzt.

Hier kann die Lösung einfach MTLS erfordern und anhand des Exchange Online Zertifikats "protection.mail.outlook.com" sicherstellen, dass der Absender auf jeden Fall Exchange Online ist und dann auf das Feld vertrauen, um den Tenant zu ermitteln.

Weitere Links