Beginning on December 2, 2024 we will be switching accounts that are currently using PHP 8.0 to PHP 8.2.

Official support for PHP 8.0 ended about a year ago, on November 26, 2023. It is time for this version of PHP to begin being retired. Accounts created within the past 6 months have had their PHP version set to PHP 8.2 by default.

In addition to the phasing out PHP 8.0 we will begin offering PHP 8.3 on our servers. A look at the PHP lifetimes for current and recent PHP versions:

PHP 8.0 – End-of-Life, ended November 26, 2023
PHP 8.1 – ending December 31, 2025
PHP 8.2 – ending December 31, 2026
PHP 8.3 – ending December 31, 2027
PHP 8.4 – ending December 31, 2028

PHP 8.4 is not yet available on our server – it was just released a few days ago. Generally PHP versions go through several minor revisions after being released before they are deemed to be production ready.

Why is this important?
A lot of web hosting service providers will continue to allow end-of-life versions of PHP to be used on their servers. We tend to believe that security is important to our web hosting clients. The issue with using end-of-life versions of PHP is not the PHP version itself, per se. The issue is the scripts that rely on those end-of-life versions of PHP, what we refer to as the low hanging fruit of security and vulnerabilities in the web hosting environment.

A script (or plugin, theme, extension, component, addon, etc) may have been written back in 2021 – during PHP 8.0’s prime. If that script was released in 2021 and then never, ever touched again by its developer – then that script is abandoned. A reputable script is going to be maintained by its developer to keep it efficient and to address any known security holes. A script that is abandoned has no such assurances of being efficient or safe and secure of any known security holes.

By rotating out end-of-life versions of PHP this brings these abandoned scripts to the forefront. By now, any reputable script developer would have updated their code to work with current in-life versions of PHP, since PHP 8.0 went end-of-life on November 26, 2023. If a script has problems handling the update from PHP 8.0 to PHP 8.1 or PHP 8.2, then you either do not have the latest version of that script installed or the script has been abandoned by its developers. This is why rotating out end-of-life versions of PHP is important.

Having said all of that, we are not yet fully removing PHP 8.0 from our servers. If you have issues with your website handling the switch to a current in-life version of PHP, we can still temporarily downgrade your account to PHP 8.0. However, you need to be aware that this is only temporary. You need to use this time to resolve the issues with the scripts on your website to bring them up to date.

On January 1, 2025 we will again switch any account that has been downgraded to PHP 8.0 back to a current in-life version of PHP. If the issues with your website’s script still haven’t been resolved then you will need to consider upgrading your web hosting plan to have the account migrated to a server with extended PHP support. Extended PHP support will allow you to run your website on PHP 8.0 while you continue to make efforts to resolve the issues with your website and current in-life versions of PHP.

The purpose of all of this is to continue to provide you safe and secure web hosting environment. If you have any questions, please contact us.

We’re seeing a larger and larger problem with users setting up forms on their websites that have their contents emailed to someone being abused more and more.

The abuse is PROBABLY from bots – or computer systems that just hunt for these forms and submits them. Bots are not human beings sitting at a computer screen filling out these forms. Most of these bots are sending spam, they’re just completing the form and submitting the form. They don’t really care where the message goes. Some forms are more abusable than others in that they may allow the submitter to specify an email address to send the submission to.

All of this adds up to a ton of spam being sent out from our server from these bots or malicious users. When this happens, our servers get blacklisted and then nobody can send out mail from the server.

We’re reaching a point to where we are going to have to do something to curtail this.

What can you do to help?

Insure that you’re forms that are emailing data have some type of anti-bot or anti-spam measures. Captcha is a common anti-bot measure – that’s those squiggly letters and numbers that you must type into a box or clicking on all of the pictures that contain a bus or some item. The understanding here is that a bot won’t be able to make that determination, but a real human being will.

How to deploy captcha on your forms depends on your infrastructure. If you are using WordPress there are various WordPress plugins that can help in adding Captcha or other anti-bot measures into your forms.

Make sure your forms are submitting to a local email address. A local email address would be something like anything@yourdomain.com – where anything@yourdomain.com is setup as an email account in your web hosting control panel. The opposite of a local email address would be a remote or external email address, i.e. an @gmail.com, @yahoo.com, @comcast.net, etc email address. Remote email addresses are not delivered to our server. When you have your form configured to send it’s contents to a remote email address, then when a bot, spammer, or malicious user submits your form with a spam message, then our server sends that message to that remote server. That remote server is eventually going to get tired of receiving spam from our server and will start blocking our server.

Using a local email address on your form won’t alone prevent spamming of the form. But it will prevent that spam from being sent out from our server leading to server blacklistings.

We will eventually have to put measures in place to prevent forms from sending to remote/external email addresses. The level of spamming being done on these forms is just becoming too great and we’re going to have to deploy measures to prevent this.

A security vulnerability has been disclosed for the Horde Webmail application. A fix for the issue is being worked on by the developers of the Horde application, but since the Horde Webmail application in use on our cPanel servers is managed by cPanel getting that fix filtered down may take some additional time.

Through an abundance of caution we have temporarily disabled the Horde Webmail application on our server. This has been the recommended security step regarding this vulnerability.

Roundcube webmail is still available to all webmail users.

We apologize for the inconvenience this will cause, but we have to weigh the importance of security on our servers versus usability. We do anticipate the issue to be resolved, we just don’t have a timetable for it.

Previously we discussed changing the default version of PHP on our servers from PHP 7.3 to PHP 8.0. This got stalled out a bit due to unrelated issues garnering much of our attention.

We have slowly been pushing this out to all of our servers as a type of “beta” testing the change. We are still doing this beta test. But from all accounts, the transition appears to be going smoothly.

So we are announcing that beginning Monday April 4, 2022, we will start changing all accounts and default PHP settings to PHP 8.0 en masse across all of our servers.

The biggest issue we have seen in regards to this upgrade is with outdated scripts, themes, plugins, extensions, and components. It’s always important to keep your scripts and script addons up to date. When a security hole is discovered in a script or script addon, a developer that cares about their product, will update the code to fix the security hole and release an update. However that update does you no good if you never apply the update. This also speaks to scripts and script addons that have been abandoned when their developers no longer care about the product.

A lot of our users use WordPress for their website – the best advice we have for you is to insure that your WordPress is up to date and that you are using up-to-date and in-life-supported plugins and themes. If your WordPress, WordPress theme, WordPress plugins are out of date or have been abandoned by their developers (as in, they haven’t released an update in some time) then you are more likely to see issues with the PHP 8.0 upgrade.

If you are using an outdated or abandoned WordPress, WordPress theme, or WordPress plugin then you need update it or stop using it and find an alternative in-life-supported plugin/theme. If something is outdated or abandoned then there’s no way to know what security holes you are exposing your website to.

PHP 7.3 and PHP 7.4 will still be available and we can change your account to one of these PHP versions if need be. However, please understand that PHP 7.3 is end-of-life, which means it really does not need to be used. If you are switched back to PHP 7.3 you will be encouraged to update the coding and scripts on your website to be compliant with an in-life version of PHP.

PHP 8.1 is gaining maturity. At this time, we would prefer to wait in offering support for PHP 8.1 until the base gets a bit more secure. The sooner we can fully remove PHP 7.3 support the sooner we can add PHP 8.1 support to our servers.

As a reminder the outlook for PHP support is:

PHP 7.3 – Supported until December 2021 – END OF LIFE
PHP 7.4 – Supported until December 2022
PHP 8.0 – Supported until December 2023
PHP 8.1 – Supported until December 2024

Over the past month or so, we’ve noticed a considerable uptick in issues sending mail to Gmail or other Google handled email addresses. Messages that had been going out to Google’s mail servers were now starting to fail. This is a perfect example of how systems on the Internet are always evolving. We receive a lot of statements from users saying “Well, these messages used to work, I haven’t changed anything.” This may very well be true – but you have to understand that all of the framework and systems that control the Internet are always changing. Just because something used to work on the Internet, doesn’t mean it will always work.

From what we have been able to ascertain about the changes Google has made, they have increased their grading on SPF records. SPF is a special DNS TXT record that a domain owner uses to identify what IP addresses should be sending out mail from that domain. It’s an email authenticity check so that receiving mail servers (i.e. Google’s mail servers) can determine if mails from the domain and from that sending server IP address are legitimate.

If you have not already managed an SPF record for your domain name, you can access this in your cPanel by clicking the Email Deliverability link and then clicking the Manage button next to the respective domain name.

If you do not see the Email Deliverability link or if you need help with this, submit a support ticket and our support team will be glad to help you with this.

Email Forwarders

The other issue that this Google deliverability and SPF requirement involves concerns the use of Email Forwarders.

We have for a long, long time strongly discouraged users from setting up email forwarders that forward mail to an external mail server (i.e. Google’s mail servers). If you log into your cPanel and click the Forwarders link, you will see a notice that states that off-site email forwarders are discouraged.

Unfortunately we can’t stop users from setting up these forwarders, but you should understand that if you set up such a forwarder you may encounter issues with email deliverability. Additionally this email deliverability issue can lead to affecting other users on the server.

Email forwarders to an off-site or third-party mail server are just a bad, bad idea. Remember, the systems that control the Internet’s infrastructure is always changing. When SPF first became a thing with identifying email legitimacy, concerns with external mail forwarders was a noted issue. But the developers of SPF had to weigh the usefulness of SPF in identifying email authenticity (which was becoming more and more of an issue) against the use of email forwarders (which was largely in decline, due to smartphones and largely an always connected world).

You should understand that because of the way SPF and forwarding works – if you have any email addresses that forward off of the server, then all mail sent to that address and forwarded on to it’s destination is ALWAYS going to fail SPF.

With Google taking such a hard-nosed stance in regards to SPF authenticity, that means email addresses on our servers that are forwarding to Google mail servers, are always failing SPF. As these failures build and build, Google starts to identify our servers as a possible spam source. This is why forwarding mail off of the server is such a bad idea, and it’s why we have been discouraging it for several years now.

If you have any email addresses that forward off of the server – and I should mention that this includes any off-site server, Hotmail/Outlook/Microsoft, Yahoo, Google, AOL, etc, not just Google – we would really, really encourage you to remove the forwarder and set the email address up as a real email account on the server and check it directly. This is going to benefit you in terms of receiving all of the mail sent to the email address and it’s going to benefit us by lessening the SPF failures sent by our servers that hurts our server’s email deliverability reputation.

You can setup a real email account for the email address by using the Email Accounts link in your cPanel.