Over the past month or so, we’ve had a few users on a few different servers. Our attempts to resolve these issues with AT&T have fallen on deaf ears and we unfortunately appear to have reached an impasse.

What is happening?
AT&T’s mail server are blocking messages from a couple of our servers. In that block message we are advised to write to them at abuse_rbl@abuse-att.net but the issue is – nobody is responding to messages sent to abuse_rbl@abuse-att.net – which means there’s no resolution happening.

We have attempted to contact AT&T through other means and they all direct us back to abuse_rbl@abuse-att.net for resolution on this. Which again, just kind of puts us going through a circle.

One contact we had with AT&T said that the IP addresses were not blocked by AT&T. When we showed the evidence to the contrary, again they directed us to abuse_rbl@abuse-att.net.

Why is AT&T not responding?
This is really a question that you’d have to ask AT&T. The general idea is that AT&T is such a large company that they believe they do not have to adhere to all of the governance that controls the Internet. They believe that they don’t have to have a reason to block an IP address. They believe that they don’t have to respond to every request for delisting. They assume that they are large enough that there’s really nothing we or other small business hosting companies can do to make them comply.

To be fair to AT&T one of the issues probably has to do with just how large the AT&T company is. Having never worked at AT&T I really can’t speak for how they do things internally, but I would suspect that they have a list of IPs that are suppose to be blocked and they hand that list out to their techs. But the issue is that the list of IPs that their mail server is actually blocking and the IPs on the list that is being distributed out to their techs are two different things. Something has gotten out of synch with their system. The techs that are doing the talking and communicating don’t actually have access to see what the mail server is blocking, they can only go with the information they have in their list. The frustrating part, however, is that its seemingly impossible to open a dialog with someone at AT&T that can actually review the list that the actual mail servers are blocking.

Is the AMS server sending spam?
Again, this would ultimately require information from AT&T to prove that the server is sending out spam. But you should know that we have several measures in place to monitor all of our servers for spam activities. In the particular cases of IP being blocked by AT&T, these same IPs are not listed on any public facing realtime blacklist. If a server is sending out rampant spam, in all of my time of doing this, then those IPs wind up on public facing realtime spam blacklists. That does not appear to be the case here.

What can I do if I’m affected by this?
The best thing you can do is have your friends or contacts that use AT&T for email contact AT&T themselves and ask about this. Have them ask why nobody is responding to messages sent to abuse_rbl@abuse-att.net. Have them ask AT&T for another email address we can use to contact AT&T regarding this issue. We’ll gladly work with AT&T to get this issue resolved, but we’re going to need an email address with someone at AT&T that will be willing to look into this issue.

We are sorry for the inconvenience this may cause. But we really do not believe we have done anything wrong. We don’t believe the IPs are sending out spam and when AT&T is unwilling to communicate with us regarding these issues, that essentially ties our hands.

If you know of users that use AT&T for their own email, I would probably encourage those individuals to consider using a different email service provider for their email service. Right now it just does not appear that AT&T holds their email users in a high regard.

As we alluded to back in September, changes are coming to the PHP system on our servers.

A few weeks ago we switched our default version of PHP for new accounts to PHP 7.3. This only affected new accounts. Accounts that already existed on the server continued to run their defined version of PHP – which for nearly all accounts is PHP 7.1.

PHP 7.1 is going end-of-life on December 1, 2019 – which is in just a few days.

Beginning next week – the week of December 1, 2019 – we will be shifting existing accounts from PHP 7.1 to PHP 7.3. PHP 7.1 will continue to be available for a while and we can switch you back to PHP 7.1 if you need it. But if the code running on your website is not PHP 7.3 compatible then you really need to make an effort to upgrade the scripts and code to become PHP 7.3 compatible. That is more or less the point of this switching to PHP 7.3. If your code is not compatible with PHP 7.3 then you need to be made aware of this and you need to be taking action to get it up to par.

Today (September 26, 2019) PHP released PHP 7.3.10. This is significant because it represents the 10th release of PHP 7.3. We now consider this PHP version to be stable and mature. As a result of this, we will be making some changes to our PHP infrastructure within the next coming weeks.

Technically we are still waiting for cPanel to release PHP 7.3.10 on their end – so this version technically isn’t available to us right now. But it should be soon.

An exact timeline of the events is still undetermined as of now and it may be impossible to give an exact timeline, but this is our current line of thinking:

1st or 2nd week of October – We will switch to assigning PHP 7.3 on all new accounts. That means any new web hosting account that is created after this date will use PHP 7.3 by default.

Around the middle of November (possibly spilling over through the first week of December) – We will be switching all existing accounts over to PHP 7.3. This means all current accounts will be switched to PHP 7.3 at this time. This is fluid because it depends on how the switch to PHP 7.3 to new accounts take hold.

We are not removing PHP 7.1 as options. At least not yet.

Around the end of Q1 2020 or the start of Q2 2020 (March/April/May 2020) – We will start removing PHP 7.1 as options. This is a fluid deadline – meaning it’s open to change. A lot of this will depend on how the uptake of PHP 7.3 holds.

Keep in mind, PHP 7.1 support officially ends on December 1, 2019 that is why this change is being made:

https://www.php.net/supported-versions.php

As long as you are using an up-to-date and reputable script – such as WordPress, Joomla!, Drupal, etc. – these script began support PHP 7.3 a long time ago and their developers are well aware of PHP 7.1’s upcoming end-of-life. You are more likely to run into issues with plugins/themes/components/extensions that you may be using but have been abandoned by their individual developers. If any plugin/theme/component/extension you are using hasn’t been updated in years, now might be a good time to inquire on their development status with their individual developers. If you get no response, then it stands as good reason that the plugin/theme/component/extension has been abandoned.

What if my script breaks after the upgrade to PHP 7.3?
No worries. We can switch you back to PHP 7.1 – which is what all of the accounts on our servers are running now. But if you’re script breaks after switching to PHP 7.3 then this would really signal that you need to figure out what is wrong with your script and why it doesn’t support the latest version of PHP. You will need to resolve these issues because we won’t be able to offer PHP 7.1 forever.

What about PHP 7.2?
PHP 7.2 is also an option if your script doesn’t work with PHP 7.3. However, the lifetime of PHP 7.2 isn’t that much longer (support ends in December 2020). And really if a script works in PHP 7.1 but doesn’t work in PHP 7.3 but does work with PHP 7.2, then this is just kicking the can further down the road. Still… this is technically a viable option… just not a very good one in our opinion.

It looks like a recent Joomla! update has enhanced the attention of the version of PHP that you are running the Joomla! script on.

It would appear that Joomla! is using a bit of a scare-tactic to try and scare people into believing their PHP version is out of date.

Joomla! will flag PHP 7.1 as out-of-date. This is not the case. As you can see in the link:

https://www.php.net/supported-versions.php

PHP 7.1 is still in-life and is still technically good until November 30, 2019. While it is true that PHP 7.1 is approaching end-of-life… approaching and being are two different things. I’m not sure if the Joomla! developers are aware of the differences between these two words.

We do have plans to update all accounts to PHP 7.3 before the end of November. And we can switch your account to PHP 7.3 now if you would prefer that. But just because Joomla! is telling you that PHP 7.1 is out of date – that is not correct.

Depending on what plugins and components you are using, you may run into compatibility issues with those plugins/components if you update to PHP 7.3. If those plugins/components have not been vetted against PHP 7.3 then they may not work properly. Again PHP 7.1 is approaching end-of-life, so the developers of those plugins and components really need to be working on making their plugins/components compatible with PHP 7.3 – technically right now they are fine if they only operate on PHP 7.1 (after November 30th, 2019 this will no longer be fine).

If you want your account switched to PHP 7.3 now, simply open a support ticket – http://www.amshelp.com/support – and we will be happy to switch your account to PHP 7.3.

We now have PHP 7.2 and PHP 7.3 available on our servers. If you wish to switch to one of these versions on your account, simply open a support ticket – http://www.amshelp.com/support and we will update your account to the desired PHP version.

Please note, there were a lot of changes made in these updates from PHP 7.1. So before updating your account to one of these version, make sure the script you are using is compatible with the desired PHP version.

There is currently (as of April 17, 2019) no need to update your account to one of these PHP versions. These versions are simple being made available for our users that wish to update, for whatever reason. If you have no reason to update to PHP 7.2 or PHP 7.3, then I would not recommend doing so at this time.

The current end-of-life schedule for PHP shows PHP 7.1 (all of our accounts are currently using PHP 7.1) going end of life just before the end of this year – December 1, 2019 (source – https://www.php.net/supported-versions.php)

Right now we don’t have a schedule really set in stone regarding our full deployment of these updated PHP versions and the removal of PHP 7.1. We’re probably looking at a schedule that will see us push out PHP 7.3 as the default PHP version on all accounts around late 3Q or early 4Q 2019 (September/October 2019) and then with the removal of PHP 7.1 sometime in December 2019 or early 2020. But that schedule is very fluid right now. Adoption rates of PHP 7.3 are very small right now. That will need to increase before we can feel comfortable pushing PHP 7.3 out. Right now that would be our preference, to skip PHP 7.2 as a default version and go straight to PHP 7.3 – but again the situation is fluid and we are still several months away from having to make any decisions on this.