- dovecot - dovecot.org

Dovecot v2.3.21.1 released
by Aki Tuomi 07 Sep '24

07 Sep '24

Hi all, we are releasing a CVE patch release 2.3.21.1. https://dovecot.org/releases/2.3/dovecot-2.3.21.1.tar.gz https://dovecot.org/releases/2.3/dovecot-2.3.21.1.tar.gz.sig Binary packages in https://repo.dovecot.org/ Docker images in https://hub.docker.com/r/dovecot/dovecot Kind regards, Aki Tuomi Open-Xchange oy --- - CVE-2024-23184: A large number of address headers in email resulted in excessive CPU usage. - CVE-2024-23185: Abnormally large email headers are now truncated or discarded, with a limit of 10MB on a single header and 50MB for all the headers of all the parts of an email. - oauth2: Dovecot would send client_id and client_secret as POST parameters to introspection server. These need to be optionally in Basic auth instead as required by OIDC specification. - oauth2: JWT key type check was too strict. - oauth2: JWT token audience was not validated against client_id as required by OIDC specification. - oauth2: XOAUTH2 and OAUTHBEARER mechanisms were not giving out protocol specific error message on all errors. This broke OIDC discovery. - oauth2: JWT aud validation was not performed if aud was missing from token, but was configured on Dovecot.

5 9

~/mail/.imap
by graeme.dovecot＠vetterlein.com 05 Sep '24

05 Sep '24

the box that runs my mailsever just reported disk > 80% full , so looking to tidy up. I note: sudo du -d2 -k -x /home/graeme/mail | sort -n ... ... 66788 /home/graeme/mail/.imap/spam 198328 /home/graeme/mail/.imap 1564680 /home/graeme/mail/2023 4009336 /home/graeme/mail Now in .imap I have directories dating back to 2013 .... the corresponding mail folders have long since moved to backup. What would be the effect of deleting EVERYTHING in .imap.... will it just get recreated as needed? or do I need to take care and only remove stuff I know is no longer used?

1 0

Can I delete duplicate messages under Maildir on the server?
by MI 05 Sep '24

05 Sep '24

After a client misconfiguration, many messages have been deleted. I restored them from backups, but now there are many duplicates. I can identify them on the server, and delete them. But do I need to also delete the dovecot.index files and/or other dovecot* files in the affected folders, or will these be automatically updated? (My Dovecot version is 2.3.13, so I guess I should not use doveadm deduplicate which would risk deleting non-duplicate messages, according to the "doveadm-deduplicate deletes non-duplicates" thread here?)

1 0

Re: Dovecot authentication hangs when ldap_start_tls_s() fails for invalid certificate
by Aki Tuomi 04 Sep '24

04 Sep '24

> On 19/11/2020 12:55 sebastiano degan <sebastiano.degan(a)frigoveneta.it> wrote: > > > On a Debian10 I've installed postfix 3.4.14 and dovecot 2.3.4.1. > I've configured multiple passdb sources and I expect that if one fails > the other ones are tested. > This is usually the case, except when the failure is due to an invalid > certificate from the ldap server. > In that case all authentication attempts from that moment on will fail. Hi! Can you try with latest CE release from https://repo.dovecot.org/ Regards, Aki

2 1

allow_nets check failure still performs LDAP bind authentication
by Florian Wunderlich 04 Sep '24

04 Sep '24

Postfix authentication via Dovecot. Dovecot performs the allow_nets check, which fails. It then still attempts to authenticate the user via LDAP bind, thus allowing DoS attacks where the entry in the directory will be locked after a few failed attempts. dovecot --version: 2.3.19.1 (9b53102964) Debian GNU/Linux 12 (bookworm), x86, no NFS Sep 04 07:26:05 postfix/smtpd[48225]: connect from unknown[182.176.211.10] Sep 04 07:26:17 dovecot[33863]: auth: *ldap(XXX,182.176.211.10): allow_nets check failed: IP 182.176.211.10 not in allowed networks* Sep 04 07:26:17 dovecot[33863]: auth: *ldap(XXX,182.176.211.10): Password mismatch (for LDAP bind)* Sep 04 07:26:27 postfix/smtpd[48225]: warning: unknown[182.176.211.10]: SASL LOGIN authentication failed: Connection lost to authentication server, sasl_username=(unavailable) Sep 04 07:26:27 postfix/smtpd[48225]: lost connection after AUTH from unknown[182.176.211.10] Sep 04 07:26:27 postfix/smtpd[48225]: disconnect from unknown[182.176.211.10] ehlo=2 starttls=1 auth=0/1 commands=3/4 The allow_nets extra field comes from LDAP. This works as a pass_filter query is performed first, which returns the allow_nets. /DN is looked up by sending a pass_filter LDAP request and getting the DN from the reply. This is very similar to doing a password lookup. The only difference is that userPassword attribute isn’t returned. Just as with password lookups, the pass_attrs may contain special extra fields./ https://doc.dovecot.org/2.3/configuration_manual/authentication/ldap_bind/#… After this, Dovecot should immediately fail the authentication. /If the user tries to log in from elsewhere, the authentication will fail the same way as if a wrong password was given./ https://doc.dovecot.org/2.3/configuration_manual/authentication/allow_nets/ There is no need to perform the bind authentication. According to the log (and the locked user accounts), it is still performed. Configuration is irrelevant, for completeness’s sake: auth_bind = yes pass_filter = (&(|(objectClass=simpleSecurityObject)(objectClass=posixAccount))(cn=%n)) pass_attrs = \ cn=user, \ allowNets=allow_nets

1 0

What are all the /var/spool/smtpd/offline/1689525601.XXXXlJ85yQ
by Steve Litt 03 Sep '24

03 Sep '24

Hi all, I just filled up my whole /var with zillions of files /var/spool/smtpd/offline , dating back to 2018. What are these files and is it safe for me to delete the ones more than a week old? Thanks, SteveT Steve Litt http://444domains.com

5 7

Inconsistency in map index with dovecot v2.3.21
by Nikolaos Pyrgiotis 02 Sep '24

02 Sep '24

Hello, We have been running dovecot version 2.3.21 since July on debian bookworm system. After upgrading we have seen in the logs similar messages to the following: 2024-08-29T19:33:27.755399+03:00 server1 dovecot: lmtp(user1(a)modulus.gr)<481240><7TMeHNei0GYpeTkA1g8ogQ:P1>: Warning: mdbox /path/user1/mdbox/storage: Inconsistency in map index (2213,40 != 2213,56). 2024-08-29T19:33:27.755399+03:00 server1 dovecot: lmtp(user1(a)modulus.gr)<481240><7TMeHNei0GYpeTkA1g8ogQ:P1>: Warning: mdbox /path/user1/mdbox/storage: Inconsistency in map index (2213,40 != 2213,56) 2024-08-29T19:33:27.838990+03:00 server1 dovecot: lmtp(user1(a)modulus.gr)<481240><7TMeHNei0GYpeTkA1g8ogQ:P1>: sieve: msgid=<39f9c444-0c08-4bda-bfc9-512c34584470(a)modulus.gr>: fileinto action: stored mail into mailbox 'Replies' 2024-08-29T19:33:27.840222+03:00 server1 dovecot: lmtp(user1(a)modulus.gr)<481240><7TMeHNei0GYpeTkA1g8ogQ:P1>: Warning: fscking index file /path/user1/mdbox/storage/dovecot.map.index 2024-08-29T19:33:27.953281+03:00 server1 dovecot: lmtp(user1(a)modulus.gr)<481240><7TMeHNei0GYpeTkA1g8ogQ:P1>: Warning: mdbox /path/user1/mdbox/storage: rebuilding indexes 2024-08-29T19:37:27.989792+03:00 server1 dovecot: lmtp(user1(a)modulus.gr)<481249><vhzsLROj0GYQVgcAfAk26A:P1>: Error: Timeout (180s)while waiting for lock for transaction log file /path/user1/mdbox/storage/dovecot.map.index.log (WRITE lock held by pid 481240) 2024-08-29T19:37:27.995913+03:00 server1 dovecot: lmtp(user1(a)modulus.gr)<481249><vhzsLROj0GYQVgcAfAk26A:P1>: Error: sieve: msgid=<39f9c444-0c08-4bda-bfc9-512c34584470(a)modulus.gr>: fileinto action: failed to store into mailbox 'Mailbox': Timeout (180s) while waiting for lock for transaction log file /path/user1/mdbox/storage/dovecot.map.index.log (WRITE lock held by pid 481240) This has happened a few times since we upgraded always by a lmtp process. It seems to be happening randomly and we have not been able to reproduce it. The mailboxes are stored in a glusterfs server, and we use the dovecot director with shared mailboxes architecture. Usually this was mitigated automatically by dovecot index rebuilding, but last time it happened on a mailbox with a lot of giga byte of mail data the following logs were produced for more than an hour: 2024-08-29T19:45:30.506694+03:00 server1 dovecot: lmtp(user1(a)modulus.gr)<481240><7TMeHNei0GYpeTkA1g8ogQ:P1>: Error: mmap_anon(/path/user/mdbox/mailboxes/Mailbox/dbox-Mails/dovecot.index.cache, 74076160) failed: Cannot allocate memory During that period segfaults starting being generated for the imap processes accessing that mailbox probably caused by timeouts from imap processes attempting to fetch emails from the affected mailbox: [3912187.557029] imap[481783]: segfault at 38 ip 00007fb03248abf8 sp 00007ffc88b264f0 error 4 in libdovecot-storage.so.0.0.0[7fb0323c7000+d8000] likely on CPU 6 (core 3, socket 0) What might be the reason that inconsistency of the map index is introduced on random users? We have seen some other users had similar issues and have mentioned them on this mailing list(dovecot Digest, Vol 249, Issue 4, dovecot Digest, Vol 250, Issue 8)? Is there any update for a mitigation or bug confirmation for dovecot version 2.3.21 that might be responsible? Thank you, Nikos Pyrgiotis

4 6

Fwd: maintainer-feedback requested: [Bug 280929] mail/dovecot move bogus warning "Time moved forwards" to debug
by Larry Rosenman 01 Sep '24

01 Sep '24

Comments from the dovecot community? Aug 19, 2024 11:07:30 AM bugzilla-noreply(a)freebsd.org: Bugzilla Automation <bugzilla(a)FreeBSD.org> has asked Larry Rosenman <ler(a)FreeBSD.org> for maintainer-feedback: Bug 280929: mail/dovecot move bogus warning "Time moved forwards" to debug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280929 --- Description --- Dovecot complains about time moving forward, which seems to be due to a broken mechanism (on FreeBSD) used to measure timeouts. This warning spams the maillog up to several hundred times per day. There's an ongoing thread about this issue in the freebsd forums: https://forums.freebsd.org/threads/dovecot-time-moved-forwards.82886 In post #33 RypPn points out the offending line in main.c and in post #34 msplsh suggests instead of completely removing/commenting out the line, it would be more sensible to move it from 'warning' to 'debug'. This is what this patch does: change the log facility to 'debug' to mute that bogus message for standard configurations, but keep it in 'debug' for anyone who might want to debug that issue in the future. I tested the patch as a local patch in poudriere and it builds fine on 13.3-RELEASE with the quarterly and latest branch.

7 12

Debug: open(/proc/self/io) failed: Permission denied
by Alex 31 Aug '24

31 Aug '24

Hi, I've seen a few emails over the years related to this error message, but they are typically associated with doveadm. In my case, it's related to dovecot itself. I've just set up dovecot-2.3.20-1.fc37.x86_64 on fedora37 and unable to receive mail. The main config was copied over from another dovecot system on fedora37 with virtually identical settings, including the same SSL cert. I've also tried to just migrate the important stuff and otherwise leave the defaults, but I'm having the same problem. imap(bcc-user)<2977522><rappeBf6vLZEw8Eq>: Debug: Loading modules from directory: /usr/lib64/dovecot imap(bcc-user)<2977522><rappeBf6vLZEw8Eq>: Debug: Module loaded: /usr/lib64/dovecot/lib20_listescape_plugin.so imap(bcc-user)<2977522><rappeBf6vLZEw8Eq>: Debug: Effective uid=1001, gid=1001, home=/home/bcc-user imap(bcc-user)<2977522><rappeBf6vLZEw8Eq>: Debug: open(/proc/self/io) failed: Permission denied imap(bcc-user)<2977522><rappeBf6vLZEw8Eq>: Debug: Namespace inbox: type=private, prefix=, sep=, inbox=yes, hidden=no, list=yes, subscriptions=yes location=mbox:~/mail:INBOX=/var/spool/mail/bcc-user imap(bcc-user)<2977522><rappeBf6vLZEw8Eq>: Debug: fs: root=/home/bcc-user/mail, index=, indexpvt=, control=, inbox=/var/spool/mail/bcc-user, alt= imap(bcc-user)<2977522><rappeBf6vLZEw8Eq>: Debug: Mailbox Trash: Mailbox opened I've set the /var/spool/mail/bcc-user permissions to 600, bcc-user:mail. The /home/bcc-user directory is 611, bcc-user:bcc-user. Here is my doveconf -n: # 2.3.20 (80a5ac675d): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.20 (149edcf2) # OS: Linux 6.1.15-200.fc37.x86_64 x86_64 Fedora release 37 (Thirty Seven) auth_debug = yes auth_verbose = yes mail_debug = yes mail_gid = mail mail_home = mail/ mail_location = mbox:~/mail:INBOX=/var/spool/mail/%u mail_max_userip_connections = 500 mail_plugins = " listescape" mail_privileged_group = mail managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date index ihave duplicate mime foreverypart extracttext mbox_write_locks = fcntl 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 { driver = pam } protocols = imap service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } } service imap-login { inet_listener imap { port = 0 } inet_listener imaps { port = 993 } process_min_avail = 6 service_count = 0 vsz_limit = 512 M } ssl_cert = </etc/letsencrypt/fullchain.cer ssl_cipher_list = ALL:!LOW:!EXP:!aNULL:!RC4::!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS ssl_dh = # hidden, use -P to show it ssl_key = # hidden, use -P to show it ssl_prefer_server_ciphers = yes userdb { driver = passwd } verbose_ssl = yes Any ideas greatly appreciated. I was very surprised to be having problems after having done this so many times before.

3 5

Connection closed (user disabled)
by Roberto J. Bolivar Plenge 28 Aug '24

28 Aug '24

Hello everyone Thank you in advance for your help. Why do I get the following error: Aug 23 10:37:51 cp-cl02 dovecot[2337577]: pop3-login: Disconnected: Connection closed (user disabled): user=<loliva(a)romaseguro.pe>, method=PLAIN, rip=x.x.x.x, lip=x.x.x.x, TLS: Connection closed, session=<8na4jlsg3HK1Q1LE>. I never observed this before: Connection closed (user disabled): I wish to know what is causing it and how can I fix it. Thank you.

2 4