XOORG und Exchange

Wie erkennt eigentlich der Exchange Receive Connector bei einer Mail von Office 365 den richtigen Tenant? Diese Frage aber wir und bei Net at Work schon häufiger gestellt. Sicher kann eine Software die IP-Adresse von Office 365 Datacenter Servern als Kriterium für "es kommt von Exchange Online" nutzen. Noch besser ist es TLS zu erzwingen und dann das Zertifikat des einliefernden Office 365 Servers zu verifizieren und auf den "cn=mail.protection.outlook.com" zu prüfen. Wer aber mal die Verbindung zwischen Exchange Online, EOP und einer Exchange On-Premises-Umgebung genauer angeschaut hat, findet im Empfangskonnector noch eine andere Einstellung.

Hybrid Receive Connector

Je nach Exchange Version und verwendeter Version des HCW - Hybrid Configuration Wizard wird ein eigener Connector für den Mailempfang angelegt oder der bestehende Connector verändert. Bei Exchange 2010 sah es noch so aus.

Get-ReceiveConnector  | fl name,TlsDomainCapabilities

Name                  : Inbound from Office 365
TlsDomainCapabilities : {outlook.com:AcceptOorgProtocol}

Bei Exchange 2016 legt der HCW keinen eigenen Connector mehr an und setzt stattdessen einen anderen Wert in die TlsDomainCapabilities

Get-ReceiveConnector  | fl name,TlsDomainCapabilities

Name                  : Default Frontend EX2016A
TlsDomainCapabilities : {mail.protection.outlook.com:AcceptCloudServicesMail}

EHLO mit eigenem Server

Ich habe daher diese Einstellung etwas erweitert und meinen eigenen Server samt Zertifikat hier ebenfalls so eingetragen. Das geht ja recht einfach mit

New-ReceiveConnector fctest -RemoteIPRanges 192.168.178.10 -Bindings 0.0.0.0:26
Set-ReceiveConnector "EX2016A\fctest" -TlsDomainCapabilities fctest.msxfaq.de:AcceptOorgProtocol

Dann habe ich einfach erst mal ein EHLO per TELNET abgesendet.

Sie sehen sehr gut hier, dass der Exchange Server mir nun auch "XOORG" als Erweiterung anbietet.

Wer nutzt XOORG?

Wenn Sie dann im Internet etwas suche, dann finden sich ganz wenige Treffer zu XOORG aber das Blog von Microsoft ist wohl die umfangreichste Quelle:

Hier ist nämlich beschrieben dass Exchange Online diese Erweiterung beim Versand von Mails per SMTP zum On-Premises Server verwendet. Der On-Premises-Server hat bei einer eingehenden Verbindung von Exchange Online die knifflige Aufgabe zu unterscheiden, ob es eine Mail vom eigenen Tenant ist oder nur ein anderer Tenant unter Nutzung des MX-Records eine Mail an den Empfänger senden will. Office 365 addiert natürlich schon länger einen eigenen SMTP-Header, welcher den Source-Tenant der Mail enthält:

X-OriginatorOrg: contoso.com

Die Zusammenhänge habe ich dazu auf folgenden Seiten schon beschrieben.

Der Microsoft Blog Artikel liefert dazu:

Can someone spoof XOORG? The answer is “no”, the XOORG headers cannot be spoofed because it is the combination of the EOP TLS certificate, connector setting and accepted domain – and we control the headers when they pass through us, which is the case when our certificate is used.
Quelle: https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Advanced-Office-365-Routing-Locking-Down-Exchange-On-Premises/ba-p/609238

Note: X-MS-Exchange-Organization-AuthAs header stamped on email received by On-Premises server from O365 can be either “Internal” or “Anonymous”. For instance, emails sent from your EXO tenant to On-Premises servers, will have the X-MS-Exchange-Organization-AuthAs set to “Internal”. If it’s an external email which is relayed through your tenant, the original “Anonymous” identity would be preserved and the X-MS-Exchange-Organization-AuthAs will be set to “Anonymous”. Thus, X-MS-Exchange-Organization-AuthAs header would not differentiate between email coming directly to your On-Premises and email relayed through your tenant.
Quelle: https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Advanced-Office-365-Routing-Locking-Down-Exchange-On-Premises/ba-p/609238

Wenn der Zielserver also "XOORG" offeriert, dann sendet der Exchange Online Server beim "MAIL FROM" nicht nur die Absenderadresse sondern auch mit XOORG=<domain> die Default-Domain des Tenants. Im SMTP-Logging des On-Premises Exchange Server ist dies gut zu sehen:

2019-05-09T13:31:50.348Z,EX2016\Default Frontend EX2016,xxxxxx,xx,192.168.178.2:25,4.4.0.1:2143
     ,<,MAIL FROM:<clouduser@msxfaq.de> SIZE=2396 AUTH=<> XOORG=uclabor.de,

Die "MAIL FROM"-Zeile enthält nicht nur die Absenderadresse, sondern auch die Größe, die Authentifizierung und das neue Feld "XOORG" mit der Default Domain des Tenant. Da die Übertragung auf dem Kabel allerdings per MTLS verschlüsselt ist, können Sie die Verbindung nicht mit Wireshark decodieren. Sie haben ja keinen privaten Schlüssel von Office 365.

Bleibt die Frage zu klären, untern welchen Umständen Exchange Online ein XORG sendet. Microsoft schreibt selbst dazu

When email is sent from or relayed through your own tenant, Exchange Online will send XOORG SMTP command extension with the “MAIL FROM” Command which will be same as the default accepted domain on Exchange Online
Quelle: https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Advanced-Office-365-Routing-Locking-Down-Exchange-On-Premises/ba-p/609238

Damit ist aber nicht klar, ob das generell der Fall ist oder nur für den Hybrid Connector gilt und TLS erzwungen sei muss. Also habe ich mir einen kleinen SMTP-Server per PowerShell gebaut, der auf ein EHLO einfach schnell auch noch ein XOORG aber kein STARTTLS liefert. und getestet. Hier sehen Sie so eine eingehende Mail an meinen "SMTP-Server"

Es ist gut zu erkennen, dass Office 365 selbst ohne TLS das "XOORG-Feld" bei "MAIL FROM" mitliefert. Es betrifft natürlich nur ausgehende Connectoren von Office 365 und hier gib es nur zwei relevante Fälle

  • Zum Mailserver der eigenen Organisation
    Kommt bei einer Verbindung im Hybrid-Mode zum Einsatz und schließt auch interne SMTP-Header mit sein
  • Zu einem Partner-Server
    Erlaubt bestimmte Vorgaben (z.B. TLS Zwang) für bestimmte Domains
  • Internet
    Können Sie nicht einrichten.

Sowohl beim "Partner"-Connector als auch beim "Organization"-Connector hat Office 365 die "XOORG"-Information mit gesendet und dies war auch nicht abhängig von einer TLS-Option. auch beim Versand per MX-Record an einen Server, der XOORG angeboten hat, wurde die Option gesetzt.

Konstellation Organisationsserver Partnerserver Internet (MX)

XOORG gesendet

Ja

Ja

Ja

Allerdings sollte ein "annehmender" Server natürlich dieser Angabe nicht blind vertrauen. Nur, wenn sich der Absender per TLS-Zertifikat als "mail.protection.outlook.com" identifiziert, dürfen Sie dieser Information auch vertrauen.

Im November 2020 hat aber Arindam Thoker von Microsoft einen sehr sehenswerten Vortrag auf YouTube veröffentlicht. Dort sind die Zusammenhänge des Hybrid Mail Flow sehr gut erläutert.

Establishing Exchange Hybrid Mailflow
https://youtu.be/1i_SO6nKe0o?t=751

Auch die Verwendung von XOORG.


Quelle Establishing Exchange Hybrid Mailflow - https://youtu.be/1i_SO6nKe0o?t=751

XOORG ist in Verbindung mit dem TLS-Zertifikat quasi der Schlüssel, dass ein Exchange Server den einliefernden Server als "vertrauenswürdig" ansieht und die Mails annimmt und ggfls. so gar weiterleitet.

Nutzen für 3rd Party Software

Das bedeutet aber, dass eine 3rd Party Software so auch sehr früh den Ursprungstenant ermitteln. Das ist natürlich z.B. für NoSpamProxy als vorgelagerter Spamfilter interessant. NoSpamProxy spricht natürlich TLS und kann eine passende EHLO-Antwort auf eine Verbindung von Exchange Online liefern. Exchange Online kann dann seine Mail über NoSpamProxy ins Internet senden oder NoSpamProxy kann Mails von anderen Office 365 Tenants Mail an die eigenen Mailserver unterscheiden. In beiden Fällen kann NoSpamProxy seine Verständnis für XOORG mitliefern und Exchange Online sendet dann den Tenant-Namen mit.

Das eröffnet natürlich neue Wege für die Regelverarbeitung von eigenen Filtern. NoSpamProxy hat ein sehr leistungsfähiges Regelwerk zur Behandlung von ein- und ausgehenden Mails. Viele Filter und Entscheidungen können damit schon früh gefällt werden, so dass die komplette Mail gar nicht mehr angenommen werden muss. Dazu ist natürlich das Wissen um den Absender erforderlich. Wenn aber Hoster wie eben Office 365 sehr viele Domains über die gleichen Versendesysteme absenden, dann ist es nicht mehr so einfach, die individuellen Mandanten dahinter zu unterscheiden. Im Extremfall muss eine Software wie NoSpamProxy dann schon die komplette Mail erst einmal empfangen, bewerten und erst am Ende noch ablehnen.

Aktuell ist Office 365 natürlich zugleich der "Größte Hoster" von Postfächern. Aber ich kann mir gut vorstellen, dass auch andere Firmen, z.B. Google Mail u.a. Hoster mit Mandanten so eine Erweiterung umsetzen könnten. Leider ist XOORG anscheinend kein RFC-Standard und noch nicht mal ein Draft. Bleibt nur zu hoffen, dass Microsoft diese Erweiterung auch weiter beibehält.

Weitere Links