- dovecot - dovecot.org

deleting maildata from virtual users
by Alexander Rivanykov 04 Jan '21

04 Jan '21

2 4

CVE-2020-25275: MIME parsing crashes with particular messages
by Aki Tuomi 04 Jan '21

04 Jan '21

Open-Xchange Security Advisory 2021-01-04 Product: Dovecot Vendor: OX Software GmbH Internal reference: DOV-4113 (Bug ID) Vulnerability type: CWE-20: Improper Input Validation Vulnerable version: 2.3.11-2.3.11.3 Vulnerable component: lda, lmtp, imap Report confidence: Confirmed Solution status: Fixed by Vendor Fixed version: 2.3.13 Vendor notification: 2020-09-10 Solution date: 2020-09-14 Public disclosure: 2021-01-04 CVE reference: CVE-2020-25275 CVSS: 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) Researcher credit: Innokentii Sennovskiy (Rumata888) from BI.ZONE Vulnerability Details: Mail delivery / parsing crashed when the 10 000th MIME part was message/rfc822 (or if parent was multipart/digest). This happened due to earlier MIME parsing changes for CVE-2020-12100. Risk: Malicious sender can crash dovecot repeatedly by sending / uploading message with more than 10 000 MIME parts. Workaround: These are usually dropped by MTA, where the mitigation can also be applied. Solution: Operators should update to 2.3.13 or later version.

1 0

TLS problem with iOS 9 Mail clients
by Maik Musall 02 Jan '21

02 Jan '21

Hi everyone, recently I migrated my mail server from an Ubuntu 16.04 box to an Ubuntu 20.04 box, so from dovecot 2.2.22 to 2.3.7.2, and to openssl 1.1.1.f. While everything else works fine, I have one important user stuck on an iOS 9 device that I need to support for a while longer, with which the IMAP TLS handshake keeps failing. From the logs: TLS handshaking: SSL_accept() failed: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol I didn’t find a debug option to dump the TLS handshake details, so I analyzed a packet dump and found the following capabilities and cipher suites offered by the client: Transport Layer Security TLSv1 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 149 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 145 Version: TLS 1.0 (0x0301) Random: 5fef787ac06215d0a4edefd17602fadf409ab0512e04e62ade6192f2499f4896 Session ID Length: 0 Cipher Suites Length: 50 Cipher Suites (25 suites) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007) Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 54 Extension: server_name (len=19) Type: server_name (0) Length: 19 Server Name Indication extension Extension: supported_groups (len=8) Extension: ec_point_formats (len=2) Type: ec_point_formats (11) Length: 2 EC point formats Length: 1 Elliptic curves point formats (1) EC point format: uncompressed (0) Extension: status_request (len=5) Type: status_request (5) Length: 5 Certificate Status Type: OCSP (1) Responder ID list Length: 0 Request Extensions Length: 0 Extension: signed_certificate_timestamp (len=0) Type: signed_certificate_timestamp (18) Length: 0 I already tweaked the dovecot-ssl config down with "ssl_min_protocol = TLSv1” and included ECDHE-ECDSA-AES256-SHA in the cipher list, but the client still won’t connect. Does anyone have an idea what else I could try? Thanks Maik

2 6

LDA ignores virtual mailbox settings
by Toni Mueller 01 Jan '21

01 Jan '21

Hi, I have a Debian/Buster system with Postfix and Dovecot from the Debian repo, and with virtual users only (ie, no system users). These virtual users are having all of their uids, gids, homes and mail quota in an PostgreSQL database. The intent is to have postfix deliver the email via dovecot's LDA, so I can set quota on a per-user basis. But for some odd reason, Dovecot's LDA can't find the user data from the userdb, and then complains about not being able to write to /var/mail. The following example shows how things fail when delivering a message from Postfix's queue (therefore, the passdb failure is expected): In /etc/dovecot.conf, I have this, amongst other things: mail_location = maildir:~/Maildir:INBOX=~/Maildir passdb { driver = sql args = /etc/dovecot/dovecot-sql.conf.ext } userdb { driver = prefetch } userdb { driver = sql args = /etc/dovecot/dovecot-sql.conf.ext } protocol lda { mail_plugins = autocreate quota mail_log trash virtual notify } 16:04:16 postfix/qmgr[4970]: 8CD6CE072E: from=<user(a)example.com>, size=880, nrcpt=1 (queue active) 16:04:16 dovecot: auth: Debug: master in: USER#0111#011user(a)example.com#011service=lda 16:04:16 dovecot: auth: Debug: prefetch(user(a)example.com): passdb didn't return userdb entries, trying the next userdb 16:04:16 dovecot: auth: Debug: sql(user(a)example.com): SELECT '/path-to-mailboxen/' || virtual_users.home AS home, uid , gid , quota as quota_rule FROM virtual_users WHERE email = 'user(a)example.com' AND status = 'A' 16:04:16 dovecot: auth: Debug: userdb out: USER#0111#011user@example.com#011home=/path-to-mailboxen/example.com/user#011uid=12345#011gid=12345#011quota_rule=*:storage=0 ^^^^^^^^^^^^^^^^^^^^^^ This shows that the database lookup works. The intended effect should be that the message is delivered to /path-to-mailboxen/example.com/user/Maidir/new 16:04:16 dovecot: lda(user(a)example.com)<5291><DDxBHYCw6F+rFAAApiCoHg>: Error: setegid(privileged) failed: Operation not permitted 16:04:16 dovecot: lda(user(a)example.com)<5291><DDxBHYCw6F+rFAAApiCoHg>: Error: Mailbox INBOX: open(/var/mail/user(a)example.com) failed: Permission denied (euid=12345(mailbox) egid=12345(mailbox) missing +w perm: /var/mail, we're not in group 8(mail), dir owned by 0:8 mode=0775) ^^^^^^^^^^^^^^^^^^^^^^ And this shows that dovecot-lda just ignores the result. 16:04:16 dovecot: lda(user(a)example.com)<5291><DDxBHYCw6F+rFAAApiCoHg>: Error: Mailbox INBOX: Failed to autocreate mailbox: Mailbox INBOX: open(/var/mail/user(a)example.com) failed: Permission denied (euid=12345(mailbox) egid=12345(mailbox) missing +w perm: /var/mail, we're not in group 8(mail), dir owned by 0:8 mode=0775) 16:04:16 dovecot: lda(user(a)example.com)<5291><DDxBHYCw6F+rFAAApiCoHg>: msgid=<20201226224933.014608(a)laptop.example.com>: save failed to open mailbox INBOX: Mailbox INBOX: Failed to autocreate mailbox: Mailbox INBOX: open(/var/mail/user(a)example.com) failed: Permission denied (euid=12345(mailbox) egid=12345(mailbox) missing +w perm: /var/mail, we're not in group 8(mail), dir owned by 0:8 mode=0775) 16:04:16 postfix/pipe[5284]: 8CD6CE072E: to=<user(a)example.com>, orig_to=<userA(a)example2.com>, relay=dovecot, delay=62083, delays=62083/0.04/0/0.04, dsn=4.3.0, status=deferred (temporary failure) In /etc/postfix/master.cf, I have this to call it: dovecot unix - n n - - pipe flags=DRhu user=_mailbox argv=/usr/lib/dovecot/deliver -f ${sender} -d ${user}@${domain} -a ${recipient} I've tried strace-ing dovecot-lda, but it didn't really help me to understand why it discards the result of the userdb lookup. Can anyone please provide a cluebat, please? Thanks, Toni

5 15

Re: Using dovecot with RoundCubeMail - where is the information for new mail in (blue coloured) directories?
by Scott Ruckh 01 Jan '21

01 Jan '21

On 2020-12-20 17:37, Philip Rhoades wrote: > @lbutlr, > > > On 2020-12-21 00:43, @lbutlr wrote: >> On 20 Dec 2020, at 04:05, Philip Rhoades <phil(a)pricom.com.au> wrote: >>> I guess that is what it seems to look like to me as well - but what >>> does that mean for what I am trying to do? - ie reset the blue folder >>> highlight arbitrarily? >> >> Sound like the Roundcube style choices are outside th purview of >> dovecot. > > > Hmm . . the first response I got here was that it was definitely an > IMAP thing . . I think he was unclear about the actual problem . . > > I will try the RCM forum . . > > Thanks, > > P. I am not sure I have understood this thread completely, but I am running dovecot/RoundCube. If a folder has new messages, then it has a badge that is dark blue (with the theme I am using) with the number of un-read messages. Otherwise it has a badge that is light-blue to indicate un-read messages only. Folders with no badges have zero un-read messages. So there is definitely a distinction for "new" messages.

2 1

migration from 2.0.16
by Barbara M. 01 Jan '21

01 Jan '21

I have an old server with CentOS 6.x and dovecot 2.0.16 (postfix-2.6.6 and roundcube), that was an update from a 1.x many years ago ... Users in /etc/passwd Mailbox format mbox some filtering via procmail About 5.000 users, 1 TB data (/var/mail + /home/users) Obviously I am searching for a smooth upgrade path (with no or minimal downtime and users problems) ;-) Until few days ago my idea was a CentOS 8.x new box with the standard default packages (dovecot-2.3.8, postfix-3.3, ...). Now this can be reconsidered. I suppose there will be a RockyLinux or something equivalent but if there is a good reason I can consider Debian or other OS if they have a decent EOL or some advantages. Anyway, the more relevant problem at the moment is collect info for the best approch to have a smooth dovecot upgrade. My dream is the possibility to configure a new server and rsync the data (/var/mail + /home/users), and, when the tests are satisfiable do the final sync and swap the IP, but I suppose deleting the .imap folders isn't a simple complete solution to compatibility problems. Any hints, links, experiences are appreciated. Thanks, B.

6 9

Initial Replication
by David Morsberger 01 Jan '21

01 Jan '21

I searched the archives and do not see a question/answer for this. Should I perform a set of ordered steps after setting up replication? I have setup dovecot on both ends with identical config except for the remote hostname. Main concern is the existing server gets replicated to the new server. I want nothing from new server replicated to the old server. Risking "Trial and error" and "crossing fingers” doesn’t work with production emails Specifically: Do I need to setup the mail directories for the various virtual users on the remote? If so, do the directories need to empty? Should I initially do a manually one-way synch using doveadm from the existing server? If so, is there a way of turning off automatic replication while the manual one runs? Anything else? T David

2 2

Imap client with ~7500 imap cmds ~250/~500 read() syscall
by Marc Roos 31 Dec '20

31 Dec '20

I am playing a bit with the monitoring, and I have noticed there is one client of the chart with ~7500, while the others are between ~17 and ~60 (dovecot_user_num_cmds). I assume this is related to the client, or is it possible something is wrong on the server side? Is someone having also such numbers or is this really strange. Is it possible to limit these cmd's?

3 8

mail-crypt when using passwd-file driver
by Adam Gould 31 Dec '20

31 Dec '20

Hi, I am just finishing my first personal email server build so I would really appreciate it if the response to my question can be spelled out in enough detail since I am struggling to fill in the gaps to get this working. I have scoured Google and the archives but I am not fully understanding the implementation for my setup. I am looking for a solution to encrypt email using a mechanism that increases the difficulty of decrypting my email. For example, having a plain-text decryption key on disk would not be suitable. From what I understand mail-crypt supports using the user password supplied via IMAP to decrypt email. Can someone explain how this technically works? i.e. is the private key encrypted in disk and then unlocked using the supplied password? Can someone also please step me through 1. how I would ammen the configuration below in order to set this up. 2. the command required to generate keys 3. Any help in understanding the limitations such as password changes or caveats around generating keys securely I am happy to take my notes and update the wiki to help others. Thanks, Adam # 2.3.8 (9df20d2db): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.8 (b7b03ba2) # OS: Linux 4.18.0-240.1.1.el8_3.x86_64 x86_64 Red Hat Enterprise Linux release 8.3 (Ootpa) # Hostname: mailserver.example.com debug_log_path = /var/log/dovecot-debug.log info_log_path = /var/log/dovecot-info.log lda_mailbox_autocreate = yes log_path = /var/log/dovecot.log log_timestamp = "%Y-%m-%d %H:%M:%S " mail_home = /var/mail/%d/%n/ mail_location = maildir:~/mail/ 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 namespace inbox { inbox = yes location = mailbox Archive { auto = create special_use = \Archive } mailbox Drafts { auto = create special_use = \Drafts } mailbox Junk { auto = create special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { auto = create special_use = \Trash } prefix = } passdb { args = scheme=CRYPT username_format=%n@%d /etc/dovecot/passdb driver = passwd-file } plugin { recipient_delimiter = - sieve = ~/.dovecot.sieve sieve_dir = ~/sieve sieve_global_dir = /etc/sieve/global/ } protocols = imap lmtp service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0600 user = postfix } } service imap-login { inet_listener imap { address = * port = 143 ssl = yes } } service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0600 user = postfix } } ssl_cert = </etc/letsencrypt/live/mail.example.com/fullchain.pem ssl_cipher_list = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384: DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA: ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256: DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384: AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH: !EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA ssl_dh = # hidden, use -P to show it ssl_key = # hidden, use -P to show it ssl_min_protocol = TLSv1.2 ssl_prefer_server_ciphers = yes userdb { args = uid=vmail gid=vmail home=/var/mail/%d/%n driver = static } protocol lmtp { mail_fsync = optimized mail_plugins = " sieve" recipient_delimiter = - }

2 1

Solr and FTS - assertion failure
by Antonino Esposito 31 Dec '20

31 Dec '20

Hi, in the latest weeks i'm working on the Solr integration and immediately i've faced the assertion failure errors, on 2.0.19, 2.2.9 and 2.3.11.3 servers in our network. Reading the thread on debian ML, I realize this issue is related to nested MIME and it affects large mailboxes In my case, the error in dovecot.log pairs with the following on solr.log and it seems the rows value has the same value of the last UID recorded in the mailbox. For your reference, here is the Solr logs, where *2276996170* is the value passed by Dovecot as rows number and it clearly don't fit with the rows data type. Have you had experienced the same behaviour? Is there a workaround? Thanks Antonino 2020-12-30 12:07:33.897 ERROR (qtp1162918744-918) [ x:qadisha] o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: For input string: "2276996170" at org.apache.solr.common.params.SolrParams.getInt(SolrParams.java:236) at org.apache.solr.search.QParser.getSortSpec(QParser.java:274) at org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:189) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:337) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2627) at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:795) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:568) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221) at org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) at org.eclipse.jetty.server.Server.handle(Server.java:500) at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383) at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:375) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806) at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.NumberFormatException: For input string: "2276996170" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Integer.parseInt(Integer.java:583) at java.lang.Integer.valueOf(Integer.java:766) at org.apache.solr.common.params.SolrParams.getInt(SolrParams.java:233) ... 46 more 2020-12-30 12:07:33.897 INFO (qtp1162918744-918) [ x:qadisha] o.a.s.c.S.Request [qadisha] webapp=/solr path=/select params={q={!lucene+q.op%3DAND}from:mykeyword+OR+to:mykeyword+OR+subject:mykeyword&fl=uid,score&sort=uid+asc&fq=% 2Bbox:6d2c381de797e95fbb160000c46e3ae7+%2Buser:info@qadisha.it&rows=2276996170&wt=xml} status=400 QTime=1

2 2