Connection could not be established with host mail.domain.com [Connection timed out #110]

[girish]

@humptydumpty the system email is configured by cloudron itself. You can ignore this (for this problem).

One thing in your screenshot: I noticed now that FS has changed it's TLS options (very nice). You have to choose STARTTLS for port 587. In yours it is none.

[girish]

[humptydumpty]

The docs still say to use none if CR mail and FS are on the same server (which they are for my case). I updated it to TLS, but issue persists. I even restarted the app with no effect.

[girish]

@humptydumpty the docs are a bit outdated since FS has changed the Encryption options. I will fix that once we resolve this... I am out of ideas now though. Can you send us an email to support@cloudron.io with the domain? It must be something very obvious because our FS works.

[humptydumpty]

@girish Sent.

[humptydumpty]

@girish I'm not sure if you got my email as I sent an email (proton email) to my CR email (roundcube) and I didn't receive it. I deleted the Hetzner firewall (as I've had it this whole time) and then sent a new email and then it was received in Roundcube.

[girish]

@humptydumpty thanks.

Just as an update: we found that for some reason, the docker containers (any of them) are unable to reach any port other than port 443/80 using the public IP. From the server itself, all ports of public IP are reachable... Have to debug this further tomorrow.

[Dave Swift]

Any update on this? I'm having the same issue.

[humptydumpty]

This is happening if the mailserver and freescout are on the same server. You can either move FS to another CR or change the mailbox settings (sending/fetching) to what's shown in the screenshots below until a perm fix is released and then you can revert to the previous settings.

SENDING

---

FETCHING

[girish]

Right, the issue here was related to disabling the userland proxy in Docker. This breaks setups where containers in UDN are unable to connect to each other via public IP. Will investigate this coming week for a proper fix. Until then, simply use what @humptydumpty said

[girish]

I pushed a fixed in the firewall for this. It's part of 8.2.3, you have to update Cloudron and hopefully that fixes this.

[bmann]

I am on 8.2.3 on a Hostinger VPS and also having trouble fetching.

This is an old FS that I had stopped and just now turned on again. Previous settings worked (group shared mailbox) -- in that it fetched the IMAP folders and said the connection was working, and the email arrives in snappymail. Tried humptydumpty settings, also "worked", still not fetching.

Sending works fine from FS, from Snappy, etc.

[girish]

Can you try openssl s_client -connect <mailsever>:993 -crlf from web terminal of FS? Does it connect?

[bmann]

@girish said in Connection could not be established with host mail.domain.com [Connection timed out #110]:

openssl s_client -connect <mailsever>:993 -crlf

Since I'm using the localhost settings that HD said, I used this (note host name and alt port):

openssl s_client -connect mail:9393 -crlf

Got this response:

CONNECTED(00000003)
40A74365227F0000:error:0A00010B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:354:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 293 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

[nebulon]

Is it possible that there is port typo? It would be 9993 not 9393. So tripple 9

[humptydumpty]

@nebulon I've been using it as 9393, and that's how Girish has it also in the screenshots he sent me during our troubleshooting. Sending and fetching are working with 9393.

Edit: I'll try reverting to the original settings soon to test with v8.2.3.