Dirk-HH-83 14 Geschrieben 8. September 2021 Melden Teilen Geschrieben 8. September 2021 (bearbeitet) Hallo, kann man mit Powershell oder im ECP eigentlich alle ausgehenden Mails z.B. an *.mail.protection.outlook.com blocken so dass sofort ein DSN/NDR zum Versendet kommt? Ich frage für einen Exchange 2010/2013. Bei Transportregeln scheint mir das nicht zu funktionieren. in der Windows Hosts Datei sowas einzutragen ist keine gute Idee, könnte aber klappen. es geht mir darum, das die ausgehenden Mails vom on-premises Exchange immer mit SCL 5 im Junk von M365 gelandet sind Grund der Frage: der on-premises-exchange-versender-Endbenutzer kann das ja nicht wissen und mittels o.g. DSN/NDR würde er es sofort "merken" dank IP wechsel beim ISP jetzt nicht mehr, d.h. eigentlich ist diese Frage jetzt auch obsolet Edit: habe bei https://docs.microsoft.com/ noch nicht recherchiert im ECP gibt es nur "Verbindungsfilter auf IP Basis" besten dank bearbeitet 8. September 2021 von Dirk-HH-83 Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 8. September 2021 Melden Teilen Geschrieben 8. September 2021 Moin, Ist da jetzt noch eine Frage dabei? Gruß, Nils Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 8. September 2021 Melden Teilen Geschrieben 8. September 2021 Was wäre denn überhaupt das Ziel, bzw. das Problem, welches du zu lösen versuchst? Wenn du den Zielhost *.mail.protection.outlook.com blockst (Hosts kann keine Wildcard), dann dürfte sich dein Empfängerkreis aktuell stark einschränken. Zitieren Link zu diesem Kommentar
cj_berlin 1.315 Geschrieben 8. September 2021 Melden Teilen Geschrieben 8. September 2021 vor 29 Minuten schrieb NorbertFe: Was wäre denn überhaupt das Ziel, bzw. das Problem, welches du zu lösen versuchst? Das Problem war, dass EOP deren Mail als Spam geflaggt hat, und man hat gesagt "dann senden wir halt gar nicht erst an die" Zum Glück war es nicht mit den vorhandenen Mitteln möglich, das technisch umzusetzen. Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 8. September 2021 Melden Teilen Geschrieben 8. September 2021 Sehr „sinnvoll“ nicht. Zitieren Link zu diesem Kommentar
Dirk-HH-83 14 Geschrieben 9. September 2021 Autor Melden Teilen Geschrieben 9. September 2021 vor 16 Stunden schrieb cj_berlin: Das Problem war, dass EOP deren Mail als Spam geflaggt hat, und man hat gesagt "dann senden wir halt gar nicht erst an die" Zum Glück war es nicht mit den vorhandenen Mitteln möglich, das technisch umzusetzen. nee, ich meinte das doch nur temporär für wenige tage bis eine neue IP vom ISP released wurde. anderes gesagt: EOP hat die vor ca. 3 Wochen neue static IP vom neuen ISP trotz delisting mit SCL5 + CAT: SPM im header geflaggt (statt ipblock) Die Idee die ausgehenden Mails an M365 global mit DSN/DNR zu blocken kam daher, das der Enduser ja nicht weiß ob seine ausgehende Mail beim Empfänger im Junk landet (weil er ja nicht wissen kann ob beim Empfänger dort M365 vorhanden ist). Es ist doch besser sofort zu wissen das eine ausgehende Mail vom Empfänger ggf. übersehen wird (wegen junk) Rote Firewalls könnten die ausgehende Port 25 Verbindung zu *.mail.protection.outlook.com blocken (weil dort auch FQDN Wildcard (a-record/cname) in den Policies stehen kann. (vermute das können andere auch) Leider funktioniert in diesen Policies keine rDNS Abfrage oder kennt jemand Firewalls die das können. (ist ein anderes Thema) Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 9. September 2021 Melden Teilen Geschrieben 9. September 2021 vor 37 Minuten schrieb Dirk-HH-83: Es ist doch besser sofort zu wissen das eine ausgehende Mail vom Empfänger ggf. übersehen wird (wegen junk) Es ist doch besser sofort zu wissen, dass eine ausgehende Mail vom Empfänger dann gar nicht gesehen werden kann, weil sie ja gar nicht zustellbar ist. ;) vor 37 Minuten schrieb Dirk-HH-83: Rote Firewalls könnten die ausgehende Port 25 Verbindung zu *.mail.protection.outlook.com blocken (weil dort auch FQDN Wildcard (a-record/cname) in den Policies stehen kann. (vermute das können andere auch) Leider funktioniert in diesen Policies keine rDNS Abfrage oder kennt jemand Firewalls die das können. (ist ein anderes Thema) Aha und wenn du den Port blockst, kommt die dann nicht im Spamordner an? Ne stimmt, die kommt dann gar nicht an. Clever! Zitieren Link zu diesem Kommentar
Squire 261 Geschrieben 9. September 2021 Melden Teilen Geschrieben 9. September 2021 ich würde eher mal checken, ob die Einträge im DNS für SPF, DKIM oder auch DMARC passen. Für mich hört es sich so an, dass es für den lokalen Exchange (Mailgateway) keinen SPF und PTR Record gibt Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 9. September 2021 Melden Teilen Geschrieben 9. September 2021 Du meinst so? Zitieren Link zu diesem Kommentar
Dirk-HH-83 14 Geschrieben 9. September 2021 Autor Melden Teilen Geschrieben 9. September 2021 vor 2 Stunden schrieb NorbertFe: Es ist doch besser sofort zu wissen, dass eine ausgehende Mail vom Empfänger dann gar nicht gesehen werden kann, weil sie ja gar nicht zustellbar ist. ;) Aha und wenn du den Port blockst, kommt die dann nicht im Spamordner an? Ne stimmt, die kommt dann gar nicht an. Clever! der Versender hätte einen NDR bekommen < darum gings mir (statt das er angst haben muss das seine mail im junk übersehen wird) vor einer Stunde schrieb Squire: ich würde eher mal checken, ob die Einträge im DNS für SPF, DKIM oder auch DMARC passen. Für mich hört es sich so an, dass es für den lokalen Exchange (Mailgateway) keinen SPF und PTR Record gibt DKIM bei Exchange 2010 "signen" habe ich jetzt nicht gemacht. Senden über SMART HOST half übrigens auch nicht, d.h. die EOP "KI" hat sich den ganzen Header durchgelesen. Root Cause war: wegen ISP Wechsel gab es neue static IP vor drei Wochen (die war bei www.mxtoolbox..com) clean, bei https://sender.office.com jedoch nicht. Es hat sich ja mittels "nochmal neuer public IP" jetzt ja gelöst. Zitieren Link zu diesem Kommentar
Dukel 454 Geschrieben 9. September 2021 Melden Teilen Geschrieben 9. September 2021 vor 10 Minuten schrieb Dirk-HH-83: der Versender hätte einen NDR bekommen < darum gings mir (statt das er angst haben muss das seine mail im junk übersehen wird) Das kann immer passieren. Nicht nur bei MS. Aber, solange die Mail von dern Gegenseite angenommen wurde, ist es für euch in Ordnung (vor allem wenn es rechtliche Kommunikation ist). Hier sollte man eher eine organisatorische und keine Technische Lösung anstreben (MA Informieren. Wenn es wichtige eMails sind, kann man z.B. telefonisch nachfragen oder Lesebestätigungen anfordern). Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 9. September 2021 Melden Teilen Geschrieben 9. September 2021 vor 30 Minuten schrieb Dirk-HH-83: der Versender hätte einen NDR bekommen < darum gings mir (statt das er angst haben muss das seine mail im junk übersehen wird) Aus Angst vor dem Tod Selbstmord begangen ;) Stimmt, stattdessen hätte der Empfänger nichts erhalten und der Absender hätte auch nix versendet. Sehr sinnvoll. ;) vor 32 Minuten schrieb Dirk-HH-83: DKIM bei Exchange 2010 "signen" habe ich jetzt nicht gemacht. Naja gibt diverse Produkte die sowas bieten (inklusive Open Source Agent der aber offiziell inzwischen auch kein E2010 mehr supported). Aber unabhängig davon kann man sowas alles designtechnisch vor dem Exchange regeln, wenns die Infrastruktur hergibt und selbst bei der besten Konfiguration kann dir das niemand GARANTIEREN, dass dein Mail nicht bei O365, Google, GMX oder sonst wem auf Empfängerseite nicht doch wieder im Junkfolder liegt. Bye Norbert vor 34 Minuten schrieb Dirk-HH-83: d.h. die EOP "KI" hat sich den ganzen Header durchgelesen. Du hast komische Vorstellungen. ;) Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 9. September 2021 Melden Teilen Geschrieben 9. September 2021 Ich hatte mal vor ein paar Jahren ein Urteil gelesen, indem festgehalten wurde, dass ein Mitarbeiter einmal täglich in den Junk Ordner sehen soll. Bitte nicht versuchen ein soziales Problem mit Technik zu erschlagen. Zitieren Link zu diesem Kommentar
Squire 261 Geschrieben 11. September 2021 Melden Teilen Geschrieben 11. September 2021 wir haben einen NoSpamProxy vor unseren Exchange Servern ... da gibt es keine Quarantäne! Die Mails werden nicht angenommen, wenn sie als Spam eingestuft werden. Der Absender erhält eine klar verständliche Meldung warum die Mails nicht durchgehen (z.B. bei unzulässigen Dokumentanhängen, abgelaufenen Zertifikaten etc.). Die Verantwortung für die gesendeten EMails liegt beim Absender. Wir haben das System jetzt seit einem halben Jahr im Einsatz - am Anfang war es für viele ungewohnt, weil es eben keine Quarantäne mehr gibt. Einige unserer Lieferanten haben wir "erzogen", damit sie ihre Mailsysteme richtig konfigurieren (angefangen von fehlenden SPF Record, fehlende PTRs oder hartnäckigen Senden alter Office Formate). So was setzt halt immer auch ein bisschen Rückhalt und Verständnis der GF voraus. Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 11. September 2021 Melden Teilen Geschrieben 11. September 2021 Das ist aber thematisch jetzt sehr am Problem, welches der to lösen wollte, vorbei. ;) denn der nospamproxy sorgt auch nicht dafür, dass o365 die Mails nicht im Spam einsortiert. Wobei… vermutlich schon, denn meist sorgen solche Betreiber dann für eine saubere Konfiguration ihrer Systeme. ;) Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.