Exchange Online - RFC Konform ?

Servus zusammen,

Kunde meldet: Software X schickt keine Mails mehr bei Updates (Listenabgleich mit Server vom Hersteller).
Also mit dem Support heute getestet. Deren Software (Name spielt keine Rolle) läuft in einen Timeout rein oder bekommt eine 4.4.5 (Temp unavailable zurück).
Dachte mir, kann so nicht sein, also an die gute alte Zeit erinnert und telnet ausgegraben.

Händische Tests mit telnet ergaben:

250 2.6.0 <27db52a3-7005-4cc4-809a-b1646bcf7d49@DB5EUR01FT045.eop-EUR01.prod.protection.outlook.com> [InternalId=1992864825764, Hostname=AM5P192MB0178.EURP192.PROD.OUTLOOK.COM] 7918 bytes in 0.206, 37.527 KB/sec Queued mail for delivery

Sehr merkwürdig, wieso kann ich Plaintext Mails mit einem 250 QMFD einliefern, und die Software nicht ?
Maillogs gibt es nicht, ausser dass eine erfolgreich übergebene Mail als .EML auf der Platte abgelegt wird. SICK!

Also Jugend forscht....

Ändere ich den Absender in der Software von heinsmutje@inderfirma.de zu hannebambel@hastenichtgesehen.de geht die Mail auf einmal raus und kommt im Zielpostfach an.
Sehr komisch. Die mit telnet versandte hatte test@inderfirma.de und kam eben trotz 250 QMFD nicht im Postfach an.

Eigentlich erwarte ich, dass nicht zustellbare Mails mit einem NDR zurück kommen.

Weiter gesucht... hmm, da war mal was mit SPF. Also schnell den Record nachgeschaut und da kam der AHA-Effekt.
Der nette Provider des 200mbit/s Glasfaseruplinks (Tochter der Terrorkomm) hat mal eben kurz die IP geändert. Der Router muss beim Kunden auf DHCP stehen, sonst geht kein Internet. Also von der Änderung nix mitbekommen.

Somit hat der SPF-Record nicht mehr gestimmt. (vorher: v=spf1 ip4:AAA.BBB.CCC.DDD include:spf.protection.outlook.com -all) jetzt auf ...snip...ip4:aktuelleip include...snip.... geändert.
Und schon kann die Software wieder Mails versenden mit einem internen Absender.

Meine große Frage...... wieso schickt Dreckschange Online (ups, Exchange) keinen NDR raus, sondern quittiert die Einlieferung und schmeisst dann die Mail in die Tonne ?

Lohnt es sich deswegen ein Ticket bei MS aufzumachen ?

Grüße, Henere

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 387706

Url: https://administrator.de/forum/exchange-online-rfc-konform-387706.html

Ausgedruckt am: 19.04.2025 um 08:04 Uhr

10 Kommentare

Neuester Kommentar

Wenn MS Exchange bei jeder von einem Deppert-Konfigurierten System (=Spam) eingehenden Mail eine NDR schicken würde, dann bräuchten die das zigfache der Kapazitäten. Übrigens, mach ich bei den meisten Systemen auch mit Spam so, dient auch dem, dass ein schlecht gelaunter Heinzelmann nicht weiss, dass er eben kein ordentliches Postfach adressiert hat.

Zur Abhilfe solltest du dem Kunden lieber auf die Schulter klopfen: Gut gemacht, billig gekauft (ohne feste IP) oder ### beraten worden.

Ein Ticket aufmachen? Wozu :D

PS: Deine Mail ist nichtmal so weit vorgedrungen, um Sie RFC konform zu behandeln, denn deine Mail wurde einfach als Spam verworfen.

Wenn ich eine Mail verwerfe, darf ich kein Queued mail for delivery zurücksenden... oder hat sich da was geändert ?
Es war mit fester IP gekauft, das ist der nächste Akt. Ging hier aber nur um das Verhalten von Dreckschange Online.

Moin,

Exchange-Online macht noch viel mehr Mist.

MS legt RFCs sehr eigenwillig aus. Und durch seine Marktmacht setzt es diese Eigenwilligkeit auch durch.

lks

PS: Spamabwehr ist kein Grund um sich nicht an RFCs zu halten.

Zitat von @Lochkartenstanzer:

Exchange-Online macht noch viel mehr Mist.

Dort ist doch aber ein Fehler von David beschrieben, der dann auch von Tobit gefixt wurde?

/Thomas

Zitat von @Th0mKa:

Zitat von @Lochkartenstanzer:

Exchange-Online macht noch viel mehr Mist.

Dort ist doch aber ein Fehler von David beschrieben, der dann auch von Tobit gefixt wurde?

Nein, das ist ein Fehler von Exchange/Forefront, der in den Headern herumpfuscht und von Tobit ein workaround eingebaut wurde. Andere MUA sind da tolerant genug, das zu kompensieren.

lks

Zitat von @Lochkartenstanzer:

Nein, das ist ein Fehler von Exchange/Forefront, der in den Headern herumpfuscht und von Tobit ein workaround eingebaut wurde. Andere MUA sind da tolerant genug, das zu kompensieren.

lks

Danke, wird irgendwo beschrieben was das konkrete Problem war/ist?

/Thomas

Zitat von @Th0mKa:

Danke, wird irgendwo beschrieben was das konkrete Problem war/ist?

https://techcommunity.microsoft.com/t5/Office-365/Exchange-Online-Protec ...

Da werden Mime-Abschnitte geändert. ohne Sigbaturen zu beachten.

Hat mich einen halben Tag Diagnose gekostet um rauszufinden, wer der Bösewicht ist.

lks

Zitat von @Lochkartenstanzer:

Moin,

PS: Spamabwehr ist kein Grund um sich nicht an RFCs zu halten.

Mag man so oder so sehen. Grundsätzlich ist das eigentliche Problem aber ein anderes: Offensichtlich ist die Feste IP nicht festgelegt worden bzw irgendwas lief damit nicht richtig. MS hätte es da wie zig andere treffen können...

Zitat von @certifiedit.net:

Übrigens, mach ich bei den meisten Systemen auch mit Spam so, dient auch dem, dass ein schlecht gelaunter Heinzelmann nicht weiss, dass er eben kein ordentliches Postfach adressiert hat.

Uuh, hoffentlich nicht bei deinen Kunden...
Wenn du der Betreiber/Adninistrator des Mailservers bist, hast du in DE grundsätzlich die Pflicht, angenommene und im SMTP-Dialog quittierte E-Mails auch zuzustellen (und sei es in ein spezielles Postfach, wo der Kunde Zugriff hat).

https://dejure.org/gesetze/StGB/206.html

Zitat von @LordGurke:
Uuh, hoffentlich nicht bei deinen Kunden...
Wenn du der Betreiber/Adninistrator des Mailservers bist, hast du in DE grundsätzlich die Pflicht, angenommene und im SMTP-Dialog quittierte E-Mails auch zuzustellen (und sei es in ein spezielles Postfach, wo der Kunde Zugriff hat).

https://dejure.org/gesetze/StGB/206.html

Servus,

also müsste jetzt genaugenommen Strafanzeige gegen MS gestellt werden, wegen Unterschlagung von Post ?