Recent content by ChristophRo

ipset is the way to go can be used for (automated) geo-ip feeds as well as manually maintained csv/txt files with 100k+ IP addesses/subnets and if you need to "whitelist" certain IPs, just put them in another ipset and put the ALLOW iptables rule for that ipset before the geo-ip/manual blocking

Seems like somewhat of a clusterf*ck in my opinion and also not what I expected it to be (from reading the release notes) Also leads to the somewhat silly situation, that on Debian 13 I can get PHP 7.0 trough 8.5, while on Debian 12 it's only possible to get 7.4 to 8.5... But on Debian/Ubuntu...

OK, as a customer of (many) Plesk Web Host licenses for phyiscal servers, I'm going to check wich ones will expire in the next 5 month and probably cancel & reorder them. And once they are all "aligned" to the black friday week/month, we may save many thousand bucks a year, by just cancel and...

I've seen a similar thing on at least one of our servers and I'm still investigating it. lately a LOT of emails have huge negativ scores (-3 to -8 points) on various "_VALIDITY_" as well as "DEF_DKIM_WL" and "DEF_SPF_WL" checks... so far I could not find out WHY these checks score so massive...

stumbled accross the same problem (status module was no longer enabled) on a Debian11 to Debian12 upgrade so, thanks for "confirming" that this happens on a "plesk repair" operation. (that gets executed automatically on a dist upgrade)

you should delete any *kolab* config file you'll find in /etc/dovecot/conf.d/ ! These are old config files from the Plesk Premium Email extension that did not get cleaned up on deactivation/uninstallation of that extension. (do you have it only deactivated or really uninstalled? that is not...

here you go: So, this time all the VPS users get screwed with ludicrous price increase, while the last three years the same was done to the dedicated/baremetal users.

That does not make sense to me, as Roundcube does use "PLAIN" per default (maybe you've changed the imap_auth_type/smtp_auth_type in the Roundcube config once?) As we have a couple or Plesk servers where CRAM-MD5/DIGEST-MD5 is manually disabled for Postfix/Dovecot since ages, I know that...

Dunno, but we have all the auto-update settings enabled on our servers and so far not once it installed a new release automatically, at least not in the first couple of weeks after release. (all the interim and extension updates, as well as OS packages get updated though) Hmm, ok, now that I...

Debian 13 is not (yet) supported by Plesk, so you are completely out of luck. You can try do downgrade again or migrate all your webs to another server with Debian 12 or live with the current situation and wait till Debian 13 is supported.

It does not matter if you remove DIGEST-MD5 or CRAM-MD5 in retrospect, as some mail clients (Thunderbird is among them) do "detect" these server capabilities only when you setup an account. If the server does advertise MD5, Thunderbird will automatically use the encrypted password option until...

Given the circumstance that your server is compromised and the hacker has gained root access (otherwise they could not use the mail_auth_view utility anyway), what is stopping them from executing cat /etc/shadow and/or plesk db "select password from accounts" to see the hashed password of all...

I do agree on this one! Of course it will not work properly, the way Plesk rushed out this feature! As I already wrote on the 20th of August, if a mailserver does advertise any of the MD5 authentication methods, certain mail clients (Outlook ahoy!) will randomly fail when the password of the...

$2y$12$ is the hashing algorithm used, in this case bcrypt. It's the recommended method, to store the algorithm together with the password this way and I don't see why that would pose any security risk. "Security by (pseudo) Obscurity" is not a thing! and not doing it this way would only...