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 |
2 |
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
- Org-Connector Attribution
- Exchange Intern/Extern
- Exchange Online als Outbound Relay
- Hybrid RoutingFail
- Exchange Online Disclaimer
- Exchange Online Connector Routing
- HCW - Hybrid Configuration Wizard
- Exchange Online mit Wildcard-Zertifikat
- Exchange Online Message Rate Grenzen
- OrganizationConnector und Spamfilter
- EXO Enhanced Filtering
- EXO mit NoSpamProxy