Thanks for the reassurance and the other assistance you have provided!
Everything seems to work a treat.
------- Original Message -------
On Sunday, March 5th, 2023 at 18:00, Aki Tuomi <aki.tu...@open-xchange.com>
wrote:
> Order does not matter much as long as you do it about same time. But
> otherwise, yes.
>
> Aki
>
>> On 05/03/2023 18:43 EET Jeremy <mailinglist-subscripti...@protonmail.com>
>> wrote:
>>
>> Hi,
>>
>> Thanks for the notice! But yes, I was aware of this. For future reference
>> though, would you mind telling me how I would go about doing this? I take it
>> I'd first have to re-encrypt the user keys, before changing the account
>> password. So before changing the password for a user in my PostgreSQL
>> database, I would do the following:
>>
>> doveadm mailbox cryptokey password -u 'u...@example.com' -o <hex-encoded
>> sha256-hashed old password> -n <hex-encoded sha256-hashed new password>
>>
>> since I am using encode(digest('%w', 'sha256'), 'hex') in the PostgreSQL
>> password_query.
>>
>> Can you confirm that this is the correct way to change the user keys'
>> password? Thanks.
>> ------- Original Message -------
>> On Saturday, March 4th, 2023 at 16:41, Aki Tuomi
>> <aki.tu...@open-xchange.com> wrote:
>>
>>> Dovecot tries to hide passwords in logs so you're probably safe.
>>>
>>> Remember that there is no automatic password change for mail crypt. If
>>> user's password is changed, it will require corresponding update for user's
>>> master key.
>>>
>>> Aki
>>>
>>>> On 04/03/2023 17:07 EET Jeremy <mailinglist-subscripti...@protonmail.com>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Yeah, I just realized myself that what I did there was probably not the
>>>> smartest thing to do, as I indeed figured dovecot would probably just use
>>>> that as a plain text string. ;-) I've now opted to do the following (I'm
>>>> using PostgreSQL BTW):
>>>>
>>>> password_query = SELECT \
>>>> email as user, password, \
>>>> encode(digest('%w', 'sha256'), 'hex') AS
>>>> userdb_mail_crypt_private_password \
>>>> FROM virtual_users WHERE email='%u';
>>>>
>>>> Please advice if you think that this is more sensible.
>>>>
>>>> Also, could you give an overview of in which logs and/or other locations
>>>> these passwords might show up? I'd like to clean up after myself.
>>>>
>>>> Thanks in advance.
>>>>
>>>> ------- Original Message -------
>>>> On Saturday, March 4th, 2023 at 15:38, Aki Tuomi
>>>> <aki.tu...@open-xchange.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> just to mention this. If you use the stored password hash, it equals to
>>>>> using a plain text string. Depending on your threat model it might or not
>>>>> be an issue that admins have access to the password used to encrypt mails.
>>>>>
>>>>> Aki
>>>>>
>>>>>> On 04/03/2023 16:12 EET Jeremy
>>>>>> <mailinglist-subscripti...@protonmail.com> wrote:
>>>>>>
>>>>>> Hi again,
>>>>>>
>>>>>> I was able to solve both questions. I was overthinking things.
>>>>>>
>>>>>> A solution to the first question about mail_attribute_dict was simply to
>>>>>> use other available variables to point to the virtual user's maildir
>>>>>> paths. Like so: /var/mail/%d/%u/dovecot-attributes
>>>>>>
>>>>>> As for the second question:
>>>>>> When I asked it, I was uncertain if dovecot would be able to cope with a
>>>>>> hashed password for userdb_mail_crypt_private_password. I somehow
>>>>>> believed dovecot required a plain text password there, as per the '%w'
>>>>>> in the example password_query. Turns out this was not the case. Simply
>>>>>> providing the already hashed password of the password field did the
>>>>>> trick. So:
>>>>>>
>>>>>> password_query = SELECT \
>>>>>> email as user, password, \
>>>>>> password AS userdb_mail_crypt_private_password \
>>>>>> FROM virtual_users WHERE email='%u';
>>>>>>
>>>>>> Hope this is of help to others if they stumble upon this question.
>>>>>>
>>>>>> ------- Original Message -------
>>>>>> On Thursday, February 23rd, 2023 at 08:53, Jeremy
>>>>>> <mailinglist-subscripti...@protonmail.com> wrote:
>>>>>>
>>>>>>> Hi again,
>>>>>>>
>>>>>>> I am using dovecot 2.3.16, along with postfix and a PostgreSQL database
>>>>>>> for managing virtual accounts.
>>>>>>>
>>>>>>> After an initial topic from me about encrypting already existent mail,
>>>>>>> I could now use some pointers on how to set up the mail-crypt plugin
>>>>>>> for pure virtual accounts (i.e. that have no matching system users
>>>>>>> and/or home directories. I hope somebody can clarify a few things that
>>>>>>> are not entirely clear to me yet.
>>>>>>>
>>>>>>> After doing my own research, I believe the following should be possible:
>>>>>>>
>>>>>>> I'd like to use the password of virtual email accounts to let dovecot
>>>>>>> encrypt/decrypt the keys needed to encrypt/decrypt the mail in the
>>>>>>> relevant folders.
>>>>>>>
>>>>>>> As per the documentation @
>>>>>>> https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/ I
>>>>>>> believe this would be all the configuration I need:
>>>>>>>
>>>>>>> # Config
>>>>>>> mail_attribute_dict = file:%h/Maildir/dovecot-attributes
>>>>>>> mail_plugins = $mail_plugins mail_crypt
>>>>>>>
>>>>>>> plugin {
>>>>>>> mail_crypt_curve = secp521r1 # or some other preferred curve
>>>>>>> mail_crypt_save_version = 2
>>>>>>> mail_crypt_require_encrypted_user_key = yes # necessary for encrypting
>>>>>>> keys with user password
>>>>>>> }
>>>>>>>
>>>>>>> # File: /etc/dovecot/dovecot-sql.conf.ext
>>>>>>> password_query = SELECT \
>>>>>>> email as user, password, \
>>>>>>> '%w' AS userdb_mail_crypt_private_password \
>>>>>>> FROM virtual_users WHERE email='%u';
>>>>>>>
>>>>>>> My first question is:
>>>>>>> Is it possible to configure mail_attribute_dict in such a way as to not
>>>>>>> use home directories. Since I only use virtual accounts, without those
>>>>>>> accounts having home directories, can I somehow tell dovecot to save
>>>>>>> the attributes into the PostsreSQL database, for instance? If not, can
>>>>>>> you suggest another approach, without having to create home directories
>>>>>>> for virtual users?
>>>>>>>
>>>>>>> My second question is:
>>>>>>> The documentation warns about not using password directly in the above
>>>>>>> SQL query:
>>>>>>>
>>>>>>>> Choosing encryption key
>>>>>>>
>>>>>>>> DO NOT use password directly. It can contain % which is interpreted as
>>>>>>>> > variable expansion and can cause errors.
>>>>>>>
>>>>>>> Does this refer to not accidentally substituting '%w' with password? In
>>>>>>> other words, if I leave the above query as is, should I be good, even
>>>>>>> if plain text passwords of users potentially have % signs in them? Or
>>>>>>> would I need to take further measurements? (The passwords in my
>>>>>>> database are already hashed, by the way).
>>>>>>>
>>>>>>> I hope somebody can offer some guidance on this. Thanks.
>>>>>
>>>>> ---
>>>>> Aki Tuomi
>>>
>>> ---
>>> Aki Tuomi
>
> ---
> Aki Tuomi
