NorbertFe

Genau wie Leerzeichen. Nicht ganz so b***d, aber b***d genug. ;)

Da wir die Empfehlung so nicht gehört haben und kennen, kann man schlecht sagen, ob dein Vorgehen korrekt so abgestimmt war. :)

Ich hatte auch noch nie einen Schädelbasisbruch. ;)

Google ist sicher ein Begriff, oder? ;) https://www.alitajran.com/exchange-send-connector-logging/

Falls ihr greylisting einsetzt, würde ich den Absender mal davon ausnehmen.

Weil grad das Update für SnagIt kam ;) https://support.techsmith.com/hc/en-us/articles/115006435067-Snagit-Windows-Version-History Fixed an issue that prevented accessing Snagit with a Windows username containing non-Latin characters. ;)

Nein wirklich? ;)

Es bleibt ja die Frage, ob du teamviewer pauschal weniger kritisch siehst. ;) also da kann man sicher drüber diskutieren, denn am Ende ist teamviewer auch nur eine Art „VPN“.

Das macht schon die Gegenstelle. Dein Server muss es nur können. Deswegen die Frage, wie das überhaupt bisher funktioniert hat, denn standardmäßig spricht der Exchange immer opportunistic TLS, es sei denn deine Zertifikatskonfiguration ist schief. Und das sollte man dann eigentlich finden und Ansätze im SMTP Log finden. ;)

Bleibt ja die Frage, ob man überhaupt im Klartext senden will oder sollte. ;) Wenn man dann über Port 587 auch StartTLS anfordert, dann kann man auch gleich Port 25 nutzen.

Und du hast bis heute kein tls konfiguriert? Wie bekommt man das denn hin? ;) wenn du ein Zertifikat an den smtp service gebunden hast, sollte das eigentlich der Standard sein, dass per tls versucht wird. Was steht denn im smtp log des send connectors?

Mist :) https://www.microsoft.com/en-us/download/details.aspx?id=47594 hier steht immer noch nur 2016 und 2019 ;) Schön versteckt die 2022 in deinem Artikel ;)

Mal die Frage an alle anderen: Gibts schon Aussagen, ob Windows 2022 irgendwie auch noch supported werden soll?

Das is so eine typische "Religionsdiskussion". Da wird keiner Recht oder Unrecht haben, und am Ende immer mit Erfahrungen der einen oder anderen Seite kommen. ;)

Man muss ja VPN Einwahlen nicht rund um die Uhr erlauben (würde ich bei Teamviewer ja auch nicht!).

So ein BS. ;) Ich hab zig Kunden bei denen das KEIN physikalisches Gerät regelt sondern eben einer der DC (PDC Emulator) die Zeit von einer externen Quelle holt. Wenn der Rest stimmt, gibts genau keine Probleme mit solchen Konstrukten. Und Windows Server und Clients holen sich per Default die Zeit von ihrem Anmelde DC und wenn der eine VM ist, dann eben da. ;)

Zwei mx sind ja nicht das Problem. Das ist einfach zu lösen, Mails über zwei Leitungen zu empfangen. ;) der Versand ist ohne externen Smarthost schon schwieriger.

Dann solltest du deinen VPN Admin fragen, wie man das vernünftig regeln kann. Gibt schließlich auch VPN Lösungen die nur bestimmte Ziele und Protokolle zulassen, je nachdem was man braucht.

Cloud? ;) ansonsten mal drüber nachdenken, den Versand dann eben über einen externen Smarthost-Anbieter zu regeln. Dann ist die eigene Leitung egal. Ist halt die Frage, ob Empfang oder Versand kritischer sind. ;)

In etwas weniger Reißerisches. ;)

Ja, warum auch nicht? Über die öffentliche ip wäre das ja auch erreichbar (wenn der reverseproxy es zulässt). DNS caching?

So kurz noch als "Lösung". Da ich ja der ausgehende Mailserver bin, hab ich das jetzt mittels Addressrewrite auf meinem Edge (Edge01) geregelt. ;) Kann mich MS mal gerne haben.

Vielleicht mag ja mal einer den Betreff hier im Thread ändern? Ich mein, bisher ist diesbezüglich nur Version 1.x abekündigt, weil die SQL Version eben veraltet war und man vermutlich keinen Bock mehr auf Windows 2012R2 hatte. ;)

Ich lese eure Posts und glaube ja selbst auch, dass es AADC nicht ewig geben wird, aber wo steht bei MS die Ankündigung, dass es abgekündigt wird bzw. wie der lifecycle dafür aussieht? Dass MS lieber ihren Clouddienst pflegen als eine lokale Komponente ist mir klar.

Und wenn du den mal löschst? Wird er dann korrekt erstellt?