October 2025 - dovecot

lmtp server disconnects upon "RCPT TO" with internal error message
by rmfuhrer＠optonline.net 30 Oct '25

30 Oct '25

I've got a dovecot 2.4.1 instance (from the DockerHub official image) in a test Docker container on MacOS, running both IMAPS and LMTP. The IMAPS service is behaving normally, including the SSL negotiation, so I'm sure my cert (from LetsEncrypt) are kosher. I want to use fetchmail to deliver emails via LTMP, and fetchmail seems to connect to LMTP but doesn't succeed in delivering any emails. I tried the following experiment to manually craft an mail-delivery interaction with LMTP, but the connection suddenly closed right after the server sees the "RCPT TO", with an odd internal SSL error: $ openssl s_client -showcerts -connect 127.0.0.1:31024 ... <SSL negotiation diagnostics> ... Secure Renegotiation IS NOT supported ... 220 104b6de64916 Dovecot ready. LHLO test.mydomain.net 250-104b6de64916 250-8BITMIME 250-CHUNKING 250-ENHANCEDSTATUSCODES 250-PIPELINING 250 SMTPUTF8 MAIL FROM:<someuser(a)somedomain.net> 250 2.1.0 OK RCPT TO:<myuser(a)mydomain.net> RENEGOTIATING 8204750656:error:1404C042:SSL routines:ST_OK:called a function you should not call:/AppleInternal/Library/BuildRoots/4ff29661-3588-11ef-9513-e2437461156c/Library/Caches/com.apple.xbs/Sources/libressl/libressl-3.3/ssl/ssl_lib.c:2435: $ Note that during SSL negotiation, the client notes that "Secure Renegotiation IS NOT supported". Not sure whether that's relevant, but I do see "RENEGOTIATING" just before the fatal (?) error. FWIW, the recipient "myuser(a)mydomain.net" really exists on the Dovecot server; I have a mail client that connects to the IMAP service and successfully authenticates as that user. The relevant LMTP portion of the Dovecot logs looks like this: Oct 29 14:02:38 lmtp(7270): Info: Connect from 192.168.65.1 Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x10, ret=1: before SSL initialization Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x2001, ret=1: before SSL initialization Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x2002, ret=-1: before SSL initialization Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x2001, ret=1: before SSL initialization Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x2001, ret=1: SSLv3/TLS read client hello Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x2001, ret=1: SSLv3/TLS write server hello Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x2001, ret=1: SSLv3/TLS write change cipher spec Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x2001, ret=1: TLSv1.3 write encrypted extensions Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x2001, ret=1: SSLv3/TLS write certificate Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x2001, ret=1: TLSv1.3 write server certificate verify Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x2001, ret=1: SSLv3/TLS write finished Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x2001, ret=1: TLSv1.3 early data Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x2002, ret=-1: TLSv1.3 early data Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x2002, ret=-1: TLSv1.3 early data Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x2002, ret=-1: TLSv1.3 early data Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x2002, ret=-1: TLSv1.3 early data Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x2001, ret=1: TLSv1.3 early data Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x2001, ret=1: SSLv3/TLS read finished Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x20, ret=1: SSLv3/TLS write session ticket Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x2001, ret=1: SSLv3/TLS write session ticket Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x2001, ret=1: SSLv3/TLS write session ticket Oct 29 14:02:38 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL: where=0x2002, ret=1: SSL negotiation finished successfully Oct 29 14:03:14 lmtp(7270): Debug: lmtp-server: conn 192.168.65.1:36620 [1]: SSL alert: close notify Oct 29 14:03:14 lmtp(7270): Info: Disconnect from 192.168.65.1: Connection closed (state=MAIL FROM) I've searched around and not found anything useful (in fact, hardly anything at all) about the above-cited error. Clues, anyone?

2 2

2.4.2: "make check" fails without json & lpeg Lua modules
by Thomas Zajic 29 Oct '25

29 Oct '25

Hi, Basically $SUBJECT. If you run "make check" after a successful build, it will fail unless you have the Lua modules "json" and "lpeg" installed. Not a huge problem, I got them from https://github.com/harningt/luajson and https://www.inf.puc-rio.br/~roberto/lpeg/, but as this sees to be a new thing with 2.4.2 I thought I'd give you a heads-up. HAND Thomas

1 0

Native ext4 fs quotas
by aris fesarlis 29 Oct '25

29 Oct '25

It seems that quota mechanism in newer linux (eg alma10) has changed. Now there are no quota files (aquota.user), but instead quotas must be enabled (ext4) using tune2fs. It seems that dovecot (in my case) cannot recognise this and still looks for quota files: error: Failed to get quota resource STORAGE: quota-fs: quotactl(Q_GETQUOTA, /dev/sda1) failed: No such file or directory Any way to overcome this? Have no time to change backends at the moment.

1 0

2.4.2 build failure in src/lib-regex
by Thomas Zajic 29 Oct '25

29 Oct '25

Hi, Building 2.4.2 fails due to a strange Makefile dependency regarding libpcre-32: > [zlatko@airframe:~/usrlocal/src/dovecot-2.4.2/src/lib-regex]$ make > make: *** No rule to make target '-L/usr/local/lib64', needed by 'test-regex'. Stop. > make: *** Waiting for unfinished jobs.... > CCLD libdregex.la This is because for some reason, $(test_regex_DEPENDENCIES) is part of the targets that need to be made before making test-regex$(EXEEXT): > test-regex$(EXEEXT): $(test_regex_OBJECTS) $(test_regex_DEPENDENCIES) $(EXTRA_test_regex_DEPENDENCIES). > @rm -f test-regex$(EXEEXT) > $(AM_V_CCLD)$(LINK) $(test_regex_OBJECTS) $(test_regex_LDADD) $(LIBS) And $(test_regex_DEPENDENCIES) contains, among other things, $(LIBPCRE_LIBS), which in turn is the output of `pkg-config --libs "libpcre2-32"`: > [zlatko@airframe:~/usrlocal/src/dovecot-2.4.2/src/lib-regex]$ pkg-config --libs "libpcre2-32" > -L/usr/local/lib64 -lpcre2-32 So, `make` thinks it needs to create two files "-L/usr/local/lib64" and "-lpcre2-32" before it can make `test-regex`, but of course it doesn't know *how* to make them, and stops. The fix is trivial, of course, just remove the incorrect requirements/targets part "$(test_regex_DEPENDENCIES) $(EXTRA_test_regex_DEPENDENCIES)" from the recipe for test-regex$(EXEEXT) so that it reads ... > test-regex$(EXEEXT): $(test_regex_OBJECTS) > @rm -f test-regex$(EXEEXT) > $(AM_V_CCLD)$(LINK) $(test_regex_OBJECTS) $(test_regex_LDADD) $(LIBS) ..., but of course the Makefile should already be generated properly in the first place. HAND Thomas

1 0

CVE-2025-30189 notification
by Aki Tuomi 29 Oct '25

29 Oct '25

Affected product: Dovecot IMAP Server Internal reference: DOV-7830 Vulnerability type: CWE-1250 (Improper Preservation of Consistency Between Independent Representations of Shared State) Vulnerable version: 2.4.0, 2.4.1 Vulnerable component: auth Report confidence: Confirmed Solution status: Fixed in 2.4.2 Researcher credits: Erik <erik(a)broadlux.com> Vendor notification: 2025-07-25 CVE reference: CVE-2025-30189 CVSS: 7.4 (CVSS3.1:AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) Vulnerability Details: Using auth caching with oauth2 passdb, passwd passdb or userdb, or passwd userdb, causes the first lookup to be cached for all the lookups. This is because the cache key is "%u" which no longer actually expands to same as "%{user}". Workaround: Disabling auth cache will prevent the issue. Fix Install non-vulnerable version of Dovecot. Patch can be found at https://github.com/dovecot/core/compare/a70ce7d3e2f983979e971414c5892c4e301…

1 0

duplicates
by Kevin Kretz 27 Oct '25

27 Oct '25

Hi, We use Dovecot and Postfix for internal emails and keep aliases in an LDAP table. We have multiple sites, with some user mailboxes local to each. If user A and B are both in alias OurGroup, and a message is sent to [ mailto:ourgroup@domain.com | ourgroup(a)domain.com ] [ mailto:a@domain.com | a(a)domain.com ] and [ mailto:b@domain.com, | b(a)domain.com, ] a and b will receive two copies of the message. Should this be addressed with Postfix or Dovecot? thanks Hi, We use Dovecot and Postfix for internal emails and keep aliases in an LDAP table. We have multiple sites, with some user mailboxes local to each. If user A and B are both in alias OurGroup, and a message is sent to [1]ourgroup(a)domain.com [2]a(a)domain.com and [3]b(a)domain.com, a and b will receive two copies of the message. Should this be addressed with Postfix or Dovecot? thanks References Visible links 1. mailto:ourgroup@domain.com 2. mailto:a@domain.com 3. mailto:b@domain.com,

2 1

Can dovecot sieve query a database file?
by Hadmut Danisch 27 Oct '25

27 Oct '25

Hi, can dovecot sieve query any external database ( berkeley database file, rest api, whatever) to determine the target folder by sender address? Background: I have to migrate a mailbox from an old ubuntu system running with mailfilter as a local delivery agent, and dovecot just as an IMAP server. Since recent ubuntu versions do not have mailfilter anymore (abandoned for a decade) I need to substitute the mailfilter file with dovecot sieve. The old mailfilter script contained something like if (gdbmopen(".mailfilter.gdbm", "R") == 0) { if ( (box=gdbmfetch(tolower($FROM),"D")) ne "" ) to $box if ( /^From: .*<(.*)>/ ) { if ( (box=gdbmfetch(tolower($MATCH1),"D")) ne "" ) to $box } gdbmclose } which allowed to sort mails into mailboxes depending on the sender for hundreds of sender addresses in a fast end efficient way. It wouldn't make sense and be too slow to translate this into a sieve script with a thousand if header :matches ... elsif header :matches ... Is there a way to do this efficently in dovecot's sieve? regards Hadmut

5 7

No Sent Items folder created
by ville＠datsuncherry.com 27 Oct '25

27 Oct '25

Hello, before paying any effort, what could be the reason that in Postfix, Dovecot, Thunderbird client setup no Sent Items folder is created on the server as a first mail is sent on the newly created account. The mail is sent, but Thunderbird saves it instead in local sent items. Also when checking account settings the 'save copy setting' has changed from server to local and when setting it back to server same happens when a new mail is sent. For comparison the Apple Mail client creates a 'Sent Items' folder on the server, which afterwards can be selected manually in Thunderbird from that point on to store sent mails. Received mails are stored under /var/mail/vhosts/domain/user in either case. This issue appeared as I configured an existing server to use another domain name. and thought replacing the host names under /etc/postfix and /etc/dovecot would suffice, besides of course replacing the mail addresses in the mysql table. Any idea what causes this. As the mail is however sent correctly, what could make creating the sent items folder 'fail' as it somehow appears. Would logging the IMAP communication from the client to the server help finding the reason if it is at all possible or otherwise I would need to compile the code with printf's. Server is Ubuntu 22.

3 5

dsync between 2 instances on same machine (but different versions and different DNS hostnames) fails with "doveadm server sent invalid handshake"
by rmfuhrer＠optonline.net 26 Oct '25

26 Oct '25

I'm trying to use dsync to upgrade from an existing 2.3 server running native on MacOS to a 2.4.1 server running inside a Docker container on the same machine, using the official Dovecot 2.4.1 Docker image from DockerHub. For testing, I decided to set up a new hostname (CNAME) record in DNS pointing to the same IP, since both Dovecot instances are running on the same host. The new 2.4.1 Docker-containerized instance is working fine so far, which is to say I can connect to it from a mail client (the Mac Mail app) using TLS/SSL, and I'm able to move mail messages in, delete them, create folders, etc. For the next phase of testing, I want to migrate a single folder of a single user's email from the 2.3 instance to the new 2.4.1 Docker instance. I recently found out about dsync and thought I'd give it a try. The test Dockerized instance exposes its IMAPS port to a different port than the legacy instance (of course). I found that dsync seems to behave differently than the IMAP service wrt the certficate chain: Whereas the Mail client was able to negotiate the encrypted connection with the LetsEncrypt server cert alone in the dovecot cert file, with dsync, the 2.3 server seemed to require the entire cert chain to reside in the file. (?) After resolving that, the source dsync could at least get past the certificate validation phase, but then complained thusly: Oct 19 21:52:11 doveadm(myuser(a)mydomain.net): Error: doveadm server sent invalid handshake: * OK [CAPABILITY IMAP4rev1 LOGIN-REFERRALS ID ENABLE IDLE SASL-IR LITERAL+ AUTH=PLAIN AUTH=LOGIN] Dovecot ready. Oct 19 21:52:11 doveadm(myuser(a)mydomain.net): Error: Disconnected from remote: EOF Oct 19 21:52:11 doveadm(myuser(a)mydomain.net): Debug: auth-master: conn unix:/usr/local/var/run/dovecot/auth-userdb (uid=0): Disconnected: Connection closed (fd=8) I can't tell from that error message what the source dsync doesn't like about the destination dsync, or for that matter, whether it might be the destination dsync that doesn't like what the source dsync is saying?? Anyway, I'm invoking dsync like this, to sync just a single folder: $ sudo doveadm -D -v backup -u myuser(a)mydomain.net -m FolderName tcps:testserver.mydomain.net:31993 ALSO: I confess that I also don't understand how dsync can work without asking for user account passwords, if it's indeed running over the IMAPS service. How can the destination service trust the incoming dsync connection? I assume it's running over a normal IMAPS connection, since that's the only port that I've given to the source dsync command, but maybe that's not the case? The docs are pretty unclear about this aspect, but I'm no expert, so maybe this is just obvious to others. (?)

3 11

mdbox: double forward-slash in mail_path
by Edmund Lodewijks 23 Oct '25

23 Oct '25

Hello List! I am testing mdbox on Dovecot 2.4.1 (currently using Maildir, but thinking of converting). I created a test server with a test domain. Installed relevant software from default repos on Debian 13: - Postfix - Dovecot 2.4.1 - PostfixAdmin - MariaDB After I had created an email address, I checked the settings as follows: ``` # doveadm user mail@$REDACTED field value uid 5000 gid 5000 home /vhosts/$REDACTED/mail/ mail_path /vhosts/$REDACTED/mail//mdbox quota_rule *:bytes=1048576000 ``` As you can see, there is a double forward-slash in the mail_path line. From /etc/dovecot/local.d/10-mail.conf: ``` mail_driver = mdbox mail_path = ~/mdbox ``` This is based on the official Dovecot docs page (see at the very bottom): https://doc.dovecot.org/2.4.1/core/config/mailbox_formats/dbox.html Is this harmful, or just "cosmetic"? Have I made a mistake somewhere? I presume the mail_path line is not even required, as it is the default for that mail_driver. Thank you for your time and reply. Kind regards, Edmund Lodewijks -- Edmund Lodewijks <edmund(a)proteamail.com> TZ: UCT+2 / GMT+2

4 8