January 2018 - dovecot

Re: TLS problem after upgrading from v2.2 to v2.3
by Joseph Tam 08 Jan '18

08 Jan '18

Jan Vejvalka <jan.vejvalka(a)lfmotol.cuni.cz> writes: >> Mine are below and they work just fine: >> >> 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:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!SSLv2:!SSLv3 I notice all the ciphers use DH, so did you a generate a permanent DH key? (https://wiki2.dovecot.org/Upgrading/2.3) ssl-parameters.dat file is now obsolete. You should use ssl_dh setting instead: ssl_dh=</etc/dovecot/dh.pem You can convert an existing ssl-parameters.dat to dh.pem: dd if=/var/lib/dovecot/ssl-parameters.dat bs=1 skip=88 | openssl dh -inform der > /etc/dovecot/dh.pem Joseph Tam <jtam.home(a)gmail.com>

2 1

Locks directory change
by Federico Bartolucci 08 Jan '18

08 Jan '18

Hello, it's the first time for me writing to the list, I'm trying to change the location into which the Dovecot's locks are done reserving a special temporary directory on an other partition, then adding to the dovecont.conf the line: mail_location = maildir:~/Maildir:VOLATILEDIR=/tmp_lock/%2.256Nu/%u so that through the VOLATILEDIR directive the locks should be written in this path. We observe though that the locks for many users are still done in the real maildir (NFS mounted filesystem) as if in some situations this instruction is not effective. Anybody knows if are there other things to change or to do or what could be the reason? (for instance to login in a specific way or doing a particular operation). Regards, Federico

3 3

Removing IMAP ID command
by Alex Hautequest 08 Jan '18

08 Jan '18

Hello all. Happy 2018! How can I disable the dovecot IMAP ID command, or hide the product name, so one does not eyeball what server software I am running (which happens to be v2.2.33.2)? Please see below for an example: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=LOGIN] Ready. * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=LOGIN A001 OK Pre-login capabilities listed, post-login capabilities have more. * ID ("name" "Dovecot") A002 OK ID completed. A003 BAD Error in IMAP command received by server. * BYE Logging out A004 OK Logout completed. It does not seems POP3 advertises itself: +OK Ready. +OK CAPA TOP UIDL RESP-CODES PIPELINING AUTH-RESP-CODE STLS SASL . Thanks and regards, Alex.

2 1

Mailing list content filtering changes
by Timo Sirainen 07 Jan '18

07 Jan '18

I've now disabled all content filtering in Mailman, because of the failing DKIM/DMARC issues. Hopefully that solves them for now.. Although this will mean that we'll probably start getting HTML mails to this list, which isn't ideal. I guess an alternative could be to reject any mails with text/html MIME part, but that could prevent some people from sending any mails to this list unless they switch to a different client/webmail.. Also that feature doesn't seem to be possible at least with the Mailman version we're currently using. BTW. All/most of the Gmail and Yahoo users just got disabled by mailman due to DMARC bounces. I've (hopefully) re-enabled mail for all of them.

2 1

Re: Updated Dovecot 2.3.0 now getting 2 strange log errors
by tony 07 Jan '18

07 Jan '18

I did some more digging around and found this is reproducible on multiple hosts running the same version of Dovecot/Pigeonhole/Postfix. The problem resurfaces on any host to an account with enabled Vacation/OOO response. The Vacation/OOO reply filter was created in Roundcubemail, but has been fine for years. One thing to note is in Dovecot 2.3.0 I did enable UTF8, but even if I disable UTF8 the issue remains. What I have discovered after digging around is.. * After a fresh postfix restart all expected processes are running without any postdrop process. postgrey 13080 0.0 0.2 73036 21108 ? Ss 17:23 0:00 postgrey --inet=127.0.0.1:10030 --pidfile=/run/postgrey/postgrey.pid --group=postgrey --user=postgrey --daemonize --greylist-text=Greylisted for %s seconds --auto-whitelist-clients root 13107 0.0 0.0 385700 108 ? Ssl 17:23 0:00 /usr/local/bin/pwhois_milter -i /run/pwhois_milter/pwhois_milter.pid -l /var/log/mail/mail.log -u postfix -g postfix -w global.pwhois.org root 13192 0.0 0.0 122536 5856 ? Ss 17:23 0:00 /usr/lib/postfix/bin/master -w postfix 13193 0.0 0.1 138524 8996 ? S 17:23 0:00 pickup -l -t unix -u postfix 13194 0.0 0.1 138572 9088 ? S 17:23 0:00 qmgr -l -t unix -u postfix 13320 0.0 0.1 163908 9832 ? S 17:24 0:00 proxymap -t unix -u postfix 13321 0.0 0.1 142756 9632 ? S 17:24 0:00 tlsmgr -l -t unix -u postfix 13322 0.0 0.1 138524 9280 ? S 17:24 0:00 anvil -l -t unix -u postfix 13352 0.0 0.1 168896 13520 ? S 17:24 0:00 smtpd -n smtp -t inet -u -o stress= -s 2 -o content_filter=spamassassin postfix 13539 0.0 0.1 163920 10156 ? S 17:24 0:00 trivial-rewrite -n rewrite -t unix -u postfix 14369 0.0 0.1 164300 10340 ? S 17:26 0:00 cleanup -z -t unix -u postfix 14370 0.0 0.1 124180 8844 ? S 17:26 0:00 pipe -n spamassassin -t unix user=spamd argv=/usr/bin/vendor_perl/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient} postfix 14375 0.0 0.1 142856 9344 ? S 17:26 0:00 lmtp -t unix -u vmail 14446 0.0 0.0 44008 7496 ? S 17:26 0:00 dovecot/quota-status -p postfix * During the problem where the logs are complaining about permission denied and sendmail exiting with signal 15 (caused by inbound email to an address with enabled Vacation notice filter) there is a running postdrop process and several expected processes are not running. postgrey 13080 0.0 0.2 73036 21132 ? Ss 17:23 0:00 postgrey --inet=127.0.0.1:10030 --pidfile=/run/postgrey/postgrey.pid --group=postgrey --user=postgrey --daemonize --greylist-text=Greylisted for %s seconds --auto-whitelist-clients root 13107 0.0 0.0 461572 408 ? Ssl 17:23 0:00 /usr/local/bin/pwhois_milter -i /run/pwhois_milter/pwhois_milter.pid -l /var/log/mail/mail.log -u postfix -g postfix -w global.pwhois.org root 13192 0.0 0.0 122536 5856 ? Ss 17:23 0:00 /usr/lib/postfix/bin/master -w postfix 13193 0.0 0.1 138524 8996 ? S 17:23 0:00 pickup -l -t unix -u postfix 13194 0.0 0.1 138644 9128 ? S 17:23 0:00 qmgr -l -t unix -u postfix 13321 0.0 0.1 142756 9632 ? S 17:24 0:00 tlsmgr -l -t unix -u postfix 20793 0.0 0.1 138524 9092 ? S 17:39 0:00 anvil -l -t unix -u vmail 25340 0.0 0.0 44108 7664 ? S 17:46 0:00 dovecot/quota-status -p postfix vmail 26298 0.0 0.1 122088 8536 ? S 17:49 0:00 /usr/bin/postdrop -r —— * When the issue is not present, an email TO any address with a disabled Vacation/OOO response filter is processed with no issues and stored in the respective folder moved by an existing filter not related to Vacation/OOO. Expected processes are still running (no postdrop process which when running seems to be causing the problem) * When the issue is not present, an email TO an address with a enabled Vacation/OOO response filter is processed and stored in the Inbox, but an auto-response fails to send. The result are these errors with the permission denied being repeated every ~minute. Dec 29 17:49:58 lmtp(jsomeone(a)domain.email)<26296><qbe8H6jwRlq4ZgAAUXb6+w>: Error: sieve: msgid=<CAE2c3QaGTiFDt5rdHEy2YeoSe+XBcB9Q5SGeOtknWKf2wgXZhQ(a)mail.gmail.com>: failed to send vacation response to someone(a)gmail.com: <Failed to execute sendmail> (temporary error) Dec 29 17:50:08 lmtp: Error: postdrop: warning: mail_queue_enter: create file maildrop/569031.26298: Permission denied * After the problem starts again with the errors shown in the logs a postdrop process stays running in the background. After a short while the number of postfix processes decreases. * If I kill the postdrop process then the logged errors stop and the expected processes all show up again. I am running out of ideas on why this has suddenly surfaced. - TC

5 12

quota issue - fs backend troubles with mount
by Arturo Bianchi 07 Jan '18

07 Jan '18

Hi, with the last update to version 2.2.33.2 I had problems with quota management; the plugin no longer reads the configuration correctly or something undocumented has changed! Until the version 2.2.30.2 the mount parameter work well, now no longer; so with... plugin { quota = fs:HOME:mount=/home quota2 = fs:INBOX:mount=/var/spool } ...the server no longer works and I read this in the log: Debug: Module loaded: /usr/lib64/dovecot/lib10_quota_plugin.so Debug: Quota root: name=HOME=fs args=mount=/home Debug: Quota grace: root=HOME bytes=0 (10%) Debug: Quota root: name=INBOX backend=fs args=mount=/var/spool Debug: Quota grace: root=INBOX bytes=0 (10%) Error: User initialization failed: Failed to initialize quota: Quota root HOME: fs quota init failed: Unknown parameter for backend fs: =/home I saw that the method for acquiring the parameters was revised in the src/plugins/quota/quota-fs.c but I still could not understand why it fails! Some advice? Do I have a formatting problem or am I missing some news about it? Thanks, Arturo. -- 73s

1 1

TLS problem after upgrading from v2.2 to v2.3
by Jan Vejvalka 07 Jan '18

07 Jan '18

Thanks for your reply; I used the defaults, both before and after the upgrade, cf. https://wiki2.dovecot.org/Upgrading/2.3 -> Setting default changes. The new defaults broke the connection. Jan > what are your settings? > > Mine are below and they work just fine: > > 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:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!SSLv2:!SSLv3

2 2

TLS problem after upgrading from v2.2 to v2.3
by Jan Vejvalka 05 Jan '18

05 Jan '18

Hi *, The change in default SSL settings between 2.2 and 2.3 cut off a few clients; Microsoft-hosted Exchange (?) being one of them: Jan 4 11:02:56 kremail dovecot: pop3-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=40.101.4.hisip, lip=myip, TLS handshaking: SSL_accept() failed: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher, session=<8SGob/BhTdcoZQS1> Explicitly setting ssl_cipher_list to the old defaults helped: ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL Does someone have an idea what to recommend to the poor user or should I accept that I stay with the old defaults ? The guy is cooperative, so we can find out which of the !'s in the new defaults actually breaks the connection... if you think it's worth. Thanks for your help, Jan

2 1

dovecot-2.3.0 'make check' error
by Eric Broch 05 Jan '18

05 Jan '18

Hello list, I've configured dovecot-2.3.0 on CentOS 6 with the following options. CFLAGS="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fno-strict-aliasing" \ LDFLAGS="-Wl,-z,now -Wl,-z,relro" \ ./configure \ --docdir=/usr/share/doc/dovecot-2.3.0 \ --with-lzma \ --disable-static \ --disable-rpath \ --with-nss \ --with-shadow \ --with-pam \ --with-gssapi=plugin \ --with-ldap=plugin \ --with-sql=plugin \ --with-lua=plugin \ --with-pgsql \ --with-mysql \ --with-sqlite \ --with-vpopmail=/etc/libvpopmail \ --with-zlib \ --with-libcap \ --with-libwrap \ --with-ssl=openssl \ --with-ssldir=/etc/pki/dovecot \ --with-solr \ --with-docs and compiled with the following: # make -j2 When I run a 'make check': # make check I get the following error: make[3]: Entering directory `/root/dovecot/dovecot-ce-2.3.0/src/lib-compression' for bin in test-compression; do \ if ! /bin/sh ../../run-test.sh ../.. ./$bin; then exit 1; fi; \ done compression handler gz ............................................... : ok compression handler bz2 .............................................. : ok compression handler deflate .......................................... : ok compression handler xz ............................................... : ok gz concat ............................................................ : ok gz no concat ......................................................... : ok gz large header ...................................................... : ok 0 / 7 tests failed ==4468== Conditional jump or move depends on uninitialised value(s) ==4468== at 0x3A6160ACB2: ??? (in /usr/lib64/liblzma.so.0.0.0) ==4468== by 0x3A6160AEA9: ??? (in /usr/lib64/liblzma.so.0.0.0) ==4468== by 0x3A61603121: ??? (in /usr/lib64/liblzma.so.0.0.0) ==4468== by 0x3A616061A0: ??? (in /usr/lib64/liblzma.so.0.0.0) ==4468== by 0x3A61605212: lzma_easy_encoder (in /usr/lib64/liblzma.so.0.0.0) ==4468== by 0x406ACF: o_stream_create_lzma (ostream-lzma.c:206) ==4468== by 0x403D89: test_compression_handler (test-compression.c:36) ==4468== by 0x4040BD: test_compression (test-compression.c:96) ==4468== by 0x408281: test_run_funcs (test-common.c:244) ==4468== by 0x4083E0: test_run (test-common.c:315) ==4468== by 0x40398B: main (test-compression.c:308) ==4468== Failed to run: ./test-compression make[3]: *** [check-local] Error 1 make[3]: Leaving directory `/root/dovecot/dovecot-ce-2.3.0/src/lib-compression' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/root/dovecot/dovecot-ce-2.3.0/src/lib-compression' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/root/dovecot/dovecot-ce-2.3.0/src' make: *** [check-recursive] Error 1 Has anyone seen the above error and/or, Can anyone give me a reason why it's occurring? -- Eric Broch White Horse Technical Consulting (WHTC)

1 0

Re: Bug in dovecot 2.3 virtual plugin
by Jakob Schürz 05 Jan '18

05 Jan '18

So hello back again! Am 05.01.2018 um 14:31 schrieb Jakobus Schürz: > > > Am 05.01.2018 um 10:25 schrieb Aki Tuomi: >> This is a different bug, and I suspect it might be caused by virtual >> plugin. We'll look into it. >> >> Aki > > It was a problem with selfhealing the index... I deleted all my emails and mailboxes and rebuild the tree of mailboxes again with doveadm. Then i put back email for email from the cur-folders from backup to the new-folders in the rebuild mailboxes. From the filename i cut of the part with hostname and size and flags. The archive now is in a separate namespace, because there are really a lot of emails in. Now it works great again (exept one error, i posted before) Maybe you can find something to improve dovecot in selfhealing broken index. Thanks for the great work on this server! jakob

1 0