@girish what about just a normal organization level rights separation? I mean - it's really two different set of roles: 1st line support, dealing with mailboxes 2nd or 3rd, making sure the system and services are up and running. I don't need hiding anything, I just want to ensure my users can manage they mailboxes and users for they own. For now I have to temporary give admin permissions to the 1st line and that's kind of risky...

@girish WHOOP!!! Thank you!!

@fbartels Optimism and hope? /s Great points.

@murgero I didn't say it wouldn't be accessible; it would, just through my proxies, that make sure to remove any information, that would help in disclosure. You also miss an option with Intranets.

The latest lamp package support PHP 8.0

@fbartels This is a much better way to say it, yes. Some way to communicate with my users in a semi-permanent way.

@marcusquinn Yeah, I for one would love for my screw-ups and poking-arounds to be recorded. Would sure save time on re-Googling commands!

A simple feature to add with a decent benefit. +1!

@robi Thanks for letting me know.

I think @robin 's suggestion seems well thought out. The big advantage is that it would be totally optional to do it for apps for which it would be hard, while providing a significantly better UX for apps which do support it.

@robi good catch, this is fixed now.

@nebulon Kind of depends on the app type, too, I guess? The one I really notice this stand out on is for LAMP. I have maybe 4-5 of these, all serving static sites. I don't really care when they update, but whenever they do, I get a bunch of notifications for them all at once. I don't know. I guess I see your point, and maybe it's fine to just leave it be. Ultimately, I guess if you don't design for people to have too many things of the same type, it probably won't matter anyway.

I still need cloudron login, because many people are using it now. I'm going to try to activate social login in nextcloud and rocket chat, and see if it merges the social token with the existing account. If so, the problem should be solved.

@girish Hi there. Thanks for checking into this for me. I had a suspicion that the spam engine was verifying, since I did see those fields in the Spam results headers. However I think it's also useful to have Haraka add the headers as well. It would add very little overhead and will add additional detail that the spam header doesn't contain about the DKIM verification (such as which signature failed or passed, since an email can contain multiple). In regards to DMARC. I don't believe this would be risky at all if implemented in the following manner: No DMARC record found, take no action. DMARC found, DKIM/SPF aligned, take no action DMARC found, DKIM/SPF alignment fails, but p=none, take no action. DMARC found, DKIM/SPF alignment fails, but p=quarantine, move to spam folder DMARC found, DKIM/SPF alignment fails, p=reject, dev/null the mail. If you don't like the risk of this, push it to spam instead... or make it a cloudron option under Settings. Thanks for listening.

There is a restart server button. But of course, that is broken in 6.3.4 Hopefully 6.4 should be out in a couple of weeks though.

@hillside502 Yes, you can update to 6.3.4 and safe. And then you update to 6.3.5. This is the correct update path. I think what's wrong is that it is telling you 6.3.4 is unstable. It shouldn't be. I am trying to reproduce this, let's see.

Internally, there is already a way to set custom env vars (you can do this only in the CLI currently, cloudron env). So, we have to update the manifest and the UI to use those fields and set env vars.