When trying to setup the custom SMTP server with the correct details, “Message could not be sent” error is shown when clicking to test email settings.
I had previously been using an older version of Manager, and was unable to send emails using defaults or the custom SMTP and updated to the latest version as mentioned in the forums for the email issue.
Doing so corrected the initial error message, though did not resolve the problem.
Tested on two Macs both running El Capitan (10.11.13) using the latest Manager (16.3.24). Both fail with the same message.
First Mac was an existing business. Second Mac was a clean install with a business quickly created just to test SMTP connection.
Tested SMTP server in several email clients. Works as expected.
“smtp.zoho.com” 465 (SSL) / 587 (STARTTLS), with login required.
Use SSL is checked, have also tried without. No change.
From address must match the account, have also tried with default no-reply. No difference.
Also tested using Hotmail and Gmail SMTP (including allowing insecure logins for gmail), but still receive the same message.
Emails can be sent when not using a custom SMTP, or when using a custom SMTP that does not use SSL.
Also tested Manager (16.3.24) on Windows and the custom SMTP works correctly as expected.
On the Windows version, the error messages were more specific if incorrect data was entered, as opposed to only “Message could not be sent” on the Mac version.
Only port 587 (STARTTLS) is supported in Manager. 465 (SSL) won’t work.
This might be weird test but could you try the following?
First send an email when custom SMTP is disabled. Don’t close the program. After email when SMTP is disabled is successfully received. Set up custom SMTP (with port 587) and try again to test email settings. Let me know if this makes any difference.
The important thing in this test is sequence. First send an email without custom SMTP, don’t close the program, then try to send an email with custom SMTP enabled.
You’re right, that test would be weird … but the result isn’t.
Still displaying the “Message could not be sent” error. Tried twice for prosperity.
I verified the email without custom SMTP is delivered.
Also checked inbox/spam/trash for the email with custom SMTP, in case it was delivered in spite of the message, and there was nothing.
My initial guess was that there is something odd happening with root certification authorities. This would explain why plain SMTP works and SMTP over SSL doesn’t.
But as you say, the same settings work fine on Windows machine, they don’t work on Mac OS X. Correct?
I’ve been having a play about with this all day, trying to hone in. That process is still ongoing.
Manager on Windows handles whatever I throw at it. Plain SMTP works on both my Macs.
I also had a volume with an older OSX on it (10.10.2), booted that up to test with a fresh install; same response there.
If I uncheck the “Use SSL” box, then I get the error message of “530 Must issue a STARTTLS command first.” as would be expected.
Between that and packet inspecting, I can see that the STARTTLS is being sent and received by the server. The server hello completes and then the TLS handshake fails for some reason.
I have been setting up email servers to see if I could get a more verbose read on the problem, with no luck so far, other than more handshake failures. I’ve just setup my last server, but won’t be able to test it out unitl a bit later, but this one should give me more paramaters to mess about with.
In addition, I am also able to connect to the SMTP servers and authenticate through openssl via the terminal.
I managed to get it to work with port 587 and without the SSL option - but it is not clear to me whether any form of encryption is now being applied or not.
I can’t speak precisely to the cloud edition, as I use desktop edition.
However, if it sends without SSL checked for port 587 then that mail server either does not require SSL on port 587, or just does not support it.
You could test with Hotmail’s server “smtp-mail.outlook.com” on port 587 without authentication. Without SSL checked you should get a message that the server requires a secure connection with STARTTLS. With SSL checked you would get a message that you need to authenticate with a username and password (or possibly “Message could not be sent” or similar on Mac at present.
That would be expected behaviour for the SMTP server using an encrypted connection.
Postscript. Just to be clear, you will want to use your specific SMTP server and not something generic, as it would likely affect receipt of your emails.
Could you try again in the latest version? If it still fails, then the issue must be in underlying implementation of Mono. Try both Zoho and Gmail just to rule out the issue with SMTP server itself.
Issue remains in Manager Desktop 16.3.37. The TLS handshake still fails. Tested with Zoho and Hotmail on both my Macs.
Out of curiosity, I’ve also tested in linux using Ubuntu 14.04/15.10 and the issue does not occur there. SSL SMTP happily connects, so this does seem more specific to Mono on OSX, as I presume linux is also using Mono.
Now for the plot twist.
I also downloaded the trial of Manager Server, installed the Mono Framework as required and started the server.
Connected to my Manager Server, attempted my tests again and it worked like a charm.
Mono Framework being installed has not had any affect on the desktop edition.
I’m not saying Mono is in the clear, but this issue appears to only affect Manager Desktop on OS X.
I was able to get some verbose messages in Terminal by launching Manager Desktop directly from within the app bundle (Manager.app/Contents/MacOS/Manager)
The program seemingly launched as normal and gave me the following messages in the terminal.
$ ./Manager
Mar 29 02:14:25 Manager[5035] : CGSConnectionByID: 0 is not a valid connection ID.
Mar 29 02:14:25 Manager[5035] : Invalid Connection ID 0
Mar 29 02:14:25 Manager[5035] : CGSConnectionByID: 0 is not a valid connection ID.
ERROR building certificate chain: System.ArgumentException: certificate —> System.Security.Cryptography.CryptographicException: Unsupported hash algorithm: 1.2.840.113549.1.1.11
at Mono.Security.X509.X509Certificate.VerifySignature (System.Security.Cryptography.RSA rsa) [0x00000] in :0
at Mono.Security.X509.X509Certificate.VerifySignature (System.Security.Cryptography.AsymmetricAlgorithm aa) [0x00000] in :0
at System.Security.Cryptography.X509Certificates.X509Chain.IsSignedWith (System.Security.Cryptography.X509Certificates.X509Certificate2 signed, System.Security.Cryptography.AsymmetricAlgorithm pubkey) [0x00000] in :0
at System.Security.Cryptography.X509Certificates.X509Chain.Process (Int32 n) [0x00000] in :0
at System.Security.Cryptography.X509Certificates.X509Chain.ValidateChain (X509ChainStatusFlags flag) [0x00000] in :0
at System.Security.Cryptography.X509Certificates.X509Chain.Build (System.Security.Cryptography.X509Certificates.X509Certificate2 certificate) [0x00000] in :0
— End of inner exception stack trace —
at System.Security.Cryptography.X509Certificates.X509Chain.Build (System.Security.Cryptography.X509Certificates.X509Certificate2 certificate) [0x00000] in :0
at System.Net.ServicePointManager+ChainValidationHelper.ValidateChain (Mono.Security.X509.X509CertificateCollection certs) [0x00000] in :0
Please, report this problem to the Mono team
I looked up the unsupported hash error and found some old references to possibly a few buggy releases of Mono.
Then I found some references in the app bundle to Mono framework 2.10.9, which was released mid 2012.
Just for giggles, I installed Mono 2.10.9 on my Mac and used that to launch the Manager Server and was able to reproduce the same issue; “Message could not be sent” due to a failed TLS handshake.
So, implementation not withstanding, I agree and think it should be fixed in Mono.
The SSL in Manager Server was tested working with Mono 3.4.0 and 4.2.3.4, where it failed with 2.10.9.
Superlative. We have lift-off.
Tested with latest version, 16.4.27, and can confirm successful mailing with SMTP over TLS.
As a heads up, there may be an issue launching this new version; I can only get it to run on this machine from inside the disk image. I’ll check on another machine in the morning.
… but the result isn’t.