Edit – November 28, 2021 – there is updated information about this in our new post.

Some of you may be seeing warning or notices in your web scripts or applications about the upcoming end of life for PHP 7.3. These concerns are true and valid. Official support for PHP 7.3 will end on December 6, 2021. This does not mean that PHP 7.3 will stop working on December 6, 2021 – it simply means that the PHP developers will no longer release any security fixes for the 7.3 branch of PHP.

All accounts on our servers are using PHP 7.3 by default. The term “by default” means that unless you have made arrangements with us to change the PHP version – then your account is using PHP 7.3.

We prefer to hold true to these development environments as much as possible. That means we would prefer to move off of PHP 7.3 by default before the December 6, 2021 cutoff. But we haven’t yet done that. Why?

The majority of the reason revolves around Ioncube. Ioncube is a very popular PHP encoding system – think of it as a way to distribute code without exposing the exact source code for that project. As of now, Ioncube still hasn’t released updated encoders and loaders for PHP 8.0. Why? We have no idea. Ioncube is severely dragging their feet in resolving this. As a leading encoder for PHP, Ioncube should have been working on a PHP 8.0 encoder/loader well before PHP 8 was release to the general public. The first alpha of PHP 8 was released on June 25, 2020. And Ioncube still has no answer for PHP 8.

Ideally we expected Ioncube to release an encoder/loader in late Summer 2021 at the latest. We had plans to begin shifting PHP by default to PHP 8.0 around the first of October 2021. But Ioncube never released an encoder/loader and now we’re knocking on the door to December and the December 6, 2021 deadline for PHP 7.3.

What about PHP 7.4?

PHP 7.4 is also out there and in life (until November 28, 2022 – so about a year from now) and an Ioncube encoder/loader is available for PHP 7.4. Typically we like to skip versions when setting a default PHP version, otherwise we’re changing default PHP versions once a year or less. We did this with the PHP 7.1 to PHP 7.3 release cycle, we skipped over PHP 7.2 as a default version. This was our intended target for PHP 8.0 – go from PHP 7.3 to PHP 8.0, skipping PHP 7.4.

Believe me when I say that Ioncube dragging their feet on this has been a huge obstacle for us, because we really did not plan for Ioncube to take this long to release an encoder/loader for PHP 8.0.

What are we going to do now?

We don’t really know. We’re playing this by ear now. From the looks of things, unless something unexpected happens with Ioncube and PHP 8.0 within the next couple of weeks, we’ll probably continue with PHP 7.3 by default after the December 6, 2021 end-of-life and re-evaluate all of this about a month later at the first of January 2022. At that time we’ll probably switch to either a PHP 7.4 with Ioncube by default or a PHP 8.0 without Ioncube by default.

Continuing to use PHP 7.3 after it’s end-of-life isn’t the end of the world. The chances of a security concern to arise in PHP 7.3 soon after it’s end-of-life is very small. However it is not a good idea to continue using PHP 7.3 long term after it’s end-of-life. We’re aware of this. But we were just really hoping to have PHP 8.0 with Ioncube available by now.

How do I know if I am using Ioncube?

If you purchased any software to use on your website then it’s a good bet that your PHP scripts are encoded with some encoder. Ioncube is not the only PHP encoder, but it is the most popular one. Just how many of our clients are using Ioncube encoded software will factor into our decision to my to PHP 7.4 with Ioncube vs. PHP 8.0 without Ioncube as the default option.

If you are using a piece of software that is encoded with Ioncube I would strongly encourage you to discuss this with that software’s developer and ask them if it’s possible for them to move the encoding to a different encoder – one that supports PHP 8.0.

This is not the first time Ioncube has dragged their feet on this. When PHP 7.0 came out they were just as slow at releasing an encoder/loader for PHP 7.0 as they are now.

I understand that users may be disgruntled with this. Believe me, we are too. But I do not know of anyway to get Ioncube to speed up their development and release process.

Edit (Wednesday, September 8th, 2021) – to include WinSCP as the preferred SFTP client.

We are planning to disable FTP on all of our servers at some point in the future. But that doesn’t mean you won’t be able to use FTP to manage the files on your website.

Instead of FTP, we will be replacing the service with SFTP. SFTP functions practically identical to FTP, except it’s simpler and built from a secure foundation.

Most modern FTP clients will function as an SFTP client as well. Modern application developers have known about the shortcomings of FTP for years and have been preparing for its demise. Unfortunately there are just too many FTP client applications out there for us to provide a guide for each and everyone of them. The bottom line is, you need to check with your FTP application, probably in the Site Manager or Connection Manager of the FTP application, and check to see if it supports the SFTP protocol for your web hosting FTP connection. You simply need to change the protocol to use SFTP and specify an SFTP port – which for our servers is Port 9122.

We’ve taken to recommending WinSCP as the preferred SFTP client. You can download WinSCP free at:

https://winscp.net

Below we have some images from Winscp’s Site Manager to illustrate these changes.

The key takeaways here:

File Protocol: SFTP
Hostname: %your_domain_name%
Port: 9122
Username: %your_webhosting_account_username%
Password: %your_webhosting_account_password%

And that’s it. Now when you connect, you’ll be using SFTP and connecting securely.

Why are we making this change?
FTP by nature is not a secure protocol. That means everything you send along the connection is not encrypted and is viewable to anyone that might be listening on the connection. While the connection can be made secure, it’s just difficult to enforce this because FTP wasn’t written with security like this in mind.

FTP is also a bit more complex. It consists of a control channel and a data channel. This made more sense back when Internet connections were not as robust as they are today. It’s just a sign of times, older technologies always get pushed out and that’s whats happening with FTP. But again, SFTP is largely a drop in replacement that only requires a slight configuration change by the end-user.

Additionally cPanel is moving to dropping FTP on their platform, so a move to rid ourselves of a reliance on FTP is needed.

When will FTP be remove?
We don’t have an exact date. We’re waiting to see how well our users embrace SFTP and how quickly they can move off of FTP. We’re probably targeting late 2021, although this could also change if cPanel moves up it’s deprecation of FTP.

We will be sending out notices to users on our server that still use FTP and notifying them of this upcoming change. The hope is that all of those users will be able to seamlessly move to SFTP and this change can move forward fairly quickly. However, if users are relying on very old FTP applications that may make the shutdown more difficult. The concern with users that are using very old FTP applications that do not support SFTP is that they may be leaving themselves vulnerable to other security implications by relying on very old and antiquated software.

There’s been a sharp uptick in malware, keylogging, and ransomware attacks over the past several months. The move to disable FTP and replace it with SFTP is meant to better safeguard our services from these attacks. In security you’re only as secure as your least secure entry point and right now, FTP is one of, if not the, least secure entry points on our servers. So removing FTP is going to serve to better secure our servers and your account.

Let’s start out by addressing one fact – The Internet is ever evolving – is this a fact that we can all get behind?

To put in a different perspective, is the Internet you see, access, and interact with today the same Internet you saw, accessed, and interacted with back in 1995?

For me, the answer is a clear No. In 1995 we didn’t fiber Internet connections. We didn’t have dynamic and interactive websites. We didn’t have streaming TV platforms. We didn’t have Facebook and Twitter and other social media platforms. We didn’t have smartphones and Internet and communication in our pockets, always connected. The Internet has changed.

Despite all of this – Email has remained largely the same. It is still a very popular communication method, although instant messaging and text messaging have carved a niche in easy and simple communication purposes.

While the Email protocol hasn’t really changed – the abuse to email has. SPAM is rampant with email – I think we can all agree on this – and there’s no end in sight. As a result of this, a lot of the major email providers Microsoft, Google, Yahoo, Verizon, etc have really clamped down on their anti-spam and anti-malware methods. It’s becoming harder and harder to get legitimate mail through due to these measures.

This has a direct correlation to email forwarding. In the ’90s and early 2000s forwarding mail may have been common place. But as more and more SPAM reached these major email providers, the notion of forwarding mail off of the server became more and more problematic.

When you forward mail off of the server – when it reaches it’s final destination, that provider (typically Microsoft, Google, Yahoo, Verizon, etc) sees the message as being sent from our server. If it turns out that that message is a SPAM message guess what server gets deemed as the source of that SPAM? Our server. And when your server gets flagged as a SPAM source, nobody gets any messages from our server with these email service providers.

In this scenario our server becomes a “man-in-the-middle” Instead of the message going directly to the intended recipient it routes through our server first. This additional step also creates additional problem points. The simpliest path is usually the best path. Sending a message directly to the intended recipient is the best way to insure deliverability.

This is why forwarding mail off of the server is a very, very bad idea. In fact, that’s why we have an advisory posted in your control panel about such actions.

Over the past several months and years we have seen a huge increase in the amount of problems our users and servers have had in sending mail to a lot of these major email service providers. We do not believe these issues to be tied to direct SPAM or abuse on our servers (these issues usually show themselves with being tied to popular public blacklists and our servers remain clean on these). Instead we believe the issue is related directly to users forwarding mail off of the server to these various major email service providers. SPAM being sent to these forwarding email addresses is resulting our servers being blocked and blacklisted by these major email service providers.

What is the solution?

The best solution is to setup all of your @yourdomain.com email addresses as real email accounts and check them directly or via webmail. Alternatively, some major email providers provide an option to download messages via POP3 into their service. I know Gmail has such a feature – in your Gmail account go to Settings -> Accounts and Filters -> Check mail from other accounts. Other service providers may offer this, you would just have to check with them. If you’re only concerned with checking your Gmail or other major email service provider then this may be an option for you.

One of the common refrains regarding this is – “But, I’ve always forwarded mail like this and it’s worked” – but again, this goes back to what we first talked about at the opening of this post – The Internet is ever evolving and changing. Just because some activity used to work, doesn’t mean it will continue to work that way forever. A blocky, scrolling text marquee based website that was appealing in the 1990s isn’t going to be appealing to the generation visiting that website today.

The bottom line is – forwarding mail off of the server really needs to stop. It just doesn’t work in the Internet of the 2020s. You can apply different band-aids to try and get around it and temporarily fix it, but it still doesn’t change that it’s a horrible idea.

Lately, we’ve been having a lot of issues with WordPress comment spamming – and the emails it generates – resulting in a degrading of the email reputation of our servers.

It seems that a lot of users either don’t pay attention to the WordPress comments or moderation messages that come into their website, use an invalid, fake, or now non-existent email address as their WordPress admin email address.

Investigating this found that almost all affected WordPress sites – either were unaware that WordPress comments were enabled or did not need WordPress comments.

Because of all of this – we have decided to add functionality on the server level to disable WordPress comments completely. With this function, we can re-enable WordPress comments on your web hosting account if you absolutely need them.

However, if you need to use WordPress comments you will have to enable some level of anti-spam/anti-spambot measures – usually in the form of captcha (the prove you’re a human images). Google has a Re-captcha service that that is commonly used. Akismet is another service that is commonly reference. There are numerous WordPress plugins available that can help with this. If you must use WordPress comments on your website you will need to have an anti-spam/anti-spambot measure in place that is effective.

Additionally, if you need WordPress comments, then the email address that comment moderation messages are sent to will have to be valid. Ideally, this would be a local @yourdomain.com email address and not an off-server email address. Comment spam messages that are sent for moderation to an off-server email address have hindered our mail server’s reputation in the past.

If you have questions or any concerns about this – feel free to open a ticket with us.

We have seen a lot of reports of end-users having issues sending emails to their hotmail.com/outlook.com/live.com/msn.com email addresses.

This is the result of Microsoft (they own the hotmail.com/outlook.com/live.com/msn.com platform) deciding to take a much, much more stricter policy shift in their handling of outside mail. We have tried to communicate with Microsoft about these issues – but we are unable to reach anybody at Microsoft that have any sort of administrative privileges on their mail servers or are aware of their own mail acceptance policies. We are an impasse. The conclusion is that because the users of hotmail.com/outlook.com/live.com/msn.com are free and not paying Microsoft, then Microsoft has little reason to be invested in it’s operation.

Please note, we are not the only ones experiencing this problem. There are a slew of other users within Microsoft’s own Community Answers platform having the same issues and getting no response from Microsoft:

Results in Outlook.com – Microsoft Community

All of this amounts to this recommendation: If you are depending on hotmail.com/outlook.com/live.com/msn.com for your email needs, you should strongly consider moving to a different platform. While you can always use email addresses associated with your domain name you have hosted with us, other potential email platforms include Gmail, Yahoo, and Protonmail. Microsoft may be blocking or excluding mail from our servers, but what other mail servers are they also blocking? How do you know you’re not receiving the important emails you need to be receiving?

Alternatively, you can try posting complaints within the Microsoft Community Answers forum. But I am also not sure if Microsoft pays a lot of attention to the complaints there.

I understand that this is frustrating. Believe me, it is frustrating to us as well. We have multiple tickets opened with Microsoft about this. We have responded to those tickets daily asking for an update or escalation. The last response we got from them was on June 22nd and that response seem to indicate that they would not be responding to us any further. Eventually we reach the bottom of our toolkit and the only recommendation is to advise users to move on from the hotmail.com/outlook.com/live.com/msn.com platform.