DBEB mit Hybrid

Diese Seite ist für Konfigurationen interessant, die Exchange Hybrid konfiguriert haben und deren MX-Record auf Exchange Online verweist oder ein vorgelagerter Spamfilter keine Empfängerprüfung macht.

Umgebung

Damit Sie sich mit dem Thema beschäftigen müssen, muss ihre Konfiguration in eine der beiden Szenarien passen:

  • MX-Record zu Exchange Online
    Wenn Mails direkt zu Exchange Online (1) zugestellt werden, dann sollte sollte Exchange Online mit Directory Based Edge Blocking (DBEB) die ungültigen Empfänger ablehnen.
  • MX-Record auf 3rd-PartySpamfilter
    Verweist ihr MX-Record auf einen 3rd-Party Service (2), dann sollte dieser Service alle gültigen Empfänger kennen und ablehnen. Es gibt 3rd Party-Systeme, die mit "VERIFY" eine Verbindung zum nächsten System (3) aufbauen und prüfen, ob es den Empfänger dort gibt oder angenommen würde. Das ist möglich aber nicht ratsam, denn wie kann das System 3 erkennen, dass es ein legitimer Service ist und nicht ein Angreifer aus dem Internet, der einfach viele Adressen durchprobiert?

Auch Exchange OnPremises kann tatsächlich Empfänger beim SMTP-Empfang schon filter. Allerdings ist diese Funktion nicht per Default aktiviert. Microsoft geht davon aus, dass Sie einen Exchange Edge Server davor stellen. Sie können aber auch ohne Edge Server diese Empfängerfilterung aktivieren.

Fehlerbild

Ob sie ein Problem haben, können Sie schnell testen, indem Sie von extern eine Mail an eine "ungültige" Adresse in ihrem Unternehmen senden. Folgende Reaktionen sind dabei möglich.

Antwort Beschreibung Status

Ihr eigener Server sendet den NDR

In der Rückantwort sehen Sie meist, welcher Server die Unzustellbarkeit generiert hat. Wenn dies ihre Server ist, dann konnte er die Mail an den per MX-Record ermittelten Server nicht senden. Die Gegenseite lehnt direkt an. Das ist der Idealzustand.

OK

Exchange Online sendet einen NDR

 In dem Fall müssen wir davon ausgehen, dass die Mail bis zu Exchange Online gekommen ist aber angenommen wurde. Das kann nur de Fall sein, wenn Exchange Online entweder keine Empfänger mittels Directory Based Edge Blocking (DBEB) prüft oder der Empfänger zwar bekannt ist, aber Exchange Online dann die Mail nicht weiter zustellen kann. Sie sind nicht nur theoretisch ein Kandidat für NDR-Backscatter.

Schlecht

Exchange OnPrem sendet einen NDR

Die nächste Steigerung ist, dass Exchange OnPremises die Mail von Exchange Online über den Hybrid Connector annimmt und der lokale Transportdienst dann den Empfänger nicht findet oder der nächste Hop nicht erreichbar ist. Dann wir der Exchange Server einen NDR an den angeblich Absender erstellen

Schlecht

Genau der letzte Fall ist mir bei einem Kunden aufgefallen, als ich für andere Fragestellungen das Messagetracking durchsucht und viele NDRs gefunden habe. Sie können das gerne selbst bei sich auf dem Exchange Server einmal prüfen:

(Get-TransportService `
| Get-MessageTrackingLog `
   -Start (get-date).adddays(-1) `
   -ResultSize unlimited `
   -Eventid DSN `
).count

Der Wert stellt die Anzahl der erstellten NDRs innerhalb der letzten 24Stunden dar und sollte je nach Umgebung eine niedrige Zahl sein. Im Idealfall haben Sie gar keine NDRs, wenn die internen Mitarbeiter ihre Empfänger aus dem Adressbuch übernehmen und extern eingelieferte Mails schon beim SMTP-Empfang auf gültige Empfänger geprüft werden. Sicher wird es die ein oder andere DSN-Meldung geben wenn ein internes Skript Mails direkt per SMTP an ihren lokalen Exchange Server zustellt und der keine Empfängerfilterung gegenüber internen Servern macht.

Es soll Firmen geben, die diese NDRs gezielt auswerten, um Fehlkonfigurationen zu erkennen. So könnten Sie z.B. in der Vergangenheit bei einem Produkt, einer USV, einem Server eine Benachrichtigung per Mail eingerichtet haben und der Zielempfänger ist später nicht mehr gültig. Wenn niemand die NDRs bemerkt, dann verpassen sie vielleicht wichtige Informationen. Das würde dann nicht mehr gehen, wenn die Mail gar nicht erst angenommen wird.

Die DSN-Meldung geht zwar vom Postmaster an den Absender zurück aber in den EventData-Feld steht schon die Fehlermeldung, aus der Sie den Empfänger ermitteln können

[PS] C:\>| Get-MessageTrackingLog -resultsize 1 -Eventid DSN | fl recipients,MessageSubject,MessageInfo

Recipients      : {ups@msxfaq.local}
MessageSubject  : Undeliverable: UPS: The power is off.
MessageInfo     : '<invalid@msxfaq.de>:<550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address lookup>'

Ansonsten bleibt natürlich immer die Suche nach der Mail von dem Absender kurz vor dem DSN. So viele werden es ja nicht sein.

Ursache "Accepted Domain"

Auf der Suche nach der Ursache ist in dem Fall eine besondere Konfiguration im Tenant die Ursache. Sowohl in Exchange OnPremises als auch Exchange Online verwalten Sie die SMTP-Domänen, für die ihr Exchange Server "zuständig" ist. OnPremises geht das direkt in der Exchange PowerShell während sie bei Exchange Online zuerst die Domain in ihrem Tenant registrieren müssen. Sobald Sie in ihrem Tenant dann eingerichtet ist, erscheint Sie unter den AcceptedDomains und kann weiter konfiguriert werden. Meine Konfiguration sieht wie folgt aus:

Meine Domain ist "Autoritativ" und damit aktiviere ich das Directory Based Edge Blocking (DBEB) in Exchange Online um ungültige Empfänger direkt zu verhindern. Wenn Sie hier aber die Einstellung "internal Relay" aktivieren, dann schalten sie damit auch DBEB aus. Bei vielen Hybrid-Konfigurationen dürfte genau das zusammen mit einem Outbound-Conector für ihre Domain zum OnPremises Server der Fall sein. Über diesen Kniff können Sie den MX-Record für die Domain schon auf Exchange Online umstellen und interne Empfänger bleiben weiterhin erreichbar. Exchange Online hat damit für alle unbekannten Empfänger einen "Überlauf" zum dahinterliegenden Server. Microsoft schreibt dazu:

Authoritative: Email is delivered to email addresses that are listed for recipients in Microsoft 365 or Office 365 for this domain. Emails for unknown recipients are rejected.
Typically, you use this option when all the email recipients in your domain are using Microsoft 365 or Office 365. You can also use it if some recipients exist on your own email servers. However, if recipients exist on your own email servers, you must add your recipients to this Microsoft 365 or Office 365 domain in order to make sure that mail is delivered as expected.
Quelle: Manage accepted domains in Exchange Online
https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains

Die Umstellung auf "Internal Relay" bedeutet:

Internal relay (also known as non-authoritative): Recipients for this domain can be in Microsoft 365 or Office 365 or your own email servers. Email is delivered to known recipients in Office 365 or is relayed to your own email server if the recipients aren't known to Microsoft 365 or Office 365.
Quelle: Manage accepted domains in Exchange Online
https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains

Wechsel zu Authoritativ

Ich bin ein Freund davon, eine nicht zustellbare Mail so schnell wie möglich zu stoppen. Das erfolgt idealerweise auf den Systemen, auf die ihr MX-Record verweist. Dann kommt es gar nicht zu Irrläufern, die auf der Suche nach einem Empfänger durch ihre Mailsysteme laufen und am Ende die gleiche Anzahl an NDRs erzeugt, die auch wieder zu angeblichen Absender zurück gehen. Es gibt dabei natürlich auch den Nachteil, dass der Absender den Fehler auch nur sieht, wenn dieser die Rückläufer kontrolliert. Bei Kunden habe ich sehr oft gesehen, dass z.B. Newsletter, Zahlungssysteme etc. nicht ihre Mails an Verteiler oder generische Adressen senden, sondern an die Person, die bei der Einrichtung ihre Daten angeben musste. Sobald diese Person weg ist, kommen die Mails nicht mehr an.

Damit lokale Empfänger auch bei einem Empfang über Exchange Online erreichbar sind, sollten Sie zuerst prüfen, ob ADSync und andere Prozesse das Provisioning richtig im Griff haben. Ein "Get-Recipient" auf dem lokalen Exchange Server sollte mit wenigen Ausnahmen die gleichen Empfänger anzeigen, wie in der Cloud. Lokal gibt es nur ein paar Health/Monitoring/Systemaufsicht-Postfächer extra während Microsoft 365 Groups in der Cloud ohne Writeback auf dem lokalen Exchange Server meist nicht bekannt sind. Einen Vergleich können Sie z.B. mit Compare-GAL ausführen

Compare-GAL

Danach können Sie die Domain in Exchange Online zu von "Internal Relay" zu "Authoritative" umstellen, so dass Exchange Online ungültige Empfänger direkt ablehnt.

Weitere Links