- dovecot - dovecot.org

Status of SMTPUTF8?
by Noah Tilton 14 Sep '18

14 Sep '18

I was wondering whether there is a roadmap for adding SMTPUTF8 support to Dovecot? My delivery pattern is Postfix -> Dovecot LMTP and it is choking on utf8 messages. I might be able to volunteer some of my time as a developer. Another thread about this seemed to go unanswered: http://dovecot.org/list/dovecot/2016-September/105474.html http://unix.stackexchange.com/questions/320091/configure-postfix-and-doveco… -Noah

4 3

LMTP tcp listener with auth?
by Andreas Thienemann 14 Sep '18

14 Sep '18

I am wondering if it's possible to have a tcp listener for LMTP do authentication and not accept any unauthenticated mail. My configuration looks like the following: service lmtp { inet_listener lmtp { address = 192.168.0.1 127.0.0.1 port = 24 } } This gives me a network reachable lmtp socket, but of course no autentication. When reading the docs, it seems though that only userdb lookup and no actual authentication is supported? Is that understanding correct? cheers, Andreas

4 3

Server certificate verification error with Dovecot 2.3.2.1
by Robert Gill 13 Sep '18

13 Sep '18

I'm attempting to upgrade my Dovecot installation to 2.3.2.1. My SSL certificate authority provides a bundle containing their CA, plus intermediate CAs, which I configure using the 'ssl_ca' option. The comments in the configuration file say to only set this when you're requiring client certificates, which I'm not, but fetchmail complains with a "Server certificate verification error, Broken certificate chain" error if that setting is not set. This works fine with Dovecot 2.2.34. After upgrading to 2.3.2.1, fetchmail throws that error whether 'ssl_ca' is set or not. Dovecot 2.3.2.1 reports the error SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca: SSL alert number 48 in the logs when attempting the TLS handshake. The permissions on the CA bundle haven't changed and should still be readable by Dovecot. I'm running Gentoo Linux on x86_64 and mail is stored on an ext4 file system. I'm attaching my config files for both Dovecot 2.2.34 and Dovecot 2.3.2.1.

3 3

dovecot + centos 7 + internal ca + hostname change
by Matt Bryant 13 Sep '18

13 Sep '18

Not sure if this is dovecot or not but can find very little ie no info around on this ... and added the pem file into /etc/pki/ca-trust/source/anchors and run udpate-ca-trust .. all works ok .. (this is on centos 7 btw) So wanted to change the hostname away from ip-x-x-x-x to something a little bit more descriptive .. but then kaboom .. doesnt work any more and the following errors are seen. Have created and internal CA for domain and added it to Sep 13 10:42:04 ip-10-0-40-230 dovecot: master: Dovecot v2.2.33.2 (d6601f4ec) starting up for imap, pop3, lmtp, sieve (core dumps disabled) Sep 13 10:42:04 ip-10-0-40-230 dovecot: auth: Error: p11-kit: 'attr->pValue != NULL' not true at attrs_build Sep 13 10:42:04 ip-10-0-40-230 dovecot: auth: Error: p11-kit: 'lexer->tok.field.name && lexer->tok.field.value' not true at p11_lexer_next Sep 13 10:42:04 ip-10-0-40-230 dovecot: auth: Error: p11-kit: 'attrs != NULL' not true at attrs_build Sep 13 10:42:04 ip-10-0-40-230 dovecot: message repeated 16 times: [ auth: Error: p11-kit: 'attrs != NULL' not true at attrs_build] Sep 13 10:42:04 ip-10-0-40-230 dovecot: auth: Error: p11-kit: 'new_memory != NULL' not true at maybe_expand_array Sep 13 10:42:04 ip-10-0-40-230 dovecot: auth: Error: p11-kit: shouldn't be reached at p11_array_push Sep 13 10:42:04 ip-10-0-40-230 dovecot: auth: Error: p11-kit: shouldn't be reached at sink_object Sep 13 10:42:04 ip-10-0-40-230 dovecot: auth: Error: p11-kit: 'attrs != NULL' not true at attrs_build Sep 13 10:42:04 ip-10-0-40-230 dovecot: auth: Error: p11-kit: 'new_memory != NULL' not true at maybe_expand_array Sep 13 10:42:04 ip-10-0-40-230 dovecot: auth: Error: p11-kit: shouldn't be reached at p11_array_push Sep 13 10:42:04 ip-10-0-40-230 dovecot: auth: Error: p11-kit: shouldn't be reached at sink_object ... ... Sep 13 10:42:04 ip-10-0-40-230 dovecot: auth: Error: p11-kit: 'new_memory != NULL' not true at maybe_expand_array Sep 13 10:42:04 ip-10-0-40-230 dovecot: auth: Error: p11-kit: shouldn't be reached at p11_array_push Sep 13 10:42:04 ip-10-0-40-230 dovecot: auth: Error: p11-kit: shouldn't be reached at sink_object Sep 13 10:42:04 ip-10-0-40-230 dovecot: auth: Error: p11-kit: 'attr->pValue != NULL' not true at attrs_build Sep 13 10:42:04 ip-10-0-40-230 dovecot: auth: Error: p11-kit: 'new_memory != NULL' not true at maybe_expand_array Sep 13 10:42:04 ip-10-0-40-230 dovecot: auth: Error: p11-kit: shouldn't be reached at p11_array_push Sep 13 10:42:04 ip-10-0-40-230 dovecot: auth: Error: p11-kit: shouldn't be reached at sink_object Sep 13 10:42:04 ip-10-0-40-230 dovecot: auth: Error: p11-kit: no CKA_CLASS attribute found Sep 13 10:42:04 ip-10-0-40-230 dovecot: auth: Error: p11-kit: couldn't load file into objects: /usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit Sep 13 10:42:05 ip-10-0-40-230 dovecot: auth-worker: Error: p11-kit: 'attrs != NULL' not true at attrs_build Sep 13 10:42:05 ip-10-0-40-230 dovecot: auth-worker: Fatal: master: service(auth-worker): child 14389 killed with signal 11 (core dumps disabled) Sep 13 10:42:05 ip-10-0-40-230 dovecot: auth-worker: Error: p11-kit: 'attrs != NULL' not true at attrs_build Sep 13 10:42:05 ip-10-0-40-230 dovecot: auth-worker: Fatal: master: service(auth-worker): child 14391 killed with signal 11 (core dumps disabled) Sep 13 10:42:05 ip-10-0-40-230 dovecot: auth-worker: Error: p11-kit: 'attrs != NULL' not true at attrs_build Sep 13 10:42:05 ip-10-0-40-230 dovecot: auth-worker: Fatal: master: service(auth-worker): child 14393 killed with signal 11 (core dumps disabled) why would a hostname change make any difference here .. the certs specified in dovecot config are all complete in their chain so not sure what its trying to do ... set hostname back to original works find .. so something is obviously tied or keyed to hostname though cant find anything specific anyone seen anything like this at all ?? rgds Matt

1 1

Re: make check (pigeonhole)
by Eric Broch 12 Sep '18

12 Sep '18

Must be non root user as well On 9/12/2018 1:05 PM, Aki Tuomi wrote: > Ok. We have that fix as well but for other reasons. Good to know this. > > --- > Aki Tuomi > Dovecot oy > > -------- Original message -------- > From: Eric Broch <ebroch(a)whitehorsetc.com> > Date: 12/09/2018 21:36 (GMT+02:00) > To: Aki Tuomi <aki.tuomi(a)dovecot.fi>, dovecot(a)dovecot.org > Subject: Re: make check (pigeonhole) > > Hi Aki, > > I needed this patch > <https://src.fedoraproject.org/cgit/rpms/dovecot.git/tree/dovecot-2.3.0.1-li…> > (fedora): > > |diff -up dovecot-2.3.0.1/src/auth/mycrypt.c.libxcrypt > dovecot-2.3.0.1/src/auth/mycrypt.c --- > dovecot-2.3.0.1/src/auth/mycrypt.c.libxcrypt 2018-02-28 > 15:28:58.000000000 +0100 +++ dovecot-2.3.0.1/src/auth/mycrypt.c > 2018-03-27 10:57:38.447769201 +0200 @@ -14,6 +14,7 @@ # define _XPG6 > /* Some Solaris versions require this, some break with this */ #endif > #include <unistd.h> +#include <crypt.h> #include "mycrypt.h" All works > well now. Thanks for your help Eric | > > On 9/12/2018 12:35 AM, Aki Tuomi wrote: >> >> I tried reproducing your problem and I only can make it happen if I >> run the test suite as root, which is not supported. >> >> Aki >> >> >> On 12.09.2018 06:49, Eric Broch wrote: >>> >>> I'll give those a look and make change accordingly. >>> >>> >>> On 9/11/2018 9:26 PM, Aki Tuomi wrote: >>>> You know we have rpm packages for 2.3.2.1 available at >>>> https://repo.dovecot.org if you are in a hurry? >>>> >>>> >>>> >>>> --- >>>> Aki Tuomi >>>> Dovecot oy >>>> >>>> -------- Original message -------- >>>> From: Eric Broch <ebroch(a)whitehorsetc.com> >>>> Date: 12/09/2018 00:35 (GMT+02:00) >>>> To: dovecot(a)dovecot.org >>>> Subject: Re: make check (pigeonhole) >>>> >>>> Any news on this error on CentOS 7 ? >>>> >>>> Help! >>>> >>>> >>>> On 9/10/2018 9:32 AM, Eric Broch wrote: >>>>> >>>>> I attempted as non-root user and got the exact same error. >>>>> >>>>> >>>>> On 9/10/2018 9:10 AM, Aki Tuomi wrote: >>>>>> Have you attempted this as non-root user? >>>>>> >>>>>> >>>>>> >>>>>> --- >>>>>> Aki Tuomi >>>>>> Dovecot oy >>>>> >>>>> -- >>>>> Eric Broch >>>>> White Horse Technical Consulting (WHTC) >>>> >>>> -- >>>> Eric Broch >>>> White Horse Technical Consulting (WHTC) >>> >>> -- >>> Eric Broch >>> White Horse Technical Consulting (WHTC) >> > > -- > Eric Broch > White Horse Technical Consulting (WHTC) -- Eric Broch White Horse Technical Consulting (WHTC)

1 0

Re: make check (pigeonhole)
by Eric Broch 12 Sep '18

12 Sep '18

I'll give those a look and make change accordingly. On 9/11/2018 9:26 PM, Aki Tuomi wrote: > You know we have rpm packages for 2.3.2.1 available at > https://repo.dovecot.org if you are in a hurry? > > > > --- > Aki Tuomi > Dovecot oy > > -------- Original message -------- > From: Eric Broch <ebroch(a)whitehorsetc.com> > Date: 12/09/2018 00:35 (GMT+02:00) > To: dovecot(a)dovecot.org > Subject: Re: make check (pigeonhole) > > Any news on this error on CentOS 7 ? > > Help! > > > On 9/10/2018 9:32 AM, Eric Broch wrote: >> >> I attempted as non-root user and got the exact same error. >> >> >> On 9/10/2018 9:10 AM, Aki Tuomi wrote: >>> Have you attempted this as non-root user? >>> >>> >>> >>> --- >>> Aki Tuomi >>> Dovecot oy >> >> -- >> Eric Broch >> White Horse Technical Consulting (WHTC) > > -- > Eric Broch > White Horse Technical Consulting (WHTC) -- Eric Broch White Horse Technical Consulting (WHTC)

2 3

Adding namespace alias_for causes index resync?
by Tom Sommer 12 Sep '18

12 Sep '18

I just added a new namespace-alias with alias_for. Apparently this causes all mailbox indexes to be resynced? Is this intentional and/or is there some way to avoid this? My NFS storage pretty much kills its elf when hundreds of thausands of users needs to resync indexes :) Thanks -- Tom

1 1

Re: LMTP tcp listener with auth?
by Andreas Thienemann 12 Sep '18

12 Sep '18

Hi Stephan, On Wed, 12 Sep 2018, Stephan Bosch wrote: > LMTP currently does not support AUTH. Bummer. Thought so. > What is your use case? Most people hide LMTP behind a firewall, or don't > expose it through TCP/IP in the first place. The port is currently only available to a few trusted machines, but having auth available would have been a nice benefit in case the firewall gets misconfigured. Cyrus for example will expose the LMTP port via TCP if configured, but expects valid user credentials. The larger use-case is a migration from cyrus to dovecot. As it's not just the MDA but also the MTA installation that is being migrated I need a way to deliver mail from the old MTA to the new MDA. LMTP comes in handy. https://github.com/ixs/lmtp_proxy/blob/master/README.md#minmal-downtime-mig… has a rough invocation of the steps needed for that. As I said, LMTP auth isn't critical for this, but would have been a nice addition. cheers, Andreas

1 0

Letsencrypt certificate for repo.dovecot.org expired May 14th..
by B. Reino 12 Sep '18

12 Sep '18

Dear all, Just in case you've missed it, the certificate for repo.dovecot.org just expired yesterday. This causes errors in e.g. apt-get update. Thanks in advance for fixing it, -- B. Reino

2 6

Re: make check (pigeonhole)
by Eric Broch 12 Sep '18

12 Sep '18

I attempted as non-root user and got the exact same error. On 9/10/2018 9:10 AM, Aki Tuomi wrote: > Have you attempted this as non-root user? > > > > --- > Aki Tuomi > Dovecot oy -- Eric Broch White Horse Technical Consulting (WHTC)

2 2

Log sync error
by Jakobus Schürz 11 Sep '18

11 Sep '18

Hi there! I get a lot of errormessages. My dovecot is: dovecot-core 2:2.3.2.1-1~stretch from Debian stable. I found this: https://www.dovecot.org/list/dovecot/2013-July/091648.html So the bug came back... The Log is attached Thanks Jakob

1 0

Re: make check (pigeonhole)
by Eric Broch 10 Sep '18

10 Sep '18

I did so as non-root user and got the same error. On 9/10/2018 9:10 AM, Aki Tuomi wrote: > Have you attempted this as non-root user? > > > > --- > Aki Tuomi > Dovecot oy > > -------- Original message -------- > From: Eric Broch <ebroch(a)whitehorsetc.com> > Date: 10/09/2018 18:03 (GMT+02:00) > To: dovecot(a)dovecot.org > Subject: Re: make check (pigeonhole) > > Dovecot list, > > 1) I downloaded latest dovecot and pigeonhole tar balls and extracted on > latest updated CentOS 7 : dovecot-2.3.2.1.tar.gz and > dovecot-2.3-pigeonhole-0.5.2.tar.gz > > 2) I moved pigeonhole (dovecot-2.3-pigeonhole-0.5.2) directory into > dovecot (dovecot-2.3.2.1) directory > > 3) built dovecot with following config and paramerters: > > patch -p1 < ../../SOURCES/dovecot-2.0-defaultconfig.patch > patch -p1 < ../../SOURCES/dovecot-1.0.beta2-mkcert-permissions.patch > patch -p1 < ../../SOURCES/dovecot-2.2.27-mkcert-paths.patch > > sed -i '/DEFAULT_INCLUDES *=/s|$| '"$(pkg-config --cflags > libclucene-core)|" src/plugins/fts-lucene/Makefile.in > > #export CFLAGS="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches > -fno-strict-aliasing" > #export LDFLAGS="-Wl,-z,now -Wl,-z,relro -Wl,-z,relro" > aclocal --install -I m4 > autoreconf -I . -fiv > > ./configure \ > INSTALL_DATA="install -c -p -m644" \ > --docdir=/usr/share/doc/dovecot-2.3.2.1 \ > --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-lucene \ > --with-ssl=openssl \ > --with-ssldir=/etc/pki/dovecot \ > --with-solr \ > --with-systemdsystemunitdir=/usr/lib/systemd/system \ > --with-docs > > sed -i 's|/etc/ssl|/etc/pki/dovecot|' doc/mkcert.sh > doc/example-config/conf.d/10-ssl.conf > > make -j3 > > 4) built pigeon hole with the following paramters: > > # required for snapshot > [ -f configure ] || autoreconf -fiv > [ -f ChangeLog ] || echo "Pigeonhole ChangeLog is not available, yet" > >ChangeLog > > ./configure \ > INSTALL_DATA="install -c -p -m644" \ > --disable-static \ > --with-dovecot=../ \ > --with-ldap=plugin \ > --without-unfinished-features > > make -j3 > > 5) during 'make check' of pigeonhole got the following error: > > make[3]: Entering directory > `/root/rpmbuild/SRPMS/dovecot-2.3.2.1/dovecot-2.3-pigeonhole-0.5.2/src/lib-sieve/util' > for bin in test-edit-mail; do \ > if ! /bin/sh ../../../run-test.sh ../../.. ./$bin; then exit 1; fi; \ > done > test-edit-header(root): Error: Cannot lookup test user: Mail access for > users with UID 89 not permitted (see first_valid_uid in config file, uid > from mail_uid setting). > ../../../run-test.sh: line 27: 29930 Segmentation fault (core > dumped) valgrind -q --trace-children=yes --leak-check=full > --log-file=test.out.$$ $noundef $* > ==29930== Invalid read of size 8 > ==29930== at 0x404699: mail_raw_user_create (mail-raw.c:142) > ==29930== by 0x40325B: test_init (test-edit-mail.c:105) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== by 0x524D8B1: test_run_funcs (test-common.c:244) > ==29930== by 0x524E280: test_run (test-common.c:315) > ==29930== by 0x402FE5: main (test-edit-mail.c:765) > ==29930== Address 0xb8 is not stack'd, malloc'd or (recently) free'd > ==29930== > ==29930== > ==29930== Process terminating with default action of signal 11 (SIGSEGV) > ==29930== Access not within mapped region at address 0xB8 > ==29930== at 0x404699: mail_raw_user_create (mail-raw.c:142) > ==29930== by 0x40325B: test_init (test-edit-mail.c:105) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== by 0x524D8B1: test_run_funcs (test-common.c:244) > ==29930== by 0x524E280: test_run (test-common.c:315) > ==29930== by 0x402FE5: main (test-edit-mail.c:765) > ==29930== If you believe this happened as a result of a stack > ==29930== overflow in your program's main thread (unlikely but > ==29930== possible), you can try to increase the size of the > ==29930== main thread stack using the --main-stacksize= flag. > ==29930== The main thread stack size used in this run was 8388608. > ==29930== 64 bytes in 1 blocks are possibly lost in loss record 35 of 77 > ==29930== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930== by 0x5277AB5: pool_system_malloc (mempool-system.c:75) > ==29930== by 0x525D2FD: p_malloc (mempool.h:99) > ==29930== by 0x525D2FD: hash_table_create (hash.c:70) > ==29930== by 0x51F377C: settings_parser_init_list > (settings-parser.c:215) > ==29930== by 0x51ED102: master_service_settings_read > (master-service-settings.c:595) > ==29930== by 0x51EE3A9: master_service_settings_cache_read > (master-service-settings-cache.c:387) > ==29930== by 0x4E874BF: mail_storage_service_read_settings > (mail-storage-service.c:1085) > ==29930== by 0x4E87745: mail_storage_service_lookup_real > (mail-storage-service.c:1249) > ==29930== by 0x4E88795: mail_storage_service_lookup > (mail-storage-service.c:1441) > ==29930== by 0x403223: test_init_mail_user (test-edit-mail.c:71) > ==29930== by 0x403223: test_init (test-edit-mail.c:103) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== by 0x524D8B1: test_run_funcs (test-common.c:244) > ==29930== > ==29930== 64 bytes in 1 blocks are possibly lost in loss record 36 of 77 > ==29930== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930== by 0x5277AB5: pool_system_malloc (mempool-system.c:75) > ==29930== by 0x525D2FD: p_malloc (mempool.h:99) > ==29930== by 0x525D2FD: hash_table_create (hash.c:70) > ==29930== by 0x51F2EA3: settings_parser_dup (settings-parser.c:1957) > ==29930== by 0x51EE844: cache_add (master-service-settings-cache.c:291) > ==29930== by 0x51EE844: master_service_settings_cache_read > (master-service-settings-cache.c:409) > ==29930== by 0x4E874BF: mail_storage_service_read_settings > (mail-storage-service.c:1085) > ==29930== by 0x4E87745: mail_storage_service_lookup_real > (mail-storage-service.c:1249) > ==29930== by 0x4E88795: mail_storage_service_lookup > (mail-storage-service.c:1441) > ==29930== by 0x403223: test_init_mail_user (test-edit-mail.c:71) > ==29930== by 0x403223: test_init (test-edit-mail.c:103) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== by 0x524D8B1: test_run_funcs (test-common.c:244) > ==29930== by 0x524E280: test_run (test-common.c:315) > ==29930== > ==29930== 64 bytes in 1 blocks are possibly lost in loss record 37 of 77 > ==29930== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930== by 0x5277AB5: pool_system_malloc (mempool-system.c:75) > ==29930== by 0x525D2FD: p_malloc (mempool.h:99) > ==29930== by 0x525D2FD: hash_table_create (hash.c:70) > ==29930== by 0x51F2EA3: settings_parser_dup (settings-parser.c:1957) > ==29930== by 0x4E8792F: mail_storage_service_lookup_real > (mail-storage-service.c:1324) > ==29930== by 0x4E88795: mail_storage_service_lookup > (mail-storage-service.c:1441) > ==29930== by 0x403223: test_init_mail_user (test-edit-mail.c:71) > ==29930== by 0x403223: test_init (test-edit-mail.c:103) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== by 0x524D8B1: test_run_funcs (test-common.c:244) > ==29930== by 0x524E280: test_run (test-common.c:315) > ==29930== by 0x402FE5: main (test-edit-mail.c:765) > ==29930== > ==29930== 128 bytes in 1 blocks are possibly lost in loss record 48 of 77 > ==29930== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930== by 0x5277456: block_alloc.isra.1 (mempool-alloconly.c:254) > ==29930== by 0x527768C: pool_alloconly_create (mempool-alloconly.c:138) > ==29930== by 0x403159: test_init (test-edit-mail.c:101) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== by 0x524D8B1: test_run_funcs (test-common.c:244) > ==29930== by 0x524E280: test_run (test-common.c:315) > ==29930== by 0x402FE5: main (test-edit-mail.c:765) > ==29930== > ==29930== 256 bytes in 1 blocks are possibly lost in loss record 52 of 77 > ==29930== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930== by 0x5277456: block_alloc.isra.1 (mempool-alloconly.c:254) > ==29930== by 0x527751D: pool_alloconly_malloc (mempool-alloconly.c:283) > ==29930== by 0x528A74E: p_malloc (mempool.h:99) > ==29930== by 0x528A74E: p_strdup_vprintf (strfuncs.c:167) > ==29930== by 0x528A833: p_strdup_printf (strfuncs.c:111) > ==29930== by 0x40318E: test_init_mail_user (test-edit-mail.c:52) > ==29930== by 0x40318E: test_init (test-edit-mail.c:103) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== by 0x524D8B1: test_run_funcs (test-common.c:244) > ==29930== by 0x524E280: test_run (test-common.c:315) > ==29930== by 0x402FE5: main (test-edit-mail.c:765) > ==29930== > ==29930== 256 bytes in 1 blocks are possibly lost in loss record 53 of 77 > ==29930== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930== by 0x5277456: block_alloc.isra.1 (mempool-alloconly.c:254) > ==29930== by 0x527768C: pool_alloconly_create (mempool-alloconly.c:138) > ==29930== by 0x5272941: event_create (lib-event.c:54) > ==29930== by 0x4E8797C: mail_storage_service_lookup_real > (mail-storage-service.c:1334) > ==29930== by 0x4E88795: mail_storage_service_lookup > (mail-storage-service.c:1441) > ==29930== by 0x403223: test_init_mail_user (test-edit-mail.c:71) > ==29930== by 0x403223: test_init (test-edit-mail.c:103) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== by 0x524D8B1: test_run_funcs (test-common.c:244) > ==29930== by 0x524E280: test_run (test-common.c:315) > ==29930== by 0x402FE5: main (test-edit-mail.c:765) > ==29930== > ==29930== 512 bytes in 1 blocks are possibly lost in loss record 56 of 77 > ==29930== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930== by 0x5277456: block_alloc.isra.1 (mempool-alloconly.c:254) > ==29930== by 0x527751D: pool_alloconly_malloc (mempool-alloconly.c:283) > ==29930== by 0x5272952: p_malloc (mempool.h:99) > ==29930== by 0x5272952: event_create (lib-event.c:56) > ==29930== by 0x4E8797C: mail_storage_service_lookup_real > (mail-storage-service.c:1334) > ==29930== by 0x4E88795: mail_storage_service_lookup > (mail-storage-service.c:1441) > ==29930== by 0x403223: test_init_mail_user (test-edit-mail.c:71) > ==29930== by 0x403223: test_init (test-edit-mail.c:103) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== by 0x524D8B1: test_run_funcs (test-common.c:244) > ==29930== by 0x524E280: test_run (test-common.c:315) > ==29930== by 0x402FE5: main (test-edit-mail.c:765) > ==29930== > ==29930== 1,024 bytes in 1 blocks are possibly lost in loss record 59 > of 77 > ==29930== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930== by 0x5277456: block_alloc.isra.1 (mempool-alloconly.c:254) > ==29930== by 0x527768C: pool_alloconly_create (mempool-alloconly.c:138) > ==29930== by 0x51F3741: settings_parser_init_list > (settings-parser.c:204) > ==29930== by 0x51ED102: master_service_settings_read > (master-service-settings.c:595) > ==29930== by 0x51EE3A9: master_service_settings_cache_read > (master-service-settings-cache.c:387) > ==29930== by 0x4E874BF: mail_storage_service_read_settings > (mail-storage-service.c:1085) > ==29930== by 0x4E87745: mail_storage_service_lookup_real > (mail-storage-service.c:1249) > ==29930== by 0x4E88795: mail_storage_service_lookup > (mail-storage-service.c:1441) > ==29930== by 0x403223: test_init_mail_user (test-edit-mail.c:71) > ==29930== by 0x403223: test_init (test-edit-mail.c:103) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== by 0x524D8B1: test_run_funcs (test-common.c:244) > ==29930== > ==29930== 1,024 bytes in 1 blocks are possibly lost in loss record 60 > of 77 > ==29930== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930== by 0x5277456: block_alloc.isra.1 (mempool-alloconly.c:254) > ==29930== by 0x527768C: pool_alloconly_create (mempool-alloconly.c:138) > ==29930== by 0x51F2D14: settings_parser_dup (settings-parser.c:1924) > ==29930== by 0x51EE844: cache_add (master-service-settings-cache.c:291) > ==29930== by 0x51EE844: master_service_settings_cache_read > (master-service-settings-cache.c:409) > ==29930== by 0x4E874BF: mail_storage_service_read_settings > (mail-storage-service.c:1085) > ==29930== by 0x4E87745: mail_storage_service_lookup_real > (mail-storage-service.c:1249) > ==29930== by 0x4E88795: mail_storage_service_lookup > (mail-storage-service.c:1441) > ==29930== by 0x403223: test_init_mail_user (test-edit-mail.c:71) > ==29930== by 0x403223: test_init (test-edit-mail.c:103) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== by 0x524D8B1: test_run_funcs (test-common.c:244) > ==29930== by 0x524E280: test_run (test-common.c:315) > ==29930== > ==29930== 1,024 bytes in 1 blocks are possibly lost in loss record 61 > of 77 > ==29930== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930== by 0x5277456: block_alloc.isra.1 (mempool-alloconly.c:254) > ==29930== by 0x527768C: pool_alloconly_create (mempool-alloconly.c:138) > ==29930== by 0x51F2D14: settings_parser_dup (settings-parser.c:1924) > ==29930== by 0x4E8792F: mail_storage_service_lookup_real > (mail-storage-service.c:1324) > ==29930== by 0x4E88795: mail_storage_service_lookup > (mail-storage-service.c:1441) > ==29930== by 0x403223: test_init_mail_user (test-edit-mail.c:71) > ==29930== by 0x403223: test_init (test-edit-mail.c:103) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== by 0x524D8B1: test_run_funcs (test-common.c:244) > ==29930== by 0x524E280: test_run (test-common.c:315) > ==29930== by 0x402FE5: main (test-edit-mail.c:765) > ==29930== > ==29930== 1,024 bytes in 1 blocks are possibly lost in loss record 62 > of 77 > ==29930== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930== by 0x5277456: block_alloc.isra.1 (mempool-alloconly.c:254) > ==29930== by 0x527751D: pool_alloconly_malloc (mempool-alloconly.c:283) > ==29930== by 0x5250ED5: p_malloc (mempool.h:99) > ==29930== by 0x5250ED5: buffer_alloc (buffer.c:34) > ==29930== by 0x525110C: buffer_create_dynamic (buffer.c:143) > ==29930== by 0x5272805: array_create_i (array.h:129) > ==29930== by 0x5272805: event_get_field (lib-event.c:383) > ==29930== by 0x5273283: event_add_str (lib-event.c:400) > ==29930== by 0x5273437: event_add_fields (lib-event.c:438) > ==29930== by 0x4E879FD: mail_storage_service_lookup_real > (mail-storage-service.c:1335) > ==29930== by 0x4E88795: mail_storage_service_lookup > (mail-storage-service.c:1441) > ==29930== by 0x403223: test_init_mail_user (test-edit-mail.c:71) > ==29930== by 0x403223: test_init (test-edit-mail.c:103) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== > ==29930== 1,608 bytes in 1 blocks are possibly lost in loss record 67 > of 77 > ==29930== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930== by 0x5277AB5: pool_system_malloc (mempool-system.c:75) > ==29930== by 0x525D33D: p_malloc (mempool.h:99) > ==29930== by 0x525D33D: hash_table_create (hash.c:79) > ==29930== by 0x51F377C: settings_parser_init_list > (settings-parser.c:215) > ==29930== by 0x51ED102: master_service_settings_read > (master-service-settings.c:595) > ==29930== by 0x51EE3A9: master_service_settings_cache_read > (master-service-settings-cache.c:387) > ==29930== by 0x4E874BF: mail_storage_service_read_settings > (mail-storage-service.c:1085) > ==29930== by 0x4E87745: mail_storage_service_lookup_real > (mail-storage-service.c:1249) > ==29930== by 0x4E88795: mail_storage_service_lookup > (mail-storage-service.c:1441) > ==29930== by 0x403223: test_init_mail_user (test-edit-mail.c:71) > ==29930== by 0x403223: test_init (test-edit-mail.c:103) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== by 0x524D8B1: test_run_funcs (test-common.c:244) > ==29930== > ==29930== 1,608 bytes in 1 blocks are possibly lost in loss record 68 > of 77 > ==29930== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930== by 0x5277AB5: pool_system_malloc (mempool-system.c:75) > ==29930== by 0x525D33D: p_malloc (mempool.h:99) > ==29930== by 0x525D33D: hash_table_create (hash.c:79) > ==29930== by 0x51F2EA3: settings_parser_dup (settings-parser.c:1957) > ==29930== by 0x51EE844: cache_add (master-service-settings-cache.c:291) > ==29930== by 0x51EE844: master_service_settings_cache_read > (master-service-settings-cache.c:409) > ==29930== by 0x4E874BF: mail_storage_service_read_settings > (mail-storage-service.c:1085) > ==29930== by 0x4E87745: mail_storage_service_lookup_real > (mail-storage-service.c:1249) > ==29930== by 0x4E88795: mail_storage_service_lookup > (mail-storage-service.c:1441) > ==29930== by 0x403223: test_init_mail_user (test-edit-mail.c:71) > ==29930== by 0x403223: test_init (test-edit-mail.c:103) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== by 0x524D8B1: test_run_funcs (test-common.c:244) > ==29930== by 0x524E280: test_run (test-common.c:315) > ==29930== > ==29930== 1,608 bytes in 1 blocks are possibly lost in loss record 69 > of 77 > ==29930== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930== by 0x5277AB5: pool_system_malloc (mempool-system.c:75) > ==29930== by 0x525D33D: p_malloc (mempool.h:99) > ==29930== by 0x525D33D: hash_table_create (hash.c:79) > ==29930== by 0x51F2EA3: settings_parser_dup (settings-parser.c:1957) > ==29930== by 0x4E8792F: mail_storage_service_lookup_real > (mail-storage-service.c:1324) > ==29930== by 0x4E88795: mail_storage_service_lookup > (mail-storage-service.c:1441) > ==29930== by 0x403223: test_init_mail_user (test-edit-mail.c:71) > ==29930== by 0x403223: test_init (test-edit-mail.c:103) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== by 0x524D8B1: test_run_funcs (test-common.c:244) > ==29930== by 0x524E280: test_run (test-common.c:315) > ==29930== by 0x402FE5: main (test-edit-mail.c:765) > ==29930== > ==29930== 2,048 bytes in 1 blocks are possibly lost in loss record 70 > of 77 > ==29930== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930== by 0x5277456: block_alloc.isra.1 (mempool-alloconly.c:254) > ==29930== by 0x527768C: pool_alloconly_create (mempool-alloconly.c:138) > ==29930== by 0x4E8C454: mailbox_attributes_init > (mailbox-attribute.c:17) > ==29930== by 0x4E7F2F5: mail_storage_init (mail-storage.c:70) > ==29930== by 0x4E87139: mail_storage_service_init > (mail-storage-service.c:975) > ==29930== by 0x403205: test_init_mail_user (test-edit-mail.c:66) > ==29930== by 0x403205: test_init (test-edit-mail.c:103) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== by 0x524D8B1: test_run_funcs (test-common.c:244) > ==29930== by 0x524E280: test_run (test-common.c:315) > ==29930== by 0x402FE5: main (test-edit-mail.c:765) > ==29930== > ==29930== 2,048 bytes in 1 blocks are possibly lost in loss record 71 > of 77 > ==29930== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930== by 0x5277456: block_alloc.isra.1 (mempool-alloconly.c:254) > ==29930== by 0x527768C: pool_alloconly_create (mempool-alloconly.c:138) > ==29930== by 0x4E8714A: mail_storage_service_init > (mail-storage-service.c:977) > ==29930== by 0x403205: test_init_mail_user (test-edit-mail.c:66) > ==29930== by 0x403205: test_init (test-edit-mail.c:103) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== by 0x524D8B1: test_run_funcs (test-common.c:244) > ==29930== by 0x524E280: test_run (test-common.c:315) > ==29930== by 0x402FE5: main (test-edit-mail.c:765) > ==29930== > ==29930== 2,048 bytes in 1 blocks are possibly lost in loss record 72 > of 77 > ==29930== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930== by 0x5277456: block_alloc.isra.1 (mempool-alloconly.c:254) > ==29930== by 0x527751D: pool_alloconly_malloc (mempool-alloconly.c:283) > ==29930== by 0x528AA66: p_malloc (mempool.h:99) > ==29930== by 0x528AA66: p_strconcat (strfuncs.c:223) > ==29930== by 0x51F40ED: settings_parse_keyvalue (settings-parser.c:845) > ==29930== by 0x51F50E0: settings_parse_environ (settings-parser.c:1103) > ==29930== by 0x51ED247: master_service_settings_read > (master-service-settings.c:648) > ==29930== by 0x51EE3A9: master_service_settings_cache_read > (master-service-settings-cache.c:387) > ==29930== by 0x4E874BF: mail_storage_service_read_settings > (mail-storage-service.c:1085) > ==29930== by 0x4E87745: mail_storage_service_lookup_real > (mail-storage-service.c:1249) > ==29930== by 0x4E88795: mail_storage_service_lookup > (mail-storage-service.c:1441) > ==29930== by 0x403223: test_init_mail_user (test-edit-mail.c:71) > ==29930== by 0x403223: test_init (test-edit-mail.c:103) > ==29930== > ==29930== 6,144 bytes in 1 blocks are possibly lost in loss record 74 > of 77 > ==29930== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930== by 0x5277456: block_alloc.isra.1 (mempool-alloconly.c:254) > ==29930== by 0x527768C: pool_alloconly_create (mempool-alloconly.c:138) > ==29930== by 0x4E876FA: mail_storage_service_lookup_real > (mail-storage-service.c:1238) > ==29930== by 0x4E88795: mail_storage_service_lookup > (mail-storage-service.c:1441) > ==29930== by 0x403223: test_init_mail_user (test-edit-mail.c:71) > ==29930== by 0x403223: test_init (test-edit-mail.c:103) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== by 0x524D8B1: test_run_funcs (test-common.c:244) > ==29930== by 0x524E280: test_run (test-common.c:315) > ==29930== by 0x402FE5: main (test-edit-mail.c:765) > ==29930== > ==29930== 12,288 bytes in 1 blocks are possibly lost in loss record 75 > of 77 > ==29930== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930== by 0x5277456: block_alloc.isra.1 (mempool-alloconly.c:254) > ==29930== by 0x527768C: pool_alloconly_create (mempool-alloconly.c:138) > ==29930== by 0x51EDD31: master_service_settings_cache_init > (master-service-settings-cache.c:75) > ==29930== by 0x4E87541: mail_storage_service_read_settings > (mail-storage-service.c:1073) > ==29930== by 0x4E87745: mail_storage_service_lookup_real > (mail-storage-service.c:1249) > ==29930== by 0x4E88795: mail_storage_service_lookup > (mail-storage-service.c:1441) > ==29930== by 0x403223: test_init_mail_user (test-edit-mail.c:71) > ==29930== by 0x403223: test_init (test-edit-mail.c:103) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== by 0x524D8B1: test_run_funcs (test-common.c:244) > ==29930== by 0x524E280: test_run (test-common.c:315) > ==29930== by 0x402FE5: main (test-edit-mail.c:765) > ==29930== > ==29930== 16,384 bytes in 1 blocks are possibly lost in loss record 76 > of 77 > ==29930== at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930== by 0x5277456: block_alloc.isra.1 (mempool-alloconly.c:254) > ==29930== by 0x527768C: pool_alloconly_create (mempool-alloconly.c:138) > ==29930== by 0x51ED84C: master_service_settings_read > (master-service-settings.c:580) > ==29930== by 0x51EE3A9: master_service_settings_cache_read > (master-service-settings-cache.c:387) > ==29930== by 0x4E874BF: mail_storage_service_read_settings > (mail-storage-service.c:1085) > ==29930== by 0x4E87745: mail_storage_service_lookup_real > (mail-storage-service.c:1249) > ==29930== by 0x4E88795: mail_storage_service_lookup > (mail-storage-service.c:1441) > ==29930== by 0x403223: test_init_mail_user (test-edit-mail.c:71) > ==29930== by 0x403223: test_init (test-edit-mail.c:103) > ==29930== by 0x4036DA: test_edit_mail_concatenated > (test-edit-mail.c:187) > ==29930== by 0x524D8B1: test_run_funcs (test-common.c:244) > ==29930== by 0x524E280: test_run (test-common.c:315) > ==29930== > Failed to run: ./test-edit-mail > > *Note: Previous versions of pigeonhole did a 'make check' successfully > even the first version of 2.3 (CE). Pigeonhole v0.5.1 and v0.5.2 fail on > CentOS 7 > > Help would be appreciated. > > > On 9/9/2018 3:11 PM, Eric Broch wrote: > > Anyone? > > > > > > On 9/8/2018 7:36 PM, Eric Broch wrote: > >> Hello list, > >> > >> During the 'make check' (pigeonhole) portion of a building (rpmbuild) > >> a dovecot.spec file I'm getting the following error: > >> > >> testsuite(root): Fatal: Couldn't drop privileges: User is missing UID > >> (see mail_uid setting) > >> > >> I'm not sure how to resolve this, and any help would be appreciated > >> to help me finish the creating the rpm > >> > > > > -- > Eric Broch > White Horse Technical Consulting (WHTC) > -- Eric Broch White Horse Technical Consulting (WHTC)

1 0

make check (pigeonhole)
by Eric Broch 10 Sep '18

10 Sep '18

Hello list, During the 'make check' (pigeonhole) portion of a building (rpmbuild) a dovecot.spec file I'm getting the following error: testsuite(root): Fatal: Couldn't drop privileges: User is missing UID (see mail_uid setting) I'm not sure how to resolve this, and any help would be appreciated to help me finish the creating the rpm -- Eric Broch White Horse Technical Consulting (WHTC)

2 4

dsync mail from a remote server
by Kai Schaetzl 10 Sep '18

10 Sep '18

I would like to transfer mail for some users from an old dovecot (with no doveadm) to a modern dovecot (2.3.2). I've read up on https://wiki2.dovecot.org/Tools/Doveadm/Sync https://wiki2.dovecot.org/Migration/Dsync and I'm not sure if I can use doveadm for this purpose. I need doveadm to login to the remote server (source) with a username/password via IMAP, fetch all mail and deliver it to a local user (target), preferrably with the same folder structure that exists on the source account. Is this possible? I don't understand this page completely: https://wiki2.dovecot.org/Migration/Dsync For some testing (that's why I used pop3, to keep it simple) I put a file for pop3c in conf.d (mostly identical with the file shown on that page) and restarted dovecot. Then I tried a command line like this: doveadm -o pop3c_user=user -o pop3c_password=password backup -R -u user@domain pop3c: This creates an error: dsync(user@domain): Error: Mail locations must use the same virtual mailbox hierarchy separator (specify separator for the default namespace) I'm not sure what this exactly means. Does it refer to the account naming structure of user@domain? The source server does not have such usernames, only the target server I run the command on. Or does it refer to structure within the mailbox? (which can't really be the case as it doesn't login to the source and can't know the structure yet). So, if it indeed refers to the user naming structure, can I tell it to use the "simple" account names on the source machine? Am I correct in assuming that I can override any pop3c_ setting in the conf file with -o? For instance also using -o pop3c_host= and that if there is -o pop3c_user=user on the command line I don't need a pop3c_user in the conf file? (no master-user). Thanks for any help on this. (If it doesn't work I can use fetchmail, but that is much less preferrable as it "delivers" all mail, so it's all "new" and in the INBOX. Kai

1 0

Disconnects on Director
by Tom Sommer 10 Sep '18

10 Sep '18

Hi I am seeing a lot of clients time out on my Director. I'm wondering if this is "normal" or there is some opportunity to tweak something? Log line: imap-login: Info: proxy(user(a)example.com): disconnecting 1.2.3.4 (Disconnected by client: read(size=433) failed: Connection timed out(37s idle, in=939, out=3083)): user=<user(a)example.com>, method=CRAM-MD5, rip=1.2.3.4, lip=172.0.0.0, TLS: read(size=433) failed: Connection timed out, session=<P2kq7H91H4dZF/2O> Any hints? Nothing is logged by the kernel. 2.3.2.1 -- Tom

2 1

Dovecot - being dropped
by Maurizio Caloro 10 Sep '18

10 Sep '18

Hello Yesterday, I could not receive an email anymore when I looked in the logs found the following errors: * Sep 7 06:04:44 mail dovecot: master: Warning: service(imap-login): process_limit (100) reached, client connections are being dropped * Sep 7 06:06:41 mail dovecot: master: Warning: service(imap-login): process_limit (100) reached, client connections are being dropped If show the config i dont see any process_limits Dovecot 2.2.13 root@mail:/var/log# dovecot -n # 2.2.13: /etc/dovecot/dovecot.conf # OS: Linux 3.16.0-6-amd64 x86_64 Debian 8.11 auth_mechanisms = plain login auth_verbose = yes disable_plaintext_auth = no info_log_path = /var/log/mail.log log_timestamp = %b %d %H:%M:%S Dovecot/ mail_access_groups = vmail mail_location = maildir:~/Maildir managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify vironment mailbox date ihave 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 = /etc/dovecot/dovecot-sql.conf.ext driver = sql } plugin { sieve = ~/sieve/.dovecot.sieve sieve_dir = ~/sieve } postmaster_address = admin@ protocols = imap pop3 lmtp service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } unix_listener auth-client { mode = 0660 user = mail } } service lmtp { inet_listener lmtp { address = 127.0.0.1 port = 24 } } ssl_cert = </etc/dovecot/dovecot.pem ssl_key = </etc/dovecot/private/dovecot.pem userdb { args = /etc/dovecot/dovecot-sql.conf.ext driver = sql } protocol lda { mail_plugins = " quota sieve" } protocol imap { mail_plugins = " quota imap_quota" } root@mail:/var/log#

3 3

Re: Dsync deleting mailboxes due to duplicate UIDs
by Andreas Thienemann 10 Sep '18

10 Sep '18

Hi Sami, On Sun, 9 Sep 2018, Sami Ketola wrote: > Is it possible to get imapc rawlogs to analyze? create a directory that is > writeable and add -o imapc_rawlog_dir=/path/to/directory to command line. Tried that. Thanks for the suggestion, that is actually really helpful. If anyone wants to play along at home, the files in that directory are created with the permissions of mail_uid/mail_gid. The dir should be world-writable to make it easy. > Also with recent dovecot release you can tell dsync which header fields to > hash when matching mails. Add dsync_hashed_headers=Message-ID to config and > dovecot will only mach mails using Message-ID header fileld. I had seen that parameter but thought it would be prudent to not _just_ rely on the Message-ID but instead keep the default "Date Message-ID". I _think_ I might have found an issue when looking at the log: 1536525811.026071 * 39 FETCH (UID 39 BODY[HEADER.FIELDS (Date Message-ID)] {159} 1536525811.026071 Message-ID: <Pine.LNX.4.30.0207091925420.433-100000(a)trinity.knopfdruck.org> 1536525811.026071 Date: Tue, 9 Jul 2002 19:26:04 +0200 (MEST) 1536525811.026071 Date: Tue, 9 Jul 2002 12:36:13 +0200 1536525811.026071 1536525811.026071 ) A duplicate Date header is certainly unexpected. Having a look at the original mail on disk on the Cyrus server shows the following Mail: >From [redacted] Tue Jul 9 19:26:04 2002 X-Sieve: cmu-sieve 1.3 Return-Path: [redacted] Received: from bender.bawue.de (localhost [127.0.0.1]) by bender.bawue.de (Postfix) with ESMTP id C79CE48CBC; Tue, 9 Jul 2002 19:29:08 +0200 (CEST) Delivered-To: [redacted] Received: from [redacted] by bender.bawue.de (Postfix) with ESMTP id CFA4848CAA for [redacted]; Tue, 9 Jul 2002 19:28:43 +0200 (CEST) From: [redacted] X-Sender: [redacted] To: [redacted] Message-ID: <Pine.LNX.4.30.0207091925420.433-100000(a)trinity.knopfdruck.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Subject: [redacted] Date: Tue, 9 Jul 2002 19:26:04 +0200 (MEST) Status: RO X-Status: X-Keywords: X-UID: 38 ---------- Forwarded message ---------- Date: Tue, 9 Jul 2002 12:36:13 +0200 Subject: Gewinn [redacted] So it looks like the Cyrus imapd is incorrectly parsing the mail and returning the body content as a header. Comparing the content of UID 39 on the remote server will then hash differently than the UID 39 on the local dovecot server, which behaves better and only returns a single date header. Following the robustness principle it feels to me that it would make sense for dsync to disregard a duplicate header from a remote server and only use the first occurence. Would that be a good approach to the problem? Now that I understand the problem I am having, I can just workaround it but it seems to me that dsync should handle this case better. Anyway, thanks a lot for the imapc_rawlog_dir hint, that helped a lot. cheers, Andreas

1 0

Re: Auth process sometimes stop responding after upgrade
by Simone Lazzaris 08 Sep '18

08 Sep '18

In data venerdì 7 settembre 2018 09:39:23 CEST, Aki Tuomi ha scritto: > Do you see anything else in logs? > Just the usual proxy messages, like these: Sep 6 14:45:41 imap-front13 dovecot: imap-login: proxy(alessandro(a)soldinicarrelli.it): disconnecting 5.169.233.224 (Disconnected by server(0s idle, in=451, out=3556)): user=<alessandro(a)soldinicarrelli.it>, method=PLAIN, rip=5.169.233.224, lip=80.76.81.92, TLS, session=<uqVq2TJ1VbkFqeng> Sep 6 14:45:51 imap-front13 dovecot: pop3-login: proxy(prg(a)pedrini.it): started proxying to 192.168.1.144:110: user=<prg(a)pedrini.it>, method=DIGEST- MD5, rip=5.34.191.10, lip=80.76.81.92, TLS, session=<WqhRRDN1qw0FIr8K> The only suspect thing is this: Sep 6 14:45:41 imap-front13 dovecot: director: doveadm: Host 192.168.1.142 vhost count changed from 100 to 0 Sep 6 14:45:41 imap-front13 dovecot: director: doveadm: Host 192.168.1.143 vhost count changed from 100 to 0 Sep 6 14:45:41 imap-front13 dovecot: director: doveadm: Host 192.168.1.219 vhost count changed from 100 to 0 Nothing on the other system logs (e.g. kernel, daemon, syslog, messages ....). -- *Simone Lazzaris* *Qcom S.p.A.*

5 11

Sievescript in database
by Harald Leithner 07 Sep '18

07 Sep '18

Hi, is it possible to save sieve scripts to a mysql database? I know its possible to read them with the dict sql plugin but iirc it wasn't possible to save it with sievemanaged. thx Harald -- Harald Leithner ITronic Wiedner Hauptstraße 120/5.1, 1050 Wien, Austria Tel: +43-1-545 0 604 Mobil: +43-699-123 78 4 78 Mail: leithner(a)itronic.at | itronic.at

1 0

Auth process sometimes stop responding after upgrade
by Simone Lazzaris 07 Sep '18

07 Sep '18

Hi all; I've upgraded a ring of dovecot directors from 2.2.15 to 2.2.36. After the upgrade I've got some instability: a few time per day per server, seemly at random, the auth process stop responding and the clients cannot authenticate any more: Sep 6 14:45:51 imap-front13 dovecot: pop3-login: Warning: Auth process not responding, delayed sending initial response (greeting): user=<>, rip=xx.xx.xx.xx, lip=xx.xx.xx.xx, TLS, session=<1HVqRTN10MNTie+S> I can't figure it out.... Any hints? This is my configuration: # 2.2.36 (1f10bfa63): /usr/local/etc/dovecot/dovecot.conf # OS: Linux 3.2.0-4-686-pae i686 Debian 7.11 # Hostname: imap-front13.mailfarm.interac.it auth_mechanisms = plain login digest-md5 cram-md5 apop scram-sha-1 auth_verbose = yes auth_verbose_passwords = plain auth_worker_max_count = 50 base_dir = /var/run/dovecot/ default_login_user = nobody director_doveadm_port = 9091 director_mail_servers = 192.168.1.142 192.168.1.143 192.168.1.144 192.168.1.145 192.168.1.216 192.168.1.217 192.168.1.218 192.168.1.219 director_servers = 212.183.164.157 212.183.164.158 212.183.164.159 212.183.164.160 listen = * passdb { args = /usr/local/etc/dovecot/sql.conf driver = sql } protocols = imap pop3 service director { fifo_listener login/proxy-notify { mode = 0666 } inet_listener { port = 9090 } unix_listener director-userdb { mode = 0600 } unix_listener login/director { mode = 0666 } } service imap-login { executable = imap-login director service_count = 0 vsz_limit = 128 M } service pop3-login { executable = pop3-login director service_count = 0 vsz_limit = 128 M } ssl_cert = </usr/local/etc/dovecot/qcom.wildcard.pem 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:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128- SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:! MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA ssl_dh_parameters_length = 2048 ssl_key = # hidden, use -P to show it ssl_parameters_regenerate = 1 weeks ssl_prefer_server_ciphers = yes ssl_protocols = !SSlv2 !SSLv3 syslog_facility = local5 userdb { driver = prefetch } -- *Simone Lazzaris* *Qcom S.p.A.*

2 1

Virtual Maildir as subfolder
by Duncan Bellamy 07 Sep '18

07 Sep '18

I have a setup where google fetches mail from dovecot with pop3s and deletes mail downloaded, so to do this I currently forward a copy of the email to user-fetch@localhost which is the google login and it downloads from that maildir. But it means creating extra folders and I was looking at better ways of doing it. So I have an entry in my user DB file which ends with userdb_mail=maildir:/var/mail/virtual/adomain.com/user/Maildir/.Gfetch, and if I do a "doveadm auth test user(a)adomain.xn--com-9o0a it shows the correct mail location of the .Gfetch folder. But even though it has 6 messages in the folder a doveadm search and google both see zero messages. I think this is because the index file is only in the root of the maildir, is there a way to have a ‘virtual root’ inside a maildir like this? Thanks, Duncan

1 0

Auth process sometimes stop responding after upgrade
by Simone Lazzaris 06 Sep '18

06 Sep '18

Hi all; I've upgraded a ring of dovecot directors from 2.2.15 to 2.2.36. After the upgrade I've got some instability: a few time per day per server, seemly at random, the auth process stop responding and the clients cannot authenticate any more: Sep 6 14:45:51 imap-front13 dovecot: pop3-login: Warning: Auth process not responding, delayed sending initial response (greeting): user=<>, rip=xx.xx.xx.xx, lip=xx.xx.xx.xx, TLS, session=<1HVqRTN10MNTie+S> I can't figure it out.... Any hints? This is my configuration: # 2.2.36 (1f10bfa63): /usr/local/etc/dovecot/dovecot.conf # OS: Linux 3.2.0-4-686-pae i686 Debian 7.11 # Hostname: imap-front13.mailfarm.interac.it auth_mechanisms = plain login digest-md5 cram-md5 apop scram-sha-1 auth_verbose = yes auth_verbose_passwords = plain auth_worker_max_count = 50 base_dir = /var/run/dovecot/ default_login_user = nobody director_doveadm_port = 9091 director_mail_servers = 192.168.1.142 192.168.1.143 192.168.1.144 192.168.1.145 192.168.1.216 192.168.1.217 192.168.1.218 192.168.1.219 director_servers = 212.183.164.157 212.183.164.158 212.183.164.159 212.183.164.160 listen = * passdb { args = /usr/local/etc/dovecot/sql.conf driver = sql } protocols = imap pop3 service director { fifo_listener login/proxy-notify { mode = 0666 } inet_listener { port = 9090 } unix_listener director-userdb { mode = 0600 } unix_listener login/director { mode = 0666 } } service imap-login { executable = imap-login director service_count = 0 vsz_limit = 128 M } service pop3-login { executable = pop3-login director service_count = 0 vsz_limit = 128 M } ssl_cert = </usr/local/etc/dovecot/qcom.wildcard.pem 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:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128- SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:! PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA ssl_dh_parameters_length = 2048 ssl_key = # hidden, use -P to show it ssl_parameters_regenerate = 1 weeks ssl_prefer_server_ciphers = yes ssl_protocols = !SSlv2 !SSLv3 syslog_facility = local5 userdb { driver = prefetch } *Simone Lazzaris* *Qcom S.p.A.* simone.lazzaris(a)qcom.it[1] | www.qcom.it[2] * LinkedIn[3]* | *Facebook[4]* [5] -------- [1] mailto:simone.lazzaris@qcom.it [2] https://www.qcom.it [3] https://www.linkedin.com/company/qcom-spa [4] http://www.facebook.com/qcomspa [5] https://www.qcom.it/includes/email-banner.gif

1 0

Global duplicate filtering via Sieve
by Hanno Stock 06 Sep '18

06 Sep '18

Hi everybody, I have the following problem: Our mail users are receiving mails from externally defined mail forwardings and lists which sometimes leads to duplicate messages. As far as I understand, a single user can use the Sieve duplicate extension for filtering out such duplicate messages. Would it be feasible to add a script with sieve_before that does this for all users? Do scripts that run from sieve_before store persistent data also on a per-user basis, i.e. in the user's home dir? Thanks for your help! Best regards Hanno

2 1

Specifying other mail_attachment_dir for namespace
by Pedro Ribeiro 04 Sep '18

04 Sep '18

Hello, I have a Dovecot setup where I need to allow users to access a snapshot of their messages (when they complain about missing messages/folders deleted by mistake). From time to time the system does a LVM snapshot of the volume holding the mailboxes and sis storage and that messages are available via a "special" namespace. The problem is the messages that references attachments in the single attachment storage cause the file in some cases (when all the references were delete), the attachment itself is missing from the current SIS. Is there any option to reference a specific SIS folder for the namespace like I do for the messages as below? > namespace arquivo { > type = private > separator = / > prefix = "@ARQUIVO/" > subscriptions = yes > list = yes > inbox = no > hidden = no > ignore_on_failure = yes > location = mdbox:/mail-snap/domains/%d/%-2.2n/%n > } TIA. -- Best regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Pedro Ribeiro Politécnico de Lisboa, Serviços da Presidência Departamento de Sistemas de Informação e Comunicações Phone: +351 210 464 700 (general) / VoIP: 80100 Helpdesk: helpdesk(a)net.ipl.pt / https://www.net.ipl.pt =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

1 0

Re: online conversion using replication?
by Daniel Miller 04 Sep '18

04 Sep '18

That works for a one-time migration, or perhaps via a cron-job, but what I want is basically a constant one-way backup and it seems replication could do it more elegantly & efficiently. -- Daniel On 9/1/2018 11:14 PM, Aki Tuomi wrote: > You don't need to setup replication for that. See > https://wiki2.dovecot.org/Migration/MailFormat > > --- > Aki Tuomi > Dovecot oy > > -------- Original message -------- > From: Daniel Miller <dmiller(a)amfes.com> > Date: 02/09/2018 04:14 (GMT+02:00) > To: Dovecot Mailing List <dovecot(a)dovecot.org> > Subject: online conversion using replication? > > With a single server - and no intent to have a second server online at > this time - is it possible to use the replication service to keep a > "live" backup? Or otherwise perform a storage format conversion? > > I'm presently using sdbox - and considering going back to mdbox though > without SIS. My intent now is ONLY a 1-way backup, to be kept current, > and no clients will utilize the converted storage (unless/until I change). > > I've successfully executed: > > doveadm backup -u <username> -n inbox > mdbox:/var/mail/<domain>/<user>/mdbox > > For a few users - but reading the docs leads me to believe I can > automate this. But there's no explicit example for this - so I'm not > sure what to set. > > Initially I'm thinking of: > > dsync_remote_cmd = doveadm backup -u %u -n inbox > mdbox:/var/mail/%d/%n/mdbox > > and if that's right - which other services/listeners do I need to setup? > > -- > Daniel >

5 5