May 2023 - dovecot - dovecot.org

Outlook fails to connect to Dovecot submission server
by Ralf Becker 28 May '23

28 May '23

Dovecot 2.3.20 including it's submission server works well with all sorts of clients, but Outlook. Outlook works / can connect to Dovecot IMAP service with same certificate TLS config, but it fails to connect using SMTPs on port 465. Other clients connect and send mails without problem, also openssl s_client can connect and reports no problems. I tried with Outlook Version 365 on Windows 11 (no cloud) and "Microsoft® Outlook® 2021 MSO (Version 2304 Build 16.0.16327.20200) 64-bit". I already enabled all submission_client_workarounds and lowered min_ssl_version from TLSv1.2 to TLSv1, but that changed nothing. I can see nothing failing in the logs, thought the OL connection wizard always check IMAP and SMTP together, so it's hard to say what the problem is. The same two Outlook version connect without a problem to Postfix authenticating via SASL to Dovecot also requiring a minimum TLS version of 1.2. They just wont connect with Dovecot submission server. Any ideas what's wrong, or how to debug that further? Ralf -- Ralf Becker EGroupware GmbH [www.egroupware.org] Handelsregister HRB Kaiserslautern 3587 Geschäftsführer Birgit und Ralf Becker Leibnizstr. 17, 67663 Kaiserslautern, Germany Telefon +49 631 31657-0

5 8

Inaccurate results while searching for a phrase in subject (fts-flatcurve)
by ss17＠fea.st 26 May '23

26 May '23

Hi, I had been using the lucene FTS plugin since a decade now and it has done me well. Thought of upgrading to the new & current stuff and came across the flatcurve plugin which seems very promising (xapian on the other hand was creating indexes larger than my mailboxes themselves). I am using following configuration in dovecot.conf: fts = flatcurve fts_filters_en = lowercase english-possessive stopwords fts_languages = en fts_tokenizers = generic email-address fts_autoindex = no fts_enforced = yes A search command like this: doveadm -D search -u john(a)doe.com mailbox INBOX SUBJECT "/home/johndoe/render.php" should show the messages with subject: "CRON: /home/johndoe/render.php OK" but produces a lot of extra undesired results and I think the second line in this debug output indicates the reason: May 23 07:44:13 doveadm(john(a)doe.com): Debug: fts-flatcurve(INBOX): Query (hdr_subject:/home/johndoe/render.php*) matches=0 uids= May 23 07:44:13 doveadm(john(a)doe.com): Debug: fts-flatcurve(INBOX): Query (hdr_subject:php* AND hdr_subject:render* AND hdr_subject:johndoe* AND hdr_subject:home*) matches=272 uids=67041,67085,67188,67223,67257,67290,67323,67355,67395,67564,67770,67817,67863,67985,68819,69512,69572,69635,69737,70017,70058,70086,70125,70147,70191,70296,70304,70331,70340,70350,70354,70375,70407,70417,70427,70449,70499,70521:70522,70535:70550,70555,70561:70563,70591,70597:70599,70662,70685,70702,70708,70718:70719,70724,70727:70728,70730:70733,70735,70746:70747,70754,70775,70777,70794,70811:70812,70822,70866,70942,70948,70971,71017,71021,71040,71042,71075,71079,71084,71113,71128:71129,71131,71152,71160,71184,71188,71208,71214,71225,71255,71269,71297,71300,71331,71375,71422,71449,71457,71467,71469,71495,71515,71605,71626,71632,71649,71672,71681:71682,71689,71692,71699,71716,71757,71770,71777,71782:71785,71790,71795,71797,71814,71818:71819,71828,71838:71842,71845,71859:71860,71937,71947,71954,71960,71963:71964,71977,71990,72014,72021:72022,72030,72034:72042,72045:72046,72049,72056,72061,72063,72073:72074,72083,72088,72090,72092,72101,72108,72129,72131:72132,72134,72136:72140,72159,72163,72172:72173,72186,72212,72218:72223,72237,72239,72246,72267,72288,72387,72410,72446,72469,72476:72477,72514,72541,72543,72568:72569,72572:72574,72598,72604,72606,72609,72644,72674,72687,72691,72694,72734,72772,72791,72797,72799,72803,72832:72833,72835:72841,72856:72857,72866:72867,72873:72874,72901,72930,72938,72948,72960,72965,72976,73018,73037,73071,73081,73116,73158,73249,73307,73352,73392,73466,73533,73601,73670,73733,73775,73784:73786,73804,73807,73811,73815,73819,73823,73825,73831,73842,73846,74005,74199,74390,74540,74684,74854,75017,75192,75354,75525,75710,75839:75843,75845,75903,75984:75985,76091,76263,76447,76624,76816,76989,77091:77092,77097,77119,77155,77293,77460,77608,77761,77908,78066,78218,78393,78400:78401,78522:78523,78560,78728,78921,79104,79298,79504,79555,79898,80027,80031:80032,80034:80035,80037,80056,80071,80073,80077:80079,80082:80084,80086,80089 I tried rebuilding the indexes with "fts_flatcurve_substring_search = yes" too but that didn't change anything. It works as expected with lucene plugin because in that case header search is performed via dovecot indexes instead of FTS. May be I am not doing something right in configuring this new FTS? Will really appreciate some pointers here. Thanks, Sam

2 2

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