MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

EXO Relay und falscher Tenant

Ich nutze diese Seite um ein Fehlerbild bei einem Kunden zu beschreiben, dessen Ursache aber beim Absender mit Exchange Online als ausgehendes Relay lag. Es ist ein gutes Beispiel, wie eine Konfiguration im Grunde funktioniert aber wie das Thema "Inbound Tenant Attribution" zu unerwarteten Fehlern führen kann. Viel Spaß bei der Denksport.

NDRs vom OnPremises-Exchange der Firma B

Der Administrator von Firma A hat mich zu einer Analyse von Unzustellbarkeiten hinzu gerufen, die er sich nicht erklären kann. Ein Postfach seiner Firma A sendet Mails an Firma B und bekommt einen NDR direkt an seinen Tenant zurück. Wir kennen die Topologie der Firma A aber noch nichts über Firma B. Ein Absender A@FirmaA bei Firma sendet eine Mail an ein PostfachB@FirmaB. Soweit ist dies erst einmal nicht ungewöhnlich. Allerdings kommt dann ein NDR von einem internen Exchange Server.

Erster Fehler: Anscheinend prüft der erste Mailserver bei Firma B nicht, ob die Empfängeradresse gültig ist, sondern alle Empfänger an und erst ein interner Server erkennt dann den Fehler

Wir haben dann den MX-Record von Firma B analysiert und dieser verweist direkt auf Exchange Online. Normalerweise blockt Exchange Online ungültige Empfänger, denn die Domains sind immer "Autoritativ" und wenn die Firma einen Hybrid-Mode hat, dann sollte ADSync ja dafür sorgen, dass alle noch lokal vorhandenen Empfänger auch in Exchange Online bekannt sind. Wenn es OnPremises ein 3rdParty Mailsystem gibt, muss man die dort gültigen Adressen in Exchange als MailContact, z.B. mit CSV2EXO oder CSV2Mailcontact anlegen.

Analyse des NDR Body

Exchange ist so freundlich und erstellt einen sehr aussagekräftigen NDR, in dem nicht nur die Fehlermeldung "Postfach nicht gefunden" sondern auch der generierende Server und der Laufwerk der Mail bis zu diesem Server in der Nachricht selbst protokolliert wird. So konnten wir aus der Ferne ermitteln, dass die Mail folgenden Weg genommen hat:

Die Mail startet bei dem OnPrem Server der Firma A (Server 2 und Mail A)

  1. Postfach in Firma A zum Mail-Relay (Server 3) Firma A
  2. Mailrelay Firma A liest MX-Record aus und sendet an den Exchange Online Tenant von Firma B (Server 4)
  3. Exchange Online Tenant von Firma B sendet vermutlich über einen Hybrid-Connector die Mail an die OnPremises Server (Server 5)
  4. OnPremises Server 5 erstellt einen NDR

Der Weg zum Server der Firma B ist nicht schön und viel zu lange aber erst mal nicht falsch und war im Messagetracking von Firma A bis zum Verlassen der eigenen Umgebung nachzuvollziehen.

Ich kann leider den NDR nicht veröffentlichen, da die Firmennamen nicht genannt werden sollen.

Analyse des NDR-Rücklaufweg

Firma A nutzt zwar auch Exchange Online aber der MX-Record verweist auf eine lokale Schutzlösung. Die Mails an die Domains von FirmaA landen nie direkt bei Exchange Online. Damit nun keine Spammer die lokale Lösung umgehen, möchte Firma A gerne die Hybrid Hintereingang/Exchange Online als Nebeneingang für Mailempfang schließen, indem Sie über einen Partner-Connector eine direkte Zustellung verhindern. Allerdings wurde vorher erst einmal geprüft, ob bereits Dienste diesen Weg nutzen und den MX-Record ignorieren. Es gibt tatsächlich einige Cloud Notification Mails, die den MX-Record ignorieren. Wir haben z.B. Nachrichten von Cloud Voice Mail und Teams-Benachrichtigungen von "no-reply@teams.mail.microsoft" gefunden, die wir auch nicht erwartet hätten.

Aber wir haben auch gesehen, dass die NDRs der Firma B bei uns direkt in den Tenant zugestellt worden sind und nicht den MX-Record genutzt haben. Das ist unerwartet und da wir den NDR selbst auch haben, konnten wir im Header des NDR auch den Rückweg durch die Systeme analysieren.

 Der Weg war:

  1. Firma B: Exchange OnPrem Server 5 generiert einen NDR und sendet die Mails an ein "mailing.<firmenname>.de"-Host (Server 6)
  2. Der "mailing.<firmenname>.de"-Host will die Mails zu Exchange Online (4) der Firma-B senden
  3. Allerdings klassifiziert Exchange Online die Mails als "Eingehend zu Tenant der Firma A (1)

Damit war schon einmal erklärt, wie der NDR angekommen ist aber nicht, warum er den MX-Record ignoriert hat. Wir kennen die Umgebung bei Firma B nun nicht auswendig aber ich habe folgende Vermutung:

  • Firma B nutzt Exchange OnPremises und Exchange Online in einer Hybrid Bereitstellung
    Im Message-Header sehen wir einige X-MSExchange-Header, die das bestätigen.
  • Firma B sendet alle Mails über Exchange Online, d.h. auch der lokale Exchange Server nutzt Exchange Online als ausgehendes Relay
    Im SPF-Record ist EOP addiert aber auch eine IP-Adresse von mailing.<firmenname>.de.
  • Ausgehend wurde dem "mailing.<firmenname>.de"-Host gesagt, dass er alle Mails zu Exchange Online senden soll
  • In Exchange Online sollte es einen "Inbound OnPremises Connector" geben
    Nur dann haben die lokalen Server auch das Recht mit einer Absenderdomain der Firma B über Exchange Online Mails ins Internet zu senden. So kann Exchange Online Protection auch ausgehende Mails auf Spam und Viren untersuchen und vor allem z.B. eine DKIM-Signatur anbringen.

Das sieht soweit nach einem korrekten Setup auf.

Der Fehler

Das ausgehende Mailrouting funktioniert so aber nur, wenn der Server "mailing.<firmenname>.de" beim Versand zu Exchange Online von Microsoft auch für den Tenant der Firma B als eingehend gewertet wird. Und da kommt wieder die Frage nach dem "Inbound Tenant Attribution". Exchange Online sieht bei einer eingehenden Verbindung erst einmal nur die IP-Adresse, ggfls. ein TLS-Zertifikat das sendenden Servers und dann die P1-Header "MAILFROM" und "RCPTTO". Anhand dieser Informationen muss Exchange Online dann ermitteln, ob es eine Mail aus dem Internet an den Tenant der "RCPTTO-Domain" als Ziel ist oder ob es eine Mail von einem OnPremises-Server mit einer MAILFROM-Adresse der eigenen Domains an den eigenen Tenant zur Weiterleitung ist. Hier hat Microsoft die Entscheidungslogik sehr gut beschrieben:

In Kurzform:

  1. TLS-Zertifikat passt zu "Inbound OnPremises Connector" mit Name und Domain
    Exchange Online sucht in allen Tenants nach einem Imbound OnPremises Connector, zu dem das TLS-Zertifikat des Absenders passt und die Domain des Zertifikats zum Tenant gehört. Dies ist ein sehr leistungsfähiger und stabiler Test und immer meine Empfehlung. Allerdings muss man sicherstellen, dass das Zertifikat des einliefernden Server nie andere Server verwenden. Wildcard-Zertifikate sind besonders kritisch. Siehe auch Hybrid RoutingFail.
    Dieser Check scheint in dem Problem nicht funktioniert zu haben, denn die Mail wurde ja eben nicht an den Tenant der Firma B sondern direkt den Tenant der Firma A gesendet.
    Mögliche Ursachen könnte ein abgelaufenes oder falsch erneuertes oder nicht gebundenes Zertifikat beim Absender sein.
  2. MAIL FROM und IP-Adresse
    Wenn über das Zertifikat kein Connector gefunden wird, dann nutzt Exchange Online die Domain des Absenders, um den Tenant zu bestimmen und darin dann nach einen OnPremises-Connector zu suchen, der auf die IP-Adresse gebunden ist.
    Auch das trifft hier nicht zu, da die Mails auch nicht anhand der IP-Adresse dem Tenant von Firma B zugeordnet wurde. Vielleicht hat an der Firewall jemand  geschraubt, so dass der OnPremises Server ausgehend nun eine andere NAT-Adresse bekommt.
  3. Alles andere ist Inbound an den Tenant der RCPT TO-Domain
    Da Fall 1 und Fall 2 nicht zutreffen, betrachtet Exchange Online die Mail als "Eingehend" zu dem Tenant, dem die Empfängerdomain gehört. In diesem Fall sind Firma A und Firma B auch in der gleichen Geo-Region, so dass die Smarthost-Einstellung glücklicherweise zum gleichen Stack führt. Die Mail wird aber direkt bei Tenant der Firma A als eingehend angenommen.

Wir haben diese Informationen an Firma B gegeben und schauen mal, ob sie den Fehler bei sich finden und wie sie in korrigieren.

Szenarien

Um ihre Denksportaufgabe noch etwas abzurunden, können Sie ja mal folgende Fälle durchdenken und die Beschreibung erst einmal abdecken:

Absender Ziel Ziel Beschreibung

Firma B Cloudpostfach

 Firma B Cloud
Firma B OnPrem
Internet

Diese drei Fälle funktionieren alle, da die Mail von Exchange Online der Firma B direkt über das Routing versendet werden und nicht über den "Inbound OnPremises-Conector" kommen.

Firma B OnPrem Absender

Firma B Cloud

Wenn das Hybrid Setup noch vorhanden ist, dann gibt es neben dem Inbound OnPrem Connector für den Server "mailing.<domain>" auch noch den regulären Hybrid-Connector, der direkt die Exchange Server verbindet und daher die Mails als "intern" ankommen.

Gibt es den Connector aber nicht oder funktioniert er nicht, dann kommen die Mails vermutlich dennoch an, da "mailing.<domain>" im SPF-Record ist und Exchange Online dann die Mails als "von Extern" ansieht. Spamfilter und Phishing-Schutz können zuschlagen und die Empfänger in Exchange Online sehen als Absender auch die SMTP-Adresse und nicht nur den Displayname. Das ist ein deutlichen Zeichen, dass die Mail als "anonym" angekommen ist.

Firma B OnPrem Absender

Firma B OnPrem Postfach

Alles von OnPremises nach OnPremises kommt bleibt OnPremises und wird nicht über "mailing.<domain>" geroutet.

Firma B OnPrem Absender

Firma A in anderer Geo-Region

Das "mailing.<domain>" per Smarthost alle Mails an die Geo-Region des Tenants von Firma B sendet, können Mails an Tenants in anderen Geo-Regionen nicht zugestellt werden. Exchange Online lehnt diese Mails ab.

451 4.4.62 E-Mail an die falsche Office 365 Region gesendet. ATTR35.

Firma B OnPrem Absender

Firma A ohne Tenant mit MX-Reord auf lokales System

Wenn Firma B eine Mail an eine Domain sendet, für die es überhaupt keinen Tenant in Exchange Online gibt, dann wird Exchange die Mail direkt ablehnen.

Firma B OnPrem Absender

Firma A in gleicher EXO Georegion und offenen Hintereingang

Die Mail kommt an, wenn Firma A und Firma B in der gleichen Georegion liegen

Firma B OnPrem Absender

Firma A in gleicher EXO Georegion und ohne Hintereingang

Exchange Online wird die Mail ablehnen und "mailing.<domain>" könnte den internen Absender darüber informieren. Wenn es aber, wie in diesem Fall, schon eine NDR-Meldung ist, wird diese einfach unbemerkt gelöscht

Wir haben in dem Support-Case nur den einen Fall gehabt, dass eine Mail von Firma B OnPrem nicht zum Tenant von Firma B und dann weiter über den MX-Record zu Firma A geroutet wurde, sondern irrtümlich direkt dem Tenant von Firma A zugestellt wurde. All die anderen möglichen Fehler hat die Firma B scheinbar noch gar nicht bemerkt.

Lernkurve

Wer Mails ins Internet sendet, sollte auch den Versandweg prüfen und vor allem die Verbindungen zwischen Servern über Smarthosts genau beobachten. Insbesondere wenn Sie Mails von ihrem OnPremises System über einen Smarthost an einen Nexthop senden, der nicht ihnen alleine gehört, sondern eine Shared Umgebung ist, dann muss die Gegenseite ihren Server eindeutig und zuverlässig erkennen können. Das gilt nicht nur bei einem Relay über Exchange Online. Auch die Nutzung anderer cloudbasierter Spamfilter und Relay-Dienste unterliegen diesem Risiko. Ob das Relay nun die IP-Adresse und MAILFROM-Information oder ein TLS-Zertifikat auswertet, ist für die Funktion nicht weiter relevant. Es muss nur zuverlässig funktionieren.

Firma B ist eine durchaus namhafte und größere Firma, die sicher sehr viele Mails versendet. Ob hier der Weg über Exchange Online sinnvoll ist (siehe auch TERRL - Tenant External Recipient Rate Limit) bewerte ich nicht. Aber bei der Überwachung könnte man schon einmal prüfen, ob man Testmails an die verschiedenen externen Gegenstellen sendet und die Zustellung verifiziert.

Weitere Links