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. 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.

Weitere Themen

Wenn es um Exchange Online und SMTP geht, gibt es immer noch ein paar weitere Punkte zu beachten:

  • Spamschutz
    Der Exchange Online Spamfilter ist eigentlich immer aktiv. Sie können ihn lockern, aber z.B. "High confidence Phish" ist dennoch aktiv. Die Mails vom Gateway an Exchange Online dürfen also nicht als "Internet" angesehen werden, auch denn der Absender aus dem Internet kommt  Durch den "Org-Connector" sollte das aber entspannt sein. (Siehe OrganizationConnector und Spamfilter) Dennoch sollten Sie EXO Enhanced Filtering aktivieren
  • SPF/DKIM eingehend
    Hier gibt es keine Veränderung, da die DKIM/SPF-Prüfung vor unseren Connectoren stattfindet.
  • SPF/DKIM ausgehend
    Die Mails werden von Exchange Online ins Internet versendet. Das Gateway ist nicht sichtbar und stört auch nicht. Exchange Online addiert die DKIM-Signatur erst beim Verlassen von Exchange Online, also lange nachdem das Gateway die Mail verändert hat.
  • Centralized Mailtransport
    Bei der Konfiguration des Hybrid Mode gibt optional die Möglichkeit, alle Mails über OnPremises routen zu lassen. Diese darf natürlich nicht mehr aktiviert sein.
  • Message Rate Limits
    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