- dovecot - dovecot.org

Patch: enhancements for solr/tika integration
by John Fawcett 09 Jan '22

09 Jan '22

Hi here's a patch with some enhancements that I am applying locally for solr/tika integration. Hopefully this can be considered for inclusion. I've tested up to 2.3.16 and this patch applies against latest version 2.3.17.1. The contents are: 1. Allow username and password in tika configuration (as is already supported for solr). For example: fts_tika = https://user:password@tika_host:tika_port/tika/tika This means that tika can be more easily located on a different server to dovecot. Locating Solr and Tika on separate servers can isolate the Dovecot server from issues that may happen on Solr or Tika (like out of memory). 2. Introduce an optional configurable limit on the size of emails whose message bodies will be indexed with solr via a new setting fts_max_size, to be put in the plugin section. For example plugin { ... fts_max_size = 2M ... } Message body indexing is skipped for messages that are larger than this setting. 3. Introduce an optional configurable limit on the size of emails whose attachments will be sent to tika for keyword extraction, via a new setting fts_max_size_tika, to be put in the plugin section. For example: plugin { ... fts_max_size_tika = 1M } I noticed that some very large attachments are being sent to tika and these often do not have any useful content to index. For simplicity the check is done on message size not individual or total attachment size. Here's the patch: diff -ur dovecot-2.3.17.1-orig/src/plugins/fts/fts-build-mail.c dovecot-2.3.17.1-new/src/plugins/fts/fts-build-mail.c --- dovecot-2.3.17.1-orig/src/plugins/fts/fts-build-mail.c 2021-12-03 12:48:47.000000000 +0100 +++ dovecot-2.3.17.1-new/src/plugins/fts/fts-build-mail.c 2022-01-09 01:33:23.398341998 +0100 @@ -17,6 +17,7 @@ #include "fts-filter.h" #include "fts-api-private.h" #include "fts-build-mail.h" +#include "settings-parser.h" /* there are other characters as well, but this doesn't have to be exact */ #define IS_WORD_WHITESPACE(c) \ @@ -25,6 +26,8 @@ wherever */ #define MAX_WORD_SIZE 1024 +static bool debug = FALSE; + struct fts_mail_build_context { struct mail *mail; struct fts_backend_update_context *update_ctx; @@ -34,6 +37,7 @@ buffer_t *word_buf, *pending_input; struct fts_user_language *cur_user_lang; + bool oversized_tika; }; static int fts_build_data(struct fts_mail_build_context *ctx, @@ -223,7 +227,7 @@ parser_context.user = mail_storage_get_user(storage); parser_context.content_disposition = ctx->content_disposition; - + parser_context.oversized_tika = ctx->oversized_tika; if (fts_parser_init(&parser_context, &ctx->body_parser)) { /* extract text using the the returned parser */ *binary_body_r = TRUE; @@ -496,7 +500,32 @@ bool binary_body; const char *error; int ret; - + uoff_t msg_size; + uoff_t fts_max_size = 0; + uoff_t fts_max_size_tika = 0; + const char * fts_max_size_setting; + const char * fts_max_size_tika_setting; + bool oversized_msg; + bool oversized_tika; + + fts_max_size_setting = mail_user_plugin_getenv(update_ctx->backend->ns->user, "fts_max_size"); + if (fts_max_size_setting != NULL) { + if (debug) i_debug("fts_max_size %s",fts_max_size_setting); + if (settings_get_size(fts_max_size_setting, &fts_max_size, &error) < 0) { + i_error("%s",error); + fts_max_size = 0; + } + if (debug) i_debug("fts_max_size (value) %"PRIuUOFF_T,fts_max_size); + } + fts_max_size_tika_setting = mail_user_plugin_getenv(update_ctx->backend->ns->user, "fts_max_size_tika"); + if (fts_max_size_tika_setting != NULL) { + if (debug) i_debug("fts_max_size_tika %s",fts_max_size_tika_setting); + if (settings_get_size(fts_max_size_tika_setting, &fts_max_size_tika, &error) < 0) { + i_error("%s",error); + fts_max_size_tika = 0; + } + if (debug) i_debug("fts_max_size_tika (value) %"PRIuUOFF_T,fts_max_size_tika); + } *may_need_retry_r = FALSE; if (mail_get_stream_because(mail, NULL, NULL, "fts indexing", &input) < 0) { if (mail->expunged) @@ -505,10 +534,21 @@ mailbox_get_last_internal_error(mail->box, NULL)); return -1; } - + oversized_msg = FALSE; + oversized_tika = FALSE; + i_stream_get_size(input,TRUE,&msg_size); + if (fts_max_size > 0 && msg_size > fts_max_size) { + i_info("Skipping message body indexing because size %"PRIuUOFF_T" exceeds setting fts_max_size %s",msg_size,fts_max_size_setting); + oversized_msg = TRUE; + } + if (fts_max_size_tika > 0 && msg_size > fts_max_size_tika) { + i_info("Skipping message attachment indexing because size %"PRIuUOFF_T" exceeds setting fts_max_size_tika %s",msg_size,fts_max_size_tika_setting); + oversized_tika = TRUE; + } i_zero(&ctx); ctx.update_ctx = update_ctx; ctx.mail = mail; + ctx.oversized_tika = oversized_tika; if ((update_ctx->backend->flags & FTS_BACKEND_FLAG_TOKENIZED_INPUT) != 0) ctx.pending_input = buffer_create_dynamic(default_pool, 128); @@ -563,7 +603,7 @@ message_decoder_set_return_binary(decoder, TRUE); body_part = TRUE; } else { - if (skip_body) + if (skip_body ||oversized_msg) continue; } @@ -597,7 +637,7 @@ else (void)fts_parser_deinit(&ctx.body_parser, NULL); } - if (ret == 0 && body_part && !skip_body && !body_added) { + if (ret == 0 && body_part && !skip_body && !oversized_msg && !body_added) { /* make sure body is added even when it doesn't exist */ block.data = NULL; block.size = 0; ret = fts_build_body_block(&ctx, &block, TRUE); diff -ur dovecot-2.3.17.1-orig/src/plugins/fts/fts-parser.h dovecot-2.3.17.1-new/src/plugins/fts/fts-parser.h --- dovecot-2.3.17.1-orig/src/plugins/fts/fts-parser.h 2021-12-03 12:48:47.000000000 +0100 +++ dovecot-2.3.17.1-new/src/plugins/fts/fts-parser.h 2022-01-09 01:33:23.399341985 +0100 @@ -10,6 +10,7 @@ /* Can't be NULL */ const char *content_type; const char *content_disposition; + bool oversized_tika; }; struct fts_parser_vfuncs { diff -ur dovecot-2.3.17.1-orig/src/plugins/fts/fts-parser-tika.c dovecot-2.3.17.1-new/src/plugins/fts/fts-parser-tika.c --- dovecot-2.3.17.1-orig/src/plugins/fts/fts-parser-tika.c 2021-12-03 12:48:47.000000000 +0100 +++ dovecot-2.3.17.1-new/src/plugins/fts/fts-parser-tika.c 2022-01-09 01:33:23.400341972 +0100 @@ -57,7 +57,7 @@ tuser = p_new(user->pool, struct fts_parser_tika_user, 1); MODULE_CONTEXT_SET(user, fts_parser_tika_user_module, tuser); - if (http_url_parse(url, NULL, 0, user->pool, + if (http_url_parse(url, NULL, HTTP_URL_ALLOW_USERINFO_PART, user->pool, &tuser->http_url, &error) < 0) { i_error("fts_tika: Failed to parse HTTP url %s: %s", url, error); return -1; @@ -148,6 +148,10 @@ if (tika_get_http_client_url(parser_context->user, &http_url) < 0) return NULL; + if (parser_context->oversized_tika) { + i_info("skipping tika parser due to oversized message"); + return NULL; + } if (http_url->path == NULL) http_url->path = "/"; @@ -159,6 +163,11 @@ http_url->host.name, t_strconcat(http_url->path, http_url->enc_query, NULL), fts_tika_parser_response, parser); + if (http_url->user != NULL) { + http_client_request_set_auth_simple( + http_req, http_url->user, http_url->password); + } + http_client_request_set_port(http_req, http_url->port); http_client_request_set_ssl(http_req, http_url->have_ssl); if (parser_context->content_type != NULL) John

1 0

Patch: safeguard against too large value for uid being sent to solr for single mailbox searches
by John Fawcett 09 Jan '22

09 Jan '22

Hi I'm reposting a patch for solr integration which I have been applying locally. It applies against 2.3.17.1. Dovecot already has a mechanism when doing solr fts searches on multiple mailboxes that prevents a too large value for maximum rows being sent to solr. #define SOLR_MAX_MULTI_ROWS 100000 (defined and used in plugins/fts-solr/fts-backend-solr.c) However on single mailbox searches Dovecot uses the last uid of the mailbox, which can be too large for solr. My suggested patch is to also limit maximum rows to return on single mailbox searches. Here is the patch: diff -ur dovecot-2.3.17.1-orig/src/plugins/fts-solr/fts-backend-solr.c dovecot-2.3.17.1-new/src/plugins/fts-solr/fts-backend-solr.c --- dovecot-2.3.17.1-orig/src/plugins/fts-solr/fts-backend-solr.c 2021-12-03 12:48:47.000000000 +0100 +++ dovecot-2.3.17.1-new/src/plugins/fts-solr/fts-backend-solr.c 2022-01-09 01:33:23.401341959 +0100 @@ -837,7 +837,7 @@ str = t_str_new(256); str_printfa(str, "wt=xml&fl=uid,score&rows=%u&sort=uid+asc&q=%%7b!lucene+q.op%%3dAND%%7d", - status.uidnext); + I_MIN(status.uidnext,SOLR_MAX_MULTI_ROWS)); prefix_len = str_len(str); if (solr_add_definite_query_args(str, args, and_args)) { John

1 0

Can't log in from Evolution or Roundcube
by Ken Wright 09 Jan '22

09 Jan '22

When I try to log in to my mail server (ubuntu 20.04, Postfix 3.4.13, Dovecot 2.3.7.2) I get a response saying "Source stream returned no data”. At least to me, that's not particularly informative. Is it any more informative to anyone else? Ken

3 10

Sv: banning
by Sebastian Nielsen 08 Jan '22

08 Jan '22

I would say, lock accounts to for example IP address, ASN or GeoIP. This can be accomplished simply by a custom login handler, which also checks IP against database. And first time users, and those who change country/ISP/IP have to simply logon to a web interface (where 2FA can be required and also Captcha) and add their IPs/ASNs/Geo's. For a larger user base, I would recommend GeoIP and no web interface, save country of first login to database, and subsequent logins must originate from same country. Users that want to reset have to contact support. If you are a web hotel who only sell service to a specific country at all, lock the ports in firewall to that GeoIP. For smaller user base, like 50-100 users, I would recommend locking to ASN and providing a web interface where multiple ASN can be added. So people syncing from mobile and home can succeed. For very small user base, like 10's of users, just plan lock to IP. By connecting IP to accounts, you greatly reduce the attack surface.

1 0

TLS connection closed unexpectedly
by Ken Wright 08 Jan '22

08 Jan '22

I reinstalled Dovecot this evening, because I haven't been able to receive emails recently. After configuring and adjusting for the use of PostfixAdmin, I get the following error message in Evolution:; Failed to open folder. The reported error was "Failed to authenticate: TLS connection closed unexpectedly". Does anyone recognize this error? Ken

6 8

Update from 2.3.16 to 2.3.17 Received invalid SSL certificate: unable to get certificate CRL
by Salatiel Filho 08 Jan '22

08 Jan '22

Hi, after updating from dovecot.x86_64 2:2.3.16-2 to 2:2.3.17.1-1 on AlmaLinux 8 my dovecot replication stopped working. Log is full of Error: doveadm server disconnected before handshake: Received invalid SSL certificate: unable to get certificate CRL: /CN=my.domain.redacted (check ssl_client_ca_* settings?) No configuration has changed on my side. My certificate is a wildcard certificate ( not sure if related ). I am also replicating over tcps. Anyone else facing this issue? Atenciosamente/Kind regards, Salatiel

1 0

Sieve scripts igniored
by Sam R 07 Jan '22

07 Jan '22

Hello, I have an issue with Sieve plugin, I can drive rules remotely with sieve:// myserver.fr:4190/?tls=YES, the rules are well created under /home/vmail/name.firstname, but these are never executed. I have also read https://doc.dovecot.org/configuration_manual/sieve/troubleshooting/, but I don't see any evident mistake. here is my dovecot -n : # 2.3.13 (89f716dc2): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.13 (cdd19fe3) # OS: Linux 5.10.0-8-amd64 x86_64 Debian 11.0 ext4 # Hostname: mail.xxx.fr auth_debug = yes auth_gssapi_hostname = $ALL auth_krb5_keytab = /etc/dovecot/dovecot.keytab auth_mechanisms = login plain gssapi mail_location = maildir:/home/vmail/%n/Maildir/ mail_privileged_group = mail managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relationa l regex imap4flags copy include variables body enotify environment mailbox date index ihave duplicate mime foreverypart extracttex t namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = } passdb { driver = pam } passdb { driver = pam } plugin { sieve = file:~/sieve;active=~/.dovecot.sieve } protocols = " imap lmtp sieve pop3" service lmtp { executable = lmtp -L unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0666 user = postfix } } service managesieve-login { inet_listener sieve { port = 4190 } } ssl = required ssl_cert = </etc/letsencrypt/live/mail.xxx.fr/fullchain.pem ssl_client_ca_dir = /etc/ssl/certs ssl_client_ca_file = /etc/letsencrypt/live/mail.xxx.fr/chain.pem ssl_dh = # hidden, use -P to show it ssl_key = # hidden, use -P to show it userdb { driver = passwd } userdb { args = uid=vmail gid=vmail home=/home/vmail/%u allow_all_users=yes driver = static } userdb { driver = passwd } protocol lmtp { mail_plugins = " sieve" } protocol lda { mail_plugins = " sieve" } Thanks for helping. kind regards. Samuel

3 3

feature-request: make received-header on submission optional or at least drop the ip in it
by dc-ml＠dvl.werbittewas.de 07 Jan '22

07 Jan '22

hi. we're just trying to re-structure a system and want to use dovcots submission-ability. because the github-repository have no entry for any issues at all, we're sending this feature-fequest to this ML. unfortunately there doesn't seem to be any option to drop the received-header at all or at least hide the IP of the user. because the client-ip is covered by GDPR as personal data and so it should never shown to others without a certain reason, we want to hide it, but there's no "submission_add_received_header"-option like for lmtp and it doesn't seem to be any other option to hide this information. maybe this is possible to implement in near future? thanks a lot. best regards d.

8 18

Dovecot fixing maildir message size?
by Grant Keller 07 Jan '22

07 Jan '22

We recently updated dovecot from 2.1.17 to 2.3.10. It used to be when we encountered the following error: Jan 6 15:29:20 d.imapd.sonic.net dovecot: imap(momomo): session=aBd2O/LULMu4F6ia Error: Mailbox INBOX: UID=1: read(/var/spool/mail/07/00/momomo/cur/1510707300.12345_0.a.spam,S=1234:2,) failed: Cached message size larger than expected (1234 > 704, box=INBOX, UID=1) (read reason=) Dovecot would fix the size by renaming the file. Now this doesn't appear to be the case. Was there a change in behaviour, or is there an option I need to enable now to have dovecot auto fix this?

1 0

Re: Error: fts_solr: received invalid uid
by oliver.krone＠snoog.ch 07 Jan '22

07 Jan '22

Hello, I made serveral tests, never had a problemm woth dovecot version 2.3.4 with 2.3.13 things get worse and dovecot crashes. I might have read someting in the release notes of dovecot 2.3.13. that there is a problem. Regards Oliver > On 1/2/22 3:08 PM, John Fawcett wrote: >> unless I'm missing something that doesn't look like the type of query >> dovecot launches - dovecot sends various parameters including the >> request for xml results. The thing that looks odd to me is that the >> results fields should be single values not arrays enclosed in [], ie I >> would have expected >> "uid":21, >> >> instead of >> >> "uid":[21], >> >> I'd be interested to see the equivalent xml output produced by running >> a query that dovecot sends. >> > > This Solr instance is not configured properly for dovecot.? Most of the > fields are configured as multiValued (which is why you see an array > rather than a single value), and the response is JSON.? A Solr instance > that is properly configured for dovecot would return XML, not JSON. > > You're going to want to provide a proper solrconfig.xml and > managed-schema file, restart Solr or reload the core for dovecot, and > do > a full reindex.? At the following URL, you can find the shell script > that I use to do a full reindex: > > https://apaste.info/tK1B > > At the following URL are links to the solrconfig.xml and schema that > are > appropriate for dovecot.? These instructions say to name the schema > file > "schema.xml" ... this will work, as long as Solr has read-write access > to the conf directory so it can rename the file to "managed-schema".? > If > it doesn't, then you should name the file "managed-schema" yourself. > > https://doc.dovecot.org/configuration_manual/fts/solr/ > > Thanks, > Shawn

2 2