Hybrid RoutingFail
Wenn Sie eine Exchange Hybrid Konfiguration nutzen aber Mails von lokalen Postfächern ins Internet nicht über ihr lokales Relay sondern über Exchange Online versendet werden und sie daher solche Mails im EXO Messagetracking sehen, dann finden Sie hier die Erklärung und Lösung.
Ausgangssituation
Wir starten mit einer Hybrid Konfiguration, wie sie vermutlich noch bei vielen Firmen umgesetzt ist. Es gibt eine klassische Koexistenz zwischen Exchange OnPremises und Exchange Online und einen vorgelagerten Spamfilter, der nicht Exchange Online Protection ist, z.B.: weil Sie Zusatzfunktionen wie Disclaimer, LargeFile oder SMIME/PGP-Handling erwarten. Zwischen Exchange OnPremises und Exchange Online wurde durch den HCW das Hybrid-Routing konfiguriert und stellt eine sichere interne Zustellung zwischen den beiden Welten sicher.
Mails zum Internet gehen aber weiter hin gewohnt über das lokale Schutzsystem und weil es so bequem erscheint, ist ein Wild-Card-Zertifikat oder SAN-Zertifikat auf den wenigen extern erreichbaren Servern im Einsatz.
Mails zu anderen Firmen im Internet
Wenn ein lokaler Anwender eine Mail eine Mail an eine externe andere Firma im Internet sendet, wird diese über die lokale Schutzlösung und MX-Record zur Fremdfirma1 gesendet.
"Alles richtig gemacht", wäre man versucht zu sagen und lange Zeit ist auch kein Fehler sichtbar gewesen
Mails zu anderen Firmen in Exchange Online
Komisch wurde es nur, wenn mehr und mehr Firmen zu Exchange Online umgezogen sind und auch ihren MX-Record zu Exchange Online gedreht haben. Die Erwartung wäre nun, dass dass die Mails von der lokalen Schutzlösung über den MX-Record zu Exchange Online gesendet werden. Exchange Online kann dann anhand der "RCPT TO"-Adresse und der Domain problemlos erkennen, zu welchem Tenant die Mails zugestellt werden soll.
Dem war dann aber nicht so und stattdessen konnte der Exchange Online Admin sehen, das die Mail von den lokalen Benutzern erst durch den eigenen Exchange Online Tenant geroutet und dann an Firma2 zugestellt wurde. Wenn Sie noch mit Centralized Mail Transport oder Transportregeln für Archiv oder Disclaimer arbeiten, dann wurden die Mails sogar wieder zum lokalen Exchange System geroutet und endeten in einer Schleife oder Unzustellbarkeit
Ursache
Der Grund ist recht schnell erklärt, wenn Sie sich die Arbeitsweise von Exchange Online beim eingehenden Mailrouting betrachten. Microsoft hat das schon 2019 sehr ausführlich beschrieben aber viele Administratoren und Consultants haben es entweder nicht gelesen oder nicht verstanden.
- Office 365 Message Attribution
https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143 - Org-Connector Attribution
Exchange Online hat die Herausforderung, die verschiedenen eingehende Verbindungen zuverlässig zu unterscheiden und kann sich dabei nur vier Kriterien bedienen:
- Zertifikat des einliefernden Servers
- IP-Adresse des einliefernden Servers
- Domain der RCPT TO-Adresse
- Domain der MAIL FROM-Adresse
Zudem gibt es nun mehrere Tenants und unterschiedliche Connectoren mit unterschiedlichen Zielsetzungen. Exchange Online nutzt nur aber nicht die Domain aus der "RCPT TO"-Adresse, um den passenden Tenant zu identifizieren, dessen Connectoren herangezogen werden sollen, sondern versucht zuerst herauszufinden, ob dies eine interne Mail von einer Hybrid-Bereitstellung ist. Hierbei kommen dann die Source-IP, Source-Zertifikat und "MAIL FROM" zum Einstz.
Das Problem ist der "Inbound Organization Connector", welcher auf ein Zertifikat hört, welches auch von der eigenen Schutzlösung verwendet wird. Ob in dem Beispiel eine Mail von NoSpamProxy oder der lokalen Exchange Umgebung an Exchange Online gesendet wird, kann die Cloud erst einmal nicht unterscheiden. Daher prüft Exchange Online zwei Bedingungen:
- Suche in allen Tenants einen Inbound Org Connector mit einem übereinstimmen Zertifikat und dessen Domain auch eine Accepted Domain ist
- Suche in allen Tenants einen Inbound Org Connector mit einer übereinstimmen Source IP-Adresse und bei der MAIL-FROM-Domain in "Accepted Domains" ist
Wenn eine zutrifft, dann wird die Mail zu diesem Tenant zugeordnert und als "Originating", d.h. vertrauenswürdig betrachtet.
Die Kopplung mit den "Accepted Domains" verhindert, dass ein "böser Tenant" auch einfach mal einen Inbound Connector mit ihrem Zertifikat anlegt. Er "matched" nie. Bei der IP-Adresse ist dann das "Mail From"-Kriterium wirksam.
Damit ist auch klar, dass die Mail mit einem MSXFAQ.DE-Absender an eine externe Domain mit einem MX-Record zu Exchange Online erst einmal wieder im Tenant von MSXFAQ landet und dann von dort als ausgehendes Relay weiter gesendet wird. Letzteres gilt natürlich nur, wenn kein Centralized Mailtransport oder Transportregeln etwas anderes vorgeben.
- Office 365 Message Attribution
https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143 - Org-Connector Attribution
Lösung
Da sie nun wissen, wie Exchange Online eingehende Verbindungen klassifiziert, wissen sie auch um die Lösungswege.
Option | Beschreibung | Bewertung |
---|---|---|
Kein TLS ausgehend auf Schutzlösung |
Sie könnten natürlich ihrer Schutzlösung das Zertifikat entziehen oder zumindest für ausgehende Verbindungen beim STARTTLS dieses nicht mehr mitsenden. Dan kann Exchange Online nicht mehr das Zertifikat als Kriterium heranziehen und Mails an fremde Microsoft 365 Tenants werden nicht mehr über den "Inbound Organization Connector" ihrem Tenant zugeordnet. Das geht schnell aber reduziert die Sicherheit und verhindert die Authentifizierung bei anderen SMTP-Servern über das Zertifikate. |
Schnell. einfach aber keine Dauerlösung |
IP statt Zertifikat |
Sie könnten in ihrem Exchange Online Tenant den "Inbound Organization Connector" von "Zertifikate" auf "Source-IP"-umstellen. Auch das geht schnell aber funktioniert nur, wenn die Source-IP auch statisch und vor allem exklusiv von Exchange OnPremises genutzt wird. Denn jeder andere interne SMTP-Server der über die gleiche IP-Adresse zu einem beliebigen Exchange Online Tenant mit ihrer Absenderdomain sendet, wird ansonsten auch als "von meiner Organisation kommend" eingestuft. |
Mit Einschränkungen aber nicht ratsam |
Unterschiedliches Zertifikat |
Sie verwenden für Exchange ein eigenes eindeutiges Zertifikat. Das müssen Sie kaufen, auf dem Exchange Server installieren, im lokalen Send-Connector hinterlegen und auch in Exchange Online beim "Inbound Organization Connector" als Namen hinterlegen. Aber dann weiß Exchange Online zu 100%, wann eine Mail vom partnerschaftlich verbundenen lokalen Exchange Server kommt. Sie könnten natürlich auch ein separates Zertifikat für ihr Mailrelay zum Internet verwenden. Aber das reicht nicht, wenn sie auf dem "Inbound Organization Connector" in Exchange Online weiterhin mit "*.msxfaq.de" arbeiten. |
Optimale Lösung |
Wildcard-Zertifikate sind ein Sonerfall, der hier aber das Routing immens stört. Ich kann Wildcards verstehen, wenn Sie einen Reverse Proxy nutzen und dahinter ganz viele Dienste verstecken aber für die Identifizierung eines Servers gegenüber einem anderen System sollten Sie keine Wildcard-Zertifikate nutzen.
Am besten verwenden Sie für beide Dienste eigene unabhängig Zertifikate und verzichten auf "*" im Namen zur Verifizierung.
Dann sollten Sie auch keine ausgehenden Mails ihrer lokalen Anwender im eigenen Tenant finden, wenn sie einen lokalen Versand konfiguriert haben. Dies gilt natürlich nicht, wenn Sie alle Mails generell von OnPremises über den eigenen Exchange Online Tenant ins Internet versenden. Dann sollten Sie aber die verschiedenen Grenzwerte zum Versand von Mails über Exchange Online beachten.
- Exchange Online Message Rate Grenzen
- Exchange Online External Recipient Rate (ERR) Limit
- HVE - High Volume Email mit Exchange
- TERRL - Tenant External Recipient Rate Limit
Weitere Links
- OrganizationConnector
- Org-Connector Attribution
- Centralized Mail Transport
- Centralized Mail Transport mit Multi Forest
- Exchange Online Connector Routing
- Hybrid Edge Falschrouting
- Hybrid, Edge und Accepted Domain
- Office 365 Message Attribution
https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143 - Org-Connector Attribution
- Exchange Online Message Rate Grenzen
- Exchange Online External Recipient Rate (ERR) Limit
- HVE - High Volume Email mit Exchange
- TERRL - Tenant External Recipient Rate Limit