Connection could not be established with host mail.domain.com [Connection timed out #110]
-
@humptydumpty just double checking, have you seen https://docs.cloudron.io/apps/freescout/#cloudron-mailbox already? Important thing here is TLS vs SSL distinction in freescout. I remember writing about this somewhere in the forum, let me see if I can find it. I think everything looks fine in your setup, just some freescout configuration.
-
@humptydumpty said in Connection could not be established with host mail.domain.com [Connection timed out #110]:
Should I manually enable ports 587 and 993 in Hetzner's firewall regardless?
Oh, this could be it. Are you using the full name in freescout like mail.domain.com ? If so, external ports have to be opened. I guess you got the blocking of those ports from somewhere in the docs? We should probably add some caveats to it.
-
@girish said in Connection could not be established with host mail.domain.com [Connection timed out #110]:
@humptydumpty just double checking, have you seen https://docs.cloudron.io/apps/freescout/#cloudron-mailbox already? Important thing here is TLS vs SSL distinction in freescout.
Yep, I've seen this and FS has been working correctly for years now.
@girish said in Connection could not be established with host mail.domain.com [Connection timed out #110]:
Oh, this could be it. Are you using the full name in freescout like mail.domain.com ?
Yes, I'm using the full domain (mail.domain.com). Again, I didn't change anything and it was all working fine until now. I switched to Hetzner a couple of months ago, but it's been working fine this whole time. It stopped suddenly on its own, coincidentally around the same time when I upgraded to 8.2/8.2.1.
I'll try opening the ports manually in Hetzner's firewall. I'd like to avoid doing that because when I first signed up with Hetzner, I did play with the firewall to open ports and things went south and couldn't undo it. I had to spin up a new one. Hopefully, it plays nice this time.
Btw, Freescout and the mail server are on the same server.
-
@girish Am I opening incoming, outgoing, or both in Hetzner?
-
Sigh. Server died upon activating the firewall.
-
Maybe I should open all of these too (except for "any"). I do use SSH and 53 for the DNS makes sense. IDK about the MYSQL and PGSQL though.
-
For the mail server domain, yes. The mailbox (different domain) is using Bunny. Proxy is off though. CDN acceleration is disabled in Bunny DNS. I didn't change anything at all when this issue started. It's been working fine. I use FS daily. Also, mail is working fine in Roundcube so DNS, ports, wtv are correct. It's FS that's picky, no sending/fetching of mailboxes. Oh, and I have multiple mailboxes using domains on Cloudflare and Bunny. Issue is the same for all. Issue is the same on a fresh FS, so it's not module related either.
Under
manage > mail settings > system emails > send test to
--- This test email is sent and received fine! -
@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.
-
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.
-
@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.
-
@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.
-
@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.