August 2017 - dovecot

unexpected delivery location
by lists 29 Aug '17

29 Aug '17

Hi, We're running dovecot 2.2.13, virtual users, with postfix. We have an olddomain and a new domainname. To 'translate' *@olddomain into *@newdomain, I have configured: > cat /etc/postfix/canonical > @olddomain.com @newdomain.com While this seems to work, lately we have noticed that dovecot occasionally creates mailboxes for non-existent users, like: > /var/vmail/...username > /var/vmail/20username This only seems to be happening for mails sent to *olddomain* Looking at the source of these mails, they are indeed sent to 20username(a)olddomain.com and ...username(a)olddomain.com Mail headers sample: > Delivered-To: 20username(a)newdomain.com > Received: from server1.newdomain.com (server2.newdomain.com [x.y.z.q]) > by server3.newdomain.com (Postfix) with ESMTPS id 067B4812CF29E > for <20username(a)olddomain.com>; Thu, 13 Jul 2017 19:05:02 +0200 (CEST) Why doesn't the emailadress 20username(a)newdomain.com in the above generate an error, but instead are delivered to a newly created mailbox? My feeling is that something is wrong with the way I created the alias for olddomain -> newdomain with the canonical-file . Does that make sense? Our goal is to accept *(a)olddomain.com like it was sent to *(a)newdomain.com, including delivery failures for nonexistent mailboxes like 20username We configured postfix like: > canonical_maps = hash:/etc/postfix/canonical > virtual_alias_maps = ldap:/etc/postfix/ad-mailboxes.cf, ldap:/etc/postfix/ad-groups.cf > virtual_uid_maps = static:5000 > virtual_gid_maps = static:5000 > virtual_transport = dovecot Verified that this config works for newdomain, using: > root@mail:/etc/postfix# postmap -q alias(a)newdomain.com ldap:/etc/postfix/ad-mailboxes.cf > userid(a)newdomain.com > root@mail:/etc/postfix# postmap -q alias(a)olddomain.com ldap:/etc/postfix/ad-mailboxes.cf > root@mail:/etc/postfix# olddomain gives no result. Then, from master.cf: > dovecot unix - n n - - pipe > flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/dovecot-lda -f ${sender} -a ${recipient} -d ${user}@${nexthop} Finally, the mail location as defined in dovecot: > mail_location = maildir:/var/vmail/%Ln/Maildir:LAYOUT=fs:DIRNAME=mAildir So, can anyone explain why for mails to olddomain, dovecot creates new mailboxes, instead of simply generating an error?

3 6

dovecot-2.2.32/src/doveadm/doveadm-mail-fetch.c: 4 * suspicious expression ?
by David Binderman 29 Aug '17

29 Aug '17

Hello there, dovecot-2.2.32/src/doveadm/doveadm-mail-fetch.c:130]: (style) Suspicious condition (assignment + comparison); Clarify expression with parentheses. Source code is if ((ret = doveadm_print_istream(input) < 0)) Maybe better code if ((ret = doveadm_print_istream(input)) < 0) Some duplicates: [dovecot-2.2.32/src/doveadm/doveadm-mail-fetch.c:220]: (style) Suspicious condition (assignment + comparison); Clarify expression with parentheses. [dovecot-2.2.32/src/doveadm/doveadm-mail-fetch.c:237]: (style) Suspicious condition (assignment + comparison); Clarify expression with parentheses. [dovecot-2.2.32/src/doveadm/doveadm-mail-fetch.c:261]: (style) Suspicious condition (assignment + comparison); Clarify expression with parentheses. Regards David Binderman

2 2

vacation problem with SRS
by Kacper Guzik 28 Aug '17

28 Aug '17

Hi i have similiar problem like here: http://www.iredmail.org/forum/topic11833-iredmail-support-vocation-respone-… email send : from : web123(a)gmail.com to : jacka(a)mail.com vocation sent back from : jacka(a)mail.com to : srs0=hmc8=v7=gmail.com=web123(a)mail.com postsrsd changing return-path from web123(a)gmail.com to srs0=hmc8=v7= gmail.com=web123(a)mail.com this is no problem for me but sieve: Vacation's messages are always addressed to the Return-Path address it is possible some how change this ugly to header to normal? I can't find anything on dovecot mailing lists

2 7

[PATCH] Add support for lower TLS version than default
by Sebastian Andrzej Siewior 27 Aug '17

27 Aug '17

The openssl library in Debian unstable (targeting Buster) supports TLS1.2 by default. The library itself supports also TLS1.1 and TLS1.0. If the admin decides to also support TLS1.[01] users he can then enable the lower protocol version in case the users can't update their system. Signed-off-by: Sebastian Andrzej Siewior <sebastian(a)breakpoint.cc> --- src/config/all-settings.c | 1 + src/lib-master/master-service-ssl-settings.c | 2 ++ src/lib-master/master-service-ssl-settings.h | 1 + src/login-common/ssl-proxy-openssl.c | 15 ++++++++++++++- 4 files changed, 18 insertions(+), 1 deletion(-) --- a/src/config/all-settings.c +++ b/src/config/all-settings.c @@ -308,6 +308,7 @@ struct master_service_ssl_settings { const char *ssl_cert_username_field; const char *ssl_crypto_device; const char *ssl_options; + const char *ssl_lowest_version; bool ssl_verify_client_cert; bool ssl_require_crl; --- a/src/lib-master/master-service-ssl-settings.c +++ b/src/lib-master/master-service-ssl-settings.c @@ -26,6 +26,7 @@ static const struct setting_define maste DEF(SET_STR, ssl_protocols), DEF(SET_STR, ssl_cert_username_field), DEF(SET_STR, ssl_crypto_device), + DEF(SET_STR, ssl_lowest_version), DEF(SET_BOOL, ssl_verify_client_cert), DEF(SET_BOOL, ssl_require_crl), DEF(SET_BOOL, verbose_ssl), @@ -54,6 +55,7 @@ static const struct master_service_ssl_s .ssl_protocols = "!SSLv3", #endif .ssl_cert_username_field = "commonName", + .ssl_lowest_version = NULL, .ssl_crypto_device = "", .ssl_verify_client_cert = FALSE, .ssl_require_crl = TRUE, --- a/src/lib-master/master-service-ssl-settings.h +++ b/src/lib-master/master-service-ssl-settings.h @@ -16,6 +16,7 @@ struct master_service_ssl_settings { const char *ssl_cert_username_field; const char *ssl_crypto_device; const char *ssl_options; + const char *ssl_lowest_version; bool ssl_verify_client_cert; bool ssl_require_crl; --- a/src/login-common/ssl-proxy-openssl.c +++ b/src/login-common/ssl-proxy-openssl.c @@ -1302,7 +1302,20 @@ ssl_server_context_init(const struct log if (ctx->prefer_server_ciphers) SSL_CTX_set_options(ssl_ctx, SSL_OP_CIPHER_SERVER_PREFERENCE); SSL_CTX_set_options(ssl_ctx, openssl_get_protocol_options(ctx->protocols)); - +#if OPENSSL_VERSION_NUMBER >= 0x10100000 + if (ssl_set->ssl_lowest_version) { + if (!strcmp(ssl_set->ssl_lowest_version, "TLS1.0")) + SSL_CTX_set_min_proto_version(ssl_ctx, TLS1_VERSION); + else if (!strcmp(ssl_set->ssl_lowest_version, "TLS1.1")) + SSL_CTX_set_min_proto_version(ssl_ctx, TLS1_1_VERSION); + else if (!strcmp(ssl_set->ssl_lowest_version, "TLS1.2")) + SSL_CTX_set_min_proto_version(ssl_ctx, TLS1_2_VERSION); + else + i_fatal("TLS min version: '%s' is invalid. Only " + "'TLS1.0' and 'TLS1.1' is supported", + ssl_set->ssl_lowest_version); + } +#endif if (ctx->pri.cert != NULL && *ctx->pri.cert != '\0' && ssl_proxy_ctx_use_certificate_chain(ctx->ctx, ctx->pri.cert) != 1) { i_fatal("Can't load ssl_cert: %s",

3 6

Debian packages for 2.2.32?
by Harald Leithner 27 Aug '17

27 Aug '17

Hi, It seams that IX didn't Motive Themen Version change. Thx Harald -- Diese Nachricht wurde von meinem Mobiltelefon gesendet.

3 6

Released Pigeonhole v0.4.20 for Dovecot v2.2.32.
by Stephan Bosch 27 Aug '17

27 Aug '17

Hello Dovecot users, Here's the definitive 0.4.20 release. There were no changes since the release candidate. Changelog v0.4.20: + Made the retention period for redirect duplicate identifiers configurable. For accounts that perform many redirects, the lda-dupes database could grow to impractical sizes. Changed the default retention period from 24 to 12 hours. - sieve-filter: Fixed memory leak: forgot to clean up script binary at end of execution. Normally, this would merely be an inconsequential memory leak. However, when the script comes from an LDAP storage, this would cause io leak warnings. - managesieve-login: Fixed handling of AUTHENTICATE command. A second authenticate command would be parsed wrong. This problem was caused by changes in the previous release. - LDA Sieve plugin: Fixed minor memory leak caused by not cleaning up the sieve_discard script. The release is available as follows: https://pigeonhole.dovecot.org/releases/2.2/dovecot-2.2-pigeonhole-0.4.20.t… https://pigeonhole.dovecot.org/releases/2.2/dovecot-2.2-pigeonhole-0.4.20.t… Refer to http://pigeonhole.dovecot.org and the Dovecot v2.x wiki for more information. Have fun testing this release and don't hesitate to notify me when there are any problems. Regards, -- Stephan Bosch stephan(a)rename-it.nl

1 0

Re: a bit further along - OpenSSL - Re: trouble compiling Dovecot 2.2.31 on Solaris 10 SPARC - libssl_iostream_openssl.so is not portable!
by Joseph Tam 27 Aug '17

27 Aug '17

Aki Tuomi <aki.tuomi(a)dovecot.fi> writes: > > I simulated your compile arguments as best as I could, and compared the libtool > > command in my compile logs with your's. > > > > (mine) > > Mine: -lssl -lcrypto -lrt -lnsl -lsocket -lsendfile > > > > (your's) > > -lcrypto -lrt -lnsl -lsocket -lsendfile -lcrypt > > > > You're missing "-lssl" but have a spurious "-lcrypt". Probably all your missing symbols are > > actually in libssl.so. > > OpenSSL usually requires both libssl and libcrypto, the -lcrypt probably is for > crypt() Makes sense. So the OP can confirm this is the problem by manually running the libtool command but adding "-lssl", and if that works, then something screwed up Makefile or other build files. Joseph Tam <jtam.home(a)gmail.com>

1 0

[SUMMARY] trouble compiling Dovecot 2.2.31 on Solaris 10 SPARC - libssl_iostream_openssl.so is not portable!
by Jerry Kemp 26 Aug '17

26 Aug '17

I'm done. Good to go. Good compile + new binaries all built against the latest OpenSSL libraries. Big thank you to James, Joseph Tam and Aki Tuomi who game me pointers and kept me in the right direction. ........................................................................ These are the settings that made everything work for me. First, needed a current, up-to-date version of OpenSSL in place. Generally pretty easy task. I discovered that OpenSSL will not create shared libraries on Solaris using GNU make. No problem, everything worked just fine using the system /usr/ccs/bin/make . Back to Dovecot. Environmental variables - this is what I needed for my system. Although I'm a Sys V guy, never cared for the /opt thing, and ended up adopting /Applications from NeXT . setenv CPPFLAGS "-I/Applications/openssl-1.0.2l.32/include -I/Applications/openssl-1.0.2l.32/include/openssl" setenv LDFLAGS "-L/Applications/openssl-1.0.2l.32/lib" setenv SSL_CFLAGS "-I/Applications/openssl-1.0.2l.32/include -I/Applications/openssl-1.0.2l.32/include/openssl" setenv SSL_LIBS "-R/Applications/openssl-1.0.2l.32/lib -L/Applications/openssl-1.0.2l.32/lib" setenv LIBS "-lcrypto -lssl" setenv LD_LIBRARY_PATH "/Applications/openssl-1.0.2l.32/lib:/usr/lib:/usr/local/lib:/usr/xpg4/lib:/usr/openwin/lib:/usr/dt/lib" ........................................................................ Config statement: ./configure \ --prefix=/Applications/dovecot-2.2.32.32 \ --with-ssl=openssl \ --with-ssldir=/Applications/dovecot-2.2.32.31/certs ........................................................................ From there, it was run "make" then wait for the compile to finish. It had been a while since I did a fresh Dovecot compile, and in the past, I had just used the system provided OpenSSL install. This took a bit more work. Hope this can help out someone else in the future. Thank you, Jerry

1 0

dovecot: config: Error: BUG: Config client connection sent too much data
by Tony 26 Aug '17

26 Aug '17

Hello, Today I started noticing a very odd Dovecot error in the mail logs across 2 replicated Dovecot hosts via dsync. I have searched the Dovecot archives, Google, back tracked, downgraded Dovecot to earlier versions from earlier this year and ruled everything out I could think of to no avail. There really are not any helpful reports with what I am specifically seeing. The strange thing is only vmail(a)domain.net is repeatedly shown in the log. The error looks like this. *Aug 24 22:46:02 orbitron dovecot: config: Error: BUG: Config client connection sent too much data****Aug 24 22:46:02 orbitron dovecot: doveadm(vmail@domain.net@domain.net@domain.net@domain.net@domain.net@domain.net@domain.net@domain.net@domain.net): Fatal: Error reading configuration: read(/var/run/dovecot/config) failed: read(size=8192) failed: Connection reset by peer*** $ dovecot --version 2.2.31 (65cde28) Dovecot #1: Linux kernel 4.9.36-x86_64 Dovecot #2: Linux kernel 4.12.8-x86_64 Here are the latest Dovecot updates performed this year. [2017-04-29 14:45] [ALPM] upgraded dovecot (2.2.28-2 -> 2.2.28-3) [2017-05-02 23:05] [ALPM] upgraded dovecot (2.2.28-3 -> 2.2.29.1-1) [2017-06-11 17:20] [ALPM] upgraded dovecot (2.2.29.1-1 -> 2.2.30.2-1) [2017-06-30 22:46] [ALPM] upgraded dovecot (2.2.30.2-1 -> 2.2.31-1) When Dovecot was last updated back on June 30, I did `systemctl daemon-reload` but never actually restarted the Dovecot daemon until what seems like today. The only thing I did today was edit /etc/dovecot/conf.d/10-auth.conf by simply enabling "*auth_username_format = %Lu*" which was commented out before I enabled it. That is the /*only*/ thing that I tested. After I was done testing I went back and commented out the same thing so it reads "*#auth_username_format = %Lu*" and of course restarted Dovecot. I really doubt this has anything to do with what I am reporting as auth is not the problem in this case. Thank You, Tony

2 4

Re: a bit further along - OpenSSL - Re: trouble compiling Dovecot 2.2.31 on Solaris 10 SPARC - libssl_iostream_openssl.so is not portable!
by Joseph Tam 26 Aug '17

26 Aug '17

Jerry Kemp <dovecot(a)oryx.us> wrote: > same ENV variable setup and configure statement as originally used, but again, :( > ended up failing here: > .......................................................................... > libtool: link: gcc -std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes > -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 > -Wbad-function-cast -fno-builtin-strftime > -I/Applications/openssl-1.0.2l.32/include > -I/Applications/openssl-1.0.2l.32/include/openssl -o .libs/test-http-client > test-http-client.o -L/Applications/openssl-1.0.2l.32/lib ./.libs/libhttp.a > ../lib-dns/.libs/libdns.a ../lib-ssl-iostream/.libs/libssl_iostream.a > ../lib-master/.libs/libmaster.a ../lib-settings/.libs/libsettings.a > ../lib-test/.libs/libtest.a ../lib/.libs/liblib.a > ../lib-ssl-iostream/.libs/libssl_iostream_openssl.so -lcrypto -lrt -lnsl > -lsocket -lsendfile -lcrypt -R/Applications/dovecot-2.2.31.32/lib/dovecot I simulated your compile arguments as best as I could, and compared the libtool command in my compile logs with your's. (mine) Mine: -lssl -lcrypto -lrt -lnsl -lsocket -lsendfile (your's) -lcrypto -lrt -lnsl -lsocket -lsendfile -lcrypt You're missing "-lssl" but have a spurious "-lcrypt". Probably all your missing symbols are actually in libssl.so. Joseph Tam <jtam.home(a)gmail.com>

2 1