yes, direct url is working again. That was it! Applied the one line change on all three servers here and the 60 query test goes from 20/60 to 60/60 on each of them. For reference, temperror was running at 48%, 34% and 18% of inbound mail over the last 24 hours on those three. I will report back once enough new mail has come in to see where it lands. Thanks for digging into this so quickly.

Just to follow up. After more than one year I decided to move the Docker Images back to the virtual machine disk because I upgraded the vm to a instance with larger disk. I never had any issue with running docker images on a Hetzner Volume.

Thanks for reporting, I have fixed this now. I have also had to make the container rebuild when the memory limit is changed, so that mysql can adjust itself appropriately on start up.

@imc67 I have bumped it up to 20mb. thanks!

Hello @loudlemur Unfortunately I can't do that. Due to license constraints and other things we currently are not looking for contributions to platform code.

@davejgreen thanks for the report, I have fixed it. The issue was that CURDATE is used in two separate queries but the code assumed it's the same value in both queries. Thus the first query can return something values for CURDATE, but the second one may not since CURDATE has changed.

Deployed

Hi @james I just re-run the entire setup of Linux, installed and restored Cloudron by using the exact folder structure as on the live system. I confirm that the restore (so far I testet 3 apps, the others are still restoring) was successful. So, yes, you can mark the topic as resolved. Thanks again!

@d19dotca both the statements are orthogonal. Cloudron can provide feature to tackle spam and make it more accessible for all users. At the same time, Cloudron can also not expose implementation details like SpamAssassin configs. In fact, there are newer solutions out there like say rspamd which even help with integrating email with LLM. But because Cloudron exposed SA we are now "stuck" and possibly have to break support at some point. We have always taken this approach to our product, so it's not anything new. We don't expose docker configs, haraka configs, dovecot configs, nginx configs etc. It's not how we do things. The SpamAssasin config was done only because an immediate problem had to be fixed and was done in haste.

We have answered the support ticket, but the app limit is handled differently since Cloudron 9.2 so this should not really apply anymore as everyhing is not local to the server and not tracked like it used to be.

@p44 Looking at the 700+ line blacklists, I don't feel it's sustainable when agents can vary their user agents at will. A whitelist approach will likely work much better for desktop/mobile/cli browsers as there aren't that many of them. Not sure if the .htaccess approach can do a not-whitelist block.

Hello @jcalag You are still on Cloudron 9.1.3 and should update to Cloudron 9.2.0 since it includes many fixes also including for backups which might already solves your issues.

whitelist will be supported in coming release. There is no plan to expose spamassasin configs and specific variables though. In some future, we want to move away from SA (unlikely but this should remain an implementation detail).

@selver I have implemented this for the next release.

@marcusquinn thanks for the great report! Fixed - https://git.cloudron.io/platform/box/-/commit/caf0cc39bec12e0085e52102f7de9b9a6a68394b

I spent several days trying to understand why backups kept failing on my Cloudron instance. After investigating the issue with Claude’s help, I identified and fixed two infrastructure issues on my own (detailed below for context), but Claude also highlighted a weakness on the Cloudron side: the lack of retries for transient network/DNS errors during S3 backup operations. I’m sharing this report written by Claude here for review. Title: Backup fails entirely on a single transient DNS/network error during S3 copy/list operations — no retry Version: Cloudron 9.2.0 (Ubuntu 22.04.5 LTS Linux 5.15.0-186-generic) Context : self-hosted server, backups to Scaleway Object Storage (S3-compatible), both tar and rsync backup formats affected Summary Over the past week I've had repeated backup failures, all sharing the same final symptom: Error: getaddrinfo EAI_AGAIN cloudron-rsync.s3.fr-par.scw.cloud This occurred at different stages of the backup pipeline across different incidents: during initial tar packing/upload, during copyInternal (S3-to-S3 copy for snapshot rotation), during checkPreconditions (mount point check), and during listDir (listing objects for rsync-based copy). The common thread in every case: a single DNS resolution hiccup during a long-running backup (which can involve tens of thousands of individual S3 operations) causes the entire backup task to crash and be marked as failed, with no retry attempted at the DNS/network level or at the individual-operation level. Root causes I found and fixed on my own infrastructure (not Cloudron bugs, but worth noting for context) A local mail service (Haraka, bundled with Cloudron) was stuck in an infinite retry loop performing reverse DNS (PTR) lookups on what turned out to be an IP in the reserved 240.0.0.0/4 range — never a real client IP, likely a bug in Haraka's own DNS-resolution/rDNS-check code generating a bad address internally. This flooded systemd-resolved with several lookups per second, 24/7, unrelated to backup timing. One of my two DHCP-provided DNS resolvers silently failed to respond at all over DNS-over-TCP (confirmed with dig +tcp @<ip>, consistent timeout), while working fine over UDP. When systemd-resolved fell back to TCP (e.g. due to the Haraka-induced UDP noise, or any other reason), it would sometimes pick this broken resolver and hang. Both issues are now fixed (mail service restart + config fix for #1, resolver removed from netplan config for #2), and backups now get much further before any failure — but a single transient DNS hiccup can still occasionally happen (as it can on any network), and it still takes down the whole backup task when it does. What would help Wrap listDir / copyDir / copyInternal (and any other network-dependent step in the backup pipeline) with a retry mechanism (e.g. 3 attempts with exponential backoff) for transient DNS/network errors like EAI_AGAIN, ETIMEDOUT, ECONNRESET. A single flaky lookup during a backup touching 80k+ files should not fail a multi-hour backup task that has otherwise fully succeeded. If a retry budget is exhausted, consider resuming/retrying at the file level rather than aborting the entire task — some backups got quite far (tens of thousands of files copied) before the single failure. More generally: the current behavior converts what should be a transient, self-healing network condition into a hard failure with reason: 'External Error' / 'Internal Error', requiring full backup task re-runs from scratch.

Thanks for the update!

@james said: I am not quite sure what "hidden" post you are referring to, sorry a little confused here. New user so my posts are/were hidden until "approved", it wasn't showing yet, thus "hidden".

@joseph I didn't realize that I could use --appstore-id and then not have to deal with the image and manifest issues. I will give that a try, even if I don't jump versions, if this works I can make something that will step through each of the versions incrementally until it reaches the current version automatically. Thank you!

Ok. I will write to support. Thank you