Regular Issues with Email Fetching via IMAP in Freescout
-
I have been experiencing regular issues with email fetching (IMAP) in Freescout. My email is set up on Cloudron, and recently, the fetching process intermittently stops working entirely. The only temporary solution I have found is rebooting the server, which resolves the issue for a short time before it recurs. I have also tried clearing the cache, but the problem persists.
Could you please help identify the cause of this issue and provide a more permanent solution?
Thank you for your assistance.
-
-
Ah ok, so maybe some issue with the nameservers.
-
-
-
@vadim how have you configured the freescout IMAP connection ? Is FreeScout and Cloudron mail on the same server ?
-
@vadim See https://docs.cloudron.io/apps/freescout/#cloudron-mailbox . Use SSL in the Encryption dropdown . FreeScout has a bit different terminology than one expects.
-
I tried also with SSL and I have been used SSL, the problem started with SSL and now I am trying with TLS.
Actually problem is Cloudron blocks some connections, my PTR record also is not reached by Cloudron, but it is OK, and I am sure, I checked it.In this moment, when the problem is Active I have next situation:
sudo cloudron-support --troubleshoot [OK] node version is correct [OK] docker is running [OK] MySQL is running [OK] nginx is running [OK] box is running [OK] unbound is running [FAIL] Could not load dashboard domain. Hairpin NAT is not working. Please check if your router supports it test@test:~$ host my.emailserver.eu Host my.emailserver.eu not found: 2(SERVFAIL)
NAT in my router is set up correctly, I am sure! Other services work perfect!
I need just to reboot server and after cloudron reboot it immediately starting to work.
sudo cloudron-support --troubleshoot [OK] node version is correct [OK] docker is running [OK] MySQL is running [OK] nginx is running [OK] box is running [OK] unbound is running [OK] Dashboard is reachable via domain name test@test:~$ host my.emailserver.eu my.emailserver.eu has address 213.my.ip.address
-
@vadim OK, so, the root cause is the DNS resolution issue . Looks like it starts to fail at some point. Is there something in the network that blocks DNS requests?
Looks like this is some internal network? Maybe try to set up a forward zone to the internal DNS (https://docs.cloudron.io/networking/#internal-dns-server) ? In the next release, we are moving away from unbound since it's causing not-so-easily debuggable situations (like this one).
-