Platform wise we could support this, however since nearly all apps manage their own login sessions after the Cloudron OpenID login, there is little on the platform side we can do. The centralized logout can be done in the apps we write and provide but only because there we reevaluate the login session/tokens against the OpenID auth provider all the time.
@CRBear said in Mail server: IP address verification?:
Am I correct in understanding that the email server checks from which IP address a connection is established to send an email and by default, it verifies against the Spamhaus blacklist?
The mail server does not make any check for outbound email. The various checks you see in the Email Status tab are purely diagnostic. The idea is if one or more checks are failing there, most likely the email won't be delivered.
The Spamhaus is checked for inbound emails though. The DNSBL zone against which it checks is configurable at https://docs.cloudron.io/email/#dnsbl
@CRBear Screenshot of your App Location Settings may help everyone to understand what you have so far, to then help with what you're doing within the LAMP app.
This seems a very specific corner-case, and I think we will aim for a less cluttered UI. If you have a lot of addresses there maybe the mailbox export feature can help you? It exports the meta data
@CRBear Yes, changes to those should work but they get overwritten on updates. Maybe you can just keep a copy of your changes for now and replace them after an update.
A little update on this:
I help a friend migrating their cloudron to another server and set-up a new backup storage (also using a Hetzner storage box).
Server migration worked fine (that was not using the Hetzner box).
When it came to connect the new storage box we faced issues.
We generated 4 pairs of ssh keys:
rsa with paraphrase
ed25519 with paraphrase
rsa without paraphrase
ed25519 without paraphrase
With all four we could connect to the storage box from outside cloudron (using terminal or from file manager). 1. and 2. required the paraphrase to do so.
On Cloudron:
and 2. didn't work >> expected as paraphrased is required
worked just fine
if trying to connect to the box by created a new volume or a new backup storage the connection failed as reported above in this thread. BUT if the volume or backup storage was already present and mounted (using key 3.), then I could go to the settings and replace key 3. by key 4. and then it connected fine.
Maybe this description might help tract where the issue comes from, since it only happens when mounted a new valume/backup and not when it's already present
