NorbertFe

Nö, wenn ein TLS Zertifikat gebunden ist, macht das Ding soweit mir bekannt automatisch TLS 1.0-1.2 wobei man TLS 1.0 wohl abschalten kann, wenn ich den Text da richtig interpretiere. Kann natürlich sein, dass beim TO vor der Sophos noch was steht, was am SMTP Traffic rumfummelt. Spontan wäre Cisco mein Gedanke. ;) Aber dazu müssten wir mehr über die Konfig wissen. Bye Norbert

Also ich bezweifle, dass dir GMail was mit TLS 1.0 oder so schicken würde. ;) Also kannst du üblicherweise TLS 1.0 und TLS 1.1 abschalten, weil TLS 1.2 inzwischen der Quasistandard ist. TLS 1.3 bei diversen Systemen ebenfalls.

Korrekt. Wobei mir persönlich die IPs wichtiger sind als die Namen. Die Namen sind in weniger LDAP Applikationen eingetragen als die DNS Server-IP bei x Geräten. Kommt natürlich immer auch auf die Umgebung an, aber bei LDAP ist zumindest meine bisherige Erfahrung so, dass normalerweise der Domain-Path und nicht zwingend einzelne DCs angesprochen werden. Womit ich sagen will, ich persönlich hätte vermutlich eher DC3 installiert und danach dann die IP-Adressen gewechselt mit DC2. ;) Bye Norbert

Genau das wäre sicherlich die sauberste Lösung, die beide Anforderungen (Namen/IP und Verfügbarkeit/Redundanz) vernünftig zu geringen Kosten erfüllt.

Nein mit „geht doch“!

Das war vor 10jahren technisch sogar noch so, inzwischen gibbet da ja was aus der Cloud.

Sophos wird bald keine on-prem software mehr anbieten. https://support.sophos.com/support/s/article/KB-000034795?language=en_US Bei eset weiß ich es nicht. Aber das sollte ggf. Berücksichtigt werden.

Das das eine so vorgesehen ist und das andere nicht. Deine manuelle Art und Weise sorgt im Allgemeinen regelmässig dafür, dass Fehler auftauchen. Wenn das bisher bei dir nicht der Fall war, sei froh. :)

Das ist eigentlich schon der Fehler. So sind Raumpostfächer nicht gedacht. ;)

Selbst durchprobiert, oder gabs Unterstützung vom Hersteller? ;)

Hi, Microsoft hat die aktuellen Exchange Security Updates bereitgestellt. Dran denken, dass nach der Installation manuell /PrepareAllDomains ausgeführt werden muss. Weitere Infos und Downloadlinks gibts hier: https://techcommunity.microsoft.com/t5/exchange-team-blog/new-exchange-server-security-update-and-hotfix-packaging/ba-p/3301819

Da wirst du wohl eine neue Vertrauensstellung konfigurieren müssen. Ist ja ein eigener Server mit eigenen Settings. So wie Test- und Produktivsystem. Ansonsten wie Nils schon schrieb mal mit dem Hersteller klären (auch wenn das vermutlich zu keinem sinnvollen Ergebnis führen wird. ;)) Die XML kann eigentlich nicht identisch sein, denn ggf. sind ja andere Zertifikate drin und auch die ZUgriffsURL sind ja ggf. anders. Bye Norbert

Wir haben bei uns und bei Kunden SecureHub von Zertificon im Einsatz. Gibts aber ähnliche Lösungen auch von NoSpamProxy usw. Bei Zertificon geht es definitiv ohne weitere Module aus dem Zertificon-Portfolio. Sehr praktisch die ganze Sache. https://www.zertificon.com/loesungen/sicherer-datenaustausch-unternehmen https://www.nospamproxy.de/de/produkt/grosse-dateien-versenden/

Korrekt. Würde ich definitiv auch von abraten.

Weil sich bei Raumpostfächern vor dem Empfang der ersten Einladung kein deutsches Outlook angemeldet hat. Wenn du da unbedingt "Kalender" haben willst, melde dich als Berechtigter beim Raumpostfach bspw. über OWA an und lass die Ordner umbenennen (gibt in den Optionen einen Haken). Oh zu spät gesehen, ist ja schon gelöst :)

Die Datenbank oder die Postfächer? Funktioniert Autodiscover korrekt? Findet sich bestimmt jemand. POPCon ist übrigens etwas, was niemand der das beruflich macht, gern macht. ;)

ARC Fail wäre ja von GMX. ;) Denn der Empfänger führt ja das ARC Signing und ARC Checks durch.

Bitte beachten, dass das bei lokaler Definition nur lokale Nutzerkonten betrifft (Passwortrichtlinie oder Änderung usw.) und nicht für Domänenkonten gilt. Sowas definiert man aber selbst dann per Domain GPO (auf anderer Ebene oder OU), als das lokal zu konfigurieren.

Sogar mit 2022 OS ;) Mit CU12.

Wie schon erwähnt prüft das Tool NICHT die Sysvol-Replikation.

Das ist irgendwie auch "nur halb" richtig. Wenn von einem nicht Exchangepostfach an einen NICHT Existierenden Empfänger (mailadresse) geschickt wird, sollte der EXCHANGE eben KEINEN NDR generieren. Steht oben jetzt bereits in mehreren Posts. Es wird nur der Statuscode im SMTP Traffic übermittelt. Was der ursprüngliche Absenderserver daraus bastelt, liegt nicht in deinem Einflussbereich. Und führen bei Admins schneller zum Ziel als diese bunten Dinger von O365, die kein normaler User liest sondern Screenshots vom bunten Teil an den Admin schickt, der darauf antwortet, schick mir den Teil wo steht "für Administratoren". ;)

Gut, wenn man einen Spamfilter hat, der sowas einfach macht. ;) Achso

Nö, glaube ich nicht, dass wir da unterschiedliche Ansichten haben. Interessant wäre, warum auch intern der remote Server was returned. ;) Siehste, so unterschiedlich sind unsere Ansichten gar nicht.

Siehe 2. im Post über dir.

Nochmal, deine Konfiguration läßt eine Fehlkonfiguration vermuten, denn wenn die Adresse nicht existent ist, wird der NDR gar nicht vom Exchange sondern vom Senderserver erstellt. Alles andere führt im Normalfall zu Backscatter und für dich unnötigen Ressourcenverbrauch (HDD, CPU, Bandbreite) und damit ggf. auf eine entsprechende Blacklist. :)