- dovecot - dovecot.org

Dovecot Gmail OAuth2.0 Setting Question
by 福田泰葵 19 Jan '21

19 Jan '21

Dear Sir or Madam Unable to build OAuth2.0 authentication to Gmail using dovecot as proxy. I have a question about how to use dovecot as a proxy to perform OAuth 2.0 authentication to Gmail using a mail client. 1. Is the following all I need to do to authenticate to Gmail using dovecot as a proxy? - passdb passdb { driver = oauth2 mechanisms = oauthbearer xoauth2 args = /etc/dovecot/dovecot-oauth2.token.conf.ext } passdb { driver = oauth2 mechanisms = plain login args = /etc/dovecot/dovecot-oauth2.plain.conf.ext } - create dovecot-oauth2.token.conf.ext and dovecot-oauth2.plain.conf.ext - create gmail service account api 2. grant_url in dovecot-oauth2.token.conf.ext and dovecot-oauth2.plain.conf.ext is URL for obtaining a Google access token for a web server that I have built myself? 3. I use a Gmail service account, so I don’t need a client ID and secret ID, right? 4. Do I set introspection_url to the URL of my own web server with the access token used for authentication to Google as the response? 5. The documentation says “pass_attrs = host=127.0.0.1”, but if you are authenticating to Gmail, I should use “pass_attrs = proxy=y host=%{if;%s;eq;imap;imap.gmail.com;%{if;%s;eq;pop3;smtp .gmail.com;pop.gmail.com}} port=%{if;%s;eq;imap;993;%{if;%s;eq;pop3;587;465}} proxy_mech=xoauth2 pass=%{oauth2:access_token} user=%{oauth2:email oauth2:email}”? 6. What is the difference between dovecot-oauth2.token.conf.ext and dovecot-oauth2.plain.conf.ext ? Do I need to configure both? I used https://doc.dovecot.org/configuration_manual/authentication/oauth2/#proxy as a reference. I would appreciate your reply. Yours faithfully, ------------------------------ e-mail: taiki.fukuda(a)justsystems.com TEL: 03-5324-7900 mobile: 080-6198-7328 ------------------------------

1 0

dovecot 2.3.13 : make check FAILURE : Assert failed: buffer_append_full_file
by J Lumby 19 Jan '21

19 Jan '21

After successfully building dovecot 2.3.13 (linux kernel 5.10.1 , glibc-2.32 , gcc-9.3) make check had one failure as follows : test-buffer-istream.c:54: Assert failed: buffer_append_full_file(result, TEST_FILENAME, SIZE_MAX, &error) == BUFFER_APPEND_READ_ERROR test-buffer-istream.c:56: Assert failed: error != NULL && *error != '\0' buffer_append_full_file .............................................. : FAILED After a brief look at the referenced code in test-buffer-istream.c , I can't find out what this FAIL really means or whether it is serious. The assert is finding that the result of the call to buffer_append_full_file is not BUFFER_APPEND_READ_ERROR, but it does not report what the result code actually was. Maybe errno was actually 0 and call succeeded? I don't know. Nor can I see how to add some code to find out. Can anyone offer any advice on what this means and/or how to investigate? Cheers, John Lumby

2 6

Changing the default delivery mailbox to something other than INBOX
by Ron Garret 18 Jan '21

18 Jan '21

Is there an easy way (i.e. a built-in configuration setting) to change the name of the mailbox that the dovecot LDA delivers mail into? The default is INBOX but I’d like mail to be delivered to some other mailbox. The reason for this is that I want all incoming mail to be invisible to the user by default until it has been screened for viruses and spam. I know I could do this with Sieve, but that is a PITA. More details in case anyone is interested: The goal of this filter is to make it work with very little training. To bootstrap the process, the filter is given access to outgoing mail (via a milter) which it uses as a reliable training corpus for good messages. It then leverages that information to filter incoming messages. For example, messages from senders which have been the recipients of outgoing messages are presumed to be good. There is also a spam honeypot to provide a reliable spam corpus. One of the heuristics I want to use is to look for the same subject line in multiple messages from unknown users received over a period of an hour or so because those are almost invariably spam. But that requires a time delay between when a message is received and when it is filtered, and that in turn requires a place to store messages for a while before they are processed. While they are in that temporary storage, I don’t want them in the user’s face, but I do want them to be accessible if the user wants to see them (e.g. if they know that an important message is coming in which may be stuck in the temp storage). So I’d like to make something like an INCOMING mailbox where all mail is delivered. The messages in INCOMING are scanned by the filter and moved to Junk or INBOX as appropriate. Thanks, rg

3 12

mbox to pst advice
by Marc Roos 18 Jan '21

18 Jan '21

Anyone an idea how to convert mbox ot pst on linux?

3 6

fts_solr: Indexing failed (fails on particular messages/mailboxes by timeout)
by Alexey Panov 18 Jan '21

18 Jan '21

Hello, I am running recent dovecot 2.3.13 (89f716dc2) within dockerized mailcow setup. During just another update routine I decided to reindex all mailboxes and some of them fail (timeout) on exactly SAME messages in SAME mailboxes: > doveadm(u@d): Error: fts_solr: Indexing failed: Request timed out (Request queued 73.213 secs ago, 1 send attempts in 73.098 secs, 60.597 in http ioloop, 0.000 in other ioloops, connected 127.875 secs ago) > doveadm(u@d): Error: Mailbox Sent: Mail search failed: Internal error occurred. Refer to server log for more information. [2021-01-14 11:23:46] > doveadm(u@d): Error: Mailbox Sent: Transaction commit failed: FTS transaction commit failed: backend deinit This error is persistent and affects only some, but always same folders of same mailboxes (i mean solr can't finish indexing them at all). I/O is in perfect condition and has no corruptions. I also tried to do fts rescan which made no change. RAM is fine, I haven't seen OOM conditions. During my research I found this discussion <https://www.mail-archive.com/dovecot@dovecot.org/msg76944.html> which lead me idea of reducing the batch_size to as low as 10 (for testing purposes). Observing SOLR logs during reindexing on the mailbox/folder causing the error I noticed the following strange behaviour. Firstly, it goes very fast but then always kinda freezes on these messages: > solr-mailcow_1 | 2021-01-14 16:05:09.615 INFO (qtp524223214-1151) [ x:dovecot-fts] o.a.s.u.p.LogUpdateProcessorFactory [dovecot-fts] webapp=/solr path=/update params={}{add=[6883/78a0ec27b091da5e4054000013681708/u@d (1688878773188952064), 6884/78a0ec27b091da5e4054000013681708/u@d (1688878773203632128), 6885/78a0ec27b091da5e4054000013681708/u@d (1688878773218312192), 6886/78a0ec27b091da5e4054000013681708/u@d (1688878773227749376), 6887/78a0ec27b091da5e4054000013681708/u@d (1688878773237186560), 6888/78a0ec27b091da5e4054000013681708/u@d (1688878773244526592), 6889/78a0ec27b091da5e4054000013681708/u@d (1688878773250818048), 6890/78a0ec27b091da5e4054000013681708/u@d (1688878773259206656), 6891/78a0ec27b091da5e4054000013681708/u@d (1688878773272838144), 6892/78a0ec27b091da5e4054000013681708/u@d (1688878773288566784)]} 0 101 > solr-mailcow_1 | 2021-01-14 16:06:42.540 INFO (qtp524223214-1143) [ x:dovecot-fts] o.a.s.u.p.LogUpdateProcessorFactory [dovecot-fts] webapp=/solr path=/update params={}{add=[6893/78a0ec27b091da5e4054000013681708/u@d (1688878773329461248), 6894/78a0ec27b091da5e4054000013681708/u@d (1688878773332606976), 6895/78a0ec27b091da5e4054000013681708/u@d (1688878774361260032), 6896/78a0ec27b091da5e4054000013681708/u@d (1688878850290745344), 6897/78a0ec27b091da5e4054000013681708/u@d (1688878851347709952), 6898/78a0ec27b091da5e4054000013681708/u@d (1688878852404674560), 6899/78a0ec27b091da5e4054000013681708/u@d (1688878853586419712), 6900/78a0ec27b091da5e4054000013681708/u@d (1688878870704422912), 6901/78a0ec27b091da5e4054000013681708/u@d (1688878870709665792), 6902/78a0ec27b091da5e4054000013681708/u@d (1688878870727491584)]} 0 92891 It takes almost one and a half minute to get those ten messages (6893-6902) indexed. It freezes exactly on that position every time I restart indexing. Actually only reducing the batch_size to 10 made it through. It was timing out with the default batch_size exactly here each time. Than it goes further again blazing fast until it reaches here: > solr-mailcow_1 | 2021-01-14 16:07:26.148 INFO (qtp524223214-1151) [ x:dovecot-fts] o.a.s.u.p.LogUpdateProcessorFactory [dovecot-fts] webapp=/solr path=/update params={}{add=[7443/78a0ec27b091da5e4054000013681708/u@d (1688878884286627840), 7444/78a0ec27b091da5e4054000013681708/u@d (1688878884293967872), 7445/78a0ec27b091da5e4054000013681708/u@d (1688878884304453632), 7446/78a0ec27b091da5e4054000013681708/u@d (1688878884502634496), 7447/78a0ec27b091da5e4054000013681708/u@d (1688878900331937792), 7448/78a0ec27b091da5e4054000013681708/u@d (1688878900508098560), 7449/78a0ec27b091da5e4054000013681708/u@d (1688878916409753600), 7450/78a0ec27b091da5e4054000013681708/u@d (1688878916424433664), 7451/78a0ec27b091da5e4054000013681708/u@d (1688878916438065152), 7452/78a0ec27b091da5e4054000013681708/u@d (1688878916448550912)]} 0 30682 > solr-mailcow_1 | 2021-01-14 16:09:40.277 INFO (qtp524223214-1325) [ x:dovecot-fts] o.a.s.u.p.LogUpdateProcessorFactory [dovecot-fts] webapp=/solr path=/update params={}{add=[7463/78a0ec27b091da5e4054000013681708/u@d (1688879057103486976)]} 0 1 > solr-mailcow_1 | 2021-01-14 16:10:00.628 INFO (qtp524223214-1009) [ x:dovecot-fts] o.a.s.u.p.LogUpdateProcessorFactory [dovecot-fts] webapp=/solr path=/update params={}{add=[7453/78a0ec27b091da5e4054000013681708/u@d (1688878916486299648), 7454/78a0ec27b091da5e4054000013681708/u@d (1688878916489445376), 7455/78a0ec27b091da5e4054000013681708/u@d (1688878916496785408), 7456/78a0ec27b091da5e4054000013681708/u@d (1688878917584158720), 7457/78a0ec27b091da5e4054000013681708/u@d (1688878994974310400), 7458/78a0ec27b091da5e4054000013681708/u@d (1688879073177108480), 7459/78a0ec27b091da5e4054000013681708/u@d (1688879074234073088), 7460/78a0ec27b091da5e4054000013681708/u@d (1688879075288940544), 7461/78a0ec27b091da5e4054000013681708/u@d (1688879076339613696), 7462/78a0ec27b091da5e4054000013681708/u@d (1688879077392384000)]} 0 154455 This results in the following error on the console where I start reindexing: > $ docker-compose exec dovecot-mailcow doveadm index -u u@d 'Sent' > doveadm(u@d): Error: fts_solr: Indexing failed: Request timed out (Request queued 134.122 secs ago, 1 send attempts in 134.098 secs, 131.923 in http ioloop, 0.000 in other ioloops, connected 376.408 secs ago) > doveadm(u@d): Error: Mailbox Sent: Mail search failed: Internal error occurred. Refer to server log for more information. [2021-01-14 17:09:40] > doveadm(u@d): Error: Mailbox Sent: Transaction commit failed: FTS transaction commit failed: backend deinit The last message about indexed block of ten messages (2021-01-14 16:10:00.628 7453-7462) arrives already after reindexing error on the other console occurs and doveadm exits. Interestingly, exactly at the time mentioned in the error message (2021-01-14 17:09:40, i.e. 16:06:40 - I don’t know why timezone differs) a message about indexing of a single message 7463 arrives (which is actually NEXT message to the block that gets indexed 20 seconds later). The whole mailbox consists of 8530 messages and doveadm/solr can’t finish indexing it at all starting over and over. Can you please help me understanding the reason of this behaviour? P.S. Is there any possibility to determine what message in vmail maildir corresponds to solr log, e.g. to 7463/78a0ec27b091da5e4054000013681708/u@d (1688879057103486976) ? Thanks, Programmierus

2 4

Additional custom fields in map dict with static values.
by Mimiko 17 Jan '21

17 Jan '21

Hello. Dovector version 2.2.27. How can I add custom fields in the map for the last_login. For example: map { pattern = shared/last_login/imap/$user/$client_ip table = users_last_login value_field = last_login_imap_int value_type = string fields { userid = $user last_login_client_ip_imap = $client_ip custom_field_name = some_static_value } }

1 0

Antispam plugin
by Maciej Milaszewski 17 Jan '21

17 Jan '21

Hi System centos8 + dovecot-2.3.8 from repo # 2.3.8 (9df20d2db): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.8 (b7b03ba2) # OS: Linux 4.18.0-193.19.1.el8_2.x86_64 x86_64 CentOS Linux release 8.2.2004 (Core) I need "Antispam plugin". What antispam-plugin I must use ? In older version dovecot-2.2.36.4 i use "dovecot-antispam-plugin" but in centos I had a problem with configure - probably toold wersion "./configure: line 3193: DC_DOVECOT: command not found" In wiki dovect is "antispam-plugin" I try this http://hg.dovecot.org/dovecot-antispam-plugin but get 404 Backand spamassassin

4 3

Re: dovecot 2.3.13 : make check FAILURE : Assert failed: buffer_append_full_file
by steve＠keptprivate.com 16 Jan '21

16 Jan '21

I was experiencing multiple failures with make check on a fresh installation of CentOS 8.3.The solution for me was to use mock instead of rpmbuild. (I was not building as root with rpmbuild.) With mock all tests were successful. Sent from my T-Mobile 4G LTE device------ Original message------From: J LumbyDate: Sat, Jan 16, 2021 11:31 AMTo: dovecot(a)dovecot.org;Cc: Subject:dovecot 2.3.13 : make check FAILURE : Assert failed: buffer_append_full_fileAfter successfully building dovecot 2.3.13 (linux kernel 5.10.1 , glibc-2.32 , gcc-9.3) make check had one failure as follows : test-buffer-istream.c:54: Assert failed: buffer_append_full_file(result, TEST_FILENAME, SIZE_MAX, &error) == BUFFER_APPEND_READ_ERROR test-buffer-istream.c:56: Assert failed: error != NULL && *error != '\0' buffer_append_full_file .............................................. : FAILED After a brief look at the referenced code in test-buffer-istream.c , I can't find out what this FAIL really means or whether it is serious. The assert is finding that the result of the call to buffer_append_full_file is not BUFFER_APPEND_READ_ERROR, but it does not report what the result code actually was. Maybe errno was actually 0 and call succeeded? I don't know. Nor can I see how to add some code to find out. Can anyone offer any advice on what this means and/or how to investigate? Cheers, John Lumby

1 0

outlook 2019 imap folder subscription
by Alexander Rivanykov 16 Jan '21

16 Jan '21

1 0

The use of %w in password_query leads to "Failed to expand plugin setting" error
by Filidor Wiese 16 Jan '21

16 Jan '21

Hi, I'm trying to convert my existing users to a more modern password scheme by following the how-to at https://wiki.dovecot.org/HowTo/ConvertPasswordSchemes. One of the steps is to include the use of '%w' in the password_query, like so: password_query = \ SELECT domain, password, '%w' AS userdb_plain_pass, \ domain as userdb_domain, concat('*:storage=', quota) AS userdb_quota_rule, 5000 as userdb_uid, 5000 as userdb_gid, '/home/%d/%n' as userdb_home \ FROM users WHERE (catch='%n' AND domain='%d') and also to configure: userdb { driver = prefetch } in order to combine the user/password_query into one. Now that all seemed to work well, except for one thing. When a user has a % sign in their password, the following error occurs: Error: Failed to expand plugin setting plain_pass = 'Tfew3322gYEp$%5Qjk0': Unknown variable '%Q' Which indicates that dovecot is trying to expand variables in the password. As a consequence, the login process fails. Is there some way around this behavior? Thanks in advance, Filidor Wiese

4 5