Cloudron Forum

Ok, so after looking into open ports a bit more, it turns out that there is nothing listening on port 587. As such, there is no SMTP server running or listening to any port whatsoever. I figure that an SMTP server may only start running if I enable incoming emails (setting which was not enabled, purposefully). When I enabled incoming email setting, sudo netstat -tlnp | grep 587 was finally returning something and n8n configuration worked fine. So to sum up, if my understanding is correct, when only using outbound mail, there isn't an actual SMTP server running, but only some kind of abstraction that containerized apps can use to send email directly through the mail relay (the internals of this are fuzzy to me...), so I need to enable incoming emails in order to send emails... But I'm glad I was at least able to make this work before going into 2026. Thanks for the help and for putting me on the right path here. Thank you for all the great work you do Cloudron Team, and wishing you all the best for the new year :).

Haven't encountered such timeouts from thunderbird, unless the network is actually flaky. Maybe check if both ipv4 and ipv6 are setup but only one works? Could be that thunderbird (probably relying on the system's network interface selector) sometimes picks one of the two which resolves but does not route.

@simplo thanks for reporting, fixed now - https://git.cloudron.io/platform/box/-/commit/fda393b5e148340e2dc138f31a5a6443fa8d0ee3

@joseph thanks! No, no errors inside of docker image logs. /home/yellowtent/platformdata/logs/mail/*.log - from what I can see, that is the same logs I can see inside of Docker - so I would say there are no (error) logs - from all of the perspective, the server looks perfectly normal... except that it doesn't accept user's messages... I would hope that you bring updated Dovecot to Cloudron 9 and it will self-resolve, but better will just do a restart for the time being...

@nebulon That's great. Apart from that, it seems to be running smoothly; it still takes time to propagate the usage stats, but that doesn't really affect us.

@hakunamatata Can you try the telnet command via SSH first (instead of web terminal) ? I think maybe a machine in DMZ is unable to connect to itself using the public IP ? Can you try `telnet cloudron-lan-ip 993 ?

Hello @ccfu and @dffla Thanks for the assistance @ccfu Good to see that you got your issue resolved @dffla

@james I have a Cloudron license, and that’s where I install and manage all our applications. Sorry for the confusion!

@mattcazz yes, definitely . In hindsight, we should have maybe package the mail server more like an "app" . And then just like other apps, it would have gained all the customization of Cloudron apps. The email configuration could then have been inside this "mail server" app. We want to rework mail server to an app after Cloudron 9.

See: https://forum.cloudron.io/post/52997

@nostrdev So glad you listened when we chatted about that too! Welcome.

Thank you all! the issue was the unbound service not working and also my email delivery issue too.

Hi @James - Many thanks for this. The changes already looks great and promising. May I make a suggestion ? I think, in this case, Freescout approach offers a greater granularity between email notification and in-app notification, with potential for further development based on the communication channel (Mobile if ever, API ? etc..), leaving the end admin users decide what works best for them Here is the screen I am referring to in Freescout. [image: 1753778253533-e6ab2fb5-e080-4b2e-8443-adde0ee3d332-64145699-7f368480-ce22-11e9-9ead-1ac3ef29ba9b-resized.png] If it is not too late in the development of this, maybe it might be worth considering?

I've also tried to create a mailbox (test@mydomain.coop) and set-up a redirect with roundcube to three "external" email addressed (@gmail / @posteo), delivery fails with all of them. So it is not specifically with Cloudron mailing lists but a bigger issue with redirects in general. @staff any clues?

What is the use case to prevent internal routing? But if you set up an external MX record and add that MX host to your SPF also (so Cloudron will accept incoming), then I think it does what you want?

@girish Thanks for this - This is a great workaround and fit the bill perfectly for us.

Just to let you know, I still get the error " Connection to the POP3 server is failing with an authentication error. Please check your POP3 settings." in the admin dashboard. Though everything looks to work perfectly fine.

Thank you @james, that is great news.

TTL issue ? I mean, this symptom lasted a very long time (a full year I'd say). Not seen since early June though. Maybe the "odd DNS issue" then. I guess this can be closed.