I am using the trial version at the moment but I assume the issue would be the same regardless of the version.
So my IMAP works fine for this account, and when doing the diagnostics I get the test email sent correctly, however when I try and send a REAL email I get an error and here is whats spat out into the logs:
09:04:11.812|001| eM Client 9.2.2157+5b4954246f (Windows)
09:04:11.812|001| Account's UID is 6acfe812-1aeb-43b1-879b-909bf4dceb6a
09:04:11.812|001| AccountBase.ChangeOnlineState : State changed to ONLINE due User
09:04:11.916|023| SMTP S: 220-the-email-server ESMTP Exim 4.95 #2 Fri, 17 Nov 2023 02:04:12 -0700
09:04:11.916|023| SMTP S: 220-We do not authorize the use of this system to transport unsolicited,
09:04:11.917|023| SMTP S: 220 and/or bulk e-mail.
09:04:11.917|023| SMTP C: EHLO [192.168.1.133]
09:04:11.944|023| SMTP S: 250-the-email-server Hello [192.168.1.133] [the-ip-address]
09:04:11.944|023| SMTP S: 250-SIZE 52428800
09:04:11.944|023| SMTP S: 250-8BITMIME
09:04:11.944|023| SMTP S: 250-PIPELINING
09:04:11.944|023| SMTP S: 250-PIPE_CONNECT
09:04:11.944|023| SMTP S: 250-AUTH PLAIN LOGIN
09:04:11.944|023| SMTP S: 250 HELP
09:04:11.945|023| SMTP C: AUTH PLAIN <Parameter removed for privacy reasons.>
09:04:11.975|023| SMTP S: 235 Authentication succeeded
09:04:11.975|023| SMTP C: MAIL FROM:<my-email> SIZE=93391
09:04:12.002|023| SMTP S: 250 OK
09:04:12.002|023| SMTP C: RCPT TO:<the-destinaiton-email>
09:04:12.076|023| SMTP S: 250 Accepted
09:04:12.077|023| SMTP C: DATA
09:04:12.104|023| SMTP S: 354 Enter message, ending with "." on a line by itself
09:04:12.160|023| SMTP C:
09:04:12.160|023| SMTP C: .
09:04:42.171|023| Exception: MailClient.Accounts.SocketException: Sending messages failed due to the following reason:
09:04:42.171|023| "Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.."
09:04:42.171|023| at MailClient.Protocols.Smtp.SmtpSendCommand.Execute(WorkerStatus status)
09:04:42.171|023| at MailClient.Commands.Command.Process(WorkerStatus status)
09:04:42.171|007| AccountBase.ChangeOnlineState : State changed to OFFLINE due BrokenConnection
I have seen other related topics that never seem to get resolved or do but no one posts back but I have tried:
Adding explicit incoming/outgoing firewall rules
Rebooting the router
I have been trying all kinds of mail apps recently and all of them have worked fine for sending, but its just emclient seems to fail here, which is a shame as everything else about the app is great, and given a competitor which I use is changing their licensing agreements for lifetime customers I was looking to move to this software.
As a test, can you completely disable any anti-virus, firewall, proxy or VPN, then try send again. Sometimes even restarting your router may resolve this.
09:58:54.639|05B| Exception: MailClient.Accounts.SocketException: Sending messages failed due to the following reason:
09:58:54.639|05B| "Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.."
09:58:54.639|05B| at MailClient.Protocols.Smtp.SmtpSendCommand.Execute(WorkerStatus status)
09:58:54.639|05B| at MailClient.Commands.Command.Process(WorkerStatus status)
09:58:54.639|056| AccountBase.ChangeOnlineState : State changed to OFFLINE due BrokenConnection
Just to confirm:
I have turned off windows firewall on domain, public, private
I do not have a VPN connection active
I am using Windows Defender and have deactivated Realtime Monitoring
To check the settings, go to Menu > Accounts and click on the SMTP tab for the account. The port and security policy are specific pairs, so should be one of the following:
Port 587 = Force usage of SSL/TLS
Port 465 = Use SSL/TLS on special port (legacy)
Port 25 = Use SSL/TLS if available
The test mail sends fine and diagnostics indicate it works, the only thing that is different really is the test email is tiny, the real email im trying to send is a forward chain which is listed as 91kb in size and has some images in there etc, so unsure if that complicates things in some way.
I have just tried sending while on a VPN connection to see if that does anything different but it gives same error, but I can see the local ip address its using for me is now the VPN ip address in the logs not my local one, so while it still doesnt solve the problem it at least is another scenario tested and not working.
The thing I find odd is that it can send the test messages, and its getting up to the same send point after the handshaking etc. I am wondering if maybe there is some cert issue or something but its not being bubbled up. Although if the test email works I imagine it cant be a cert issue.
If you can recommend any other things to try I am happy to give it a go, but I can send from this account using other email clients (not open when I try using em client), its just em client that seems to have problems, but if there is any other debug information output anywhere or if any of the testers/devs in the business want me to setup a temporary account for them to try and use to see if they get other errors im more than happy to set that up, as I would really like to buy a pro license for this, but if I cant send emails then there is no point.
I found this post which is the same issue I have with same provider I am using, I get that maybe their SMTP setup is rubbish, but it works with other clients so it seems like emClient should have some way to work around this, be it an explicit timeout override or something else.
You can see in the initial error logs, and pretty much anyone elses error logs that it waits 30 seconds from the send to timing out, and I imagine other email clients just wait longer. I guess regardless if emclient cant support slow email servers I cant use it as other clients work with it, and I don’t understand why an explicit override value could not be provided in the UI if someone wants to allow for longer timeout durations.
This is a grey area but I have looked through some of your source code and you do seem to have advancedParameters which allow you to override the ConnectionTimeout otherwise it defaults the server.SendTimeout to 30000 ms (30 seconds) and uses this value. This lower level logic can be found within the SmtpSendCommand class.
So is it just a case that this was never exposed in the UI? as people are complaining about this as far back as 2017 and it seems a simple enough change to propagate this value up to the UI in some way so baffled as to why its not been done.
I found this post which is the same issue I have with same provider I am using, I get that maybe their SMTP setup is rubbish, but it works with other clients so it seems like emClient should have some way to work around this, be it an explicit timeout override or something else.
If the SMTP provider server has constant or random timeout issues with mail clients (like Tsohost appears to have alot of the time), then it’s up to the host technical support to fix that. Or alternatively you have to use a different SMTP mail server if they carnt resolve the problem.
Putting in a SMTP timeout option within a mail client is no guarantee that would 100% fix that problem (even if it was implemented). It’s a band-aid solution. You could be constantly adjusting the timeout setting everyday depending on how bad the SMTP mail server was at any given time through the day. Needs a proper SMTP server fix
They wont though, and I understand the angle you are coming from, where really its the SMTP server not being fast enough at responding/accepting payloads BUT at the same time, what if we legitimately have a large file we want to send, even a fast server may take longer than 30 seconds to send causing it to timeout.
However you spin this, other email clients work around this issue differently, and some offer configurable values to allow you as the user to decide how long is too long, here we have no option to do so, and the smtp provider isnt going to change its infrastructure because I tell them emclient only gives them a 30 second window to process a send request.
I would LOVE to use this product as it does everything I want, but unfortunately right now its more faff to change my entire web/mail host provider than it is to move off emclient to another app, but its a shame as there is literally no technical reason why they could not expose this value and potentially have had new customers (even if its only a handful) and avoided a lot of these same sort of posts where peoples SMTP calls timeout, which also costs support time etc.
That is not what the timeout is about. It is not the time it takes to upload the message, but rather the time the server takes to respond when communicating with it. Normally the server should respond in a few milliseconds, so you can understand how extraordinarily long 30 seconds is to go without a response.
Ah right, either way I appreciate 30 seconds is a totally crazy length of time to take to respond, but unfortunately none of that matters if I cant use that server with this client and other clients work.
Either the app developers make the timeout configurable, or somehow tso host increase their timeout, I cant see either happening.
There is a 3rd option that there is something causing the timeout on the server side, which other apps don’t have, be it a cert resolution error or some DNS thing, who knows…
I send emails using that server from android, desktop etc and none of them have an issue and while I dont see debug logs etc they seem to send within a few seconds (I appreciate behind the scenes it may be taking much longer to actually send) but its only since using emclient that I have seen this issue.
In a last ditch attempt to try and solve this I have asked TSOHost (the mail provider) if they can check any logs their side to see if there is any reason why its timing out, and they couldnt see anything however they did notice there were some DNS records that were incorrect, so they have updated them and im waiting to see if that fixes it.
I am unconvinced as other clients worked fine before they changed DNS records, but will report back after ive given it a few hours to propagate.
Granted its not been the full 24-48 hours yet (its about 18 hours as of writing) but I had an urgent mail to send, tried again on this, wouldn’t send, went on a competitors email client (which I am trying to move away from), sent right away.
Im assuming whatever DNS changes they have made wont fix the issues im facing with emClient, can anyone confirm do the devs check this forum? as I would be more than willing to work with the devs to dig deeper into whats causing the issue and trying to solve/mitigate it, as im not the only one over the years whos suffering from it and am more than happy to pay for a pro license (still on my free trial) if it means a developer can treat it as an issue and work with me to resolve it.
I am intrigued with your issue as I see that you have given your Port addresses etc but you have grayed out your actual SMTP host address, it would be helpful to have this when attempting to resolve your issue. Also do you have your own Domain?
I just left my local IP address in the logs as its just a LAN IP so no one could do anything malicious with it. In terms of the SMTP host I wouldn’t want to put its host name or IP address on here but I am happy to pm you the details if you wish.
I do have my own domain name but like a lot of Web hosts these days the actual SMTP server address is a separate url which is a custom guid subdomain on their own domain i.e some-unique-id.secureserver.net.
These settings work fine on other email clients for send/receive, on here it receives fine but only does a diagnostic send, I tried sending a minimal email from this to another account via em client and even a message saying “hello” won’t send, so it makes me think the code behind the scenes somehow sends the test email a different way to how the real SMTP send is processed.
I don’t really know what you would be able to do to help diagnose with the SMTP host name other than potentially look at DNS records for that domain, I am more than happy to do DNS lookups and provide information back if thats what you would be wanting to see to help diagnose further.
If you purchase eM Client you can then login and lodge a support request via the Pro support page.. An engineer will then be assigned to you to troubleshoot this issue. You can then send in logs etc as they advise.
There is also a 30 day money back guarantee if for some reason this issue cannot be resolved.
We can only give limited user help on this free community forum.
So after speaking to support on both sides I am able to somewhat work around.
The host of the SMTP server tells me there is nothing erroneous in their logs or issues effecting my account/server and they have tested with various other email clients and have no such issues.
Support on EM Client have confirmed they also get the same issues as me, and after giving them a test account to diagnose further they indicate the SMTP host disconnects frequently and takes longer than 30 seconds to respond when it does work.
So while this isnt a solution and there is still a problem, there was one MAJOR breakthrough from the EM Client support which was how to extend the timeout for SMTP requests. To do this you can go to your account settings and then Advanced Options at the bottom of the page and in the Parameters field enter the following:
--smtp-timeout 3600 --smtp-initial-timeout 3600
I think 3600 here is the value in seconds, so we are saying wait 1 hour (60 seconds * 60), so you can set this to whatever interval you want, I have not done any in depth evaluation of the timeouts but I can see now that it is not erroring out as it did before, as the logs end with this now:
09:33:46.832|02E| SMTP S: 250 Accepted
09:33:46.832|02E| SMTP C: DATA
09:33:46.867|02E| SMTP S: 354 Enter message, ending with “.” on a line by itself
09:33:46.871|02E| SMTP C:
09:33:46.871|02E| SMTP C: .
09:34:16.945|02E| SMTP S: 250 OK id=1r665k-00GLOq-A1
09:34:16.947|02E| SMTP C: QUIT
It seemed to only take 30 seconds ironically to accept the email, but I could not find any information in the EM Client docs/articles about how to extend the timeout, so I hope this helps others solve/workaround the problem.
as other clients work with it, and I don’t understand why an explicit override value could not be provided in the UI if someone wants to allow for longer timeout durations.