Cloudron Forum

@nebulon It isn’t even so much complicated filters as it is dozens of filters. If I were to move my clients to the new webmail client for example today, they’d have no ability to edit their existing filters at all because it doesn’t expose the sieve filters in the UI like Roundcube does.

As an example, one of my clients is a doctors office and they have roughly 30-50 folders (for different doctors, test types, digital faxes, etc), and there are almost just as many filters, because much of it is automated for them. There’s just no way I can have them use the new webmail app right now because they have no way to make changes to their existing filters if they needed to.

I hope that helps paint the picture a bit better.

@nebulon said:

Yeah that is a shortcoming of sieve mostly as webclients build filters which are often incompatible with each other, since sieve is more like a programming language rather than a config setting.

One of the things Roundcube has going for it is the ability to edit sieve filters directly (via code which is also nice because it allows AI to generate some complicated ones if needed since like you said it's a practically it's own language). It'd be awesome of the webmail app from Cloudron could do the same.

Right now if I add a filter via the Webmail app from Cloudron, it shows up in Roundcube as a numbered filter. So I can effectively see it and edit it from Roundcube, but I cannot view the filters created in Roundcube from the new webmail app from Cloudron.

Since pretty much all my clients use Roundcube right now and a few of them in particular (mostly the doctors offices) have pretty extensive filtering rules enabled, I think that may be a requirement for my clients before I can look at transitioning them from Roundcube to the more modern Webmail app from Cloudron.

@nottheend In my experience, if AI has access to the source code, it can easily write tests to verify it's own accuracy which greatly reduces the hallucinations. And combined with a frontier model like Astra or Fable (overkill for documentation but just saying...) the accuracy is likely very high.

I only say it because I do tend to do writing and documentation for technical products as a small part of my job, and ever since giving it access to product source code, the accuracy of its responses has been significantly better.

Agree though that AI isn't necessary, especially if the people writing the documentation are the ones developing the product in the first place (which is the case with Cloudron), because they'll know better than pretty much everyone what the intention is and how something is meant to work. AI can still be useful though, as it can help spot errors, find better ways to write things, ensure written consistency across all the documentation, etc.

Just my two cents.

Hello,

I believe there is a limitation somewhere (undocumented though) for contact imports. The HTTP response is a 500 because the request entity too large in the payload upon import.

For context: I have a VCF file with around 1,700 contacts that I was trying to import for testing purposes, and it errored out with Failed to import contacts (500). The VCF file I was using to import was 14.2 MB in size.

I could not find this documented, but the stack trace generated in the logs was pretty clear this was a size issue overall. Logs below.

Sep 03 22:31:11 ==> Starting contacts
Sep 03 22:31:12 CardDAV discovery: http://0.0.0.0:3000/.well-known/carddav
Sep 03 22:31:12 CardDAV server running at http://0.0.0.0:3000
Sep 03 22:31:12 Users authenticate with their email and app-specific passwords
Sep 03 22:32:59 at file:///app/code/node_modules/@cloudron/tegel/index.js:262:14
Sep 03 22:32:59 at Layer.handleRequest (/app/code/node_modules/router/lib/layer.js:152:17)
Sep 03 22:32:59 at Layer.handleRequest (/app/code/node_modules/router/lib/layer.js:152:17)
Sep 03 22:32:59 at Route.dispatch (/app/code/node_modules/router/lib/route.js:117:3) {
Sep 03 22:32:59 at getRawBody (/app/code/node_modules/@cloudron/tegel/node_modules/raw-body/index.js:116:12)
Sep 03 22:32:59 at next (/app/code/node_modules/router/lib/route.js:157:13)
Sep 03 22:32:59 at next (/app/code/node_modules/router/lib/route.js:157:13)
Sep 03 22:32:59 at read (/app/code/node_modules/@cloudron/tegel/node_modules/body-parser/lib/read.js:113:3)
Sep 03 22:32:59 at readStream (/app/code/node_modules/@cloudron/tegel/node_modules/raw-body/index.js:163:17)
Sep 03 22:32:59 at textParser (/app/code/node_modules/@cloudron/tegel/node_modules/body-parser/lib/types/text.js:34:5)
Sep 03 22:32:59 error: PayloadTooLargeError: request entity too large
Sep 03 22:32:59 expected: 14165817,
Sep 03 22:32:59 length: 14165817,
Sep 03 22:32:59 limit: 10485760,
Sep 03 22:32:59 path: '/api/addressbooks/5fa3c363/import',
Sep 03 22:32:59 status: 500,
Sep 03 22:32:59 type: 'entity.too.large'
Sep 03 22:32:59 {
Sep 03 22:32:59 }
Sep 03 22:32:59 }
Sep 03 22:34:29 at file:///app/code/node_modules/@cloudron/tegel/index.js:262:14
Sep 03 22:34:29 at Layer.handleRequest (/app/code/node_modules/router/lib/layer.js:152:17)
Sep 03 22:34:29 at Layer.handleRequest (/app/code/node_modules/router/lib/layer.js:152:17)
Sep 03 22:34:29 at Route.dispatch (/app/code/node_modules/router/lib/route.js:117:3) {
Sep 03 22:34:29 at getRawBody (/app/code/node_modules/@cloudron/tegel/node_modules/raw-body/index.js:116:12)
Sep 03 22:34:29 at next (/app/code/node_modules/router/lib/route.js:157:13)
Sep 03 22:34:29 at next (/app/code/node_modules/router/lib/route.js:157:13)
Sep 03 22:34:29 at read (/app/code/node_modules/@cloudron/tegel/node_modules/body-parser/lib/read.js:113:3)
Sep 03 22:34:29 at readStream (/app/code/node_modules/@cloudron/tegel/node_modules/raw-body/index.js:163:17)
Sep 03 22:34:29 at textParser (/app/code/node_modules/@cloudron/tegel/node_modules/body-parser/lib/types/text.js:34:5)
Sep 03 22:34:29 error: PayloadTooLargeError: request entity too large
Sep 03 22:34:29 expected: 14165817,
Sep 03 22:34:29 length: 14165817,
Sep 03 22:34:29 limit: 10485760,
Sep 03 22:34:29 path: '/api/addressbooks/5fa3c363/import',
Sep 03 22:34:29 status: 500,
Sep 03 22:34:29 type: 'entity.too.large'
Sep 03 22:34:29 {
Sep 03 22:34:29 }
Sep 03 22:34:29 }

Hello,

I was just deploying the Mail app to test with (I love the modern UX by the way, thank you for building this app!), and I see that the Spam tab in mailbox settings has a few things which I wanted to provide feedback on (and a question to ask too). Screenshot below for reference as well.

1. At least while in dark mode, I find the placeholder text in the Allowlist and Blocklist divs to be bright enough that they almost look at first glance like real text rather than placeholders. And I think the reason I think that way is because it's brighter than the text under the "Allowlist & blocklist" heading. It may just be a my own perspective, but I would maybe suggest darkening the placeholder text a little bit to make it less obvious, either that or perhaps increase the contrast between that and the descriptive text under the various headings on the same tab.

2. For the spam filter is active part with the statistics on how much is spam vs not spam... it took me a while to understand what the / 20 part represented? At first I thought it was a bug or that text was cut-off. From re-reading the text above though, I guess the "100%" part is representative of at least 20 messages in each classification, is that correct? I don't necessarily have a solution here, but I just feel like this part could use a little work in terms of how to display that information. But I might just be sour because I was embarrassed on how long it took me to understand it.

3. For the blocklist and allowlists... this might be obvious to most users perhaps, but for an admin side of things, it might be helpful if there was descriptions there (or at least maybe in the documentation for the app?) to confirm that this is a per mailbox setting but more importantly explain how this affects the spam filters server-wide in Cloudron if there is ever a conflict between what's set server-side and what's set in the Mail app (client-side).

That's all my feedback for now on that tab. Thank you again for considering it and for building such a replacement webmail app for everyone using Cloudron.

This CMS is fantastic. Been playing around with it the past few weeks, it's great!

I used AI to help me create a Cloudron package, I'm still exploring it and will try to publish it when it's safe. It took me a while to get the email portion working, but it seems to be working in my latest tests. Would love Cloudron to implement this one natively, but community apps can definitely fill in the gap in the meantime. I'm hoping Instatic comes up big.

@joseph Maybe an alternative UX could be for an app admin to have the ability to “disable” the Cloudron robots.txt feature on apps like WordPress so that it’s clear to other admins that the app is managing the robots.txt instead of Cloudron. Just an idea at least.

@girish No I wasn’t and still don’t, that’s why I mentioned in an earlier comment that it was a little bit misleading. I’m just saying now though since this was marked as solved because you weren’t sure what more could be done, I’m just adding that exposing the ability to set rate limits in Haraka could be nice as a workaround and giving more control to users.

@james Hi James. I think you may have misunderstood my current status. Sorry for any confusion there.

I already found the root cause and worked around it by manually flattening the forwards I had in place which were affected, so by going from A to B to C to instead using A to C directly, cutting out the middle layer forwarding chain. It’s all fixed for me at the moment, although I would prefer to use the original chain so that aliasing works well whenever C needs to be updated so that only one account needs to be updated instead of several.

But I am reporting it here to the Cloudron team because it still should be a use-case that is handled by Cloudron in the migration from mailing lists to the new forwarding style.

Cloudron either needs to flatten the mailing lists so that A goes directly to C instead of via B, or else Cloudron needs to properly support A to B to C as it did before.

Otherwise when 10.0 goes out to more people you’re going to have a lot of complaints from users who use the same forwarding scheme.

@girish Having the option to add rate limiting outbound to certain domains in Haraka would be nice to have.

I encountered what appears to be a mail-forwarding migration regression after upgrading from approximately Cloudron 9.2.0 to 10.0.1.

Before the upgrade, I had forwarding chains like:

address-a@example.com
→ address-b@example.com
→ external-recipient@example.net

Cloudron 10 migrated the former forwarding addresses into mailboxes with forwarding enabled, but these multi-stage chains no longer worked.

Mail sent to the first address was accepted and redirected to the second local mailbox, but never reached the external recipient. The messages remained in:

/home/yellowtent/boxdata/mail/haraka-queue

The queued messages confirmed that the first redirect occurred:

X-Sieve-Redirected-From: address-a@example.com
Delivered-To: address-a@example.com

After affected messages entered the queue, the entire mail service became unreliable. Roundcube reported:

SMTP Error (0): Connection to server failed.

Sending and receiving mail stopped working. Restarting the mail service did not resolve it because the problematic queue entries and forwarding configuration remained.

I recovered by:

1. Moving the four stranded messages out of haraka-queue.
2. Changing each affected mailbox to forward directly to its final external recipient, eliminating the intermediate local forwarding mailbox.
3. Restarting the mail service.
4. Replaying the preserved messages through SMTP.

All replayed messages received SMTP 250 responses and appeared as Sent in Cloudron’s event log. New mail is also working normally.

Possible reproduction

1. On Cloudron 9, create a forwarding address A that forwards to another local forwarding address B.
2. Configure B to forward externally to C.
3. Upgrade to Cloudron 10.0.1.
4. Send mail to A.
5. Check whether it reaches C or remains in haraka-queue.

It may also be reproducible directly on 10.0.1 by configuring forwarding-enabled mailboxes as:

A → B → external C

My suspicion is that the migration preserves each forwarding relationship without flattening the chain, while the new forwarding implementation does not safely handle mailbox-to-mailbox forwarding chains.

@girish said:

Also, the plan is not to expose spamassassin and it's features/plugins. We will simply integrate the use cases and never implementation details. Currently, the custom SA config is allowed in the UI but this was a mistake on our side.

Hmm, I am not sure if I agree with that view. Why do you think that was a mistake? If it wasn't customizable, many of us would be getting many more times the spam we already do because the default SpamAssassin rules are pretty awful these days with the aggressive spam nature as a result of so many more bots and more sophisticated spam attacks.

Please don't remove that. If anything, I am in agreement with @imc67 that we need more controls. Cloudron is maturing, and with the help of AI many people are getting more advanced in their skillsets, and hiding things away from technical admins only increase friction with using Cloudron. I do hope that this will be reconsidered, and that more controls can be exposed for us.

---

On a separate note about the SpamAssassin sa-update and sa-learn stuff that Cloudron has a script for, I was recently looking into that myself and comparing it with a script I wrote myself for running some SpamAssassin scans for learning ham and spam (BAYES training). Here is an AI summary of this for reference:

The bundled /app/code/spamassassin-config/learn-from-user-mail.sh, scheduled daily at 22:00 UTC by /app/code/service.js, only identifies paths under .Spam as spam.

Its ham search excludes exact .Drafts, .Spam, and .Trash paths, but it does not correctly handle:

- .Junk or nested Junk folders, which are learned as ham
- .Deleted Messages, which is learned as ham
- nested Trash folders such as .Trash.CANCELLATIONS
- Sent/Sent Messages, with no option for administrators to exclude them
- folder and message paths containing spaces, because results from find are processed through whitespace-splitting shell variables
- messages above the default spamc 512 KB limit

The script also applies head -n 200 to unsorted find output, so the selected messages are not necessarily the newest 200.

Could the learner use Dovecot special-use metadata (\Junk, \Trash, \Sent, and \Drafts) or, at minimum, robust Maildir folder-name matching with NUL-delimited paths?

It would also be helpful to make Sent-folder learning configurable and provide an administrator option to disable or customize the bundled automatic learner.

I love the idea of handling bots. Currently I use a script from some sites but it’s more spam-based and unfortunately the API in Cloudron will only handle so many network addresses (or specifically a max size of PUT I believe) so I can’t keep expanding the list of IP firewall lists I want to use for blocking traffic.

Lately this has become an issue for me for a few reasons but notably I’m finding too much bot traffic showing up in website analytics when using Matomo or Umami, and even third-party app Rybbit, and I have been trying to find a way to fight this so that the analytics is more accurate. If there’s a way to better fight this at the network layer in Cloudron I think that would be fantastic. At the very least though I think increasing the size allowed for network lists would be very helpful so that we can include more IP addresses.

Also, I love that mail is finally getting the attention it much deserves. Looking forward to that.

I think apart from what one person mentioned which is domain-based SpamAssassin rules or changing scores for example depending on the type of spam they receive, it’d be really nice if we could easily configure SpamAssaasin in the UI for resetting training data and forcing a rescan of spam and ham folders, as well as the ability to note which folders should or should not be treated as ham or spam so that we can add in our own for example.

Just something else to consider.

Thank you for all the hard work! Looking forward to v10.

I assume this may be more of Vaultwarden issue than a Cloudron one but I wanted to say the recent image update (https://forum.cloudron.io/topic/2546/vaultwarden-package-updates/79?_=1778039394241) seems to have broken Vaultwarden, requiring me to restore from backup.

May 05 20:47:32 => Exporting env vars expected by Vaultwarden
May 05 20:47:32 => Starting Bitwarden
May 05 20:47:32 /--------------------------------------------------------------------\
May 05 20:47:32 |                        Starting Vaultwarden                        |
May 05 20:47:32 |--------------------------------------------------------------------|
May 05 20:47:32 | This is an *unofficial* Bitwarden implementation, DO NOT use the   |
May 05 20:47:32 | official channels to report bugs/features, regardless of client.   |
May 05 20:47:32 | Send usage/configuration questions or feature requests to:         |
May 05 20:47:32 |   https://github.com/dani-garcia/vaultwarden/discussions or        |
May 05 20:47:32 |   https://vaultwarden.discourse.group/                             |
May 05 20:47:32 | Report suspected bugs/issues in the software itself at:            |
May 05 20:47:32 |   https://github.com/dani-garcia/vaultwarden/issues/new            |
May 05 20:47:32 \--------------------------------------------------------------------/
May 05 20:47:32 2026-05-06T03:47:32Z 
May 05 20:47:32 [INFO] Using saved config from `/app/data/config.json` for configuration.
May 05 20:47:32 2026-05-06T03:47:32Z 
May 05 20:47:32 [2026-05-06 03:47:32.167][panic][ERROR] thread 'main' panicked at 'Error running migrations: QueryError(DieselMigrationName { name: "2026-03-09-005927_add_archives", version: MigrationVersion("20260309005927") }, DatabaseError(Unknown, "Referencing column 'user_uuid' and referenced column 'uuid' in foreign key constraint 'archives_ibfk_1' are incompatible."))': src/db/mod.rs:501
May 05 20:47:32 0: vaultwarden::init_logging::{{closure}}
May 05 20:47:32 1: std::panicking::panic_with_hook
May 05 20:47:32 2: std::panicking::panic_handler::{closure#0}
May 05 20:47:32 3: std::sys::backtrace::__rust_end_short_backtrace::<std::panicking::panic_handler::{closure#0}, !>
May 05 20:47:32 4: __rustc::rust_begin_unwind
May 05 20:47:32 5: core::panicking::panic_fmt
May 05 20:47:32 6: core::result::unwrap_failed
May 05 20:47:32 7: vaultwarden::db::DbPool::from_config
May 05 20:47:32 8: vaultwarden::main::{{closure}}
May 05 20:47:32 9: vaultwarden::main
May 05 20:47:32 10: std::sys::backtrace::__rust_begin_short_backtrace
May 05 20:47:32 11: main
May 05 20:47:32 12: <unknown>
May 05 20:47:32 13: __libc_start_main
May 05 20:47:32 14: _start

Any ideas on this one?

@timconsidine So does Umami but it doesn't seem to work too well, haha. I just installed it last night from the community package that you built and will try that out today on a few sites to compare the data. I really appreciate you putting that together!

Not to distract too much from the original topic, but do you have a Claude Skill or something that you use to help package apps for Cloudron? I just realized a Claude Skill may be super helpful for something like this and maybe it'll help me package some apps myself too which I've avoided since I was never too knowledgable of the full process yet.

@timconsidine oh this is fantastic! I love Umami overall but the main trip up for me is the excessive bot requests that it’s tagging as valid analytics. So many hits (multiplier over expected Canadian visitors for a small local business) from Singapore for example, and it’s all basically Petalbot traffic hitting the client sites with a 100% bounce rate. If I exclude bounce rate (a new feature in the Umami dashboard) then it is much closer to expected traffic data. There’s been a few posts from a few users (including myself) in their GitHub repo but seemingly no desire to fix it. ‍️

Because of that, I’d definitely be interested in Rybbit analytics on Cloudron. Happy to beta test the community package if that helps.

@jadudm Agreed. But isn’t that something configurable in the package? Looks like it isn’t a user-facing setting, but I assume this can be taken care of in the code part of the package? I’m not super familiar with packing apps just yet so correct me if I’m wrong.

Probably worth setting the client max body size to 0 for unlimited since there will be all sorts of sizes to an app that’s used for backups. I’m just surprised nobody else has run into this issue, it happens immediately upon backup.

@timconsidine hi Tim,

I tried to use the community app but I get a 413 response code (which suggests the payload is too large). It happens at the very first backup attempt.

Any suggestions? Is there anything I may have missed, or anything you had to do after deploying the app? Did you ever run into the 413?

I’m using tarball and encryption in case that matters at all.

I haven’t used Garage yet but isn’t it just another s3? So it’d basically be a MinIO replacement, right? Do we have any other options for ones with “hardlinks” using rsync? I kind of think the Surfer app would honestly be a great way to use as a backup somehow if it could be used to expose a disk.

I am in a similar position. I currently use iDrive e2 for backups and it’s fine but it does take around 1.5 hours uploading tarballs from my server. I’m looking at possibly deploying a low-budget Kimsufi server in the same OVH data centre and just mounting that disk as SSHFS to Cloudron on my primary server, haven’t tried it out yet. If I go this way I will likely still keep iDrive as a second backup destination and just run it a little less frequently and with lower retention to save on costs a little bit there.

I’m wondering about MinIO alternatives as I tried MinIO on a second Cloudron install but it seemed to take even longer than uploading to iDrive e2 somehow (I expected it’d be quicker not slower). It seemed the project is dead too but then it also looks like there’s an active fork that maybe the Cloudron @staff can look into using instead. Brings back many of the lost MinIO features by the sounds of it too.

Thinking of other avenues to keep backups more “local” or as close to local as possible for rapid quick backups, and then completely offsite as a second backup plan too.

I have around 65 GB compressed to back up, around 125 GB uncompressed, I believe.