SPF_fails wegen OWA aus fremden Netzwerk

[Lukikum 8]

Moin zusammen,

 

momentan wollen wir ein bisschen mit SPF Fails arbeiten und bestimmte Mails komplett sperren, die einen SPF_Fail vorweisen.

Nun ist die Problematik, dass wenn Leute aus einem bestimmten Netzwerk unser OWA aufrufen und dort eine Mail schreiben und die dann auch wieder in das gleiche Netzwerk geht, diese Mail laut Bericht dann auch aus dem Netzwerk kommt. Eigentlich sollten die Mails aber doch aus unserem Netzwerk kommen. Jedenfalls wird dadurch ein SPF Fail ausgelöst, obwohl es unser offizielles OWA ist.

Kennt jemand das Problem ? Ist es die Schuld von uns oder von dem anderen Netzwerk?

LG und vielen Dank für die Hilfe
Lukas

bearbeitet 17. November 2022 von Lukikum

[cj_berlin 1.329]

Moin,

 

sprechen wir hier von Exchange OWA, oder was ist "euer offizielles Webmail"?

[Lukikum 8]

vor 12 Minuten schrieb cj_berlin:

Moin,

 

sprechen wir hier von Exchange OWA, oder was ist "euer offizielles Webmail"?

Moin,

 

sorry, meine natürlich OWA.

LG

[NorbertFe 2.066]

vor 56 Minuten schrieb Lukikum:

wollen wir ein bisschen mit SPF Fails arbeiten

Weil man dann nur ein bisschen Spam bekommt, oder wie?

Gleich vorneweg: SPF hilft heutzutage nur noch bedingt. Auch Spammer können SPF. ;)

 

Zu deinem Problem: Es wäre einfacher, wenn du das mal konkret skizzierst. OWA wäre ja direkt per https auf dem Exchange und da spielt der SPF Record keinerlei Rolle.

 

[cj_berlin 1.329]

Hmmm. Dann sind das ja interne Mails - warum sollten sie überhaupt auf SPF geprüft werden? Welches System macht es?

 

Welchen Bericht meinst Du genau? Im SMTP-Protokoll oder im Mail-Header steht nicht drin, in welchem Netz der Nutzer seinen Browser aufgerufen hat, um die Mail abzusetzen, denn an dieser Stelle ist SMTP noch gar nicht involviert. Und wenn Exchange angefangen hat, bei OWA diese Info im Header zu verewigen, dann wohl kaum in einem Header, der für die SPF-Prüfung relevant ist...

[Lukikum 8]

vor 16 Minuten schrieb NorbertFe:

Weil man dann nur ein bisschen Spam bekommt, oder wie?

Gleich vorneweg: SPF hilft heutzutage nur noch bedingt. Auch Spammer können SPF. ;)

 

Zu deinem Problem: Es wäre einfacher, wenn du das mal konkret skizzierst. OWA wäre ja direkt per https auf dem Exchange und da spielt der SPF Record keinerlei Rolle.

 

Wir wollen nur die Adressen blockieren, die unsere Domain fälschen. Da wir aber noch ein paar externe Systeme haben, die Mails verschicken, müssen wir das über SPF machen.

vor 15 Minuten schrieb cj_berlin:

Hmmm. Dann sind das ja interne Mails - warum sollten sie überhaupt auf SPF geprüft werden? Welches System macht es?

 

Welchen Bericht meinst Du genau? Im SMTP-Protokoll oder im Mail-Header steht nicht drin, in welchem Netz der Nutzer seinen Browser aufgerufen hat, um die Mail abzusetzen, denn an dieser Stelle ist SMTP noch gar nicht involviert. Und wenn Exchange angefangen hat, bei OWA diese Info im Header zu verewigen, dann wohl kaum in einem Header, der für die SPF-Prüfung relevant ist...

Unser Smarthost prüft die Mails und schreibt Logs. Ich weiß leider nicht genau wie unser Smarthost aufgebaut ist, war schon lange vor meiner Zeit.

 

Jedenfalls stellt der fest, dass anscheinend ein anderer SMTP Server die Mails verschickt. Das Problem tritt auch nur auf zwei Netzwerken auf. Wenn ich z.B. OWA in meinem Heimnetzwerk benutze, gibt es garkeine Smarthost Log Einträge, weil ja alles über die Interne Transportqueue vom Exchange geregelt werden kann. So sollte es eigentlich auch bei den anderen Mails sein. Deshalb wundere ich mich so darüber.

bearbeitet 17. November 2022 von Lukikum

[cj_berlin 1.329]

Moin,

aber spätestens im Header einer empfangenen Mail (aus einem "falschen" Netzwerk verschickt) steht doch, von welchem Server sie ursprünglich ausgeht. Das sollte ein guter Anhaltspunkt fürs Troubleshooting sein  

[NorbertFe 2.066]

vor einer Stunde schrieb Lukikum:

Wir wollen nur die Adressen blockieren, die unsere Domain fälschen.

Das schaffst du nicht (allein) mit SPF. 

 

vor einer Stunde schrieb Lukikum:

Da wir aber noch ein paar externe Systeme haben, die Mails verschicken, müssen wir das über SPF machen.

Ja. Siehe oben.

vor einer Stunde schrieb Lukikum:

So sollte es eigentlich auch bei den anderen Mails sein. Deshalb wundere ich mich so darüber.

Und an der Stelle solltest du als erstes ansetzen. Denn wenn du nicht weißt, wie und warum deine Mails irgendwo landen, ist das immer ein schlechter Start für Antispam Maßnahmen. SPF kann man dann immer noch leicht konfigurieren. Dein Problem hat aber wie schon erwähnt mit hoher Wahrscheinlichkeit gar nichts damit zu tun.

Bye

Norbert

[Lukikum 8]

vor einer Stunde schrieb cj_berlin:

Moin,

aber spätestens im Header einer empfangenen Mail (aus einem "falschen" Netzwerk verschickt) steht doch, von welchem Server sie ursprünglich ausgeht. Das sollte ein guter Anhaltspunkt fürs Troubleshooting sein  

Also einem Fall/Netzwerk konnte ich nun zuordnen, dass dort wohl eine Weiterleitung gegriffen hat. Eine Mitarbeiterin aus unserem Netzwerk hat eine Mail an eine externe Adresse geschickt. Die externe Adresse hat es dann weitergeleitet(zufälligerweise sogar wieder in unser Netzwerk rein) und dadurch konnte ich dann den SPF_Fail sehen.

 

Mir war nie bewusst, dass eine einfache Weiterleitung einen SPF_Fail auslöst, kann man das irgendwie verhindern? Sonst können wir das blocken von SPF Fails von unserer Domain vergessen..

[NorbertFe 2.066]

vor 10 Minuten schrieb Lukikum:

Mir war nie bewusst, dass eine einfache Weiterleitung einen SPF_Fail auslöst, kann man das irgendwie verhindern? Sonst können wir das blocken von SPF Fails von unserer Domain vergessen..

 

vor 10 Minuten schrieb NorbertFe:

Das schaffst du nicht (allein) mit SPF. 

 

Man müßte halt lesen, was einem geantwortet wird. Ohne SPF/DKIM und DMARC wirds garantiert nix und selbst mit denen gibts immer noch diverse Situationen, wo Fehler auftreten. Die sind dann aber eben auch seltener im normalen Mailverkehr

[Lukikum 8]

vor 3 Minuten schrieb NorbertFe:

Man müßte halt lesen, was einem geantwortet wird

Hallo Norbert,

du hast in der gleichen Minute wie ich geantwortet, meine Antwort hat sich noch auf CJ bezogen.

 

vor 4 Minuten schrieb NorbertFe:

Ohne SPF/DKIM und DMARC wirds garantiert nix

Meine Idee war es, Mails ohne Benachrichtigung am Exchange zu droppen. Das wollte ich mit 2 Bedingungen machen, einmal wenn einer unserer Mail Domains in der Absender Adresse benutzt wird und einmal wenn im Header die Markierung zu finden ist, wenn ein SPF_FAIL beim Smarthost erkannt wird.

 

Ich kann DMARC leider nicht einführen weil unser Smarthost das nich kann. Deshalb habe ich versuch etwas kreativ zu werden.

LG

[NorbertFe 2.066]

vor 5 Minuten schrieb Lukikum:

Meine Idee war es, Mails ohne Benachrichtigung am Exchange zu droppen.

Schlechte Idee. Reject wäre das Sinnvollste in dieser Situation.

 

vor 5 Minuten schrieb Lukikum:

Ich kann DMARC leider nicht einführen weil unser Smarthost das nich kann. Deshalb habe ich versuch etwas kreativ zu werden.

Tausch den Mist aus. Anders kann man das nicht mehr bezeichnen. Und wenn du nach deinem Smarthost was einfach löschst, dann bist DU verantwortlich. Der richtige Punkt für die Spamfilterung ist IMMER der erste annehmende Host für deine Domain. Wenn das dein Smarthost ist und der sowas nicht kann, dann wirds echt Zeit und alles andere brauchst du dir nicht ausdenken, denn das wird nur Quark.

[Lukikum 8]

vor 17 Stunden schrieb NorbertFe:

Schlechte Idee. Reject wäre das Sinnvollste in dieser Situation.

Würde ein reject nicht einen NDR auslösen ? Wenn also jemand unsere Domains fälscht, würde der NDR doch im Zweifel bei unseren Postfächern landen und die Nutzer verwirren. Was spricht denn gegen löschen ohne Benachrichtigung? Ich brauche leider gute Gründe, um die meinem Vorgesetzten zu erklären.. False positives wird es keine geben, sobald ich mein oben genanntes Problem gelöst habe.

 

vor 17 Stunden schrieb NorbertFe:

Tausch den Mist aus.

Geht leider nicht so easy. Außerdem meinten die, die sind dran das einzuführen. Abgesehen vom fehlenden DMARC haben wir sehr gut Erfahrung mit denen.

LG

[NorbertFe 2.066]

vor 12 Minuten schrieb Lukikum:

Würde ein reject nicht einen NDR auslösen ?

Ja, das ist der Zweck eines Rejects.

vor 12 Minuten schrieb Lukikum:

Wenn also jemand unsere Domains fälscht, würde der NDR doch im Zweifel bei unseren Postfächern landen und die Nutzer verwirren.

Eher unwahrscheinlich, da oft nicht den Sender Address (RFC5321.MailFrom) gefälscht wird (jedenfalls nicht _an_ dich, sondern von anderen), sondern die From (RFC5322.From und die steht innen und interessiert bei SPF null) und wenn, dann sollte euer System eben Backscatter erkennen können. ;)

 

vor 12 Minuten schrieb Lukikum:

Was spricht denn gegen löschen ohne Benachrichtigung?

Man löscht keine Nachrichten ohne Benachrichtigung. Isso. Ich weiß, das will dein Chef nicht hören.

 

vor 13 Minuten schrieb Lukikum:

Geht leider nicht so easy. Außerdem meinten die, die sind dran das einzuführen. Abgesehen vom fehlenden DMARC haben wir sehr gut Erfahrung mit denen.

Jeder wie er meint.

 

Bye

Norbert

[Dukel 455]

vor 20 Minuten schrieb Lukikum:

Was spricht denn gegen löschen ohne Benachrichtigung? Ich brauche leider gute Gründe, um die meinem Vorgesetzten zu erklären.

 

Da soll er mal seinen Rechtsbeistand dazu befragen!