7
Mailversand an outlook.com aktuell verzögert
Moin,
aktuell sehe ich auf allen Mailservern die ich betreue, dass sich da E-Mails teilweise seit über 3-4 Stunden stapeln, wenn sie an outlook.com (sowie die Derivate live.de, hotmail.com, u.s.w.) adressiert sind - und das auch nur, wenn die E-Mails über IPv6 eingeliefert werden sollen.
Fehlermeldung des Remote-Servers:
Liefert man die E-Mails per IPv4 ein, werden sie sofort zugestellt.
In meiner Erinnerung, die mich möglicherweise täuscht, waren die Outlook.com-Server bisher nicht per IPv6 erreichbar, heute fällt es mir zumindest auf.
Falls die IPv6-Konnektivität bei diesen Diensten neu ist, wäre das möglicherweise eine Erklärung dafür, dass die Server da unsinnige Antworten geben.
Möglicherweise wird das Problem verstärkt dadurch, dass ich auf unserer Seite den Server konfiguriert habe, IPv6 zu benutzen, wenn es verfügbar ist und nicht beides zu versuchen. Bisher hatte ich das aktiviert, um Verzögerungen durch Greylisting zu verkürzen, aber es scheint im Zusammenhang mit Outlook.com gerade das Gegenteil zu bewirken.
aktuell sehe ich auf allen Mailservern die ich betreue, dass sich da E-Mails teilweise seit über 3-4 Stunden stapeln, wenn sie an outlook.com (sowie die Derivate live.de, hotmail.com, u.s.w.) adressiert sind - und das auch nur, wenn die E-Mails über IPv6 eingeliefert werden sollen.
Fehlermeldung des Remote-Servers:
host eur.olc.protection.outlook.com[2a01:111:f400:fe0c::33] said: 451 4.7.500 Server busy. Please try again later from [2a01:111:e400:7e0c::52]. (AS750) (in reply to RCPT TO command)Liefert man die E-Mails per IPv4 ein, werden sie sofort zugestellt.
In meiner Erinnerung, die mich möglicherweise täuscht, waren die Outlook.com-Server bisher nicht per IPv6 erreichbar, heute fällt es mir zumindest auf.
Falls die IPv6-Konnektivität bei diesen Diensten neu ist, wäre das möglicherweise eine Erklärung dafür, dass die Server da unsinnige Antworten geben.
Möglicherweise wird das Problem verstärkt dadurch, dass ich auf unserer Seite den Server konfiguriert habe, IPv6 zu benutzen, wenn es verfügbar ist und nicht beides zu versuchen. Bisher hatte ich das aktiviert, um Verzögerungen durch Greylisting zu verkürzen, aber es scheint im Zusammenhang mit Outlook.com gerade das Gegenteil zu bewirken.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 4399285758
Url: https://administrator.de/contentid/4399285758
Printed on: May 20, 2024 at 20:05 o'clock
7 Comments
Latest comment
Nachtrag: So trüb ist meine Erinnerung offenbar nicht:
Laut den Mailserver-Logs haben wir heute ab 06:38 Uhr MESZ angefangen, E-Mails per IPv6 an outlook.com zuzustellen. Aber erst ab etwa 15:00 Uhr herum kamen die ersten vereinzelten "Server busy"-Rückmeldungen.
Laut den Mailserver-Logs haben wir heute ab 06:38 Uhr MESZ angefangen, E-Mails per IPv6 an outlook.com zuzustellen. Aber erst ab etwa 15:00 Uhr herum kamen die ersten vereinzelten "Server busy"-Rückmeldungen.
Erste Gehversuche mit IPv6 bei MS 😁
Hallo
kann ich bestätigen!
Bei uns war das gleiche Problem, Teilweise 1800 Mails in der Queue
Wir haben die Server jetzt umgestellt, damit mails an MS nur per IPv4 verschickt werden.
MS soll IPv6 selber testen
kann ich bestätigen!
Bei uns war das gleiche Problem, Teilweise 1800 Mails in der Queue
Wir haben die Server jetzt umgestellt, damit mails an MS nur per IPv4 verschickt werden.
MS soll IPv6 selber testen
Hier ist es laut Logs übrigens so, dass Mails über IPv6 zwar teilweise angenommen wurden aber beim Kunden nicht in der Mailbox angekommen sind und im Nirvana verschwunden sind, also ganz arger Fehler ... Ein IPv6 Blackhole für Mails ...
Ich glaube, Microsoft hat das Problem, dass deren Load-Balancer die originale IPv6-Adresse der einliefernden Clients nicht mitgeben.
Eine Testmail, die per IPv6 durchkam, deutet zumindest sehr deutlich darauf hin:
Der Server "mx0.301-moved.de" ist meiner. Aber die dabei angezeigte Adresse ist es nicht, die gehört zu MICROS~1.
Die SPF-Prüfungen, die Microsoft macht, schlagen daher fehl, weil sie von der falschen Adresse ausgehen. Meine Mail ist mutmaßlich durchgekommen, weil sie eine gültige DKIM-Signatur trägt.
Könnte aber, wenn deine E-Mails nicht DKIM-Signiert sind und ggf. auch "-all" im SPF-Record auftaucht, genau der Grund sein, warum deine E-Mails verschwinden.
Eine Testmail, die per IPv6 durchkam, deutet zumindest sehr deutlich darauf hin:
Received: from mx0.301-moved.de (2a01:111:e400:7e1a::44) by
DB5EUR01FT006.mail.protection.outlook.com (2a01:111:e400:7e1a::134) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5769.13 via Frontend
Transport; Wed, 26 Oct 2022 05:24:24 +0000
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
meinedomain.tld discourages use of 2a01:111:e400:7e1a::44 as permitted sender)
Authentication-Results: spf=softfail (sender IP is 2a01:111:e400:7e1a::44)
smtp.mailfrom=meinedomain.tld; dkim=pass (signature was verified)
header.d=meinedomain.tld;dmarc=pass action=none
header.from=meinedomain.tld;compauth=pass reason=100Der Server "mx0.301-moved.de" ist meiner. Aber die dabei angezeigte Adresse ist es nicht, die gehört zu MICROS~1.
Die SPF-Prüfungen, die Microsoft macht, schlagen daher fehl, weil sie von der falschen Adresse ausgehen. Meine Mail ist mutmaßlich durchgekommen, weil sie eine gültige DKIM-Signatur trägt.
Könnte aber, wenn deine E-Mails nicht DKIM-Signiert sind und ggf. auch "-all" im SPF-Record auftaucht, genau der Grund sein, warum deine E-Mails verschwinden.
Autsch, wenn da auch noch IPv6 NAT im Spiel ist dann gute Nacht dann macht das auch Sinn. Danke für die Info.
Kurze Durchsage von Microsoft dazu:
October 26, 2022 6:24 PM
Title: Some users may be unable to send email to some Microsoft hosted domains via any third-party cloud-based gateway
User impact: Users may be unable to send email to some Microsoft hosted domains via any third-party cloud-based email gateway.
Current status: Our efforts to collect an updated reproduction of the issue have been unsuccessful. Regardless, we’ve determined that the reversion of the affected infrastructure components back to the last known healthy state is the most efficacious mitigation strategy. This process is ongoing, and we anticipate that it will complete by our next scheduled update.
Scope of impact: Any user attempting to send email messages to some Microsoft 365 domains from third-party cloud-based email gateways may be impacted.
Next update by: Thursday, October 27, 2022, 3:30 AM (1:30 AM UTC)
Title: Some users may be unable to send email to some Microsoft hosted domains via any third-party cloud-based gateway
User impact: Users may be unable to send email to some Microsoft hosted domains via any third-party cloud-based email gateway.
Current status: Our efforts to collect an updated reproduction of the issue have been unsuccessful. Regardless, we’ve determined that the reversion of the affected infrastructure components back to the last known healthy state is the most efficacious mitigation strategy. This process is ongoing, and we anticipate that it will complete by our next scheduled update.
Scope of impact: Any user attempting to send email messages to some Microsoft 365 domains from third-party cloud-based email gateways may be impacted.
Next update by: Thursday, October 27, 2022, 3:30 AM (1:30 AM UTC)
