August 2024 - dovecot

dovecot-2.3.2.1 and dovecot-pigeonhole-0.5.2 bug?
by Jan Nowak 16 Aug '24

16 Aug '24

Hello, we have a problem after updating the software with the operation of sieve scripts sending a copy of the e-mails, e-mails are not transferred. Configuration: dovecot-2.3.2.1 + dovecot-pigeonhole-0.5.2 + FreeBSD 11.2 log: Sep 06 13:28:17 lda(XXX@XXX)<38615><XXX+XXX>: Info: sieve: msgid=<XXX-XXX-XXX-7788-XXX@XXXXnet>: stored mail into mailbox 'INBOX' Sep 06 13:28:17 lda(XXX@XXX)<38615><XXX+XXX>: Info: sieve: Execution of script /usr/home/XXX/mail/XXX(a)XXX/.dovecot.sieve failed, but implicit keep was successful (user logfile /usr/home/XXX/mail/XXX(a)XXX/.dovecot.sieve.log may reveal additional details) .dovecot.sieve.log: error: msgid=<XXX-XXX-XXX-7788-XXX@XXXXnet>: failed to redirect message to <XXXXX(a)XXXXXX.com>: smtp(127.0.0.1:25): DATA failed: 552 Message header not CRLF terminated (permanent failure). On old configuration: dovecot 2.2 + dovecot-pigeonhole- 0.4 + FreeBSD 11.2 we don't have problem. Has anyone had a similar problem, knows the solution?

5 12

The future of SIS
by Sebastian Marsching 16 Aug '24

16 Aug '24

Hi, I am currently in the process of planning a new deployment of Dovecot. I was planning to use mdbox or sdbox with “mail_attachment_fs = sis posix”, but I stumbled across the following notice in the documentation for Dovecot 3.0 (https://doc.dovecot.org/3.0/settings/core/#core_setting-mail_attachment_fs) > Changed in version 2.4.0 (CE): SIS is deprecated and writing of SIS files is disabled. Reading is supported for now, any missing SIS attachments are replaced with files filled with spaces. > > Changed in version 3.0.0 (Pro): SIS is deprecated and writing of SIS files is disabled. Reading is supported for now, any missing SIS attachments are replaced with files filled with spaces. And https://doc.dovecot.org/3.0/installation_guide/upgrading/from-2.3-to-3.0/ says: > Saving new mails’ attachments via fs-sis is disabled, but reading SIS attachments is still supported. Missing SIS attachments are replaced with files filled with spaces. What is not entirely clear from this comment is whether this only applied to “sis posix” or also to “sis-queue posix”. Does anybody whether sis-queue is also affected by this? I saw that the notice was added to the dovecot/documentation Git repository in April 2023, but I couldn’t find any further information there or the main branch of the dovecot/core repository. Maybe, the code for 2.4 / 3.0 has not made it into that branch or repository yet. SIS sounds like a neat concept and I would like to use it, but obviously I do not want to use a soon-to-be-deprecated feature in a completely new deployment. So, does anybody know an alternative solution for attachment deduplication (except file-system level deduplication)? Thanks, Sebastian

19 43

vacation is not using from in envelope
by Marc 16 Aug '24

16 Aug '24

How to get dovecot use the from in sieve in the envelope?

3 5

Frequency Control for IMAP connection
by Corey H 15 Aug '24

15 Aug '24

Hello one of our users makes too quick IMAP connections to the server. $ sudo tail -10000 /var/log/mail.log|grep **(a)**mail.com|wc -l 3544 logs like this: Aug 15 19:54:10 mx dovecot: imap-login: Login: user=<**(a)**mail.com>, method=PLAIN, rip=**, lip=**, mpid=4151830, TLS, session=<UPotgLcfTOjYUzTN> How can I implement a Frequency Control on client connections to slow down his requests? Thank you.

2 1

2.3.21.1 build failure on MacOS X 14.6.1
by Daniel J. Luke 15 Aug '24

15 Aug '24

Hi - I get a build failure from dbox-storage.c because the stat struct doesn't have st_atim/st_ctim This simple patch fixes it (and should also work on linux/glibc hosts, but I haven't tested it there). --- src/lib-storage/index/dbox-common/dbox-storage.c.orig 2024-08-14 14:59:57 +++ src/lib-storage/index/dbox-common/dbox-storage.c 2024-08-14 15:01:23 @@ -293,8 +293,8 @@ if the directory exists. In case, get also the ctime */ struct stat stats; if (stat(path, &stats) == 0) { - last_temp_file_scan = stats.st_atim.tv_sec; - change_time = stats.st_ctim.tv_sec; + last_temp_file_scan = stats.st_atime; + change_time = stats.st_ctime; } else { if (errno != ENOENT) e_error(user->event, "stat(%s) failed: %m", path); -- Daniel J. Luke

2 1

v2.3.21 compile error
by Goetz Schultz 14 Aug '24

14 Aug '24

Hi, I am trying to compile said version above under FreeBSD 14.1 . Config setting is: ./configure --with-pgsql --with-sql However, during compile the process halts with below errors: <quote> test-mail-index-transaction-update.c:648:17: error: incompatible pointer to integer conversion assigning to 'uint32_t' (aka 'unsigned int') from 'char *(*)(int, int)' [-Wint-conversion] 648 | hdr.day_stamp = tests[i].old_day_stamp + timezone; | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ test-mail-index-transaction-update.c:650:49: warning: arithmetic on a pointer to the function type 'char *(int, int)' is a GNU extension [-Wgnu-pointer-arith] 650 | mail_index_update_day_headers(t, tests[i].now + timezone); | ^ ~~~~~~~~ test-mail-index-transaction-update.c:650:36: error: incompatible pointer to integer conversion passing 'char *(*)(int, int)' to parameter of type 'time_t' (aka 'long') [-Wint-conversion] 650 | mail_index_update_day_headers(t, tests[i].now + timezone); | ^~~~~~~~~~~~~~~~~~~~~~~ </quote> Other info: gcc -v FreeBSD clang version 18.1.5 (https://github.com/llvm/llvm-project.git llvmorg-18.1.5-0-g617a15a9eac9) Target: x86_64-unknown-freebsd14.1 Thread model: posix InstalledDir: /usr/bin Any clue or pointer (no pun intended) what's going wrong and how to fix it? -- Thanks and regards Goetz R Schultz Quis custodiet ipsos custodes? ---------------------------->8------------------------------ /"\ \ / ASCII Ribbon Campaign X against HTML e-mail / \ ---------------------------->8------------------------------ ---------------------------->8------------------------------ /"\ \ / ASCII Ribbon Campaign X against HTML e-mail / \ This message is transmitted on 100% recycled electrons. ---------------------------->8------------------------------ Unsigned message - no responsibillity that content is not altered

3 5

[bug?] doveadm -f json who output
by Jasper Spaans 14 Aug '24

14 Aug '24

Hi, I'm trying to parse the output of `doveadm -f json who`[0] and am running into a small issue when it returns data about multiple users: the stream that is emitted in that case is not valid json. dovecot -version tells me dovecot 2.3.21 (47349e2482), more specifically, this is the version shipped in ubuntu 24.04, 1:2.3.21+dfsg1-2ubuntu5 doveadm -f json who [{"username":"<REDACTED>","connections":"4","service":"imap","pids":"(272307 270876 270872 270869)","ips":"(2001:<REDACTED>:7488)"}],{"username":"<REDACTED>","connections":"2","service":"imap","pids":"(271469 271465)","ips":"(2a02:<REDACTED>:9c28)"} When trying to pretty print this with jq, it complains about invalid json: doveadm -f json who|jq [ { "username": "<REDACTED>", "connections": "4", "service": "imap", "pids": "(272307 270876 270872 270869)", "ips": "(2001:<REDACTED>0:7488)" } ] jq: parse error: Expected value before ',' at line 1, column 167 Is this expected behaviour? I would have expected a list of user objects, and then it seems like the list-closing bracket that is currently at the end of the first user object should have been at the end of the last user object. I can code around this in my parser, but would rather not. Best, Jasper [0] actually I'm parsing the output of the doveadm http api, but that just seems to copy the data from the json format in there verbatim

2 1

Dovecot refuses to install/run on machine without IPv6
by Kurt Fitzner 14 Aug '24

14 Aug '24

Hi, I just tried to install Dovecot (version 2.3.19.1 9b53102964) on a Debian 12 server I'm building. It failed because Dovecot's default listen address is explicitly "*, ::" and it appears to have no logic to determine if there actually is an IPv6-enabled interface or that IPv6 is enabled on the target machine before it tries to listen on it. If dovecot wants to listen on IPv6 by default, that's neither here nor there, but if this is default behaviour it should check first. I'm curious if it's the same behaviour for machines without IPv4. Kurt Fitzner

5 5

CVE-2024-23184: Having a large number of address headers (From, To, Cc, Bcc, etc.) becomes excessively CPU intensive
by Aki Tuomi 14 Aug '24

14 Aug '24

Affected product: Dovecot IMAP Server Internal reference: DOV-6464 Vulnerability type: CWE-770 (Allocation of Resources Without Limits or Throttling) Vulnerable version: 2.2, 2.3 Vulnerable component: lib-mail Report confidence: Confirmed Solution status: Fixed in 2.3.21.1 Researcher credits: Vendor internal discovery Vendor notification: 2024-01-30 CVE reference: CVE-2024-23184 CVSS: 5.0 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N) Vulnerability Details: Having a large number of address headers (From, To, Cc, Bcc, etc.) becomes excessively CPU intensive. With 100k header lines CPU usage is already 12 seconds, and in a production environment we observed 500k header lines taking 18 minutes to parse. Since this can be triggered by external actors sending emails to a victim, this is a security issue. The main problem is that each header line's address is added to the end of a linked list. This is done by walking the whole linked list, which becomes more inefficient the more addresses there are. Workaround: One can implement restrictions on address headers on MTA component preceding Dovecot. Fix: Install non-vulnerable version of Dovecot. Patch can be found at https://github.com/dovecot/core/compare/8e4c42d%5E...1481c04.patch

2 1

Dovecot CVE-2024-23185: Very large headers can cause resource exhaustion when parsing message
by Aki Tuomi 14 Aug '24

14 Aug '24

Affected product: Dovecot IMAP Server Internal reference: DOV-6601 Vulnerability type: CWE-770 (Allocation of Resources Without Limits or Throttling) Vulnerable version: 2.2, 2.3 Vulnerable component: lib-mail Report confidence: Confirmed Solution status: Fixed in 2.3.21.1 Researcher credits: Vendor internal discovery Vendor notification: 2024-01-31 CVE reference: CVE-2024-23185 CVSS: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) Vulnerability Details: Very large headers can cause resource exhaustion when parsing message. The message-parser normally reads reasonably sized chunks of the message. However, when it feeds them to message-header-parser, it starts building up "full_value" buffer out of the smaller chunks. The full_value buffer has no size limit, so large headers can cause large memory usage. It doesn't matter whether it's a single long header line, or a single header split into multiple lines. This bug exists in all Dovecot versions. Incoming mails typically have some size limits set by MTA, so even largest possible header size may still fit into Dovecot's vsz_limit. So attackers probably can't DoS a victim user this way. A user could APPEND larger mails though, allowing them to DoS themselves (although maybe cause some memory issues for the backend in general). Workaround: One can implement restrictions on headers on MTA component preceding Dovecot. Fix: Install non-vulnerable version of Dovecot. Patch can be found at https://github.com/dovecot/core/compare/f020e13%5E...ce88c33.patch

1 0