I have issues with sending mail from Manager. I use the Linux version on Ubuntu 20.04. The error message when setting up the smtp account is: Message could not be sent.
When trying to send a mail from within the invoice i get:
System.IO.IOException: System.IO.IOException: Unable to read data from the transport connection: Connection reset by peer. ---> System.Net.Sockets.SocketException: Connection reset by peer
at System.Net.Sockets.Socket.Receive (System.Byte[] buffer, System.Int32 offset, System.Int32 size, System.Net.Sockets.SocketFlags socketFlags) [0x00016] in :0
at System.Net.Sockets.NetworkStream.Read (System.Byte[] buffer, System.Int32 offset, System.Int32 size) [0x0009b] in :0
--- End of inner exception stack trace ---
at System.Net.Sockets.NetworkStream.Read (System.Byte[] buffer, System.Int32 offset, System.Int32 size) [0x000e2] in :0
at Mono.Net.Security.MobileAuthenticatedStream+<>c__DisplayClass85_0.b__0 () [0x0002b] in :0
at System.Threading.Tasks.Task`1[TResult].InnerInvoke () [0x0000f] in <6649516e5b3542319fb262b421af0adb>:0
at System.Threading.Tasks.Task.Execute () [0x00000] in <6649516e5b3542319fb262b421af0adb>:0
--- End of stack trace from previous location where exception was thrown ---
at Mono.Net.Security.MobileAuthenticatedStream.InnerRead (System.Boolean sync, System.Int32 requestedSize, System.Threading.CancellationToken cancellationToken) [0x00104] in :0
at Mono.Net.Security.AsyncProtocolRequest.InnerRead (System.Threading.CancellationToken cancellationToken) [0x000ac] in :0
at Mono.Net.Security.AsyncProtocolRequest.ProcessOperation (System.Threading.CancellationToken cancellationToken) [0x00093] in :0
at Mono.Net.Security.AsyncProtocolRequest.StartOperation (System.Threading.CancellationToken cancellationToken) [0x0008b] in :0
at Mono.Net.Security.MobileAuthenticatedStream.AuthenticateAsClient (System.String targetHost, System.Security.Cryptography.X509Certificates.X509CertificateCollection clientCertificates, System.Security.Authentication.SslProtocols enabledSslProtocols, System.Boolean checkCertificateRevocation) [0x0004b] in :0
at System.Net.Mail.SmtpClient.InitiateSecureConnection () [0x00059] in :0
at System.Net.Mail.SmtpClient.SendCore (System.Net.Mail.MailMessage message) [0x000a0] in :0
at System.Net.Mail.SmtpClient.SendInternal (System.Net.Mail.MailMessage message) [0x00050] in :0
at System.Net.Mail.SmtpClient.Send (System.Net.Mail.MailMessage message) [0x00084] in :0
The smtp setup and credentials are correct because on Win10 version is have no issues.
I mentioned this issue in another thread but since it seems a linux issue only i start this new one. I would like to know if there are other linux (ubuntu) users which experience same issue.
The issue is easy to replicate, you only need a clean install of ubuntu 20.04 (or 18.04) and test the sending of the mail.
If i am the only one with this issue, i rest my case and move on to another solution but as a long time user of Manager i would like to keep using it.
I know email has been a bug bear for a lot of users and thought I would investigate here’s what I have found:
using manager server 20.5.17 on ubuntu 18.04 with mono 6.4.0.198 and gmail settings with port 587 and an app specific password, email works
using manager appimage 20.5.17 on a fresh virtual machine of linux mint 20.04 no mono install, just the appimage itself, the email fails, doesn’t send, no error message reported (TBH, I didn’t try sending an email, I just used the “Test Email Settings” under Settings > Email Settings. None-the-less, it failed. This was using the same gmail settings as above with app specific password set.
I don’t exactly know the makeup of an AppImage and what’s required behind the scenes, I assumed it was a complete runtime, being a fresh install, there is virtually nothing installed on this VM except manager (I use specifically for testing).
I just installed mono using the generic repo of Mint with:
sudo apt-get install -y mono-complete
This has installed mono 6.8.0.105
I then re-ran the appimage and made no other changes, the test email button made a successful connection.
I’m still unable to use TLS1.2 on any of my Linux installs.
My WSL2 running ubuntu 18.04 is using mono version 6.10.0.104 and it works OK with tls1. My ISP plus my hosting server support TLS1 on port 587, so I’m lucky.
I’ve also seen (via wireshark capture) if a server responds with a “hello” response using TLS1.2 a client, originally which used tls1 for it’s “hello”, will switch to TLS1.2 OK.
However, some servers (postmark included) will not even respond to a TLS1 client “hello”
I’ve also installed Docker onto my Synology NAS DS716+II and loaded Manager onto the default Mono stack which also uses version 6.10.0.104 and I get the same results.
I just can’t figure how to instruct mono to use TLS1.2 instead of TLS1. I’ve even added some entries to ManagerServer.exe.config but they never worked either.
For Windows 10, ManagerServer.exe work with TLS1.2 by default as TLS1 and TLS1.1 has been disabled in the registry…
Can you capture the traffic to see if its using TLS1 or TLS1.2?
Local WSL I have a script that downloads and installs the latest version (currently 20.8.92). On the NAS I have 20.8.91 as I only set it up yesterday morning. That was the latest available when I built it.
I’m just preparing some tests for API testing and automation so I can find breaking changes early LOL
Thanks heaps @d3mad! I am seeing the same behaviour. Manager/Mono is using TLS1.0 on both my WSL and NAS and works only because my ISP/Hosting allow it even though it is now strongly suggested not to be used.
I’m glad you are seeing the same behaviour which means it’s pointless downgrading the mono version I’m using.
If I start ManagerServer.exe on my Windows 10 box, then you can see it uses TLS1.2.
It’s certain email providers that are blocking TLS1.0 and TLS1.1. This trend will grow. I wanted to use PostMark for a client because it it great for transactional email deliverability, but will completely ignore you if you use TLS1 and 1.1.
So do you think it’s mono that’s limiting TLS to v1?
perhaps @lubos might comment on this, I have no idea the mechanism by which he sends the email out, I’m assuming he’s just making a .NET call (through mono for linux and mac), but I don’t know if he sets anything in that request or not. Looking at the following I think he just makes the call and it handles the authentication. but he’d have to comment.
edit: I did just try this in OS-X and it too uses TLS v1.0 so my guess it’s mono that’s doing this
So here are some screenshots from my attempts at getting Manager to use TLS1.2 on my ubuntu 18.04 WSL2 setup. (I have the wireshark captures, but this is just what is relevant)
Standalone Manager working on Windows 10 talking to PostMark (they do NOT support anything less than TLS 1.2)
As the service providers tighten up their systems (as we can see is happening) more failures will likely occur.
I think the key is to restrict the ciphers that mono uses which will restrict the version of TLS. e.g. on my WSl2 Ubuntu server I ask what ciphers are available. markll@MarkW8-PC:~$ openssl ciphers -v -tls1_2
The standard list includes ssl3 and tls1 which I have removed. This is a list that should be allowed. TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 RSA-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=RSAPSK Au=RSA Enc=AESGCM(256) Mac=AEAD DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(256) Mac=AEAD RSA-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=RSAPSK Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD DHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=DHEPSK Au=PSK Enc=CHACHA20/POLY1305(256) Mac=AEAD ECDHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=ECDHEPSK Au=PSK Enc=CHACHA20/POLY1305(256) Mac=AEAD AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD PSK-AES256-GCM-SHA384 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(256) Mac=AEAD PSK-CHACHA20-POLY1305 TLSv1.2 Kx=PSK Au=PSK Enc=CHACHA20/POLY1305(256) Mac=AEAD RSA-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=RSAPSK Au=RSA Enc=AESGCM(128) Mac=AEAD DHE-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(128) Mac=AEAD AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD PSK-AES128-GCM-SHA256 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(128) Mac=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
Unfortunately Nix (osx/linux) is not my strong suit so I don’t know how to restrict it. It may be as easy as adding a setting the the ManagerServer.exe.config file, I’m really not sure.
Lubos has changed the underlying framework of .Net within the binary itself by including .Net Core as part of the binary instead of bundling a framework that had the TLS issue.
I have tested this latest implementation and the .Net issues with TLS appear to be fixed. I have confirmed it on a box that previously defaulted to v1 and it now defaults to v1.2. My mail server wasn’t rejecting TLSv1, but I’m confident this latest version will fix the issue you (and possibly others) were having.
I can confirm that the issue with Manager not sending email on Ubuntu has been fixed in latest version.
Many thanks to @d3mad and @MarkLL for investigating this issue.
