Mail-Zustellungsprobleme: Microsoft 365/Exchange Online; 1&1 IONOS-Status; Vodafone

MailKurzer Beitrag zur Information an die Leserschaft und gleichzeitig Rundfrage nach Erfahrungen. Die Tage eine Info bekommen, dass Microsoft mit IPs wieder auf eine Sperrliste (Black-List) geraten ist, also keine Mails zugestellt werden können. Dann gibt es in Bayern momentan Probleme mit einem "Netzwerk", wo keine Mails an Exchange Online zugestellt werden können. Nächster Infosplitter wäre meine Nachfrage nach Erfahrungen mit der Änderung bei Mail-Postfächern, die auf 1&1/IONOS gehostet sind. Und es gibt ein Fundstück, dass sich bei Vodafone etwas bzgl. Einbindung eines Clients geändert haben könnte. Zeit für einen Sammelbeitrag.


Anzeige

Wie ist der Status bei 1&1/IONOS?

Bei 1&1 sowie dem Brand IONOS gab es vor einiger Zeit zwei Beiträge hier im Blog. IONOS hatte angekündigt, dass man den SMTP-Relay (SmartHost)Dienst zum 15. Januar 2024 in der bisherigen Form einstellen werde. Später wurde das auf Ende Januar 2024 verschoben. Damit entfällt die Möglichkeit zum Versand von Mails mit vom SmartHost abweichenden E-Mail-Adressen. Ich hatte im Blog-Beitrag IONOS schafft SMTP-Relay (SmartHost) zum 15. Januar 2024 ab dazu berichtet.

Und auch von 1&1 gab es die Meldung, dass ab dem 15.01.2024 wichtige Änderungen im E-Mail-Versand über die 1&1-Server erfolgen. Nutzer der 1&1-Postfächer müssen sicherstellen, dass die Absenderadresse der versandten E-Mails mit der Adresse des eingerichteten Postfachs übereinstimmt. Ich hatte die Details im Beitrag Auch 1&1-Postfächer von Änderungen der Einstellungen zum 15. Januar 2024 betroffen aufgegriffen.

Die Termine 15. Januar 2024 und Ende Januar 2024 sind ja nun verstrichen. Bei meine 1&1-Postfach war ich zwar benachrichtigt worden, dass mein web.de-Konto betroffen sei – was ich aber nicht nachvollziehen konnte. Am Ende des Tages kann ich feststellen, dass ich man meinen Thunderbird-Einstellungen für das 1&1-Postfach nichts ändern musste.

Aber die Frage: Wie sind eure Erfahrungen mit Postfächern bei 1&1 und IONOS? In den Kommentaren hier gibt es ab dem 16. Januar 2024 unterschiedliche Kommentare zu 1&1. Und zur IONOS-Umstellung gibt es diese Kommentare ab Februar 2024 mit Erfahrungen.

Änderung bei Mails über Unitybox.de?

Aktuell bin ich auch über die Beobachtung eines IT-Dienstleisters gestolpert, der bei einem Kunden zu einem Rechner gerufen wurde, der plötzlich keine Mails mehr über unitybox.de per IMAP versenden konnte. Am betreffenden Client ließen sich über Jahre E-Mails der Adresse xxx@unitybox.de per IMAP mit der Server-Einstellung mail.unity-box.de verschicken.

Ältere Artikel wie hier behaupten, dass mail.unitybox.de für den IMAP -Server einzutragen sei. Die Vodafone-Seiten geben inzwischen imap.vodafonemail.de für den IMAP-Server auf Port 993 vor. Und damit hat es in obigem Fall dann auch wieder mit dem Mailversand geklappt. Ich habe noch einen Forenbeitrag von 2023 gefunden, wo es ähnliche Probleme gab.

Microsoft wieder auf Blacklist

Ich hatte im Januar 2024 im Beitrag Microsoft IP-Adressen auf Blacklists gelandet (Jan. 2023) darüber berichtet, dass Nutzer von Exchange Online in Probleme mit der Mail-Zustellung laufen, weil IP-Adressen, die Microsoft hält, auf Sperrlisten (Blacklists) landen. Nun hat mich ein Nutzer schon in der ersten Februar-Woche kontaktiert, weil ihm das Gleiche passiert ist. Er bekam folgende Fehlermeldung:

smtp31.gate.iad3a.rsapps.net hat diesen Fehler ausgegeben:

Decision Engine classified the mail item was rejected because of IP Block (from outbound normal IP pools) -> 554 5.7.1 ACL dns_rbl; Client host [40.107.xxx.xx] blocked using sa-ip4tset.blagr.emailsrvr.com=127.22.0.2 Senderscore. Please visit https://senderscore.org/rtbl/ for more information on why this message could not be delivered (G31)

Da ist also ein Gateway auf der Liste gelandet, worauf Mails zur Weiterleitung verweigert werden. Noch jemand mit diesen Erfahrungen?


Anzeige

Problem mit Microsoft 365/Exchange Online-Mails

Ein Leser informierte mich per E-Mail, dass er seit Sonntag (11.2.2024) Probleme mit der Mailzustellung feststellt. Die Mails werden nur verzögert zugestellt oder abgelehnt. In einem Fall bekam der Leser folgende Meldung:

Remote Server returned '554 5.0.0 <[52.101.xx.xx] #5.0.0 smtp; 5.4.7 –
Delivery expired (message too old) [Default] 451-'4.7.500 Server busy.
Please try again later from [193.34.xxx.xxx]. (S77719)
[DU6PEPF0000xxxx.eurprd02.prod.outlook.com 2024-02-14T05:48:32.876Z
08DC2C4B495Dxxxx]' (delivery attempts: 77)>'

Deutet auf Problemen mit Exchange Online hin. Die erste Problem-Mail wurde am Sonntag verschickt und die
Unzustellbarkeitsmeldung zur Nachricht kam exakt 72 Stunden danach. Wer weiß schon, was er vor 72 Stunden für Mails verschickt hat.

Im Internet lässt sich wohl nichts dazu finden – u.a. weil es nur ganz wenige Leute betrifft. Ich kann noch etwas präziser werden, betroffen sind nur Bayern – ok, ich muss es anders formulieren: Nur Nutzer in Bayern, die bestimmte Anbieter nutzen, sind betroffen. Ich habe gehört, dass das "Ausliefern von Mails vom Bayerischen Behördennetz an Microsoft-gehostete Konten (Office 365) durch Microsoft verhindert wird.

So erster Gedanke: Sind die reitenden Boten für die Mail-Zustellung in Bayern in Streik getreten. Hab es dann verworfen, weil Microsoft ja verhindert. Dann war ich verwirrt und kam auf die Lösung: Fasst wie Beamtenmikado. Der Dienstleiter für dieses bayerische Behördennetz ist die IT-DLZ Bayern, und die haben schon Microsoft kontaktiert, dass es klemmt.

Ich spekuliere mal nicht, sonst müsste ich schreiben: Ob das ein Warnschuss von Microsoft war, die Füße ruhig zu halten, sonst klemmt es. Oder ob es auf ein Beamten-Mikado zwischen der IT-DLZ Bayern und dem Großunternehmen Microsoft hinaus läuft – "wer sich zuerst bewegt, hat verloren". Nein, so etwas schreibe ich nicht, die bemühen sich sicherlich redlich, dass es bald funktioniert. Ein böse Zunge hat mir aber verraten, dass nicht bekannt ist, wie lange diese (atmosphärische) Störung anhalten wird. Denn Microsoft muss sich bewegen.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Mail abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

50 Antworten zu Mail-Zustellungsprobleme: Microsoft 365/Exchange Online; 1&1 IONOS-Status; Vodafone

  1. A. Nonym sagt:

    Eine Mail von 1&1 zu Freenet hat von Sonntag 16:00 bis Dienstag 13:00 benötigt.

  2. Michael sagt:

    Seit 29.01.2024 hat IONOS die Smarhost Policy verschärft, daher man kann nur noch Mails über den Smarthost senden, der auch zu der Domaine gehört, alle anderen werden mit einem Fehler abgewiesen. Ich hab mehrere Domains dort und jede hat auch ein eigenes Sammelpostfach. Vorher reichte es, man authentifizierte sich mit Domain A und konnte auch Mails für Domain B versenden, das geht nun nicht mehr, man muss das Postfach dann von Domain B nehmen. Es reicht ein Sammelpostfach *@domain-a.de *@domain-b.de nur der Smarthost muss sich halt immer am richtigen Postfach anmelden. Damit hab ich derzeit noch ein Problem, denn eigentlich sende ich immer direkt die Mail und nur bei einem Fehler kommt dann der Smarthost zu tragen, leider kann ich da nur einen hinterlegen. Das heißt, für die Domain B nur noch über Smarthost von Domain B senden.

    Du hast t-online.de vergessen, die nerven mich auch seit einigen Tagen wieder, kann keine Mails zustellen, weil der Mailserver nach einem Impressum sucht, obwohl deren eigener selbst kein Impressum anbietet lol.

    https://www.andysblog.de/t-online-keine-smtp-zustellung-moeglich

    Ich zitiere mal einen anderen User

    "funnily enough T-Online do not run web services on _their_ outgoing smtp server addresses …

    Ø tobr@rx.t-online.de

    I had some cases with customers where T-Online refused to accept eMails from those customers eMail systems despite correct A, MX, PTR, SPF and DKIM setup.
    I wrote an email to tobr@ asking for „eventual" block reasons which led to T-Online accept those eMails afterwards."

  3. J. sagt:

    Zum Thema unity-box.de: Vermutlich ist das ein Überbleibsel aus alten Zeiten, das bislang noch mitgelaufen ist. Inzwischen scheint die Domain aufgegeben zu sein, die Domain ist liegt bei einem "Domain Parking Programm".

    • Anton sagt:

      Ich besitze noch einige uralte unity.box Postfächer (> 10 Jahre). Unter der Servereinstellung "mail.unity-mail.de" funktioniert bisher Senden und Empfangen unter IMAP problemlos.

  4. Olli sagt:

    Mail Relay bei IONOS geht nur noch mit Sendegleicher Domain-Adresse. Also Smarthost Adresse zum Senden lautet z.B.: 1@meineDomain.de, damit können auch 2@meineDomain.de, 3@meineDomain.de usw. versendet werden.

    Was entgegen einiger Kommentare im Internet nicht geht ist das Senden mit weiteren Domains die aber im selben Vertrag liegen. Genau das ist aber keine Seltenheit. Wenn man Exchange bislang mit einem Smarthost wie z.b. einer Fortinet oder Sophos UTM genutzt hat, geht das jetzt nicht mehr bzw. nur noch mit einer Domain, weil die Dinger keine SenderBased Smarthosts sind.

    Auf Exchange könnte man jetzt z.B. Multisendcon benutzten, was aber wiederum kein DKIM unterstützt, also müsste man dem Exchange selbst auch noch DKIM beibringen und dann per Multisendcon versenden.

    Also in Summe sehr sehr hässlich und eine üble Nummer von IONOS. Bleibt sinnvoll nur übrig sich mit Open Source selbst einen Smarthost zusammen zubauen oder auf einen Cloud Dienstleister auszuweichen der das kann – hahaha!

    Auch eine OpnSense kann sowas wohl nur wenn man heftig per CLI die Konfig ändert.

    • Robert Glöckner sagt:

      alles schön und gut mit einem eigenen Smarthost, aber der braucht erstmal eine gute Reputation, damit die gegnerischen Mailserver das auch annehmen. Direktversand von meiner dynamischen IP geht erwartungskonform nicht.

      wo kriegt man also einen Smarthost mit Zustellgarantie her? ich bin auch bereit dafür zu bezahlen.

      • Olli sagt:

        Nimm das Geld und buche eine feste IP – das sollte bei einem Mailserver eine Selbstverständlichkeit sein. Dynamische IP und Mailserver ist einfach falsch – das macht man seit vielen Jahren nicht mehr.

        Meine Mails haue ich jetzt auch per DNS raus und bis auf die (dämliche) T-Online werden die Mails alle brav angenommen, von Microsoft, von Google, von Sonstwem – nur T-Online hält sich da wiedermal für was Besseres als der Rest der Welt und nimmt aus Prinzip keine Mails von "Non Reputation" Servern an – feste IP, TLS, ordentliches Zertifikat, Reverse DNS, SPF, DKIM hin oder her – aber T-Online bzw. das ganze Rosa Unternehmen war schon immer besonders (an U-R2 denkend).

      • Bernd B. sagt:

        Wie @Olli schon vorschlug: Feste IP.
        Diese feste IP dann z.B. auf multirbl . valli . org auf Blacklisteinträge prüfen und wenn es nur Wenige (bzw. wenige Wichtige) sind bei deren Betreiber um Delisting bitten.

        IIRC hatte mein 1blu Billigserver "VPS SX"* eine blitzsaubere IP

        * www . 1blu . de/server/vserver/

        • Robert Glöckner sagt:

          1&1 bietet keine feste IP, und mit Telekom will ich nicht.
          aber einen VPS habe ich noch, nie zu Ende konfiguriert, ist v.a. um auf dem Vertrag meine Domains zu lagern.

          da muss ich dann wohl mal ran…

          • Bernd B. sagt:

            Feste IP aus einem "DialUp"-Range ist eh nicht sinnvoll für MXout, weil bei den arroganten 'Grossen' (ganz vornweg MS) oft pauschal ganze entsprechende Subnetze geblockt sind (ohne das es auf public BLs stünde).
            Auch die IP-Ranges vieler VPS übrigens, deshalb zuerst mal die IP checken, bevor Sie sich die Arbeit machen – da eine einzelne IP whitelisten zu lassen dürfte eine Sisyphusaufgabe sein.

          • Olli sagt:

            Doch 1&1 bittet seit einigen Jahren auch feste IPs.

    • Pau1 sagt:

      es war früher wohl möglich sich mit einem Account anzumelden und dann mit diversen domains E-Mails zu versenden, auch wenn einem diese Domains gar nicht gehörten?
      (Da war doch neulich auch Hack mit zusätzlichen Email headern).
      Das war für Spammer ideal.
      Für den Provider stellte sich das Problem, wie er SPF und DKIM einrichten sollte.
      Er konnte ja schlecht in alle 3 Millionen Domains die er hostet in den SPF die gleiche Domian eintragen, wie es Microsoft macht(Microsoft trägt einfach alles was sie so an Netzen haben in den SPF ein…).
      Ich vermute Mal das das der Hintergrund für diese Unbequemlichkeit ist.

    • Martin Feuerstein sagt:

      Hab bei deiner Frage nochmal über das Thema nachgedacht…

      Ich hab bisher Exchange SBR von Tuescher.net eingesetzt, auf Multisendcon bin ich auch schon mal gestoßen.

      Mir fallen noch ein paar Möglichkeiten/Produkte ein, hab das aber noch nicht selbst getestet. Ich nehme deinen Post daher auch nochmal als Denkanstoß zum Ausprobieren:
      – hMailServer (setze ich an verschiedenen Standorten derzeit als POP3-Abruf-Connector ab)
      – Proxmox Mail Gateway
      – Xeams (ehemals Synametrics SMTP Gateway, das war kostenlos), gibts als kostenfreie/eingeschränkte Community-Edition.

  5. bon-go sagt:

    Ja, das mit IONOS kann ich bestätigen. Bei einem Kunden von uns wird seit dem 29./30.01.2024 für jede E-Mail Domain ein dazu passender Smarthost benötigt. Ein Smarthost für mehrere unterschiedliche E-Mail Domains – wie bisher dort im Exchange als einziger Sendeconnector hinterlegt – funktioniert seitdem nicht mehr, auch wenn die Domains im gleichen Vertrag liegen. Wir haben nun in einer vorgeschalteten VM im eigenen Netzwerk einen Proxmox Mail Gateway dafür installiert und der tut es.

  6. Ralph D. Kärner sagt:

    Okay, ich verstehe es nicht, vielleicht kann mich ja mal jemand abholen. Exchange ist doch ein vollwertiger Mailserver, oder kriegt der noch die Flasche? Wieso braucht ein vollwertiger Mailserver bitte einen Smarthost?

    • Olli sagt:

      Der Exchange braucht das nicht, aber weil z.B. T-Online der Meinung ist Betreibern von "kleinen" eigenen Mailservern pauschal aus Prinzip das Zustellen zu verweigern ist es halt schmerzfreier über einen Smarthost zu senden, der von vorne herein eher nicht geblockt wird.

      • Exchadmin sagt:

        Wir haben keine Probleme an T-Online per DNS zu versenden, obwohl nur eine statische IP und kein IP-Netz vorhanden ist.

        • Olli sagt:

          Da sagt T-Online:

          host mx01.t-online.de [194.25.134.72]
          SMTP error from remote mail server after initial connection:
          554 IP=xyz – None/bad reputation. Ask your postmaster for help or to contact tobr@rx.t-online.de for reset. (NOWL)

          uns nein mein Server hat keine "bad" reputation, aber aus Sicht von T-Online eben eine "None" reputation – und da ist das Verhalten pauchal abzulehnen, einfach weil man einen Host nicht kennt schon ziemlich dreist.

          • Matschmeer sagt:

            Hatte das Problem mit t-online ebenfalls. Habe an die genannte Mailadresse geschrieben und meinen Mailserver beschrieben. Am nächsten Tag kam eine höfliche Antwort und wiederum tagsdrauf hat es mit t-online funktioniert.
            Immerhin.

            • Olli sagt:

              Ändert nichts daran, dass es dreist ist um nicht zu sagen Diskriminierung. Wenn das alle Mailserver Betreiber machen würde, könnte man Mail abschalten – aber auch die c't hatte vor kurzem das Thema Entwicklungen bei den Mailservices im Test und geschrieben, dass e-Mail auf dem besten Weg ist tot zu sein.

              Abgesehen davon: bekommt jemand ein Impressum angezeigt, wenn er mx00.t-online.de, mx01.t-online.de, mx02.t-online.de oder mx03.t-online.de im Browser aufruft? Sollte T-Online vielleicht mal die eigenen Kriterien bei sich selbst erfüllen?

          • JohnRipper sagt:

            T-Online war doch schon immer schwierig. Wie gut, dass der Service an Relevanz abnimmt.

      • Daniel A. sagt:

        Dafür landen deren Ausgangsserver auch immer mal wieder auf Blacklist. Erst diese Woche den Fall gehabt, dass ein Kunde (mit eigener Domäne) anscheinend bei T-Online gehostet wird und unser System hat teilweise Mails abgelehnt, weil "mailout12.t-onlie.de" auf drei Blacklists stand. Aussage Telekom: Dann sollen die Empfänger (also wir) die Telekomserver auf eine Whitelist setzen, damit das nicht geprüft wird.
        Äh, ja ne, ist klar Telekom. Aber selbst Mails nur von bekannten Servern annehmen wollen.

        • Olli sagt:

          T-Online gehört doch gar nicht mehr der Telekom – das ist sowieso schon lange irreführend – eigentlich sollte man die Zwingen entweder wieder von der Telekom betrieben zu werden oder den Markennahmen aufzugeben und zu löschen ;)

  7. icke sagt:

    Vielleicht etwas OT, aber als ich Vodafone gelesen habe, kam gleich wieder die Frage hoch: Bei mir gab es seit Sonnabend nun schon ie dritte Komplettstörung bei Kabel-Internet und -Fernsehen (Sonnabend früh für 2-3 Stunden, Montag Nachmittag für etwa anderthalb Stunden, heute nun von 9 Uhr bis 17:30 Uhr). Der Nachwuchs ein paar Häuser weiter hat ebenfalls Kabel-Internet per Vodafone. Da war's das gleiche.
    Bisher lief das seit ca. 15 Jahren recht zuverlässig, aber so ist das nicht tragbar.
    Weiß da jemand mehr dazu? Gab es auch woanders Störungen?

  8. Pau1 sagt:

    Remote Server returned '554 5.0.0 '

    Deutet auf Problemen mit Exchange Online hin. Die erste Problem-Mail wurde am Sonntag verschickt und die
    Unzustellbarkeitsmeldung zur Nachricht kam exakt 72 Stunden danach. Wer weiß schon, was er vor 72 Stunden für Mails verschickt hat.

    Das sind mehrere Fehler.
    Zum einen sollte man heute keine retries über Tage machen Das stammt aus der Steinzeit, als man eMails noch per uucp und Modems transportiert hat.
    Heute erwarten die Absender "real time", also dass die E-Mail innerhalb von max. 2..3 Minuten zugestellt wurde oder eine Fehlermeldung kam.
    Hier wurde 77 mal erfolglos versucht zuzustellen und nach 3 Tagen das Versuchen aufgegeben und eine Bounce mail erzeugt.
    Der Zahlen-Salat könnte eine Message ID sein mit der man die originale Email in seinem Log finden könnte.
    Also bitte den Betreiber des Relays bitten, keine wiederholten Zustellversuche zu machen.
    Ja, das ist schlecht für die Empfänger die irrtümlich immer noch glauben per "teergrube" Spammer abhalten zu können.

    Der Server mit der 193 ist oder tut so als sei er überlastet. Da müsste man sich auch an den admin wenden Es solltet "postmaster@193…" oder abuse@ funktionieren. Evtl. direkt per Telnet in den SMTP eingetippt. Ein guter Postmaster spricht SMTP…
    Sonst kann man via Denic eine Nachricht an den Besitzer der Domain schreiben.
    Vermutlich ist dieser sich des Problems gar nicht bewusst, weil manchmal Emails ja durchkommen.
    Besonders übel ist es bei uralten Systemen, die mehrere Host als MX eingetragen habe, wie es in den 80er empfohlen wurde.
    Wenn ein MX nicht erreichbar war, wurde die Mail mit der IP auf den Spool gelegt und immer wieder nur diese IP verwendet. Bescheuert, aber war so um die kostbare Resource "DNS" zu schonen. Damals gab es aber noch keine Krücken, die ihren MX auf eine Dynamischen IP legten…(Mail empfangen auf einer dyn. IP ist prinzipiell erlaubt und kein Problem, wenn die Email auch mal verzögert werden darf.
    Versenden von dyb.IP ist per Konvention heute tabu.)

    HTH

    • Bernd B. sagt:

      JAIN.
      Der Fehler hier war, auf einen 5xx-Fehler ("permanent error") hin nicht sofort abzubrechen. Retries sind hingegen legitim bzw. empfohlen, wenn man 4xx-Fehler ("temporary error") erhält.

      Hab lange nicht mehr in die RFC geschaut, IIRC ist das sogar so vorgeschrieben.

      • Pau1 sagt:

        ja, es steht in den RfC.
        Da steht vermutlich auch noch, das es zum guten Ton gehört, E-Mails für jede Absender-Domain zu relayen und keine Beschränkung bzw. der Annahme von Emails von dyn. IP.

        Aber das mit den retries bei 4xx sollte man heute unterlassen, weil die User damit einfach nicht umgehen können, und zur Not dann halt telefonieren oder faxen können oder es mit einer anderen Adresse bei einem Kollegen der nicht im Urlaub ist und dessen Postfach nicht randvoll ist m
        Es war damals schon einigermaßen sinnlos, nach einer Woche noch einen Bounce zu bekommen.
        Der Kunde, ob wohl er es selbst verbockt hat war stinke sauer dass man sich so viel Zeit gelassen hat.

        der 5xx kam davon das man es 77 mal mit 4xx Resultat probiert hat und der Text nicht so exact war.

        • Bernd B. sagt:

          "Aber das mit den retries bei 4xx sollte man heute unterlassen, weil die User damit einfach nicht umgehen können"

          ???
          Der User bekommt doch vom retry des Servers gar nichts mit (war nicht genau das Ihre Reklamation ("72h!!!")?!) und die Retries sind immer noch essentiell, insb. da Graylisting sich nach wie vor grosser Beliebtheit erfreut, aber auch, weil ein kurzer Netzunterbruch, Routingproblem, … keinen NDR erzeugen sollte!
          Der Postmaster ist immer noch gemeiner Dienstleister, der sich auf Nutzenmaximierung fokussieren sollte – insb. aber nicht auf Dogmatismus.

          P.S. "MB randvoll" == 5xx, sonst ist der MXin fehlkonfiguriert.

          • JohnRipper sagt:

            Es gibt Mailserver die Emailverzögerungen zurückmelden.

            Also: Die E-Mail konnte nicht zugestellt werden wegen Fehler xyz. Es wird 72h weiter Versucht.

      • Pau1 sagt:

        Remote Server returned
        '554 5.0.0 '

        193.34 hat ein Problem und möchte den Anfragen hängen lassen (beachte das "-" hinter der 451#
        das Problem besteht seit 77 attempts und dauert 72h.

        was den 451 ausgelöst hat wird nicht gesagt.
        Ist auch egal. Man verwirft sofort und verbrät nicht noch mehr Bandbreite und Rechenzeit.

        Warum sollte man 72h warten?
        Worauf?

        • Bernd B. sagt:

          Wirkt auf mich recht wirr (fehlt da Kontext?) und soviel Rage, statt den Verantwortlichen zurechtzustutzen?

          Und ist ein Einzelfall, das individuelle Versagen eines einzelnen Postmasters, wirklich in irgendeiner Form themenrelevant?

        • Ralph D. Kärner sagt:

          Der Verantwortliche für den Mist ist hier einwandfrei Winzigweich, die mal wieder was verkackt haben. Betroffen ist ausschließlich das bayrische Behördennetz. Die zitierte Fehlermeldung oben ist die "Mail unzustellbar" Email, die den letzten Liebesgruß dieses Zustellversuches darstellt. Der Admin des sendenden Servers kann nichts tun, weil er nicht direkt senden kann, sondern den Weg über das bayrische Behördennetz ins öffentliche Netz nehmen muss.

          Irgendjemand anderer Meinung, was meine Analyse angeht? Dann seid so nett und korrigiert mich.

          Pau1, Du sprichst Bullshit. Zum einen ist die Geschichte mit dem "server busy, please try again later", die 76 Mal vor diesem letzten Liebesgruß passiert sein wird, ein vollständiger Automatismus, den man ganz sicher nicht verbiegt. Was der Enduser wie schnell will, ist nämlich an der Stelle gar nicht releveant. Der User will, dass seine Mail ankommt. Der Mailserver regelt das. Nach rfc. Und wenn Du sofort verwirfst, nachdem der erste Zustellversuch (gern wegen greylisting) nicht geklappt hat, dann hast Du ein Problem an Deiner Tastatur und nicht der Email sendende Benutzer oder der annehmende MTA.

          Ich hatte Dich schon einmal gebeten, das zu lassen, Deine Annahmen und Deine Praktiken als "best use" und als "default today" zu verkaufen. Das ist schlicht nicht hilfreich, zumal die arme Sau von Admin am Sender-Server gar nichts tun kann. Der ist gezwungen, darauf zu warten, dass IT-DLZ mit dem Nagelbrett in der Hand den richtigen Deppen bei M$ so trifft, dass die das wieder gerade biegen, was sie versaut haben.

  9. Superduper sagt:

    Als betroffene bayerische Behörde stehen wir ziemlich dumm da, denn das IT-DLZ kann nichts machen und nicht sagen wie lange die „Blockierung/Limitierung" seitens Microsoft anhält. Da merkt man erstmal wie viele Leute Exchange Online nutzen.

    • Günter Born sagt:

      I know, wurde aber vom Tipp-Geber gebeten, das nicht so 1:1 zu publizieren.

      • WEISSNIX sagt:

        Zumindest Empfänger, die häufig E-Mails von bayerischen Behörden erhalten, könnten per EOP (Exchange Online Protection) die IPs des Bayerischen Mail-Relay auf eine White-Liste setzen, danach ist läuft die Kommunikation wieder.

        • Pau1 sagt:

          Verhindert auf jeden Fall spontane Anschreiben durch die bayerischen Behörden.
          Das will mal.
          Email als Lotterie Spiel.
          Die Bank gewinnt immer.

          Die Leidensfähigkeit von Microsoft-Kunden ist erstaunlich.

          • Ralph D. Kärner sagt:

            Sind wir mal ehrlich: Dank diverser "consultants", die über Jahre den Schrott aus Redmond als einzige wahre und unverzichtbare Lösung für jedes Problem schön gesungen haben, hat der Microsoft-Kunde heutzutage doch gar keine andere Wahl mehr, als zu leiden. Ob er will oder nicht. Schließlich hat die Umstellung von On Premises in die Cloud eine Menge Geld gekostet. Die auf dem Papier aufgemalten Synergieeffekte und vor allem die Einsparungen sind noch lange nicht erreicht, und jetzt soll man dann wieder zurück rudern, damit man selbst dafür verantwortlich ist, wenn man nicht per Mail erreichbar ist?

            Das wissen wir doch beide, dass eher die Hölle zufriert, als dass das passiert. :-)

        • Ralph D. Kärner sagt:

          Diese Empfänger (ich nenne sie mal "Architekten", "diverse Gewerke auf einer behördlichen Baustelle", "Dienstleister außerhalb des IT-Bereichs, gern auch KMU mit eher K als M") haben, so sie bei M$365 gelandet sind, gar keine Ahnung, wie man so etwas tut bzw. dass man so etwas tun kann. Diese Empfänger merken auch nicht sofort, dass sie keine Emails mehr empfängen von diesem Absender.

    • Luzifer sagt:

      Problem wurde laut IT-DLZ am 16.02.24 um 10:30 Uhr von Microsoft behoben…..

      • Anonymous sagt:

        Funktioniert jedoch immer noch nicht. Das IT-DLZ betont, dass das Problem bei Microsoft liegt und man absolut nichts machen könne.
        All die Teilnehmer des Bayerischen Behördennetzes, die die Email-Infrastruktur des IT-DLZ nutzen, schauen nun also erstmal in die Röhre und dürfen sich selbst um zusammengefrickelte Notlösungen kümmern.

        • Anonymous sagt:

          Einen Tag später kommen immer noch Verzögerungs- bzw. Unzustellbarkeitsbenachrichtigungen bei Emails in Richtung Microsoft.
          Die Liste der Domains, die über einen separaten Sendeconnector im Exchange direkt über den Internetanschluss (am IT-DLZ vorbei) versendet werden müssen, wird immer länger. :-)

  10. Detlef Bracker sagt:

    Ja, wenn ein großer Anbieter, wie Microsoft seinen Laden nicht mehr im Griff hat, dann muß er sich nicht wundern, daß alle Empfangs-Server ihn auf Blacklisten setzen und er seine Mails nicht mehr raus bekommt!

    Ich habe ein erschreckendes Video gemacht, nachdem ich als Admin Virus-Warnungen von unserem Mail-Gateway bekam und diesen nach gegangen bin, den Skandal findet Ihr hier im Video: https://youtu.be/oENudGiPqxs

    Es hat viel Zeit gekostet, den Vorgang zu untersuchen. Zeit, die ich von Microsoft nicht bezahlt bekomme und die nicht das erste mal, nur weil Microsoft Mist baut, entstanden ist! Im Moment häuft sich das ganz extrem. MS ist ein Laden, der macht was er will!

  11. Arne Schiedt sagt:

    Mußte heute feststellen, daß ein Mail-Versand von beliebigen @web.de, @Gmx.__ oder auch bei IONOS gehosteten Dmoins zu beliebigen bei Microsoft office365 gehosteten Domains nicht funktioniert. Es kommen keine Fehlermeldungen zurück, auch nach Tagen nicht. Der Versender geht davon aus, das seine Rechnungen – Angebote usw angekommen sind. Da auch nicht ersichtlich ist das es die leidigen office365 Konten betrifft.
    Ich habe keine Idee mehr, da es ja keine Ansatzpunkte gibt :-((

  12. Stefan sagt:

    Wir haben hier (Bayern) seit ein paar Tagen auch Probleme – sporadisch kommen Mails nicht an. Sind scheinbar spurlos verschwunden, nicht im Spamordner o.ä., der Absender erhält auch keine Nachricht darüber, dass die Mails nicht zugestellt werden konnten.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.