- dovecot - dovecot.org

How to send mail to mailbox with disabled domain?
by Kai Schaetzl 17 Sep '18

17 Sep '18

Given the following: mailboxes: user1(a)example1.com user2(a)example1.com user3(a)example1.com etc. aliases: whatever(a)example1.com -> user1(a)example1.com whatever(a)example2.com -> user1(a)example1.com whatever(a)example3.com -> user1(a)example1.com Now the problem: example1.com MX goes elsewhere (doesn't point to this server anymore). Domains example2.com and example3.com still point to that server and should be able to accept mail. I have to disable mail acceptance for example1.com. If not, mail sent *from* that server (e.g. from a web form) to that domain will not leave the server. However, if I disable example1.com for mail dovecot lmtp will not deliver mail to this mail box anymore, although the mailbox still exists. How can I solve this? Is there a way of solving this, but keeping the domain example1.com in the name for these mailboxes? Or is there a way to tell dovecot to ignore domains for mailbox names? e.g. deliver to "user1"? (All user localparts are unique.) Thanks for any hints. Kai

4 6

Re: Proxy secured incoming POP3/IMAP4 to unsecure backend?
by Alexander Chekalin 17 Sep '18

17 Sep '18

Thank you! Ok, so I can omit ssl=no and startssl=no, and this results in default settings for ssl which is 'off'? Or the defaults are 'on' anyway? Can I somehow specify ports on remote hosts that proxy will use to connect to? Like (just image): 'proxy host_imap=10.1.1.1:143 host_pop=10.1.1.1:110' or somehow? On Mon, Sep 17, 2018 at 4:33 PM Aki Tuomi <aki.tuomi(a)dovecot.fi> wrote: > Due to certain design issues, the ssl=no is actually same as ssl=yes, same > goes for starttls=no. So there is no support actually for "ssl=no" at this > moment. > > Aki > > > On 17 September 2018 at 15:32 Alexander Chekalin < > alexander.chekalin(a)gmail.com> wrote: > > > > > > Surely. > > > > Here it is: > > > > # doveadm auth user(a)domain.com > > Password: > > passdb: chekalin_krg(a)ascon.ru auth succeeded > > extra fields: > > user=user(a)domain.com > > proxy > > host=10.10.14.131 > > ssl=no > > startssl=no > > source_ip=10.10.14.2 > > proxy > > proxy > > pass=password > > > > Two "proxy" are from two "proxy" and "proxy=yes" settings passed from > > passdb. > > > > On Mon, Sep 17, 2018 at 3:03 PM Aki Tuomi <aki.tuomi(a)dovecot.fi> wrote: > > > > > Can you provide output of > > > > > > doveadm auth test some-user > > > Aki > > > > > > On 17.09.2018 14:58, Alexander Chekalin wrote: > > > > > > Dear Aki, > > > > > > we keep our users in LDAP so I when I even return 'proxy > host=backend_ip > > > tls=no' it won't use non-TLS connection. The same is when I remove > 'tls=no' > > > part. May there be any extra things I need to pass when I use LDAP? > > > > > > On Mon, Sep 17, 2018 at 2:07 PM Aki Tuomi <aki.tuomi(a)dovecot.fi> > wrote: > > > > > >> > > >> > > >> On 17.09.2018 13:59, Alexander Chekalin wrote: > > >> > Hi, > > >> > > > >> > I try to set up dovecot as a proxy server, to proxy requests to > > >> > several dovecot-based backend servers. I wand external clients who > > >> > connects to this proxy Dovecot to use TLS (this is easy to set up) > > >> > while want to have unsecured (plain IMAP/POP) connections to > backends. > > >> > > > >> > You see, links to backends are over LAN so no TLS needed, and these > > >> > backends are poor old machines (with old Docecots like 2.0.6) this > is > > >> > why I don't want to use TLS to acces backends. > > >> > > > >> > But as I did the test setup I can see proxy Dovecot uses TLS to > > >> > connect to backends. Is there any way I can specify this aspect of > > >> > Dovecot proxy? > > >> > > > >> > Please advice! > > >> > > > >> > Yours, > > >> > Alexander > > >> > > >> Dovecot does not use TLS/SSL when connecting to a backend server by > > >> default, you are probably specifying this in your proxy config or > > >> password database. > > >> > > >> Aki > > >> > > > > > > >

2 5

Proxy secured incoming POP3/IMAP4 to unsecure backend?
by Alexander Chekalin 17 Sep '18

17 Sep '18

Hi, I try to set up dovecot as a proxy server, to proxy requests to several dovecot-based backend servers. I wand external clients who connects to this proxy Dovecot to use TLS (this is easy to set up) while want to have unsecured (plain IMAP/POP) connections to backends. You see, links to backends are over LAN so no TLS needed, and these backends are poor old machines (with old Docecots like 2.0.6) this is why I don't want to use TLS to acces backends. But as I did the test setup I can see proxy Dovecot uses TLS to connect to backends. Is there any way I can specify this aspect of Dovecot proxy? Please advice! Yours, Alexander

3 2

Problem with envelope from in Pigeonhole after upgrade
by David Dodd 17 Sep '18

17 Sep '18

On our FreeBSD 11.2 servers, we recently upgraded from: dovecot2-2.2.26.0_1 dovecot-pigeonhole-0.4.16_1 to: dovecot-2.3.2.1 dovecot-pigeonhole-0.5.2_3 Prior to the upgrade the envelope sender was as expected. After the upgrade, the envelope sender for a user with a sieve script configured is now being set to: >From MAILER-DAEMON Tue Sep 04 13:31:39 2018 The same user without a sieve script in place gets: >From someone(a)gmail.com Tue Sep 04 11:06:04 2018 This happens when manually testing by directly executing: /usr/local/libexec/dovecot/dovecot-lda -d dgdtst -f someone(a)gmail.com It happens with an empty sieve script i.e. just using the implicit keep functionality. I have groped around looking for a configuration setting that might fix the behaviour but nothing I have tried helps. Can anyone suggest what to set to correct the problem ? -- Dave

2 7

Quotas not working with roundcube
by Mik J 17 Sep '18

17 Sep '18

Hello, I'm trying to have quotas working with roundcube. When I'm logged into roundcube I see 0% quota which seems to correspond to disabled. However I did everything that I could to enable quotas https://wiki.dovecot.org/Quota # doveconf -n auth_mechanisms = cram-md5 loginauth_verbose = yes debug_log_path = /tmp/dovecot.log first_valid_uid = 1000 log_path = /var/log/dovecot.log mail_gid = vmail mail_location = maildir:/home/mail/%d/%n/Maildir mail_plugins = notify replication quota mail_uid = vmail mbox_write_locks = fcntl mmap_disable = yes 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 { driver = bsdauth } passdb { args = /etc/dovecot/dovecot.passwd driver = passwd-file } plugin { quota_grace = 10%% quota_rule = *:storage=2G quota_rule2 = Trash:storage=+200M quota_rule3 = SPAM:ignore quota_status_nouser = DUNNO quota_status_overquota = 552 5.2.2 Mailbox is full quota_status_success = DUNNO quota_warning = storage=95%% quota-warning 95 %u quota_warning2 = storage=80%% quota-warning 80 %u } ssl_ca = /etc/ssl/certs/CA_Intermed_Lets_Encrypt.crt ssl_cert = </etc/ssl/certs/imap.mydomain.org.crt ssl_key = # hidden, use -P to show it ssl_key_password = # hidden, use -P to show it userdb { driver = passwd } userdb { driver = static } protocol lda { mail_plugins = notify replication quota } protocol imap { mail_plugins = notify replication quota imap_quota }

3 5

Dsync deleting mailboxes due to duplicate UIDs
by Andreas Thienemann 16 Sep '18

16 Sep '18

Hi, I am attempting to migrate a mailspool from a cyrus server to a dovecot server using the dsync backup approach as described in the wiki at <https://wiki.dovecot.org/Migration/Dsync>. The first attempt works great. Everything copies over and a quick glance over the spool looks good. Running doveadm backup again though results in the following error: dsync(eggs): Warning: Deleting mailbox 'INBOX.MailRestore': UID=39 already exists locally for a different mail: Headers hashes don't match (18d567fc7e258a67e47b629c8bb16500 vs 230354b2d5cad21ebbb4a7440b977adb) As promised, the folder MailRestore is gone after dsync finishes. Running doveadm backup again for the third time copies the folder again. Running it a fourth time gives the same error and the folder is gone. Trying to figure this out I initially had a few mails where the header hashes were 68b329da9893e34099c7d8ad5cb9c940, the md5sum of an empty string. Turns out that the source mailspool had a few broken emails and cleaning these out fixed most my issues. But in this case, I am stumped. UID 39 on the server is a valid mail with correct headers and everything. Is there a good way of identifying the two mails that seem to clash? I had a quick look at the dovecot code but did not see how the header_stream gets hashed into the hdr_hash used for comparing mails. Thanks, Andreas

3 5

dovecot_deleted_to_trash no longer compiles with dovecot 2.3.2.1
by Robert S 16 Sep '18

16 Sep '18

I have just upgraded to the latest version of dovecot (Gentoo amd64). When I try to compile the dovecot_deleted_to_trash plugin it won't compile. Is this plugin going to be updated (from https://github.com/lexbrugman/dovecot_deleted_to_trash - same error from https://github.com/NethServer/dovecot-deleted-to-trash)? # make cc \ -fPIC -shared -Wall \ -I/usr/include/dovecot \ -I/usr/include/dovecot/src \ -I/usr/include/dovecot/src/lib \ -I/usr/include/dovecot/src/lib-storage \ -I/usr/include/dovecot/src/lib-mail \ -I/usr/include/dovecot/src/lib-imap \ -I/usr/include/dovecot/src/lib-index \ -DHAVE_CONFIG_H \ src/deleted-to-trash-plugin.c -o lib_deleted_to_trash_plugin.so src/deleted-to-trash-plugin.c: In function ‘copy_deleted_mail_to_trash’: src/deleted-to-trash-plugin.c:117:16: error: too few arguments to function ‘mail box_transaction_begin’ dest_trans = mailbox_transaction_begin(trash_box, MAILBOX_TRANSACTION_FLAG_EX TERNAL); ^~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /usr/include/dovecot/mail-storage-private.h:7:0, from src/deleted-to-trash-plugin.h:5, from src/deleted-to-trash-plugin.c:4: /usr/include/dovecot/mail-storage.h:656:1: note: declared here mailbox_transaction_begin(struct mailbox *box, ^~~~~~~~~~~~~~~~~~~~~~~~~ make: *** [Makefile:32: lib_deleted_to_trash_plugin.so] Error 1 Some further info: # dovecot -n # 2.3.2.1 (0719df592): /etc/dovecot/dovecot.conf # OS: Linux 4.14.8-gentoo-r1 x86_64 Gentoo Base System release 2.4.1 # Hostname: basement-vm.schmidli.com.au doveconf: Warning: please set ssl_dh=</etc/dovecot/dh.pem doveconf: Warning: You can generate it with: dd if=/var/lib/dovecot/ssl-parameters.dat bs=1 skip=88 | openssl dhparam -inform der > /etc/dovecot/dh.pem dict { expire = db:/var/lib/dovecot/expire.db } disable_plaintext_auth = no listen = * mail_location = maildir:~/.maildir mail_plugins = deleted_to_trash mailbox_alias 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 = * driver = pam } plugin { deleted_to_trash_folder = Trash expire = Trash 7 Spam 30 expire_dict = proxy::expire

1 0

Re: auth_policy in a non-authenticating proxy chain
by Peter Mogensen 15 Sep '18

15 Sep '18

On 09/15/2018 10:41 AM, Aki Tuomi wrote: > Point of sending the success ones is to maintain whitelist as well as > blacklist so you know which ones you should not tarpit anymore. We > know it does scale as we have very large deployments using the whole > three request per login model. > > "Success" in a proxy which is not it self authenticating is only whether it know where to proxy the requested username to. I'm not sure whether this would be input to a whitelist. I'm not doubting that 3 req/login scales. /Peter

2 1

auth_policy in a non-authenticating proxy chain
by Peter Mogensen 15 Sep '18

15 Sep '18

Hi, I was looking into the new Authentication Policy feature: https://wiki2.dovecot.org/Authentication/Policy I had kinda hoped that I would be able to enfore this in a proxy running in front of several backends. This proxy does not authenticate. It use "nopassword". But I realize that the "succes" reported in the final authpolicy req. (command=report) is not what is actaully happening on the IMAP protocol level, but rather the result of the passdb chain in the proxy. (I should probably have predicted this, it's kinda reasonable). However... since the proxy use "nopassword", ALL passdb lookups result in "success", so the proxy will never report an authentication failure to the authpolicy server. This, of course, forces me to do the authpolicy check on the backend with a shared state, but It would still have been nice to have the proxy being able to do the first "command=allow" req. and reject attemps already there even though the backend does "command=report". /Peter

3 4

encryption issue in outlook 2016
by ChandranManikandan 14 Sep '18

14 Sep '18

Hi Friends, Am facing the serious issue in outlook 2016. When i tried to configure the email in outlook 2016 it's asking encrypted connection and checked automatically and if not available then it showing unencrypted. but finally unable to configure the email account in outlook 2016 and not permitted. Do i need to update any in the server. Am using COS 6 32 and 64 bit servers with qmailtoaster + dovecot 2.2.7. Currently configured in outlook 2010 it's working without any issue. And always showing in outlook 2010 when i open the account. Do you want to continue yes or no for the certification. Because i have configured in advanced selected Auto in outlook 2010. If i select none it was not working the email. Anyone facing the same issue. How do i rectify it in outlook 2016 and how can i stop the certificate warning message in outlook. If possible to use without encryption and what's the configuration. Please advice and let me know the process. Am seriously cannot access the email from outlook. I have attached the message while open outlook. If i click yes then it will open Is the certificate expired. How do renew it or reload it with the fresh certificate. -- *Thanks & Best Regards,Manikandan.C*

4 4

Occasional crash in db-auth.c (Valgrind: Invalid read of size 4 et al.), Dovecot 2.2.27+
by Jonas Wielicki 14 Sep '18

14 Sep '18

Dear list, We are encountering troubles with dovecot using LDAP userdbs on Debian stretch (but if I’m reading valgrind correctly, we can reproduce this with vanilla dovecot master). Minimal reproducer below. While testing an upgrade to Debian stretch (dovecot-core=1:2.2.27-3+deb9u1), auth-worker has stopped working. We are using two LDAP user databases; one which is iterable, and one which is not (for reasons; I think this is not relevant; if it is, we’re happy to elaborate). The issue seems to be present in any LDAP userdb iteration handling, but it only seems to cause a crash in certain conditions which seem to be reproducibly caused by our setup for some reason. We’re seeing one of two errors. Variant A: Jan 27 13:40:05 up2 dovecot: auth-worker: Error: *** Error in `dovecot/auth': free(): corrupted unsorted chunks: 0x000056553f0fcfa0 *** Jan 27 13:40:05 up2 dovecot: auth-worker: Error: ======= Backtrace: ========= Jan 27 13:40:05 up2 dovecot: auth-worker: Error: /lib/x86_64-linux-gnu/ libc.so.6(+0x70bcb)[0x7f78426adbcb] Jan 27 13:40:05 up2 dovecot: auth-worker: Error: /lib/x86_64-linux-gnu/ libc.so.6(+0x76f96)[0x7f78426b3f96] Jan 27 13:40:05 up2 dovecot: auth-worker: Error: /lib/x86_64-linux-gnu/ libc.so.6(+0x777de)[0x7f78426b47de] Jan 27 13:40:05 up2 dovecot: auth-worker: Error: /usr/lib/dovecot/modules/ auth/libauthdb_ldap.so(+0x5bde)[0x7f7842008bde] Jan 27 13:40:05 up2 dovecot: auth-worker: Error: /usr/lib/dovecot/ libdovecot.so.0(io_loop_call_io+0x52)[0x7f78430cfdd2] Jan 27 13:40:05 up2 dovecot: auth-worker: Error: /usr/lib/dovecot/ libdovecot.so.0(io_loop_handler_run_internal+0x109)[0x7f78430d1409] Jan 27 13:40:05 up2 dovecot: auth-worker: Error: /usr/lib/dovecot/ libdovecot.so.0(io_loop_handler_run+0x3c)[0x7f78430cfe6c] Jan 27 13:40:05 up2 dovecot: auth-worker: Error: /usr/lib/dovecot/ libdovecot.so.0(io_loop_run+0x38)[0x7f78430d0018] Jan 27 13:40:05 up2 dovecot: auth-worker: Error: /usr/lib/dovecot/ libdovecot.so.0(master_service_run+0x13)[0x7f7843057e93] Jan 27 13:40:05 up2 dovecot: auth-worker: Error: dovecot/auth(main+0x398) [0x56553da45f98] Jan 27 13:40:05 up2 dovecot: auth-worker: Error: /lib/x86_64-linux-gnu/ libc.so.6(__libc_start_main+0xf1)[0x7f784265d2b1] Jan 27 13:40:05 up2 dovecot: auth-worker: Error: dovecot/auth(_start+0x2a) [0x56553da461aa] Variant B: Jan 27 13:06:56 up2 dovecot: auth-worker(27495): Panic: file db-ldap.c: line 840 (db_ldap_result_unref): assertion failed: (res->refcount > 0) Jan 27 13:06:56 up2 dovecot: auth-worker(27495): Error: Raw backtrace: /usr/ lib/dovecot/libdovecot.so.0(+0x95272) [0x7f027a4fc272] -> /usr/lib/dovecot/ libdovecot.so.0(+0x9536d) [0x7f027a4fc36d] -> /usr/lib/dovecot/libdovecot.so. 0(i_fatal+0) [0x7f027a492951] -> /usr/lib/dovecot/modules/auth/ libauthdb_ldap.so(+0x3868) [0x7f0279447868] -> /usr/lib/dovecot/modules/auth/ libauthdb_ldap.so(+0x5d7c) [0x7f0279449d7c] -> /usr/lib/dovecot/libdovecot.so. 0(io_loop_call_io+0x52) [0x7f027a510dd2] -> /usr/lib/dovecot/libdovecot.so. 0(io_loop_handler_run_internal+0x109) [0x7f027a512409] -> /usr/lib/dovecot/ libdovecot.so.0(io_loop_handler_run+0x3c) [0x7f027a510e6c] -> /usr/lib/ dovecot/libdovecot.so.0(io_loop_run+0x38) [0x7f027a511018] -> /usr/lib/ dovecot/libdovecot.so.0(master_service_run+0x13) [0x7f027a498e93] -> dovecot/ auth(main+0x398) [0x55b981cd2f98] -> /lib/x86_64-linux-gnu/libc.so. 6(__libc_start_main+0xf1) [0x7f0279a9e2b1] -> dovecot/auth(_start+0x2a) [0x55b981cd31aa] When running auth-worker within valgrind, we get more information (valgrind extract from mail.log attached for two versions of dovecot). We have attached mail.log contents for the respective valgrind runs. This seems to affect at least 2.2.27 onwards. We can reproduce the crash with our production data 100% of the time. The valgrind error is present even with very minimal setups (see below). Unfortunately, I haven’t been able so far to create an LDAP database which produces the crash as reliable as our production database does (which we cannot share for obvious reasons). Minimal Reproducer of Valgrind error: - Install dovecot 2.2.27 from debian stretch, or compile from master. - Install valgrind - In conf.d/10-auth.conf, disable auth-system.conf.ext - In conf.d/10-auth.conf, enable auth-ldap.conf.ext - Set contents of dovecot-ldap.conf.ext to: hosts = localhost base = dc=nodomain - In conf.d/10-master.conf, in section "service auth-worker", set executable = /usr/bin/valgrind /usr/lib/dovecot/auth -w (path may differ on your system) - Install an LDAP server with a database for dc=nodomain; this is trivial to do with debian: Simply install slapd and systemctl start slapd. - Start dovecot - Run doveadm user '*' - You should find the error in the mail.log. I hope this is somehow useful to fix our crash issue. We’ll be happy to provide more information as needed. kind regards, Jonas

4 4

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