Es gibt aber auch viele E-Mail Messies die Papierkorb und Spamfolder zwangsläufig niemals leeren, da kommt dann einiges zusammen ...

Einstellungen ---> Konfiguration ---> E-Mail-Server ---> Screenshot from 2025-07-09 17-11-05.png Das sollte das Problem beseitigen, oder? Nicht ganz ... wenn z.b. die besagten 10 Emailkonten mit jeweils 10GiB "VOR" einem Account Overquota angelegt wurden, greift es nicht und Emails werden weiterhin ...

Also da sind ganz sicher neuere Logins veröffentlicht worden, vor allem Email Zugänge, heute wieder 2 Kunden die erst vor 2-3 Monaten angelegt wurden. Es gab keine fremden Panel Logins d.h. die Emailkonten Logindaten wurden sehr wahrscheinlich direkt von Email Clients abgefischt ... zufällig mal wi ...

Florian wrote: ↑Fri 4. Jul 2025, 10:18 Natürlich kannst du das über Massenoperationen im Menü links

oho ... das ist ja sehr gut, damit bin ich dann für heute komplett beruhigt
Ist mir bisher gar nicht aufgefallen ... sorry.
Ich danke dir!

Hallo, die kannst normal keine PHP Version löschen im Keyhelp wenn diese in Verwendung ist. Oh, wäre dann problematisch bei sehr vielen Domains ... gibt es denn eine Möglichkeit um ein Bulk Update durchführen zu können, also alle betroffenen Domains markieren und z.b. 100 oder mehr auf einmal zu änd ...

Was geschieht mit den Kunden/User PHP settings wenn ein Admin eine compiled PHP Version löscht die von diesen Kunden/User in Verwendung ist? Müssen dann alle User PHP Versionen von Hand umgestellt werden oder fallen diese PHP Versionen dann auf PHP System default zurück? Es geht darum bei kommenden R ...

Das Problem wird so schnell niemand in den Griff bekommen, nicht mit Geoblocking und auch nicht mit IP Blacklists ... weil die Botnets bereits zu riesig geworden sind und neue attackierende IP Adressen jeden Tag massenhaft hinzukommen :roll: Wäre vieleicht besser und weniger Aufwand nur Whitelists ...

Für country blocking verwende ich ein script was einmalig beim Systemstart ausgeführt wird. Script & Länder können und sollten erweitert und optimiert werden, ich verwende eine externe FW und habe die KH FW deaktiviert, mein script ist auch etwas umfangreicher, aber unten mal ein kurzes Beispiel daz ...

Ich sehe keine Probleme damit, keine Fehlermeldungen oder Warnungen (rspamd, clamav, postfix) ... anscheinend unbedenklich.
Wird vermutlich irgendwann mal überschrieben, habe die clamd.conf bezgl. Änderungen auch mal ins monitoring gepackt.

Wenn ich für ClamAV (monitoring) das PID file aktiviere, könnte dies Konflikte mit der neuen config (rspamd, clamav) verursachen?
Sollte doch machbar sein oder?

Halte ich persönlich nicht für sinnvoll. Dann kannst du auch gleich wieder MD5, SHA-1 oder SSLx.x zulassen. Manche Sachen sollten einfach als notwendig deklariert werden, zumal ja in diesem Fall sowieso nur Hashes ausgetauscht und überprüft werden, was aus Sicht des Datenschutzes ja nun keinerlei Pr ...

Ist schon nervig u. paradox, der ganze DSGVO Kram steht mit momentan notwendigen sicherheitstechnischen Schutzmaßnahmen immer in Konflikt ... Wäre vieleicht keine schlechte Idee, wenn der User diese Option für HIBP selbst aktivieren müsste, schau mal wie z.b. keymatiq das machen: https://key.matiq.co ...

Jolinar wrote: ↑Sat 28. Jun 2025, 10:34 Würde auf jeden Fall Sinn machen...

Ok, hast Du eine Ahnung wie es sich technisch damit verhält ist es ein lokaler Check oder auch eine Übermittlung?

Disallows the 100,000 most common passwords.

Ja, ein klarer Verweis in den AGB und/oder der Datenschutzerklärung ist absolut empfehlenswert und aus Gründen der Transparenz und der Datenschutzgrundverordnung (DSGVO) auch notwendig. Der Nutzer muss darüber informiert werden, dass eine Überprüfung seiner Passwörter mittels eines Dienstes wie Have ...

Ist das 100% der Fall? Ja. Ich habe bisher noch kein "compromised PW result" in KH gesehen, wie sieht diese Meldung aus bzw. was bekommt der Kunde angezeigt - wird auch eine Email versendet? Leg testweise irgendwas an, wo ein PW erforderlich (zB. einen User) und gib dort ein kompromittiertes PW an ...