[English]Zum 11. Oktober 2023 ist es bei Exchange Online zu einer schweren Störung des Mail-Verkehrs gekommen. Mehrere Leser berichteten von Problemen beim Empfang von E-Mails von externen E-Mail-Adressen. Microsoft hat den Vorfall bestätigt und will bereits einen Fix ausgerollt haben. Spoiler: Die sind Opfer des eigenen SPAM-Schutzes geworden, den man zum Patchday ausrollte.
Anzeige
Ich wurde heute gleich von mehren Nutzern bezüglich der Störung informiert (danke dafür), kann aber erst jetzt reagieren, da ich unterwegs war. Christoph Z. schrieb zum Beispiel:
Probleme mit M365 Exchange Online
Hallo,
Bei unseren Kunden mit M365 Exchange Online treten heute vermehrt Probleme beim Empfang von E-Mails von externen E-Mail-Adressen auf. Offenbar liegt eine Störung seitens Microsoft vor.
"Microsoft is reporting a service issue that is causing delivery delays for email coming from outside our organization. Microsoft has identified the cause of the issue and is in the process of deploying a fix. "
Vielleicht haben Ihre Leser auch Probleme mit Exchange Online.
Andere Leser hatten diese Probleme ebenfalls. Steffen H. meldete sich und schrieb dazu:
Guten Tag Herr Born,
ich würde Sie nur gerne über aktuelle Probleme mit dem Exchange Online von Microsoft informieren, sofern noch nicht bekannt.
Es kommt aktuell dazu das Mails welche Richtung Exchange Online gesendet werden von MS nicht angenommen werden.
Diese verbleiben in der E-Mail-Warteschlange unseres NoSpamProxy's.
Grund: „451 4.7.500 Server busy"
Im Admin Center gibt es ebenfalls einen entsprechenden Eintrag/Vorfall dazu.
Thomas W. hat per Mail folgende Infos geliefert:
Anzeige
seit heute morgen gibt es erhebliche Probleme mit Exchange Online.
Auf unseren MTAs hängen hunderte E-Mails an Empfänger bei Exchange Online.
Microsoft bestätigt es telefonisch, aber keine offizielle Kommunikation…
Er verwies auf einen reddit.com-Post, wo entsprechendes ebenfalls zu lesen ist. Thomas Z. schrieb mir dazu:
Hallo Herr Born,
auf unserem mx4.tz-com.at (78.47.134.189) habe ich seit heute 5:29 Uhr > 400 E-Mails hängen die an M365 gehen sollen. Hier senden unsere Kunden alle E-Mails via Relay weg. Unser Server ist auf keiner Blacklist zu finden.
Alle Meldungen lt. Log ziemlich gleich
——- cut ——-
451 4.7.500 Server busy. Please try again later from [x.x.x.x]. (S77719) [DBAEUR03FT016.eop-EUR03.prod.protection.outlook.com 2023-10-11T13:37:42.355Z 08DBC945E7F99585]
<xxx@xxx.com>… Deferred: 451 4.7.500 Server busy. Please try again later from [x.x.x.x]. (S77719) [DBAEUR03FT016.eop-EUR03.prod.protection.outlook.com 2023-10-11T13:37:42.355Z 08DBC945E7F99585]
Closing connection to xxxx.mail.protection.outlook.com.
Thomas verwies auf diesen Beitrag bei Microsoft, wo ein Administrator das Problem ebenfalls gemeldet hat. Andreas P. hat mir wie immer die betreffenden Auszüge Microsofts im Admin-Statusbereich per Mail geschickt:
Published Time: 11.10.2023 19:11:15
We've completed development of an additional fix which is undergoing validation prior to deployment. We expect to complete this process within the next 60 minutes.
This quick update is designed to give the latest information on this issue.Published Time: 11.10.2023 18:27:35
Title: Some users may encounter delays receiving external email messages in Exchange Online
User impact: Users may encounter delays receiving external email messages in Exchange Online.
More info: Impact is specific to Simple Mail Transfer Protocol (SMTP), and users may encounter delays of up to 24 hours. Additionally, the email sender may receive a Non-Delivery Report (NDR) with a "451 4.7.500 Server busy" error message, and their attempt to retry delivery of the email may be delivered up to 24 hours later.
Current status: We've determined that our previous developed fix to resolve the throttling issue has proven to be unsuccessful. We're developing a new fix that will undergo internal validation to ensure it resolves the underlying issue before deploying it to the impacted environments.Scope of impact: Impact is specific to some users who are served through the affected infrastructure.
Start time: Monday, October 9, 2023, at 9:00 PM UTC
Root cause: A recent service update, applied to a section of infrastructure responsible for enforcing IP address anti-spam rules, contains a change which is causing impact.
Next update by: Wednesday, October 11, 2023, at 6:30 PM UTCPublished Time: 11.10.2023 12:26:01
Title: Some users may encounter delays receiving external email messages in Exchange Online
User impact: Users may encounter delays receiving external email messages in Exchange Online.
More info: Affected users may see a "451 4.7.500 Server busy" error message.
Current status: We've identified that specific IP addresses are being unexpectedly limited by our anti-spam procedures, causing inbound external email delivery to become throttled and delayed. We're reviewing if there have been any recent changes to our anti-spam rules to understand why the IP addresses are being limited. In the meantime, we're manually adding reported affected IP addresses to an allowed list to provide immediate relief.
Scope of impact: Impact is specific to some users who are served through the affected infrastructure.
Next update by: Wednesday, October 11, 2023, at 12:30 PM UTCPublished Time: 11.10.2023 10:59:51
Title: Some users may encounter delays receiving external email messages in Exchange Online
User impact: Users may encounter delays receiving external email messages in Exchange Online.
More info: Affected users may see a "451 4.7.500 Server busy" error message.
Current status: We're analyzing sample throttling IPs from simple messages to confirm whether the issue with the portion of SQL infrastructure is causing impact, before we begin formulating a remediation plan.
Scope of impact: Impact is specific to some users who are served through the affected infrastructure.
Next update by: Wednesday, October 11, 2023, at 11:00 AM UTCPublished Time: 11.10.2023 08:33:49
Title: Users are unable to receive external email messages within Exchange Online
User impact: Users are unable to receive external email messages within Exchange Online.
More info: Some users email messages may send; however, users may experience delays up to one hour.
Current status: Our review of simple messages has lead us to a potential root cause where a portion of SQL infrastructure may be receiving an unusually large number of requests that may be hindering Exchange Online's performance. We're working to confirm our findings to cultivate further troubleshooting steps.
Scope of impact: Your organization is impacted by this event, as well as users who are attempting to receive external email messages within Exchange Online.
Next update by: Wednesday, October 11, 2023, at 8:30 AM UTCPublished Time: 11.10.2023 06:52:50
Title: Users are unable to receive external email messages within Exchange Online
User impact: Users are unable to receive external email messages within Exchange Online.
Current status: We're currently reviewing simple messages to refine our understanding of this specific impact scenario and establish our troubleshooting steps.
Scope of impact: Your organization is impacted by this event, as well as users who are attempting to receive external email messages within Exchange Online.
Next update by: Wednesday, October 11, 2023, at 6:30 AM UTCPublished Time: 11.10.2023 06:22:26
Title: Users are unable to receive external email messages within Exchange Online
User impact: Users are unable to receive external email messages within Exchange Online.
Current status: We're investigating a potential issue and checking for impact to your organization. We'll provide an update within 30 minutes.
Microsoft ist Opfer seines Anti-Spam-Updates geworden. Ein kürzlich durchgeführtes Service-Update für einen Teil der Infrastruktur, der für die Durchsetzung der Anti-Spam-Regeln für IP-Adressen zuständig ist, enthielt eine Änderung, die diese Auswirkungen verursachte. Das Problem sollte nun behoben sein.
Immer wieder schön zu lesen, wie die Cloud-Lösungen mit Exchange Online da weltweit Administratoren in Atem halten. Ganz pöse Zungen flüstern, dass wenige Stunden vorher Patchday bei Microsoft war und On-Premises Exchange Server Updates bekamen, die Probleme verursacht haben. Obiger Vorfall bezieht sich aber auf Exchange Online, da sorgt Microsoft für Patches und reibungslosen Betrieb – ist jedenfalls das Argument, was man so landläufig hört.
Vielleicht ist das die "ausgleichende Gerechtigkeit" des Administratoren-Gotts, der sah, wie Exchange On-Premises Admins leiden und beschloss, da auch mal einen Blitz in die Cloud zur Exchange Online-Fraktion zu schleudern. Der Einschlag war scheinbar gut zu hören, hat mich aber heute so gar nicht gestört.
Anzeige
451 bedeutet so grob, dass der empfangenen Host ein internes, temporäres Problem hat.
Man möge einen Moment warten und es dann erneut probieren.
Zum Spam-Filtern ist das nicht wirklich geeignet.
Es gab mal "Gray listing".
Da würden alle E-Mails erstmal mit einem 400er abgelehnt.
Man war der Meinung,das das Spammer irgendwie stören würde.
Tat es nicht.
Aber es störte bestimmte Großmailversrnder wie Yahoo, die solche 400er E-Mails nicht spoolten, sondern beim 2. Versuch einfach neu generierten. Mit einer neuen ID…
Das hier unterschiedliche Delays von 1h und 24h gemeldet wurden passt dazu:
Die Wsrte. Zeit nach einem 400er wird expotietiell mit jedem Versuch verlängert. Bis zu einer Woche!
Weil, auch wenn es inzwischen vergessen wurde!
Email ist kein Echtzeit medium.
das ist allerdings nicht mehr in die Köpfe der User zu bekommen.
Und so gibt es Systeme, die die Anzahl der erneuten zustellversuche auf Null gesetzt haben, dem User also sofort ein NDR ins Postfach hauen.
Diese Konfiguration sei allen heutigen Admins dringend empfohlen.
Die User glauben an den Osterhasen und das jede eMail nach maximal 1..2 Minuten beim Empfänger ist.
Ist sie das nicht, ist es in der Regel besser dem User sofort Bescheid zu geben. Dann kann er den Kunden anrufen und das Angebot faxen.
Obige retries stammen aus DialUp Zeiten (wie auch der ebenfalls unsinnige Einsatz von 2 stmp Servern: Der eine hat ein Störung und vergisst die E-Mails weiterzuleiten. Das fällt U.U. sehr lange nicht auf, weil die Mail über den anderen Server noch funktioniert… also:
Bitte:
Weder eine. 2. SMTP Server als MX eintragen
(manche Absender Hosts merkten sich tatsächlich die MX IP Adresse im Spool und versuchten es immer wieder auf dem toten Server. Damals war DNS noch kostbar.)
noch bei 400er Fehlern mehr als 2 Minuten retries, sondern sofort NDR an den eigenen User
Das stammt alles aus den 80ern und war damals sehr sinnvoll.)
Was es hier geholfen hätte?
Der Help desk wäre in Minuten voll mit User Meldungen gewesen "Ich kann Kunde XY nicht mehr erreichen ".
Jetzt kamen die Meldungen erst nächsten Tag, wenn Kunde sich schon schwarz geärgert hatte, dass man ihm nicht antworten würde… Dabei hatte es sein Mailprovider verbockt.
Klar das man dann als Admin etwas mehr arbeiten muss, als einfach zu warten "Microsoft wird das schon richten, darum sind wir ja in der Cloud", aber…der Kollege kommt weiter, wenn man ihm sofort sagt, dass es da draußen ein Problem gibt und nicht erst nach mehrere Stunden.
(Mir fällt da der Kollege ein, der am Freitag Nachmittag, ganz dringend ein Binary Blop nach Timbuktu mailen wollte.
Er hatte nicht auf die Größe geachtet(es sollte schnell gehen…), es waren auch nur 10 MB.
Leider war der Blop für dem Empfänger zu groß (binary base64 encoded, 16MB brutto .)und der Empfänger bliess die Aktion immer mit einem 400er Fehler ab.Frag nicht aus welches Wunder der Selbst-Heilung er hoffte…
Und der eigene Server hatte damals noch kein Limit von 0…
Und wenn seine Frau nicht angerufen hätte, sässe er wohl noch heute da und wartete auf die Bestätigung des Services Menschen. Also ging er nach Hause, und am Montag morgen war seine E-Mail immer noch in Timbuktu.
Erst jetzt rief er beim Admin an, und der sagte ihm wie er sejnen Blop nach Timbuktu bekam. Ob sich der Service Techniker gefreut hat, 2 Tage im Hotel rumzuhängen ist nicht überliefert.
Wenn der Mailserver modern eingerichtet gewesen wäre hätte der Kollege nahezu sofort einen NDR bekommen und hätte entsprechend sofort reagieren können. ..
Alle wären zufrieden gewesen. der Kollege, seine Frau, Der Techniker, der Kunde)
Also bitte:
Keine retries machen.
als wenn Otto Normalo überhaupt Fehlermeldungen lesen würden ;-P
Da kommen dann höchstens so Anrufe beim Admin: du ich habe das Internet kaputt gemacht…
@Born
******************Vielleicht ist das die "ausgleichende Gerechtigkeit" des Administratoren-Gotts, der sah, wie Exchange On-Premises Admins leiden und beschloss, da auch mal einen Blitz in die Cloud zur Exchange Online-Fraktion zu schleudern. Der Einschlag war scheinbar gut zu hören, hat mich aber heute so gar nicht gestört.*****************
Ich liebe diese Art Humors ;-P
Ja, genau. Die User müssen den NDR nicht interpretieren können. Es kommen zeitnah Meldungen der User.
Versucht der Mail Server es eigenmächtig immer wieder, kommen keine Meldungen der User.
Und selbst wenn der gute Admin seine Mail queues von einem Script überwachen lässt, er kann nichts machen als zu gucken wie sein Server langsam absäuft…
Anyway, es zeigt Recht schön, wie genial einst das Internet geplant war, atombomben sicher, und was für einen grazilen Schrott die Geldgier draus gemacht hat.
Und fast alle, due Entscheiden dürfen sind begeistert sparen sie doch Personalkosten.
Sehr dramatisch ist die Kommunikation seitens Microsoft.
Wenn ich als Admin mit dem OnPremises-Exchange Probleme hatte, wurde im Intranet eine Meldung geschaltet.
Gestern konnte ich nichts bei Microsoft finden, es gab auch keine Logs, die ich überprüfen konnte. Den Usern konnte ich nur sagen "Sind mal wieder Patch-Days bei Microsoft, wir müssen zwei, drei Tage abwarten." Erst die Logs auf dem eigenen privaten Mail-Server gaben Hinweise.
Traurig. Leider liegt die Entscheidung über O365 auch nicht bei mir :-(
Doch, als Sender der eMails konntest Du sehen das Deine Send que voll läuft. So ist das wohl auch auf Opfer-Seite aufgefallen.
Als Empfänger würdest Du im logfile sehen, das Dein MX reichlich 451er wirft…
Leider leider hast Du natürlich keinen Zugriff auf die Log Files der Microsoft MXe, obwohl man natürlich anhand der Domain feststellen könnte, dass das diese Log Einträge für Dich sind.
Es ist ja nicht ungewöhnliches, daß ein MX für mehrere Domains arbeitet. Nur Microsoft spart sich die Arbeit oder lässt sie sich teuer bezahlen.
Wenn man vor den MS kram noch einen Antispam Provider gesetzt hat, der erstmal alles annimmt, was nicht von bösen IPs kommt, glaubt der Absender, das seine E-Mail gleich beim Empfänger ist.
Es hängt dann vom Antispam Provider ab, wue er reagiert, wenn er diese eMails mit 451 nicht los wird…
K.I.S.S….
Ich kann nur hoffen, dass MS der Müll weiterhin so richtig um die Ohren fliegt und daß immer mehr Chefetagen auf wachen, das man nicht 24h ohne IT auskommen kann.
Kann das Problem bei Microsoft auch dazu führen, dass alle Mails von einem unseren Kunden grundsätzlich als SPAM deklariert werden?
der SPF-Eintrag ist sauber gesetzt und wird akzeptiert. DERDKIM-Eintrag ist sauber gesetzt und wird akzeptiert. Trotzdem landen Mails, vom Kunden verschickt immer im SPAM-Ordner. Mir gehen die Ideen aus, wo da noch ein Problem sein könnte. Der Absender ist auch nicht auf einer Blacklist zu finden.
Normalerweise steht der Grund für die Spam-Zuordnung im RfC Header der eMail und im logfile des MTA oder Spamfilters.
Wenn ihr beides nicht habt, solltet ihr euch nach einer neuen Consultante umsehen, die etwas von Email versteht und nicht nur vom Rechnungen schreiben.
Der Kollege auf der anderen Seite kann ja Mal händisch eine Email per SMTP und einem Telnet einreichen.
Ja, das geht wirklich, wenn der Server keine absurd kurzen Timeouts hat, weil ja nur pöse Menschen SMTP per Telbet machen(*) Daher das "S" wie "Simple" in SMTP.
(*) so überraschend das jetzt klingt:
Ein SMTP Mail server muß eine Email an "postmaster" ohne Domain annehmen und an den zuständigen Postmaster weiter leiten. Für diesen Zweck benutzt man I.d.R. eine. Telnet client und tickert das manuell ein.
Bei uns hat sich das Problem mittlerweile so verlagert, dass wir nun den Fehler "hop count exceeded" erhalten, wenn wir eine E-Mail von unserem MS Tenant an einen anderen MS Tenant versenden und wir über unseren Smarthost (Postfix) gehen.
In der Exchange Ablaufverfolgung sieht man, dass MS eine Ausgehende E-Mail 7 Mal an den Empfänger sendet und dieser, beim 7 Mal die Annahme mit "hop count exceeded" verweigert und alle zuvor erhaltenen Mails verwirft. Sprich, der Empfänger bekommt nichts.
Schalten wir das Routing um und umgehen unseren Smarthost, wird nur eine E-Mail versendet und die Zustellung funktioniert.
Weiterhin haben iPhone Nutzer nun auch Probleme mit den "nativen" Funktionen von Apple auch Ihr Exchangekonto zuzugreifen. Wenn die Outlook App installiert ist läuft alles.
Habt ihr vielleicht eine Mail Schleife?
Hat früher mal zum Tod ganzer Mail Systemr geführt.
Aber heute wird das Recht gut geprüft.
Warum kommt dieselbe E-Mail immer wieder beim selben SMTP Server an?
Das sollte natürlich nicht passieren, passiert aber manchmal.
Über wie viele unterschiedliche Host die Mail gegangen ist, ist wurscht.
Das ist oft historisch gewachsen und Aufräumen spart viel Strom…
Wenn euer smarthost die Sachen nicht los wird wg. 451 muss er eine bestimmte Zeit warten ehe es wieder versucht.
Bei 451 ist er die Email aber überhaupt nicht losgeworden.
Das da ne Grenze der Zustellversuche gibt ist mir neu.
Der Text bei der Fehlermeldung ist gerne Mal falsch.
Welche Codes kommen dam
Wie lange steht natürlich in der RfC.
Nein, keine Schleife. Der Mist passiert nur innerhalb von MS Tenant zu Tenant. Mails an andere Provider gehen problemlos durch. MS hat auch irgendwo bestätigt, das es Probleme bei der Übermittlung über Smarthosts gibt.
Mit Apple Mail & Exchange Online bisher keine Probleme bei uns bekannt. Und auch sonst habe ich dazu noch nichts gesehen gehabt.
Exchange Online läuft super, es ist günstig, zuverlässig und verringert die Komplexität enorm, vor allem, wenn man eine eigene AD hat.
Außerdem ist es viel viel günstiger.