Directory Based Edge Blocking (DBEB)

Exchange Online akzeptiert für eine eigene autoritative Domain trotzdem auch ungültige Empfänger und sendet einen NDR an den vorgebliche Absender. ich beschreibe, warum das so ist und wie sie es abschalten, nachdem Sie natürlich sichergestellt haben, dass wirklich alle Empfänger auch in der Exchange Online GAL vorhanden sind.

Standardkonfiguration

Ich konnte es auch erst einmal nicht glauben, denn das Ablehnen von ungültigen Empfängern gehört doch zu guten Ton eines korrekt konfigurierten Mailserver. Wenn sich ein legitimer Absender bei der Adresse verschreibt, dann bekommt er eine Unzustellbarkeit von seinem eigenen System und das Zielsystem muss keinen NDR an den angeblich Absender erstellen. Da gibt es nämlich das Risiko, dass der Absender gefälscht ist und man selbst zum NDR-Spammer wird. Natürlich verrate ich damit dem Spammer welche Adressen ungültig sind aber das bekommt er über den NDR auch heraus oder es interessiert ihn eh nicht. Ich verliere also nichts, wenn ich eine Mail ablehne, die ich eh nicht zustellen kann. Siehe auch Spam und UCE - gültige Empfänger.

Erfahrene Exchange OnPremises Administratoren wissen sicher, dass bei Exchange OnPremises diese Funktion im Standard auch erst einmal abgeschaltet ist und manuell aktiviert werden muss (Siehe E2013 Recipient Filter), denn OnPremises hat Microsoft eine Exchange Edge Server für diese Aufgabe vorgesehen. Bei Exchange Online ist die Empfängerfilterung "vielleicht" aktiv. Dazu habe ich zwei Tests mit einem unverfälschten Tenant gemacht (Stand Fab 2023)gemacht. In Diesem Tenant gibt es zwei Domains

Passend dazu gibt es auch Cloud-Only-Benutzer und ADSync-Benutzer mit Postfächern in der Cloud: Die Domains sind in Exchange Online alle als Autoritativ gelistet:

Zur Sicherheit habe ich noch beide Domänen per PowerShell "Get-AcceptedDomain" (https://learn.microsoft.com/en-us/powershell/module/exchange/get-accepteddomain) ausgegeben:

Einstellung msxfaqdev.onmicrosoft.com msxfaq.net 
DomainName                      
CatchAllRecipientID             
DomainType                      
MatchSubDomains                 
AddressBookEnabled              
Default                         
EmailOnly                       
ExternallyManaged               
RawAuthenticationType           
AuthenticationType              
LiveIdInstanceType              
PendingRemoval                  
PendingCompletion               
FederatedOrganizationLink       
MailFlowPartner                 
OutboundOnly                    
PendingFederatedAccountNamespace
PendingFederatedDomain          
IsCoexistenceDomain             
PerimeterDuplicateDetected      
IsDefaultFederatedDomain        
EnableNego2Authentication       
CanHaveCloudCache               
SendingFromDomainDisabled       
InitialDomain                   
AdminDisplayName                
ExchangeVersion                 
Name                            
Identity                        
OrganizationalUnitRoot          
Id                              
msxfaqdev.onmicrosoft.com

Authoritative
False
True
False
False
False
Managed
Managed
Business
False
False
Federation

False
False
False
False
False
False
False
False
False
True

0.20 (15.0.0.0)
msxfaqdev.onmicrosoft.com
msxfaqdev.onmicrosoft.com
msxfaqdev.onmicrosoft.com
msxfaqdev.onmicrosoft.com
 
msxfaq.net

Authoritative
False
True
True
False
False
Managed
Managed
Business
False
False
Federation

False
False
False
False
False
False
False
False
False
False

0.20 (15.0.0.0)
msxfaq.net
msxfaq.net
msxfaqdev.onmicrosoft.com
msxfaq.net

Die meisten Einstellungen sind hier also identisch. Nur die Einstellungen bei "InitialDomain" und "Default" sind unterschiedlich. Für die Domain "msxfaq.net" möchte Microsoft, dass ich folgenden MX-Record addiere:

Das kann ich machen, aber ich kann auch darauf verzichten, wenn ich beim Versender den Hostnamen direkt angeben. Per CURL sende ich nun Mails an die Domains.

Achtung: Prüfen Sie die Rückgaben genau, CURL zeigt nicht immer den kompletten Antwortstring sondern nur den Fehlercode an und es könnte sein, dass ihre Source-IP, z.B. auf einer RBL-Liste steht. Relativ sicher sind solche Tests von einer Azure-VM oder hinter einer statischer IP-Adresse.

Einstellung msxfaqdev.onmicrosoft.com msxfaq.net

Versand mit CURL aus einer CMD-Shell

 
curl smtp://msxfaq-net.mail.protection.outlook.com ^
   --mail-from frank@example.com ^
   --mail-rcpt invalid@msxfaqdev.onmicrosoft.com ^
   --upload-file body.txt

 
curl smtp://msxfaq-net.mail.protection.outlook.com ^
   --mail-from frank@example.com ^
   --mail-rcpt invalid@msxfaq.net ^
   --upload-file body.txt

Ergebnis

Wird mit "RCPT failed: 550" abgewiesen

Wird angenommen

SMTP Ergebnis

 
550 5.4.1 Recipient address rejected: Access denied. AS(201806281)
 
250 2.6.0 ....Queued mail for delivery

WireShark-Trace

Obwohl beide Domain im Tenant gleich konfiguriert und insbesondere als "autoritativ" geführt werden, verhalten Sie sich bei der Empfängerprüfung unterschiedlich. Die für "invalid@msxfaq.net" angenommene Mail findet sich sogar im Messagetracking samt der erzeugten und zurückgesendeten NDR-Meldungen.

Sie sehen auch dass anscheinend ein paar Spammer wohl Mailadressen auf der msxfaq.de einsammeln und ausprobieren. Genau das ist aber das große Risiko, dass jemand z.B. eine Absenderadresse fälscht und massenhaft Mails zu Microsoft sendet, auf die Microsoft dann einen NDR an den vorgeblichen Absender zurücksendet.

Empfängerfilterung aktivieren

Warum Microsoft nur auf der eigenen Domain diese Empfängerfilterung bei Empfang aktiv hat, kann ich nur vermuten. Es mag ja Firmen geben, die eine Domain nicht nur bei einem System hosten, sondern weiterleiten. So ist es durchaus denkbar, dass eine Firma alle Mails zu Exchange Online sendet und über einen Outbound-Connector alle nicht zugestellten Mails zum nächsten Server weiterleitet. So kann man sich sie Mühe ersparen, in Exchange Online z.B. über Kontakte die Adressen richtig zu routen. Diese Funktion wird von Exchange sogar schon immer unterstützt, indem Sie eine Domain als "Internal Relay" konfigurieren können.

Ich rate von der Verwendung eines "Eimerkettenroutings" ab, da es Loops erzeugen kann und keine sichere Zustellung darstellt. Der erste Server einer Domain, der die Mails aus dem Internet annimmt, sollte eine Liste der gültigen Empfänger und deren finales Zielsystem kennen, optimiert routen und ungültige Empfänger direkt ablehnen.

Wenn Sie nun aber die Funktion auch für eigene Domains aktivieren wollen, dann gibt es auf Microsoft eine etwas ungewöhnliche Beschreibung.

Die Anleitung beschreibt es ziemlich unerwartetes Vorgehen.

Aktivieren Sie Schritt 3 erst, wenn Sie sicher sind, dass alle Empfänger auch wirklich in Exchange Online bekannt sind. Denken Sie auch an Objekte, die im Hybrid Mode durch ADSync vielleicht aufgrund der Konfiguration noch nicht synchronisiert werden, z.B. öffentliche Ordner, dynamische Verteilerlisten.
Siehe dazu auch Compare-GAL.

  1. Domain als "Internal Domain" setzen
    Zuerst werden Sie darum gebeten, die Domain als "Internal Relay" zu setzen
  2. Empfänger addieren
    Dann sollte man sicherstellen, dass alle Empfänger auch in der Exchange Online GAL vorhanden sind, z.B.: durch ADSync, als Kontakte o.ä.
  3. Domain als "Autoritative" setzen
    Damit wird Exchange dann angewiesen, dass er alle Empfänger kennt und alle anderen abgewiesen werden

Achtung: Die Änderung wird quasi sofort aktiv. Bei mir hat die Umstellung von "internal Relay" auf "authoritative" nur weniger Sekunden benötigt.

Microsoft weist dabei aber selbst darauf hin, dass die Liste der Empfänger in Exchange Online nicht immer von alleine vollständig ist. Das betrifft z.B.

  • OnPremises:Dynamische Verteiler
    Diese werden von ADSync nicht als Kontakte ins AzureAD und damit Exchange Online repliziert. Sie müssten dafür manuell Kontakte anlegen
  • OnPremises: Mailaktivierte öffentliche Ordner
    Auch diese Objekte werden von ADSync ignoriert und sie müssen entsprechende Kontakte anlegen.

Die Filterung durch Exchange Online funktioniert natürlich nur, wenn der MX-Record auch zu Exchange Online gesetzt wird.

Mit der Umschaltung einer Domain von "Internal Relay" zu "Authoritative" wird dann die Filterung per DBEB aktiv. Also habe ich die Domain im Exchange Admin Center erst auf "Internal Relay" gestellt

Achtung: Die Funktion das Relay auf Unterdomains zu erweitern gibt es nicht bei "Autoritativ" Wenn Sie z.B. ihre Teams-Adressen auf eine Subdomain umlenken, dann können Sie die Filterung nur auf die Hauptdomain konfigurieren.

Kontrolle

Dass die Änderungen greifen, können Sie wieder mit einer Test-Mail an einen ungültigen Empfänger prüfen.

curl smtp://msxfaq-net.mail.protection.outlook.com ^
   --mail-from frank@example.com ^
   --mail-rcpt invalid@msxfaq.net ^
   --upload-file body.txt

Diesmal wird auch diese Mail mit einem "550" abgelehnt, die vorher noch angenommen wurde

Natürlich finden Sie diesen "Versuch" dann auch nicht mehr im Messagetracking. Ich habe natürlich mit "Get-AcceptedDomain" noch einmal die Daten der Domain ausgelesen aber bist auf das "LastModified"-Feld hat sich nichts sichtbar geändert.

Ich habe bislang keinen Weg gefunden, eine aktive DBEB-Filterung zu erkennen. Wenn Sie diese aber abschalten wollen, dann stellen Sie die Domain einfach wieder auf "internal Relay" um.

Zurückstellung

Ich kennen keinen einfachen Weg, die Ausgangssituation wieder herzustellen. Aber das müssen wir auch gar nicht, denn nun verhält sich eine "authoritative Domain" auch wirklich so, wie ich es von Anfang an erwartet hätte: Sie lehnt ungültige Empfänger ab.

Wenn ich das Verhalten aber wieder abschalten will, dann brauche ich die Domain einfach auf "Internal Relay" zuzustellen Exchange nimmer dann Mails für jeden Empfänger dieser Domain an und versucht sie intern neu zuzustellen. Allerdings weist mit zumindest die PowerShell bei der Umkonfiguration auf einen wichtigen Sachverhalt hin:

PS C:\> set-acceptedDomain msxfaq.net -DomainType internalrelay
WARNING: Es ist kein ausgehender Connector vorhanden, der E-Mail für diese Domäne zustellt. 
Vergewissern Sie sich, dass ein ausgehender Connector vom Typ \"OnPremises\" vorhanden ist, 
der jede akzeptierte "interne Relaydomäne" zuordnet. Für den Connector kann entweder das 
Flag \"AllAcceptedDomains\" aktiviert sein, oder er verfügt über eine Empfängerdomäne, 
die mit der akzeptierten Domäne übereinstimmt.

Ich sollte Exchange Online schon einen Weg zeigen, wohin er Mails an solche nicht vorhandene Empfänger weiter sendet. Ein entsprechender Outbound-Connector mit dem eigenen Adressraum oder auch mit einem "*" als Adressraum sollten Sie auf jeden Fall anlegen, damit die Mail nicht im Kreis läuft oder NDRs erzeugt.

Im Exchange Admin Center (https://admin.exchange.microsoft.com) bekommen Sie diesen Hinweis nicht!

Wenn Sie unbedingt wieder den Ausgangszustand herstellen wollen, dann könnten Sie natürlich die DNS-Domain im Tenant entfernen und wieder neu hinzufügen. Aber das erscheint mir unsinnig.

Bonus

Da ich mehr als einen Tenant habe, habe ich die Tests auf einem zweiten Tenant wiederholt. Dessen Konfiguration ist etwas umfangreicher und hat vier Domains, die alle "authoritative" sind.

Ich hätte hier erwartet, dass ungültige Empfänger direkt abgelehnt werden. Da die Domains aber schon einige Jahre verbunden sind und es offensichtlich auch schon einen Exchange Hybrid Mode gegeben hat, habe ich ich mit TELNET auf fcedv-de.mail.protection.outlook.com und Port 25 verbunden und sowohl mit RCPTTO als auch VRFY verschiedene Mailadressen ausprobiert

Test Ergebnis Ergebnis Bewertung 
rcpt to: invalid@fcedv.de
 
250 2.1.5 Recipient OK

Hier hätte ich erwartet, dass Exchange Online die Mail an eine ungültige Adresse gar nicht annimmt

 
rcpt to: invalid@carius.onmicrosoft.com
 
550 5.4.1 Recipient Address Rejected

Die native Microsoft Domain ist wohl "geschützt"

 
rcpt to: invalid@carius.mail.onmicrosoft.com
 
250 2.1.5 Recpient OK

Die Exchange Hybrid Domain aber wieder nicht

 
rcpt to: invalid@carius.de
 
550 5.4.1 Recipient Address Rejected

Die "carius.de"-Domain ist aber versichert. Ich vermute mal, dass ich hier mit "InternalRelay" und "Authoritative" im Rahmen der Hybrid Bereitstellung gespielt habe.

 
rcpt to: valid@carius.de
 
250 2.1.5 Recpient OK

Eine gültige Adresse wird natürlich angenommen.

 
vrfy invalid@carius.de
vrfy valid@carius.de
vrfy invalid@carius.onmicrosoft.com
vrfy invalid@carius.mail.onmicrosoft.com
 
252 2.1.5 cannot VRFY user

Der Versuch per VRFY die Adresse zu prüfen wurde für gültige und ungültige Adressen immer mit der gleichen Meldung abgelehnt. Microsoft hat das VRFY-Kommando wohl nicht implementiert aber quittiert dies nicht mit einem "502 5.5.1 Command not implemented". Ein schlecht programmierter Mailserver, der vor dem Versand mit VRFY nachfragt, würde hier nicht weiter machen. Allerdings wüsste ich grade keinen SMTP-Server außer CURL, der so etwas macht.

Sie sehen hier, dass Microsoft das VRFY-Kommando anscheinend nicht implementiert hat aber die Rückantwort suggeriert ein "Benutzer nicht gültig". Die native "<tenantname>.onmicrosoft.com ist geschützt aber die Hybrid-RoutingDomain (MOERA) ist ebenfalls nicht gegen ungültige Empfänger gesichert.

Ich habe die Tests dann auch gegen einige andere Tenants von Kunden gemacht und ein ähnliches Bild gesehen. Es waren sogar einige recht große Firmen darunter, die über ihre "onmicrosoft.com"-Adresse ungültige Empfänger annehmen und entsprechende NDRs versenden.

Zusammenfassung

Ich finde es suspekt, wenn Microsoft eine neue Domain als "Authoritative" einträgt aber dann keine Empfängerfilterung per Default aktiviert. Für mich bedeutet das doch, dass es vermutlich sehr viele Tenants mit eigenen Domains gibt, die beliebige Empfänger erst einmal annehmen und Unzustellbarkeiten senden. Wer hat schon die Einstellung pro Domain einmal hin und her gewechselt? Nur Kunden mit NoSpamProxy oder anderen vorgelagerten Filtern, die zudem den Exchange Online als Nebeneingang oder Hybrid Hintereingang über einen "Inbound Connector" von diesem Partner abgesichert haben, sind davon nicht betroffen.

Mich irritiert, dass die beiden Verhaltensweisen einer "Authoritative Domain" nicht per PowerShell irgendwo ausgelesen werden können und Microsoft überhaupt die Funktion nicht gleich an den Status "Authoritative" koppelt. Für die eigene <tenantname>.onmicrosoft.com-Domain ist der Schutz ja auch per Default aktiv.

Wenn Sie aber eine eigene Domain immer noch ungültige Empfänger annimmt, dann sollten Sie sicherstellen, dass alle Empfänger in Exchange Online bekannt sind (Get-Recipient) und dann die Einstellung von "Authoritative" auf "internal Relay" und wieder zurück auf "Authoritative" stellen.

Weitere Links