Jump to content

ausgehende negativliste für smtp-hosts mit wildcard


Recommended Posts

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

 

 

Edited by Dirk-HH-83
Link to post

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.

Link to post
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.

Link to post
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)

Link to post
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!

Link to post
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.

 

Link to post
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).

Link to post
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. ;)

Link to post

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.

Link to post

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.

Link to post

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. ;)

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...