EXO Mailflow 1 Nov 2023 Update

Wer sein Messagecenter liest, bekommt Änderungen mit, die auch Exchange Online betreffen.

Diese Seite betrifft alle Firmen, die einen "OnPrem"-Inbound Connector im Tenant haben der nicht über Zertifikate funktioniert und Mails über Exchange Online ins Internet senden.

Worum geht es?

Betroffen sind Firmen, die Mails von einem lokalen Service über Exchange Online zu anderen Drittsystemen routen. Sie "verstecken" Exchange OnPremises quasi hinter Exchange Online. Diese Konstellation nutzen Sie, wenn sie z.B. Exchange Online Protection als Spamfilter nutzen und nicht nur eingehende Mails über Exchange Online zum lokalen Server geroutet werden, sondern sie auch ausgehend Mails durch EOP senden wollen. So können Sie auch vom OnPremises-Server z.B. von DKIM profitieren.

Exchange Online arbeitet dabei als "Relay" und natürlich sollte Exchange Online kein "offenes Relay" sein. Allerdings ist die Schnittstelle, an die ihr OnPremises-Server seine Mails sendet, keine private Adresse für ihre Firma, sondern eine allgemein zugängliche Adresse und Port 25. Microsoft muss sich hier also absichern.

Absicherung des Tenant

Daher hat Microsoft einen dokumentierten Prozess, wie Exchange Online generell eingehende Verbindungen klassifiziert. Exchange Online sucht zuerst nach einer Übereinstimmung des Zertifikats, welches der einliefernde Server vorweist. Es ist sehr unwahrscheinlich, dass jemand ein Zertifikat für eine Domain erhält, die ihm nicht gehört. So kann Microsoft sehr sicher anhand der Domain des Zertifikat und den "Accepted Domains" in einem Tenant eine Zuordnung erreichen und dem einliefernden Server "vertrauen". Dazu muss natürlich ein "Inbound OnPrem-Connector" im Tenant konfiguriert sein.

Wenn Sie ohne Zertifikat einliefern, dann nutzt Exchange Online die Quell-IP-Adresse, die in der Regel auch einer Firma gehört. Da aber auch ein anderer Tenant die gleiche Quell-IP in einem "Inbound OnPrem Connector" konfigurieren kann, verknüpft Microsoft noch die "MAIL FROM"-Domain (P1-Absender) um den Tenant eindeutig zu ermitteln.

In allen anderen Fällen nimmt Microsoft an, dass die Mail von außerhalb der Kundenumgebung kommt und daher als "Inbound" deklariert wird. Hier wird dann anhand der RCPT TO-Adresse (P1-Empfänger) der Tenant ermittelt und wenn es einen passenden Partner-Connector gibt, wird dessen Konfiguration z.B. hinsichtlich TLS-Zwang angewendet.

Hier nicht weiter betrachtet werden sollten Mail von einem OnPremises-Mailsystem, welche an einen Empfänger in ihrem Tenant gesendet werden. Kritisch sind Mails von ihrem lokalen Server, die über Exchange Online ins Internet gehen. Hier ändert sich etwas

Vor dem 1 Nov 2023

Bis zum 1. Nov 2023 hat Microsoft folgende Anforderungen an so eine Mail gestellt, die ich soeben schon beschrieben habe.


Quelle: https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/updated-requirements-smtp-relay#current-requirements

Damit eine Mail nicht nur dem richtigen Tenant zugeordnet wird, sondern auch über Exchange Online ins Internet geroutet wird, müssen beide Haupt-Kriterien und je eine der Unterkriterien erfüllt sein.

Wer genau hinschaut sieht, dass eine Einlieferung mit dem passenden Zertifikat schon beide Hauptkriterien erfüllt.

Nach dem 1 Nov 2023

Diese bisherige Regelung war aber Microsoft wohl zu freizügig und daher wurden diese seit dem 1. Nov 2023 schärfer gestellt.


https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/updated-requirements-smtp-relay#new-requirements

Genaugenommen wurde beim ersten Hauptkriterium der Punkt "c" entfernt. Ab sofort ist die Verwendung eines Absender aus einer eigenen Domain in der Mail selbst nicht mehr relevant.

Missbrauch möglich

Microsoft dürfte diese Änderung eingeführt haben, weil ein Anwender den Header relativ leicht selbst fälschen kann. "Gute Anwender" nutzen einfach Outlook, OWA, ActiveSync, um eine Mail zu schreiben und kümmern sich nicht um besondere Header. Exchange setzt dann den Absender in der Mail selbst (Header) auf den Benutzer und auch beim Versand per SMTP wird im Envelope die Absenderadresse des Benutzers verwendet.

Wenn Sie bei den Begriffen "Envelope" und "Header" unsicher sind, dann lesen Sie die Seiten Envelope und Header, SMTP P1/P2-Felder und weitere Seiten der MSXFAQ.

Auf jeden Fall kann ich eine Mail senden, in der ich den Header-From" auf eine andere Domain setze, die mir nicht gehört. Sollte dann ein andere Tenant z.B. einen OnPrem-Connector nicht über Zertifikate sondern IP-Adressen/IP-Subnetze abgesichert haben und die IP-Adresse z.B. hinter einem NAT-Router auch von mir verwendet werden könne, dann könnte ich an Exchange vorbei die Exchange Online Umgebung als Relay missbrauchen. Denken Sie ein eine Firma, deren Firewall ausgehend allen Clients Port 25 über NAT erlaubt und auch der OnPremises Exchange ausgehend zur Cloud diesen Weg nutzt.

Das mag konstruiert wirken aber es reicht schon eine Malware auf einem Client, der dann im Namen und mit DKIM-Signatur der Firma über Exchange Online das Internet als Relay erreichen kann. Ihre Firewall blockt vielleicht Port 25 ausgehend ins Internet für Clients aber haben sie nicht davor eine Regel, die ausgehende Verbindungen zu Exchange Online vielleicht etwas zu freizügig zulässt.

Wir können lange sinnieren, welche Fehlkonfigurationen und Lücken es noch geben könnte aber letztlich sind die Änderungen von Microsoft mittlerweile aktiv und wir richten uns besser danach oder bestimmte Mails werden einfach nicht mehr akzeptiert und mit einer Unzustellbarkeit abgelehnt.

Betroffene Systeme

Microsoft listet selbst einige Beispiele auf, die durchaus zutreffend sein können.

  • Unuzustellbarkeiten
    Eine Mail wird an eine Adresse gesendet, die der lokale Exchange Server bedient. Allerdings kann Exchange die Mail z.B. nicht zustellen, weil das Postfach voll ist, die Mailbox mittlerweile gelöscht wurde o.ä. Als Ergebnis stellt Exchange Online eine Unzustellbarkeit und bringt diese auf den Weg. Im Header kann hier durchaus postmaster@<ihrefirma> stehen aber im Envelope verwenden die meisten Server eine leere Adresse. Damit sagen sie der Gegenseite, dass Sie keine Rückmeldung auf eine Rückmeldung erwarten.
    Mit den neuen Einstellungen kann Exchange Online die Mail zwar annehmen, aber wenn sich ihr Server nicht über ein Zertifikat ausweist, dann treffen vom Hauptkriterium weder A (Zertifikat) noch B (Domain im Envelope MailFrom) zu. Die Mail wird von Exchange Online nicht als Relay ins Internet gesendet.
    Eine Lösung gibt es hier nicht
  • Eigene Mailsysteme
    Auch umgekehrt kann es passieren, dass ein von ihnen bislang betriebenes System Mails zustellt, und im Envelope eine Domain verwendet die Sie nicht in ihrem Tenant haben. Viele Mailinglisten oder Massenmailer nutzen eine Subdomain, z.B. info@news.<ihredomain>, die bislang nie in Exchange Online eingetragen wurde. Nur im Header wurde eine Domain ihrer Firma verwendet. Das reicht nun nicht mehr.
    Das Problem lösen Sie, indem entweder das Mailsystem eine eingetragene Domain im Envelope als Absender verwendet oder sie die Domain auch noch in ihrem Tenant eintragen
  • Cloud Dienste wie z.B. SMIME-Gateways, Disclaimer-Produkte, Journal
    Sie können solche 3rd-Party Lösung über Transportregeln und Connectoren einbinden. So landet eine Mail Richtung Internet zuerst einmal bei der 3rd-Party Software, die eine Signatur anbringt. Wen der Dienstleister die Mail dann aber nicht selbst versendet, dann routet er Sie z.B. wieder zu ihrem Exchange Online Server, der diese als Relay ins Internet weiterleitet. Das funktioniert nun auch nur, wenn der 3rd-Party Service ein pro Tenant individuelles Zertifikat nutzt, dessen Domain der Kunde auch noch im Tenant eintragen muss. Oder der 3rd-Party-Service verzichtet auf einen "falschen" Envelope-From, aber muss sich dann auch mit den Rückläufern auseinandersetzen.

Beste Option: Zertifikat!

Exchange Online leitet Mails eines OnPremises-System nur dann ins Internet weiter, wenn er sicher ist, dass der Absender zur Firma passt. Der beste Weg dies zu beweisen geht über ein Zertifikat, welches der einliefernde Server vorweist und zu einer Domain gehört, die im Tenant hinterlegt ist. Damit ist eine eindeutige 1:1 Zuordnung samt Verschlüsselung gewährleistet. Allerdings ist das Thema Zertifikate nicht bei allen Administratoren gerne gesehen, denn sie müssen jedes Jahr erneuert werden und kosten Geld, da sie von einer von Microsoft vertrauenswürdige PKI kommen.

Sie können natürlich weiter ohne Zertifikat und über die IP-Adresse arbeiten. Dann müssen Sie aber sicherstellen, dass der einliefernde Server im Envelope-Form eine Domain verwendet, die zu dem Tenant passt.

Zuletzt können Sie natürlich den Versand auch selbst organisieren. Sie müssen solche Mails nicht über Exchange Online ins Internet senden, sondern können selbst direkt per SMTP über den MX-Record versenden. Allerdinge müssen Sie dann die IP-Adressen per SPF zulassen und auch alle anderen Annehmlichkeiten von Exchange Online wie DKIM, Transportregeln etc. werden damit umgangen.

Weitere Links