- dovecot - dovecot.org

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

Pigeonhole v0.5.21.1 released
by Aki Tuomi 14 Aug '24

14 Aug '24

Hi all, we are releasing new version of Pigeonhole. https://pigeonhole.dovecot.org/releases/2.3/dovecot-2.3-pigeonhole-0.5.21.1… https://pigeonhole.dovecot.org/releases/2.3/dovecot-2.3-pigeonhole-0.5.21.1… Binary packages in https://repo.dovecot.org/ Docker images in https://hub.docker.com/r/dovecot/dovecot Kind regards, Aki Tuomi Open-Xchange oy --- - sieve: When saving to local storage failed after a successful action in sieve (e.g. redirect, vacation), the mail was reported as successfully delivered, although it was lost locally.

1 0

Extra listener for client cert ?
by Laura Smith 13 Aug '24

13 Aug '24

Is it possible to, and (if yes) has anyone had experience with setting up an extra listener that requires client certs. The problem I've got is I still need to support Outlook clients. Fortunately these are located in fixed locations on desktop computers. Meanwhile, I would like to harden the configuration for road warriors who are all using devices and OSs that play nicer with client certs than Outlook does (well, Outlook doesn't play at all !). So I was thinking of opening 993 on a seperate IP address with that listener requiring client certificates. The alternative is, of course a VPN, which is still under consideration as an option. But even then, with the security onion, I'd still rather have both .... :)

1 0

Synchronize email folders
by Odhiambo Washington 13 Aug '24

13 Aug '24

I moved services to a new server (VPS) when I had issues with my hardware. Now I have copied data from the disk of the old server into the VPS. On the VPS, mail is delivered to /var/spool/virtual/DOMAIN/USER/Maildir/ I have the old emails in /root/DOMAIN/USER/Maildir. What is the easiest way to import the old emails into the current active folders without causing chaos with MuAs?? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

3 3