January 2021 - dovecot

2.3.13: newly introduced TLS bug : tls_construct_server_key_exchange
by Marius Schwarz 08 Jan '21

08 Jan '21

Hi, since the update from 2.3.11 to 2.3.13 some clients generate this bug : TLS handshaking: SSL_accept() failed: error:141EC044:SSL routines:tls_construct_server_key_exchange:internal error As it looks for now, they use the old SSL approach on Ports 993 and 995. SSL Config says: ssl = yes ssl_cert = </etc/pki/tls/certs/exim.pem ( Lets Encrypt R3 based cert ) ssl_key = </etc/pki/tls/private/exim.pem ssl_dh_parameters_length = 2048 ssl_dh= </etc/dovecot/dh.pem ssl_cipher_list = PROFILE=SYSTEM OS: Fedora 32 X86_64 Ext4 file storage on local disks Versions: dovecot-2.3.13-1.fc32.x86_64 openssl-1.1.1i-1.fc32.x86_64 best regards, Marius Schwarz

2 2

Re: problem building on centos 8 (8.3 kernel)
by steve＠keptprivate.com 07 Jan '21

07 Jan '21

Another thought... Could I use a different build mechanism that would result in the same installation rpm? There's no reason I have to use source rpms, I'm just used to it because of qmailtoaster.SteveSent from my T-Mobile 4G LTE device------ Original message------From: steve(a)keptprivate.comDate: Thu, Jan 7, 2021 3:48 PMTo: Aki Tuomi;dovecot(a)dovecot.org;Cc: Subject:Re: problem building on centos 8 (8.3 kernel) Any ideas about the lsb_release error in the spec file and where that came from? I have a very vanilla centos 8 install I'm trying to bulid on. Any thoughts appreciated because I'm stuck and at something of a loss on what to try next. My first thought is to look at spec file revisions.SteveSent from my T-Mobile 4G LTE device------ Original message------From: Aki TuomiDate: Thu, Jan 7, 2021 3:10 AMTo: steve@keptprivate.com;dovecot@dovecot.org;Cc: Subject:Re: problem building on centos 8 (8.3 kernel)> On 07/01/2021 03:57 steve(a)keptprivate.com wrote: > > > Hi, > > I'm converting from qmailtoaster/vpopmail build. > When I try to build dovecot-2.3.13-2.src.rpm for centos 8.3 the first thing I run into is this: > > + sed -i 's|/etc/ssl|/etc/pki/dovecot|' doc/mkcert.sh doc/example-config/conf.d/10-ssl.conf > + '[' -e buildinfo.commit ']' > ++ head -1 buildinfo.commit > + COMMIT=89f716dc2ec7362864a368d32533184b55fb7831 > ++ /bin/sh /home/build/rpmbuild/SOURCES/lsb_release -is > /bin/sh: /home/build/rpmbuild/SOURCES/lsb_release: No such file or directory > + ID= > error: Bad exit status from /var/tmp/rpm-tmp.WFaLYQ (%build) > > > RPM build errors: > Macro expanded in comment on line 455: %{_libdir}/dovecot/settings > > Bad exit status from /var/tmp/rpm-tmp.WFaLYQ (%build) > > I can get past this with an edit to the dovecot.spec file (removing sourcedir): > > if [ -e "buildinfo.commit" ]; then > COMMIT=`head -1 buildinfo.commit` > ID=`/bin/sh %̶{̶_̶s̶o̶u̶r̶c̶e̶d̶i̶r̶}̶/̶lsb_release -is` > RELEASE=`/bin/sh %̶{̶_̶s̶o̶u̶r̶c̶e̶d̶i̶r̶}̶/̶lsb_release -rs` > CODENAME=`/bin/sh %̶{̶_̶s̶o̶u̶r̶c̶e̶d̶i̶r̶}̶/̶lsb_release -cs` > ARCH=`arch` > fi > > The RPM builds but it fails to run with this message in the logs: > > Jan 6 20:52:11 beta1 systemd[1]: Starting Dovecot IMAP/POP3 email server... > Jan 6 20:52:11 beta1 systemd[1]: Started Dovecot IMAP/POP3 email server. > Jan 6 20:52:11 beta1 dovecot[356909]: /usr/sbin/dovecot: error while loading shared libraries: libdovecot.so.0: cannot open shared object > file: No such file or directory > Jan 6 20:52:11 beta1 systemd[1]: dovecot.service: Main process exited, code=exited, status=127/n/a > Jan 6 20:52:11 beta1 systemd[1]: dovecot.service: Failed with result 'exit-code'. > > Any ideas what I have going wrong? > > Also, a side question, when I build the rpm it's not running the extensive tests that the old qmailtoaster source rpm used to run. I've > looked through the spec file and I don't really see where to turn that back on. > > Sorry if any of this is stupid, but I'm new to building directly from the dovecot repo. > > Steve I think the file is installed under /usr/lib64/, so check ldd /usr/lib64/libdovecot.so.0 Is there some reason you are building the rpms yourself? Aki

1 0

Re: problem building on centos 8 (8.3 kernel)
by steve＠keptprivate.com 07 Jan '21

07 Jan '21

Any ideas about the lsb_release error in the spec file and where that came from? I have a very vanilla centos 8 install I'm trying to bulid on. Any thoughts appreciated because I'm stuck and at something of a loss on what to try next. My first thought is to look at spec file revisions.SteveSent from my T-Mobile 4G LTE device------ Original message------From: Aki TuomiDate: Thu, Jan 7, 2021 3:10 AMTo: steve@keptprivate.com;dovecot@dovecot.org;Cc: Subject:Re: problem building on centos 8 (8.3 kernel)> On 07/01/2021 03:57 steve(a)keptprivate.com wrote: > > > Hi, > > I'm converting from qmailtoaster/vpopmail build. > When I try to build dovecot-2.3.13-2.src.rpm for centos 8.3 the first thing I run into is this: > > + sed -i 's|/etc/ssl|/etc/pki/dovecot|' doc/mkcert.sh doc/example-config/conf.d/10-ssl.conf > + '[' -e buildinfo.commit ']' > ++ head -1 buildinfo.commit > + COMMIT=89f716dc2ec7362864a368d32533184b55fb7831 > ++ /bin/sh /home/build/rpmbuild/SOURCES/lsb_release -is > /bin/sh: /home/build/rpmbuild/SOURCES/lsb_release: No such file or directory > + ID= > error: Bad exit status from /var/tmp/rpm-tmp.WFaLYQ (%build) > > > RPM build errors: > Macro expanded in comment on line 455: %{_libdir}/dovecot/settings > > Bad exit status from /var/tmp/rpm-tmp.WFaLYQ (%build) > > I can get past this with an edit to the dovecot.spec file (removing sourcedir): > > if [ -e "buildinfo.commit" ]; then > COMMIT=`head -1 buildinfo.commit` > ID=`/bin/sh %̶{̶_̶s̶o̶u̶r̶c̶e̶d̶i̶r̶}̶/̶lsb_release -is` > RELEASE=`/bin/sh %̶{̶_̶s̶o̶u̶r̶c̶e̶d̶i̶r̶}̶/̶lsb_release -rs` > CODENAME=`/bin/sh %̶{̶_̶s̶o̶u̶r̶c̶e̶d̶i̶r̶}̶/̶lsb_release -cs` > ARCH=`arch` > fi > > The RPM builds but it fails to run with this message in the logs: > > Jan 6 20:52:11 beta1 systemd[1]: Starting Dovecot IMAP/POP3 email server... > Jan 6 20:52:11 beta1 systemd[1]: Started Dovecot IMAP/POP3 email server. > Jan 6 20:52:11 beta1 dovecot[356909]: /usr/sbin/dovecot: error while loading shared libraries: libdovecot.so.0: cannot open shared object > file: No such file or directory > Jan 6 20:52:11 beta1 systemd[1]: dovecot.service: Main process exited, code=exited, status=127/n/a > Jan 6 20:52:11 beta1 systemd[1]: dovecot.service: Failed with result 'exit-code'. > > Any ideas what I have going wrong? > > Also, a side question, when I build the rpm it's not running the extensive tests that the old qmailtoaster source rpm used to run. I've > looked through the spec file and I don't really see where to turn that back on. > > Sorry if any of this is stupid, but I'm new to building directly from the dovecot repo. > > Steve I think the file is installed under /usr/lib64/, so check ldd /usr/lib64/libdovecot.so.0 Is there some reason you are building the rpms yourself? Aki

1 0

Re: problem building on centos 8 (8.3 kernel)
by steve＠keptprivate.com 07 Jan '21

07 Jan '21

Hi,Yes, a whole subdir "dovecot" in /usr/lib64 with files. The actual so.0 file is a link to an so.0.0.0 file.I was able to successfully build test run the source rpm from qmailtoaster 2.3.11.I'm building from source because I have a patch I want to apply. My suspicion is the problem is config. related given the odd lsb_release issue that happens right at the start of the build.I've tried to review the spec files for differences, qmailtoaster 2.3.11 vs 2.3.13 but the differences are significant.SteveSent from my T-Mobile 4G LTE device------ Original message------From: Aki TuomiDate: Thu, Jan 7, 2021 3:10 AMTo: steve@keptprivate.com;dovecot@dovecot.org;Cc: Subject:Re: problem building on centos 8 (8.3 kernel)> On 07/01/2021 03:57 steve(a)keptprivate.com wrote: > > > Hi, > > I'm converting from qmailtoaster/vpopmail build. > When I try to build dovecot-2.3.13-2.src.rpm for centos 8.3 the first thing I run into is this: > > + sed -i 's|/etc/ssl|/etc/pki/dovecot|' doc/mkcert.sh doc/example-config/conf.d/10-ssl.conf > + '[' -e buildinfo.commit ']' > ++ head -1 buildinfo.commit > + COMMIT=89f716dc2ec7362864a368d32533184b55fb7831 > ++ /bin/sh /home/build/rpmbuild/SOURCES/lsb_release -is > /bin/sh: /home/build/rpmbuild/SOURCES/lsb_release: No such file or directory > + ID= > error: Bad exit status from /var/tmp/rpm-tmp.WFaLYQ (%build) > > > RPM build errors: > Macro expanded in comment on line 455: %{_libdir}/dovecot/settings > > Bad exit status from /var/tmp/rpm-tmp.WFaLYQ (%build) > > I can get past this with an edit to the dovecot.spec file (removing sourcedir): > > if [ -e "buildinfo.commit" ]; then > COMMIT=`head -1 buildinfo.commit` > ID=`/bin/sh %̶{̶_̶s̶o̶u̶r̶c̶e̶d̶i̶r̶}̶/̶lsb_release -is` > RELEASE=`/bin/sh %̶{̶_̶s̶o̶u̶r̶c̶e̶d̶i̶r̶}̶/̶lsb_release -rs` > CODENAME=`/bin/sh %̶{̶_̶s̶o̶u̶r̶c̶e̶d̶i̶r̶}̶/̶lsb_release -cs` > ARCH=`arch` > fi > > The RPM builds but it fails to run with this message in the logs: > > Jan 6 20:52:11 beta1 systemd[1]: Starting Dovecot IMAP/POP3 email server... > Jan 6 20:52:11 beta1 systemd[1]: Started Dovecot IMAP/POP3 email server. > Jan 6 20:52:11 beta1 dovecot[356909]: /usr/sbin/dovecot: error while loading shared libraries: libdovecot.so.0: cannot open shared object > file: No such file or directory > Jan 6 20:52:11 beta1 systemd[1]: dovecot.service: Main process exited, code=exited, status=127/n/a > Jan 6 20:52:11 beta1 systemd[1]: dovecot.service: Failed with result 'exit-code'. > > Any ideas what I have going wrong? > > Also, a side question, when I build the rpm it's not running the extensive tests that the old qmailtoaster source rpm used to run. I've > looked through the spec file and I don't really see where to turn that back on. > > Sorry if any of this is stupid, but I'm new to building directly from the dovecot repo. > > Steve I think the file is installed under /usr/lib64/, so check ldd /usr/lib64/libdovecot.so.0 Is there some reason you are building the rpms yourself? Aki

1 0

Server searches not working for 1 user only
by Ignacio García 07 Jan '21

07 Jan '21

Hi there I'm using dovecot version 2.3.4.1 precompiled in Debian stretch-backports (with Maildir, and Lucene FTS). Everything seems to be running fine but server searches by one user (precisely me) using roundcube 1.4.8. For all other checked users server searches work fine. My account is not particularly differnt from others, aprox same amount of mail. The only difference with others is that I use/check my mail constantly and from different devices at the same time (roundcube, a couple of instances of Thunderbird and Aquamail for Android always open). I only use IMAP. Googling around I read about deleting cache/index files with Dovecot recreating them automagically, but since I haven't found anything official on the Wiki, before I do something potentially stupid I wanted to confirm with you all for guidance on this Thanks so much in advance Ignacio

1 0

CVE-2020-24386: IMAP hibernation allows accessing other peoples mail
by Aki Tuomi 07 Jan '21

07 Jan '21

Open-Xchange Security Advisory 2021-01-04 Product: Dovecot Vendor: OX Software GmbH Internal reference: DOP-2009 (Bug ID) Vulnerability type: CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences Vulnerable version: 2.2.26-2.3.11.3 Vulnerable component: imap Report confidence: Confirmed Solution status: Fixed by Vendor Fixed version: 2.3.13 Vendor notification: 2020-08-17 Solution date: 2020-08-27 Public disclosure: 2021-01-04 CVE reference: CVE-2020-24386 CVSS: 8.2 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N) Vulnerability Details: When imap hibernation is active, an attacker can cause Dovecot to discover file system directory structure and access other users' emails using specially crafted command. The attacker must have valid credentials to access the mail server. Risk: Attacker can access other users' emails and filesystem information. Workaround: Operators can choose to disable IMAP hibernation. IMAP hibernation is not on by default. To ensure imap hibernation is disabled, make sure imap_hibernate_timeout is set to 0 or unset. Solution: Operators should update to 2.3.13 or later version.

6 6

systemd-homed
by Yilin Wei 07 Jan '21

07 Jan '21

Hi, I’ve been looking into a problem with a local dovecot setup with ~systemd-homed~ and uses PAM authentication. To give a brief overview, ~systemd-homed~ mounts the users home directory upon particular authencation calls (which is configurable through ~/etc/pam.d~). Dovecot currently supports PAM authentication perfectly fine — the problem comes when a system has systemd-homed. This is because the session is created and deleted immediately afterwards [1]. This is a problem because if the server isn’t busy, systemd-homed can run it’s cleanup which causes the home directory to be unavailable once again [2]. To support this properly, ideally the whole of the imap/pop3/lda session needs to happen before the deletion of the session. Does the imap session happen within a ~verify_plain~ [3] call? If not, are there any other authentication backends which currently need to keep a live token? Yilin [1] https://github.com/dovecot/core/blob/266e54b7b8c34c9a58dd60a2e53c5ca7d1deae… [2] https://dovecot.org/pipermail/dovecot/2019-April/115559.html [3] https://github.com/dovecot/core/blob/266e54b7b8c34c9a58dd60a2e53c5ca7d1deae…

2 1

multiple mailstores
by Alexander Rivanykov 07 Jan '21

07 Jan '21

2 1

Dovecot + sis problem
by Michał Kiljański 07 Jan '21

07 Jan '21

Hi, My setup is: mail_attachment_dir = /var/mail/attachments mail_attachment_hash = %{sha512} mail_attachment_min_size = 64k mail_attachment_fs = sis posix Something works - but I expected that is one instance of file, and this file is linked to messages. But here in folder I have got this: sudo ls -la /var/mail/attachments/8b/67/ -rw-rw-rw- 3 buser dovecot 5425280 Jan 5 23:13 8b67b29a73b74ecf48e17e789051602cec13aa78cc01c06c8eee1ca4be7c8e07f700cdc9e9ca0381fa3541bdd4e26289de1d7eee763233dfaa0a200a264e5258-0258913a92f2f45f0d700000035f3f08 -rw-rw-rw- 1 cuser dovecot 5425280 Jan 5 23:13 8b67b29a73b74ecf48e17e789051602cec13aa78cc01c06c8eee1ca4be7c8e07f700cdc9e9ca0381fa3541bdd4e26289de1d7eee763233dfaa0a200a264e5258-28571b018ff2f45f0c700000035f3f08 -rw-rw-rw- 3 buser dovecot 5425280 Jan 5 23:13 8b67b29a73b74ecf48e17e789051602cec13aa78cc01c06c8eee1ca4be7c8e07f700cdc9e9ca0381fa3541bdd4e26289de1d7eee763233dfaa0a200a264e5258-50315d3a8ef2f45f0a700000035f3f08 -rw-rw-rw- 1 auser dovecot 5425280 Jan 5 23:13 8b67b29a73b74ecf48e17e789051602cec13aa78cc01c06c8eee1ca4be7c8e07f700cdc9e9ca0381fa3541bdd4e26289de1d7eee763233dfaa0a200a264e5258-586cdb378ef2f45f07700000035f3f08 drwxrwsrwx 2 buser dovecot 4096 Jan 5 23:13 hashes sudo ls -la /var/mail/attachments/8b/67/hashes/ -rw-rw-rw- 3 buser dovecot 5425280 Jan 5 23:13 8b67b29a73b74ecf48e17e789051602cec13aa78cc01c06c8eee1ca4be7c8e07f700cdc9e9ca0381fa3541bdd4e26289de1d7eee763233dfaa0a200a264e5258 What is wrog? How to setup SIS to get one instance of file? Regards Michal

2 2

Pigeonhole v0.5.13 released
by Aki Tuomi 06 Jan '21

06 Jan '21

We are pleased to release pigeonhole 0.5.13. You can download it from locations below: https://pigeonhole.dovecot.org/releases/2.3/dovecot-2.3-pigeonhole-0.5.13.t… https://pigeonhole.dovecot.org/releases/2.3/dovecot-2.3-pigeonhole-0.5.13.t… Binary packages in https://repo.dovecot.org/ Docker images in https://hub.docker.com/r/dovecot/dovecot Aki Tuomi Open-Xchange oy --- - duplicate: The test was handled badly in a multiscript (sieve_before, sieve_after) scenario in which an earlier script in the sequence with a duplicate test succeeded, while a later script caused a runtime failure. In that case, the message is recorded for duplicate tracking, while the message may not actually have been delivered in the end. - editheader: Sieve interpreter entered infinite loop at startup when the "editheader" configuration listed an invalid header name. This problem can only be triggered by the administrator. - relational: The Sieve relational extension can cause a segfault at compile time. This is triggered by invalid script syntax. The segfault happens when this match type is the last argument of the test command. This situation is not possible in a valid script; positional arguments are normally present after that, which would prevent the segfault. - sieve: For some Sieve commands the provided mailbox name is not properly checked for UTF-8 validity, which can cause assert crashes at runtime when an invalid mailbox name is encountered. This can be caused by the user by writing a bad Sieve script involving the affected commands ("mailboxexists", "specialuse_exists"). This can be triggered by the remote sender only when the user has written a Sieve script that passes message content to one of the affected commands. - sieve: Large sequences of 8-bit octets passed to certain Sieve commands that create or modify message headers that allow UTF-8 text (vacation, notify and addheader) can cause the delivery or IMAP process (when IMAPSieve is used) to enter a memory-consuming semi-infinite loop that ends when the process exceeds its memory limits. Logged in users can cause these hangs only for their own processes.

2 1