Kurzer 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.
Anzeige
Ä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?
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.
Anzeige
Eine Mail von 1&1 zu Freenet hat von Sonntag 16:00 bis Dienstag 13:00 benötigt.
Was sagen denn die Mailheader, wo es konkret hing?
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."
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".
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.
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.
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.
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).
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/
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…
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.
Doch 1&1 bittet seit einigen Jahren auch feste IPs.
jaein. In diesem Fall nicht.
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.
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.
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.
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?
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.
Wir haben keine Probleme an T-Online per DNS zu versenden, obwohl nur eine statische IP und kein IP-Netz vorhanden ist.
DNS?
Exchange löst per DNS den zuständigen MX selbst auf und stellt direkt per SMTP zu und eben nicht über den Umweg eines Smarthost.
Ich weiß wie E-Mail grds funktioniert, aber wieso nennt ihr das DNS?
DNS ist ein vollkommen anderer Dienst.
Weil es im Exchange Dialogfeld mehr oder weniger so heißt und sich "Senden via DNS" als geflügeltes Wort eingebürgert hat.
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.
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.
Ä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?
T-Online war doch schon immer schwierig. Wie gut, dass der Service an Relevanz abnimmt.
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.
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 ;)
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?
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
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.
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.
"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.
Es gibt Mailserver die Emailverzögerungen zurückmelden.
Also: Die E-Mail konnte nicht zugestellt werden wegen Fehler xyz. Es wird 72h weiter Versucht.
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?
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?
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.
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.
I know, wurde aber vom Tipp-Geber gebeten, das nicht so 1:1 zu publizieren.
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.
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.
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. :-)
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.
Problem wurde laut IT-DLZ am 16.02.24 um 10:30 Uhr von Microsoft behoben…..
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.
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. :-)
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!
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 :-((
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.
Hallo ihr netten SMTP ler,
ich bin dem Problemen schon länger auf der Spur, und es bei den ersten 90% [ist die Lösung] relativ einfach wenn man die Spielregeln kennt.
– Bei mehreren IP`s darauf achten das die gehende Adresse mit dem PTR Record übereinstimmt.
– Im Notfall S-Nat Eintrag in der Firewall setzen. Dann PTR prüfen.
SPF sollte immer vorhanden sein, und DMARC ist bei fast Mailanbietern Pflicht. DKIM ist "nice to have" da man ja ein par mehr Infos für die versendeten Mails bekommt.
Ich würde es auf jeden Fall empfehlen. Selbst mit dem Fachwissen ist es möglich das Mails nicht angenommen werden.
Viele Anbieter haben er mal alle IP Ranges geblockt (z.B t-online.de) und wenn man dann eine Mail an postmaster** sendet und mit mxtoolbox.com Protokoll anschaulich macht, das alles richtig ist, bekommt man eine Freischaltung, wenn ein Impressum mit der Mail seiner Domäne *.*de existiert.
Steht in keiner RFC aber wird trotzdem gefordert.
550 5.7.25 Client host rejected: cannot find your hostname, [xxx.xxx.xxx.xxx]
das kommt jetzt von mx2.vodafonemail.de. Ich frage mich, was die da machen, mit ihren DNS Servern? Kennt jemand die Mail vom Postmaster vodafonemail.de, oder hat jemand eine Idee, wie Vodafone-Mail das macht, um die Leute zu verärgern.
Ich hoffe ich konnte etwas helfen. Ach so wenn es Blacklist Einträge gab bei RBL`s dann können diese fast immer entfernt werden wenn der Rest i.O. ist. Die Regel lautet:
A MX SPF DMARC DKIM im DNS und Firewall
und dann sollte es bis auf wenige Ausnahmen klappen. Und da muss in der Regel der Postmaster angefleht werden zu Whitelisten. Hier ein Beispiel von T-Online ( Vielen Dank für Ihre Nachricht. Wir werden veranlassen, dass die Reputation dieser IP-Adresse in unseren Systemen resettet wird. (Berücksichtigen Sie bitte, dass es je nach Systemlast bis zu 24 Stunden dauern kann bis die Änderung wirksam wird, erfahrungsgemäß dürfte dies allerdings in ein bis zwei Stunden erledigt sein.) Mit freundlichen Grüßen Deutsche Telekom AG)
MFG
—————–
GB: Danke für die Ergänzung. Ich habe den Kommentar zur besseren Lesbarkeit etwas umformatiert.
Hallo, ich habe folgende Spielart eines Problems mit IONOS:
Wir erhalten bei folgender Kombi den Fehler "554 Unauthorized Sender Address"
In Microsoft Outlook 365 Client eingerichtet:
– MS 365 Exchange bei Microsoft mit Domäne bei Hoster XY 'exchange@contonso.com'
– IMAP Konto von IONOS 'extern@ionos-domain.de'
Wird nun im Exchange Kalender exchange@contonso.com ein Eintrag angelegen und einen Teilnehmer eingeladen gibt es die Möglichkeit, diese Einladung über das IMAP Konto zu versenden.
VON Dropdown -> Konto extern@ionos-domain.de' auswählen.
Diese Termin-Einladung wird von IONOS blockiert und nach vielen Stunden mit dem Tech-Support von IONOS (und Microsoft) gibt es von beiden Seiten ein 'won't fix'.
Getestet mit unterschiedlichen MS365 Tenants.
Der Versand mit IMAP Konten anderer Hoster ist kein Problem.
Kurzes Feedback zu unserem Problem, vielleicht hilft es ja jemandem:
In den Outlook Kontoeinstellungen des Exchange Postfachs unter Erweitert "Verbesserung für geteilte Kalender aktivieren" deaktivieren. Dadurch scheint der Header nicht manipuliert zu werden.
Thank you for nothing, Microsoft.