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.

Shortly after our previous post, Ioncube released version 11 of their encoder and loader. This is a major release from Ioncube. However, this major release does not include support for PHP 8.0. This speaks volumes to Ioncube’s commitment to staying current with PHP development. We no longer expect PHP 8 support in Ioncube to be any where near imminent.

After this announcement we decided to take a look and see just how many PHP scripts on our servers are using Ioncube encoded files. This is honestly something we should have done many months ago – but again we though PHP 8 support in Ioncube was forthcoming. The results of our findings was “not many” Ioncube encoded scripts exist on our servers.

Given all of this, we’re going to proceed forward with slowly switching accounts over to PHP 8 by default. Effectively, this means that if you’re account is using PHP 7.3 it will be switched to PHP 8.0. We want to introduce this slowly because we’re unsure of how this will affect real world application use. If we start to receive reports of issues, then we will tap the breaks on this.

How can you prepare yourself for this?

The best thing you can do is to make sure your scripts are being kept up to date and that any plugins, themes, components, or extensions are also being maintained by reputable developers and being kept up to date.

One of the more popular scripts/applications used on our servers is WordPress. We’re told that WordPress 5.6 and higher should be compatible with PHP 8.0. WordPress 5.8 is currently the latest branch to be developed and is more likely to be developed with PHP 8.0 in mind. If possible, we would encourage you to insure that your WordPress script is updated to WordPress 5.8.

WordPress has a very extensive plugin and theme system. Keeping these up to date and insuring that they are being maintained by reputable developers. However, it’s just impossible for us to know what plugins and themes are still being maintained and are compatible with PHP 8.0. The best advice here is to contact the developer of the plugin or theme in question. Any PHP developer that’s worth their weight will be aware of PHP 8.0 and PHP 7.3’s end-of-life. If they’re not – then that tells you the plugin or theme probably isn’t that reputable. If you contact them and don’t get a response then that would tell you that the project has been abandoned.

Other scripts and systems that aren’t associated with WordPress would also need to be properly updated and maintained.

If you do encounter an issue after being switched to PHP 8.0 – then that tells you that you have some issues that need to be addressed. Either the script, plugin, theme, component, extension, etc is not up to date or is not being properly maintained.

If you do encounter issues after being switched to PHP 8.0 – we can downgrade you back down. We’re not cutting PHP 7.3 from our systems entirely just yet. But we do want to raise awareness that if your script or application won’t function under PHP 8.0 then you’ve got some issues with that script or application that needs to be addressed.