Thanks for opening your first pull request in this repository! ✌️

SO users do not have a password set, and the auto provisioning of mail does not work for SSO user.

I think it would make most sense if the static password can be an option of provisioning. With the current approach it will be impossible to allow installations to have provisioned accounts and accounts on other imap servers.

I think it would make most sense if the static password can be an option of provisioning. With the current approach it will be impossible to allow installations to have provisioned accounts and accounts on other imap servers.

Do you mean that I should add an option for the admin settings like a checkbox "Use master password" and also a textbox for entering a password?

Yes, that is what I mean.

Yes, that is what I mean.

Cool! I will start working on that :)

Code looks clean, kudos!

I see that the master password is a global option. How about we move it into a provisioning config? The benefit is that one would be able to add two or more provisioned accounts with master passwords.

Code looks clean, kudos!

Thanks! It is not fully working yet though, the master password is not being prefilled if it is set, like I would expect (so that you can intuitivly remove it). Do you have any idea what I did wrong there?

I see that the master password is a global option. How about we move it into a provisioning config? The benefit is that one would be able to add two or more provisioned accounts with master passwords.

Absolutly, I could do that. How can we detect if an account can be associated with a master password in IMAP and SMTP factories, in that case?

BTW, my idea is that we will use the master password(s) as a fallback if the user has no password set. Does that sound good?

Also I just noticed #849 . I noticed that they wanted imap and smtp default passord to be separated. Should we do that? And is "default password" a better nomenclature than "master password"? Or maybe "fallback password"?

I see that the master password is a global option. How about we move it into a provisioning config? The benefit is that one would be able to add two or more provisioned accounts with master passwords.

Absolutly, I could do that. How can we detect if an account can be associated with a master password in IMAP and SMTP factories, in that case?

Could setting the password for provisioned accounts with a master password moved to \OCA\Mail\Http\Middleware\ProvisioningMiddleware::beforeController?

Could setting the password for provisioned accounts with a master password moved to \OCA\Mail\Http\Middleware\ProvisioningMiddleware::beforeController?

So setting the master password as password for the user inside the if clause here?

or will the exceptions be triggered anyway you think? That worked it seems. Now I only have to figure out how to get the password from the specific configuration in stead of using a global one :)

I moved the settings in to the provisioning/config but I fail to grasp where the values are saved to oc_mail_provisionings. Any pointers here would be welcome, I tried to mimic how the sieve settings were handled, but so far no luck as far as getting any settings in to the database.

Also I don't understand how I can get the master password out of the config in \OCA\Mail\Http\Middleware\ProvisioningMiddleware::beforeController (assuming I can get it in there 😅 ), can I loop through the $configs and get the values out somehow?

The provisioning configs will need a database schema change to hold the new password (or two if we split imap and smtp) and changes in the entity that represents the database entries.
Then you will be able read the password through a getter of the config.

The provisioning configs will need a database schema change to hold the new password (or two if we split imap and smtp) and changes in the entity that represents the database entries. Then you will be able read the password through a getter of the config.

Does that mean we need a migration?

And after that do I only need to add the values to lib/Db/Provisioning.php or something else?

Yes, a migration and the changes on Provisioning.php, correct :)

This is working fully now. I had to add a getter for the mail account in 1d116ad

If there is a better way to get around this, please point me in the right direction. But this is what I came up with :).

Anyway, it works for me know, and this is what it looks like:

Thanks for this great commit. Could you provide more details about configuring postfix and dovecot to be able to use this feature? I mean any minimal simplified config that will get this working.

It is not completly straight forward and involves sasl auth for postfix a lua passdb in dovecot and sql userdb in dovecot and mysql user accounts in postfix. But I will do a writeup if this gets merged, because I think it will be immensly useful to any organization using nextcloud mail.

Do you have any idea when this will be merged to main?

This is up to @ChristophWurst :)

That would be great. Thank you! I already use SASL for postfix to authenticate against LDAP. So it should be not to much changes for my case at least, I think.

Tested and works 👍

Please bump the info.xml version from alpha.2 to alpha3. A version bump causes Nextcloud to check for new migrations and run the one you've added.

Tested and works 👍

Please bump the info.xml version from alpha.2 to alpha3. A version bump causes Nextcloud to check for new migrations and run the one you've added.

Done!

I lack permission to push to your branch

You can find my amendments at #9008. It adds a safety check and fixes typing issues.

@MohammedNoureldin seems like this will be merged soon, and here is my prommised write up: https://wiki.sunet.se/pages/viewpage.action?pageId=164888692

I am interesting in knowing if Nextcloud supports automatic logging in to Email if the server supports OIDC login. Or is our only chance to auto-login to emails is using this Master password approach?

UPDATE:

This seems to be possible as shown here: https://docs.mailcow.email/third_party/nextcloud/third_party-nextcloud/#configure-nextcloud-to-use-mailcow-for-authentication

@mickenordin, have you maybe tried using Docker-Mailserver and OIDC directly instead of master password? From the link of mailcow above this should be somehow possible. If you are interested, we can try this together with Docker-Mailserver (which I prefer more because it has no dependency on any database if you use LDAP as your backend).

Superceded by #9008

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!