October 2019 - dovecot

Re: fts_solr: Error: fts_solr: received invalid uid '0'
by Fabian Kuran 10 Dec '19

10 Dec '19

Hi, > Am 23.09.2019 um 09:36 schrieb Filip Hanes <filip.hanes(a)ringier.sk>: > > > št 19. 9. 2019 o 15:30 Fabian via dovecot <dovecot(a)dovecot.org <mailto:dovecot@dovecot.org>> napísal(a): > Are there any other hints or tips regarding this „invalid uid ‚0‘"-message? > from fts-solr source: > case SOLR_XML_CONTENT_STATE_UID: > if (uint32_parse(str, len, &ctx->uid) < 0 || ctx->uid == 0) { > i_error("fts_solr: received invalid uid '%s'", t_strndup(str, len)); > It means that plugin tries to parse '0' when in state of parsing uid in xml response from solr or there is a bug in xml response parser. > I would enable rawlog_dir in config and look there for unusual response or extra tags near usual uid in xml response. For example: > plugin { > fts = solr > fts_solr = url=... rawlog_dir=/var/log/fts-solr/ > } > Thanks for this tip! The rawlog_dir option is not yet supported in our version 2.3.4. What we could provide now would be the XML-Response from Solr. The corresponding search query sometimes causes this error. But Solr's answer seems to always remain the same - in my opinion this already indicates a bug of Dovecot? The XML response can be downloaded here: https://owncloud.eideo.de/index.php/s/8oyJaf5HBK6zdbr Kind regards, Fabian

4 6

[2.3.8] possible replication issue
by Carsten Rosenberg 06 Dec '19

06 Dec '19

Hi, some of our customers have discovered a replication issue after upgraded from 2.3.7.2 to 2.3.8. Running 2.3.8 several replication connections are hanging until defined timeout. So after some seconds there are $replication_max_conns hanging connections. Other replications are running fast and successful. Also running a doveadm sync tcp:... is working fine for all users. I can't see exactly, but I haven't seen mailboxes timeouting again and again. So I would assume it's not related to the mailbox. >From the logs: server1: Oct 16 08:29:25 server1 dovecot[5715]: dsync-local(username1(a)domain.com)<FXnVDW22pl0tGAAA1cwDxA>: Error: dsync(172.16.0.1): I/O has stalled, no activity for 600 seconds (version not received) Oct 16 08:29:25 server1 dovecot[5715]: dsync-local(username1(a)domain.com)<FXnVDW22pl0tGAAA1cwDxA>: Error: Timeout during state=master_recv_handshake server2: Oct 16 08:29:25 server2 dovecot[8113]: doveadm: Error: read(server1) failed: EOF (last sent=handshake, last recv=handshake) There aren't any additional logs regarding the replication. I have tried increasing vsz_limit or reducing replication_max_conns. Nothing changed. -- Both customers have 10k+ users. Currently I couldn't reproduce this on smaller test systems. Both installation were downgraded to 2.3.7.2 to fix the issue for now -- I've attached a tcpdump showing the client showing the client stops sending any data after the mailbox_guid table headers. Any idea what could be wrong here or the debug this issue? Thanks. Carsten Rosenberg

5 5

Supporting RFC 5466 (IMAP4 Extension for Named Searches (Filters))
by Jesus Cea 06 Dec '19

06 Dec '19

I wonder if Dovecot supports RFC 5466 (IMAP4 Extension for Named Searches (Filters)) or if there is any plan about it. -- Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz

4 6

dovecot sieve duplicates detection
by André Rodier 04 Dec '19

04 Dec '19

Hello, I have tested the sieve duplicate script with success so far, but I have a question. I would like to know if the "duplicate" sieve flag in Dovecot is global to all folders, or specific to one folder only. For instance, if I copy an email from one folder to another, and I have a discard action on duplicate email, is this action will be applied (in this case, discard) or not. If the duplicate is global to all folders, is there a way to restrict the search in one folder only. Thanks for your help. André

3 10

IMAP4 extensions for Visual Voicemail (VVM)
by Rajesh Bansal 15 Nov '19

15 Nov '19

Hi Team, I need to develop Visual VoiceMail solution. In this solution I need a IMAP4 server, from which I can get a hit for each mail retrieval. Can anyone help me if dovecot can be used for this purpose. BR, Rajesh Bansal

5 5

Sieve vacation :addresses match only case-sensitive?
by Philipp Faeustlin 11 Nov '19

11 Nov '19

The recipients in the vacation :addresses String list are matched case-sensitive. If the recipient gets a mail with wrong case, the message is discarded with: "discarding vacation response for implicitly delivered message; no known (envelope) recipient address found in message headers" I think the matching should be case-insensitive. Is this a bug or do I miss some option? I'm using Dovecot 2.3.7.2, Pigeonhole version 0.5.7.2. -- Philipp Fäustlin

5 9

User found but password failure
by Mauricio Tavares 11 Nov '19

11 Nov '19

Trying to figure out which step is causing me not to be able to login. I am using a password file, passdb { driver = passwd-file args = scheme=SHA512-CRYPT username_format=%u /etc/dovecot/passwd } We will assume that the pw I created using 'doveadm pw -s SHA512-CRYPT' matches the password I will be using to login below. I crank the debugging mode, auth_debug_passwords = yes auth_debug = yes And then try to login [root@mail ~]# nc -t localhost 143 * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN AUTH=GSSAPI] Howdy a login raub(a)example.com password [blank] which from what I gathered from /var/log/dovecot means it found matching username but did not match password: secured session=lyJttvyQ9I0AAAAAAAAAAAAAAAAAAAAB lip=::1 rip=::1 lport=143 rport=36340 resp=base64-reply (previous base64 data may contain sensitive data) Aug 26 03:25:52 auth: Debug: passwd-file(raub@example.com,::1,<lyJttvyQ9I0AAAAAAAAAAAAAAAAAAAAB>): lookup: user=raub(a)example.com file=/etc/dovecot/passwd Aug 26 03:25:52 auth: Debug: client passdb out: OK 1 user=raub(a)example.com Aug 26 03:25:52 auth: Debug: master in: REQUEST 1520959489 26560 1 63ee7f45236f85fd39573a5c8a2eb46a session_pid=26563 request_auth_token Aug 26 03:25:52 auth-worker(26562): Debug: passwd(raub@example.com,::1,<lyJttvyQ9I0AAAAAAAAAAAAAAAAAAAAB>): lookup Aug 26 03:25:52 auth-worker(26562): Info: passwd(raub@example.com,::1,<lyJttvyQ9I0AAAAAAAAAAAAAAAAAAAAB>): unknown user Aug 26 03:25:52 auth: Debug: passwd-file(raub@example.com,::1,<lyJttvyQ9I0AAAAAAAAAAAAAAAAAAAAB>): lookup: user=raub(a)example.com file=/etc/dovecot/passwd Aug 26 03:25:52 auth: Error: plain(raub@example.com,::1,<lyJttvyQ9I0AAAAAAAAAAAAAAAAAAAAB>): user not found from any userdbs Aug 26 03:25:52 auth: Debug: master userdb out: NOTFOUND 1520959489 Aug 26 03:25:52 imap: Error: Authenticated user not found from userdb, auth lookup id=1520959489 (auth connected 1 msecs ago, handshake 0 msecs ago, request took 1 msecs, client-pid=26560 client-id=1) Aug 26 03:25:52 imap-login: Info: Internal login failure (pid=26560 id=1) (internal failure, 1 successful auths): user=<raub(a)example.com>, method=PLAIN, rip=::1, lip=::1, mpid=26563, secured, session=<lyJttvyQ9I0AAAAAAAAAAAAAAAAAAAAB> Per [1] I decided to see what the response (base64-reply) I am submitting to dovecot looks like: echo 'base64-reply' | base64 -d raub(a)example.compassword Which has the right username and password but follows the userpassword format, not useruserpassword as I was led to believe by [1]. Is that to be expected? If it is then the issue is further down the line. [1] https://wiki.dovecot.org/Debugging/Authentication

3 5

Reading config-value from file does not work.
by Jakobus Schürz 08 Nov '19

08 Nov '19

Hi guys! In https://doc.dovecot.org/configuration_manual/config_file/config_file_syntax/ i ca see this: Reading value from file It’s possible to read the value for a setting from a file: key = </path/to/file The value is read exactly as the entire contents of the file. This includes all the whitespace and newlines. The paths are relative to the currently parsed config file’s directory, similar to how !include works. The file is read immediately whenever parsing the configuration file, so if it changes afterwards it requires a configuration reload to see the changes. This functionality is especially useful for reading SSL certificates and keys. So i thought it's a good idea, to write the password for dnpass for my ldap in this notation in my config dnpass = <private/dnpass /etc/dovecot/private/dnpass contains only this myVerYSecretLdApPAssworD no space, no newline. But dovecot cannot authenticate on the ldap-host. I also tried dnpass = </private/dnpass dnpass = </etc/dovecot/private/dnpass Then i tried a file /etc/dovecot/conf.d/00-dnpass.conf with dnpass = myVerYSecretLdApPAssworD It should be included with dovecot.conf !include conf.d/*.conf The only notation that works is the line dnpass = myVerYSecretLdApPAssworD in /etc/dovecot/dovecot-ldap-userdb.conf.ext I thought it's a good idea to write it in an extra file, so i have to manipulate only one small file with ansible, when i renew the password. Is it a bug or does it work as designed, and the doc is wrong? thank you Jakob

1 1

Using attachment_dir with plugin zlib corrupt mails
by MAREN ZUBIZARRETA 06 Nov '19

06 Nov '19

Hello: I have found the same problem reported above by Patrick Cernko affecting our system and corrupting our messages. Even worse, Outlook 2016 will no synchronize and the clients cannot see any message, even if there is only one corrupted mail per mailbox. I cannot figure out a feasible workaround for our system, and I can see that in new version 2.38 the bug is not fixed. Will this issue be treated soon? Thanks a lot Maren Zubizarreta WARNING: using attachment_dir with plugin zlib can corrupt mails Patrick Cernko pcernko at mpi-klsb.mpg.de<mailto:dovecot%40dovecot.org?Subject=Re:%20Re%3A%20WARNING%3A%20using%20attachment_dir%20with%20plugin%20zlib%20can%20corrupt%20mails&In-Reply-To=%3C1ab8edcc-bef4-3b41-d09a-c523674a5031%40mpi-klsb.mpg.de%3E> Fri Jul 19 17:52:37 EEST 2019 * Previous message: index worker 2.3.7 undefined symbol errors<https://dovecot.org/list/dovecot/2019-July/116617.html> * Next message: Address family not supported by protocol<https://dovecot.org/list/dovecot/2019-July/116571.html> * Messages sorted by: [ date ]<https://dovecot.org/list/dovecot/2019-July/date.html#116570> [ thread ]<https://dovecot.org/list/dovecot/2019-July/thread.html#116570> [ subject ]<https://dovecot.org/list/dovecot/2019-July/subject.html#116570> [ author ]<https://dovecot.org/list/dovecot/2019-July/author.html#116570> ________________________________ Hello list, hello Dovecot developers, this week, I discovered a serious bug in Dovecot, that lead to several broken mails on our servers. The bug corrupts the first few characters of the mail header during saving. On our setup, it was almost always only the very first line of text, that was corrupted. Depending on the IMAP client (they seem to request different header fields, ... during mail access), the bug causes the imap process to hang up the TCP connection and log errors like this: > imap(USERNAME)<4767><TeQP4ASOTK5/AAAB>: Error: Corrupted record in index cache file /IMAP/mail/mailboxes/USERNAME/mdbox/mailboxes/Trash/dbox-Mails/dovecot.index.cache: UID 489113: Broken fields in mailbox Trash: read(attachments-connector(zlib(/IMAP/mail/mailboxes/USERNAME/mdbox/storage/m.813))): FETCH BODY[HEADER.FIELDS (RETURN-PATH SUBJECT)] got too little data: 2 vs 122 In our case that finally grabbed my attention, the client was the users iphone that did not display any new messages but his Thunderbird did. The bug seems to be triggered by a bad "interaction" of attachment_dir option and zlib plugin. If you use both, you most likely are affected, too, except you only use zlib plugin for reading previously compressed stored mails. That's also the workaround we use now: zlib plugin only enabled in mail_plugins but no plugin/zlib_save set. The bug occurs on very specific mails. Due to privacy reasons I could not provide sample mails here. Storing such mails seems to trigger the bug reproducible. I attached a very minimal doveconf -n config, that can be used to trigger the bug. If one of the developers is interested, I can try to generate an "anonymized" version of such a specific mail that still causes the issue. I discovered the bug on our productive systems, running latest Dovecot 2.2 release, but the latest 2.3 I used during debugging is affected, too. During debugging, I also found one hint, that might help find the bug: If you store a problematic mail with zlib_save=gz (or zlib_save=bz2) and then disable the zlib plugin in mail_plugins, you can call doveadm fetch -u test hdr all | grep -v ^hdr: | gzip --decompress on test's mailbox with only that one broken mail. This will display the beginning of the rfc822 mail text until gzip terminates with "gzip: stdin: unexpected end of file", approximately after twice the length of the mail HEADER. This might indicate, that dovecot stores the uncompressed size of the header in it's data structures although the mail is stored compressed. I also found a very efficient way to find all affected mails in our setup: doveadm -f flow fetch -A 'user guid mailbox uid seq flags hdr' all | \ grep -a "^[^ ]+ user=" | \ grep -avF ' hdr=Return-path: ' | \ grep -av '.* hdr=[[:print:][:space:]]*$' (runtime for ~6M mails on our servers was 20-30min) This can be even more optimized if you have a powerful storage system with GNU parallel: > doveadm user '*' | parallel "doveadm -f flow fetch -u '{}' 'user guid mailbox uid seq flags hdr' all | grep -a '^user=' | grep -avF ' hdr=Return-path: ' | grep -av '.* hdr=[[:print:][:space:]]*$' || true" (runtime for ~6M mails on our servers was ~4min) The command will give you a list of mails that possibly are affected, check the full output of doveadm fetch -u USERNAME hdr guid GUID | less to verify that the header is really broken. On our systems I found 39 mails within ~12M mails. I was able to recover these mails "manually" by reconstructing the Return-Path header line, importing the fixed mails and expunging the corrupt ones. Before importing, I had to disable zlib_save option obviously. Best regards, -- Patrick Cernko <pcernko at mpi-klsb.mpg.de<https://dovecot.org/mailman/listinfo/dovecot>> +49 681 9325 5815 Joint Administration: Information Services and Technology Max-Planck-Institute fuer Informatik & Softwaresysteme

6 11

warning: NFS hangs with dovecot 2.3.8 on Debian buster
by Jan-Pieter Cornet 01 Nov '19

01 Nov '19

A warning to those considering to upgrade to Debian 10 (buster): we have seen occasional NFS hangs with dovecot when using the stock debian buster kernel (4.19.67-2+deb10u1). When we downgrade to the debian stretch kernel (4.9.189-3+deb9u1), the issue does not occur. Note that we *only* downgraded the kernel, the rest of the OS is still debian buster. Dovecot 2.3.8. A little more info: we have a dovecot cluster, using mdbox for storage, on an NFS server (netapp Cmode version 9.6P2). We use a dovecot director layer, so a user is always connected to the same back-end dovecot server. The NFS hang occurs on the back-end server. Once the process hangs, other processes trying to write to the same mailbox, will get an error like this: Timeout (180s) while waiting for lock for transaction log file /var/mail/.../index/storage/dovecot.map.index.log (WRITE lock held by pid XXXX) The stuck process itself doesn't seem to do anything, is stuck in "D" disk state, "strace" doesn't show anything (and after attaching, strace itself needs a kill -KILL to stop). The only way to unwedge the process seems to be to do a kill -KILL of the stuck process. Reading from the mailbox is still possible. We are in the process of contacting the linux-nfs folks about this, but I'm trying to reproduce this on a test-cluster first, to be able to present a well-documented case. Since this hang doesn't happen immediately, but takes a few hours to a day to occur in the wild, or a few thousand writes to the same mailbox, it's a bit hard to debug. -- Jan-Pieter Cornet <johnpc(a)xs4all.net> Systeembeheer XS4ALL Internet bv www.xs4all.nl

1 1