- dovecot - dovecot.org

dovecot indexer-workers
by Nikolay Zlatkov 26 May '23

26 May '23

Hi, I have a problem with dovecot indexer-workers starting at the same time everyday and using too much disk io and cpu. I have limited indexer-workers to 2, but i am not sure this is the solution. Can you help me to configure this automatic reindex to be in the night for example. Best Regards! -- Николай Златков / Nikolay Zlatkov Системен администратор / System Administrator CALLFLOW mobilePhone +359 87 986 85 32 <tel:+359 87 986 85 32> emailAddress nzlatkov(a)callflowlab.com <mailto:nzlatkov@callflowlab.com> website www.callflowlab.com <//www.callflowlab.com> address Magnaurska shkola 11 Str., Office 310, Sofia 1784 All channels. One place. | OMNILINX | Check out our new product. <https://omnilinx.com/?utm_source=email&utm_medium=signature>

1 0

The (doveadm search HEADER "Header" "") command does not return email which have the header "Header"
by Léo El Amri 26 May '23

26 May '23

Hello there, When using the doveadm command (search HEADER "X-Discourse-Post-Id" "") or the IMAP command (SEARCH HEADER X-Discourse-Post-Id ""), emails containing a X-Discourse-Post-Id header are not listed. I've also tried with non X- headers, such as List-Unsubscribe and Auto-Submitted. RFC 3501 [1] and Dovecot's documentation [2] both says that this command should return emails containing the header searched. I couldn't find a mention of this bug in the git history, hence why I'm posting here, maybe there is something wrong with my installation ? I'm running Dovecot 2.3.20 on Debian on amd64 with an ext4 filesystem. I attached the output of dovecot -n. [1]: https://www.rfc-editor.org/rfc/rfc3501.html#section-6.4.4 [2]: https://wiki.dovecot.org/Tools/Doveadm/SearchQuery -- Cordially, Léo

1 1

dovecot replication crashing
by Heiko Schlittermann 25 May '23

25 May '23

Hi, I'm a but clueless, having issues with replication. `doveadm dsync -u hans` works. But using the following replication setup, I see coredumps. Where to go next? Interestingly not for all users. (For testing purposes I've only 2 users. One having about 20 messages: here even the replication works, but the 2nd user (having about 14k messages) fails. The failure seems to happen immediatly after starting the replication attempt). I saw the replication crashing using Dovecot packages from the current Debian distro. In order to debug this, I'm now using 2.3.20, built from Git. The replicator config boils down to this (complete config is attached) replication_full_sync_interval = 90d replication_max_conns = 16 mail_plugins = $mail_plugins notify replication plugin { mail_replica = tcps:smtp-mz.example.com:9090 } service replicator { process_min_avail = 1 unix_listener replicator-doveadm { mode = 0666 } } service aggregator { fifo_listener replication-notify-fifo { user = dovecot mode = 0666 } unix_listener replication-notify { user = dovecot mode = 0666 } } The stacktrace I get looks like this: Stack trace of thread 729589: #0 0x00007f9e4f2c8ce1 __GI_raise (libc.so.6 + 0x38ce1) #1 0x00007f9e4f2b2537 __GI_abort (libc.so.6 + 0x22537) #2 0x00007f9e4f5fe8c6 default_fatal_finish (libdovecot.so.0 + 0x558c6) #3 0x00007f9e4f6ab601 i_internal_fatal_handler (libdovecot.so.0 + 0x102601) #4 0x00007f9e4f5fe589 i_panic (libdovecot.so.0 + 0x55589) #5 0x00007f9e4f5fe99e fd_set_nonblock (libdovecot.so.0 + 0x5599e) #6 0x00005564cbe6a08d cmd_dsync_ibc_stream_init (doveadm-server + 0x3008d) #7 0x00005564cbe6b772 cmd_dsync_run (doveadm-server + 0x31772) #8 0x00005564cbe6d284 doveadm_mail_next_user (doveadm-server + 0x33284) #9 0x00005564cbe6e4ba doveadm_mail_cmd_exec (doveadm-server + 0x344ba) #10 0x00005564cbe7eb71 doveadm_cmd_run_ver2 (doveadm-server + 0x44b71) #11 0x00005564cbe8300a doveadm_cmd_server_run_ver2 (doveadm-server + 0x4900a) #12 0x00007f9e4f6c1799 io_loop_call_io (libdovecot.so.0 + 0x118799) #13 0x00007f9e4f6c2e82 io_loop_handler_run_internal (libdovecot.so.0 + 0x119e82) #14 0x00007f9e4f6c1840 io_loop_handler_run (libdovecot.so.0 + 0x118840) #15 0x00007f9e4f6c1a00 io_loop_run (libdovecot.so.0 + 0x118a00) #16 0x00007f9e4f6343a3 master_service_run (libdovecot.so.0 + 0x8b3a3) #17 0x00005564cbe5d9a2 main (doveadm-server + 0x239a2) #18 0x00007f9e4f2b3d0a __libc_start_main (libc.so.6 + 0x23d0a) #19 0x00005564cbe5da2a _start (doveadm-server + 0x23a2a) 2023 Mar 28 00:09:28 clone doveadm(hans)<729589><TdSzNhcUImT1IQsAKQCViw>: Fatal: master: service(doveadm): child 729589 killed with signal 6 (core dumped) I'm a bit clueless now, even using the coredump and gdb. -- Heiko

3 7

subscriptions via master user
by Przemysław Kwiatkowski 25 May '23

25 May '23

Hello, When I impersonate an regular user using master user (log in to Roundcube as "user*masteruser") - there are user's subscriptions missing. I can see all folders, but have to manually enable visibility in settings. Is this normal? Can I fix it? passdb { driver = passwd-file master = yes args = /filepath pass = yes } passdb { driver = passwd-file args = /filepath } userdb { driver = passwd-file args = /filepath default_fields = uid=vmail gid=vmail system_groups_user=vmail home=/srv/vmail/%d/%n master_user=%u } -- Przemyslaw Kwiatkowski

1 0

fts crash
by Przemysław Kwiatkowski 21 May '23

21 May '23

Hello, I started full reindex of whole emails base (doveadm index -A '*') and solr crashed due to out of memory. I had plenty of such messages: doveadm(gzt): Error: fts_solr: Indexing failed: Connection lost: read((conn:127.0.0.1:8983,id=621)) failed: EOF (Request queued 40.832 secs ago, 1 send attempts in 39.359 secs, 0.002 in http ioloop, 0.000 in other ioloops, connected 704.138 secs ago) doveadm(gzt): Error: Mailbox Sent: Precache for UID=4036 failed: Internal error occurred. Refer to server log for more information. [2023-05-20 06:01:40] doveadm(gzt): Error: Mailbox Sent: Transaction commit failed: FTS transaction commit failed: backend deinit I increased solr memory and restarted it. Do I have to restart dovedam index? The "request queued" message suggest that Dovecot is smart and I don't need to do anything. Am I right? (Any way to confirm that indeed everything was indexed?) -- Przemyslaw Kwiatkowski

2 1

Re: LMTP server client certificate validation
by Jochen Bern 19 May '23

19 May '23

On 16.05.23 14:27, Sean Gallagher wrote: > I have a created a CA for the sole purpose of signing the certificate of > the LMTPS client. I regard this as a horrible horrible kludge. ... how do you figure that? *Someone*, and that means you, has to specify which clients are allowed to connect. Which leaves three possibilities: a) You run the CA and thus, the CA can do the selection for you. Which means that in order to deal with a single-permissible-client situation, you need the CA to issue client certs to just that one entity. b) The CA does *not* and issues (client) certs to entities you do *not* want to grant access. Then the selection job remains yours and, assuming that requiring a client cert from that CA makes any sense in the first place, auth_ssl_username_from_cert is there to help you (by making sure that the username will be "the ID" from the cert so that you can base some additional filtering on that). c) The CA is willing to enrich the certs it issues with DN parts, X509v3 extensions or the like signalling access rights as granted beforehand by a *fourth* party, as in, you. Which is a terrible can of worms as soon as things, especially the number of such fourth parties to support by the same CA, start to scale up IMHO. Which promptly brings us back to you running the CA yourself ... Kind regards, -- Jochen Bern Systemingenieur Binect GmbH

3 5

Possible hack via doveadm
by Daniel L. Miller 18 May '23

18 May '23

I currently have two servers running with synchronization that I've been very happy with. However, I'm seeing the following in my logs recently: May 12 15:45:58 cloud1 dovecot: doveadm(194.165.16.78): Error: doveadm client not compatible with this server (mixed old and new binaries?) May 13 03:44:31 cloud1 dovecot: doveadm(45.227.254.48): Error: doveadm client not compatible with this server (mixed old and new binaries?) Since I don't recognize those IPs, the first is out of Panama and the other is Belize, I assume these are hostile attackers trying to exploit something. How can I defend against this? -- Daniel

5 6

pigeonhole: sieve: float score failed for comparator-i ascii-numeric
by Randy Li 18 May '23

18 May '23

Hello Following the sieve_spamtest_status_header from the document, I think I could extract the score from the spamassassin (which is from spampd lmtp). But sieve script can't never work properly with comparator "i;ascii-numeric". I have used sieve-test several times, once I remove the dot from the mail sample, the sieve script works well. I noticed that document says i;ascii-numeric is for unsigned integer only which certainly does work for this case. The score here would be signed float(all right all the float is signed) and it is a float variable from tst-spamvirustest.c. I think that is the place the bug happened. Unfortunately, I didn't found any RFC that supports a float comparator and I am not familiar with the sieve interrupter. If someone could give me a possible method to fix this, I could submit a patch. Sincerely Randy Li

2 2

Re: Incorrect saved dates in mailboxes
by Joseph Tam 18 May '23

18 May '23

> OK, that does make sense so far. Today I have checked, and the correct > dates seem to be showing up now after the initial date (ever since that > initial run of the "dovecot expunge" command was run on all mailboxes). > So in our case I have the expunge set to delete older than 30 days. I > assume if I wait 30 days from now, it will start working? Yup. If you run your script every day (and thus, run "doveadm fetch ... date.saved" as well), that will make sure any new mail put into your Trash folder will have date.saved within 24h of the "real" value. Joseph Tam <jtam.home(a)gmail.com>

1 0

Re: Incorrect saved dates in mailboxes
by Joseph Tam 18 May '23

18 May '23

Chris Szilagyi <chris(a)apex-internet.com> writes: > Recently, I noticed that our expunge script is not working, and I don't > think it ever has on this server. On further inspection, it looks like > the saved date for emails in the folders we want to expunge is set to a > recent date (yesterday) for almost all messages. For example, when I > run the command "doveadm -f tab fetch -u username date.saved mailbox > Trash", the date for almost all of the messages is yesterday at the > exact same time. I tried this on other users and they have this exact > same timestamp shown for most of their messages, too. > > I tried checking for "date.received" and that shows correct, it is > "date.saved" that is not working. > > Any idea of how or why this would not be showing the correct date? I've > used this setup in the past on other servers with dovecot and it has > worked great, no idea why we would be seeing this issue now. I recall having the same problem. I think the "date.saved" is not instantiated in the cache until you query for it. So the value you were shown is when you last dumped its value if it wasn't previously set -- your run of same values coincided when you ran "doveadm fetch". My expunge script just uses date.received instead -- it seems to work. Joseph Tam <jtam.home(a)gmail.com>

2 1