Lacking decent documentation for groupware e-mail provisioning

Nextcloud version (eg, 20.0.5): 26.0.2
Operating system and version (eg, Ubuntu 20.04): Docker
Apache or nginx version (eg, Apache 2.4.25): Docker
PHP version (eg, 7.4): Docker

The issue you are facing:

The (new) e-mail client built-into next cloud is great. However, provisioning is an exercise left to the magician. The server admin documentation has a 3 line paragraph Mail — Nextcloud latest Administration Manual latest documentation which doesn’t explain at all how this feature is supposed to be setup, and the included documentation in nextcloud itself, also reads as something not easy to follow.

 Account provisioning

A provisioning configuration will provision all accounts with a matching email address. Using the wildcard (*) in the provisioning domain field will create a configuration that applies to all users, provided they do not match another configuration.
The provisioning mechanism will prioritise specific domain configurations over the wildcard domain configuration. Should a new matching configuration be found after the user was already provisioned with another configuration, the new configuration will take precedence and the user will be reprovisioned with the configuration.
There can only be one configuration per domain and only one wildcard domain configuration.
These settings can be used in conjunction with each other.
If you only want to provision one domain for all users, use the wildcard (*).
This setting only makes most sense if you use the same user back-end for your Nextcloud and mail server of your organization. 

E.g. a few examples could really help here. What if I have multiple domains that are being hosted. This seems to be supportorted, but not show as to how. The prefilled example possibly being incorrect doesn’t help either %USERID%domain.com (where did the @ go? why not example.com, why not pre-filled with the server host variable?) Why are the first two fields not prefilled to match the domain.com example below? Anyway.

That last line is the most interesting one ** This setting only makes most sense if you use the same user back-end for your Nextcloud and mail server of your organization.**, though i also read ‘if the passwords are the same’. So first the passwords being the same, that of course doesn’t help, because the moment the user changes his nextcloud password, they are no longer the same. This is something I actually want to avoid. So shared authentication backends. But this is even more mysterious then the rest :slight_smile:

So with lack of documentation hereof; what are the possible shared authentication backends? LDAP certainly is one. The external_user plugin could be another (though that one is a bit harder to configure, at least no GUI components seem to exist, and I couldn’t get it to work in either case).

What other options are there? Since I use an SQL backend for e-mail authentication already I was thinking, of telling courier-dovecot/sasl to simply query nextcloud, but then comes the password compatibility to mind (surely something that can be solved on my end hopefully).

So in short, I’m dabbling a bit in how to make this work, with the sparse documentation. In the end, all I want, is that (on the same network/server) a user can login to nextcloud, click the mail tab, and things just work, without having to enter any passwords there, without having to worry passwords being out-of-sync, but with the ability for the user to change their own password.

I could always go the roundcube route, which I currently use, but I’d prefer to use nextclouds premium citizen.

Where’s the hidden documentation :wink:

A provisioning configuration uses the user authentication from Nextcloud to autoconfigure an email account. It works when the credentials for Nextcloud and IMAP are the same. If we don’t know the password (e.g., if the user authenticated via saml) you cannot use it.

The preview on the right tells you the used settings to connect with the remote imap/smtp server.

There is no additional documentation. But we are always happy for pointers where to improve our documentation. Until now, the inline documentation was enough for most people.

Every authentication backend should be supported.

I doubt that makes sense.

1 Like