You should see a summary in the email header just after the X-Spam-Status one, which explains how it came to this (ham) score. This should looks something like this, with different scores of course: X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -0.0 SPF_HELO_PASS SPF: HELO matches SPF record * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no * trust * [87.253.236.95 listed in list.dnswl.org] * 0.0 HTML_MESSAGE BODY: HTML included in message

(moving to support since this is not surfer related) This was a translation bug and already fixed in the repo, but didn't make it into the 9.0.5 release just yet. https://git.cloudron.io/platform/box/-/commit/a78799973dc2c988edf4e68f73f962d305d252f8

Hello @3246 Yes, as stated in the information text in AdGuard: Allowed clients A list of CIDRs, IP addresses, or ClientIDs. If this list has entries, AdGuard Home will accept requests only from these clients. Emphasis on only.

Yes, that did it! Thanks Nebulon.

Indeed the latest Immich version we have packaged is 2.1.0. The reason it isn't offered as an update is, because your Cloudron is not compatible with it yet. Newer Immich versions require the vectorchord Postgres extension, which is only part of Cloudron 9, which in turn is only available for users who want to early test it for the moment. But we will be start rolling it out to all users slowly this or next week.

It worked! Thanks.

Thanks @zohup !

Hello @Dont-Worry If you have some custom DNS setup and Cloudron is struggling with it you can choose no-op as the DNS provider. This will skip all checks and verifications and just assumes, you know what you are doing.

@SansGuidon Yes, it's because of that syslog file. Thanks to your post, I was able to fix it. It seems like v8.3.2 (Ubuntu 24.04.3 LTS) is the only one with the error.

Mystery solved! https://forum.cloudron.io/post/35426

@OrezBodajoy wow, great find

Thanks @james -- yes, this is solved.

I was using ChatGPT for some assistance on this, as I'm still struggling with this issue off-and-on-again, and it recommended applying this to the Haraka configuration: [outbound.limits] gmail.com=1/30s Essentially rate limiting delivery to Gmail which should lessen the likelihood of being rate limited by Gmail. Is there a way for us to configure this at all for testing purposes? I can't seem to create the outbound.limits file due to the read-only file system in the mail container, so I'm not sure how I can try this. Interestingly though, I noticed today that this issue only seems to happen if sending from a hotmail.com / outlook.com address to the hosted Cloudron domain name which then forwards to the gmail.com address will this issue be triggered. If I send to the same distribution list from my other email addresses, it seems to not trigger the rate limiting response. So it seems possibly related to the sending domain originally before the hosted domain itself, which Gmail occasionally seems to have problems with. Since the error is also sometimes Gmail has detected this message exceeded its quota for sending 4.7.28 messages with the same Message-ID, is there any possibility that Cloudron's mailing list feature could rotate the message-ID to avoid Gmail flagging it?

Issue was resolved with support@cloudron.io

I have updated https://docs.cloudron.io/backups/#restore-cloudron and https://docs.cloudron.io/guides/download-backups/#backup-file-names . Bit of a hasty edit but time is really right these days!

James, Thanks, that's useful, I can use that as a workaround. I will need a 20GB pool size to keep things running the way I want. Thank you. Lee

Nevermind, it was just a matter of being patient. Everything was set up correctly. For anyone else using Namecheap, it takes a minute for the DNS to sync. Give it some time (quite a bit more than you think) and it'll work.

Maybe https://forum.cloudron.io/topic/1579/var-lib-docker-overlay2-getting-full?_=1760112116784 is helpful: @nebulon said in /var/lib/docker/overlay2 getting full: For a start, docker images are often quite large, composed of a multitude of filesystem layers on top of each other. To mitigate the problem a bit, all Cloudron apps share the same base image, that helps a bit. The appsdata folder really only contains the data from within the apps, so that heavily depends on your own usage. The application code, so to speak, is inside those docker images.

I updated redis to 8.2.2 - https://git.cloudron.io/platform/box/-/commit/3547be34010a737d9fbd5aed5bb9e787eeff5456