- dovecot - dovecot.org

V1 Dovecot POP3 index migrate to V3
by Umut Arus 26 Apr '17

26 Apr '17

Hi, I've very old Dovecot version so I'm trying to migrate new disk and current version of dovecot. But POP3 accounts have "version 1" .INBOX/dovecot-uidlist files so clients download the messages again. How can achieve not to download to mailbox after copy to new disk? Is there any script or something to migrate index v1 to v3? thanks for your suggestions.

2 2

error ssl stacked error routines
by Poliman - Serwis 26 Apr '17

26 Apr '17

Hi I have configured one line in postfix main.cf (after configure each line I check /var/log/mail.err): smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem After setup above line I have error in above log file (these 4 lines looped): Apr 25 14:08:09 serwer-1 dovecot: imap-login: Error: SSL: Stacked error: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol Apr 25 14:08:09 serwer-1 dovecot: imap-login: Error: SSL: Stacked error: error:1408A10B:SSL routines:ssl3_get_client_hello:wrong version number Apr 25 14:08:51 serwer-1 dovecot: imap-login: Error: SSL: Stacked error: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac Apr 25 14:08:51 serwer-1 dovecot: imap-login: Error: SSL: Stacked error: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher Apr 25 14:14:25 serwer-1 dovecot: pop3-login: Error: SSL: Stacked error: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher Apr 25 14:10:51 serwer-1 dovecot: pop3-login: Error: SSL: Stacked error: error:14094085:SSL routines:ssl3_read_bytes:ccs received early Apr 25 14:09:16 serwer-1 dovecot: imap-login: Error: SSL: Stacked error: error:1408A0E3:SSL routines:ssl3_get_client_hello:parse tlsext And second thing: smtpd_sasl_security_options=noanonymous,noplaintext smtpd_sasl_tls_security_options=noanonymous,noplaintext These two lines in main.cf postfix file generate error no SASL authentication method. What should be configured in Dovecot to avoid both problems? -- *Pozdrawiam / Best Regards* *Piotr Bracha* *tel. 534 555 877* *serwis(a)poliman.pl <serwis(a)poliman.pl>*

1 0

Issue with POP3s TLS/SSL on port 995 on Outlook 2016
by Bhushan Bhosale 26 Apr '17

26 Apr '17

Dear Team, I'm facing issue with POP3s TLS/SSL on port 995 only for outlook2016. It's working fine with dovecot v2.2.28 on test environment. Is the dovecot v2.2.28 is stable released? I can upgrade the version from v2.1.17 to v2.2.28 on production if its stable version. Kindly confirm and provide the proper solution. Thanks and Regards, Bhushan Previous Mail:==========I have faced issue with email downloading in the email client by using pop3s SSL port 995 in dovecot v2.1.17 for outlook client 2016 on production environment. As per my troubleshooting on my test environment, I have upgraded dovecot version v2.2.28, and changed paramer "ssl_dh_parameters_length = 2048" and "verbose_ssl = yes", The issue seems to be resolved in dovecot v2.2.28. What can i do to resolve this issue in dovecot v2.1.17? Kindly help.

4 5

building Dovecot in Debian 9
by KT Walrus 26 Apr '17

26 Apr '17

I’m trying to build Dovecot 2.2.29.1 in a Docker container today and have the following error in ./configure: checking for shadow.h... yes checking for pam_start in -lpam... no checking for auth_userokay... no checking for mysql_config... mysql_config checking for mysql_init in -lmysqlclient... no configure: error: Can't build with MySQL support: libmysqlclient not found #> find / -name libmysqlclient\* /usr/share/doc/libmysqlclient20 /usr/share/lintian/overrides/libmysqlclient20 /usr/lib/x86_64-linux-gnu/libmysqlclient.so.20.3.5 /usr/lib/x86_64-linux-gnu/libmysqlclient.so.20 /var/lib/dpkg/info/libmysqlclient20:amd64.triggers /var/lib/dpkg/info/libmysqlclient20:amd64.shlibs /var/lib/dpkg/info/libmysqlclient20:amd64.list /var/lib/dpkg/info/libmysqlclient20:amd64.md5sums I have installed MySQL 5.7.18 Debian 9 packages (including the libmysqlclient-dev package) from the MySQL repo. I’m not an expert, but is there a bug in the "./configure --prefix=/usr --sysconfdir=/etc --with-mysql”? I’ve been building Dovecot with this Dockerfile using Ubuntu 16.04 for a while now without issue. Do I need some extra ./configure option to get it to find libmysqlclient.so.20? Kevin

2 7

Streaming out?
by Michael Segel 26 Apr '17

26 Apr '17

Hi, Has anyone tried to write out a mail stream to Kafka? Are there any good write ups on this feature? Can you split the mail so that you still write to a MailDir and also write to a stream? Thx -Mike

1 0

fts error recovery
by Daniel Miller 26 Apr '17

26 Apr '17

When a message is received, that is supposed to be added to the fts index, and an fts error occurs (like the Solr server is offline for some reason) - Dovecot logs that error and stores the message. Later, the fts system is available and new messages are added to the fts index without issue. Will the "missed" messages get added? Or would this require a manual re-indexing? -- Daniel

1 0

namespace alias issues?
by Kelsey Cummings 25 Apr '17

25 Apr '17

The Courier IMAP backwards compatibility section in the Namespaces wiki suggests that hidden aliased namespace can cause problems for some clients but doesn't quantify the extent or likelihood of running into these problems. Does anyone with real world experience with similar configurations have any feedback? -- kelsey.cummings(a)sonic.com sonic.net, inc. System Architect 2260 Apollo Way 707.522.1000 Santa Rosa, CA 95407

1 0

Host ... is being updated before previous update had finished
by Mark Moseley 24 Apr '17

24 Apr '17

We just had a bunch of backend boxes go down due to a DDoS in our director cluster. When the DDoS died down, our director ring was a mess. Each box had thousands (and hundreds per second, which is a bit much) of log lines like the following: Apr 03 19:59:29 director: Warning: director(10.1.20.10:9090/left): Host 10.1.17.15 is being updated before previous update had finished (up -> down) - setting to state=down vhosts=100 Apr 03 19:59:29 director: Warning: director(10.1.20.10:9090/left): Host 10.1.17.15 is being updated before previous update had finished (down -> up) - setting to state=up vhosts=100 Apr 03 19:59:29 director: Warning: director(10.1.20.10:9090/left): Host 10.1.17.15 is being updated before previous update had finished (up -> down) - setting to state=down vhosts=100 Apr 03 19:59:29 director: Warning: director(10.1.20.10:9090/left): Host 10.1.17.15 is being updated before previous update had finished (down -> up) - setting to state=up vhosts=100 Apr 03 19:59:29 director: Warning: director(10.1.20.10:9090/left): Host 10.1.17.15 is being updated before previous update had finished (up -> down) - setting to state=down vhosts=100 Apr 03 19:59:29 director: Warning: director(10.1.20.2:9090/right): Host 10.1.17.15 is being updated before previous update had finished (down -> up) - setting to state=up vhosts=100 Apr 03 19:59:29 director: Warning: director(10.1.20.2:9090/right): Host 10.1.17.15 is being updated before previous update had finished (up -> down) - setting to state=down vhosts=100 Apr 03 19:59:29 director: Warning: director(10.1.20.2:9090/right): Host 10.1.17.15 is being updated before previous update had finished (down -> up) - setting to state=up vhosts=100 Apr 03 19:59:29 director: Warning: director(10.1.20.2:9090/right): Host 10.1.17.15 is being updated before previous update had finished (up -> down) - setting to state=down vhosts=100 Apr 03 19:59:29 director: Warning: director(10.1.20.2:9090/right): Host 10.1.17.15 is being updated before previous update had finished (down -> up) - setting to state=up vhosts=100 This was on every director box and the status of all of the directors in 'doveadm director ring status' was 'handshaking'. Here's a sample packet between directors: 19:51:23.552280 IP 10.1.20.10.56670 > 10.1.20.1.9090: Flags [P.], seq 4147:5128, ack 0, win 0, options [nop,nop,TS val 1373505883 ecr 1721203906], length 981 Q. [f.|.HOST 10.1.20.10 9090 1006732 10.1.17.15 100 D1491260800 HOST 10.1.20.10 9090 1006733 10.1.17.15 100 U1491260800 HOST 10.1.20.10 9090 1006734 10.1.17.15 100 D1491260800 HOST 10.1.20.10 9090 1006735 10.1.17.15 100 U1491260800 HOST 10.1.20.10 9090 1006736 10.1.17.15 100 D1491260800 HOST 10.1.20.10 9090 1006737 10.1.17.15 100 U1491260800 HOST 10.1.20.10 9090 1006738 10.1.17.15 100 D1491260800 HOST 10.1.20.10 9090 1006739 10.1.17.15 100 U1491260800 HOST 10.1.20.10 9090 1006740 10.1.17.15 100 D1491260800 HOST 10.1.20.10 9090 1006741 10.1.17.15 100 U1491260800 HOST 10.1.20.10 9090 1006742 10.1.17.15 100 D1491260800 HOST 10.1.20.10 9090 1006743 10.1.17.15 100 U1491260800 HOST 10.1.20.10 9090 1006744 10.1.17.15 100 D1491260800 HOST 10.1.20.10 9090 1006745 10.1.17.15 100 U1491260800 HOST 10.1.20.10 9090 1006746 10.1.17.15 100 D1491260800 HOST 10.1.20.10 9090 1006747 10.1.17.15 100 U1491260800 SYNC 10.1.20.10 9090 1011840 7 1491263483 3377546382 I'm guessing that D1491260800 is the user hash (with D for down), and the U version is for 'up'. I'm happy to provide the full tcpdump (and/or doveconf -a), though the tcpdump is basically all identical the one I pasted (same hash, same host). This seems pretty fragile. There should be some sort of tie break for that, instead of bringing the entire cluster to its knees. Or just drop the backend host completely. Or something, anything besides hosing things pretty badly. This is 2.2.27, on both the directors and backend. If the answer is upgrade to 2.2.28, then I'll upgrade immediately. I see commit a9ade104616bbb81c34cc6f8bfde5dab0571afac mentions the same error but the commit predates 2.2.27 by a month and a half. In the meantime, is there any doveadm command I could've done to fix this? I tried removing the host (doveadm director remove 10.1.17.15) but that didn't do anything. I didn't think to try to flush the mapping for that user till just now. I suspect that with the ring unsync'd, flushing the user wouldn't have helped. The only remedy was to kill dovecot on every box in the director cluster and then (with dovecot down on *all* of them) start dovecot back up. Restarting each director's dovecot (with other directors' dovecots still running) did nothing. Only by brining the entire cluster down did dovecot stop furiously logging "Host ... is being updated before previous update had finished" on every director host. Any advice is most welcome.

2 3

System load spike on dovecot reload
by dave＠evilcigi.eu 24 Apr '17

24 Apr '17

Hi everyone, I'm running dovecot with quite a lot of users and lots of active imap connections (like 20'000). I'm using different user IDs for users, so I need to have imap {service_count=1} - i.e. I have a lots of imap processes running. Everything works fine, until I reload dovecot configuration. When that happen, every client is forced to relogin in the same time and that causes a huge system load spike (2-3000 5 min load). I was thinking that it would be great, if dovecot wouldn't kick all the users in the same time during reload, but somehow gradually, during specified interval. I'm aware of the shutdown_clients directive that could help, but I don't like it - I do want the clients get disconnected on dovecot shutdown and also I want them to relogin in reasonably short time after reload. Is something like that possible with dovecot or does it make sense to implement that in the future versions? Thank you. Dave.

5 4

Feature Request - Director Balance
by Webert de Souza Lima 24 Apr '17

24 Apr '17

Hi, often I run into the situation where a dovecot server goes down for maintenance, and all users get concentrated in the remaining dovecot server (considering I have 2 dovecot servers only). When that dovecot server comes back online, director server will send new users to it, but the dovecot server that was up all the time will still have tons of clients mapped to it. I suggest the director servers to always try to balance load between servers, in the way: - if a server has several more connections than other, mark it to re-balance - when a user connected to this loaded server disconnects, map it to another server (that is per definition not the same server) immediately. that way it would gracefully re-balance, not killing existing connections, just waiting for them to finish. Thank you for your time. Webert Lima MAV Tecnologia Belo Horizonte, Brasil.

2 2