October 2022 - dovecot

[Dovecot] doveadm delete folders ?
by Robert Schetterer 19 Feb '24

19 Feb '24

Hi , is there a feature like doveadm expunge savedbefore ... for imap folder delete ? -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria

5 10

Recommended changes for delivery from Exim
by jgh＠exim.org 05 Feb '24

05 Feb '24

Hi, Security changes to Exim have invalidated certain suggested configurations in the Dovecot wiki. As I do not have a Dovecot installation to test, I am not going to write any updates there. It would be good if someone would test these suggestions and then make updates as needed. 1) The use of $local_part and $domain in commands run by the "pipe" transport will be disallowed in the upcoming Exim release. These are currently noted as optional, with the "-m" flag to dovecot-lda. They should be replaced with validated (untainted) versions, commonly $local_part_data and $domain_data, developed via one of the several de-taint methods documented for Exim. The same applies to $original_local_part and $original_domain. 2) The use of $sender_address will likewise be disallowed. This and the "-f" flag can be dropped from the dovecot-lda command line, and the specification of a null "message_prefix" option removed. The defaults for a pipe transport will then prefix the message with a suitable Mbox "From " header line, which dovecot-lda is documented to extract the sender from. Both of these suggestions are back-compatible to the current 4.95 release of Exim, and will be required with the 4.96 release. -- Cheers, Jeremy Refs: - https://wiki.dovecot.org/LDA/Exim - https://doc.dovecot.org/configuration_manual/protocols/lda/

3 3

JMAP support?
by Mark Constable 31 Jan '24

31 Jan '24

On Fri Jan 25 2019 Aki wrote: > There is no JMAP support in any dovecot version yet. Two years on so what is the status of JMAP support in Dovecot now?

7 10

bug report: lmtp fails on root-squashed NFS filesystem
by Anne Bennett 09 Oct '23

09 Oct '23

Hi, all. I'm trying to set up Postfix with dovecot LTMP delivery on a host where the user files (/var/spool/mail as well as home directories) are on NFS filesystems, which are exported root-squashed to the mail server. I definitely don't want to give the mail server root permissions on the user files. LMTP delivery fails with this logged message (e.g.): Nov 16 17:51:36 lust dovecot: lmtp(anne)<16830><mkkzEPg1lGG+QQAAs/mAJw>: msgid=<202111162229.1AGMTfAO024765(a)vindemiatrix.encs.concordia.ca>: save failed to INBOX: Read-only mbox I found this posting where someone else had a similar problem and traced it in some detail back in 2019: https://dovecot.org/list/dovecot/2019-February/114611.html but apparently no one answered the fellow. In order to check that this is indeed the same problem, I temporarily changed the INBOX definition to make it write into /var/tmp/ (on a local filesystem), and delivery worked. I then temporarily changed the INBOX definition to make it write into an NFS filesystem with root NOT squashed, and again it worked (after I chmodded the directory to 1777 to allow any user to create a file). I believe that the person who wrote the above posting is correct: at some point, file access is (incorrectly) checked as root instead of as the target user. This is a bit of a showstopper for me. Any plans to address this? I attach the output of "dovecot -n", fwiw, but I don't think that this is a configuration problem... Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne(a)encs.concordia.ca +1 514 848-2424 x2285

2 4

Pigeonhole redirect is adding a message-id header when it already exists
by Sébastien Riccio 04 Aug '23

04 Aug '23

Hello, We are using sieve filter to redirect incoming mails to an external mailbox (gmail) an we are seeing some forwarded e-mails being rejected by gmail because of duplicate headers. I think was able to identify the probable cause of the duplicate headers: It seems that when the original message's "Message-ID" is not compliant, pigeonhole acts like if the header is not existing and adds it's own Message-ID. This result in having two "Message-ID" headers being submitted to the destination mail server. Original Message-ID: Message-ID: 1883biz_pay_after_purchase:0:0_572392900$ae7ed6e4d53b424c84aaf83b30c507e7 Pigeon hole adds his own Message-ID: Message-ID: <dovecot-sieve-1664386049-21512-0@510faa1ff2d9> Gmail answer: 550-5.7.1 [94.103.100.17] Our system has detected that this message is not RFC 550-5.7.1 5322 compliant: duplicate headers. To reduce the amount of spam sent 550-5.7.1 to Gmail, this message has been blocked. Please review 550 5.7.1 RFC 5322 specifications for more information. While I understand the original "Message-ID" seems to be all but compliant with RFCs, shouldn't a "Message-ID" be added only when "Message-ID" is really missing ? When redirecting a message, If the original "Message-ID" exists but is bogus shouldn't it still be forwarded untouched ? Also, maybe if pigeonhole is adding it's own "Message-ID", shouldn't it remove any previous "Message-ID" to avoid generating duplicate headers ? (but maybe it could break some DKIM stuff?) Any ideas how to workaround this issue ? Thanks a lot for your feedbacks! Sébastien RICCIO SYSTEM ADMINISTRATOR P +41 840 888 888 F +41 840 888 000 M sriccio(a)swisscenter.com<mailto:sriccio@swisscenter.com>

9 17

Warning sqlpool(mysql): Query failed
by Alessio Cecchi 27 Jun '23

27 Jun '23

Hi, with the last dovecot version (2.3.13) I see many of this warnings via "doveadm log errors": Feb 17 03:26:28 Warning: dict(31513): conn unix:dict (pid=31330,uid=95): dict(mysql)<email1(a)company1.com>: sqlpool(mysql): Query failed, retrying: MySQL server has gone away (idled for 679 secs) Feb 17 03:48:53 Warning: dict(31013): conn unix:dict (pid=31805,uid=95): dict(mysql)<email2(a)company2.com>: sqlpool(mysql): Query failed, retrying: MySQL server has gone away (idled for 685 secs) Feb 17 03:54:12 Warning: dict(32529): conn unix:dict (pid=3147,uid=95): dict(mysql)<email3(a)company3.com>: sqlpool(mysql): Query failed, retrying: MySQL server has gone away (idled for 670 secs) What do they mean? I thinks are related to inactivity timeout on mysql server (where I have a wait_timeout=600), but these warnings could be problems or can be fixed with some setting in dovecot? My dovecot configuration about dict: dict { acl = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext expire = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext sieve = mysql:/etc/dovecot/dovecot-dict-sieve-sql.conf.ext sqlquota = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext } plugin { [...] acl_shared_dict = proxy::acl expire_dict = proxy::expire quota2 = dict:Quota Usage::noenforcing:proxy::sqlquota sieve = file:~/sieve;active=~/.dovecot.sieve sieve_before = dict:proxy::sieve;name=activesql [...] } service dict { process_limit = 500 unix_listener dict { group = vmail mode = 0660 user = vmail } } Thanks -- Alessio Cecchi Postmaster @ http://www.qboxmail.it https://www.linkedin.com/in/alessice

2 1

dovecot-fts-solr Solr9 support
by PGNet Dev 24 Apr '23

24 Apr '23

I run dovecot-2.3.18 , & am deploying Solr search with 'dovecot-fts-solr' I run Solr standalone. When creating a dedicated 'dovecot' core, cp'ing from Dovecot's included solr schemas ls -al /usr/share/doc/dovecot/solr-* -rw-r--r-- 1 root root 12K Dec 3 06:48 /usr/share/doc/dovecot/solr-config-7.7.0.xml -rw-r--r-- 1 root root 2.7K Dec 3 06:48 /usr/share/doc/dovecot/solr-schema-7.7.0.xml -rw-r--r-- 1 root root 2.9K Dec 3 06:48 /usr/share/doc/dovecot/solr-schema.xml is tested only for Solr 7.7.0 https://doc.dovecot.org/configuration_manual/fts/solr/ "The steps described in this page are tested for Solr 7.7.0. For other versions, this these steps may need to be adjusted." which, per solr docs https://solr.apache.org/downloads.html About versions and support Version Description 9.x Current major version for feature releases (STABLE) 8.11.x Previous major version may sometimes receive critical bugfix releases 10 Next major version, yet to be released (UNSTABLE) <8.11 All older versions are End Of Life (EOL) is EOL'd and unsupported. In the dovecot 7.7.0 schema, FastLRUCache/LRUCache are used as the caching class(es), grep class=.*LRU /usr/share/doc/dovecot/solr-config-7.7.0.xml <filterCache class="solr.FastLRUCache" <queryResultCache class="solr.LRUCache" <documentCache class="solr.LRUCache" class="solr.search.LRUCache" For Solr 9, cat CHANGES.txt Upgrade Notes --------------------- ... * SOLR-13817: Deprecate legacy SolrCache implementations. Users are encouraged to transition their configurations to use org.apache.solr.search.CaffeineCache instead. (ab) running solr9 + dovecot-fts-solr search, based on the 7.7.0 schemas, results in errors, failed scan & search. Modifying the config to use CaffeineCache cp solr-config-7.7.0.xml solr-config-9.0.0.xml perl -pi -e '\ s|solr.FastLRUCache|solr.CaffeineCache|g; \ s|solr.LRUCache|solr.CaffeineCache|g; \ s|solr.search.LRUCache|solr.search.CaffeineCache|g;' \ solr-config-9.0.0.xml appears to do the trick. Atm, indexing & search -- both manually triggered, and on delivery receipt to Dovecot store -- is working with no errors (yet). I've not tested exhaustively yet, & don't know if this Cache class change in the schema is both necessary & sufficient for dovecot-fts-solr search use with solr 9.0.0 Given that for Solr "<8.11 All older versions are End Of Life (EOL)" it'd be useful for Dovecot to 'retest' for current, not-EOL'd Solr, and publish/package compatible schemas accordingly.

5 8

decrypt.rb
by Dave 11 Apr '23

11 Apr '23

Per the Dovecot site here: https://wiki.dovecot.org/Plugins/MailCrypt ... the "decrypt.rb" ruby script can be used to decrypt a Dovecot-encrypted message file from the command line. The script sort of runs successfully for me, in the sense that it doesn't error out, but it doesn't show the decrypted message. I've called it like so: decrypt.rb -k <PATH_TO_DOVECOT_KEYFILE> -f ./encrypted_message But when I do it just displays the info below and exits (I've subbed <DATA> tags for the actual data): ------------------[OUTPUT]----------------------- Key(s) (total: 1) - Key type : EC - Key digest: <DATA1> - Peer key : <DATA2> - Encrypted : <DATA3> - Kd hash : <DATA4> ------------------------------------------------------- I've tried specifying an output file as well, per the script's command line options, but the output file is 0 bytes. Does anyone have any suggestions? I *think* I'm using it the way it's intended to be used, but maybe I'm not?! -Dave

5 14

ot: how to t/s TBird problems ?
by Voytek Eymont 22 Mar '23

22 Mar '23

I have a Dovecot/Postfix/MariaDB on a Centos, just have a user ask me: ------------------ I recently upgraded my Thunderbird email client and have experienced problems since. It appears that when Tbird polls for new messages it gets held up waiting for a response from the server I'm using POP port 995. Any ideas as to why I'm having a problem ? ------------------- how to investigate such issue ? CentOS release 6.10 (Final) # dovecot --version 2.3.11.3 (502c39af9) load average on server 0.05/0.01 user log shows like: Oct 12 10:08:50 pop3-login: Info: Login: user=<user(a)tld.com.au>, method=PLAIN, rip=49.111.222.333, lip=103.xxx.yyy.zzz, mpid=17371, TLS, session=<E83xW8rqDPkxw3EW> Oct 12 10:09:34 pop3(user(a)tld.com.au)<17371><E83xW8rqDPkxw3EW>: Info: Disconnected: Logged out top=0/0, retr=0/0, del=0/114194, size=10616009472 Oct 12 10:14:36 imap-login: Info: Login: user=<user(a)tld.com.au>, method=PLAIN, rip=49.111.222.333, lip=103.xxx.yyy.zzz, mpid=17460, TLS, session=<ftiLcMrqR/gxw3EW> Oct 12 10:14:37 imap(user(a)tld.com.au)<17460><ftiLcMrqR/gxw3EW>: Info: Logged out in=152 out=69724 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=1 body_bytes=68628 Oct 12 10:28:27 pop3-login: Info: Login: user=<user(a)tld.com.au>, method=PLAIN, rip=49.111.222.333, lip=103.xxx.yyy.zzz, mpid=17714, TLS, session=<+WsXosrqK/gxw3EW> Oct 12 10:29:16 pop3(user(a)tld.com.au)<17714><+WsXosrqK/gxw3EW>: Info: Disconnected: Logged out top=0/0, retr=1/76174, del=0/114195, size=10616085600 Oct 12 10:32:19 imap-login: Info: Login: user=<user(a)tld.com.au>, method=PLAIN, rip=49.111.222.333, lip=103.xxx.yyy.zzz, mpid=17817, TLS, session=<bZftr8rqq/gxw3EW> Oct 12 10:32:20 imap(user(a)tld.com.au)<17817><bZftr8rqq/gxw3EW>: Info: Logged out in=153 out=135592 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=1 body_bytes=134503 Oct 12 10:45:58 imap-login: Info: Login: user=<user(a)tld.com.au>, method=PLAIN, rip=49.111.222.333, lip=103.xxx.yyy.zzz, mpid=18081, TLS, session=<U3674Mrqzfgxw3EW> Oct 12 10:45:59 imap(user(a)tld.com.au)<18081><U3674Mrqzfgxw3EW>: Info: Logged out in=152 out=24602 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=1 body_bytes=23514 Oct 12 10:48:49 pop3-login: Info: Login: user=<user(a)tld.com.au>, method=PLAIN, rip=49.111.222.333, lip=103.xxx.yyy.zzz, mpid=18135, TLS, session=<y1/r6srqtPsxw3EW> Oct 12 10:49:53 pop3(user(a)tld.com.au)<18135><y1/r6srqtPsxw3EW>: Info: Disconnected: Logged out top=0/0, retr=2/166190, del=0/114197, size=10616251743 Oct 12 10:50:42 imap(user(a)tld.com.au)<3274><cr10yqTqifgxw3EW>: Info: Logged out in=192516 out=5957294 deleted=0 expunged=0 trashed=0 hdr_count=263 hdr_bytes=358656 body_count=126 body_bytes=5110403 Oct 12 10:50:42 imap(user(a)tld.com.au)<3271><hLl0yqTqh/gxw3EW>: Info: Logged out in=78324 out=58677 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0 Voytek

4 3

2.3.14: stale imap-login processes due to bogus user setup tying up process limit
by Volker Stolz 16 Dec '22

16 Dec '22

I just dealt with an interesting Dovecot issue on our small server, and thought I might share it. I also feel that although in the end it was a configuration error, Dovecot should somehow avoid leaving this processes around and hence filling up the process limit quickly. - set up Dovecot IMAP on Debian buster (either with the older 2.3.x Debian package, or 2.3.14 from the dovecot-repo) - config: ... namespace inbox { inbox = yes location = ... default settings ... ... passdb { args = scheme=HMAC-MD5 username_format=%u /etc/dovecot/users driver = passwd-file } protocols = " imap" ... userdb { args = blocking=no driver = passwd } ... - secret sauce: have a user in the passdb that doesn't have a physical account on the system yet (we were migrating to a new machine). The log-file shows successful authentication for that user (after we flipped DNS to point to this new machine), but over time (2-3 times/day) we were left with an increasing number of `imap-login` processes in state `pre-login`, eventually requiring a dovecot restart. Dialling up process_limits didn't seem to help, we'd just get more of these stale processes. After creating the user on the system, the behaviour reverted to normal, no more stale processes. I do not know what error message that user received on their end, but since we announced we were migrating, they probably just ignored it and thought it as part of the transition. Best, Volker (a happy & long Dovecot user)

3 4