EXO mit 3rd Party Service

Immer mehr Firmen sind schon zu fast 100% in der Cloud und der Empfang als aus Versand wird über Exchange Online umgesetzt. Wie kann ich in so einer Umgebung eine 3rd-Party-Lösung z.B. für Disclaimer, Archivierung, SMIME/PGP einbinden?

Anforderung

Die Anforderung an meine Konfiguration sind folgende:

Richtung Beschreibung

Interne Mails unverändert

Mails zwischen den eigenen Benutzern sollen nicht über das Gateway geroutet werden sondern innerhalb des Exchange Systems und ggfls. einer Hybrid-Konfiguration zugestellt werden.

Internet zu eigenem Postfach

Jede eingehende Mail soll von Exchange Online empfangen und direkt zum Gateway gesendet werden. Wir nutzen so den Exchange Online Spamfilter. Das Gateway kann die Mail dann z.B. entschlüsseln und routet diese wieder zu unserem Exchange Tenant zurück. Exchange Online muss die eingehende Verbindung als immer unserem eigenen Tenant zuordnen, auch denn der Absender selbst auch in Exchange Online ist

Postfach ins Internet

Ausgehende Nachrichten müssen vor dem Versand ins Internet natürlich ebenfalls einmal durch das Gateway laufen, damit diese entsprechend verarbeitet werden, z.B. Anfügen eines Disclaimers, SMIME/PGP-Vorgaben etc.

Dabei soll in meinem Beispiel die Kommunikation mit dem Internet immer über Exchange Online erfolgen, Damit ich keinen eigenen Spamfilter betreiben muss und mein Gateway "versteckt" ist. Zudem ist es damit für mich einfacher, auch ein vom Anbieter gehostetes Gateway zu nutzen, z.B. NoSpamProxy Cloud als SMIME/PGP-Lösung.

Übersicht

Die gleich beschriebene Konfiguration habe ich hier als Bild dokumentiert. Wenn Sie keinen Exchange OnPremises Sender oder Empfänger haben, können Sie den grünen Teil links wegrationalisieren.

Achtung: Die folgende Beschreibung gilt nur, wenn das Gateway dediziert für ihren Tenant genutzt wird.
Ist das Gateway ein "Shared Service", der von mehreren Exchange Online Tenants genutzt wird, dann funktioniert diese Konfiguration nicht!

Die Konfiguration kommt mit zwei Connectoren in Exchange Online für das Gateway und zwei optionalen Connectoren in Exchange Online für die Hybrid Bereitstellung aus. 

Zudem brauche ich zwei Transportregeln in Exchange Online, die Mails zu Connectoren umleiten. Zudem müssen die Mails durch einen Header o.ä. gekennzeichnet werden, damit ich wieder Ausnahmen von den Regeln definierten kann. Dazu setze ich hier im Beispiel einen Header "X-EXO2GW" auf "1". Wenn ihr Gateway selbst einen eindeutigen Header nach Verarbeitung setzt, dann können Sie auch diesen Header nutzen und ersparen sich das Setzen eines eigenen Headers.

Denken Sie daran, dass es nicht nur ein Exchange Online gibt, sondern ganz viele Firmen in Exchange Online sich die gleichen Server, IP-Adressen und Zertifikate von Exchange Online teilen. Da auch jeder andere Tenant solche Connectoren konfigurieren kann, darf ihr Gateway nicht einfach auf die IP-Adressen oder Zertifikate vertrauen, sondern muss auch noch z.B. die eindeutige und von Exchange Online gesetzte "TenantID" im Header auswerten. Es könnte ja sonst mal passiere, dass ein anderer böser Tenant bei ihrem Gateway landet. Kniffliger ist die Konfiguration des Gateways für Hoster, die solche Gateways als "Shared Plattform" für viele Kunden betreiben.

Für die Einrichtung in meinem eigenen Tenant macht dies aber keinen Unterschied.

Konfiguration Connectoren

Zuerst sollten wir sicherstellen, dass überhaupt die Übertragung von Mails möglich ist. In Exchange Online sind dazu vier Connectoren zu konfigurieren, da zwei sowieso vorhanden sind:

Nr  Beschreibung

1

Der Versand von Exchange Online ins Internet muss nicht gesondert konfiguriert werden. Es gibt einen quasi "unsichtbaren" Connector, der alle Mails, die nicht intern sind oder über einen Connector abweichend übertragen werden, ins Internet routet. Sie können dessen Einstellungen nicht ändern. Sie können natürlich einen "Partner Connector" für die Domain "*" anlegen und damit abweichend die Zustellung steuern. Für dieses Beispiel ist dies nicht erforderlich

Exchange Online hat auch immer einen "eingehenden Connector" um Mails zu empfangen, die aus dem Internet an Exchange Online gesendet werden. Wenn die Mails als "Inbound" klassifiziert werden, weil kein anderer "Inbound Connector" etwas anderes vorgibt, dann kommt der Spamfilter von Exchange Online zum Einsatz. Auch hier ist erst einmal nichts zu ändern

3

Ein "Outbound Connector" zu einer lokalen Exchange Installation wird in der Regel durch den HCW - Hybrid Configuration Wizard angelegt. Er sorgt dafür, dass alle Mails an die eigenen Domain, die nicht direkt einen Empfänger in Exchange Online haben, über einen Smarthost zum lokalen Exchange Server geroutet werden. Auch hier brauchen wir nichts zu ändern.

4

In die Gegenrichtung sendet ein lokales Exchange in der Standardeinstellung die Mails an die Domain "<tenantname>.mail.onmicrosoft.com" zu Exchange Online und identifiziert sich über ein Client-Zertifikat oder notfalls die IP-Adresse. In unserem Beispiel möchte ich aber den Exchange Server hinter Exchange Online "verstecken". Daher wird auf dem lokalen Exchange Server, sofern sie dies nicht eh schon gemacht haben, der Adressraum auf "*" erweitert. Auf Exchange Online gibt es einen passenden "Inbound Connector" vom Typ "Organisation", damit diese Mails auch unbeschadet Exchange Online erreichen und sogar ins Internet weiter geleitet werden.

5

Damit unser Exchange Online Tenant weiß, wie Mails an das Gateway zu senden sind, legen wir einen neuen Org-Connector an, der alle Mails an den Zielnamen oder IP-Adresse sendet, die durch eine später anzulegende Transportregel dorthin umgeleitet  werden. Wir sollten aber TLS erzwingen. Dann ist nicht nur die Übertragung verschlüsselt. Das Gateway kann dann vom Exchange vorgezeigten Zertifikat sicherstellen, dass die Mail von Exchange Online kommt und die TenantID unverfälscht ist. Notfalls tut es aber auch die Source IP, die dann im Gateway zu pflegen ist.

Name        : Outbound EXO2GW
Typ         : An Organisation
Scope       : Durch Transporregel
Ziel        : gw.msxfaq.de  (oder IP-Adresse)
Absicherung : TLS Required, optimal Zertifikatname gw.msxfaq.de prüfen

6

Damit die Mails vom Gateway auch wieder in unseren Tenant samt Header kommen, legen wir einen Inbound-Org-Connector an, der diesmal aber zwingend ein Zertifikat aus einer im Tenant registrierten Domains erwarten muss. Nur dann funktioniert die "Tenant Attribution" sauber, denn bei Nutzung einer IP-Adresse als Quelle wertet Exchange Online die FROM-Adresse aus und das passt nicht bei eingehenden Mails aus dem Internet.

Name        : Inbound GW2EXO
Typ         : Von Organisation
Source      : Zertifikat: "gw.msxfaq.de"  (IP-Adresse reicht nicht!)
Absicherung : TLS Required

Zudem sollten Sie aktivieren, dass "EXO Enhanced Filtering, damit der SPF-Check sich nicht auf die IP-Adresse des Gateway bezieht.

Während der Konfiguration der Connectoren haben Sie die Möglichkeit, die Funktion zu "verifizieren". Nutzen Sie diese Funktion, um ihre Konfiguration zu prüfen.

Konfiguration Regeln

Wenn das Mailrouting im Grunde funktioniert, können wir die beiden Regeln anlegen. Ich nutze zwei Regeln von denen jede eine Richtung steuert. Dazu müssen wir beachten, dass eine Mail immer nur genau einmal durch das Gateway laufen soll, damit wir keine Schleifen bauen. Wir müssen also in der Regel eine Ausnahme definieren. Ideal ist dazu ein Message Header, der vom Gateway selbst gesetzt wird. Wenn das Gateway dies nicht macht, dann lassen wir Exchange Online einen Header addieren.

Hinweis:
Bei der Einrichtung der Transportregeln können Sie zum Test noch weitere Einschränkungen nutzen, z.B. dass die Regel nur auf bestimmte externe Test-Domains oder interne Absender/Empfänger wirkt. So können Sie recht gefahrlos die neue Konfiguration einführen.

Richtung Beschreibung

Internet -> Gateway -> Postfach

Jede Mail aus dem Internet soll zum Gateway gehen, sofern sie nicht schon einmal durch das Gateway gelaufen ist. Die Regel lautet daher:

Name  : "Internet via GW nach Intern"
WENN  : Absender ist extern
DANN  : Route Mails zum Outbound Connector EXO2GW
UND   : Setze Message Header X-EXO2GX = 1
AUSSER: Message Header X-EXO2GW ist schon 1

Damit bekommt die Mail auf dem Weg zum Gateway schon den Header mit und wenn sie zurückkommt, dann wird diese Regel nicht mehr angewendet.

Postfach -> Gateway -> Internet

Auch in die Gegenrichtung ins Internet möchten wir jede Mail an extern Empfänger erst durch das Gateway routen aber dann wieder annehmen und durch Exchange Online versenden lassen. Dazu legen wir folgende Regel an:

Name   : "Intern via GW ins Internet"
WENN   : Empfänger ist Extern
DANN   : Route Mails zum Outbound Connector EXO2GW
UND   : Setze Message Header X-EXO2GX = 1
AUSSER: Message Header X-EXO2GW ist schon 1

Wenn die ausgehende Mail wieder vom Gateway zurück kommt, wird es dank des "Inbound Connectors" als "Intern" angenommen aber aufgrund des Headers nicht erneut umgeroutet und stattdessen über den "Default Outbound Connector" versendet.

Wenn alles richtig konfiguriert ist, sollte immer nur genau eine der beiden Regeln gewinnen, denn ich hoffe nicht, dass ihr Tenant z.B.: Mails routet, bei denen Absender und Empfänger aus Sicht von Exchange Online "Extern" sind.

SPF-Check eingehend

Wenn eine Mail von Exchange Online über ein 3rd-Party Gateway verarbeitet wird, dann müssen Sie die Verbindung vom 3rd-Party-Gateway zurück zu ihrem Tenant hinsichtlich SPF-Check beachten. Zuerst die eingehende Richtung:

 

Wenn die Absenderdomain einen SPF-Eintrag mit "-all" veröffentlicht, dann wird Exchange Online beim Empfang vom Gateway die Mails als "SPF=FAIL" kennzeichnen.

Wenn die Absenderdomain einen SPF-Eintrag mit "~all" oder keinen SPF-Eintrag hat, dann ist das Ergebnis ein "Neutral" und der Anwender sieht folgende Meldung:

Der Link verweist auf:

Mit der Funktion "SkipLastIP" im Inbound Connector können wird dies nicht heilen, denn dann sind immer noch die Exchange Online-Stationen als "Received:"-Zeilen enthalten, die nur ein SPF=PASS liefern, wenn die Absenderdomain selbst mittels „include:spf.protection.outlook.com“ Exchange Online einbindet. Das können wir als Empfänger aber nicht steuern. Ansonsten ist es ein "Neutral", wie dieser Header gut zeigt:

Unten der erste Empfang durch Exchange Online mit SPF=Pass, weil die Absenderdomain einen SPF-Eintrag hat und die IP-Adresse passt. Dann der mittlere Block des internen Exchange Online Routings bis es zum Gateway läuft und dann beim erneuten Empfang ist der SPF=Neutral. Exchange Online hat beim zweiten Empfang die einliefernde IP-Adresse 197.37.132.199 durch "SkipLastIP" überlesen aber dann die IP-Adresse 40.93.78.50 zur SPF-Bestimmung genutzt.

Wir müssen also Zurücksenden vom Gateway zum eigenen Tenant dafür sorgen, dass entweder kein Spamfilter aufgrund von SFP passiert oder Exchange Online die richtige IP-Adresse auswertet. Allerdings ist ein SPF-Check sowohl bei eingehende „OnPremises-Connectoren Incoming“ mit CloudMailServices:$true als auch bei „OnPremises Incoming“ mit TreatMessagesAsInternal:$true aktiv!

Aber es gibt andere Optionen:

  • Enhanced Filtering
    Allerdings müssten wir alle IP-Adressen eingeben, die zwischen dem ersten Empfang und zweiten Empfang durch Exchange Online stehen. Das ist nicht nur das Gateway und dessen interne Verarbeitung sondern auch die ausgehenden Exchange Online Server und das kann sich auch ändern und müsste in jedem Tenant passieren, Das ist sicher kein praktikabler Ansatz.
  • ARC
    Ich kann meinen Exchange Online Tenant beibringen, welchem ARC-Seal ich vertraue. Wenn das Gateway oder Exchange Online im ersten Durchlauf ein ARC-Seal abringen, welches Exchange Online im zweiten Durchlauf akzeptiert, dann sollte das eine zweite SPF-Prüfung überstimmen. Allerdings darf das Gateway dann nichts an der Mail verändern, was bei Disclaimer und SMIME nicht mehr funktioniert oder muss selbst ein ARC-Siegel anbringen.
  • Exchange Transportregel
    Zuletzt bleibt nur eine Regel, die den "SCL=-1" anhand zuverlässiger Bedingungen setzt. Das kann die Source-IP des Gateways sein oder ein Header, den das Gateway setzt. Leider kann in Exchange Online keine Prüfung auf den "Connectornamen" oder das Client-Zertifikat des Gateway erfolgen. Man könnte auch hier einen weiteren SMTP-Header durch Gateway setzen lassen, um diesen mit in der Regel abzufragen. Aber dann würde der Spamfilter die Mail nicht verlagern aber die Spoofing-Warnung kommt dennoch.
  • "Received:"-Header Tuning
    Damit "SkipLastIP" greift und Exchange Online beim zweiten Empfang nicht die zwischenzeitlich von Exchange Online addierten Header sieht, könnte das Gateway einfach die "Received:"-Zeilen zwischen dem ersten Empfang und vor dem Gateway entfernen. Beim zweiten Empfang würde Exchange Online dann die IP-Adresse des Gateways überspringen und dann die richtige IP-Adresse der verbliebenen "Received:"-Zeile extrahiert.

Je nach Produkt habe ich unterschiedliche Ansätze gesehen, dies zu lösen. Das Problem bei SPF ist, dass es oft nicht sofort auffällt. Wenn der Absender auch eine gültige DKIM-Signatur angebracht hat, dann kann diese ein "SPF=FAIL" überstimmen. Ein SPF-FAIL wirkt auch nur, wenn der Absender seine Domain mit einem "-All" abschließt. Wenn dort nur ein "?All", "~All" oder nichts steht und keine DMARC-Richtlinie ein Reject vorschreibt, dann sollte SPF nur einen SoftFail oder Ignore gehen. Es gibt also sehr viele Konstellationen.

SPF-Check ausgehend

In die Gegenrichtung sieht die Lösung schon deutlich einfacher aus, da die Absende-Domain meine eigene Domain ist und ich die passenden SPF-Einträge selbst bestimmen kann.

 

Hier sendet ich mit "msxfaq.org" und Exchange Online routet die Mails zum Gateway, welches keine SPF-Prüfung macht, weil es andere Kriterien nutzt, z.B. X-OriginatorOrg oder eigene Header. Das Gateway liefert die Mails dann wieder über einen Connector zu Exchange Online ein. Da die Absender-Domain aber zum Tenant passt, kommt die Mail über den Connector als "Internal" an und wird von Exchange Online dann weiter versendet. Das externe System sieht eine eingehende Verbindung von einer Exchange Online-IP-Adresse, die ich im SPF-Record natürlich aufführen muss.

Shared 3rd Party Gateway

Am Anfang habe ich geschrieben, dass die Beschreibung nicht funktioniert, wenn das Gateway selbst auch ein Shared Service ist. Das möchte ich hier erklären. Die Gateways, welche in den Mailfluss meines Tenants eingebunden werden, sind noch relativ einfach zu konfigurieren, wenn jede Firma ihr eigenes Gateway verwendet. Da aber "as a Service" immer häufiger nachgefragt wird, gibt es entsprechende Gateways auch als "Shared" Cloud-Service und im Extremfall kann das Bild wie folgt sein:

Ich habe die Farben der Server gleich gelassen, denn alle blauen Server gehören zu Exchange Online und sind nicht pro Firma unterschiedlich. Alle arbeiten mit den gleichen gemeinsam genutzten IP-Bereichen und "protection.mail.outlook.com" als Client-Zertifikat. Ein Gateway kann also nicht anhand dieser beiden Kriterien den Tenant ermitteln.

Die beiden gelben Server gehören zum gleichen "Service" und sind im Extremfall auch die gleichen Server. Und diese müssen, abhängig vom der logischen Funktion unterschiedlich funktionieren. Schauen Sie sich jeweils die beiden Verbindungen einmal genau an:

  • Verbindung 1+3
    Eine Mail von Links nach rechts geht sowohl über die Verbindung 1 als auch 3 von Exchange Online zum Service. Für das Gateway ist es beide Male eine eingehende Verbindung von Exchange Online (gleiche IP-Range und Zertifikat = mail.protection.outlook.com") und auch die MAIL FROM und RCPT TO-Domains sind identisch. Hier braucht der Service etwas Hilfe von Exchange Online, um die wahre Quelle zu erkennen, z.B. ein eigener "Custom Header" mit einem Secret oder vielleicht X-OriginatorOrg, oder besser X-MS-Exchange-CrossTenant-Id welches von Exchange Online nicht "gefälscht" werden kann.
  • Verbindung 2+4
    Wenn der Service die Mails an Exchange Online zurücksendet, müssen wir darauf achten, dass die Mail dem richtigen Tenant zugeordnet wird (Org-Connector Attribution). Das Gateway "as as Service" sendet mit der gleichen Source-IP und seinem Zertifikat und auch hier sind MAIL FROM und RCPT TO in beiden Fällen identisch. Auf der Quelle sollte Exchange Online die Zuordnung anhand der MAIL FROM machen und im Ziel aber anhand von RCPT TO. Einen Header kann Exchange Online hier nicht nutzen. Dieses Problem ist nur über individuelle Zertifikate oder das Ändern des Absenders nach dem Sender Rewriting Scheme (SRS) durch das Gateway an der Quelle hilft nicht. Eventuell aber am Ziel, um den Ziel-Tenant anhand der MAIL FROM-Adresse zu erreichen.

Denken Sie in dem Umfeld auch an an NDRs, bei denen die "MAIL FROM"-Domain leer ist.

Zuletzt ist natürlich noch zu prüfen, dass alle Änderungen nicht auch die Installationen beschädigen, bei denen Das Gateway weiterhin zwischen Exchange Online und dem Internet steht und die Gegenseite "nur" Exchange Online nutzt.

Hier sind die Verbindungen 2 und 4 interessant, die aus Sicht von Exchange Online wieder "identisch" sind, wenn der Betreiber des Gateways keine Vorkehrungen trifft. Hier darf die Verbindung 4 nicht irrtümlich als eingehend vom Absender-Tenant klassifiziert werden. Das geht aber noch einfach über Header, die im Ziel Tenant beim ersten Empfang gesetzt und beim zweiten Empfang geprüft werden.

Aber auch die Verbindungen 1 und 3 sehen sehr ähnlich aus. Das Gateway sieht nur Exchange Online als Absender (IP und Zertifikat) aber bei beiden Verbindungen sind MAIL-FROM und RCPT-TO identisch. Aber hier liegt es auch in der Verantwortung des Exchange Administrators in Firma2 z.B. durch einen Header "seinen" Tenant zu kennzeichnen. Die Verbindung 4 darf also nicht als "Originating" sonder nur als "Anonym Incoming" klassifiziert werden damit Exchange Online anhand der RCPT-TO-Information den Tenant bestimmt. Kritisch ist in allen Fällen der Eingang zu Exchange Online, da hier Microsoft eine klare Regel der "Attribution" hat.

Und das ist alles andere als einfach, bei all den Konfigurationen den passenden Tenant zu ermitteln.

Message Rate Limits

Wenn es um Exchange Online und SMTP geht, gibt es immer noch ein paar weitere Punkte zu beachten. Exchange Online hat bestimmte Grenzwerte für übertragene Mails pro Zeiteinheit und Benutzer, Hosts, Tenants etc. Da die Mail aber über die Organization-Connectoren zum und vom Gateway übermittelt werden, sollten hier keine Einschränkungen zu erwarten sein 

Zusammenfassung

Die Beschreibung ist kein "How-To", bei dem jeder einzelne Schritt, möglichst noch mit Bildschirm-Fotos, dokumentiert wird. Darin sehe ich wenig Sinn, da Microsoft auch das Exchange Admin Center immer wieder verändert. Alle Einstellungen können Sie aber (Stand Nov 2024) über das Exchange Admin Portal vornehmen. Ich kann ihnen aber nicht die Arbeit abnehmen, ihre vorhandene Konfiguration auf Kompatibilität zu überprüfen. Meist gibt es schon Transport-Regeln und Connectoren, die bei der Einrichtung eines 3rd-Party-Gateway zu berücksichtigen sind.

Dennoch sollten sie mit der Beschreibung und einem Grundverständnis der Exchange Online Administration das gewünschte Ergebnis erreichen können. Die Schlüsselkomponenten sind die Organization-Connectoren und die Art und Weise, wie Exchange Online eingehende Verbindungen klassifiziert. Lesen Sie dazu unbedingt die Seiten zu "Tenant Attribution" (Siehe Org-Connector Attribution) und Exchange Intern/Extern, damit ihre Regeln auch zuverlässig funktionieren.

Wenn Sie eine komplexe Umgebung haben, dann können Sie gerne uns um Unterstützung bitten. Net at Work

Weitere Links