SOLVED Outbound email error: "Client network socket disconnected before secure TLS connection was established"
d19dotca last edited by d19dotca
Running into an issue with one particular mail server for a recipient. My emails aren't arriving at all. I see the following in the logs when it tries to send my message:
2020-11-24T01:21:09.000Z [INFO] [528A8DBB-ECC3-43B8-8D2E-DC65014EC9C5.1.1] [outbound] Looking up A records for: gw6158.fortimail.com 2020-11-24T01:21:09.000Z [INFO] [528A8DBB-ECC3-43B8-8D2E-DC65014EC9C5.1.1] [outbound] Attempting to deliver to: 188.8.131.52:25 (0) (8) 2020-11-24T01:21:10.000Z [ERROR] [528A8DBB-ECC3-43B8-8D2E-DC65014EC9C5.1.1] [outbound] Ongoing connection failed to 184.108.40.206:25 : Error: Client network socket disconnected before secure TLS connection was established 2020-11-24T01:21:10.000Z [INFO] [528A8DBB-ECC3-43B8-8D2E-DC65014EC9C5.1.1] [outbound] Temp failing 1606179904597_1606180869126_4_87_95hV7K_3760_88af3024f7bc for 1024 seconds: Tried all MXs
So it tries later and basically is in a loop as it can't succeed. It seems like the backend isn't even responding, but their mail server is definitely working because another client working with alongside (but not at) this other company is receiving mail just fine. Also other mail is being sent and received successfully to other recipients across all sorts of domains. This makes me think it's an issue with their mail server but they seem to have no trouble receiving from anyone else, so I can't quite narrow this down where the issue is.
I think this is unlikely to be a Cloudron issue, but wanted to raise it here in case anyone else has come across this and in case this is some sort of TLS-type compatibility issue. I'm usually pretty good at troubleshooting email issues but this one I can't quite figure out and it's also a bit time-sensitive in nature unfortunately.
I kind of want to say this is a TLS-based issue where the backend requires a certain TLS protocol version which isn't supported / being used from Cloudron server, that's usually where I see "Client network socket disconnected before secure TLS connection was established" with regards to other HTTP services anyways, just never seen it in SMTP before.
Any ideas on the above?
To my surprise, Fortinet's "fortimail" server isn't quite as secure as it should be when it comes to the certificate and server set... according to https://www.ssllabs.com/ssltest/analyze.html?d=gw6158.fortimail.com
It seems to support all TLS versions though and many ciphers. Is it possible there's a rare incompatibility here though? I'm not sure how to determine that in Cloudron to know what ciphers are used during negotiation.
I see https://git.cloudron.io/cloudron/box/-/blob/master/src/nginxconfig.ejs#L75 has the cipher suites but it's for Nginx, is that same list used for the Cloudron mail server outbound?
@girish I'll try as soon as I can later today, but according to the SSLlabs report above their backend supports TLSv1.2 to the older TLSv1.0, so it should be fine to talk on TLSv1.2 from what I can tell.
@d19dotca I thing this sslabs thing checks their web server ssl config, not their mail server tls config
@mehdi Oh does it? Ah, interesting it that's the case. Are you aware of any method for me to determine what the receiving mail server supports for TLS protocols and cipher suites? I haven't quite figured that out yet. I'm used to just openSSL for HTTP requests and SSLlabs, but if they don't really apply then to mail servers to reflect what the mail servers will see when they talk to each other then I guess that won't help me too much yet, so trying to find a way to find that data.
@d19dotca https://ssl-tools.net/mailservers/gw6158.fortimail.com it seems it also runs into a problem "unexpected EOF"
@mehdi Ah interesting. Okay cool, that might give me a bit to work with then if it's their issue (which I believe it is but couldn't really prove it), I can show them that. Thanks for the help!
Are you aware of any method for me to determine what the receiving mail server supports for TLS protocols and cipher suites?
You can try something like
openssl s_client -starttls smtp -connect server:25. Note that usually you have to do this from a real server and not from your laptop, since most residential networks will block outbound port 25.
There is also a better tool for SMTP connection testing, it's at the tip of my tongue...
Edit: gnutls-cli is the tool. It has some feature which openssl s_client does not support. I can't seem to remember what exactly.