Org-Connector Attribution

Das Mailrouting zwischen Exchange Online und einer lokalen Exchange Organisation wird in der Regel als Hybrid-Konfiguration bezeichnet. Dazu legt der HCW - Hybrid Configuration Wizard passende Connectoren an, die die Cloud mit der lokalen Umgebung verbinden. Dabei sollte natürlich sichergestellt werden, dass nur die legitime Gegenstelle diesen Connector nutzt, kein Spamfilter die Verbindung stört und die Daten verschlüsselt sind. Klingt einfach aber ich gehe auf dieser Seite auf einige Besonderheiten ein, insbesondere in Verbindung mit eigenen vorgeschalteten Spamfiltern.

Beachten Sie die generelle Seite zum Org Connector

Umgebung

Wir haben eine klassische Exchange Online-Umgebung mit vorgeschaltetem externen Spamfilter, wie hier abgebildet. Links ist der eigene Tenant, der alle Mails über eine NoSpamProxy-Instanz leitet und mit dem Internet als auch mit anderen Office 365 Tenants kommuniziert. Wenn der Connector zwischen NoSpamProxy und dem eigenen Tenant als "Unternehmenskonnektor" ausgebildet ist, dann müssen beide System auch die Kommunikation mit einem anderen Tenant klar unterscheiden können.

Die Konfiguration ist schnell erklärt:

1. Ausgehende Mails via NoSpamProxy
   Der Exchange Online Tenant bekommt einen Outbound-Connector vom Typ "zu Mailserver meiner Organisation", zu dem alle Mails geroutet werden. Quasi die Funktion Hybrid Centralized Mail Transport und NoSpamProxy bekommt eine Konfiguration, dass er die Mails von Exchange Online als "intern" ansieht.
   Hier ist aber schon das erste Ausrufezeichen (), wenn Sie müssen natürlich irgendwie sicherstellen, dass NoSpamProxy den Tenant unterscheiden kann. Eine IP-Adresse oder das Zertifikat scheidet hier aus. NoSpamProxy muss im Header erkennen, dass es der eigene Tenant ist
2. Mail vom Spamfilter zu Office 365
   In der Gegenrichtung sendet NoSpamProxy eingehende Mails einfach an Exchange Online. Hier ist das zweite Ausrufezeichen(), denn Sie müssen einen "Inbound Connector" anlegen. Die Einstellung muss dafür sorgen, dass eingehende Mails nicht mehr durch den Spamfilter gehen. Wenn Sie ihre eigene NoSpamProxy-Instanz betreiben, dann können Sie einfach die Quell-IP des NoSpamProxy-Servers nutzen. Wenn der vorgelagerte Spamfilter aber seinerseits "gehostet" ist, dann können ja auch andere Firmen diesen Spamfilter nutzen. Da muss Office 365 dann unterscheiden können, zu welchem Tenant die Mail gehört. Die Ziel-Domäne wäre hier ein Kriterium, wenn Sie Exchange nicht selbst als "Relay ins Internet" verwenden.
3. Vom Spamfilter ins Internet per MX-Record
   NoSpamProxy löst dann die Ziel-Adresse anhand der Domäne und MX-Record auf, um den nächsten Hop zu ermitteln
4. Zielserver ist im Internet
   Der Mailserver der anderen Seite nimmt die Verbindung an, prüft ggfls. RBL-Listen, SPF-Records etc. und die Mail ist zugestellt
5. Zielserver ist auch in Exchange Online
   Wenn der externe Empfänger ebenfalls die Dienste von Exchange Online nutze, dann verweist der MX-Record auf die gleichen Server, auf die auch die Verbindung 2 verweist. Hier ist dann die Frage zu stellen, wie Exchange Online den richtigen Tenant und Connector auswählt.

Den letzten Fall schauen wir uns etwas genauer an. Da die Verbindung zwischen Exchange Online und NoSpamProxy über "Connectoren Zu/von eigenen Mailservern" in Exchange Online hergestellt werden, ist folgendes Zitat hilfreich:

The following conditions must be met:
1. Connections must have a matching certificate name
2. At least one of the following domains must be a verified and accepted domain in Office 365:
   a Sender domain
   b Recipient domain
   c Domain name that matches the certificate's subject name
Quelle: “Identifying email from your email server” https://technet.microsoft.com/en-US/library/ms.exch.eac.InboundConnector_TlsNameMatchYourOrgServerCert(EXCHG.150).aspx

Aus der Beschreibung lese ich heraus, dass quasi auch ein Unternehmens-Connector mit IP-Adresse so nicht vorgesehen ist aber dennoch funktioniert. Viel wichtiger und aufschlussreicher ist aber der folgende Blog-Artikel:

Office 365 Message Attribution
https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143

Er beschreibt sehr genau, wie Exchange Online eine eingehende Verbindung erkennt und zu einem Tenant zuordnet.

Exchange Online versucht zuallererst zu ermitteln, ob eine Mail als "Originating" oder "Incoming" gewertet wird. "Originating" bedeutet, dass die Mail von einem Absender in ihrer Firma, d.h. entweder ein Exchange OnPremises oder ein Exchange Online-Postfach, ist. Eine Mail über einen Partner-Connector kann nie als "Originating" klassifiziert werden.

Der Partner-Connector trifft nur zu, wenn eine Mails nicht auf einen Org-Connector zugeordnet werden kann.

Konfliktfall

Bei all den Verbindung gibt es einen Fall, der besonders zu beachten ist:  Ein interner Exchange Online Absender des Tenant1 sendet eine Mail an einen Empfänger in Tenant2. Die Mail verlässt also ihren Tenant über NoSpamProxy und landet wieder bei Exchange Online. Damit stellt sich die Frage:

Wie unterscheidet Exchange Online die eingehende Verbindung vom NoSpamProxy hinsichtlich des Tenant?

Denn der Mailfluss ist ja wie folgt:

Der Weg ist auf den ersten Blick einfach aber offenbart das zweite Problem: Wenn der externe Empfänger ebenfalls die Dienste von Exchange Online nutzt, dann verweist der MX-Record auf die gleichen Server, auf die auch die Verbindung 2 verweist. Office 365 muss hier also primär anhand der Zieladresse den richtigen Tenant auswählen, damit Sie keine Loop produzieren. Eigentlich müsste ich nun eine kleine Testserie mit zwei Tenants starten und sehen, wann welcher Connector zum Einsatz kommt. Die Arbeit kann ich mir aber sparen, denn Microsoft hat das schön auf der folgenden Seite dokumentiert:

Office 365 Message Attribution
https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143

Diese Seite ist

Exchange Online versucht zuallererst zu ermitteln, ob eine Mail als "Originating" oder "Incoming" gewertet wird. "Originating" bedeutet, dass die Mail von einem Absender in ihrer Firma, d.h. entweder ein Exchange OnPremises oder ein Exchange Online-Postfach, ist. Ein Organization Connector ist definitiv die falsche Konfiguration für eingehende Mails über einen vorgelagerten Spamfilter!

Noch komplexer

Nun erschweren wir die Konfiguration durch eine Kaskade von Exchange OnPremises mit Exchange Online und vorgeschalteten Spamfilter. Eingehende Mails aus dem Internet durch NoSpamProxy und den Tenant sind noch einfach anhand der eigenen "Accepted SMTP-Domains" zu erkennen.

Aber ausgehend wird das Routing interessant, da nun Exchange Online eine Mail der On-Premises Umgebung erhält, deren Zieladresse nicht zur eigenen Domain gehört. Wenn aber genau diese Zieldomäne einem anderen Office 365 Tenant zugeordnet ist, dann muss Exchange Online unterscheiden können, wie die Mail zu behandeln ist. Erwartet wird, dass die Mail eingehend zum Tenant 1 geht und dann über NoSpamProxy weiter zum Tenant 3 geroutet wird. Es könnte aber genauso möglich sein, dass Exchange Online die Zieldomäne "erkennt" und damit direkt die Regeln des Tenant 3 anwendet. Die Mail umgeht dann ausgehend die NoSpamProxy-Instanz und wird nicht verschlüsselt, signiert, mit Disclaimer versehen.

Wie erkennt Exchange Online zuverlässig den On-Premises Hybrid Server, der natürlich nicht selbst per MX-Record Mails versenden darf? Eine kleine Testserie mit folgender Mail und unterschiedlichen Connectoren bringt auch hier Klarheit.

Absender: user@tenant1
Empfänger: user@tenant3s

Variiert werden dann die Einstellungen bezüglich IP-Adressen und TLS auf dem Connector, der aber immer ein "OrganizationConnector" ist, da ansonsten Header etc. nicht greifen. Erwartet wird, dass Exchange Online die Mail in Richtung NoSpamProxy sendet.

Beachten Sie, das selbst mit der Einstellung auf eine "Remote IP" als Kriterium der Org-Connector genutzt wird, wenn die RemoteSite mit einem Zertifikat ankommt, welches matched.

Störfaktor BadAdmin

Als Administrator des Tenant 1 habe ich natürlich keine Kenntnis, was der Admin von Tenant 3 macht. Theoretisch könnte es im Tenant 3 auch einen "Inbound Connector" geben, der den Einstellungen von Tenant1 entspricht. Die Analyse, wie Exchange Online in dem Fall dann reagiert, macht das Bild zum Routing komplett. Die Test-Mail hat die gleichen Absender und Empfänger wie bisher:

Absender: user@tenant1
Empfänger: user@tenant3

Zudem ist im Tenant1 der Connector so konfiguriert, dass er Mails von OnPremises in den Tenant1 überträgt. Sie erinnern sich auch noch an das Zitat für die Identifizierung des eigenen Servers:

The following conditions must be met:
1. Connections must have a matching certificate name.
2. At least one of the following domains must be a verified and accepted domain in Office 365:
   a Sender domain
   b Recipient domain
   c Domain name that matches the certificate's subject name
Quelle: “Identifying email from your email server” https://technet.microsoft.com/en-US/library/ms.exch.eac.InboundConnector_TlsNameMatchYourOrgServerCert(EXCHG.150).aspx

Was kann ich als BadAdmin erreichen?

• 1: Die Ersten kann ich als "BadAdmin" einfache konfigurieren indem ich den Zertifikatnamen des zu störenden Mailservers nutzen.
• 2a) Die "Sender-Domain" besitze ich aber nicht
• 2b) ich könnte aber "Empfänger" sein
• 2c) es ist sehr unwahrscheinlich, dass ich als BadAdmin eine Domäne in Office 365 registrieren kann, die im Zertifikat des Absenders ist

Mit dieser Analyse ist nun auch klar, welche Konstellation stören kann:

Allerdings ist auch dieses Testmuster wichtig für das Verständnis, wenn Exchange oder Spamdienstleister für mehrere Kunden genutzt werden und daher mehrere Kunden mit dem gleichen Zertifikat bei Exchange Online aufschlagen.

Weitere Links

• Org Connector
• Exchange Online Connector Routing
• Exchange Online als Nebeneingang für Mailempfang
• Hybrid Hintereingang
• Hybrid Mail Routing
• Hybrid Centralized Mail Transport
• EXO mit NoSpamProxy