September 2017 - dovecot

Embeding a path in address extensions
by ＠lbutlr 09 Sep '17

09 Sep '17

I generate bcc backups with the pattern backups+DATE.user.domain.tld(a)myBackupDomain.tld (for example, backups+20170908.kremels.kreme.com(a)myBackupDomain.tld) This puts mail in …/.20170908.kremels.kreme.com/new What I would like to do is get the expansion to generate the following path …/.20170908/.kremels.kreme.com/new Of course the date changes everyday, but it will always be numeric if that helps. dovecot get the mail from postfix: dovecot unix - n n - - pipe flags=DRhu user=vpopmail:vchkpw argv=/usr/local/libexec/dovecot/dovecot-lda -f ${sender} -d ${user}@${nexthop} -m ${extension} -a ${original_recipient} Would it make more sense (or is it even possible) to split the extension in postfix or to do something with sieve? Or is there a character I can use in the extension that tells dovecot to create a path? Even though I am using a maildir structure for the backups, this "account" never accesses the mail via a MUA, only via the command line when an admin has to restore an email, so it would be much easier to deal with this with daily subfolders. Or, maybe I make the admins use an MUA? If so, I should replace most of these .'s with dashes… -- Apple broke AppleScripting signatures in Mail.app, so no random signatures.

1 1

can't get quota working. I use static userdb driver.
by Вадим Бажов 08 Sep '17

08 Sep '17

Hi, people ! Set up global quota according to docs to 2 Mb. Send more than ten Mb on the box. Mail still getting put in the box, no bounces, no error messages in logs, nothing to prevent mail to be delivered in overflooded mailbox. quota settings are: mail_plugins = quota lmtp_rcpt_check_quota = yes quota_full_tempfail = yes protocol lmtp { postmaster_address = postmaster # required mail_plugins = $mail_plugins sieve } protocol lda { mail_plugins = $mail_plugins sieve } protocol imap { mail_plugins = $mail_plugins imap_quota } plugin { quota = maildir:"User quota" quota_rule = *:storage=10M quota_rule3 = INBOX.Trash:storage=+10%% quota_exceeded_message = "552 5.2.2 Mailbox is full" } doveconf -n is attached. # doveadm quota get Quota name Type Value Limit % "User quota" STORAGE 0 10240 0 "User quota" MESSAGE 0 - # doveadm quota get -u vadim Quota name Type Value Limit % "User quota" STORAGE 0 10240 0 "User quota" MESSAGE 0 - # du -sh /var/mail/vadim/ 23M /var/mail/vadim/ I tried to pass quota_rule as an argument to userdb, quota is being parsed, but still doesn't work. I think problem is that dovecot can't (re)calculate the actual quota on disc (cant calculate how disk space mailbox is used), despite the fact that quota limit itself is configured correctly, since dovecot shows it in log and doveconf -n. What I am dong wrong ?

4 8

EOF from net_disconnect(fd)
by Steffan Cline 08 Sep '17

08 Sep '17

I’m working on an OS project from github. There are two parts: Dovecot plugin - https://github.com/st3fan/dovecot-xaps-plugin Daemon written in Go - https://github.com/st3fan/dovecot-xaps-daemon # dovecot --version 2.2.10 Both parts worked fine on CentOS 6 but I recently rebuilt them both for CentOS 7 and have run into some errors. The plugin sends a notification over a socket to the daemon. The daemon then processes the request and returns a message to the plugin. The plugin reads the response then closes the socket and at that point, I’m running into an issue. The daemon reports the following: read unix /tmp/xapsd.sock->@: read: connection reset by peer In reading the Go language docs, it says that it will throw the first error it hits before the EOF from the socket. This led me to think that perhaps the plugin was not sending an EOF when closing the socket. I tried to write an EOF to the socket before the close but no change. Everything works between the plugin and daemon right up until the socket close. Is there a way to monitor the stream through the socket so I can see if the plugin is indeed sending the EOF? Knowing that lets me know if I need to chase down the issue in the Go daemon code. I’m no pro with C but I tried. The snippet from the plugin follows: alarm(1); { if (net_transmit(fd, str_data(req), str_len(req)) < 0) { i_error("write(%s) failed: %m", socket_path); ret = -1; } else { char res[1024]; ret = net_receive(fd, res, sizeof(res)-1); if (ret < 0) { i_error("read(%s) failed: %m", socket_path); } else { res[ret] = '\0'; if (strncmp(res, "OK ", 3) == 0) { ret = 0; } } } } alarm(0); char stx[1]; stx[0]=(char) 4; //stx[1]='\0'; if ( net_transmit(fd, stx, sizeof(stx) ) < 0 ) { i_error("Error writing EOF"); } //string_t *testEOF= t_str_new(2); //str_append(testEOF, (char*) 4); //if ( net_transmit(fd, str_data(testEOF), str_len(testEOF) ) < 0 ) { // i_error("Error writing EOF"); // } //i_close_fd(&fd); net_disconnect(fd); fd=-1; Thank you, Steffan Cline 602-793-0014

3 6

Automatic DB password hash scheme selection
by Kurt Fitzner 08 Sep '17

08 Sep '17

Hi all, Is there a way to get dovecot to recognize arbitrary password hash schemes when looking up a password in a database? I originally set up with #default_pass_scheme = MD5, and I would like to migrate to SHA512. Seeing as the scheme is actually stored in the password column along with the password in the format $_<scheme#>_$_<salt>_$_<passwordhash>_, it seems to me that dovecot should be able to look at the scheme number and simply do the right thing. If this is possible, then migrating passwords over would be much easier, since people will still be able to log in with their old MD5-hashed password and the changer can be set up to hash with the new method. Is this possible currently? Thanks, Kurt

2 2

Hide public mailboxes from some users
by Arie Peterson 08 Sep '17

08 Sep '17

Hi all, I'm trying to set up public mailboxes for a subset of my users. This is on dovecot 2.2.27. I've created a new public namespace, and the new mailboxes indeed show up for everyone. So far so good. Now I want to restrict access: these mailboxes shouldn't be visible at all except to a fixed list of users. This part I can't seem to get working. I've added acl data along these lines: ``` pubbox anyone pubbox/* anyone pubbox user=me(a)example.com lrwstipekxa pubbox/* user=me(a)example.com lrwstipekxa ``` However, other users can still see "pubbox" and its subfolders, although they can't actually view the contents. This is corroborated by some of the output of `doveadm mailbox list`: ``` # doveadm -D mailbox list -u other(a)example.com … doveadm(other(a)example.com): Debug: Namespace : type=public, prefix=pubbox/, sep=/, inbox=no, hidden=no, list=children, subscriptions=no … doveadm(other(a)example.com): Debug: Mailbox 'pubbox/Drafts' matches global ACL pattern 'pubbox/*' doveadm(other(a)example.com): Debug: Mailbox 'pubbox/Drafts' matches global ACL pattern 'pubbox/*' doveadm(other(a)example.com): Debug: acl vfile: reading file /mnt/data/mail/example.com/public/pubbox/mail/Drafts/dovecot-acl doveadm(other(a)example.com): Debug: acl: No lookup right to mailbox: pubbox/Drafts doveadm(other(a)example.com): Debug: Mailbox 'pubbox/Sent' matches global ACL pattern 'pubbox/*' doveadm(other(a)example.com): Debug: Mailbox 'pubbox/Sent' matches global ACL pattern 'pubbox/*' doveadm(other(a)example.com): Debug: acl vfile: reading file /mnt/data/mail/example.com/public/pubbox/mail/Sent/dovecot-acl doveadm(other(a)example.com): Debug: acl: No lookup right to mailbox: pubbox/Sent doveadm(other(a)example.com): Debug: Mailbox 'pubbox' matches global ACL pattern 'pubbox' doveadm(other(a)example.com): Debug: Mailbox 'pubbox' matches global ACL pattern 'pubbox' doveadm(other(a)example.com): Debug: acl vfile: reading file /mnt/data/mail/example.com/public/pubbox/mail/dovecot-acl pubbox pubbox/Drafts pubbox/Sent INBOX ``` Why do these "pubbox/*" mailboxes show up in the `mailbox list` output, even though the debug messages say that the user has no lookup right for them? `doveadm acl rights` seems to confirm that `other(a)example.com` does not have the lookup right for these mailboxes. So why do they show up in their email clients anyway? Thanks for any advice!

1 2

password reset
by ＠lbutlr 08 Sep '17

08 Sep '17

This is off topic, but I am not sure where to go. I have a local user who cannot login because of a forgotten password, so I went to reset her password with sudo passed <user> Which appears to work, asking for a new password and a confirmation. No error occurs (unless I give it unmatched passwords), but the password is not changed. if I try to change the password in the user's account (after su <user>) t requires the old password. running on FreeBSD 11.0 When I try to change the password with sudo, the timestamp on /etc/passwd gets updated but there is nothing logged to anything in /var/log/

4 6

pop3-login core dump when using TLSSTART on version dovecot-2.2.32 (OPEN)
by Arvid.Eikas＠telenor.com 08 Sep '17

08 Sep '17

Hi, Pop3-login are CORE-dumping when I log on with TLSSTART, I believe the same will happen with imap-logon to, but I have not tested it yet. The TLS session is coming up and it works fine until I log off, then it's core dump. Open sslvesrion is openssl-1.0.2k. We ran dovecot-2.2.27 before we upgraded to dovecote-2.2.32, and that seems to work fine. (not core dumping) Arvid LOG Sep 05 14:27:34 pop3-login: Debug: SSL: elliptic curve secp384r1 will be used for ECDH and ECDHE key exchanges Sep 05 14:30:30 pop3-login: Debug: SSL: elliptic curve secp384r1 will be used for ECDH and ECDHE key exchanges Sep 05 14:30:30 pop3-login: Debug: SSL: elliptic curve secp384r1 will be used for ECDH and ECDHE key exchanges Sep 05 14:30:42 pop3-login: Debug: SSL: elliptic curve secp384r1 will be used for ECDH and ECDHE key exchanges Sep 05 14:30:42 pop3-login: Debug: SSL: elliptic curve secp384r1 will be used for ECDH and ECDHE key exchanges Sep 05 14:30:50 pop3-login: Info: Login: user=<tstrand>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=18361, secured, session=<65m8ZXBYtpN/AAAB> Sep 05 14:30:50 pop3-login: Error: ENGINE_finish, bad functional reference count Sep 05 14:30:50 pop3-login: Fatal: master: service(pop3-login): child 18359 killed with signal 6 (core dumped) >From ./crypto/engine/eng_init.c ......... int engine_unlocked_finish(ENGINE *e, int unlock_for_handlers) { int to_return = 1; /* * Reduce the functional reference count here so if it's the terminating * case, we can release the lock safely and call the finish() handler * without risk of a race. We get a race if we leave the count until * after and something else is calling "finish" at the same time - * there's a chance that both threads will together take the count from 2 * to 0 without either calling finish(). */ e->funct_ref--; engine_ref_debug(e, 1, -1); if ((e->funct_ref == 0) && e->finish) { if (unlock_for_handlers) CRYPTO_w_unlock(CRYPTO_LOCK_ENGINE); to_return = e->finish(e); if (unlock_for_handlers) CRYPTO_w_lock(CRYPTO_LOCK_ENGINE); if (!to_return) return 0; } #ifdef REF_CHECK if (e->funct_ref < 0) { fprintf(stderr, "ENGINE_finish, bad functional reference count\n"); abort(); ......... /* The API (locked) version of "finish" */ int ENGINE_finish(ENGINE *e) { int to_return = 1; if (e == NULL) { ENGINEerr(ENGINE_F_ENGINE_FINISH, ERR_R_PASSED_NULL_PARAMETER); return 0; } CRYPTO_w_lock(CRYPTO_LOCK_ENGINE); to_return = engine_unlocked_finish(e, 1); CRYPTO_w_unlock(CRYPTO_LOCK_ENGINE); if (!to_return) { ENGINEerr(ENGINE_F_ENGINE_FINISH, ENGINE_R_FINISH_FAILED); return 0; } return to_return; }

2 1

Strange SASL issue
by Antoine Nguyen 07 Sep '17

07 Sep '17

Hi all, I've just upgraded my server from debian 8 to debian 9 and I now encounter a strange issue. I'm using prosody (XMPP server), configured to authenticate against dovecot using SASL and a unix socket. This setup was working fine on debian 8. Now, each time I try to connect using my XMPP client, the authentication fails and I see the following error in logs: auth: Error: BUG: Authentication client said it's PID 0 Have you ever heard about this? For information, dovecot version is 2.2.27. Thank you, Antoine Nguyen

4 6

imapc bug (signal 6)
by Ralf Hildebrandt 07 Sep '17

07 Sep '17

Running 2.3.0~alpha0-1~auto+1045, basically as a proxy between MUA and Exchange (IMAP): Sep 7 16:10:32 mproxy dovecot: imap-login: Login: user=<holtgrem>, method=PLAIN, rip=172.16.128.8, lip=141.42.206.11, mpid=61031, TLS, session=<fp3JBZpYop+sEIAI> Sep 7 16:10:32 mproxy dovecot: imap(holtgrem)<fp3JBZpYop+sEIAI>: imapc(exchange-imap.charite.de:993): Connected to 10.32.37.100:993 (local 141.42.206.11:58124) Sep 7 16:10:32 mproxy dovecot: imap(holtgrem)<fp3JBZpYop+sEIAI>: Panic: file mail-index-sync-update.c: line 1056 (mail_index_sync_map): assertion failed: (map->hdr.indexid == index->indexid || map->hdr.indexid == 0) Sep 7 16:10:32 mproxy dovecot: imap(holtgrem)<fp3JBZpYop+sEIAI>: Error: Raw backtrace: /usr/lib/dovecot/libdovecot.so.0(+0xa1c2e) [0x7f059bd4cc2e] -> /usr/lib/dovecot/libdovecot.so.0(+0xa1d1c) [0x7f059bd4cd1c] -> /usr/lib/dovecot/libdovecot.so.0(i_fatal+0) [0x7f059bcdbbce] -> /usr/lib/dovecot/libdovecot-storage.so.0(mail_index_sync_map+0x6a0) [0x7f059c0c91c0] -> /usr/lib/dovecot/libdovecot-storage.so.0(mail_index_map+0xf8) [0x7f059c0c01c8] -> /usr/lib/dovecot/libdovecot-storage.so.0(mail_index_refresh+0xe) [0x7f059c0d66de] -> /usr/lib/dovecot/libdovecot-storage.so.0(mailbox_list_index_refresh_force+0x8c) [0x7f059c094e7c] -> /usr/lib/dovecot/libdovecot-storage.so.0(+0xab786) [0x7f059c091786] -> /usr/lib/dovecot/libdovecot-storage.so.0(+0xabadc) [0x7f059c091adc] -> /usr/lib/dovecot/libdovecot-storage.so.0(mailbox_sync_deinit+0x35) [0x7f059c02f925] -> /usr/lib/dovecot/libdovecot-storage.so.0(mailbox_sync+0x4b) [0x7f059c0315bb] -> dovecot/imap [holtgrem 172.16.128.8 EXAMINE](cmd_select_full+0x170) [0x55fac9ae2b60] -> dovecot/imap [holtgrem 172.16.128.8 EXAMINE](command_exec+0x5c) [0x55fac9aea39c] -> dovecot/imap [holtgrem 172.16.128.8 EXAMINE](+0x1b822) [0x55fac9ae8822] -> dovecot/imap [holtgrem 172.16.128.8 EXAMINE](+0x1b8ac) [0x55fac9ae88ac] -> dovecot/imap [holtgrem 172.16.128.8 EXAMINE](client_handle_input+0x1e5) [0x55fac9ae8d05] -> dovecot/imap [holtgrem 172.16.128.8 EXAMINE](client_input+0x85) [0x55fac9ae9265] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x69) [0x7f059bd63469] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x10a) [0x7f059bd64c9a] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x52) [0x7f059bd63572] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x38) [0x7f059bd63788] -> /usr/lib/dovecot/libdovecot.so.0(master_service_run+0x13) [0x7f059bce6fe3] -> dovecot/imap [holtgrem 172.16.128.8 EXAMINE](main+0x343) [0x55fac9adb143] -> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f059b901830] -> dovecot/imap [holtgrem 172.16.128.8 EXAMINE](+0xe323) [0x55fac9adb323] Sep 7 16:10:32 mproxy dovecot: imap(holtgrem)<fp3JBZpYop+sEIAI>: Fatal: master: service(imap): child 61031 killed with signal 6 (core dumped) Sep 7 16:10:33 mproxy dovecot: imap-login: Login: user=<holtgrem>, method=PLAIN, rip=172.16.128.8, lip=141.42.206.11, mpid=61034, TLS, session=<X48IBppYpJ+sEIAI> Sep 7 16:10:33 mproxy dovecot: imap(holtgrem)<X48IBppYpJ+sEIAI>: imapc(exchange-imap.charite.de:993): Connected to 10.32.37.100:993 (local 141.42.206.11:58128) Sep 7 16:10:33 mproxy dovecot: imap-login: Login: user=<holtgrem>, method=PLAIN, rip=172.16.128.8, lip=141.42.206.11, mpid=61036, TLS, session=<0CQPBppYpp+sEIAI> Sep 7 16:10:33 mproxy dovecot: imap(holtgrem)<0CQPBppYpp+sEIAI>: imapc(exchange-imap.charite.de:993): Connected to 10.32.37.100:993 (local 141.42.206.11:58132) Sep 7 16:12:30 mproxy dovecot: imap(holtgrem)<0CQPBppYpp+sEIAI>: Connection closed (EXAMINE finished 28.690 secs ago) in=643 out=101173 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0 Sep 7 16:12:30 mproxy dovecot: imap(holtgrem)<X48IBppYpJ+sEIAI>: Connection closed (FETCH running for 116.592 + waiting input for 0.001 secs, 0.001 in locks, 28 B in + 64787+2070 B out, state=wait-input) in=105 out=66175 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0 Sep 7 16:12:35 mproxy dovecot: imap-login: Login: user=<holtgrem>, method=PLAIN, rip=172.16.128.8, lip=141.42.206.11, mpid=61049, TLS, session=<2ZkfDZpYKKCsEIAI> Sep 7 16:12:35 mproxy dovecot: imap(holtgrem)<2ZkfDZpYKKCsEIAI>: imapc(exchange-imap.charite.de:993): Connected to 10.32.37.100:993 (local 141.42.206.11:58160) Sep 7 16:12:36 mproxy dovecot: imap-login: Login: user=<holtgrem>, method=PLAIN, rip=172.16.128.8, lip=141.42.206.11, mpid=61051, TLS, session=<eg9cDZpYLqCsEIAI> Sep 7 16:12:36 mproxy dovecot: imap(holtgrem)<eg9cDZpYLqCsEIAI>: imapc(exchange-imap.charite.de:993): Connected to 10.32.37.100:993 (local 141.42.206.11:58164) Sep 7 16:12:41 mproxy dovecot: imap(holtgrem)<2ZkfDZpYKKCsEIAI>: Error: imapc: Remote server didn't send BODY[] for UID 1 in Calendar/BIH BCU (FETCH replied: FETCH completed.) Sep 7 16:14:19 mproxy dovecot: imap(holtgrem)<2ZkfDZpYKKCsEIAI>: Error: imapc(exchange-imap.charite.de:993): Command '1321 APPEND "INBOX" (\Seen) "29-Aug-2017 11:36:49 +0200" {42176625}' failed with BAD: 1321 Command Argument Error. 11 Sep 7 16:14:19 mproxy dovecot: imap(holtgrem)<2ZkfDZpYKKCsEIAI>: Error: imapc: APPEND failed: Command Argument Error. 11 Sep 7 16:14:19 mproxy dovecot: imap(holtgrem)<2ZkfDZpYKKCsEIAI>: IMAP session state is inconsistent, please relogin. in=42180017 out=220890 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=1 body_bytes=788 Sep 7 16:14:19 mproxy dovecot: imap-login: Login: user=<holtgrem>, method=PLAIN, rip=172.16.128.8, lip=141.42.206.11, mpid=61072, TLS, session=<Aa2IE5pYkKCsEIAI> Sep 7 16:14:19 mproxy dovecot: imap(holtgrem)<Aa2IE5pYkKCsEIAI>: imapc(exchange-imap.charite.de:993): Connected to 10.32.37.100:993 (local 141.42.206.11:58198) Sep 7 16:14:27 mproxy dovecot: imap(holtgrem)<Aa2IE5pYkKCsEIAI>: Connection closed (EXAMINE finished 8.029 secs ago) in=63 out=1372 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0 Sep 7 16:14:29 mproxy dovecot: imap(holtgrem)<eg9cDZpYLqCsEIAI>: Connection closed (FETCH running for 112.511 + waiting input for 0.001 secs, 0.001 in locks, 28 B in + 127311+2054 B out, state=wait-input) in=105 out=128699 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0 -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebrandt(a)charite.de | https://www.charite.de

1 0

master: Warning: Sent SIGKILL to 511 pop3-login processes
by Luciano Mannucci 07 Sep '17

07 Sep '17

I have a lot of "master: Warning: Sent SIGKILL to 511 pop3-login processes" in my log file. Should I worry? (I'm running # 2.2.32 (dfbe293d4)) Thanks to all, Luciano. -- /"\ /Via A. Salaino, 7 - 20144 Milano (Italy) \ / ASCII RIBBON CAMPAIGN / PHONE : +39 2 485781 FAX: +39 2 48578250 X AGAINST HTML MAIL / E-MAIL: posthamster(a)sublink.sublink.ORG / \ AND POSTINGS / WWW: http://www.lesassaie.IT/

1 0