PHP Mail - now disabled on all shared

Over the past few months, we have noticed a large increase in outbound SPAM activity, which has unfortunately led to a number of our IP addresses and subnets getting listed on RBL's.

As such, we have made the decision to disable PHPMail() entirely across our network, restricting relays via SMTP only.

Please note, that all PHP scripts, or applications should be relaying through the SMTP protocol, and not PHPMail().

This ensures that your messages are relayed through our premium delivery solution, MailChannels without additional cost. This ensures your mail reaches the recipient, without risk of the messages being rejected on the basis of the RBL listings / IP blacklists.

This change has been made effective immediately, and was essential for us to improve our overall network IP reputation.

Client Area - Reseller Quotas Resolved

Previously, our client area was showing limits for those plans which didn't have any defined limitations. This was a bug in WHMCS, which we have now patched. The client area should now reflect the correct usage / available bandwidth and storage quotas.

Email Delivery Limits

Due to a number of abuse cases, we have been forced to revise our current configuration, limits and policies in terms of outbound mail.

As part of that revision, we will be decreasing our sending limit per account to 75/hour.

On checking through our service delivery statistics, for genuine usage, we anticipate less than 2% of accounts to be affected by the change globally.

The new limits ensure that we are able to continue to provide MailChannels, which we know remains ever-popular within our hosting solutions.

AutoSSL - Patch Fix

We have received a number of reports from clients, where SSL certificates have not been installed, or have stalled through the AutoSSL procedure.

We have an extensive conversation earlier today with one of the Senior Techs at cPanel, who have confirmed a bug. This bug only takes place when AutoSSL attempts to enqueue larger quantities of subdomain / domains through their daily cron, which eventually hangs / never completes.

The expected release time for the patch was 100 days, which of course wasn't acceptable in our case.

Given their delay in terms of releasing a patch fix, we have decided to write a fix in-house for this, which after thorough testing resolves the issue.

Once cPanel release an official patch for this, or release in an upcoming version our patch-fix will be removed, in place of their own solution.

For now, AutoSSL is now working again as expected.

PHP Versions 'Auto Changing'

We had a number of tickets raised by clients stating that their PHP versions were 'reverting' periodically.

After thoroughly investigating the issue, we have found that this issue is isolated to accounts which have been migrated from other hosting providers which specifically make use of the MultiPHP Manager in WHM / cPanel.

At Brixly, we don't use the MultiPHP Selector throughout, allowing us to make use of the 'PHP Selector' which is bundled with the Cloudlinux product.

The investigation led us to notice that the MultiPHP configuration was being migrated from the previous provider, ignoring the global 'disable' of this functionality on our own servers.

We have raised this with cPanel, who confirmed they believe this to be a bug, however we have deployed a solution internally to resolve the issue.

We have added a 'post restore' cPanel hook, which now resets the PHP Version to 'Inherit', allowing the account to make full use of the Cloudlinux PHP Selector as intended.

This script is publicly available here…

https://gitlab.com/brixly/file-dump/raw/master/php_version_inherit_hook.sh

The fix has now been deployed to all servers.