NorbertFe

Wie wärs wenn du den Rechtsbeistand fragst. ;) Dürfen wir hier nicht, aber ich hab mal gegooglet (ohne Anspruch auf irgendwas) https://www.computerweekly.com/de/ratgeber/Datenschutz-Rechtskonforme-Spam-Filterung (Zwar schon älter, aber ich bezweifle, dass sich da wirklich großes dran geändert hat) Für rechtlich verbindliche Aussagen siehe meinen ersten Satz. Wenn du sie also NICHT annimmst, dann hast du genau dieses Problem gar nicht erst. Und ja das ist ein Unterschied, ob ich eine Mail nicht annehme oder sie nach der Annahme dem eigentlichen Empfänger vorenthalte. Bye Norbert

Dann schau doch mal mit adsiedit nach. CN=NetServices,CN=Services,CN=Configuration,DC=domain,DC=tld Man kann die Autorisierung auch delegieren, so dass man dazu nicht Org-Admin sein muss. https://secureidentity.se/delegate-dhcp-admins-in-the-domain/ https://regularsysadmin.wordpress.com/2015/02/07/delegating-microsoft-dhcp-server-administration-completely/

Ja, das ist der Zweck eines Rejects. Eher unwahrscheinlich, da oft nicht den Sender Address (RFC5321.MailFrom) gefälscht wird (jedenfalls nicht _an_ dich, sondern von anderen), sondern die From (RFC5322.From und die steht innen und interessiert bei SPF null) und wenn, dann sollte euer System eben Backscatter erkennen können. ;) Man löscht keine Nachrichten ohne Benachrichtigung. Isso. Ich weiß, das will dein Chef nicht hören. Jeder wie er meint. Bye Norbert

Hardware? Ich kenn solche Phänomene aber auch unter Windows 10 schon. Meist hat ein Update des Docks geholfen.

Schlechte Idee. Reject wäre das Sinnvollste in dieser Situation. Tausch den Mist aus. Anders kann man das nicht mehr bezeichnen. Und wenn du nach deinem Smarthost was einfach löschst, dann bist DU verantwortlich. Der richtige Punkt für die Spamfilterung ist IMMER der erste annehmende Host für deine Domain. Wenn das dein Smarthost ist und der sowas nicht kann, dann wirds echt Zeit und alles andere brauchst du dir nicht ausdenken, denn das wird nur Quark.

Man müßte halt lesen, was einem geantwortet wird. Ohne SPF/DKIM und DMARC wirds garantiert nix und selbst mit denen gibts immer noch diverse Situationen, wo Fehler auftreten. Die sind dann aber eben auch seltener im normalen Mailverkehr

Das schaffst du nicht (allein) mit SPF. Ja. Siehe oben. Und an der Stelle solltest du als erstes ansetzen. Denn wenn du nicht weißt, wie und warum deine Mails irgendwo landen, ist das immer ein schlechter Start für Antispam Maßnahmen. SPF kann man dann immer noch leicht konfigurieren. Dein Problem hat aber wie schon erwähnt mit hoher Wahrscheinlichkeit gar nichts damit zu tun. Bye Norbert

Weil man dann nur ein bisschen Spam bekommt, oder wie? Gleich vorneweg: SPF hilft heutzutage nur noch bedingt. Auch Spammer können SPF. ;) Zu deinem Problem: Es wäre einfacher, wenn du das mal konkret skizzierst. OWA wäre ja direkt per https auf dem Exchange und da spielt der SPF Record keinerlei Rolle.

Schau mal, was du für Backup Software bekommst, die Proxmox nativ unterstützt und vergleich das mal mit Hyper-V oder ESX. Von den beiden letzteren gibts übrigens genauso kostenfreie Editionen die in deinem Fall vermutlich ausreichen und die genauso "sehr problemlos" laufen würden. ;)

Ich werte den ;) mal entsprechend. :p

Wenn ich das richtig sehe, aktiviert das wieder RC4 korrekt? Da bin ich bei solchen Quick'n'dirty Lösungen ja immer skeptisch, ob hinterher überall auch wieder auf 24 gesetzt wird. ;) Und dann sind sich alle sicher, dass sie immer gepatcht haben und vergessen die Q'n'D Aktion ausm November 2022. ;)

Dazu hatte ich ja neulich einen Thread aufgemacht, aber das war noch vor den November Updates. Ich hatte übrigens heute einen anderen "netten" Fehler mit CVE-2021-42287. Das hatten wir vor Monaten auf 2 gesetzt und gefühlt seit Oktober (das war ja angekündigt) liefen die GPOs auf den DCs nicht mehr alle. Aufgefallen ist das, weil per GPO auf dem PDC Emulator der falsche Zeitserver (auf Domain Root auf NT5DS) ankam, anstatt der entsprechende NTP Server. Policy auf nicht konfiguriert gesetzt Fehler weg Zeit wieder in Ordnung. :/ Nervt aktuell richtig, wenn ich auch an das aktuelle Problem mit DirectAccess denke. Bye Norbert

Wie hat sich das denn gezeigt? Fällt vermutlich in einer Kerberos-only Umgebung deutlich schneller auf als in einer wo NTLM als Fallback noch läuft, oder?

Ja.

Ja aber auch da für jedes einzeln und dann per Schleife. ;)

Wieso ob? Na klar kann man das machen. Obs hilft oder sinnvoll ist, sei mal dahingestellt. :)

Wirf es nochmal raus und importiere es komplett neu (per Exchange Powershell). Alternativ vermutlich sowieso egal. Was ergibt ein Test mit checktls.com? Alternativ 2: Setz das Zertifikat explizit in den Sende- und Empfangsconnector. Bye Norbert PS: Der Thumbprint ist nicht geheim. ;) Der steht im Zertifikat öffentlich zugänglich.

Hast du geklärt, dass das Zertifikat gültig ist? Hat der Exchange evtl. einen Proxy eingetragen? Welchen Fehler gabs denn? Zertifikat ungültig oder kein Zugriff auf die CRL. Viel mehr Möglichkeiten gibts nicht. Bye Norbert

Es geht um den exchange Patch, nicht um den für Windows. ;)

Wenn man weiß, warum das auftritt, kann man durch "zügiges" Arbeiten viele der Meldungen abfangen, aber eben meist nicht alle.

Ja logisch. Interessant war ja auch nicht welche ClientAccessservices du hast, sondern was im oben erwähnten autodiscoverserviceinternalURI steht. Wenn dort überall exchange.domain.de drin steht, dann is ja gut, und dann wird sich der Client irgendwann auch beruhigen. Ist halt immer das Problem bei Neuinstallationen, dass der Server erstmal mit einem falschen Wert installiert wird und man das danach grade ziehen muss.

Im Zweifel sind beide falsch, aber wenn deine Clients Exchange2013 eben akzeptieren, solltest du den erstmal weiternutzen. Ansonsten hilft es, sich mal drüber schlau zu machen, wie Autodiscover funktioniert. :) Du sollst schauen, was unter autodiscoverserviceinternalURI steht. :) Und da steht drin, was die Clients versuchen zu erreichen.

Hast du den Exchange einfach mit Setup weiter enter enter installiert, oder hast du dazu ein How To verwendet?

Na dann hast du doch den Fehler schon gefunden. Zumindest den SCP (set-clientaccessservice) solltest du erstmal auf den bereits existierenden Server setzen. Bye Norbert

Das hilft dir in diesem Falle NUR, wenn die gefakten Absender auch DMARC für ihre Domain konfiguriert haben. Dann würden diese Mails nämlich anhand der DMARC Richtlinie rejected oder in Quarantäne geschoben werden. Ich bevorzuge ersteres. Hatte den selben Fall wie du am Anfang der Woche, und mein Kunde hat DMARC konfiguriert, aber leider setzen viele Empfänger die DMARC Policy offensichtlich aus was auch immer für Gründen nicht um, so dass sie die gefakten Mails dann mit dem Vermerkt "Spamverdacht" oder ähnlichem bis zu deren Empfängern durchgelassen haben. Die stellen dann natürlich meinem Kunden die Frage, warum sie sowas denn bekommen. Und nein, mein Kunde ist NICHT gehackt worden, sondern das waren Mails, die er vor "Wochen" mal an Kunden geschickt hatte. Also ist nicht nachvollziehbar, wo die Daten abgeflossen sind. Kann nämlich auch bei anderen Kommunikationsteilnehmern geschehen sein. Ich empfehle jedem Mailadmin usw. sich mit DMARC, DKIM (und SPF sowieso) zu beschäftigen. Das wird in Zeiten von Phishing immer wichtiger und ist keine Raketentechnik. Im Zweifel fragt man jemanden der sich auskennt. ;) Bye Norbert Der zeigt meiner Erfahrung nach Tagen schon keine Wirkung mehr, und bei Mailkommunikation die mehrfach hin- und hergeht, hat der Nutzer dann das Problem, dass dann mehrfach im Betreff dieser Kram auftaucht. ist wie 1, und sorgt nur für zertorfte Mailbodies, die dann auch keiner mehr sinnvoll lesen kann/will. S/Mime hast du schon angesprochen, man macht sich also das kaputt, was als einziges eindeutig beweisen kann, dass die Mail korrekt vom Absender käme. ;) Nr. 3 ist wichtig, darf aber nicht zu häufig stattfinden, weil das die Nutzer "belästigt", und das wollen die ja nicht. Im Zweifel hilft die Info an alle, dass sie lieber einmal zuviel fragen als einmal zu wenig. Geht natürlich nicht bei jedem Kunden. Bye Norbert