- dovecot - dovecot.org

Patch SERVICE_FIRST_STATUS_TIMEOUT
by Andre Helwig 17 Mar '15

17 Mar '15

Hi list, we had a lot of trouble with our Dovecot Replicating-Cluster installation authenticating against LDAP Service. We ran in a timeout and what happened was that we got more and more search requests running against on our ldap server. And on the dovecot site the process got killed after a couple of seconds. So we ran into a race condition and our LDAP Server was under heavy load. We got a log entry like this: "Initial status notification not received in 30 seconds, killing the process" So we had to apply the attached patch to our Source based Dovecot Cluster. Could you please make a configurable Parameter for our Patched value? That would be great to get this parameter Configurable. Thanks Andre Helwig -- Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-0 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin

2 3

Dovecot 2.1.7 still accepting SSLv3 though disabled?
by Thomas Preissler 17 Mar '15

17 Mar '15

Hello, I came across a strange problem with my Dovecot 2.1.7 installation (updated Debian Wheezy) in regards to SSL/TLS connections. My configuration is as follows: $ dovecot -n | grep ssl service imap-login { ssl = yes ... } ssl_cert = <...... ssl_cipher_list = EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA ssl_key = <...... ssl_protocols = !SSLv3 !SSLv2 This cipherstring has been taken from https://bettercrypto.org/static/applied-crypto-hardening.pdf. But this is not the problem, when I comment it out, Dovecot still behaves the same way. When I enable verbose_ssl I get this: 2015-03-15 08:27:39 imap-login: Warning: SSL: where=0x10, ret=1: before/accept initialization [$CLIENTIP] 2015-03-15 08:27:39 imap-login: Warning: SSL: where=0x2001, ret=1: before/accept initialization [$CLIENTIP] 2015-03-15 08:27:39 imap-login: Warning: SSL: where=0x2002, ret=-1: unknown state [$CLIENTIP] 2015-03-15 08:27:39 imap-login: Warning: SSL: where=0x2001, ret=1: SSLv3 read client hello A [$CLIENTIP] 2015-03-15 08:27:39 imap-login: Warning: SSL: where=0x2001, ret=1: SSLv3 write server hello A [$CLIENTIP] 2015-03-15 08:27:39 imap-login: Warning: SSL: where=0x2001, ret=1: SSLv3 write certificate A [$CLIENTIP] 2015-03-15 08:27:39 imap-login: Warning: SSL: where=0x2001, ret=1: SSLv3 write server done A [$CLIENTIP] 2015-03-15 08:27:39 imap-login: Warning: SSL: where=0x2001, ret=1: SSLv3 flush data [$CLIENTIP] 2015-03-15 08:27:39 imap-login: Warning: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [$CLIENTIP] 2015-03-15 08:27:39 imap-login: Warning: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [$CLIENTIP] 2015-03-15 08:27:39 imap-login: Warning: SSL: where=0x2001, ret=1: SSLv3 read client key exchange A [$CLIENTIP] 2015-03-15 08:27:39 imap-login: Warning: SSL: where=0x2001, ret=1: SSLv3 read finished A [$CLIENTIP] 2015-03-15 08:27:39 imap-login: Warning: SSL: where=0x2001, ret=1: SSLv3 write change cipher spec A [$CLIENTIP] 2015-03-15 08:27:39 imap-login: Warning: SSL: where=0x2001, ret=1: SSLv3 write finished A [$CLIENTIP] 2015-03-15 08:27:39 imap-login: Warning: SSL: where=0x2001, ret=1: SSLv3 flush data [$CLIENTIP] 2015-03-15 08:27:39 imap-login: Warning: SSL: where=0x20, ret=1: SSL negotiation finished successfully [$CLIENTIP] 2015-03-15 08:27:39 imap-login: Warning: SSL: where=0x2002, ret=1: SSL negotiation finished successfully [$CLIENTIP] Is this right? Is SSLv3 used on this connection? But when I explicitely test for SSLv3 support I get $ openssl s_client -connect $SERVERIP:993 -ssl3 CONNECTED(00000003) 140683835029160:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1260:SSL alert number 40 140683835029160:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 0 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : SSLv3 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1426411304 Timeout : 7200 (sec) Verify return code: 0 (ok) --- Where I got this from says "if you you get a handshake failure, then you don't support SSLv3". But in my case the following output kinda says, that I do support it - with a ciphers of (NONE)? In regards to libraries $ ldd /usr/lib/dovecot/imap-login | grep ssl libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f1f55025000) $ dpkg -l | grep ssl ii libcrypt-openssl-bignum-perl 0.04-3 amd64 Access OpenSSL multiprecision integer arithmetic libraries ii libcrypt-openssl-dsa-perl 0.13-6 amd64 module which implements the DSA signature verification system ii libcrypt-openssl-rsa-perl 0.28-1 amd64 module for RSA encryption using OpenSSL ii libcrypt-ssleay-perl 0.58-1 amd64 OpenSSL support for LWP ii libio-socket-ssl-perl 1.76-2 all Perl module implementing object oriented interface to SSL sockets ii libnet-ssleay-perl 1.48-1+b1 amd64 Perl module for Secure Sockets Layer (SSL) rc libssl0.9.8 0.9.8o-4squeeze14 amd64 SSL shared libraries ii libssl1.0.0:amd64 1.0.1e-2+deb7u14 amd64 SSL shared libraries ii openssl 1.0.1e-2+deb7u14 amd64 Secure Socket Layer (SSL) binary and related cryptographic tools ii openssl-blacklist 0.5-3 all Blacklists for OpenSSL RSA keys and tools ii python-openssl 0.13-2+deb7u1 amd64 Python 2 wrapper around the OpenSSL library ii ssl-cert 1.0.32 all simple debconf wrapper for OpenSSL ii ssl-cert-check 3.22-1 all proactively handling X.509 certificate expiration ii sslmate 0.6.2-1 all Buy and manage SSL certificates from the command line My NginX is using the same library, and this does indeed support TLSv2, so what I am doing wrong in my Dovecot configuration? Any clues? Regards Thomas -- www.preissler.co.uk | Twitter: @module0x90 | PGP-Key: 75889415 GPG Fingerprint: CCBD 153A D257 CA7E A217 FDF7 5928 03D1 7588 9415

3 2

Released Pigeonhole v0.4.7.rc3 for Dovecot v2.2.16
by Stephan Bosch 17 Mar '15

17 Mar '15

Hello Dovecot users, The rc2 release had a couple of new, rather small, but very annoying bugs. First of all, the path for a file storage wasn't actually normalized, due to a stupid last-minute change before the release. This caused the personal script to be skipped with a warning when there were e.g. duplicate slashes in the path. Second, due to recent changes, the file storage would complain with a temporary error if the directory where the active script symlink would be located was missing. Changelog v0.4.7 (unchanged): * editheader extension: Made protection against addition and deletion of headers configurable separately. Also, the `Received' and `Auto-Submitted' headers are no longer protected against addition by default. * Turned message envelope address parse errors into warnings. * The interpreter now accepts non-standard domain names, e.g. containing '_'. + Implemented the Sieve index extension (RFC 5260). + Implemented support for the mboxmetadata and servermetadata extensions (RFC 5490). + Implemented new sieve commands for the doveadm command line utility. These commands are currently limited to ManageSieve operations, but the other current sieve tools will be migrated to doveadm in the near future as well. + Added more debug output about binary up-to-date checking. + Added script metadata to binary dump output. - Fixed Sieve script binary up-to-date checking by normalizing the script location. - The Sieve interpreter now flushes the duplicate database during start phase of result execution rather than commit phase. This makes sure locks on the duplicate database are released as soon as possible, preventing contention. - Performed a few optimizations in the lexical scanner of the language. - Fixed bug in `:matches' match-type that made a pattern without wildcards match as if there were a '*' at the beginning. - Fixed crash in validation of the string parameter of the comparator tag. - extprograms extension: Made sure supplemental group privileges are also dropped. This was a problem reported by Debian lintian. - Fixed bug in handling of binary errors for action side-effects and message overrides. - file script storage: Restructured storage initialization to address backwards compatibility issues. - dict script storage: Fixed small memory allocation bug. The release is available as follows: http://pigeonhole.dovecot.org/releases/2.2/dovecot-2.2-pigeonhole-0.4.7.rc3… http://pigeonhole.dovecot.org/releases/2.2/dovecot-2.2-pigeonhole-0.4.7.rc3… Refer to http://pigeonhole.dovecot.org and the Dovecot v2.x wiki for more information. Have fun testing this new release and don't hesitate to notify me when there are any problems. Regards, -- Stephan Bosch stephan(a)rename-it.nl

1 0

Released Pigeonhole v0.4.7.rc2 for Dovecot v2.2.16
by Stephan Bosch 16 Mar '15

16 Mar '15

Hello Dovecot users, The rc1 release showed a few problems with the up-to-date checking of on-disk binary files. The binary files contain some metadata about the script these were compiled from. If this doesn't match the current script anymore, the script is recompiled. One of these metadata items is the script location. However, this location wasn't normalized, so when the binary would be compiled with sievec it depended on the path provided at the command line. When dumping a script binary, the metadata is now printed as well. Also, I added more debug log lines about up-to-date checking. I improved backwards compatibility for the file script storage a bit relative to the last version. It now properly recognizes a regular file at the symlink path, even when the storage path itself doesn't exist. Changelog v0.4.7 (updated): * editheader extension: Made protection against addition and deletion of headers configurable separately. Also, the `Received' and `Auto-Submitted' headers are no longer protected against addition by default. * Turned message envelope address parse errors into warnings. * The interpreter now accepts non-standard domain names, e.g. containing '_'. + Implemented the Sieve index extension (RFC 5260). + Implemented support for the mboxmetadata and servermetadata extensions (RFC 5490). + Implemented new sieve commands for the doveadm command line utility. These commands are currently limited to ManageSieve operations, but the other current sieve tools will be migrated to doveadm in the near future as well. + Added more debug output about binary up-to-date checking. + Added script metadata to binary dump output. - Fixed Sieve script binary up-to-date checking by normalizing the script location. - The Sieve interpreter now flushes the duplicate database during start phase of result execution rather than commit phase. This makes sure locks on the duplicate database are released as soon as possible, preventing contention. - Performed a few optimizations in the lexical scanner of the language. - Fixed bug in `:matches' match-type that made a pattern without wildcards match as if there were a '*' at the beginning. - Fixed crash in validation of the string parameter of the comparator tag. - extprograms extension: Made sure supplemental group privileges are also dropped. This was a problem reported by Debian lintian. - Fixed bug in handling of binary errors for action side-effects and message overrides. - file script storage: Restructured storage initialization to address backwards compatibility issues. - dict script storage: Fixed small memory allocation bug. The release is available as follows: http://pigeonhole.dovecot.org/releases/2.2/dovecot-2.2-pigeonhole-0.4.7.rc2… http://pigeonhole.dovecot.org/releases/2.2/dovecot-2.2-pigeonhole-0.4.7.rc2… Refer to http://pigeonhole.dovecot.org and the Dovecot v2.x wiki for more information. Have fun testing this new release and don't hesitate to notify me when there are any problems. Regards, -- Stephan Bosch stephan(a)rename-it.nl

2 2

Warning: sieve: file storage: Active sieve script symlink is broken: Invalid/unknown path to storage
by Василий Севостьянов 16 Mar '15

16 Mar '15

dovecot version: 2.2.16 (3d8a054a93a9) sieve configuration: plugin { sieve = ~/.dovecot.sieve sieve_dir = ~/sieve } For each of the users, ~/.dovecot.sieve is a symlink to ~/sieve/roundcube.sieve Until yesterday, everything was working find. But starting from yesterday's update, the log is filling up with messages like: Mar 16 19:12:32 cs12986 dovecot: lda(postmaster(a)contoso.com <postmaster(a)euro-contact.ru>): Warning: sieve: file storage: Active sieve script symlink /home/virtualmail/contoso.com/it/.dovecot.sieve <http://euct.ru/it/.dovecot.sieve> is broken: Invalid/unknown path to storage (points to /home/virtualmail/contoso.com/it/sieve <http://euct.ru/it/sieve>). Nothing was changed in the config files. What might have gone wrong?

3 4

Configuring Shared Mailbox Dictionaries
by james＠lottspot.com 16 Mar '15

16 Mar '15

Hello, list! I am in the midst of configuring a new Dovecot IMAP server, and I'm preparing to setup shard mailboxes as part of the ocnfiguration. In order to get these setup the way I want, I've figured out that I'm going to have to setup an acl_shared_dict. This is where things start to get confusing for me, as I have had difficulty finding thorough explanations of dictionary configuration. My primary concern is that all my user details are stored in a sqlite database in which the '%n' and '%d' components of username/email addresses are stored in separate columns. The SQL dictionary example in the Shared Mailboxes document [http://wiki2.dovecot.org/SharedMailboxes/Shared] assumes that the username is stored as a singular '%n@%d' key. In my authdb lookups, I use sqlite syntax to concatenate the '%n' and '%d' columns around a '@' character to find the user. Is it possible to implement an acl_shared_dict in some similar fashion? My second question, which is completely unrelated and more out of morbid curiosity than anything (although it could affect my configuration decisions) is that I noticed every dictionary which shows up in the documentation has a "pattern" field. In the case of the acl_shared_dict example, the pattern is 'shared/shared-boxes/user/$to/$from'. I couldn't figure out by studying the example where this value was derived from, or indeed where it is derived from in any example dictionaries which are documented. Can anyone explain the meaning of the "pattern" field and what exactly its value means? Thanks in advance for all your helpful answers! :)

1 1

Problem with replication ("Fatal: -N parameter requires syncing with remote host")
by Casey Stone 16 Mar '15

16 Mar '15

Switching to official dovecot-ee version solved my sync/backup issues, also on Ubuntu. The 12.04 package works on 14.04. It's free and should update fine. Backup your config files first (dovecot and postfix if you use that)! http://shop.dovecot.fi/home/8-dovecot-ee-repository-access.html

1 0

Problem with replication ("Fatal: -N parameter requires syncing with remote host")
by Vanja 16 Mar '15

16 Mar '15

I have been fighting, for 2 days, with a Dovecot setup and I now officially need help :) Basically, I am trying to setup replication between 2 identical Dovecot servers, on different physical servers (different hostnames/etc, of course), and although I've managed to solve many problems I can't overcome the final hurdle. When a mail comes in to one of the servers, replication over TCP should kick in and mail should be replicated, but instead I get this in the mail log: ------------------------------------------------------------------------------------------------- dovecot2 dovecot: doveadm(user1(a)test1.int): Fatal: -N parameter requires syncing with remote host ------------------------------------------------------------------------------------------------- Mail is delivered to dovecot2 server, Postfix delivers it via LMTP, and everything seems to work ok. However, I can't figure out the cause for the error that I am seeing. I have looked into source code and found where this error is triggered (line 834 in doveadm/dsync/doveadm-dsync.c, inside Dovecot 2.2.9 source code), but I am afraid that I don't understand the context (ctx->run_type == DSYNC_RUN_TYPE_LOCAL) and it would take me a lot of time to debug the whole thing from the scratch. I've never looked into Dovecot internals before, so it's all a mystery to me at this point. I've tried stracing the process but the flow does not make sense to me, I can't understand what exactly happens before error is displayed. Also, there is no traffic to port 12345 on other node, so execution fails before syncing even starts (and error message is not related with remote node config/setup/etc). Triggering replication manually, from command line, works as expected: # doveadm sync -A tcp:192.168.1.100 (at this point user1's mail folder is properly updated on remote server) I've tried searching around, but it appears that noone else has this problem(or isn't complaining about it :). I am not sure if I am doing something wrong (apart from replication). I will need to support multiple virtual domains and I am basically using passwd-file for authentication, so I am using a single passwd file for all virtual domain users which allows user lookup (doveadm user '*') to work, which is required by replication. This is configuration file from dovecot2 server (which I use for testing and delivering mails): --- config start --- # 2.2.9: /etc/dovecot/dovecot.conf # OS: Linux 3.16.0-30-generic x86_64 Ubuntu 14.04.2 LTS ext4 debug_log_path = /var/log/dovecot_debug.log doveadm_password = 67890 doveadm_port = 12345 mail_debug = yes mail_location = maildir:/vmail/mail/%d/%n/Maildir mail_plugins = " notify replication" 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 { args = username_format=%u /vmail/auth/passwd driver = passwd-file } plugin { mail_replica = 192.168.1.100 } protocols = imap lmtp service aggregator { fifo_listener replication-notify-fifo { user = vmail } unix_listener replication-notify { user = vmail } } service auth-worker { unix_listener auth-worker { user = dovecot-auth } } service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } user = dovecot-auth } service doveadm { inet_listener { port = 12345 } } service imap-login { inet_listener imap { port = 0 } } service lmtp { inet_listener lmtp { address = 127.0.0.1 port = 10024 } process_min_avail = 3 unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0660 user = postfix } user = vmail } service replicator { process_min_avail = 1 unix_listener replicator-doveadm { mode = 0666 } } ssl_cert = </etc/dovecot/dovecot.pem ssl_key = </etc/dovecot/private/dovecot.pem userdb { args = username_format=%u /vmail/auth/passwd default_fields = uid=vmail gid=vmail home=/vmail/mail/%d/%n driver = passwd-file } protocol lmtp { postmaster_address = root@localhost } --- config end --- Configuration file on other node is exactly the same, except different IP address in mail_replica statement. Any help is much appreciated. Thank you.

1 1

Re: Problem with replication ("Fatal: -N parameter requires syncing with remote host")
by Vanja 16 Mar '15

16 Mar '15

Sorry to post to the list again, but just to confirm that I am seeing same problem with 2.2.16 that I compiled from sources. Same error message appears in the log, can't figure out what in the setup makes replication break. Philipp, can you tell me which auth backend are you using? passwd-file, SQL database or something else? Would you consider posting your 'sanitized' config file here, or emailing it to me privately? Thanks. Vanja On 03/16/2015 03:23 PM, Philipp wrote: > Am 16.03.2015 09:12 schrieb Vanja: >> doveadm_port = 12345 > >> plugin { >> mail_replica = 192.168.1.100 >> } > > would you try: > mail_replica = tcp:192.168.1.100:12345 > which works for me. > > check for firewall settings (both ways) anyway - and I can only advise > to go for 2.2.16; there have been > numerous fixes after 2.2.9 to the whole dsync/replica parts.

1 0

Re: Problem with replication ("Fatal: -N parameter requires syncing with remote host")
by Vanja 16 Mar '15

16 Mar '15

Philipp, I already tried explicitly specifying port, it does not make any difference. I tried quite many 'obvious' (to put it this way) configuration changes and tried changing many things in setup, but it would be too much to list all of them in a post. Basically, I was hoping that someone would know what exactly triggers this behavior, so I could fix it. At this point in time, I would like to see whether I can make this work with 2.2.9 that comes with Ubuntu 14.04, to avoid having to compile anything from sources (for easier maintenance, later on, since I probably won't be the one maintaining this). I am also not sure whether there is a reliable (semi-official?) PPA with latest Dovecot. I saw this one ( https://launchpad.net/~mamarley/+archive/ubuntu/updates ) but I am not sure whether I can rely on it not breaking anything at some point. Thanks. On 03/16/2015 03:23 PM, Philipp wrote: > Am 16.03.2015 09:12 schrieb Vanja: >> doveadm_port = 12345 > >> plugin { >> mail_replica = 192.168.1.100 >> } > > would you try: > mail_replica = tcp:192.168.1.100:12345 > which works for me. > > check for firewall settings (both ways) anyway - and I can only advise > to go for 2.2.16; there have been > numerous fixes after 2.2.9 to the whole dsync/replica parts.

1 0