- dovecot - dovecot.org

v2.3.5.2 released
by Aki Tuomi 18 Apr '19

18 Apr '19

https://dovecot.org/releases/2.3/dovecot-2.3.5.2.tar.gz https://dovecot.org/releases/2.3/dovecot-2.3.5.2.tar.gz.sig Binary packages in https://repo.dovecot.org/ * CVE-2019-7524: Missing input buffer size validation leads into arbitrary buffer overflow when reading fts or pop3 uidl header from Dovecot index. Exploiting this requires direct write access to the index files. --- Aki Tuomi Open-Xchange oy

1 0

Problem with mysql backend and SSL ciphers
by TG Servers 18 Apr '19

18 Apr '19

3 3

Documentation update
by azurit＠pobox.sk 18 Apr '19

18 Apr '19

Hi guys, this page needs to be updated: https://wiki2.dovecot.org/MailLocation/Maildir#Control_files (link was from here: https://wiki2.dovecot.org/MailLocation) Section 'Control files' is mentioning only 2 files but, in fact, Dovecot will store some additional files in CONTROL location: dovecot-uidvalidity dovecot-uidvalidity.* subscriptions (anything more?) Even more, page https://wiki2.dovecot.org/MailLocation has missing note to CONTROL files location about storing files 'dovecot-uidlist' and 'dovecot-keywords' of INBOX inside .INBOX directory instead of root directory (as it's stored inside mailbox). Missing anything from above will cause re-downloading of all e-mails by e-mail clients! And finally, i'm attaching a Python script which will safely copy/move CONTROL files from mail_location to new location (btw, moving it on SSD storage caused quite high performance boost in our environment). azur

2 1

Full mail
by Yevgeny Kosarzhevsky 18 Apr '19

18 Apr '19

Hello, I am getting strange messages on logs and I cannot find any reason. Could someone point me on what's wrong with my dovecot configuration? ~# dovecot -n # 2.3.4.1 (f79e8e7e4): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.4 () # OS: Linux 4.9.0-8-amd64 x86_64 Debian 9 ext4 ~# grep 'full mail' //var/log/dovecot.log Apr 16 19:25:43 imap(phaoost(a)phaoost.net)<15956><bv4DlqqGQNC5LcCN>: Debug: Mailbox INBOX: UID 3: Opened mail because: full mail Apr 16 19:29:06 imap(phaoost(a)phaoost.net)<17588><U1oXyKqGKNG5LcCN>: Debug: Mailbox INBOX: UID 4: Opened mail because: full mail Apr 16 20:28:19 imap(phaoost(a)phaoost.net)<21808><pT01V6uGgtO5LcCN>: Debug: Mailbox INBOX: UID 6: Opened mail because: full mail Apr 16 22:22:38 imap(phaoost(a)phaoost.net)<32077><lQTltKyGItq5LcCN>: Debug: Mailbox INBOX: UID 7: Opened mail because: full mail Apr 16 22:55:57 imap(phaoost(a)phaoost.net)<3732><hw1UQ62GWt25LcCN>: Debug: Mailbox INBOX: UID 8: Opened mail because: full mail Apr 16 23:37:12 imap(phaoost(a)phaoost.net)<8139><+2dd262G3N+5LcCN>: Debug: Mailbox INBOX: UID 9: Opened mail because: full mail Apr 17 01:09:13 imap(phaoost(a)phaoost.net)<8041><BqWBiK+GAua5LcCN>: Debug: Mailbox Trash: UID 3: Opened mail because: full mail Apr 17 01:09:13 imap(phaoost(a)phaoost.net)<8041><BqWBiK+GAua5LcCN>: Debug: Mailbox Trash: UID 4: Opened mail because: full mail Apr 17 01:09:13 imap(phaoost(a)phaoost.net)<8041><BqWBiK+GAua5LcCN>: Debug: Mailbox Trash: UID 5: Opened mail because: full mail Apr 17 01:09:13 imap(phaoost(a)phaoost.net)<8041><BqWBiK+GAua5LcCN>: Debug: Mailbox Trash: UID 6: Opened mail because: full mail Apr 17 01:09:13 imap(phaoost(a)phaoost.net)<8041><BqWBiK+GAua5LcCN>: Debug: Mailbox Trash: UID 7: Opened mail because: full mail Apr 17 04:34:44 imap(phaoost(a)phaoost.net)<23874><PC06DLKGaoC5LcCN>: Debug: Mailbox INBOX: UID 10: Opened mail because: full mail Apr 17 05:45:21 imap(phaoost(a)phaoost.net)<17176><fcoRZLOGHIW5LcCN>: Debug: Mailbox INBOX: UID 11: Opened mail because: full mail Apr 17 07:00:10 imap(phaoost(a)phaoost.net)<5348><bG6Ub7SGKom5LcCN>: Debug: Mailbox INBOX: UID 12: Opened mail because: full mail Apr 17 07:35:58 imap(phaoost(a)phaoost.net)<8078><QsTyj7SGyom5LcCN>: Debug: Mailbox INBOX: UID 13: Opened mail because: full mail Apr 17 08:25:17 imap(phaoost(a)phaoost.net)<29005><Zyr3n7WGIJC5LcCN>: Debug: Mailbox INBOX: UID 14: Opened mail because: full mail Apr 17 10:36:54 imap(phaoost(a)phaoost.net)<31565><TcqvdreGwJi5LcCN>: Debug: Mailbox INBOX: UID 15: Opened mail because: full mail Apr 17 11:08:27 imap(phaoost(a)phaoost.net)<7864><0+xW57eGjJq5LcCN>: Debug: Mailbox INBOX/Spam: UID 1: Opened mail because: full mail Apr 17 11:09:11 imap(phaoost(a)phaoost.net)<7864><0+xW57eGjJq5LcCN>: Debug: Mailbox Spam: UID 27: Opened mail because: full mail Apr 17 11:09:11 imap(phaoost(a)phaoost.net)<7864><0+xW57eGjJq5LcCN>: Debug: Mailbox Spam: UID 28: Opened mail because: full mail Apr 17 12:09:12 imap(phaoost(a)phaoost.net)<25908><bXnRwLiGKJ+5LcCN>: Debug: Mailbox Spam: UID 33: Opened mail because: full mail Apr 17 13:19:38 imap(phaoost(a)phaoost.net)<20835><El6SvLmGEKG5LcCN>: Debug: Mailbox Spam: UID 34: Opened mail because: full mail Apr 17 16:50:57 imap(phaoost(a)phaoost.net)<14923><hkpHsLyGYKa5LcCN>: Debug: Mailbox Spam: UID 35: Opened mail because: full mail Apr 17 16:50:57 imap(phaoost(a)phaoost.net)<14923><hkpHsLyGYKa5LcCN>: Debug: Mailbox Spam: UID 36: Opened mail because: full mail Apr 17 18:50:56 imap(phaoost(a)phaoost.net)<14650><JJZsXb6GCq25LcCN>: Debug: Mailbox Spam: UID 37: Opened mail because: full mail Apr 17 18:50:56 imap(phaoost(a)phaoost.net)<14650><JJZsXb6GCq25LcCN>: Debug: Mailbox Spam: UID 38: Opened mail because: full mail -- Regards, Yevgeny

2 1

Sieve operation "send copy" not working since upgrade from dovecot 2.2.31-1 to 2.3.5.1-1
by Kristijan Savic - ratiokontakt GmbH 16 Apr '19

16 Apr '19

I hope that someone can help me here. Software: CentOS 7.6.1810, dovecot-2.3.5.1, dovecot-pigeonhole-2.3.5.1, exim 4.91-1 Example filter: # rule:[test] if header :contains "subject" "meow" { redirect :copy "ks(a)ratiokontakt.de"; } Mail log: Apr 16 11:29:02 frontend-17 dovecot: lmtp(testi(a)mrhoang.de)<25201><QPgZHF6gtVxxYgAARS1pjg>: sieve: msgid=<311099964.O2fbMfmo3K(a)ws-ks.intern.ratiokontakt.de>: failed to redirect message to <ks(a)ratiokontakt.de>: smtp(localhost): DATA failed: 552 Message header not CRLF terminated (permanent failure) Apr 16 11:29:02 frontend-17 dovecot: lmtp(testi(a)mrhoang.de)<25201><QPgZHF6gtVxxYgAARS1pjg>: sieve: msgid=<311099964.O2fbMfmo3K(a)ws-ks.intern.ratiokontakt.de>: stored mail into mailbox 'INBOX' Apr 16 11:29:02 frontend-17 dovecot: lmtp(testi(a)mrhoang.de)<25201><QPgZHF6gtVxxYgAARS1pjg>: sieve: Execution of script /usr/local/mail/0117/mrhoang.de/testi/.dovecot.sieve failed, but implicit keep was successful (user logfile /usr/local/mail/0117/mrhoang.de/ testi/.dovecot.sieve.log may reveal additional details) And in the: /.dovecot.sieve.log: sieve: info: started log at Apr 16 11:29:02. error: msgid=<311099964.O2fbMfmo3K(a)ws-ks.intern.ratiokontakt.de>: failed to redirect message to <ks(a)ratiokontakt.de>: smtp(localhost): DATA failed: 552 Message header not CRLF terminated (permanent failure) We are stumped. Any ideas? Regards, Kristijan Savic

2 2

Fwd: SOLR/Index?
by Larry Rosenman 15 Apr '19

15 Apr '19

forgot to reply all. ---------- Forwarded message --------- From: Larry Rosenman <larryrtx(a)gmail.com> Date: Mon, Apr 15, 2019 at 5:58 AM Subject: Re: SOLR/Index? To: John Fawcett <john(a)voipsupport.it> the local users (myself, my wife, a friend) can authenticate EITHER as <username> or <username>@lerctr.org. switching to all virtual users is NOT going to happen. If I login to roundcube with <user>@lerctr.org it finds the autoindexed mail. So, if I make everyone always authenticate as <user>@lerctr.org we should be fine. and change my script to do doveadm -u <user>@<domain> instead of depending on the local user running the cron job. question: Is there some way to have dovecot change what it sees to be <user>@lerctr.org when they login as <user>? On Mon, Apr 15, 2019 at 5:54 AM John Fawcett via dovecot < dovecot(a)dovecot.org> wrote: > On 15/04/2019 11:38, Larry Rosenman via dovecot wrote: > > ⌂63% [ler@thebighonker.lerctr.org:~] $ grep fts1970 mail/INBOX > ⌂67% [ler@thebighonker.lerctr.org:~] 1 $ mail -s "test fts1970" > ler(a)lerctr.org > test fts1970 > > test fts1970 > . > EOT > [ler@thebighonker.lerctr.org:~] $ mailq > [ler@thebighonker.lerctr.org:~] $ grep fts1970 mail/INBOX > Subject: test fts1970 > test fts1970 > test fts1970 > > > Apr 15 04:29:03 thebighonker exim[49528]: 1hFxvD-000Csq-P6 <= > ler(a)lerctr.org U=ler P=local S=388 > Apr 15 04:29:03 thebighonker dovecot[2507]: lmtp(49364): Connect from local > Apr 15 04:29:03 thebighonker dovecot[2507]: lmtp(ler(a)lerctr.org/49364): > save: box=INBOX, uid=175402, msgid=< > E1hFxvD-000Csq-P6(a)thebighonker.lerctr.org>, size=640, vsize=660, > from=Larry Rosenman <ler(a)lerctr.org>, subject=test fts1970, flags=() > Apr 15 04:29:03 thebighonker dovecot[2507]: lmtp(ler(a)lerctr.org/49364): > sieve: msgid=<E1hFxvD-000Csq-P6(a)thebighonker.lerctr.org>: stored mail > into mailbox 'INBOX' (subject=test fts1970 from=ler(a)lerctr.org size=660) > Apr 15 04:29:03 thebighonker dovecot[2507]: lmtp(49364): Disconnect from > local: Client has quit the connection (state=READY) > Apr 15 04:29:03 thebighonker exim[49535]: 1hFxvD-000Csq-P6 => ler < > ler(a)lerctr.org> R=localuser T=dovecot_lmtp S=404 C="250 2.0.0 < > ler(a)lerctr.org> 6ACWMN9OtFzUwAAAu+mOrA Saved" QT=0s DT=0s > Apr 15 04:29:03 thebighonker exim[49535]: 1hFxvD-000Csq-P6 Completed QT=0s > Apr 15 04:29:03 thebighonker dovecot[2507]: indexer-worker( > ler(a)lerctr.org/49366) Indexed 1 messages in INBOX (UIDs 175402..175402) > > > ⌂81% [ler@thebighonker.lerctr.org:~] $ doveadm search mailbox INBOX body > 'fts1970' > ⌂83% [ler@thebighonker.lerctr.org:~] $ > > > ⌂65% [ler@thebighonker.lerctr.org:~] 75 $ doveadm search -u ler(a)lerctr.org > mailbox INBOX body 'fts1970' > a53a143be44bda5bd4830000bbe98eac 175402 > [ler@thebighonker.lerctr.org:~] $ doveadm index -q INBOX > [ler@thebighonker.lerctr.org:~] $ doveadm search mailbox INBOX body > 'fts1970' > [ler@thebighonker.lerctr.org:~] $ doveadm fts rescan > [ler@thebighonker.lerctr.org:~] $ doveadm index -q INBOX > [ler@thebighonker.lerctr.org:~] $ doveadm search mailbox INBOX body > 'fts1970' > a53a143be44bda5bd4830000bbe98eac 175402 > [ler@thebighonker.lerctr.org:~] $ doveadm search -u ler(a)lerctr.org > mailbox INBOX body 'fts1970' > a53a143be44bda5bd4830000bbe98eac 175402 > [ler@thebighonker.lerctr.org:~] $ > > So, yes, your hypothesis is correct. > > Question: How can I make it consistent? > > I have a script that runs on the first of the month that does archiving, > and I have similar issues in that namespace: > ⌂67% [ler@thebighonker.lerctr.org:~] $ cat bin/archive-mail > #!/bin/sh > PATH=$PATH:/usr/local/bin > #Expects to be run after midnight on the first of the month > # to archive all the previous months mail > #Date Run: > TODAY=`date "+%Y-%m-%d"` > #last month in YYYY/MM > YEAR_LAST_MONTH=`date -v-1d "+%Y/%m"` > #1st of last month as 01-Mon-YYYY > FIRST_LAST_MONTH=`date -v-1d "+01-%b-%Y"` > echo 'TODAY=' ${TODAY} > echo 'YEAR_LAST_MONTH=' ${YEAR_LAST_MONTH} > echo 'FIRST_LAST_MONTH=' ${FIRST_LAST_MONTH} > # get a list of all the mailboxes with at least one real message > doveadm -f tab mailbox status vsize \* 2>/dev/null | > sed -e 1d | sort -k 1,1 | > awk 'BEGIN {FS="\t"} {if ($2 > 0) print $1}' | > while read i > do > echo `date` start ${i} > doveadm mailbox create "ARCHIVE/${YEAR_LAST_MONTH}/${i}" > doveadm -f tab mailbox status messages "${i}" > doveadm move "ARCHIVE/${YEAR_LAST_MONTH}/${i}" mailbox \ > "${i}" BEFORE ${TODAY} SINCE ${FIRST_LAST_MONTH} > doveadm -f tab mailbox status messages "${i}" > echo `date` done ${i} > done > ⌂64% [ler@thebighonker.lerctr.org:~] $ > > > The Exim config can be provided as well if necessary. > > ler & ler(a)lerctr.org *ARE THE SAME MAILBOX* > > At the moment it looks as though you have two sets of emails indexed in > solr. One is indexed under username (the one you are running mannually and > apparently the one used by roundcube too, but that's to be verified) and > another set being indexed by autoindex = yes option using the full email > address. Once you've got it working as you require, then you may want to > clean out solr and reindex with just one of them just to reduce volumes. > > Your setup seems to have a mix of users from mysql and from /etc/passwd. > Not sure if your mysql users are all mapped to real users or they have > their own mailboxes with domain included. Your solution will depend on what > you really need and if the setup is working correctly you may not want to > tweak it too much or other things may start breaking. > > The simplest thing that comes to mind (providing your manually indexed > mails show up in roundcube searches) is just to turn off autoindex and > schedule indexing from cron. As things stand I believe autoindex works well > with virtual users username@domain. You'll probably need to start off > with a rescan if you do this. > > If you can swith to all virtual users without local users then probably > you can use autoindex, but I can understand that may not be possible. For > sure I'd recommend doing it in a test environment first so you can be sure > of the configuration and then look at migrating your existing mailboxes > over to virtual users. > > John > > > > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: larryrtx(a)gmail.com US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: larryrtx(a)gmail.com US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

4 11

No CRLF in Pigeonhole's header?
by Wojciech Sychut 15 Apr '19

15 Apr '19

Hello, I have been told on Freenode's #dovecot to ask here. I have Exim 4.92 complaining about "Non-CRLF-terminated header, under CHUNKING: message abandoned" with redirects made by Pigeonhole 0.5.5 (with Dovecot 2.3.5.1). Please find relevant part of the traffic below, and help me determine whether Exim is correct on this. 0x0000: 4500 0954 0000 4000 8006 0000 7f00 0001 E..T..@......... 0x0010: 7f00 0001 6ea2 0019 8982 e279 d090 b820 ....n......y.... 0x0020: 8018 021e 0749 0000 0101 080a c345 2b51 .....I.......E+Q 0x0030: b382 853c 4d41 494c 2046 524f 4d3a 3c72 ...<MAIL.FROM:<r 0x0040: 4073 3066 2e6d 642e 6465 7664 6576 6465 @sxf.md.devdevde 0x0050: 762e 6e65 743e 0d0a 5243 5054 2054 4f3a v.net>..RCPT.TO: 0x0060: 3c63 6f6e 7461 6374 4072 6567 6973 2e74 <contact(a)regis.t 0x0070: 6563 683e 0d0a 4244 4154 2032 3235 3420 ech>..BDAT.2254. 0x0080: 4c41 5354 0d0a 582d 5369 6576 653a 2050 LAST..X-Sieve:.P 0x0090: 6967 656f 6e68 6f6c 6520 5369 6576 6520 igeonhole.Sieve. 0x00a0: 302e 352e 3520 2832 3438 3362 3038 3529 0.5.5.(2483b085) 0x00b0: 0a58 2d53 6965 7665 2d52 6564 6972 6563 .X-Sieve-Redirec 0x00c0: 7465 642d 4672 6f6d 3a20 7240 7330 662e ted-From:.r@sxf. With Dovecot 2.2.36 + Pigeonhole 0.4.24.1 and required minimum of version-related configuration changes - redirection works properly. Related Exim code fragment: https://github.com/Exim/exim/blob/master/src/src/receive.c#L2222 Thank you, -- Wojtek Sychut

2 1

rsync sdbox, no new mails?
by Jakob Curdes 15 Apr '19

15 Apr '19

Hello, I had to restore a mailserver from a backup to replace a system with problems that is still live. I did a 1:1 restore as far as possible from a backup, then rsynced the /var/vmail/ directory, where we have all the mailboxes, in sdbox format. So both directories should be the same. After syncing, I started dovecot. I can see the mails until to the point of the backup, but not the newer ones ,although they seem to be present in the "cur" directory. I thought with sdbox it is all in the index files that have been transferred with the mails? Or am I missing a place that has to be synced? Thank you for hints, Jakob

2 2

LDAP iterate (dovecoc 2.2.27)
by Debreczeni Attila 15 Apr '19

15 Apr '19

Dear Dovecot Team, We would like to use the LDAP iterate for dovecot replication, but I got this error: dovecot: auth-worker(10149): Error: ldap(*): ldap_search(base=ou=mail,o=asd,c=TLD filter=(objectClass=inetMailUser) failed: Size limit exceeded dovecot: replicator: Error: User listing returned failure dovecot: replicator: Error: listing users failed, can't replicate existing data When I check the "doveadm replicator status": ... Total number of known users 1200 But we have more than 10.000 users. When I run the ldapsearch manually, I get the full list of the mail addresses. Who can I fix it? Thank you, Attila # dovecot --version 2.2.27 (c0f36b0) # dovecot -n | filtered # 2.2.27 (c0f36b0): /etc/dovecot/dovecot.conf # Pigeonhole version 0.4.16 (fed8554) # OS: Linux 4.9.0-6-amd64 x86_64 Debian 9.8 auth_worker_max_count = 150 default_vsz_limit = 512 M doveadm_password = # hidden, use -P to show it doveadm_port = *** mail_gid = vmail mail_plugins = " quota notify replication" namespace inbox { ... } passdb { args = /etc/dovecot/dovecot-ldap.conf.ext driver = ldap } plugin { mail_replica = tcp:REMOTE_IP } replication_dsync_parameters = -d -N -1 -l 30 -U service aggregator { fifo_listener replication-notify-fifo { user = vmail } unix_listener replication-notify { user = vmail } } service auth { inet_listener { address = LOCAL_IP port = LOCAL_PORT } unix_listener auth-userdb { group = vmail mode = 0600 user = vmail } } service dict { unix_listener dict { group = vmail mode = 0600 user = vmail } } service lmtp { inet_listener lmtp { address = LOCAL_IP port = LOCAL_PORT } } service replicator { process_min_avail = 1 unix_listener replicator-doveadm { mode = 0600 } } userdb { args = /etc/dovecot/dovecot-domain-ldap.conf.ext driver = ldap result_success = continue-ok } userdb { args = /etc/dovecot/dovecot-ldap.conf.ext driver = ldap result_failure = return-fail } protocol imap { ... } protocol pop3 { ... } # grep -v '^ *$#.*$\?$' dovecot-ldap.conf.ext uris = ldaps://ldap.URL dn = uid=auth,o=domain,c=TLD dnpass = **** sasl_bind = no tls_ca_cert_dir = /etc/ssl/certs tls_require_cert = demand ldap_version = 3 base = ou=mail,o=asd,c=TLD deref = never scope = subtree user_attrs = =home=/dev/null/%Ld/%L{ldap:uid}, mailQuota=quota_rule=*:bytes=%$ user_filter = (objectClass=inetMailUser) pass_attrs = userPassword=password pass_filter = (objectClass=inetMailUser) iterate_attrs = mail=user iterate_filter = (objectClass=inetMailUser) default_pass_scheme = PLAIN

1 0

LDAP iterate (dovecoc 2.2.27)
by Debreczeni Attila 15 Apr '19

15 Apr '19

Dear Dovecot Team, We would like to use the LDAP iterate for dovecot replication, but I got this error: dovecot: auth-worker(10149): Error: ldap(*): ldap_search(base=ou=mail,o=asd,c=TLD filter=(objectClass=inetMailUser) failed: Size limit exceeded dovecot: replicator: Error: User listing returned failure dovecot: replicator: Error: listing users failed, can't replicate existing data When I check the "doveadm replicator status": ... Total number of known users 1200 But we have more than 10.000 users. When I run the ldapsearch manually, I get the full list of the mail addresses. Who can I fix it? Thank you, Attila # dovecot --version 2.2.27 (c0f36b0) # dovecot -n | filtered # 2.2.27 (c0f36b0): /etc/dovecot/dovecot.conf # Pigeonhole version 0.4.16 (fed8554) # OS: Linux 4.9.0-6-amd64 x86_64 Debian 9.8 auth_worker_max_count = 150 default_vsz_limit = 512 M doveadm_password = # hidden, use -P to show it doveadm_port = *** mail_gid = vmail mail_plugins = " quota notify replication" namespace inbox { ... } passdb { args = /etc/dovecot/dovecot-ldap.conf.ext driver = ldap } plugin { mail_replica = tcp:REMOTE_IP } replication_dsync_parameters = -d -N -1 -l 30 -U service aggregator { fifo_listener replication-notify-fifo { user = vmail } unix_listener replication-notify { user = vmail } } service auth { inet_listener { address = LOCAL_IP port = LOCAL_PORT } unix_listener auth-userdb { group = vmail mode = 0600 user = vmail } } service dict { unix_listener dict { group = vmail mode = 0600 user = vmail } } service lmtp { inet_listener lmtp { address = LOCAL_IP port = LOCAL_PORT } } service replicator { process_min_avail = 1 unix_listener replicator-doveadm { mode = 0600 } } userdb { args = /etc/dovecot/dovecot-domain-ldap.conf.ext driver = ldap result_success = continue-ok } userdb { args = /etc/dovecot/dovecot-ldap.conf.ext driver = ldap result_failure = return-fail } protocol imap { ... } protocol pop3 { ... } # grep -v '^ *$#.*$\?$' dovecot-ldap.conf.ext uris = ldaps://ldap.URL dn = uid=auth,o=domain,c=TLD dnpass = **** sasl_bind = no tls_ca_cert_dir = /etc/ssl/certs tls_require_cert = demand ldap_version = 3 base = ou=mail,o=asd,c=TLD deref = never scope = subtree user_attrs = =home=/dev/null/%Ld/%L{ldap:uid}, mailQuota=quota_rule=*:bytes=%$ user_filter = (objectClass=inetMailUser) pass_attrs = userPassword=password pass_filter = (objectClass=inetMailUser) iterate_attrs = mail=user iterate_filter = (objectClass=inetMailUser) default_pass_scheme = PLAIN

1 0

Re: SOLR/Index?
by Larry Rosenman 15 Apr '19

15 Apr '19

full solr.log at: https://www.lerctr.org/~ler/solr.log The search DOES make it to SOLR: ⌂77% [ler@thebighonker.lerctr.org:~] 130 $ grep sysutils /var/log/solr/solr.log 2019-04-14 18:31:34.749 INFO (qtp349420578-7538) [ x:dovecot] o.a.s.c.S.Request [dovecot] webapp=/solr path=/select params={q={!lucene+q.op%3DAND}(hdr:sysutils\/+OR+body:sysutils\/)&fl=uid,score&sort=uid+asc&fq=%2Bbox:8097632f69627b5b58950000bbe98eac+%2Buser:ler&rows=22644&wt=xml} hits=0 status=0 QTime=460 Pick showing subjects: https://www.lerctr.org/~ler/sysutils_mail.png What else? I'm happy to provide access. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: larryrtx(a)gmail.com US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

3 11

SOLR/Index?
by Larry Rosenman 15 Apr '19

15 Apr '19

Given all the discussion on FTS/Solr, etc, I have a question: I have autoindex set, and searching in roundcube most of the time does NOT find things, HOWEVER if I do: doveadm fts rescan doveadm index I can find things in the mailboxes. WHY? (doveconf -n attached). -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: larryrtx(a)gmail.com US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

2 1

Re: dovecot Digest, Vol 192, Issue 52
by Peter Mogensen 15 Apr '19

15 Apr '19

On 4/14/19 4:04 PM, dovecot-request(a)dovecot.org wrote: >> Solr ships with autoCommit set to 15 seconds and openSearcher set to >> false on the autoCommit.? The autoSoftCommit setting is not enabled by >> default, but depending on how the index was created, Solr might try to >> set autoSoftCommit to 3 seconds ... which is WAY too short. I just run with the default. 15s autoCommit and no autoSoftCommit >> This thread says that dovecot is sending explicit commits.? I see explicit /update req. with softCommit and waitSearcer=true in a tcpdump. >> One thing >> that might be happening to exceed 60 seconds is an extremely long >> commit, which is usually caused by excessive cache autowarming, but >> might be related to insufficient memory.? The max heap setting on an >> out-of-the-box Solr install (5.0 and later) is 512MB.? That's VERY >> small, and it doesn't take much index data before a much larger heap >> is required. I run with SOLR_JAVA_MEM="-Xmx8g -Xms2g" > I looked into the code (version 2.3.5.1): This is 2.2.35. I haven't checked the source difference to 2.3.x I must admit. > I immagine that one of the reasons dovecot sends softCommits is because > without autoindex active and even if mailboxes are periodically indexed > from cron, the last emails received with be indexed at the moment of the > search.? I expect that dovecot has to because of it's default behavior by only bringing the index up-to-date just before search. So it has towait for the index result to be available if there's been any new mails indexed. > 1) a configurable batch size would enable to tune the number of emails > per request and help stay under the 60 seconds hard coded http request > timeout. A configurable http timeout would be less useful, since this > will potentially run into other timeouts on solr side. Being able to configure it is great. But I don't think it solves much. I recompiled with 100 as batch size and it still ended in timeouts. Then I recompiled with 10min timeout and now I see all the batches completing and their processesing time is mostly between 1 and 2 minutes (so all would have failed). To me it looks like Solr just takes too long time to index. This is no small machine. It's a 20 core Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz and for this test it's not doing anything else, so I'm a bit surprised that even with only a few users this takes so long time. /Peter

2 1

Re: Solr connection timeout hardwired to 60s
by Peter Mogensen 15 Apr '19

15 Apr '19

On 4/4/19 6:47 PM, dovecot-request(a)dovecot.org wrote: > For a typical Solr index, 60 seconds is an eternity. Most people aim > for query times of 100 milliseconds or less, and they often achieve > that goal. I'm pretty sure I get these while indexing, not querying. Apr 04 16:44:50 host dovecot[114690]: indexer-worker(me(a)example.com): Error: fts_solr: Indexing failed: Request timed out (Request queued 66.015 secs ago, 1 attempts in 66.005 secs, 63.146 in http ioloop, 0.000 in other ioloops, connected 94.903 secs ago) /Peter

5 8

Fwd: Problem with solr working, but not indexing
by TG Servers 14 Apr '19

14 Apr '19

2 2

Problem with solr working, but not indexing
by TG Servers 14 Apr '19

14 Apr '19

2 1

Re: Solr connection timeout hardwired to 60s
by Peter Mogensen 14 Apr '19

14 Apr '19

sorry... I got distracted half way and forgot to put a meaningfull subject so the archive could figure out the thread. - resending. On 4/14/19 4:04 PM, dovecot-request(a)dovecot.org wrote: >> Solr ships with autoCommit set to 15 seconds and openSearcher set to >> false on the autoCommit.? The autoSoftCommit setting is not enabled by >> default, but depending on how the index was created, Solr might try to >> set autoSoftCommit to 3 seconds ... which is WAY too short. I just run with the default. 15s autoCommit and no autoSoftCommit >> This thread says that dovecot is sending explicit commits.? I see explicit /update req. with softCommit and waitSearcer=true in a tcpdump. >> One thing >> that might be happening to exceed 60 seconds is an extremely long >> commit, which is usually caused by excessive cache autowarming, but >> might be related to insufficient memory.? The max heap setting on an >> out-of-the-box Solr install (5.0 and later) is 512MB.? That's VERY >> small, and it doesn't take much index data before a much larger heap >> is required. I run with SOLR_JAVA_MEM="-Xmx8g -Xms2g" > I looked into the code (version 2.3.5.1): This is 2.2.35. I haven't checked the source difference to 2.3.x I must admit. > I immagine that one of the reasons dovecot sends softCommits is because > without autoindex active and even if mailboxes are periodically indexed > from cron, the last emails received with be indexed at the moment of the > search.? I expect that dovecot has to because of it's default behavior by only bringing the index up-to-date just before search. So it has towait for the index result to be available if there's been any new mails indexed. > 1) a configurable batch size would enable to tune the number of emails > per request and help stay under the 60 seconds hard coded http request > timeout. A configurable http timeout would be less useful, since this > will potentially run into other timeouts on solr side. Being able to configure it is great. But I don't think it solves much. I recompiled with 100 as batch size and it still ended in timeouts. Then I recompiled with 10min timeout and now I see all the batches completing and their processesing time is mostly between 1 and 2 minutes (so all would have failed). To me it looks like Solr just takes too long time to index. This is no small machine. It's a 20 core Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz and for this test it's not doing anything else, so I'm a bit surprised that even with only a few users this takes so long time. /Peter

2 2

Re: Mail account brute force / harassment
by Odhiambo Washington 14 Apr '19

14 Apr '19

On Thu, 11 Apr 2019 at 13:24, Marc Roos via dovecot <dovecot(a)dovecot.org> wrote: > > > Say for instance you have some one trying to constantly access an > account > > > Has any of you made something creative like this: > > * configure that account to allow to login with any password > * link that account to something like /dev/zero that generates infinite > amount of messages > (maybe send an archive of virusses?) > * transferring TB's of data to this harassing client. > > I think it would be interesting to be able to do such a thing. > > Instead of being evil, just use fail2ban to address this problem :-) -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", grep ^[^#] :-)

10 24

permissions for quota-status
by Andreas Meyer 14 Apr '19

14 Apr '19

Hello! doveconf --version 2.2.36 I want to move to a new server with dovecot but get an error Error: service(quota-status): listen(*, 12340) failed: Permission denied when I define service quota-status { executable = quota-status -p postfix inet_listener { port = 12340 } client_limit = 1 } private]# ll insgesamt 0 srw-rw-rw-. 1 postfix postfix 0 14. Apr 15:05 anvil srw-rw-rw-. 1 postfix postfix 0 14. Apr 15:05 bounce srw-rw-rw-. 1 postfix postfix 0 14. Apr 15:05 defer srw-rw-rw-. 1 postfix postfix 0 14. Apr 15:05 discard srw-------. 1 postfix postfix 0 14. Apr 15:08 dovecot-lmtp srw-rw-rw-. 1 postfix postfix 0 14. Apr 15:05 error srw-rw-rw-. 1 postfix postfix 0 14. Apr 15:05 lmtp srw-rw-rw-. 1 postfix postfix 0 14. Apr 15:05 local srw-rw-rw-. 1 postfix postfix 0 14. Apr 15:05 proxymap srw-rw-rw-. 1 postfix postfix 0 14. Apr 15:05 proxywrite srw-rw----. 1 postfix postfix 0 14. Apr 14:58 quota-status srw-rw-rw-. 1 postfix postfix 0 14. Apr 15:05 relay srw-rw-rw-. 1 postfix postfix 0 14. Apr 15:05 retry srw-rw-rw-. 1 postfix postfix 0 14. Apr 15:05 rewrite srw-rw-rw-. 1 postfix postfix 0 14. Apr 15:05 scache srw-rw-rw-. 1 postfix postfix 0 14. Apr 15:05 smtp srw-rw-rw-. 1 postfix postfix 0 14. Apr 15:05 tlsmgr srw-rw-rw-. 1 postfix postfix 0 14. Apr 15:05 trace srw-rw-rw-. 1 postfix postfix 0 14. Apr 15:05 verify srw-rw-rw-. 1 postfix postfix 0 14. Apr 15:05 virtual Don't know what's wrong. Can someone help? Kind regards Andreas -- PGP-Fingerprint: D392 5D21 0299 63D7 5BAE 4562 1E56 B2EA 81A2 59F1

2 1

nginx configuration to pass x-originating-ip
by André Rodier 14 Apr '19

14 Apr '19

Hello, There is a bug in SOGo, as it sends the original IP after successful login, and not before the login process. I traced the bug to the source code. https://sogo.nu/bugs/view.php?id=2979. Then, in my research, I found this old thread: https://forum.nginx.org/read.php?29,237299,237367#msg-237367 Can I use Nginx as an IMAP proxy to add the missing ID. I suspect this is something that can be achieved? I already have an Nginx for the SOGo front-end, so I would add another one for the IMAP proxy. With a little bit of luck, I should be able to pass the original IP between the two servers Does anyone has a working example? Thanks, André -- André Rodier HomeBox: https://github.com/progmaticltd/homebox

1 0

Post login scripts environment
by André Rodier 14 Apr '19

14 Apr '19

Dear Dovecot users, I am running Dovecot 2.2.27 on Debian Stretch, no issue so far. I wonder if there is a way to pass the remote IP address, in an environment variable, in the post login script. My Post login scripts are working well, except that when the server is accessed through a webmail (Roundcube or SOGo), the remote IP address is systematically 127.0.0.1. The other question I have is, is it possible to pass the user agent of the email client used to access the server? I know this can be easily forged, but I would like to log it. Thanks for your insight. -- André Rodier

2 6

Using userdb/passdb data in director_username_hash
by Mark Moseley 12 Apr '19

12 Apr '19

TL;DR: Can director_username_hash use %{userdb:...} or %{passdb:...} ? ==================================== This is on Ubuntu Precise, running dovecot 2.2.36. It's a fully production, director-ized env, so assume everything is working correctly. Happy to post doveconf if it's relevant but wanted to ask a general question first. I was curious if there's a way to get userdb/passdb data into director_username_hash. Currently, we've got default hashing (on %u). I'm returning a SQL field called 'real_username' (the owner of the mailbox, so almost never the same as %u). I'd like (for mdbox reasons) to hash on that rather than %u. My test SQL is returning (this is just a chunk -- it's duplicated for testing): UserName AS userdb_real_username, UserName AS real_username I can see in my director boxes that it's at least picking up the latter: passdb out: PASS 1 user=tesbox(a)mailbox.com proxy=y real_username=testuser Is it possible to inject 'real_username' into director_username_hash? That is, I'd rather hash on 'testuser' instead of 'testbed'. I've been trying different permutations on my director boxes with no luck. director_username_hash = %{userdb:real_username} director_username_hash = %{passdb:real_username} director_username_hash = %{userdb:userdb_real_username} director_username_hash = %{passdb:userdb_real_username} With any of those settings, every mailbox gets hashed to the same backend, so I'm guessing it's not getting anything useful (i.e. probably resolving to the same empty string and hashing on that -- or perhaps is just hashing on the literal string, e.g. "%{userdb:real_username}" ). And I'm not even sure if director_username_hash has access to any passdb/userdb data. Is there a debug setting that would show what string director is using to do the hashing? Current debug settings are: auth_debug = yes auth_debug_passwords = yes mail_debug = yes but not a peep as to the string that director is hashing on.

2 2

Migrating from external server to Dovecot (doveadm sync issues)
by Sven Strickroth 12 Apr '19

12 Apr '19

Hi, I'm experiencing serious issues when using doveadm sync not working at all or do not properly sync. I wanted to use this for migrating external mailboxes to my server (in order to overcome the time when some servers/clients still use the old server and some already the my server). I tried to find a few steps in order to replicate this: For testing purposes I simulate both the remote and local server on my Dovecot instance. I created remote(a)DOMAIN.TLD and local(a)DOMAIN.TLD both use mdbox and are empty (i.e., the mail_location is still non-existent). Then I send two mails to remote(a)DOMAIL.TLD (Subjects: Test1 and Test2). Start backup remote IMAP account (remote(a)DOMAIN.TLD) to local account (local(a)DOMAIN.TLD) * doveadm -o imapc_user="remote(a)DOMAIN.TLD" -o imapc_password="PW" -o imapc_host="localhost" -o mail_prefetch_count=20 -o imapc_features="rfc822.size fetch-headers" backup -R -u local(a)DOMAIN.TLD imapc: (without this I often got errors such as "Error: Backend didn't update mailbox Trash GUID" on sync runs, which seems to be an unrecoverable error). Now the two mailboxes seem to be the same (can confirm this when logging into the two mailboxes). Now, run first sync: * doveadm -o imapc_user="remote(a)DOMAIN.TLD" -o imapc_password="PW" -o imapc_host="localhost" -o mail_prefetch_count=20 -o imapc_features="rfc822.size fetch-headers" sync -R -u local(a)DOMAIN.TLD imapc: Seems to work and does nothing at the moment. Deliver one message to local(a)DOMAIN.TLD (Subject Test3). * doveadm -o imapc_user="remote(a)DOMAIN.TLD" -o imapc_password="PW" -o imapc_host="localhost" -o mail_prefetch_count=20 -o imapc_features="rfc822.size fetch-headers" sync -R -u local(a)DOMAIN.TLD imapc: Now Test1,2,3 are in both mailboxes (further runs do change nothing). Everything OK up the here. Now deliver one messages to remote(a)DOMAIN.TLD (Test4) and delete one old message (Test3). Deliver two messages to local(a)DOMAIN.TLD (Subjects Test5 and Test6) and delete one message (Test2). In sum both mailboxes look like this: remote(a)DOMAIN.TLD has Test1,2,4 and local(a)DOMAIN.TLD has 1,3,5,6. Now sync: * doveadm -o imapc_user="remote(a)DOMAIN.TLD" -o imapc_password="PW" -o imapc_host="localhost" -o mail_prefetch_count=20 -o imapc_features="rfc822.size fetch-headers" sync -R -u local(a)DOMAIN.TLD imapc: dsync(local(a)DOMAIN.TLD): Warning: Mailbox changes caused a desync. You may want to run dsync again: 3 UIDs changed due to UID conflicts Rerun again and see that mails start duplicating and deletings are not synced: remote(a)DOMAIN.TLD: Test1,2,4,3,5,6,5,6,6,5,3,4 (12 mails) and local(a)DOMAIN.TLD: 1,6,4,3,5,6,4,3,5,6,5 (11 mails) When I re-run again I sometimes see the above error message again, mails keep duplicating in both mailboxes and the mailboxes are not synced at all. Am I using doveadm sync wrongly? Is there a way to use "sync" directly w/o backup from the beginning (i.e., how to get rid of the error "Error: Backend didn't update mailbox Trash GUID"). Context: # 2.2.27 (c0f36b0): /etc/dovecot/dovecot.conf # Pigeonhole version 0.4.16 (fed8554) # OS: Linux 4.9.0-8-amd64 x86_64 Debian 9.8 imap_client_workarounds = delay-newmail I can't upgrade to latest Dovecot right now. :( -- Best regards, Sven Strickroth PGP key id F5A9D4C4 @ any key-server

1 0

Mail account brute force / harassment
by Marc Roos 12 Apr '19

12 Apr '19

Say for instance you have some one trying to constantly access an account Has any of you made something creative like this: * configure that account to allow to login with any password * link that account to something like /dev/zero that generates infinite amount of messages (maybe send an archive of virusses?) * transferring TB's of data to this harassing client. I think it would be interesting to be able to do such a thing.

3 2

Emails redownloading
by azurit＠pobox.sk 12 Apr '19

12 Apr '19

Hi, recently, we had a problem on one of our mail servers and, after reboot, HDD with emails wasn't mounted into system. Until we fixed it, LOTS of users logged in (Dovecot allowed login and recreated directory structure of mailboxes) and saw empty mailboxes. Now they are redownloading all email, which isn't fun, as it's about 2 TB of data. Anyway, is there a way how to prevent this in the future? Can i set Dovecot to disallow logins in such situations? Thanks. azur

3 5