Recent content by ChristophRo

The Comodo (free) ruleset is exactly the same for Nginx and Apache - you can compare it yourself - /etc/nginx/modsecurity.d/rules/owasp_modsecurity_crs_4-plesk - /etc/apache2/modsecurity.d/rules/owasp_modsecurity_crs_4-plesk When selecting the Nginx Option, the download and automatic update of...

The "rbl_reply_maps" parameter does not get touched/changed by Plesk on upgrades or mail repairs and so far we've never ever had this setting overwritten or deleted on any of our servers. So i'ts save to assume, that unless something extraordinary happens, you're save.

On the one server we did not already downgrade to dovecot v2.4.1, I've set "mail_attachment_detection_options =" option for now In the last ~30 minutes since that change, we've not had any singe crash of the dovecot imapsieve process. Sure, no guarantee yet, but it really looks like this might...

Problem may be related to Panic: file imap-sieve-storage.c: line 216 (imap_sieve_add_mailbox_event): assertion failed: (ismt->src_box == NULL || ismt->src_box == src_box) - dovecot - dovecot.org and thus might affect Debian 13 and possibly other OSes as well

looks like these problems are caused by crashes in the dovecot imap/sieve process

sorry, needed new post as there an error in the code snippets and editing does not work with these in it wget https://ch.origin.autoinstall.plesk.com/pool/PSA_18.0.75_18153/dist-deb-Debian-12.0-x86_64/opt/mail/plesk-dovecot_2.4.1-4-v.debian.12+p18.0.75.0+t251208.1034_amd64.deb wget...

OK, I've downgraded dovecot on one of our servers and the problem is gone! Now I just have to repeat these steps on the other servers and make sure that no auto-upgrade is happening again In case anyone else is having the same problem and needs to do the same: Warning! this only applies to...

we have already a cronjob running, that periodically removes these files in all tmp folders... shopt -s dotglob; find /var/qmail/mailnames/*/*/Maildir/*/tmp -type f -delete but they all keep reappearing (except if we disable these users/mail accounts) I did now also open a support request...

OK, it's worse than expected.... Happens on ALL our servers with Plesk 18.0.76 reveals that the same behavior can be seen on many account, but some do only have a couple hundred of the same files/mails in that folder and not very big ones. but we also see folders with several million! copies...

Since yesterday we now had two different servers, where the disk/partition for emails filled up completely within a very short time. (many 100 Gigs in our case) Both servers got updated to Plesk 18.0.76 beforehand and as we never ever had such an occurrence in the past, I do suspect a...

The Comodo Ruleset does no longer get updates (latest change is from 2023 or so) but still covers all the basics. You can use the OWASP ruleset, but in my experience this generates way to much false positives on a server with many different sites. (if enabled generally)

What we did in similar cases in the past, is to move the attacked site to a dedicated IP address and then depending on the attack volume and server load, either: a) block all traffic for this IP address via iptables b) only allow access from specific countries (we use iptables/ipset for that...

OK, I see now the incentive on why you force an automatic installation. But as the Joomla Toolkit is a paid extension and to my knowledge not usable at all without a subscription...I still don't agree with that move. (well, I do in general never agree on any automatic Extension installation...

Looks like you guys forced an auto installation of the Joomla Toolkit extension with it's latest 3.0.10 release on all servers....I do not like that! But what's even more annoying, is the fact that it's not possible to uninstall it anymore without encountering an error, that may or may not...

check "Tools & Settings" --> "Security Policy" --> "Storing email passwords" and make sure it's set to "Symmetric encryption"