In my experience, Roundcube constantly checks for new mail and therefore keeps the session alive. I currently have a Roundcube tab open for over an hour now (just a guess, I didn't actually look at the time) and it still hasn't logged me out. Maybe your Browser sends an inactive Roundcube tab to ...

mhagge wrote: ↑Wed 26. Aug 2026, 10:34 Reicht es aus, wenn ich das Postfach via Datenbank verkleinere? (müsste Tabelle mail_users -> size_max sein).

Ja, das reicht aus.

Du kannst ihn per Hand löschen: ---

Ich werd das Patch-System künftig erweitern, so das ich künftig in solchen Fällen bei Bedarf nach dem Patchen den Template Cache leeren und den Browsercache für ungültig erklären kann.

Ich konnte die Ursache auf PaterNosta Server nun nachvollziehen. Der neue Patch ist online (und ersetzt den Ersten). Die die Ihn bereits Installiert haben, können den Neuen einfach nochmal installieren und die Schritte zum Leeren der beiden Caches nochmal ausführen. Dann sollte es bei allen f ...

Für die Nachwelt: In den PHP-FPM logs waren häufig folgende Einträge ala Folgendem zu sehen: [23-Aug-2026 01:01:09] WARNING: [pool xxx] server reached max_children setting (3), consider raising it Lösung in diesem Fall: Über Benutzerverwaltung -> Benutzer bearbeiten -> Reiter: PHP-FPM -> Dort die Ein ...

Wie gesagt, es gibt keinerlei Pläne diesbezüglich.
Wenn es ein Protokoll zur Ablösung von IMAP/SMTP sein soll, dann natürlich nicht.

Das wären die Befehle die im Zuge eines Roundcube-Updates laufen sollten. Sofern also jemand das selbe Problem haben sollte, dann lieber diese beiden Befehle ausführen und nicht in der Datenbank selbst Hand anlegen ;). php /home/keyhelp/www/roundcube/bin/cleandb.sh php /home/keyhelp/www/roundcube/b ...

zu 1.) Ja, das habe ich auch gemacht. Ich nehme an, du hast den cache geleert, und die Seite aufgerufen, noch bevor der Patch überhaupt vollständig installiert war (kann auch bis zu 1 Minute dauern), damit wurde nochmal der alte stand der Datei gecacht. Geh einfach nochmal in die Toolbox und setzte ...

Tobi wrote: ↑Mon 24. Aug 2026, 11:49 kann man die "normale Fehlermeldung" irgendwie anpassen?

Die Nachricht steht in /etc/rspamd/local/force_actions.conf,
wird aber von KeyHelp wieder überschrieben, sofern man "Konfiguration -> E-Mail-Spam- & Virenschutz" speichert.

Diesen Schritt hast du aber auch erledigt, ja? 2) Einmal "keyhelp-toolbox" -> "Template-Cache löschen" --- Ferner berichten mir Benutzer ein weiteres seltsames Phänomen: Wenn man im hellen Modus im Datei-Manager unterwegs ist und Dateien ändert und speichert, wechselt das Design nach dem Speichern in ...

Ich hoffe doch, der Server wurde vor jeder KeyHelp Installation entsprechend wieder auf Betriebssystem Minimal-Installation zurückgesetzt. 1. Sicherstellen das dein Hostnamen korrekt auflösen würde (Einstellung beim Domain-Provider überprüfen) 2. KeyHelp Hostnamen ggf. korrigieren: Über keyhelp-toolb ...

Danke fürs Melden, ist korrigiert und über den Patch-Manager verfügbar.

Damit dieser Fix wirksam wird zusätzlich noch:
1) Browser-Cache leeren
2) Einmal "keyhelp-toolbox" -> "Template-Cache löschen"

Ein Eintrag in der Whitelist bewirkt, das die Email einen niedrigeren Spam-Bewertungs-Score bekommt und damit ggf. unterhalb der Greylist-Schwelle liegt. Beispiel: Eine Email kommt rein, und bekommt aufgrund diverser Kriterien einen Wert von 6.0 Ein hoher Wert bedeutet: wahrscheinlich Spam, ein ...

Aktuell gibt es keine Pläne zur Umsetzung von JMAP. Sollte sich JMAP künftig etablieren, wird es auch Einzug in KeyHelp halten.

Problem gelöst, Ursache war ein vorrangegangenes Read-Only Filesystem und ein Reboot mitten im KeyHelp Update-Prozess.