Topics created by d19dotca

@girish That's great to know, thank you! I will wait before migrating then so it's easier to do. A request for clarification though... when you say "Change the Cloudron DNS backend ... to no-op"... do you mean all domains on the Cloudron or only the main one the Cloudron runs on? I have about 15 domains on my Cloudron, would I need to do that for them all or just the one main one?

@d19dotca Currently, there is no way. The SA settings are set in stone. I can open up our mail addon git repo tomorrow so you can get a better idea of how we have implemented it. But overall, our idea was that customers don't have to deal with implementation details like SA (for example, maybe we use rspamd later) and that spam detection should just work. If you have SA expertise, I am happy to incorporate your suggestions into the default settings.

Done, added notification for the next release.

I have 18 differents domains with 46 apps at present. As of now, I don'(t extensively use tagging, because the tag selector is a multiselect, which means I have to unselect my previous selection to switch context, which is too much trouble for me to use. I don't really use domain switchign because, selection with dropdown is a bit awkward to work with once you have a pretty long amount of items. (and it resets once you quit the page) So I haven't been really happy with the way it works. Thinking about it, a structure like the App Store, but configurable would probably be a pretty decent way organizing it. The default homepage could show Favorite Apps (instead of "Popular"), Tags instead of "Categories" and with a "Search" and "All" filter, we could get all sorted. (pun intended^^) What would also help would be to have the app meta fields (tags, label and maybe icon) show up before you click install/clone. Also, when an app in installed/cloned, it is viewable on every user dashboard, regardless of groups. The access settings can only be done afterwards. So there's a, arguably small privacy issue here. Access should ideally be configurable before app is installed. With those two changes, everything (permissions and meta) could be setup and correctly categorized when the app is installed. I have no idea how many apps are typically installed on a cloudron, I can totally understand this structure wouldn't be worth it for users with a limited number of apps. Though the permissions and meta fields setup at app install/clone time is relevant in any case. Finally, there would be a case for merging groups and tags, so users relating to a group can access all apps tagged in this group. Maybe it's a bit too rigid and this is probably a wider conversation because it also encompasses users, emails etc.

The memory limit set for apps does not mean that the memory cannot be used otherwise. This is just the upper limit at which the app gets restarted. Given that Cloudron has to strike a good default over various use-cases for the same apps, the limit is a bit conservative, but you can totally ignore that warning during installation as long as you keep an eye on the actual memory usage in your case.

@ruihildt This is not for deleting emails but for deleting a whole mailbox. If email is deleted, they are gone forever. You can see all the mailboxes under /home/yellowtent/boxdata/mail/vmail.

@d19dotca Thanks for the details! Let us get back by testing it out on a Mac.

Okay, that makes sense. Thank you for the quick reply. I wonder if it would make sense to add a feature where we can set the IP address to accommodate floating IP's in providers like DigitalOcean, so that the DNS records automatically setup by Cloudron in DigitalOcean would be using the floating IP instead. Without such a feature, it kind of removes the ability to have a sort-of manual failover method which is one of the main purposes of a floating IP from DigitalOcean (along with a secondary use-case of setting up a new server to replace an old one and moving the floating IP to the new one when ready, eliminating the need to update a whole bunch of DNS records). It would be nice, I think, to have Cloudron use a floating IP that we give it even if it means we have to set it manually in Cloudron first since it can't detect it automatically. The main reason for this is that whenever I switch a server, for example, nothing really needs to be changed at all, leaving downtime to a minimum if it exists at all during a server switch.

@dustinddotca If you add a CNAME record manually from mail.example.com to my.example.com that should work. Your email client might complain about certificate hostname mismatch but this is unlikely.