NorbertFe

Hi, ich hab grad nicht nachgeschaut aber ich meine, dass man mittels "Ethical Wall" genau das erreichen müsste. https://answers.microsoft.com/en-us/msoffice/forum/all/office-365-ethical-wall-support/ed3160c5-9a8e-42df-ba35-7ec68e9957fd https://learn.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/conditions-and-exceptions glaub ich nicht. :) Einfach mal so pauschal ;)

Na da hätte ich aber Vertrauen… nicht ;)

Achso, aber passender wärs doch gewesen, du hättest dich auf die rausgestellten Terassenstühle gesetzt.

Na dann sauber bereinigen und den neuen nicht mit Setup enter enter installieren. ;) Glaub ich nicht. Zumindest deine dcs haben sich dort ein Zertifikat gezogen. Ansonsten war’s kein Standard. ;) bye norbert

Man kann sich auch alles "schön reden" ;) Solange ncpa.cpl da ist, ist mir fast alles egal. Die neue Netzwerk UI is einfach nur gruselig und in Teilen sogar dysfunktional.

Sind wir mal gespannt :)

Hab das mal korrigiert 😂

Naja irgendwie logisch, dass das so nicht unbedingt toll funktioniert. Stehen die Namen im Zertifikat? Falls nein, dann mal die Hosts korrekt setzen. Was steht denn im Zertifikat für ein Name? Die müssen ja wohl unterschiedlich sein, sonst gäbe es keine Probleme. Deine scp sind unterschiedlich, wie du ja schreibst. Sollte man nicht unbedingt tun.

Warum? Dann kannst du sie ja auch gleich löschen, denn dann siehst du, ob du evtl. noch was vergessen hast ;) Fahr ihn doch mal runter. Geht dann auch noch alles? Dann sind wohl die Virtual Directories noch nicht sauber konfiguriert bzw. der ClientaccessService im SCP. Gib mal ein get-clientaccessservice | fl *uri* Dann haben einige offenbar falsche Settings und finden ihr Postfach nicht. Nichts, was man nicht beheben kann, aber ich würds halt vorher sauber ziehen. Nach welcher Anleitung bist du vorgegangen? Bye Norbert

Betrifft übrigens nicht nur SMTP Domains, sondern bspw. auch die Neueinrichtung von Entra ID Connect. Das dauert aktuell wenigstens 4-6h bevor die Synchronisation sauber abgeschlossen werden kann.

Ist es so schwer, sich das mal beim Hersteller anzuschauen? https://learn.microsoft.com/en-us/powershell/module/exchange/set-organizationconfig?view=exchange-ps#-ewsenabled

Was soll der denn da ausrichten? Oder hast von ihm die O365 Lizenzen?

Ja, warte einfach mal 5-6h. Scheint seit kurzem etwas langsamer zu gehen in der ms Cloud. ;)

Wie lange hast du bis jetzt gewartet?

Kann durchaus sein. Ich hab’s nirgends benutzt. War halt irgendwann mal schulungsbestandteil. ;)

Nein, das stimmt so nicht. Bis irgendwann 2024 war das eine Funktion, die es in Exchange Online gab (DLP Transport Rules). Wurde lange vorher an- bzw. abgekündigt, man kann also maximal den Vorwurf machen, dass man den Empfehlungen zum Löschen nicht gefolgt ist. ;) https://techcommunity.microsoft.com/blog/exchange/exchange-online-etrs-to-stop-supporting-dlp-policies/3886713 https://techcommunity.microsoft.com/blog/exchange/exchange-online-mail-flow-rules-to-stop-supporting-dlp-related-rules-conditions-/3959870

Hilft dir evtl. nur bedingt, aber ich würde einfach ein Ticket bei MS eröffnen für den Kram.

Ich vermute, es geht um Exchange Online? Falls ja, dann hast du vermutlich gelesen, dass es die in ExO nicht mehr gibt und man das im neuen PurView Portal bearbeiten=löschen kann. Ich hab grad keine DLP Richtlinien mehr irgendwo im Einsatz um zu sehen, was da in der Praxis mit passiert, aber man wird ja zum neuen Portal geleitet: https://purview.microsoft.com/datalossprevention Bin mir grad nicht sicher, ob da in der E3 (die wir haben) extra Lizenzen notwendig sind, aber ich komm zumindest ins Portal rein.

Das ist meine letzte Antwort hier im Thread. Ich habe dir oben geschrieben, dass Exchange kein Sender Based Routing beherrscht. Es also ohne Hilfsmittel nur anhand der EMPFÄNGERDOMAIN oder anhand der Priorität möglich einen Sendeconnector zu wählen. Wenn ihr also 4 Sendeconnectoren verwendet, dann hab ihr dafür entweder einen guten Grund, oder eine unnötige Konfiguration. Kann ich ja schlecht einschätzen. Fakt ist aber, dass man dir eine Antwort schreibt und du daraufhin eine irrelevante Aussage kommt, die ja 1. genau null zusätzliche Info enthält noch 2. auf meine eigentliche Aussage eingeht. Insofern wenns für euch funktioniert ist gut, für mich ist hier jetzt Ende. Bye Norbert

Da Exchange kein Sender based routing kann, ist das entweder immer derselbe senconnector aufgrund von * oder in der Priorität an der richtigen Stelle. Jedenfalls gibts da keinen für mich erkennbaren Zusammenhang von leerem oder nicht leerem Absender.

Steht doch alles schon oben. Leerer Sender heißt, es ist kein Return-Path (AKA Envelope Sender) drin und somit kann auf einen OOF auch kein Bounce erfolgen. Und leer bedeudet leer. NICHTS, Empty, Leer, Nada also auch keine Domain. Hier zum Nachlesen: https://datatracker.ietf.org/doc/html/rfc2298 bye Norbert

Die ist LEER. was soll er denn da finden? Es soll auf einen OOF keinen Bounce geben. Aus gutem Grund. Exchange verhält sich hier vollkommen RFC-konform. Ja es gibt Tools, die diese Konformität dann kaputtmachen, damit der Absender Ruhe gibt. Für mich kein sinnvoller Lösungsweg.

Na dann ist doch gut für euch.😆

Hängt halt vom Anforderungsprofil ab. Und bevor ich sowas pauschal umsetze, schaue ich mir evtl. eben erstmal die Konsequenzen an, die diese Konfiguration mit sich bringt.

Wer kommt denn auf die Idee 😆