Kurze Rundfrage an Administratoren von Microsoft 365-Installationen. Taucht bei euch auch das Problem auf, dass Rückmeldungen eintreffen, dass Mails aus Office 365 wegen DMARC-Fehler nicht ausgeliefert werden können und dann die Antwort mit dieser Status-Meldung beim Admin aufschlägt? Zudem möchte ich noch einige offene Punkte in Verbindung mit Mails und Exchange Online aufgreifen (die z.B. durch den kürzlich Ausfall des Dienstes aufgetreten sind). Der Ausfall am 1. März 2023, den Microsoft als EX522020 beschrieben hat, dürfte bei einigen Kunden zu nicht zugestellten Mails geführt haben.
Anzeige
DMARC verhindert Mail-Zustellung
Microsoft unternimmt ja verstärkte Anstrengungen zur SPAM-Abwehr und Verifizierung von Mails, die von einer Domain ausgehen. Mit DMARC ("Domain-based Message Authentication, Reporting & Conformance) existiert ja ein Framework zur E-Mail-Authentifizierung samt Reporting bei Problemen. Auf Twitter ist mir gerade folgender Tweet untergekommen:
Ad-hoc würde ich auf eine fehlerhafte Konfigurierung tippen, denn der Hinweis "Sender IP-Adresse ist nicht im SPF-Protection deutet auf so etwas hin. Microsoft hat dazu den Beitrag Verwenden von DMARC zum Überprüfen von E-Mails veröffentlicht, der beschreibt, wie DMARC für Office 365 einzurichten ist. Aber trotzdem in diesem Zusammenhang die Frage an die Leserschaft, ob sich was geändert hat und diese Meldungen nun verstärkt auftreten?
Handeln nach Exchange Online-Ausfall vom 1. März 2023
Zum 1. März 2023 gab es einen mehrstündigen Ausfall von Microsoft Exchange Online – ich hatte dies am Rand im Beitrag Microsoft 365 und Twitter "rumpeln" (1. März 2023) – jetzt auch Exchange Online angesprochen. Microsoft hatte ein Problem auf Twitter eingestanden – und Blog-Leser Andreas P. hatte mir die Statusmeldungen zur Verfügung gestellt:
Anzeige
Published Time: 01.03.2023 21:58:06
Title: Users may be unable to access their Exchange Online mailbox or send/receive messages
User impact: Users may have been unable to access their Exchange Online mailboxes or send and receive email messages.
More info: Users may have received an error message including: "550 5.4.1 Recipient address rejected: Access denied" when attempting to send or receive messages.
Final status: We've confirmed that rerouting EOP traffic away from the affected portion of infrastructure has successfully resolved the user impact.
Scope of impact: Impact was specific to users who are served through the affected infrastructure in North America, Europe, and the United Kingdom.
Start time: Wednesday, March 1, 2023, at 1:02 PM UTC
End time: Wednesday, March 1, 2023, at 8:20 PM UTC
Preliminary root cause: A portion of Exchange Online Protection (EOP) infrastructure wasn't operating as expected due to a potential misconfiguration, resulting in the impact.
Microsoft hat für betroffene Administratoren zusätzliche Informationen im Statusbereich zum Ausfall veröffentlicht. In der Regel heißt es in den Kommentaren hier im Blog bei einem solchen Ereignis schulterzuckend "kommt vor, kann man nix machen, war auch nur kurz und On-Premises ist es auch nicht besser".
Lasse ich gerne im Raum stehen – aber ich hätte noch was aus den Weiten dieses Universums, welches sich Administratoren von Exchange Online-Instanzen vielleicht doch zu Gemüte führen sollten. Wenn ich so intergalaktisch unterwegs bin, sehe ich ja so einiges. Der Ausfall am 1. März 2023, den Microsoft als EX522020 beschrieben hat, dürfte einige Kunden erwischt haben, bei denen Mails nicht zugestellt wurden. In diesem Zusammenhang ist mir dann auch der nachfolgende Tweet von Frank Carius vom 5. März 2023 aufgefallen, den ich vor dem 30. März 2023 hier im Blog gepostet haben wollte – daher kippe ich den hier mit rein.
Frank hat sich diesen Exchange Online-Ausfall aber genauer angeschaut, weil ein Kunde sich beschwert hat, weil eine wichtige Mail nicht angekommen ist. Normalerweise ist es ja kein Problem, nicht zustellbare Mails werden irgendwie protokolliert und Administratoren können dann reagieren. Aber der Teufel steckt im Detail, wie Frank Carius schreibt. Ich zitiere mal aus seinem Beitrag:
Die Mails sind aus dem Internet über einen Spamfilter bei einem Exchange Edge Server gelandet. Der Edge Server hat diese Mails dann zum internen Mailbox-Server gesendet. Da die Mailbox aber schon in Exchange Online lag, hat der Exchange Server die TargetAddress umgeschrieben und die Mail wieder über die Edge-Server mittels "Hybrid Bereitstellung" zum Exchange Online Server senden wollen. Bis zum eigenen Edge Server ist die Mail noch gelaufen aber dann wurde sie von Exchange Online abgelehnt.
Frank war per PowerShell in der Lage, dieses Bouncing per PowerShell im Edge-Server des Kunden ermitteln. Die Gegenstelle war ein Exchange Online Server, der die Benachrichtigung mit "550 5.4.1 Recipient address rejected: Access denied" ablehnte. Frank hat sich dann mal die Mühe gemacht, und untersucht, wie arg sich der Exchange Online-Ausfall vom 1. März 2023 auf den Kunden auswirkte und wie viele Mails verloren gegangen sind. Nach der Analyse tangierte die Störung den Kunden 4 bis 5 Stunden und in diesem Zeitraum waren doch ca. 2655 Mails betroffen. Frank schreibt zum Ergebnis der Analyse "Microsoft hat in der Zeit also mehr als 1/3 der Mails abgelehnt, die eigentlich zugestellt werden sollten." und zeigt detailliert auf, wie er das Ganze per PowerShell analysiert hat.
Der Beitrag von Frank Carius könnte für Exchange Online-Administratoren wegen der dort gegebenen Details ganz hilfreich sein, zumal sich dort die Information "Wenn sie diese Seite noch vor dem 31. März 2022 lesen und ihr Exchange Server per Default die Daten für 30 Tage vorhält, dann nutzen Sie doch einfach mal folgenden Code, um den Einfluss auf ihr System zu ermitteln." findet.
Anzeige
Bisher keinerlei Probleme.
Einige Kollegen bei uns erhielten letzte Woche Fehlermails von Google Mailservern, als sie versucht hatten, über unsere Microsoft 365 Mailkonten E-Mails an verschiedene Gmail-Adressen zu versenden. Google wies unsere Mails ab wegen fehlender DMARC-Einträge, SPF records sind bei uns aber vorhanden. Anscheinend genügt das seit Neuestem nicht mehr?
Mal eine Frage in die Runde: Ich bekomme seit dem vorletzten Exchange 2019-Update (onprem) vermehrt Outlook-Passwortanmeldungen angezeigt.
Betroffen sind alle Anwender. Die üblichen Hilfen und Registrykeys sind gesetzt, die Outlook-Profile sind neu aufgebaut. Der Cache-Modus ist deaktiviert.
Hat sich in Verbindung mit Autodiscovery etwas geändert? Denn – in der Outlook-Verbindungsstatus-Übersicht sind alle Verbindungen aktiv.
Gruß, Christian
Das in diesem Artikel Fix für Verbindungsprobleme mit Microsoft 365 Anwendungen (März 2023) angerissene Problem lässt sich ausschließen?
Ich habe öfters mal, dass wir Mails von Kunden-Tenants ablehnen, da die Kunden DKIM im Tenant aktiviert haben. Sie haben auch die CNAMEs auf Microsofts Public-DNS angelegt, aber dort werden die DNS-Records schlicht nicht erstellt:
selector1/selector2-"Tenantkürzel"-._domainkey."Tenantname".onmicrosoft.com sind leer.
In der Sophos Firewall werden seit heute Mails aus dem Office365 Land mit [pubkey_unaviable] oder [bodyhash_mismatch] abgelehnt.
Früher haben wir das per Telnet gemacht.
Darum trägt das Protokoll ja das "S" wie "Simple" im Namen.
Ach mist. Telnet hat MS ja aus "Sicherheits"gründen von den Kisten geschmissen.
Naja, der SSH-Client kann es auch, sogar besser.
(Es gibt aber gestörte Firewalls Admins, deren Firewall prüft, ob auf der Gegenseite ein Telnet ist. Wie traumatisiert muß man sein, so eine Regel einzuführen?
Hallo?
Und morgn blocken wir ICMP. Braucht eh niemand und es gibt wieder man einen
Ping-of-death, nein besser, ping-for-remote-control für sämtliche Windows-Kisten seit 2008, auch die die man nicht mehr patchen kann.
SO macht sich Umsatz! Bravo MS!
Leute, das war ein Scherz.
Last das ICMP an!
Das braucht man auch für andere Sachen auser Ping!
Z.B. um Verstopfungen zu melden
"weil eine wichtige Mail nicht angekommen ist"
Email ist KEIN Echtzeit Medium, das ist "store and forward".
Eine eMail darf auch schon mal ne Woche rumliegen, wenn der Postmaster des Empfängers zugelassen hat (Heut eher unüblich, weil die User denken, das emai
"Echtzeit" sein)
Aber, aaanz wichtig:
Email kann nicht "verloren gehen".
Die muß "irgendwo" angekommnén sein,
Wer sie angenommen hat, ist für die Zustellung verantwortlich!
Ich kann nur davor warnen, Bounce-Emails zuverschocken.
Man landet dann ganz schnell auf einer "Back scattering" Blacklist,
weil Spammer mit Absicht eMails an unbekannte Empfänger verschicken,
damit der Bounce, leider oft genug mit der Kompletten eMail, bein eigentlichen Opfer landet. Und was macht dessen Postmaster? Dumpt alle Bounce Mails.
Was tun?
Natürlich an der vordesten Front prüfen, ob man den Empfänger kennt, ob man überhaut zustellen könnte. Man ist ja für die eMail, die angenommen hat verantwortlich.
Und nicht, wie Barracuda das macht, allen Müll mit einer dicken Leitung und dicken Server annimmt (damit schön viel mail ist, achne, um DOS zu verhindern…), Spam und virenfiltert und den -riesigen- Rest dem Kunden in den Excahnge steckt. Der dafür teuer bezahlen muß und oberdrein noch auf einer schwarzen Liste wg. Back scattering landet, wenn er, korrekt, Bounces versendet.
Man begrenzt also die Bandbreite des SMTP Servers.
Aber der Spam!!! Ja, die Spammer sind nicht doof, die Nutzen nur soviel von der Bandbreite das etwas übrig bleibt. D.h. je dicker der Server/Leitung um so größer wird der Spamanteil. Baracuda&Co. kommt das zu pass…
Wenn diese 550er "Rejects" nicht beim Eimpfänger angeliefert worden sind hat der
ein kaputtes eMail system!
Emails können nicht verloren gehen!
DMARC dient auch dafür, solche falschen Bounces (Back scaterring) zu erkennen und gezielt abzu lehnen.
Baracuda bietet, gegen einwurf kleiner Münzen, für das Erkennen von "False Bounces" eine eigene Lösung an. Vermutlich werden sie am Ausgang kein DMARC machen wollen und am Eingang nicht prüfen wollen?
(Ich habe nur mal deren Homepage gelesen)
Wäre ja zu blöd, sich das Geschäft selbst kaputt zu machen, oder?
Boa.
Danke für den Link von @Frank
Sehr interessant.
Les ich da richtig?
Innerhalb einer halben Stunde sind 14000 mails angkommen, 2500 tausend rejected/gebounct worden für nur 650 User?
Was haben die denn für ein Geschäft (so grob) bei dem pro Stunde mehr als 20000 eMails verarbeitet werden können/müssen?
Das wären pro Mitarbeiter ca. 120 eMail, pro Sekunde…
Irgenwie verstehe ich da 'was nicht, oder das, was durchgekommen ist hauptsächlich spam oder ne Mailloop oder Automaten mails.
Normal ist das nicht :-)
Hm, wenn eine Email 10KB hat, 28800 in 3600 Sekunden kommen,
Haben wir ungefähr 77kBps, was wiederum nicht so viel ist, nur fast
0,75 Mbps… nur für eMails? Für 650 Leute?
Ich sagte schon? Boa.
Wo ist mein Komma fehler?
ie man sih finde ich das gerade sehr interressatn. ich hofe ich nerve nicht zuviel :-)
Ich mal Googgel gefragt:
"550 5.4.1 Recipient address rejected: Access denied."
Google sagt:
"This error typically occurs because of the Directory-Based Edge Blocking (DBEB) settings configured within Exchange Online. DBEB is usually enabled for your accepted domains in Microsoft 365 to reject external emails with addresses that are not present within the Azure Active Directory.03.03.2023
"
Ich hätte auf grund des Fehler Textes auch irgendwie erwartet, das der Server der eigentlich die eMail final speichern sollte nicht erreichbar ist, aus rechtlichen Gründen (und nicht weil das Postfach voll ist) zum es ja auch Probleme beim Abrufen der eMails gab.
Was hat das mit DMARC zu tun, wenn das Postfach des Empfängers nicht erreichbar ist.
Woran sieht man das?
Ich würde sagen:
"MS hat die Permissions in Azure versaubeutelt"
Oben im twtter steht doch was von SPF.
Wieso geht es denn mit DMARK weiter?
"This error typically occurs because of the Directory-Based Edge Blocking (DBEB) settings configured within Exchange Online. DBEB is usually enabled for your accepted domains in Microsoft 365 to reject external emails with addresses that are not present within the Azure Active Directory.03.03.2023"
sgt google zu der Reject Meldung
"550 5.4.1 Recipient address rejected: Access denied."
Was hat das mit DMARK zutun?
Auch der Fehlerreport von MS sagt, das es einen Konfigrationsfehler, gab, der zeigt weise die Postfächer der User unzugäglich machte.
Was hat dsa mit DMARK zutun?
Hm, habe ich meinen Postings zu der 550er Fehler Meldung
irgenwie ein böses Wort genutzt, vielleicht eines das aussíeht wie g##gle oder
wieso erscheinen diese Postings nicht, nicht mal "wartet auf Moderation"?
Es laufen hier im Blog einige Filter mit – bei einigen kommt möglicherweise eine Meldung, bei anderen nicht. Ich gebe die Kommentare jetzt frei.
Wenn Kommentare zu viel freigegeben wurden, bitte kurze Meldung an mich – ich kann nachträglich löschen.
Hab mich wohl ver guckt.
Hau das weg.
Sorry
Achso.
Für mich sind SPF und DMARC zwei völlig getrennte Sachen.
Das einzige gemeinsame ist, das sie das DNS benutzen.
MS verwendet DMARC aber als Oberbegriff, der auch SPF enthält.
Hier geht es um 2 Probleme.
Zum einen das MS oder Google einen fehlenden SPF record neuerdings mit einem reject ahndet, was zu einem NDR führt.
Zum anderen um eine Fehlkonfiguration Anfang des Monats innerhalb von Azzure, die E-Mails zum Teil für ein paar Stunden bouncen ließen.
Das führte auch zu einer NDR Mail.
Richtig?
Das hat nichts mit DMARC zu tun, außer der für mich seltsamem Begrifflichkeit, das SPF Teil von DMARC wäre.
Wir erhalten auch vermehrt Emails an Postmaster, nachdem Emails Aufgrund von DMARC nicht zugestellt werden konnten.
Wir haben auch seit Anfang letzten Jahres einen Case offen, in dem Mails teils von anderen Mailservern abgelehnt werden, weil die ausgehenden Exchange / EOP Nodes teilweise IPs verwenden, die nicht im Microsoft SPF Include Record vorhanden sind.
Leider nicht reproduzierbar, da wir ja nicht steuern können, welches Exchange Online Node verwendet wird.
Der Office 365 Support weigert sich wehement, dass Problem zu debuggen weil wir einen SPF Flattener aufgrund von zu vielen Includes verwenden müssen um im Spec zu bleiben. Selbst nachdem ich bei zwei separaten Mails die sogar unterschiedliche EXO Nodes verwendet haben, nachweisen konnte, dass die externen Adressen nicht im SPF Record vorhanden sind, weigert sich der Support es entsprechend zu eskalieren.
Jedes Mal, wenn ich einen neuen Fall nachliefere, ist die Durchlaufzeit so lang, dass sie schon nicht mehr die entsprechenden Logs für den Fall haben..
Dieses Ticket ist ein reines Trauerspiel, wir überlegten sogar schon mindestens den Transport, nach jüngsten Ausfällen sogar die Mailboxen, wieder in unsere Obhut zu ziehen..