February 2019 - dovecot

flags not synced correctly with dovecot sync (dsync)
by Dan Christensen 31 Aug '19

31 Aug '19

I'm running dovecot 2.3.4.1 from https://repo.dovecot.org/ on Ubuntu 18.04 on three machines that I'll call server, laptop1 and laptop2. Both laptop1 and laptop2 run dovecot sync against server to keep local copies of my imap folders. Even when I initially had only two machines, laptop1 and server, I occasionally noticed that flags were lost, usually custom flags used by Gnus, but I couldn't reliably reproduce the problem. Now that I have two laptops syncing against the server, the problem has gotten worse and I figured out a way to reproduce it: - on server: create new IMAP folder test, and put two read messages in it - on laptop1: doveadm sync -u user -l 10 -m test -f user@server - on laptop2: doveadm sync -u user -l 10 -m test -f user@server At this point, all three machines show the two messages M1 and M2 as being read. - on laptop1: mark message M1 unread - on laptop2: mark message M2 unread - on laptop1: doveadm sync -u user -l 10 -m test -f user@server Both laptop1 and server have M1 unread, M2 read, as expected. - on laptop2: doveadm sync -u user -l 10 -m test -f user@server Now laptop2 and server have M1 *read*, M2 unread. - on laptop1: doveadm sync -u user -l 10 -m test -f user@server Now laptop1 and the server have both M1 and M2 *read*. - on laptop2: doveadm sync -u user -l 10 -m test -f user@server Now laptop2 has both read as well. The two lines that say "*read*" are wrong in my opinion. dsync propagated a read mark to an unread message, even though that message was marked unread more recently than it was marked read. I usually use stateful sync, and get many related problems. I just did a test in which M1 and M2 started out read, and I started with empty files named dstate.test on laptop1 and laptop2. Then I did the above procedure, using the command doveadm sync -u user -l 10 -m test -s "`cat dstate.test`" user@server > dstate.test At the end, laptop2 and server had both messages unread (which is good), but laptop1 had only M1 unread, and repeated runs of the sync command did not correct this. So the stateful sync failed to detect a change. Are these bugs in dovecot? Is there more information that I can provide? The output of doveconf -n on one machine is below, and the others are almost identical. Thanks for any help! Dan # 2.3.4.1 (3c0b8769e): /etc/dovecot/dovecot.conf # OS: Linux 4.15.0-45-generic x86_64 Ubuntu 18.04.1 LTS # Hostname: laptop2 auth_mechanisms = plain login listen = 127.0.0.1 mail_index_log2_max_age = 10 days mail_index_log_rotate_min_age = 1 days mail_index_log_rotate_min_size = 300 k mail_location = maildir:~/Maildir namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = } passdb { args = scheme=CRYPT username_format=%u /etc/dovecot/users driver = passwd-file } protocols = imap service imap-login { inet_listener imap { address = * port = 143 } inet_listener imaps { address = * port = 943 ssl = yes } } service imap { process_limit = 25 } ssl_cert = </etc/dovecot/private/dovecot.pem ssl_client_ca_dir = /etc/ssl/certs ssl_dh = # hidden, use -P to show it ssl_key = # hidden, use -P to show it userdb { args = username_format=%u /etc/dovecot/users driver = passwd-file } protocol lda { postmaster_address = [elided] } protocol imap { mail_max_userip_connections = 20 }

3 8

GSSAPI vs group check
by Németh Ákos Ferenc 05 Aug '19

05 Aug '19

Dear All, Is it possible to make any authorization (eg. checking of group membership) in case of GSSAPI authentication? Our dovecot authenticates the users against PAM and GSSAPI. In the PAM file I'm able to check if a user is a member of a selected (e.g mailreader) group. If the user is member, he can login otherwise not (see below). If the user has a valid Kerberos ticket and he tries to login via GSSAPI, I can't restrict him if he is not a member of the selected group. How can I overcome this issue? My config: passdb { driver = pam # [session=yes] [setcred=yes] [failure_show_msg=yes] [max_requests=<n>] # [cache_key=<key>] [<service name>] #args = dovecot } userdb { # <doc/wiki/AuthDatabase.Passwd.txt> driver = passwd # [blocking=no] #args = # Override fields from passwd #override_fields = home=/home/virtual/%u } ...in PAM file: auth [success=1 default=ignore] pam_succeed_if.so user ingroup mailreader auth [success=ignore default=2] pam_succeed_if.so user ingroup admins auth [success=ignore default=1] pam_succeed_if.so uid >= 1000 auth [success=3 default=ignore] pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login auth [success=ignore default=1] pam_succeed_if.so uid < 1000 auth [success=1 default=ignore] pam_unix.so nullok_secure try_first_pass auth requisite pam_deny.so auth required pam_permit.so Thank you. Br, Ákos

2 3

Bug with latest GCC 9
by Martin Liška 29 Jul '19

29 Jul '19

Hi. As mentioned here: https://bugzilla.opensuse.org/show_bug.cgi?id=1123136 there's a new issue with GCC 9, it's related to: https://gcc.gnu.org/gcc-9/porting_to.html#complit in: /* Not const! Never return this as a result directly! */ #define SMTP_ADDRESS_LITERAL(localpart, domain) \ &((struct smtp_address){ (localpart), (domain) }) Thanks, Martin

2 4

IMAP copy stopped copying flags
by Andrzej A. Filip 29 Jul '19

29 Jul '19

Is it intended behavior? It seems to be caused by upgrade to 1:2.3.2-2 on Debian/Testing. -- A. Filip

4 6

Re: Best mail encryption solution for per-user
by Aki Tuomi 12 Jul '19

12 Jul '19

On 27.05.2018 21:16, mail(a)sjemm.net wrote: > May 27, 2018 8:52 AM, "Aki Tuomi" <aki.tuomi(a)dovecot.fi> wrote: >>> On 26 May 2018 at 10:36 mail(a)sjemm.net wrote: >>> >>> May 23, 2018 10:10 AM, mail(a)sjemm.net wrote: >>> May 23, 2018 9:46 AM, "Aki Tuomi" <aki.tuomi(a)dovecot.fi> wrote: >>> >>> On 23.05.2018 10:15, mail(a)sjemm.net wrote: >>> >>> May 23, 2018 8:31 AM, "Aki Tuomi" <aki.tuomi(a)dovecot.fi> wrote: >>> >>> On 23.05.2018 09:13, mail(a)sjemm.net wrote: >>> May 20, 2018 8:01 PM, mail(a)sjemm.net wrote: >>> May 20, 2018 2:47 PM, "Aki Tuomi" <aki.tuomi(a)dovecot.fi> wrote: >>> On 19 May 2018 at 16:40 mail(a)sjemm.net wrote: >>> >>> May 18, 2018 10:01 PM, "Aki Tuomi" <aki.tuomi(a)dovecot.fi> wrote: >>> On 18 May 2018 at 21:44 mail(a)sjemm.net wrote: >>> >>> May 18, 2018 4:43 PM, "Aki Tuomi" <aki.tuomi(a)dovecot.fi> wrote: >>> On 18 May 2018 at 17:38 mail(a)sjemm.net wrote: >>> >>> May 18, 2018 4:05 PM, "Aki Tuomi" <aki.tuomi(a)dovecot.fi> wrote: >>> On 18 May 2018 at 16:43 mail(a)sjemm.net wrote: >>> >>> Hi Tai74 and Aki, >>> I followed your conversation with interest on how to setup per user encryption in dovecot. >>> I have setup my dovecot with the following in a conf file: >>> >>> ============== >>> >>> mail_attribute_dict = file:%h/Maildir/dovecot-attributes >>> mail_plugins = $mail_plugins mail_crypt >>> plugin { >>> >>> mail_crypt_curve = secp521r1 >>> >>> mail_crypt_save_version = 2 >>> >>> } >>> >>> ============== >>> >>> This works nice, all emails are being encrypted and every user/folder has keys. >>> But as I understood from your conversation these keys are not protected. And I want them to be >>> protected by the users password used by imap. >>> >>> Those passwords are stored in a mysql DB file. ( I used a guide from workaround [dot] org to set up >>> the DB and postfix/dovecot) >>> >>> but how would i set it so, that the users password from the DB is used to encrypt the keys? >>> >>> should i use mail_crypt_private_password = ? >>> how do i point it to the mysql db then? >>> im unsure about this >>> >>> Do you have any hints on this? >>> >>> Kind regards, >>> Zjemm >>> >>> The passwords in your MySQL database are, hopefully, not in plaintext. If you want to secure your >>> user's keys using user's login password, you must have a TOOL that manages this. >>> >>> You can use mail_crypt_private_password = %w in (mysql) passdb fields to provide the user's login >>> password as private password. You might want to run it thru some hash, so %{sha1:password} might be >>> a good option. >>> >>> You can change the key password using 'doveadm mailbox cryptokey', this needs to be done every time >>> user changes his password. >>> >>> Also note that if you go down this road, and the user forgets his password, you will not be able to >>> recover the emails without backup copy of the private key. >>> >>> Aki >>> >>> Hi Aki >>> >>> I used the following command: >>> dovecot pw -s SHA256-CRYPT >>> >>> the output on the chosen password looks like: {SHA256-CRYPT}$5$Rokc06a7In4SF3bO$OQpGQWqg........ >>> >>> This output is used to store in the password fields in the database. So no plain text passwords no >>> :) >>> >>> You can use mail_crypt_private_password = %w in (mysql) passdb fields to provide the user's login >>> password as private password. >>> >>> can you explain this a bit more for me? >>> >>> for now i have in the 10-auth.conf file the following: >>> ============== >>> passdb { >>> driver = sql >>> >>> # Path for SQL configuration file, see example-config/dovecot-sql.conf.ext >>> args = /etc/dovecot/dovecot-sql.conf.ext >>> } >>> >>> and: >>> >>> userdb { >>> driver = static >>> args = uid=vmail gid=vmail home=/var/vmail/%d/%n >>> } >>> ============== >>> >>> then i have in dovecot-sql.conf.ext >>> ============== >>> driver = mysql >>> connect = host=x.x.x.x dbname=mailserver user=mailuser password=mailpasswordexample >>> default_pass_scheme = SHA256-CRYPT >>> password_query = SELECT email as user, password FROM virtual_users WHERE email='%u'; >>> ============== >>> Where do i need to set : mail_crypt_private_password = %w ? >>> >>> password as private password. You might want to run it thru some hash, so %{sha1:password} might be >>> a good option. >>> >>> the passwords are allready hashed in the DB using: dovecot pw -s SHA256-CRYPT to genereate the has. >>> so this step isnt nesesary anymore am i right? >>> >>> Thank you for your quick response, very helpfull >>> >>> Zjemm >>> >>> You misunderstood a bit. The idea is to use the *plaintext* password as the password for the >>> private key. Otherwise anyone could just decrypt it by looking at your database where the hashed >>> password is.. >>> >>> So: >>> >>> password_query = SELECT email as user, password, '%w' AS userdb_mail_crypt_private_password FROM >>> virtual_users WHERE email='%u' >>> >>> Aki >>> >>> Hi Aki, >>> >>> Thank you very much for your help, i realy appreciate that. >>> >>> Ok so if i understand it correctly i'll have to use: >>> >>> password_query = SELECT email as user, password, '%w' AS userdb_mail_crypt_private_password FROM >>> virtual_users WHERE email='%u' >>> >>> in my dovecot-sql.conf.ext file >>> >>> This query selects the user, the password, and %w >>> >>> if i run a little query myself: >>> MariaDB [mailserver]> SELECT email as user, password, '%w' AS userdb_mail_crypt_private_password >>> FROM virtual_users; >>> +------------------+----------------------------------+------------------------------------+ >>> | user | password | userdb_mail_crypt_private_password | >>> +------------------+----------------------------------+------------------------------------+ >>> | john(a)example.org | {SHA256-CRYPT}$5$M/GWzmtjsLroRWI | %w | >>> +------------------+----------------------------------+------------------------------------+ >>> >>> %w is a dovecot variable, and stands for the plaintext password, but the password is not stored as >>> plaintext in the DB, %w get filled with the actual plaintext password by dovecot upon the user that >>> is typing in the password when authenticating. >>> >>> is this correct? >>> >>> yes. >>> >>> so then i have the username the hashed password en the plaintext password as a result of the query. >>> >>> yes >>> >>> now userdb_mail_crypt_private_password = the plaintext password >>> do i need to reference it somewhere? or is userdb_mail_crypt_private_password autmatically used by >>> the dovecot mail_crypt plugin to encrypt the keys? or should it be mail_crypt_private_password? >>> >>> It gets injected into the mail process as 'mail_crypt_private_password', as if it was set in plugin >>> {} section. >>> >>> if i have this setup working i'm going to write a blog post on this topic to share this knowledge >>> >>> Thanks again and have a great weekend. >>> >>> Zjemm >>> >>> Aki >>> >>> Hi Aki, >>> >>> Cool i'm testing it right now. >>> I have set up a new mailserver (life is great with lxc containers :) ) >>> >>> postfix and dovecot are working like normal >>> >>> next i enable mail_crypt >>> >>> i did create a file: /etc/dovecot/conf.d/10-mailcrypt.conf >>> ========================== >>> mail_attribute_dict = file:%h/Maildir/dovecot-attributes >>> >>> mail_plugins = $mail_plugins mail_crypt >>> >>> plugin { >>> mail_crypt_curve = secp521r1 >>> mail_crypt_save_version = 2 >>> } >>> ========================== >>> >>> and then i changed the file: /etc/dovecot/dovecot-sql.conf.ext >>> >>> so the query is now the new query: >>> password_query = SELECT email as user, password, '%w' AS userdb_mail_crypt_private_password FROM >>> virtual_users WHERE email='%u'; >>> >>> then i restarted dovecot and postfix and send a test email to the one and only testuser that is in >>> there. >>> >>> when i open the mailbox with the tool mutt, i can see the new email, and when openening the email >>> the mutt client drops the connection. >>> >>> in the log i can see: >>> >>> May 19 13:34:48 mailserver1.example.local dovecot[600]: imap-login: Login: user=<john(a)example.org>, >>> method=PLAIN, rip=::1, lip=::1, mpid=713, TLS, session=<E3PnIY9sNM4AAAAAAAAAAAAAAAAAAAAB> >>> May 19 13:34:49 mailserver1.example.local dovecot[600]: imap(john(a)example.org): Error: read() >>> failed: >>> read(/var/vmail/example.org/john/Maildir/cur/1526736378.M161472P641.mailser…, >>> =571:2,) failed: Private key not available: Cannot decrypt key >>> bfc5bb25b1bf64290eea6dc14b516c6a0a25b64551b6e4f0f8677ba7274887cb: error:03070068:bignum >>> routines:BN_mpi2bn:encoding error (FETCH BODY[] for mailbox INBOX UID 8) >>> >>> i think i missed a step, but witch one? >>> >>> the userpassword hasnt been changed (that would be the next step in the testing process) >>> >>> should i've use doveadm first to encrypt the key with that userpassword? i thought it would do that >>> on the fly, because the initial keys where only just created when enabling the mail_crypt plugin >>> >>> please let me know your thougts >>> Zjemm >>> I noticed you replied directly to me, and not to the list, too... fixed that for you. >>> >>> mail_crypt_private_password is used when key is created, but if you have created it before using >>> password, you'll need to encrypt it before turning the setting on. >>> >>> Aki >>> Hi, Ok i'm sorry about that, thank you for fixing that. i'm a bit new to mailing lists :) >>> >>> are you a dovecot devoloper? or a enthusiastic user? >>> >>> anyway, i managed to get it working now with all your help :) >>> >>> to start fresh i did a: >>> rm -rf /var/vmail/example.org >>> >>> so all email is gone, and i assume all dovecot keys are gone that way. >>> >>> Then i tried to set a password first: >>> >>> root@mailserver1:/var/vmail# doveadm mailbox cryptokey password -u john(a)example.org -n summersun >>> result: Changed password for 0 key(s) >>> >>> (summersun = the password for this user) >>> >>> but then it says there are 0 keys, so then i send the test user an email and try to open the >>> mailbox, i'll get: >>> >>> imap(john(a)example.org): Error: read() failed: >>> read(/var/vmail/example.org/john/Maildir/cur/1526827992.M149712P883.mailser…, >>> =561:2,) failed: Private key not available: Cannot decrypt key >>> 71849013a70b0c631c06112077e7c2fe39b0b2737b4933b219793841209d4e7f: error:03070068:bignum >>> routines:BN_mpi2bn:encoding error >>> >>> but hey, now the key's are created, so i tried to set the password again: >>> >>> root@mailserver1:/var/vmail# doveadm mailbox cryptokey password -u john(a)example.org -n summersun >>> result: dcrypt_key_load_private(787701bd677dd69a26842547a3926cbaa625b0b5a91751f06678c3e9708343d9) >>> failed: password missing >>> ========= >>> >>> Lets start over again, i did a new: >>> rm -rf /var/vmail/example.org >>> >>> i disabled the mail_crypt_private_password in the sql query and send an email to the test user. >>> now again new keys are generated. >>> >>> then i did set the password via doveadm: >>> >>> root@mailserver1:/var/vmail# doveadm mailbox cryptokey password -u john(a)example.org -n summersun >>> result: Changed password for 1 key(s) >>> >>> i enabled the mail_crypt_private_password again in the sql query part and now it works :) >>> >>> YESSS!!! >>> >>> if i now change the password for the user, i cannot read the email anymore. that is what should >>> happen. >>> so now i changed the password for this user also with doveadm: >>> - doveadm mailbox cryptokey password -u john(a)example.org -n qwerty -o summersun >>> >>> and now i'm able to read the emails again. so it all works now as expected. >>> >>> i have now only one thing remaining. >>> >>> when i want to add a new user, i have to somehow: >>> - create the new user in the mysql DB >>> - start with dovecot not using mail_crypt_private_password (so disabled) >>> - send an initial email to let the users mailbox be created and generate the keys >>> - set the users password with doveadm >>> - restart dovecot again with mail_crypt_private_password (so enabled) >>> >>> but this would be disruptive to existing users, and i would have to script the whole thing as a >>> "add-new-user" script to make it usable i guess. >>> >>> do you know of a more easy way of acomplishing this? >>> could i use doveadm for all steps, and get around the mail_crypt_private_password disable part? >>> >>> or could i add a column in the mysql db called userdb_mail_crypt_private_password and fill that >>> column with %w for users that allready exist, and empty for new users. >>> when being empty, it might not set the mail_crypt_private_password for new users >>> >>> or is this the wrong way of thinking? >>> >>> let me know your thoughts on this. >>> >>> And last but not least, i really want to thank you for all your help. It is a really nice >>> experience. >>> Bless you! >>> >>> Zjemm >>> Hi Aki, >>> >>> You did fix the posting on the mail archive, i can see our conversation on there, all but the last >>> email i send to you. >>> Maybe you did not received the last email? >>> >>> would you be willing to take a look at my last question in the email See below: >>> Thank you very much. >>> >>> ================================ >>> i have now only one thing remaining. >>> >>> when i want to add a new user, i have to somehow: >>> - create the new user in the mysql DB >>> - start with dovecot not using mail_crypt_private_password (so disabled) >>> - send an initial email to let the users mailbox be created and generate the keys >>> - set the users password with doveadm >>> - restart dovecot again with mail_crypt_private_password (so enabled) >>> >>> but this would be disruptive to existing users, and i would have to script the whole thing as a >>> "add-new-user" script to make it usable i guess. >>> >>> do you know of a more easy way of acomplishing this? >>> could i use doveadm for all steps, and get around the mail_crypt_private_password disable part? >>> >>> or could i add a column in the mysql db called userdb_mail_crypt_private_password and fill that >>> column with %w for users that allready exist, and empty for new users. >>> when being empty, it might not set the mail_crypt_private_password for new users >>> >>> or is this the wrong way of thinking? >>> >>> let me know your thoughts on this. >>> >>> And last but not least, i really want to thank you for all your help. It is a really nice >>> experience. >>> Bless you! >>> >>> Zjemm >>> >>> If you have mail_crypt_private_password set *when* keys are generated, >>> dovecot should use that password to encrypt the user key. >>> >>> Aki >>> Hi Aki, >>> >>> well, if there is a new email user setup in the mysql DB, and no email has been send to that new >>> user. at that point there are no keys. >>> >>> So trying to set a password on those key's wont work. see: >>> root@mailserver1:/var/vmail/example.org# doveadm mailbox cryptokey password -u john2(a)example.org -n >>> qwerty >>> result: Changed password for 0 key(s) >>> >>> the keys need to be generated first. And that only happens when sending a mail to that new user. >>> Also, at the point of creating the keys, the mail_crypt_private_password should be disabled >>> otherwise the keys are generated and also encrypted with no user password, and then im unable to >>> set a new pasword for that key >>> >>> How can i set the password before the keys are generated? >>> or can i manually generate key's and then set the password? >>> >>> so at this point i have to do the following: >>> >>> You can use doveadm mailbox cryptokey generate -u user -U >>> >>> to generate a user key. >>> >>> Aki >>> >>> - create the new user in the mysql DB >>> - start with dovecot not using mail_crypt_private_password (so disabled) >>> - send an initial email to let the users mailbox be created and generate the keys >>> - set the users password with doveadm >>> - restart dovecot again with mail_crypt_private_password (so enabled) >>> can i somehow enable the mail_crypt_private_password per user? >>> because this mysql query always returns: %w >>> and thus allways sets: userdb_mail_crypt_private_password >>> SELECT email as user, password, '%w' AS userdb_mail_crypt_private_password FROM virtual_users; >>> >>> Hi Aki, >>> >>> You are correct >>> >>> doveadm mailbox cryptokey generate -u user -U generates the keys, but i have to first remove: >>> '%w' AS userdb_mail_crypt_private_password >>> from dovecot configuration and restart dovecot. >>> >>> if i don't do that, the keys are generated, but also somehow encrypted using: no >>> password/empty/something else (i don't know) >>> >>> here you can see that happening: >>> >>> root@mailserver1:/var/vmail/example.org# doveadm mailbox cryptokey generate -u john2(a)example.org -U >>> Folder Public ID >>> ✓ <userkey> 53004acf9886f887ca081c83d7392a5aa3fac4b5a20ce013db91a341fb4644c4 >>> root@mailserver1:/var/vmail/example.org# doveadm mailbox cryptokey password -u john2(a)example.org -n >>> qwerty >>> result: dcrypt_key_load_private(53004acf9886f887ca081c83d7392a5aa3fac4b5a20ce013db91a341fb4644c4) >>> failed: password missing >>> >>> it expects an old password wich is never set in my opinion. >>> >>> so the last part of this setup would be to figure out a way to disable '%w' AS >>> userdb_mail_crypt_private_password for new users without manually removing that part from the query >>> and restarting dovecot. As that would mean connection interruption while adding new users >>> >>> if we could add new users to the DB and somehow not give '%w' AS userdb_mail_crypt_private_password >>> for that new user in the query, we can add the password afterward, and then enable '%w' AS >>> userdb_mail_crypt_private_password in the query for this user >>> >>> could we add a column in the user db lets say called: encrypted (yes/no) >>> >>> and then change the existing query: SELECT email as user, password, '%w' AS >>> userdb_mail_crypt_private_password FROM virtual_users; >>> >>> to firrt check if encryption is set to 'yes', if so retrun: >>> SELECT email as user, password, '%w' AS userdb_mail_crypt_private_password FROM virtual_users; >>> >>> if not return: >>> SELECT email as user, password FROM virtual_users; >>> >>> but then in one mysql query so dovecot can work with it >>> >>> ? >>> >>> Hi Aki, >>> >>> would you be willing to respond to my last question i had send to you last week? >>> its this one: >>> ================================== >>> doveadm mailbox cryptokey generate -u user -U generates the keys, but i have to first remove: >>> '%w' AS userdb_mail_crypt_private_password >>> from dovecot configuration and restart dovecot. >>> >>> if i don't do that, the keys are generated, but also somehow encrypted using: no >>> password/empty/something else (i don't know) >>> >>> here you can see that happening: >>> >>> root@mailserver1:/var/vmail/example.org# doveadm mailbox cryptokey generate -u john2(a)example.org -U >>> Folder Public ID >>> ✓ <userkey> 53004acf9886f887ca081c83d7392a5aa3fac4b5a20ce013db91a341fb4644c4 >>> root@mailserver1:/var/vmail/example.org# doveadm mailbox cryptokey password -u john2(a)example.org -n >>> qwerty >>> result: dcrypt_key_load_private(53004acf9886f887ca081c83d7392a5aa3fac4b5a20ce013db91a341fb4644c4) >>> failed: password missing >>> >>> it expects an old password wich is never set in my opinion. >>> >>> could this be a bug? or am i doing it wrong? if needed i could send in a bug report? >>> >>> or might we need to enable the userdb_mail_crypt_private_password "per user" ? >>> >>> so the last part of this setup would be to figure out a way to disable '%w' AS >>> userdb_mail_crypt_private_password for new users without manually removing that part from the query >>> and restarting dovecot. As that would mean connection interruption while adding new users >>> >>> if we could add new users to the DB and somehow not give '%w' AS userdb_mail_crypt_private_password >>> for that new user in the query, we can add the password afterward, and then enable '%w' AS >>> userdb_mail_crypt_private_password in the query for this user >>> >>> could we add a column in the user db lets say called: encrypted (yes/no) >>> >>> and then change the existing query: SELECT email as user, password, '%w' AS >>> userdb_mail_crypt_private_password FROM virtual_users; >>> >>> to firrt check if encryption is set to 'yes', if so retrun: >>> SELECT email as user, password, '%w' AS userdb_mail_crypt_private_password FROM virtual_users; >>> >>> if not return: >>> SELECT email as user, password FROM virtual_users; >>> >>> but then in one mysql query so dovecot can work with it >>> >>> Please let me know your thougts, after this last thing im done :) >>> also let me know if i can support this project in some way, im willing to contribute >>> >>> Zjemm >> You can select it as userdb_mail_crypt_save_version=0 to disable encryption (it won't disable >> decryption). You can use value '2' for enabling encryption. DO NOT USE 1. >> >> Also I tried the SQL based thing, and if you had EMPTY mail_crypt_private_password, try these to >> change the password. If the one that works is the second one, let me know =) >> >> doveadm mailbox cryptokey password -u testuser -nnewpass -o "" >> >> doveadm mailbox cryptokey password -u testuser -nnewpass -o "yes" >> >> Aki > Hi Aki, > > Thanks for replying > > So if i understand you correctly i could enable encryption per user by using: userdb_mail_crypt_save_version= in the database as an extra column. the column would be called "userdb_mail_crypt_save_version" and the value is "0" or "2" > > if a user has: userdb_mail_crypt_save_version=0, encryption is disabled for that user > if a user has: userdb_mail_crypt_save_version=2, encryption is enabled for that user > > would this also override the setting: mail_crypt_save_version = 2 > in the mailcryp.conf file where that is a global setting? or should i delete it there and only use userdb_mail_crypt_save_version= from the database? > > for the password set command i hve testest some things: > > new user with no keys yet: > doveadm -o plugin/mail_crypt_private_password=password mailbox cryptokey generate -u john2(a)example.org -U > > i can set a password with: > new password: > doveadm mailbox cryptokey password -u john2(a)example.org -n newpass -o password > > > if i do not use new user doveadm: (doveadm -o plugin/mail_crypt_private_password=password mailbox cryptokey generate -u john2(a)example.org -U) > then use this: > doveadm mailbox cryptokey password -u john2(a)example.org -n newpass -o "yes" > > > so yes it is the second one > > Kind regards, > > Zjemm It's unfortunate problem with 2.2 that it defaults empty userdb variables into yes. This has been remedied in 2.3. Unfortunately there is no clean fix to this, they all resort to various levels of trickery. Variables set in passdb/userdb overwrite the ones in plugin {} section. Aki

2 2

Dovecot 2.3.0 TLS
by Hauke Fath 07 Jul '19

07 Jul '19

All, our dovecot installation provides a bundle of intermedia CA certificates using the ssl_ca option. 2.3.0 does not supply the bundle, resulting in various clients either complaining about an unverifiable server cert, or quietly not connecting. The log has Jan 5 17:01:46 Bounce dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=XXX, lip=YYY, TLS handshaking: SSL_accept() failed: error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown: SSL alert number 46, session=<uKK/kAlia+GCUyU5> We fixed the issue by downgrading to 2.2.33.2. Cheerio, hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344

11 22

JMAP support in Dovecot
by Andrew Jones 29 May '19

29 May '19

Hi there, I understand there were discussions to try and develop JMAP support for Dovecot. Is this still in the pipeline for Dovecot 2.5? Regards Andrew Sent from my iPhone

10 18

Automatically subscribe to the INBOX folder
by glts 26 May '19

26 May '19

Hello, I am using the ‘auto = subscribe’ feature in the mailbox configuration section in the usual fashion (as shown in conf.d/15-mailboxes.conf): namespace inbox { inbox = yes mailbox Drafts { special_use = \Drafts auto = subscribe } ... } When I connect to an account with the Thunderbird mail client, those mailboxes/folders get autocreated and autosubscribed. Good! INBOX, however, does not get subscribed to automatically. When I look at the account’s subscriptions in Thunderbird, all folders are subscribed, except INBOX. How can I enable autosubscribe for the INBOX folder (like the other folders)? Is there an option for this? This is in Dovecot 2.2.22. Cheers, David

2 1

[Dovecot] Dovecot LDA/LMTP vs postfix virtual delivery agent and the x-original-to header
by Charles Marcus 19 Apr '19

19 Apr '19

On 2012-04-05 4:18 AM, Thomas Leuxner <tlx(a)leuxner.net> wrote: > Also with 2.x you may want to use LMTP rather than the LDA Piping. > > http://wiki2.dovecot.org/HowTo/PostfixDovecotLMTP I am preparing to convert my main client's postfix_courier-imap setup to dovecot 2.1, which currently just uses the postfix virtual delivery agent... Does anyone know if the use of LMTP (or even the dovecot LDA) still loses the x-original-to header that the postfix vda adds and that I rely heavily on (since I use a lot of aliases), and if it does, is there any solution to get the original recipient added back in before final delivery? Everything I'm reading says that LMTP is better, but I really do need this header (or one like it) to be there so I know who the original recipient was (for filtering and other purposes). Thanks, -- Best regards, Charles

8 16

Regression ACL & namespace prefix
by Michal Hlavinka 28 Mar '19

28 Mar '19

Hi tl;dr: Seems that for Global ACL directory, namespace prefix is not part of the path, when looking for acl file. Long version: We're planning to update dovecot in next os update to 2.2.36 and while going through regression testing, we found a problem with ACL configuration combined with namespace. Test uses "Global ACL directory" configuration. Relevant configuration part: mail_location = maildir:~/Maildir namespace inbox { hidden = no inbox = yes list = yes location = prefix = separator = / } namespace { hidden = no list = yes location = maildir:/var/mail/pub prefix = pub/ separator = / type = public } mail_plugins = acl protocol imap { mail_plugins = $mail_plugins acl imap_acl } plugin { acl = vfile:/etc/dovecot/global-acls } ACL config file is stored at: /etc/dovecot/global-acls/pub/.DEFAULT when trying to examine "pub", it is denied: fetchmail: IMAP> A0005 EXAMINE "pub" fetchmail: IMAP< A0005 NO Mailbox doesn't exist: pub (0.001 + 0.000 secs). # doveadm acl debug -u d2 pub doveadm(d2): Info: Mailbox '' is in namespace 'pub/' doveadm(d2): Info: Mailbox path: /var/mail/pub doveadm(d2): Info: All message flags are shared across users in mailbox doveadm(d2): Info: User d2 has no rights for mailbox doveadm(d2): Error: User d2 is missing 'lookup' right doveadm(d2): Info: Mailbox pub is NOT visible in LIST because it did not find acl file: imap(d2): Debug: Namespace : type=public, prefix=pub/, sep=/, inbox=no, hidden=no, list=yes, subscriptions=yes location=maildir:/var/mail/pub imap(d2): Debug: maildir++: root=/var/mail/pub, index=, indexpvt=, control=, inbox=, alt= imap(d2): Debug: acl: initializing backend with data: vfile:/etc/dovecot/global-acls imap(d2): Debug: acl: acl username = d2 imap(d2): Debug: acl: owner = 0 imap(d2): Debug: acl vfile: Global ACL legacy directory: /etc/dovecot/global-acls imap(d2): Debug: pub: Mailbox opened because: EXAMINE imap(d2): Debug: acl vfile: file /etc/dovecot/global-acls//.DEFAULT not found imap(d2): Debug: acl vfile: file /var/mail/pub/dovecot-acl not found see it's looking for: /etc/dovecot/global-acls//.DEFAULT instead of /etc/dovecot/global-acls/pub/.DEFAULT Checking with documentation https://wiki.dovecot.org/ACL it seems that prefix should still be part of the path, as it was before: """The filenames must start with namespace prefix (if it has one). For example with namespace prefix=INBOX/ containing mailbox "foo" use /etc/dovecot/acls/INBOX/foo.""" Just for comparison, previous version (2.2.10) would work fine: imap(d2): Debug: Namespace : type=public, prefix=pub/, sep=/, inbox=no, hidden=no, list=yes, subscriptions=yes location=maildir:/var/mail/pub imap(d2): Debug: maildir++: root=/var/mail/pub, index=, indexpvt=, control=, inbox=, alt= imap(d2): Debug: acl: initializing backend with data: vfile:/etc/dovecot/global-acls imap(d2): Debug: acl: acl username = d2 imap(d2): Debug: acl: owner = 0 imap(d2): Debug: acl vfile: Global ACL directory: /etc/dovecot/global-acls imap(d2): Debug: acl vfile: reading file /etc/dovecot/global-acls/pub/.DEFAULT imap(d2): Debug: acl vfile: file /var/mail/pub/dovecot-acl not found I've localized problem to: src/plugins/acl/acl-backend-vfile.c: acl_backend_vfile_object_init(...) and change from: vname = mailbox_list_get_vname(_backend->list, name); to: vname = *name == '\0' ? "" : mailbox_list_get_vname(_backend->list, name); that happened quite time ago during bigger acl changes and I don't know why exactly this line was changed previously. Anyway, reverting this line alone fixes the problem and while testing both per-mailbox ACL vfile and Global ACL file, reverting this did not affect them.

3 7