An upcoming change to the SMTP/Outgoing mail server configuration may affect your ability to send out mail.  The upcoming change will require SSL/TLS connections on all outbound SMTP/outgoing mail server connections.  Up until now, our servers have required SMTP Authentication in order for you to relay out mail through our servers.  Using a secure and TLS encrypted connection was always encouraged, but was not required.  This upcoming change will make the TLS encryption a required setting.

(As a side note – TLS is the appropriate name for connecting to services securely on the Internet.  Originally this was referred to as SSL.  SSL was developed by Netscape back in the 1990s.  In 1999 the IETF organization took over the publishing of the secure standard and renamed it TLS to give it a more neutral name.  Having said all of that, you will still see applications referring to the setting as SSL, it's just a naming convention that is difficult for some companies to drop.  The last update to the actual SSL standard was nearly 20 years.  No modern application is going to be using that standard even if they still refer to it as SSL)

This is all part of a larger movement to insure that Internet connections are encrypted and secure.  This is especially true for any situation where you are passing a username and password or other sensitive information.

Most modern email clients are defaulting to secure TLS encrypted connections when you setup your email account in your email application.  I do not expect this change to affect a large percentage of our users, because chances are your email application is already using a secure TLS connection.

No other changes are required if you are affected by this.  There are no mail server hostname changes to be made or anything like that.  You simply need to instruct your email application to use a secure or TLS connection when connecting to our outgoing mail servers.

A quick look at the necessary settings to adjust if you are using Microsoft Mail as your email application is shown below:

Of course every email application is going to be a little different.  You would just need to identify and enable the necessary option in your email application.

We are working on compiling a list of affected email accounts – that we can see from the server side – that are still not using secure TLS encryption.  We will try to start sending out notices to those affected accounts next week.  Depending on just how many accounts are affected and what email applications are being used, we may create additional tutorial pages for how to update the appropriate settings for those email applications.

 

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