Cloudron Forum

You can also follow this great guide and set up an automated blocklist update: https://forum.cloudron.io/topic/3795/firewall-spamassassin-automatic-list-update/41?_=1740739173375 Might mitigate some (few) of these annoying spam attacks.

@neki The misconfiguration warning is for your IP and has no relevance for incoming mails. That warning is being shown because Spamhaus is not reponding correctly to the request from Cloudron and Cloudron is incorrectly interpreting that as your IP being blocklisted. It is nothing more than a display error though and should be fixed in the next release. If you are seeing incoming mails rejected due to Spamhaus listing then this is due to the DNSBL checking. The error may well be with Cloudron and how Spamhaus reports are interpreted, but that will be resolved if you deactivate the checks. @SansGuidon Had you removed Spamhaus from the DNSBL checks? I think the issue is (at least partly) to do with changes in the way Spamhaus processes queries (I noticed a lot of errors in the logs before deactivating Spamhaus altogether) and the way Cloudron interprets the results when errors are thrown. I have two Cloudron servers, both running version 8.3.2, but one on Ubuntu 22.04, the other on Ubuntu 24.04. Interestingly, the server running on 24.04 does not show the (false) email configuration error, but the one on 22.04. regularly does. As already mentioned, however, that is just an icorrect message and has no affect at all on deliverability as that will depend only on the receiving mailserver.

@IniBudi @nebulon I can confirm that problem is not related to Cloudron, after I did some sending tests.

@scooke if you have an account, can you are share a screenshot so we can copy get inspiration from?

Ok, I understand that. The case which you're saying is different. If anyhow the user doesn't have access to the Admin and just the user account is compromised then he can send emails from that account only and if admin has setup limits over that then the spammer can't go beyond the limits. Limits should be setup in any case and should be controlled by Admin. This is a very important and good feature that needs to be implemented. I hope you understand. Thanks!

@JohnBee said in email server broken after update...: snapshots to fall back-on You restored the entire server to a previous working state?

@osobo the power of the forum, thanks are due to @jdaviescoates and all those who went before on this issue.

@joseph said in Frequent Email is not configured properly notice: Maybe DNS is periodically failing on your servers. Do you know which DNS servers your server is using? You can use resolvectl to figure this. Thanks for the explanation! my DNS servers are : Current DNS Server: 1.1.1.1 DNS Servers: 1.1.1.1 9.9.9.9

Looks like this part does fix it (instructions for root server): [image: 1737492462373-9fbbe904-6e2e-4deb-8d7d-5d2812a54c83-image.png] Thanks to you both for the pointers!

working now. thx

I use netcup too, I disabled IPv6 on the server entirely and since everything has been working with no issues. Though disabling IPv6 persistently on reboot was not straightforward and had to be done modifying netplan config, see above on the thread (https://forum.cloudron.io/post/102554).

Omg, for whatever reason the TLD did change from .de to .com (I have .de but not .com) so the failure was totally correct. No problems, nothing to see here, please close the case Happy holidays!

Well, the thing is that I can obviously rename folders in my own account(s) in order to work around this, but when migrating accounts for other family members, colleagues or clients it's harder since I will be asking them to change their folder naming habits just because the mailsystem can't handle it. To be honest I never ran into this with other mailsystems and I've used / tried a considerable amount of them in the meantime: Google (Gmail/workspace), Microsoft (hotmail/365), Zoho, Mailcow just to name a few and they all accept periods in folder names. As a result we got used to use periods in our folder names. I'm fine if the default stays as it is in order to not break anything for other people, but being able to change it when needed would be nice. And yes, there are possible collisions with the internal folders (new, cur, tmp) when switching to FS, but this can be anticipated by setting the DIRNAME variable to something unique. In regards with testing, I'm not sure this has a huge impact since the working of dovecot shouldn't change in any way when switching to FS.

That's great, thanks @girish! It seems to work now. I enabled it and followed the steps in the new documentation you linked to, and then ran doveadm -c /run/dovecot.conf index -A '*' from the mail container which started indexing everything. Just waiting for the indexing to finish to confirm it'll be good.

@LoudLemur You could do that. No problem. You can specify the mail server location to be any SUB and pick any of the domains you have set up in Cloudron. To make things even wackier, you could use multiple subdomains like sub.sub.domain.com as the mail server.

@james seems to me this is the likely cause of this too: https://forum.cloudron.io/topic/13068/issue-with-email-delivery-going-through-cloudron-mailing-lists

nice i eventually figure it out thanks

Ok weird, this worked, I backed up apps and updated to Cloudron 8 but it's not working again. that file didn't change. I set it to google's public DNS and it was fine - I reinstalled tailscale and set override DNS to true which I think should fix it and let me keep using TS

Ah yes, you were quicker than me, all green again, so I guess that was just a temporary minor glitch Thanks for checking though!

@brettjhonson that looks like quite a clumsy service advertising. But thank you for the idea.