What's coming in Cloudron 10

[girish]

@dsp76 Good point about the matuc example. But I think URL based protection is more complicated because we will need help from the apps. For example, it will require all of mautic admin and it's assets to be designed to be served from under a specific subpath. I haven't really investigated how friendly apps are in this regard but most likely we will have to handle this package by package (in a future release).

[girish]

Getting there slowly. Some of the mail features are also implemented, I will post them.

Backup codes for TOTP is implemented now.

[girish]

Mailbox indexing status for FTS is exposed in dashboard now

[girish]

girish said:

mail: fix mail forwarding. there's been lots of bug reports on this feature. have to investigate the root cause

The mailing list feature has got a revamp. For a start, it's completely removed and all the lists will be migrated to a mailbox with the Cloudron superadmin as the owner.

Each mailbox now has a capability to set up forwarding (same options as mailing list):

For the delivery aspect:

• SRS is still the way to go to overcome SPF.
• We follow best practices from gmail - https://support.google.com/mail/answer/175365?hl=en . Body/message headers are not changed. We also add Forwarding headers. Spam filtering is done before forwarding.
• We now attach ARC headers when forwarding. However, ARC is a system of trust and mostly the big mail providers won't trust ARC headers originating from Cloudron. So, this is mostly a theoretical exercise.

Unfortunately, there is nothing much we can do here about the delivery aspect. If it works, it works.

[fbartels]

@girish said:
Each mailbox now has a capability to set up forwarding (same options as mailing list):

Looking forward to try out this new feature. Now that each mailbox has some settings, would it be possible to configure a different delivery for a given mailbox? Like some apps want mail delivered via pipe to a command, lmtp, or simply another internal smtp port in an app.

[girish]

@fbartels not yet, but we can possibly add routing options as we go. Do we have concrete use cases? Maybe we should collect them and decide what is the best approach. I know "always bcc" is something people have wanted but the real use case here is to have an archive of email for regulatory purposes.

[fbartels]

@girish said:

Do we have concrete use cases? Maybe we should collect them and decide what is the best approach

It certainly always depends on the application one wants to use. I do remember some people requesting mailman as an app, but that was not possible because mailman wants mails directly delivered to it instead of to a mailbox.

One application that i currently use and could benefit from this would be ntfy, where you can also submit messages via smtp.

Another application that could benefit from this would be alternative mailservers like stalwart or the product from my employer if you need exchange like sync.

[avatar1024]

avatar1024 said:

Also given you're looking at emails, I wonder if you might have time to look at a couple more email related ideas (but I understand new features aren't and shouldn't be the priority over what you've listed):

2. Creating mailing lists based on a Cloudron group, so that mailing list recipients / email addresses get automatically updated when users enter / leave the group

3. Currently when I send an email to a mailing list I'm part of I also receive that email. Would it be possible to have an option (per mailing list) so that it is not the case, i.e. that senders don't receive their own email if they are part of the list?

@girish have any of the two features been looked at as part of the revamp (got kind of a workaround for 1. in my original post which in fact should work even work better with your new approach)?

No worries if not of course, it's just to know what to expect. 2. especially would be super useful as I can't find a clean workaround for doing that with current features.

[CRBear]

@subven said:

While I appreciate the upcoming mail related features and fixes, there is still one crucial feature left out that was talked about for years: Auto/Custom BCC for incoming/outgoing mail

We need to make them archivable to comply with german GoBD law. Setting this at client level would not pass as the law requires seamless documentation without user influence. This is not limited to german law but is generally useful for any company that needs to document business processes comprehensively. I know a lot of companys and freelancers lacking DMS systems, mostly because its complicated and can be very expensive.

Best case would be the ability to set global BCC per mailbox within Cloudron.

Is there any update on when this feature will become available?

A global/custom BCC setting per mailbox would be absolutely essential for us and is urgently needed, especially for reliable and seamless email archiving without depending on individual client-side settings.

[nebulon]

There are unfortunately no concrete plans to add this right now, but we do investigate this. For German GoBD law some "always BCC" is actually not a compliant way as I understand it, neither is using https://mail-archiver.org/ for example. The reason is that one has to archive in- and outbound emails on the transport and not storage (like mail archiver does) side of things. Which in our case means in haraka.

We will continue to discuss this internally where an how this can be best and ideally most compliant implemented with Cloudron, but we are not there just yet.