cPanel email hosted by GoDaddy is no longer working after upgrading to the latest eM Client version

Mail
1

I can receive my mail messages, but can no longer send mail after upgrading eM Client a few days ago. ( I am now on v.9.2.1841) My last upgrade was around October of 2022, and I am not sure what my previously installed version was.

I see no reasonable explanation for this since my SMTP configuration hasn’t changed. The other thing is, that eM Client has verified my incoming and outgoing email account settings are “Ok”. I even receive the confirmation email to my inbox via eM Client Diagnostics from the very account that I cannot otherwise send mail from.

GoDaddy Pro Support, that I have paid for, has looked at the problem and claim my mail server is running fine with no errors. They have also looked at my eM Client configuration and see no problems with the set-up. Furthermore, I have been able to configure 2 other email clients to use the same configuration and can successfully send email from both of those clients without any trouble. (i.e. it is only with eM Client that I have the problem)

Since I use the account in question for my business, I have real problem with not being able to send email. This makes eM Client useless for me when sending cPanel email hosted by GoDaddy.

Even more interesting is that I am able to receive and send email messages with no problems from other cPanel email accounts that are not hosted by GoDaddy. So it seems, either GoDaddy or eM Client is at fault. Since the problem manifested just after upgrading eM Client, I conclude that my desktop mail client and not the mail server, is the culprit.

There are several other nearly identical issues that can be found in this support forum that do not appear to have a resolution. Though, only one of those issues appears to involve GoDaddy and the mail hosting client is different.

My question then is, “What changed in the SMTP functionality since October, when I previously upgraded my eM Client?” Certainly something seems to be different. If eM Client can answer this question, then I should have a reasonable chance to debug the problem.

2

The latest MacOS version is “9.2.2041.0”. You might want to go to this website “Release History | eM Client” and click the latest version number to download and install and see if it fixes your issue.

If it doesn’t, then look at the operations window log tab for the exact error occurring when you run into the issue.

3

Thanks. Interesting that there are newer versions that eM Client doesn’t detect when it checks for an update.

Updated to most recent release. But, unfortunately, this did not fix my problem.

4

Checked the operations log and saw this error:
Sending messages failed due to the following reason:
“net_io_readfailure, Operation timed out”

Is there any way to cure that with application preferences that extend the read time interval?
Other email clients I have been testing with don’t have the timeout issue.

5

net_io_readfailure, Operation timed out

That error can sometimes be related to security software like optionally installed Firewall / security programs, optional Antivirus programs or VPNs slowing the connection and timing out. So if you have any of those installed, try completely disabling those to test.

Also try powering off and on your modem / router and any switches / hubs if you have those as well, incase your physical connection is getting some delay causing the time outs.

6

I tried disabling security software and cold restarting my access point with no perceivable impact. So, no luck in determining the cause if the time lag.

My feeling is that any latency concern is most likely created on the GoDaddy mail server side, because they are currently undergoing some infrastructure consolidation. However, it still seems strange that my other email clients don’t have issues with outgoing mail on the same accounts. (i.e. other email clients on the same computer are impervious to any lag and function as expected when sending email, despite the time-delay that derails my outgoing mail in eM Client). It is also strange that eM Client Account Diagnostics can send a mail message over an account when I am not able to do so on the same account through the normal sending process.

7

tried disabling security software and cold restarting my access point with no perceivable impact. So, no luck in determining the cause if the time lag

I would next then eg: ping the GoDaddy SMTP server and see what ms round trip on average you get. See if you are getting alot of lag there.

9

The Godaddy server is terribly slow. They are loading up a shared server with too many accounts as they begin to phase out cPanel hosting. They have also added layers of email security that further slow the exchange of data. I am working with them to see if they can move my account to a different server and will likely abandon GoDaddy in the near future. But, I hate to do that at this time since I am paid up through next February and all of my mail filters are in place.

My only question is, why do I not have the issue with other email clients? Only eM Client keeps my mail from sending.

10

I am also just seeing another SMTP error message in the operations log:
Connection failed due to the following reason:
“net_frame_read_size”

11

Connection failed due to the following reason:
“net_frame_read_size”

Apart from any GoDaddy SMTP mail server issues, that error might be pointing to a eg: OS framework installation problem or outdated or older framework. Check you have done all your framework updates. Also TLS1.3 has been known to cause issues if you have installed that.

Also might be something to do with your “Security Policy” SSL / TLS setting in your email account config in eM Client.

What’s your Port and Security Policy in eM Client accounts for the account which fails to send ?

12

Same settings I use on other non-GoDaddy accounts that all work fine.
Port:465
Security Policy: Use SSL/TLS on special port (legacy)

Also, I checked these settings with GoDaddy support, sent screen shots, etc. and they believe SMTP settings in eM Client are correct. Plus, I never changed them from last week when all SMTP email was sending perfectly.

Another quirk. I am able to send email from the account, but only occasionally. In the last 24hrs my pending outgoing mail, from the account in question, was successfully sent at 1am, 7am, 4:40pm and 8:35pm. The respective mail messages were sitting in my outbox for many hours while sending was being continuously retried until it was finally executed.

This behavior seems to point toward congestion on the server side where SMTP mail goes through only when the delay becomes lower.

Though, I am still not sure why this is only a problem with eM Client. GoDaddy’s solution is to simply stop using eM Client and switch to another product that performs better.

13

@Striker

Same settings I use on other non-GoDaddy accounts that all work fine.
Port:465
Security Policy: Use SSL/TLS on special port (legacy)

Also, I checked these settings with GoDaddy support, sent screen shots, etc. and they believe SMTP settings in eM Client are correct. Plus, I never changed them from last week when all SMTP email was sending perfectly.

This behavior seems to point toward congestion on the server side where SMTP mail goes through only when the delay becomes lower.

Ok your SMTP settings look fine.

I would agree that then does sound like a GoDaddy mail server related congestion sending issue with that specific email account.

Also agree it sounds like they need to move this specific mail account to one of their other mail servers or mirrors. It might be currently on a eg: slow shared server with limited bandwidth.

14

After spending many hours with GoDaddy technical support and escalating of the issue, they have concluded that the problem is eM Client and not their server. They are seeing no excessive processing delay of SMTP mail and are urging me to abandon eM Client, since that seems to be the only application that can’t send mail from my GoDaddy server. This is of course not the result I am looking for.

I can measure the SMTP processing delay to be in excess of 30 seconds consistently. This is true no matter what network or ISP I am using and regardless of the physical location of my computer (i.e. from my office or from my home), or which computer I am using. I can even see the delay from a web based email client. However, though I can see the delay in excess of 30 seconds only eM Client times out. Plus, when it times out it leaves junk in my outbox.

Is there any way to extend the timeout interval in eM Client to at least 40 seconds? This should solve the problem for me until I find another hosting solution and migrate my server from GoDaddy.

15

Then that is definitely not an email application issue, but a server problem.

16

I have the same problem as of yesterday. I tried all of the same solutions you did and nothing worked.
My IPHONE can send emails through my godaddy cpanel, so the emclient is the problem

17

Well, @Striker says he gets the same issue in his web browser, so that really doesn’t have anything to do with eM Client.

But what solutions did you try? Did you completely disable any anti-virus, firewall, proxy or VPN, then try send again? Did you restart your router?

What SMTP settings are you using?

What version of Windows are you using?

What is the timeout error you are getting?

What version of eM Client are you using?

18

The problem with eMclient is that there is no way to extend the SMTP timeout period.

Every other email client I have used (I have tried many, on different platforms, including web clients) worked fine. However, I was able to see a latency of roughly 30 seconds on the GoDaddy side that wasn’t there in the past.

So, you might blame GoDaddy or you might blame eMclient. Each have their own drawbacks.

I had no problems on any of my other email accounts in eMclient, just the one hosted at GoDaddy.

I had put considerable effort working with GoDaddy to prove to them that the delay is unreasonable. The problem is that they did not experience the same latency issues I had been seeing. They were seeing at worst a second of SMTP processing delay. When I asked them to look at the same email server from outside of GoDaddy’s firewall they seem to see what I was seeing. THEN SUDDENLY, the SMTP delay issues went away and eMclient began to work just fine with that same account (no changes made to the SMTP settings in eMclient).

Though all ended well, it still would have been nice if eMclient could have allowed a setting to extend the latency timeout period and perform as well as the other 7 clients I had tested. Then I wouldn’t have had to spend 10’s of hours dealing with the issue (on very tedious and long support calls, including with 3rd parties, and conducting may hours of testing, screen recordings etc., to prove I wasn’t crazy, including evaluating a replacement client for eM Client.

19

The problem with eMclient is that there is no way to extend the SMTP timeout period

Though all ended well, it still would have been nice if eMclient could have allowed a setting to extend the latency timeout period and perform as well as the other 7 clients I had tested.

In all the years I’ve done lvl 3 Internet tech support for many different major isps using pretty much every mail Client on the planet, I’ve never needed to adjust smtp timeout settings even when using basic adsl 1 or basic satellite with eg: 5 mbps constant u/l speed.

If you are getting massive smtp latency whether that be using a mail Client or web mail, putting in SMTP latency settings (even if eM Client added that) would not always 100% guarantee to fix that issue in my professional opinion. That a bandaid solution to the real problem.

1 Like
20

In the 25+ years I’ve managed tech support for many different clients around the world, using pretty much every Email Client on the planet, I’ve never observed the need to adjust SMTP timeout settings either. That is because SMTP is an old and very well established protocol and generally just works, After all, the “S” stands for “simple”, which is why I use it.

The downside for me is that I had to use another email application just to check the one account hosted by Go Daddy, so I could continue to run my business. It was literally a show stopper for me, because my timely communication to key customers with time sensitive problems did not go out. Perhaps not the fault of eM Client, but certainly a big problem that was challenging to solve. The technical experts at at my email hosting service couldn’t see the performance bottleneck on their side. I had escalated the problem up to the most seasoned support personnel and they only accommodated me because of who I am and how well I made my case. All the while, of course they were pleading with me to drop eM Client, sparing no opportunities to poke holes in my application preferences.

While I agree with you that adjusting the timeout interval is a bandaid, it might be part of the new reality in supporting the next generation of mail hosting services. As the industry evolves lately we are seeing more aging infrastructure, hybrid networks, new interoperability challenges, software defined networks with many unproven 3rd party components, higher staffing turnover, reduced average years of experience among the technical staff, outsourcing to the lowest bidder, backward incentive plans, untested remote management paradigms, cyber security threats, financial and non-tech executive driven technology decisions, the rapid growth of automation, heavily optimized workloads, high infrastructure utilization, lack of IT revenue growth, cloud computing proliferation, etc… (i.e. more loading on the networks, financial pressure on businesses, and new 3rd party points of failure)

An adjustable timeout feature is certainly unnecessary for most, but that can be said about a plethora of features. They are only 100% useful when you actually need it and if you don’t need it they are not very useful at all.

Had I anticipated the amount of effort involved in dealing with the issue I would have never started. But, then again, when I started to debug the problem no one knew the answer and every solution provider pointed me to another party, which wasn’t helpful.

No matter what you say and what your experience tells you, only eM Client failed to work for me. That is my benchmark for suggesting the feature. I would have liked that capability, even if it was only a bandaid, until a more suitable solution could have been identified and implemented. If the same problem appears again, I will just use another email client for that specific domain and move it to a more reliable hosting service as fast as I can.

21

While I agree with you that adjusting the timeout interval is a bandaid, it might be part of the new reality in supporting the next generation of mail hosting services

No matter what you say and what your experience tells you, only eM Client failed to work for me. That is my benchmark for suggesting the feature.

Ok. Well then If there is “enough other forum peeps who also want or need that SMTP timeout adjustment option added”, then who knows eM Client might add that option / feature in the future. Time will tell.