I am trialing eM Client on a new Windows 10 laptop and cannot get it to connect to my SMTP server (Stackmail).
When I send mail I get an “incorrect authentication error”. Running diagnose and then fix tells me it has found the server but the password is wrong (it isn’t) and prompts for a new one.
IMAP works fine with the same password
Windows Mail and Mailbird on the laptop both work fine with the same config
Another account in eM Client (VirginMedia) works fine
I have tried with Anti-virus (MS Defender) turned off.
I have removed and reinstalled eM Client but the problem remains.
I logged a call yesterday with Stackmail but they can find no issues on their end that would cause this. Doing a Google search I see that connecting to SMTP is a common issue with eM Client so I am coming to the conclusion that this is a fault in the product. Windows Mail and Mailbird both worked straight out of the box. Has anyone got any suggestions I haven’t tried? For what it’s worth, I’ve attached a screenshot but note I have tried every combination of settings.
Apart from this issue, this is my favorite of the clients I have tested … but if I can’t SEND email with it I shall have to go with something else.
I am just evaulating clients on a new laptop so at the moment only have the free licence. My hosting company (Lowreg) provides the email service, they happen to use Stackmail at the backend. I’m not clear why that should make a difference to the licence agreement?
I’ve spent another few hours on this and I now understand the problem. The diagnosis logs show that eMC is trying to use CRAM-MD5 to authenticate. From other posts on the forum it seems that nobody has managed to get CRAM-MD5 working from eMC and it can’t be overridden, so it looks like eMC isn’t for me.
I’m really disappointed as this was by far my preferred client.
viernes 18 septiembre 2020 :: 1423hrs (UTC +01:00)
Hi IanW…
These are the settings from Stackmail:
+++++ +++++ +++++ +++++
Account type: IMAP
Incoming mail server: imap.stackmail.com.
Outgoing mail server: smtp.stackmail.com.
Incoming server port (IMAP): 993.
Use the following type of encrypted connection: SSL.
Outgoing server port (SMTP): 587.
Use the following type of encrypted connection: TLS.
+++++ +++++ +++++ +++++
Comparing these with your grapic it appears that you are using
the wrong SMTP Port: you have 465
The Free licence doesn’t allow commercial use of eMC. It requires a Pro licence.
Also, I thought CRAM-MD5 was obsolete.
There are no problems with SMTP and eMC that I’m aware of. It’s certainly the best mail client I’ve tried by a country mile.
Try using port 587 to force SSL/TLS
Just to reiterate, the screenshot was just an example, in fact it was how the “fix” option left it (“fix” was impressive, by the way, managing to identify the correct servers). I have tried all the ports (25, 465 & 587) and security policy settings, including combinations that shouldn’t work. The diagnostic logs show that the systems are connecting but the authorisation - using CRAM-MD5 - is rejected. I know it’s an obsolete protocol but I have no contol over that and anyway, if it’s in the product it ought to work.
I’m not using it commercially. I do have my own domain on a hosting company, which happens to use stackmail, does this constitute commercial use? Even so, I can’t believe the restriction would be implemented by deliberately failing authentication.
I am very impressed with the product (its diagnosis options are unrivalled!). If someone can definitely confirm that this issue goes away with a licence I will happily buy one, but to me this looks like a bug. If you do a forum search on CRAM-MD5 you’ll see there are lots of issues with it.
My flag about the licence was just cautionary. Even if you get the CRAM-MD5 authentication working, experience from past posts here have resulted in Free licences being chopped dead when eMC “powers that be” recognises the potential use as commercial. How it does it I’m not sure, but having your own domain/mail server is probably an indicating factor.
I have no idea why the server has rejected the authentication, so it might be worthwhile trying to contact the Support group for advice here:
That’s the whole point, why is it in the product? I don’t care if they fix it or remove it, either will be fine. My server doesn’t require CRAM-MD5, it is eMC that is choosing to use it (and failing).
I have spent a number of man-hours debugging this product, I would very much like to have bought it but it doesn’t work in my case and there is no value to me in spending any more time on it. It’s a product bug that has existed for at least 10 years and has been reported here a number of times, which reduces my confidence in it somewhat.
How many accounts are you attempting to run with the Free license?
I assume you know there is a limit of TWO.
I also have my own hosted domains and some while back had SMTP
issues, long before I started using EMC with whom I’ve never had
any mail issues.
I overcame the original problem by switching to a 3rd party SMTP
service, also because of ISP connection permissions throughout EMEA.
I have used ‘authSMTP’ for over 15 years, have never had a problem.
I have 116 users on the service throughout my companies.
No that’s incorrect - eMC requests the authentication methods supported by the server and chooses the most secure.
“SMTP S: 250-AUTH PLAIN LOGIN CRAM-MD5” - this is SENT from the server.
The server gives eMC a choice of PLAIN or CRAM-MD5 (as above) so eMC has to choose the latter.
It’s almost certainly a problem with the server side processing NOT eMC - but try contacting eMC Support and send them a copy of the log for analysis as suggested.
But, as I advised above. CRAM-MD5 authentication protocol was obsolete over 12 years ago I don’t offer much hope that Support is going to give much attention to this.
If this was a server side issue then why does every other client connect without a problem? I am using Windows 10 Mail, Thunderbird, Mailbird, Android Mail, and Samsung Mail and all are able to send email through this SMTP server. Not to mention my hosting company’s thousands of other customers.
It doesn’t have to choose the latter, it only does so because it thinks it can support it. If it had to, what would be the point of the server sending a list at all?
Many clients allow you to force PLAIN and if eMC had this option I could use it as a workaround, but unfortunately it doesn’t. Note however that I haven’t actually had to do this in any other client, either they use CRAM-MD5 properly or - more likely - they don’t support it and fall back to PLAIN. I don’t know which but it doesn’t matter to me, they work!
The only attention they need give is to take it out, then it will work.
I have sent the log to support. If they can fix this before my 30 day trial expires they will have another customer!
I hope you get your issue resolved. I suspect TB et al work around CRAM-MD5 problems by defaulting to PLAIN or LOGIN, but that opens up all sorts of security exposures.
Anyway, good luck.
I’ve now got a new demo licence and I’m happy to report that it works. The diagnosis log shows that Stackmail and eMC have successfully negotiated CRAM-MD5.
I’ve now got a new demo licence and I’m happy to report that it works. The diagnosis log shows that Stackmail and eMC have successfully negotiated CRAM-MD5.
Ok. Did you setup the account via the “automatic account wizard” or via “Add account / Mail / Other” option ? Also did you use have to any plain text strings in the diagnostics tab ?
Ok that’s interesting it sends with your own Domain name SMTP Server “without specifying any security policy on port 587”. Very strange.
So “with your domain name now as the SMTP server” and Port 587, will it then send if you set the Security policy to use “Force usage of SSL/TLS” rather than no security. ?
Or “with your domain name now as the SMTP server” and Port: 465, will it then send if you set the Security policy to “Use SSL/TLS on special port (legacy)” ?
If it wont send mail with either that way, then i would personally suggest to “contact your Domain SMTP Server” technical support and let them know you cannot use the secure SMTP Security policy with either port number in eM Client. They can then test that with eM Client & Postbox.
As its really not good in my opinion using a Secure port without the security policy.
As an additional test, I have reset the host from my domain back to stackmail and even that works. i.e. I am now running with the exact configuration that was failing 4 years ago.
As I mentioned early in the thread, Stackmail’s response was that they had thousands of customers using the service successfully and eMC was the only client software with a problem.
Academic for me as I now can’t get it to fail. I am aware that there are users still having an issue with smtp and stackmail. My only suggestion is that they ensure they are on the very latest version of eM Client as something has changed since 2020.
