Can't reproduce as of 338138c9d2007e75ebb7f5e97dc5894cb125193d.

This looks like something on your system is broken and you can't launch the shell in the flatpak at all. You should definitely be running the command as user (it's not installed as root),
but it looks like that LD_PRELOAD error is fatal, and a quick google search pointed me to some ubuntu related issues (I didn't find anything directly related to flatpak though).

With the latest flatpak you can run a connection test like so

This looks like the resource has no server url whatsoever configured... Are you running the flatpak?

I don't know what's going on, but we seem to have moved on to a new error.

FWIW, it's now possible to specify which authentication method to use, so you could experiment with alternatives.

I'll close this as I currently don't have any intention of separating this in the UI.

I'm not sure what the rfc's have to say about it, but I agree it would be better if it was one or the other.

I agree that this would be a better approach, thanks for the suggestion.

Ah, yes, a restart is unfortunately required atm.

If you can send mail, that's just smpt working. The IMAP part is separate.

I suggest you try the flatpak at https://kube-project.com/getit.html

\n in your domain is clearly not normal or correct. One slash only is also incorrect, it's always smtps:// or imaps://.

mailo also doesn't advertise which authentication method it does support in it's capabilities. If you know, I'm sure we can fix this with a bit of work.

In the case of mailo imaps://mail.mailo.com:993 should be correct. I don't have an account there but I'm getting "Warning: {09573c96-3a6f-40f6-87fe-c4e89c339edb}.imapserverproxy : Job failed: "Login failed, server replied: A000002 NO Authenticate mechanism PLAIN unknown ", which seems to indicate that the server does not support imap PLAIN authentication, which is currently the only one that is supported (due to lack of a configuration option for it).

We are not yet using SPECIAL-USE yet, simply because we didn't get to implementing it yet.

In T12004#208820, @ognarb wrote:

It feels for me that the major problem with the current infrastructure is that we support 5 documentation tools. Is there a reason why Kube and other apps use another tooling? Do these projects have other needs? Does the maintainer prefer another tooling? Or did nobody have the time to update the documentation tooling for these projects?

We have read-only memory hole support and decrypt messages on sync for local search support.

Not really a problem in practice, and a solution would be search.

We're using flatpak

Also, support configuring starttls in the UI (necessary for some services).