Recent content by websavers

Hey @Sebahat.hadzhi - thanks for the update. We're still working on determining the source of the issue as it's not occurring for all clients. It may be that a 3rd party extension that still uses standard password authentication is triggering this, possibly only when the saved password for Plesk...

How do we get this fixed now that you know it's still occurring with the most recent version of WHMCS? In particular, if the passwords are correct, why does it seem to be rate limiting API access?

We have reproduced the identical issue with WHMCS 8.13.1 (latest) and Plesk 18.0.70 Update #1

Same issue occurred here on one of our boxes, and it had completed successfully in the background, but the UI lost its connection apparently. If you open Plesk fresh in a new tab, it'll likely show you that it was completed successfully with a notification in the lower right corner. The...

Thank you for the clarification! My understanding is that most mail clients that have already negotiated with the server a previous time will assume the same connection settings and present an error if they don't work (unless the client has an 'automatically try other settings' option)...

I didn't say a MitM attack would require STARTTLS. I'm saying a MitM attack only works if there's no security on the connection at all and since Plesk requires STARTTLS on 587, the certificate validation would fail once STARTTLS was attempted to be negotiated (which occurs prior to...

This is a good point. Very few people are going to notice this kind of minor, yet surprisingly important adjustment for user experience. That means that, compared to other requests, it's likely going to get buried underneath the pile of 'fancy new stuff', making the whole point of having it in...

I have done so, thank you.

Explain. We're talking in the context of Plesk servers. By default Plesk servers require STARTTLS on 587. So in the context of Plesk servers, how is that relevant?

I'm not certain if that's exactly our issue, but we do have clients reporting issues with some mail apps on 465 that work fine with 587, so that probably is the issue. Another reason why, when 587 is enabled in Plesk, it should be the default in all guides.

@Kaspar@Plesk when the submission port (587) is enabled, that should become the default in all guides, not 465. We shouldn't have to use a panel.ini override to do that. In other words, keep it at 465 if submission port is not enabled, and force it to 587 when submission port is enabled.

Found the source of this issue and a solid workaround. Apparently Virtuozzo/OpenVZ symlinks /sbin/init to systemd within the container, but then on the node when vzctl launches things it passes init parameters in like: init -z, which results in systemd -z. For reasons unknown to me, the -z...

@Dave W would welcome a pull request with these changes over on GitHub if only to ensure it works in more scenarios! Technically we could modify the --d value to --description in alamconvert8_plesk via sed, though I'd also recommend submitting that to Virtuozzo devs. If you have a vz license...

I believe these might have been two different things. 1. @mow described that when you create an email account in Plesk, it creates a *mail* user that can login to Plesk. It has limited capabilities, just to set things like the autoresponder and manage the spam filter for that particular email...

@Dave W Just realized - did you remove /root/almaconvert8-plesk after updating Virtuozzo/OpenVZ? Our wrapper will likely need to copy an updated version of the software over and modify it, but it assumes you started this from an updated node.