Jump to content

NorbertFe

Expert Member
  • Gesamte Inhalte

    43.299
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von NorbertFe

  1. Vielleicht sind auch einfach Makros unterbunden. ;) Will man wegen der Nutzer dann das Sicherheitsloch wieder aufmachen?
  2. 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. ;) 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 Du hast komische Vorstellungen. ;)
  3. Dann gehts dir wie mir. So in etwa hab ich das auch in Erinnerung, finde aber auf der Partnerseite gerade nicht den Vertrag bzw. die Nutzungsbedingungen.
  4. Hi, kann mir jemand spontan verraten, ob die IURL (Windows, Exchange, SQL, CALs usw.) aus der MS Partnerschaft auch in fremden Rechenzentren (nicht eigene Hardware) betrieben werden dürfen? Ich meine explizit nicht Azure (wäre aber ggf. auch interessant), sondern klassische Anbieter in eigenen RZs. Danke Norbert
  5. 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!
  6. Dann machst du was falsch. ;)
  7. Sehr „sinnvoll“ nicht.
  8. 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.
  9. Naja das VLSC ist so ziemlich die letzte Krücke für sowas, man hat sich nur dran gewöhnt. Allerdings ist das neue auch irgendwie "sch...e" ;) MS kann sowas nicht.
  10. Du mußt die Webconfig nicht anpassen: https://www.frankysweb.de/exchange-server-und-amsi-ein-paar-infos/ (kann man auch global abschalten) bis Sophos evtl. mal vernünftige Software liefert. Alternativ nimm den Sophos Client vom Exchange runter und nutze vorerst den Windows Defender, der diese Probleme nicht hat.
  11. Schwer abzuschätzen. Landet man von extern direkt auf dem Exchange? Bietet der TLS 1.2 an? Falls davor Firewall und oder Reverse Proxy stehen, dann musst du da suchen. Bye Norbert
  12. Könnte mit amsi zusammenhängen. https://www.frankysweb.de/exchange-2016-2019-amsi-integration-sorgt-fuer-probleme-mit-outlook/
  13. Also ich bekomme da eins, welches am 4.5.2021 ausgestellt wurde und bis 29.4.2022 läuft.
  14. Wenn Send-As Rechte genutzt werden, maximal noch in irgendwelchen korrelierenden Anmeldelogs. Deswegen ggf. sinnvoller mit Send on behalf arbeiten.
  15. Hmm Überlegungen die ich zum Glück nie anstellen muss. ;) Geld kommt doch aus dem Drucker, oder?
  16. Und warum Single Socket? Gibt doch immernoch vernünftige CPUs mit 8 Core und Ghz. Alternativ passt doch in so ziemlich jede Dual CPU Serverplattform auch nur Single CPU. ;)
  17. Hab ich mich doch oben schon korrigiert. Da brauch ich doch kein lmgtfy ;) trotzdem danke. :)
  18. Was steht denn als Firewall davor? Kenne genug, die solche Tests unterbinden.
  19. Bis jetzt ging das in allen Hochschulen die ich (von innen) gesehen habe. ;) Da sitzen dann Leute die ad und DNS können. ;) scnr.
  20. Wäre aber praktischer. Denn dann würden sich solche Fragen gar nicht stellen. Das war Nils' und mein Hinweis.
  21. Achsoooo :)
  22. Na dann ist doch alles gut. Oder wo ist das Problem?
  23. Bist du sicher, dass die SIgnierung bei Nicht-Domänenmitgliedschaft möglich ist? Ich bin da nicht sicher, deswegen oben auch das AFAIK. Edit: OK im verlinkten Artikel steht es wäre common bei Nicht-Windows Clients, also muss es wohl gehen. ;) Vermutlich meinte ich, dass man keinen Klartext Simple Bind hinbekommt. Ich hatte dazu damals auch einen Artikel bei Nils veröffentlicht: https://www.faq-o-matic.net/2018/07/16/ldap-signing-auf-domnencontrollern-erzwingen/
  24. 389 vermute ich? Das kannst du mit ldp oder jedem beliebigen LDAP Browser testen. Du wirst einen simple Bind nicht hinbekommen auf Port 389. alternativ nimm dir Wireshark oder den netmon und schau nach, ob das Klartext ist. ;)
×
×
  • Neu erstellen...