Ich stelle mal eine Beobachtung eines Blog-Lesers hier ein, die sich auf Microsofts Exchange Online bezieht. Der Leser sieht sich mit dem Problem konfrontiert, dass Beschwerden von Geschäftspartnern über nicht „angekommene“ E-Mails auflaufen. Der Verdacht, dass Exchange Online die E-Mail-Absender vielleicht manipuliert, steht im Raum.
Ein Blog-Leser hatte sich bereits zum 13. Dezember 2024 bei mir per E-Mail gemeldet und schrieb unter dem Betreff „Microsoft Exchange Online verändert Absender?“, dass er im Unternehmen im Moment immer mehr Beschwerden bekomme, das E-Mails nicht beim Partner ankommen.
Die IT ist dann diesem Problem nachgegangen. Nach Recherchen hab man herausgefunden, schreibt der Leser, das als Absender immer eine MS Cloud IP in den betreffenden Mails steht.
Im Unternehmen werden aber die E-Mail-Server nur On-Premises betrieben. Alle Logs zeigen, so der Leser, dass die Mail das im Unternehmen betriebene E-Mail-System verlassen hat und erfolgreich bei Exchange Online eingereicht wurde.
Da das Unternehmen eine strikte SPF-Richtlinie eingerichtet hat, wird die Mail als SPAM verworfen, gibt der Leser an. Sofern jemand „schon bei MS in der Cloud sitzt und die Kommunikation von Microsoft zu Microsoft (Exchange Online-Postfächern) stattfindet, sei das egal, da ja die Microsoft IPs in den SPF-Einträgen steht.
Der Leser merkt an, dass man die SPF-Richtlinie jetzt aufweichen könnte, bis Microsoft das gefixed hat. Aber dann macht auch eine Blockierung von Mails über Blacklistening keinen Sinn, schreibt der Leser und begründet dies damit, dass auch immer mehr Microsoft IP-Adressen in diesen Sperrlisten landen. Der Leser fragt: „Sind wir die einzigen die so was beobachten?“
Ergänzung: Auf Facebook gab es folgende Anmerkung „eine spontane Vermutung: beim Einrichten des EXO-Connectors vergessen den Haken „Header beibehalten“ zu setzen.“ Auf BlueSky gab es noch den Hinweis von Frank Carius „Also das wäre neu. Es gibt aber eine Fall: der Absender ist beim Ziel als Kontakt und die Mail über einen inprwm Connection ankommt.“ Das Thema ist noch in Klärung.
Ich verstehe das Problem nicht aus dem Text ;)
Alle Logs zeigen, so der Leser, dass die Mail das im Unternehmen betriebene E-Mail-System verlassen hat und erfolgreich bei Exchange Online eingereicht wurde.
Dann steht doch eine Exchange Online IP in dem Absender, wenn dieser es an dem Empfänger Server gibt.
Ich glaube das ist etwas missverständlich formuliert.
Der Sender hat Exchange nur OnPrem.
Der Empfänger nutzt Exchange Online.
On Prem sendet laut logs alles sauber raus, ExO ist Empfänger.
Der soll jetzt mutmaßlich den Absender ändern.
Erschließt sich mir aber auch nicht, denn die SPF Prüfung würde ja genau dieser Empfänger ExO Server machen.
Nutzt man natürlich ExO im Hybrid oder als Smarthost, dann ist die das works as designed.
das spf schlägt beim Empfänger zu. Logo. und nicht beim Transport Server des Absenders.
es gibt eine FAQ E-Mails Header verstehn“ Ich glaube da wird das mit SPF ganz gut erklärt.
hier müsste der Absender seinen SPF kastrieren, oder alle potentiellen Empfänger sich nur nur noch auf DKIM verlassen(was deutlich besser ist als SPF,da MS ja Millionen IP aus eigener Bequemlichkeit mit in den SPF einträgt und ihn so wirkungslos macht.)
wenn das wirklich ein Problem bei Microsoft ist, dann sollte man schnellstens von diesen Saft laden weg.
nicht alle Kunden machen sich die Mühe zurück fragen wo denn die E-Mails bleiben. Und neue Kunden schon gar nicht
aber andererseits muss eigentlich auch der Absender Bescheid bekommen, wenn seine E-Mails rejected werden, mit einem lauten Alarm.
oder muss man sich den Zugriff auf diese Log Einträge teuer erkaufen?
wo bleiben denn die NDR?(bounce mail)
Achso, die können nicht zugestellt werden, weil MS ja den Absender verhundst und keine Sau im Error Log nachsehen kann, da Aufpreis pflichtig.
da ist ein richtiges Konzept hinter… aber welches?
zurück zum Telefon?
Aber was hat MS damit zu tun wenn der Empfänger seine config nicht im griff hat. So ein verhalten kenne ich nur von falschen connector Einstellungen oder falsche hybrid Umgebung. Da bekommt die email nochmal einen releay host dazwischen und dann schlägt die spf fail das ist korrekt.
„Spamfilter Problem.
Nur dass hier alles fehlt was man braucht zum debuggen. Also Fehlermeldung, IPs, usw.
Übrig bleibt dir Glaskugel, und die sagt Schnee.“
Ich selbst verwende eigenen Server, und habe nichts mit Microsoft am laufen außer Windows auf dem PC Client. Es reicht also dass der Empfänger Exchange/Azure Zeugs verwendet. Manchmal ist aber auch noch ne Amazon oder Oracel IP bei, was auch immer diese da zusuchen hat bei Outlook Business.
Bei kurzem Überfliegen hat Microsoft wohl meine Email an Outlook Business über 104.47.11.41 oder 104.47.17.171 zugestellt was zu spf fail führt wenn man sich mal DMARC Berichte anschaut. Ist aber normal nicht problematisch da ja DKIM signiert sind.
Wer also Probleme vermeiden möchte trennt sich mal endlich von Microsoft, Google und Amazon Cloud Zeugs. Bisschen Postfix und Dovecot sind kein Hexenwerk und laufen hervorragend. Da bedarf es kein Exchange Zeugs. Gibt da auch Alternativen, und dass sogar ohne Abokosten. Aber Cloud ist ja der „heiße Scheiß“… da machts auch KI nicht besser…
Dem kann ich nur zustimmen. Es erschliesst sich mir einfach nicht, wie gerade Unternehmen, die über Ressourcen und Möglichkeiten verfügen, nicht im Stande sind, eigene Mailserver zu betreiben. Mit richtig eingerichteten Mailservern und vor allem strikten SPF/DMARC Policies schafft man auf einen Schlag Vertrauen in das Medium EMail und beseitigt gefühlt 95% aller Spam und Phishing Versuche nicht nur bei sich im Hause sondern auch bei Zulieferern/Kunden.
Nunja, ganz so einfach ist es dann doch wieder nicht. Es gibt Mail-Provider, die nehmen nur von den großen Anbietern E-Mails entgegen, da guckt man dann mit seiner Maschine (und IP) doof aus der Wäsche, wenn man an den Anbieter keine E-Mails senden kann.
Zumal muss auch eine auf Linux Infrastruktur gewartet werden, dafür benötigt man Personal und Zeit. Es gibt etliche Firmen, die sich diesen Klotz nicht ans Bein binden möchten.
Dann die größte Hürde: Microsoft Outlook. Man muss kein Fan davon sein, jedoch ist das gerade im geschäftlichen Umfeld der defacto Standard. Muss man nicht mögen, aber das ist (leider) die Realität. Das wird nochmal komplizierter, wenn sich Fachsoftware in Office Produkte integriert (wir hatten es die Tage hier im Blog mit DATEV). Dann kommt aus der Abhängigkeit zu Microsoft Outlook nur sehr schwer bis gar nicht mehr raus. Microsoft Exchange Server zu administrieren macht solange Spaß, bis man Updates installieren muss. An dem Punkt sagen sich viele, dann soll Microsoft den Krempel betreiben und gut ist.
> Nunja, ganz so einfach ist es dann doch wieder nicht. Es gibt Mail-Provider, die nehmen nur von den großen Anbietern E-Mails entgegen, da guckt man dann mit seiner Maschine (und IP) doof aus der Wäsche, wenn man an den Anbieter keine E-Mails senden kann.
Blödsinn und Falschaussage!
Ich betreibe seit 10 Jahren für eine handvoll Kunden und mich meinen eigenen Mailserver, da hat noch niemand eine Mail abgewiesen.
> Zumal muss auch eine auf Linux Infrastruktur gewartet werden …
mit deutlich weniger Aufwand als den Klicki-Bunti Windows-Schrott, der kaum zu automatisieren ist.
> Microsoft Outlook… defacto Standard…
So what? Active Sync mit Sogo und gut ist…
>Blödsinn und Falschaussage!
>
>Ich betreibe seit 10 Jahren für eine handvoll Kunden und mich >meinen eigenen Mailserver, da hat noch niemand eine Mail >abgewiesen.
Mach mal halblang. Google mal „Telekom abgelehnte Mails vom eigenen Mailserver“.
> mit deutlich weniger Aufwand als den Klicki-Bunti Windows->Schrott, der kaum zu automatisieren ist.
Das kann nur jemand behaupten der davon aber mal so gar keine Ahnung hat. Die Aussage disqualifiziert dich aber mal komplett. Gerade mit Windows 10/11, Windows Server 2016/2019 und der neuen PowerShell ist die Automatisierung unter Windows besser denn je.
Oh Boy, man sieht, Du hast keine Ahnung: Google mal „Telekom Voraussetzungen Mailserver“. Da wirst Du einige Vorraussetzungen finden wie z.B. eine Website mit Impressum auf die jeweilige Domain etc.
Ich möchte (zum wiederholten Male) als Linuxer mich von Tomas Jakobs distanzieren. Diese Art ist kein Umgang.
Auch ist anzumerken dass es, da wo Geld verdient wird keine „eigenen Mailserver“ gibt.
Ein Niemand, der sich selbst zum Linux-Repräsentant erhebt und sich distanzieren will. Deine überhebliche Art ist ebenfalls keiner.
Ich bin aus diesem Thread raus.
Dummschwätzer gibt es genügend…
Es geht nicht um können, sondern wollen.
Und ein Mail System korrekt zu betreiben ist mehr Arbeit als einen MTA wie postfix einmal zu installieren. Ein MTA ist auch nur ein sehr kleiner Teil von dem was Exchange zur Verfügung stellt. So toll und unproblematisch dovecot funktioniert, so eingeschränkt sind am Ende die Möglichkeiten für alles was komplexer wird.
Es scheitert schon daran, dass der postfix keine Mail-Logs nach User Sessions kann, man also jedesmal wenn man eine Mail sucht, erstmal reverse engineeren muss, wie die Mail zugestellt wurde, anstatt beim Empfänger auf auf Zustell-Protokoll zu gehen, und das unter einmal den Weg zu sehen, von irgendwelchen smtp-proxys und miltern reden wir besser nicht.
Und ja.. Kunden von mir haben tatsächlich Mitarbeiter im Support Callcenter für Online Shopping, die aktuell sehr wohl in Echtzeit auch das E-Mail log einsehen können, um Kunden bei .. „Ich hab das Mail nicht bekommen“ Situationen sinnvolle Auskunft zu geben.
Früher gab es mal passende Kommentare hier die man als Hilfe verwenden konnte. Mittlerweile sobald irgendwie MS im Title der Artikel ist, kommen immer die selben Kommentare von den selben Personen angezogen, die einem natürlich als einzige Professionelle Lösung das Abschalten jeglicher MS Produkte wieder und wieder nahelegen. Aber nicht eine Lösung die dem Topic oder Problem irgendwie weiterhelfen könnte. Das ist wie wenn man einen Dienstleister hat der nur seine eigene Scheiße Verkaufen will und kann.
Ist leider das gewohnte Bild. Mir stehen nur die im Text gegebenen Informationen von Leserseite zur Verfügung. Und im letzten Satz war die explizite Frage des Betroffenen, ob es weitere Admins, die das beobachten, gibt.
Aktuell stelle ich fest, dass sich kein weiterer Betroffener bisher gemeldet hat (ok, ist Wochenende, kann also noch kommen). Falls es Einzelfall bleibt, würde das bedeuten, in die Konfigurierungen zu gehen und zu schauen, ob da was falsch eingetragen ist.
Aber es gibt sehr viele Vermutungen und ein Flame-Ware, was imho niemanden weiter bringt. Schade.
es ist halt schlimm, dass man inzwischen erstmal den Fehler bei MS vermuten kann oder muss.
vielleicht ist auch bedenklich dass Grundlagen wissen zu fehlen scheint.
um wirklich konkret helfen zu können bräuchte man die Texte der Fehlermeldungen und nicht nur deren Interpretation.
das würde auch später anderen bei der Suche helfen.
aber für einen Konsum Leser ist das noch langweiliger.
MS ist halt einfach Murks, man sieht hier im Blog, bei Deskmodder, Heise und co. wie oft es Ausfälle/Störungen gibt, Windows Updates zurückgezogen oder Probleme gibt mit Kleinigkeiten wie Netzwerk, booten, drucken usw. aber wer braucht sowas schon, besonders in Business Umgebung.
Dann kommen noch diverse Sicherheitsvorfälle, Lücken im Exchangeserver und und und. Also aus meiner Sicht schon fahrlässig dort überhaupt irgendwas zumachen.
Dabei gibt es Alternativen, wenn man keine Lust hat auf eigene Hardware, dann geht man halt z.B. zu Mailbox_org, oder wenn man eigene Hardware mag und nicht so Lust hat auf Konsole usw. holt sich z.B. ein Synology NAS, kann LDAP oder auch ganze AD Domain, hat Chat, Office Tools solange man nicht unbedingt Makros braucht, und auch Mails (MailPlus) wo man Postfächer teilen kann. Kann man sogar in Outlook (classic) verwenden, auch wenn Kontakte/Kalender notfalls per kostenlosen Plugin sync. werden müssen. In wie wie sowas geht mit Plesk/Confixx kann ich nicht sagen, aber gibt auch Lösungen auf github wie Mailcow.
Man kann also ohne Abo auskommen, einmalige Anschaffung, und etwas Pflege laufend.
Und habe oben schon geschrieben, in 1, 2 Fällen wurde meine Email mit einer MS IP „verseucht“ beim zustellen. Aber hier kommt es wohl drauf an ob man noch irgendwelche Relays zwischen schaltet von MS, Amazon, Oracle usw.
Und wenn ich bei mir schaue von wo meiste Spam kommt, ist es MS und Google.
Wenn sich Firmen sich wundern wieso beim Empfänger nichts ankommt, weil MS auf öfters auf Blacklisten steht.
Man könnte auch eine andere Sichtweise haben.
Das System das funktioniert wird viel verwendet, dementsprechend gibt es natürlich auch viele Probleme.
Wenn es nach Anzahl Benutzer geht, gibt es bald eh nur noch 2 Anbieter am Markt.
> so eingeschränkt sind am Ende die Möglichkeiten für alles was komplexer wird.
Ab hier bin ich bei Dir lachend raus…
So so Linux-Mailserver sind eingeschränkter als ein Exchange… gerade wenn es komplexer wird… sehr interessant.
> reverse engineeren
Für manche ist es Reverse Engineering, für andere normales Handwerkszeug von CLI Tools und Skripten.
Jeder hat verstanden, dass deine Weise die Dinge zu lösen für dich die beste ist.
Schwierig ist nur dass du davon ausgehst dass deine Anforderungen für alle anderen auch genügen.
Und bei uns in der Firma wurde alles zu MS verlagert, Adobe hat man sich auch ans Bein gebunden, dazu noch etwas Schlangenöl. Vor betrieb man alles im Haus unter eigener Regie. Kannst nur mit dem Kopf schütteln… Tatsache ist nun, dass es immer wieder Probleme gibt, Mails kommen nicht an, Server machen Probleme und einiges mehr.
damit ist Dein Job doch sicher :-)
ok, das die ganze Firma an Reputation verliert, wenn Kunden Anfragen nicht beantwortet werden (scheinen) wird völlig überbewertet. Hauptsache das Kontroling ist glücklich, weil es nun die ,IT Kosten auf Heller und Pfennig genau berechnen kann… Nur du störst da noch. Besonders wenn du auf Stunden Basis abrechnet. (Werte das du nicht als persönliche Anrede da sondern als Ersatz für ein diskriminierendes „man“)
> IT Kosten auf Heller und Pfennig genau berechnen kann…
by the way. Das genau kann es bei einem Abo-Modell und zudem in Abhängigkeit durch einen Dienstleister genau nicht, da dieser jederzeit ide Spielregeln ändern kann und es auch genau macht. Oder kann mir jemand ein Abo-Modell nennen, das jemals günstiger geworden ist?
ich habe jetzt einen Vertrag, der sagt zahle jeden Monat xx Euro pauschal und wir machen alles was nötig ist für deine E-Mails.
der Vertrag läuft x Monate.
das ist alles kalkulierbar.
mache ich es selbst, habe ich das Risiko dass mein Admin krank wird. also hol ich mir einen Leiharbeiter. da weiß ich aber nicht wie gut und schnell der ist.
(ich habe schon einen Deppem gesehen, der 6 Stunden gebraucht hat um einen un zu lässigen Dhcp Server mittels Klicki bunti zu erkennen.)
das meine ich mit berechnenbar.
das ich mich für Nötigungen empfänglich mache steht auf einem anderen Blatt, nicht meinem..
Da ist genau nix kalkulierbar.
Weil wenns mal nicht funktioniert, wieviel zahlt MS dann für deine Mitarbeiter die rumsitzen und Eier schaukeln.
Du ahnst es: Nix.
Von daher halte ich die Umstellung großer Firmen auf komplett Cloud für eine die Existenz der Firma gefährdende Entscheidung. Aber Lemminge sind halt toll…
Dürfte ja eigentlich nur bei denen funktionieren, die nicht über einen Connector die Mails raushauen.
Wenn der Empfänger dann nicht bei Microsoft ein Konto hat, dann wird auch keine Microsoft IP im Header zu finden sein.
Ich habe auch mehr Fragen als Klarheit, zum Beispiel über die Konfiguration auf Empfängerseite.
Ein mögliches Szenario, das ich in der Form leider auch schon sehen durfte, ist eine Exchange Hybridstellung mit Umleitung auf die @onmicrosoft.com Tenant-Adresse ohne korrekt gepflegtem Connector für den hybriden Mailfluss.
Dadurch werden die E-Mails von EXO bei Empfäng über den OnPrem-Exchange Server als extern deklariert (und nicht als unternehmensintern via Hybridstellung), dann greifen natürlich auch mehr Regeln.. ;-)
Oder aber Microsoft beginnt wieder damit eine Latte alter Server zu drosseln oder abzuweisen? Wäre auch eine weitere Möglichkeit.
Oder aber es wird im Nachgang wieder klar, dass es Probleme mit den – wo sind wir gerade dieses Jahr mit der Verfügbarkeit? – M358 Diensten gibt?
oh, gibt es schon ein Update auf M358…?
nimmt MS da nicht wieder mal den Mund zu voll?
358 Tage verfügbar?
Spamfilter Problem.
Nur dass hier alles fehlt was man braucht zum debuggen. Also Fehlermeldung, IPs, usw.
Übrig bleibt dir Glaskugel, und die sagt Schnee.
das es ein Spam-Filter Problem ist ist doch klar.
auch ein würg Arround wird genannt.
ich wüsste allerdings auch zu gerne wie genau die unzulässige Adresse aussieht und warum MS das so macht. Fas es normalerweise nicht auffällt liegt ja daran, das MS scheinst alle seine IP Adressen im spf hat und so einfach kein Problem stehen kann, weil allem, nur weil es von MS kommt traut.
in sofern ist der Beitrag nötig um mal wieder in sein errlog zu schauen, denn der , Absender kann nicht informiert werden weil MS dessen Adresse verkorkst hat (O der MS hat das mailing Listen
RFC falsch implementiert.
Wir kommen an der Stelle dummerweise nicht weiter. Zum 23.12.2024 meldet sich der Leser und schrieb, dass er bei den „Empfängern“ der abgewiesenen Mails nach Logs gefragt habe, um das Problem verstehen zu können. Er hat leider, trotz mehrfacher Nachfrage, keine Log-Dateien erhalten.
Mir liegt ein Screenshot vor, den ich aber nicht veröffentlichen darf. Dort wird ausgeführt, dass DMARC und SPF einen Fehler liefern. Diese Information kommt von einer IP, die zu Microsoft gehört und nicht mehr der erwarteten IP entspricht. Daher die Verwirrung, ob Microsoft Exchange die IP-Adressen ändert.
Wenn er es debuggen will, würde ich vorschlagen er legt sich eine free mail Adresse an, z.b. Gmail/GMX schickt sich ein Mail, und sieht in den Mail Headern nach welchen Weg die Mail genommen hat. Wichtig hier sich Zeit nehmen zu verstehen, und nicht voreilig Schlüsse ziehen .
SMTP Logs können auch auftreten wenn z.b. die Outlook App prüft ob ein Empfänger Mailserver die Mail überhaupt annehmen würde. Auch Spam Filter testen das. Die sagen deshalb quasi nie was aus.
zur Klärung
die Adressen die im spf stehen sind in der Regel „White Listed“ und somit ist das wo Microsoft seine Adressen einträgt(um Service Fälle zu vermeiden sehr großzügig) keine „Sperr Liste“ sondern eine „White list“, zumindest in meiner Welt
Wir haben bei uns festgestellt, dass Microsoft Outlook beim weiterleiten von Termineinladungen den Absender so verändert, dass der Absender dem Organisator des Termins entspricht.
Angenommen weiter@leitung.com sendet den Termin von org@nisator.net an empf@nger.de sieht der Mailserver von empf@nger.de als Absender org@nisator.net und prüft auf dessen SPF.
Da die Mail aber effektiv über die Server von weiter@leitung.com schlägt die SPF Prüfung ziemlich sicher fehl, es sei denn org@nisator.net und weiter@leitung.com nutzen die selben Mailserver.
Sprich nutzen beide Office365 und haben entsprechende SPF Einträge, kommen die Mails erfolgreich an.
Passen die SPF Einträge nicht zusammen, wird die Mail abgelehnt.
was macht Microsoft denn da wieder für einen Stuß?
dieses Problem wurde schon vor Jahrzehnten für mailing Listen gelöst in dem der Absender vom mailing Listen Server so geändert wurde dass er zum SPF des ausgehenden Hosts passt,
der empfangenende Server baut das sofort zurück, wenn er zustellen kann, so dass der Listen teilzunehmer das gar nicht wahrnimmt. Das hat auch den Vorteil, dass bounces an den Listen Admin gehen und nicht an den armen Teilnehmer.
es ist unglaublich welchen Murkss seinen Kunden zumutet um diese in die Cloud zu nötigen (ich glaube nicht dass die Leute bei MS so dumm sind und diese uralten RfC nicht kennen. auch wenn der Satz heißt: wenn Dummheit den Fehler ausreichend beschreibt, unterstelle keinen Vorsatz…
Hängt vielleicht mit MS SRS zusammen:
https://learn.microsoft.com/en-us/exchange/reference/sender-rewriting-scheme
Vlt einfach mal den Header hier im Beitrag oder Kommentar einfügen damit man was sehen kann.
Microsoft leitet die an Exchange Online gehenden Mails intern weiter, ohne den Header mit zu übergeben.
Dadurch greifen dann entsprechend DMARC/SPF Regeln nicht mehr und die Mails werden abgewiesen (weil die Ursprungs-IP nicht mehr enthalten ist).
Das Problem haben wir schon seit Monaten. Absender-Server ist On-Premise.
danke für die Bestätigung
@Christian B: Ihr habt das Problem seit Monaten? Wer ist denn euer Dienstleister? Ein Spamfilter sollte nie auf IP-Adressen auf dem Header aufsetzen, denn der kann gefälscht sein. Es sei denn man sagt dem Spamfilter, welche Stationen „davor“ vertrauenswürdig sind. (Exchange Enhanced Filtering-Logik) Er nutzt „MAIL-FROM“, „RCPT TO“, IP-Adresse Zertifikat und dann natürlich DKIM/ARC
Ich nehme an, dass dein MX zu Exchange Online geht und dann über Hybrid zum lokalen Server. Warum machst du dann lokal noch mal eine Spamerkennung auf eingehende Mails, die von Exchange Online schon geprüft wurden?
Dann verzichtet man besser auf den eigenen SPF-Check und prüfte das ARC-Seal, mit dem Exchange Online seinen SPF-Check signiert.
Nein, unser Server ist der On-Prem Server, wir nutzen kein Exchange Online. Mailfilterung geschieht über Sophos Central, bevor sie zu uns zugestellt werden. Wir haben auch nicht das Problem mit eingehenden Mails, sondern mit denen, die AN Exchange Online von Kunden/Lieferanten gehen.
Ich verstehe das Problem hier einfach nicht.
Kann es aber sein, dass es hier ein Problem in einer hybrid Konfiguration gibt?
Also ich habe die umgekehrte Konstellation:
Es gibt immer mal wieder Kunden, die an mich keine Mail loswerden (bei mir eigener Mailserver nur für diese Firma). Schnittmenge: Alle sind in der Cloud, fast alle bei MS.
Hakt man dann mal intensiv nach, haben sie dann doch eine Fehlermeldungsmail bekommen. Letztens wars mal zu groß (45 MB), aber normalerweise hat eine Blacklist zugeschlagen. Ist halt blöd, wenn man seine Mailserver mit der halben Welt teilt…
Mails von meinen Systemen kommen bis jetzt immer an, mir werden keine Problemfälle berichtet.
Blöd ist auch, wenn eine Firma meint, sie könne alles selber – und dann für den Massen-Newsletter-Versand (zuerst noch mit eigenem Gebastel, später dann per CleverReach) reguläre E-Mail-Adressen und vor allem mit der Haupt-TLD nimmt! :D
Ich hatte Firmen im Modebereich aus Düsseldorf, die wochenlang immer wieder keine Mails mehr senden konnten, weil sie das zuerst nicht verstanden haben… :)
Es muss ja theoretisch nur ein Newsletter-Empfänger einen Abuse melden.
Also immer mindestens eine Subdomain oder besser eigene TLD (EigentlicheFirmenseite-newsletter.de) nehmen.
Bei einem unserer Kunden kamen auch immer wieder (2-3x im Abstand einiger Wochen) Mails nicht an bzw. die gingen an mich als unzustellbar/abgelehnt zurück:
Kunde nutzt einen On-Premise-Server hinter bzw. mit Office/Exchange, wobei der öffentliche MX-Eintrag zu Microsoft zeigt.
In den Headern war klar ersichtlich, dass Exchange die eingehenden Mails nicht wie eigentlich erwartet an den On-Premise-Server regulär weiterleitet und nur die Headerzeilen ergänzt, sondern dass er diese neu und von sich ausgehend verschickt hat. Die vorherigen Header blieben aber erhalten(???), aber es gab eben eine neue Reihe von Absender-/Weiterleitungszeilen, die dann eben von der falschen IP (der MS-IP und nicht mehr unserem bei SPF gelisteten Mailserver) ausgingen und beim On-Premise-Server dann entsprechend unserer SPF-Anforderungen abgelehnt wurden.
Glücklicherweise scheinen sie das dann doch jeweils binnen eines Tages behoben zu haben, aber nervig ist das trotzdem.
Habe ich so noch nie gehört und wäre auch untypisch. Warum sollte Exchange die Mails „neu schreiben“. Es sei denn da arbeitet jemand mit Weiterleitungen statt Umleitungen.
Und wenn EXO schon den Spamfilter macht, dann sollten die Mails per Hybrid Connector zum lokalen Server gehen und der lokale Exchange macht kein SPF. Also hast du vielleicht lokal einen 3rd PArty Scanner zwischen EXO und Exchange OnPrem? Das ist nicht supported und dann passiert sowas.
Hallo und sorry,
ich „muss“ mich auch mal einmischen. Ich denke, das kennen viele:
Wie oft musste ich die letzten Jahrzehnte Kunden erklären, dass der die Meldung generierende, ablehnende Mailserver der der Firma ist, an die geschickt wurde und nicht die – damals noch – On-prem-Server, die wir installiert haben…
Das hat nicht selten zehn Versuche oder mehr gebraucht – und obwohl ich wirklich sehr gut erklären kann haben es viele Kunden dann trotzdem nicht verstanden oder wahrhaben wollen.
Argument oft: „Was, das ist doch eine riesen Firma? Das kann doch nicht sein!“
Ich habe dann akribisch die Konfigurationsfehler von wirklich sehr sehr großen Firmen (z.B. Kölner Fernsehsender, so 7.500 Mitarbeiter) nachgewiesen, habe dann teilweise mit deren Admins persönlich gesprochen, die nicht selten arrogant waren – und immer dann klein beigeben mussten bzw. auf einmal funktionierte es dann kommentarlos…
Was soll ich machen, meine kleinen Kunden mit so bis zu 150 Mitarbeitern müssen Auftraggebern, die um den Faktor ca. 300 größer sind rein von den Beschäftigten her „kleinlaut“ mitteilen, dass sie zu doof sind…
Das war regelmäßig für alle nicht schön… :D
Grüße
p h o s m o
Da gebe ich dir Recht. Unser tägliches Geschäft als Hersteller von NoSpamProxy. Wenn man SPF,DKIM,DMARC, ARC, DNSSEC, TLSA macht und sich an die Vorgaben des Absender hält, blockt man natürlich „falsche“ Mails. oder die Gegenseite meint sie müsste blocken, obwohl alles richtig ist. Ist ein dauernder Kampf aber den wird man führen müssen.
Nach der Meldung von Günther und mein Feedback auf Bluesky habe ich mir die ganzen Kommentare mal durchgelesen und ich stelle für mich mal fest, dass wir alle nichts genaues sagen können, solange man nicht den SMTP-Header der empfangenen Mail kennt. Ich kläre das gerne mit dem Absender und Empfänger, wenn Sie Lust haben. meine Kontaktdaten sind auf der MSXFAQ auch aufgeführt.
Aber mal ein paar Dinge
– SPF ist eine Option als Absender zu veröffentlichen, welche Mailserver „autorisiert“ sind. Ich bin ein Freund von „SPF-Einträgen, die am Ende ein „-all“ haben.
Das kann zu Problemen bei Weiterleitungen und Mailinglisten führen, die den Absender nicht per Sender Rewriting Scheme (SRS) umschreiben)
Exchange Online schreibt übrigens Absender in einigen Fällen mit SRS um (der Mail-From, nicht den Header From)
– DKIM wurde bislang gar nicht genannt, daher spare ich das mal aus :-)
– DMARC wurde auch nicht genannt kann aber in Verbindung mit DKIM helfen aber mit SRS wieder stören.
Ja, es gibt fehlerhafte Implementierungen von DMARC-Validatoren und auch Firmen die in DMARC ein „p=None“ machen, was aus meiner Sicht die Unfähigkeit des Mailadmins belegt. Er hat nichts verstanden.
In dem Artikel von Günni steht, dass „Exchange Online“ Adressen im Header vorkommen. Das ist normal, wenn der MX-Record des Empfängers bei Exchange Online liegt. Und ist auch nicht schlimm sondern sehr oft sogar der Fall und fast nie das Problem.
Exchange Online nimmt Mails an und macht IMMER einen SPF-Check. Das sieht man im Header unter „Authentication-Results“.
Das steht dann SPF=PASS oder SPF=SoftFail oder SPF=Fail oder SPF=None. Abhängig von weiteren Regeln landet die Mail dann in der Quarantäne oder Postfach
Oder wird beim Ziel zu einem OnPremises-Server weitergeleitet. (Das kann Exchange 2019/2016 etc sein aber auch Postfix/Sendmail etc)
Dazu richtet man in Exchange Online einen „Outbound OnPremises Connector“ für die Accepted Domains ein mit dem Smarthost zum lokalen Server oder Relay.
Die lokalen Postfächer werden mit ADSync in Exchange Online als MailUser angelegt, damit Exchange Online weiss, dass die weitergeroutet werden (umleitung, nicht weiterleitung) . Das lokale Relay sollte dann natürlich KEINEN SPF-Check mehr machen, sondern die eingehende Verbindung als „Trusted“ ansehen, wenn..,
1. sie von den IP-Ranges von Microsoft Exchange kommen (Das kann eine Firewall gut filtern)
2. sich Exchange Online mit einem Zertifikat „protection.mail.outlook.com“ ausweist und der lokale Server MTLS bei STARTTLS kann. Exchange kann das schon lange. Postfix/Sendmail etc können es auch, wenn der Admin es kann.
3. Im Header das Feld „x-originatorOrg“ oder „X-MS-Exchange-CrossTenant-id“ prüfen um den eigenen Tenant zu erkennen
Das macht der Hybrid Configuration Wizard alles für euch, wenn man ihn denn nutzt und die Konfig danach in Frieden lässt.
Mittlerweile addiert Exchange Online übrigens ein ARC-Seal mit den Details seiner eigenen SPF/DKIM/DMARC-checks
Das gilt auch in Gegenrichtung:
Wenn der Empfänger eingehende Mails selbst annimmt und dann hintenrum an ein Exchange Online Postfach sendet, dann sollte man Exchange Online auch sagen, dass er die IP-Adressen des eigenen Spamfilters beim SPF-Check umgehen sollte. Dazu gibt es Enhanced Filtering, was man auf dem Inbound Connector konfigurieren muss, es sei denn die Mail kommt über einen Hybrid Connector.
Dann „vertraut“ Exchange Online dem lokalen Exchange anhand der Source-IP der besser Client-Zertifikat. Zusätzlich kann man noch ein ARCSeal anbringen und Exchange Online als „Trusted“ geben
Ich vermute mal, dass dies das Problem beim Empfänger ist.
Generell
– Bitte keine SPF-Richtlinien „aufweichen“. Wenn der Empfänger ein Problem hat, dann hilft man ihm besser es zu „verstehen“.
SPF/DKIM/DMARC verhindern kein Spam. auch Spammer kaufen sich Domains und sendet perfekte Mails. Aber es ist ein Schutz von Phising von entsprechenden Domains. Aber es ist kein Schutz gegen „ähnliche „Domains .Aber man kann dann natürlich seine Partner „belohnen“. Wobei ich dann noch TLS-Zwangs und TLSA mit DNSSEC wünsche. Aber das dauert und wollen wir wirklich ein Rating von „guten Domains“? und wer sagt dir, dass dein Lieferant nicht grade gehackt wurde und daher von dort Spam/Phishing kommt?
Ich habe die letzten 30 Jahre zu viele „perfekte Lösungen“ genannt bekommen und man kann sie immer aushebeln.
Es wird immer „abgelehnte Mails“ geben. das nennt sich false positive und der ist nie 0, wenn man filtert. Der Empfänger stellt seine eigene Hausordnung auf. Google u.a. sind groß genug, dass Sie das vorschreiben können.
https://support.google.com/a/answer/14289100?hl=en
Beim kleinen Mittelstand, der vom großen Kunden abhängig ist, ist das nicht immer so einfach
Exchange Online ist sicher nicht perfekt und man immer wieder was besser machen. Aber den Fehler aus dem Blog sollte man finden und fixen können.
Ich denke ich melde micht als der Anfrager auch mal hier. Ich wollte mit der kleinen Anfrage eigentlich nicht so viel Staub „aufwirbeln“.
Danke für die Konstruktiven Lösungsansätzte. Haben wir so alles vor meiner Anfrage auch schon durchgespielt (und noch viel verdrehtere Szenarien) und zeigt mir das wir bisher auf dem richtigen Weg sind.
Unsere E-Mails gehen defintiv bei uns im Rechenzentrum über die Mailgateways lokal in das Internet raus.
Auch die Logs unserer Systeme zeigen immer(!) wie die E-Mail bei *.protect.microsoft.com eingeliefert wurden (das Mailgateway zeigt den Verbindungsaufbau der Komunikation mit den MS IPs).
Bis auf ein Screenshot eines aufgebrachten Geschäftspartners und einer herablassenden Mitteilung der IT gegenüber, bekamen wir nie mehr Infos. Immer wenn wir nach dem Mailheader fragten und unsere Logs zeigen verstummte die Kommunikation mit der gegenüberliegenden IT schlagartig. Nun mitlerweile drei mal genau so abegelaufen, aber immer mit einer anderen Firma.
Beim Scrennshot welchen wir haben, steht als Absender eine MS IP (nicht unsere). Das Bild deutet auf Outlook Online hin. Mehr Infos haben wir leider nicht. Daher auch die Frage hier. Wir müssen auch raten, versuchen aber eine Lösung zu finden um dem in Zukunft vorbeugen zu können.
Unsere SPFs sind alle mit Fail (nicht softfail) eingerichtet. DMARC und DKIM sind alle entsprechend vorhanden. Hierum geht es aber primär gar nicht. Sondern warum steht beim Absender eine MS IP und nicht unsere. Wir können auch nur raten.
Das Phanomän haben wir bisher auch noch(!) nicht häufig. Mit einem Mailaufkommen von 2000- 3000 ausgehenden Mails am Tag sind wir auch nicht rießig groß.
Logs von unseren Systemen kann ich leider auch nicht einfach so hier veröffentlichen. Manche Institutionen unterliegen erhötem Schutz und strengeren Richtlinien was bei uns vorliegt.
Falls ich nach dem Urlaub doch noch einen Mailheader von dem Gegenüber bekomemn sollte :0), werde ich den hier gerne entsprechend Teilen (sofern möglich).
Mit der MS Cloud kämpfen wir nun seit ein paar Monaten immer mehr, da unser Mailgateway diese immer öffters als nicht vertrauenswürdig einstufen (diverse Probleme).
Aber wir können leider hier nicht mehr machen, das muss die IT der gegenüberliegenden Seite die die Cloud Systeme betreut. Unser Mailteam hilft hier gerne (weil es uns auch interessiert). Aber ohne Mitarbeit der Gegenüberliegenden IT wird das schwierig.
By the way: Die MS Cloud mag ihre Eigenarten haben, aber die erste Mail die von unserem neuen Mailgateway blockiert wurde kam vom BSI.
Aber jetzt ist erst mal Familienzeit…