- dovecot - dovecot.org

After user disconnect run the custom script
by Alexey Krylov 20 May '24

20 May '24

Sirs, good day. Please, send me the link, where I can find the info about configuring firing script after dovecot client is disconnected. I found post-login scripting. Than's cool, but... I need to fire script a little bit later. May be I try to build crutches... But I wish with all my heart to do this. Thanks to everyone who responded. -- Это сообщение было проверено антивирусным ПО Avast на наличие вирусов. www.avast.com

1 0

Errors after enable add mail_attachment_detection_options
by Ricardo Machini 20 May '24

20 May '24

Hello, I got a lot of fatal errors on differents mailbox after I added the option: mail_attachment_detection_options = add-flags Rocky Linux release 8.9 (Green Obsidian) 2.3.21 (47349e2482) May 16 15:03:00 Panic: imap(user(a)domain.com.br)<1669762><cOqoC5YYQlq63CaF>: file imap-sieve-storage.c: line 317 (imap_sieve_add_mailbox_event): assertion failed: (ismt->src_box == NULL || ismt->src_box == src_box) May 16 15:03:00 Error: imap(user(a)domain.com.br)<1669762><cOqoC5YYQlq63CaF>: Raw backtrace: /usr/lib64/dovecot/libdovecot.so.0(backtrace_append+0x41) [0x7f2c9d8b9761] -> /usr/lib64/dovecot/libdovecot.so.0(backtrace_get+0x22) [0x7f2c9d8b9882] -> /usr/lib64/dovecot/libdovecot.so.0(+0x10bb6b) [0x7f2c9d8c6b6b] -> /usr/lib64/dovecot/libdovecot.so.0(+0x10bc07) [0x7f2c9d8c6c07] -> /usr/lib64/dovecot/libdovecot.so.0(+0x5cec5) [0x7f2c9d817ec5] -> /usr/lib64/dovecot/lib95_imap_sieve_plugin.so(+0x7ebc) [0x7f2c9b011ebc] -> /usr/lib64/dovecot/lib95_imap_sieve_plugin.so(+0x815f) [0x7f2c9b01215f] -> /usr/lib64/dovecot/lib20_zlib_plugin.so(+0x4a37) [0x7f2c9c179a37] -> /usr/lib64/dovecot/libdovecot-storage.so.0(index_mail_free+0x12) [0x7f2c9dc73982] -> /usr/lib64/dovecot/lib95_imap_sieve_plugin.so(+0x71be) [0x7f2c9b0111be] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mail_free+0x1e) [0x7f2c9dbef55e] -> /usr/lib64/dovecot/libdovecot-storage.so.0(+0xf124f) [0x7f2c9dc8624f] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mail_index_transaction_commit_full+0x80) [0x7f2c9dc9f900] -> /usr/lib64/dovecot/libdovecot-storage.so.0(index_transaction_commit+0xf1) [0x7f2c9dc867e1] -> /usr/lib64/dovecot/libdovecot-storage.so.0(+0xccb15) [0x7f2c9dc61b15] -> /usr/lib64/dovecot/lib95_imap_sieve_plugin.so(+0x885d) [0x7f2c9b01285d] -> /usr/lib64/dovecot/lib20_fts_plugin.so(+0x13de4) [0x7f2c9c79fde4] -> /usr/lib64/dovecot/lib15_notify_plugin.so(+0x240d) [0x7f2c9c9cf40d] -> /usr/lib64/dovecot/lib10_quota_plugin.so(+0xfcdf) [0x7f2c9cde5cdf] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mailbox_transaction_commit_get_changes+0x7a) [0x7f2c9dc000ba] -> dovecot/imap [user(a)domain.com.br 186.220.38.133 UID COPY](+0x153c2) [0x559668ce73c2] -> dovecot/imap [user(a)domain.com.br 186.220.38.133 UID COPY](command_exec+0x6c) [0x559668cf559c] -> dovecot/imap [user(a)domain.com.br 186.220.38.133 UID COPY](+0x215af) [0x559668cf35af] -> dovecot/imap [user(a)domain.com.br 186.220.38.133 UID COPY](+0x21661) [0x559668cf3661] -> dovecot/imap [user(a)domain.com.br 186.220.38.133 UID COPY](+0x21882) [0x559668cf3882] -> dovecot/imap [ user(a)domain.com.br 186.220.38.133 UID COPY](client_handle_input+0x1c5) [0x559668cf3a95] -> dovecot/imap [user(a)domain.com.br 186.220.38.133 UID COPY](client_input+0x76) [0x559668cf3f96] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_call_io+0x6d) [0x7f2c9d8dd84d] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x139) [0x7f2c9d8def09] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_handler_run+0x50) [0x7f2c9d8dd8f0] May 16 15:03:00 Fatal: imap(user(a)domain.com.br)<1669762><cOqoC5YYQlq63CaF>: master: service(imap): child 1669762 killed with signal 6 (core dumps disabled - https://dovecot.org/bugreport.html#coredumps) Regards, Ricardo

1 0

Change the default base_dir to /run from ${prefix}/var/run
by Дилян Палаузов 20 May '24

20 May '24

Hello, at 6b1bcf1bad1d7, calling ./configure && make install sets prefix=/usr/local, and thus the default base_dir = /usr/local/var/run/dovecot. Moreover it installs /usr/lib/systemd/system/dovecot.service with [Service] ProtectSystem=full. ProtectSystem=full mounts /usr as read-only, so no files can be written under the default base_dir. The Linux Hierachy Standard says for /usr/local - https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html - directories bin, etc, games, include, lib, man, sbin, share, and src must be in /usr/local. No other directories, except those listed below, may be in /usr/local after first installing a FHS-compliant system. var is not listed below. (“below” means the citation above, not the next paragraph) For /var/run LSH contains - https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#varrunRuntimeVari… - This directory was once intended for system information data describing the system since it was booted. These functions have been moved to /run; this directory exists to ensure compatibility with systems and software using an older version of this specification. In general, the requirements for /run shall also apply to /var/run. It is valid to implement /var/run as a symlink to /run. . For /run LHS mentions “This directory contains system information data describing the system since it was booted. Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process.” The defaults base_dir=/usr/local/var/run/dovecot and ProtectSystem=full present a non-working configuration. • Please consider changing the default (implicit) value of base_dir to /run. • When prefix is /usr/local, then dovecot.service should be installed in /usr/local/lib/systemd/system/. Kind regards Дилян

1 1

example/config misses required section names for passdb{} and userdb{}
by Дилян Палаузов 20 May '24

20 May '24

Hello, I installed Dovecot from git 6b1bcf1bad1d78e, copied /usr/local/share/doc/dovecot/example/config to /usr/local/etc/dovecot and called dovecot -F . The system reported doveconf: Fatal: Error in configuration file /usr/local/etc/dovecot/conf.d/auth-system.conf.ext line 11: passdb { } is missing section name The problem remains, if I delete dovecot-dict-auth.conf.ext dovecot-ldap.conf.ext dovecot-oauth2.conf.ext dovecot-sql.conf.ext conf.d/auth-deny.conf.ext conf.d/auth-ldap.conf.ext conf.d/auth-passwdfile.conf.ext conf.d/auth-static.conf.ext conf.d/auth-dict.conf.ext conf.d/auth-master.conf.ext conf.d/auth-sql.conf.ext thus leaving passdb {} and userdb {} defined on a single place. Indeed, auth-system.conf.ext contains the sections passdb and userdb without the optional name, as described at https://doc.dovecot.org/configuration_manual/config_file/#sections . The problem report is that the example configuration does not contain for sections userdb and passdb a section name, and at the same time the as optional described section name is mandatory in Dovecot on these places. Kind regards Dilyan

2 1

Dovecot logging to files causes issues
by Richard Rosner 20 May '24

20 May '24

I have a mailing server setup based on Debian Stable that uses postfix (v3.7.10) for SMTP and dovecot (v2.3.19.1 (9b53102964)) for IMAP. I now wanted to set dovecot to not write to syslog, but to dedicated files in /var/log/dovecot. While everything indicates that this happens successfully as the log files gain in size, I also get lots of these errors: May 13 20:55:37 mail postfix/local[2824184]: 95BCF1000A9: to=<user(a)domain.de>, relay=local, delay=3.2, delays=1.9/0.29/0/1.1, dsn=4.3.0, status=deferred (temporary failure. Command output: lda(user): Error: net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied Can't open log file /var/log/dovecot/error.log: Permission denied ) If it would only log the complaints I wouldn't worry, but as long as I don't revert the changes in dovecot's config, mail receiving is at least vastly delayed, most likely stuck alltogether. So how am I supposed to set these settings? I've chainged these settings in /etc/dovecot/conf.d/10-logging.conf: log_path = /var/log/dovecot/error.log debug_log_path = /var/log/dovecot/debug.log log_debug = category=error The whole directory /var/log/dovecot is owned by dovecot:dovecot, permissions on debug.log, error.log and info.log are 644. Best Richard

5 10

Re: Failing to archive many messages
by Francis Augusto Medeiros-Logeay 18 May '24

18 May '24

Today I realized that it was indeed the sa-learn that is slowing down my Archiving. I added an «&» on the end of the line that calls the sa-learn (called by the report-ham.sieve script): exec /usr/bin/sa-learn -u ${1} --ham & Does anyone thing this is a bad idea? I noticed that archiving got way faster this way… Best, Francis > On 9 May 2024, at 23:09, dovecot-request(a)dovecot.org wrote: > >> On 9 May 2024, at 19:45, dovecot-request(a)dovecot.org <mailto:dovecot-request@dovecot.org> wrote: >> >> Francis Augusto Medeiros-Logeay via dovecot skrev den 2024-05-09 12:29: >> >>>> If you want to analyze emails, why not do it with scheduled crons >>>> after they are archived? >> >> maybe ask for skip older then one day in here >> https://github.com/isbg/isbg/tree/master >> >> while roundcube just set the needed flag for retest ? >> >>> wouldn't it reanalyze all archived messages anyway? >> >> sometimes email is ham at recpt stage, while its spam later on test, >> this is why isbg is made imho :) > > > I see. > > But I wonder if there is something wrong with what I already have. It worked fine for years, and it works fine for most of my users. I tested with a few accounts, and Archving (with its sa-learn script) works blazingly fast. But with one user - happens to be mine - it is super slow when archiving, most likely due the sa-learn. > > Best, > > Francis

2 2

Sieve extprograms pipe :try cancels implicit keep
by Sebastiaan Hoogeveen 17 May '24

17 May '24

Hi, When using the :try tag on the pipe command in the sieve_extprograms plugin Sieve’s implicit keep is cancelled if the executed command fails. The specification on https://raw.githubusercontent.com/dovecot/pigeonhole/master/doc/rfc/spec-bo… states: “When the ":try" tag is specified, the "pipe" instruction will attempt execution of the external program, but failure will not cause the whole Sieve script execution to fail with an error. Instead, the Sieve processing continues as if the "pipe" action was never triggered." However, using the :try tag marks the pip command as successful even if it fails and because pipe is a disposition-type action the implicit keep is cancelled, resulting in the piped message being discarded. If this is the intended behaviour then I would suggest amending the text of the specification to: “When the ":try" tag is specified, the "pipe" instruction will attempt execution of the external program, but failure will not cause the whole Sieve script execution to fail with an error. Instead, the Sieve processing continues as if the "pipe" action was executed successfully and cancel implicit keep.” If this is not the intended behaviour then please consider this a bug report, with my apologies for not adding a patch (it seems to be a bit more complex than just changing the return value of act_pipe_commit). Kind regards, -- Sebastiaan Hoogeveen NederHost https://www.nederhost.nl/ KvK: 34099781

1 0

MySQL connection with SSL
by Gandalf Corvotempesta 16 May '24

16 May '24

Hi all is possible to tell dovecot to use a mysql connection with SSL ? My new remote mysql server only allows ssl connections

6 10

Pigeonhole Sieve only runs scripts if in users' home directories, or if Sieve is purposely broken
by Douglas Morse 15 May '24

15 May '24

Hi, Dovecot version is 2.3.19.1 (9b53102964) running on fully up-to-date Debian 12 (Bookworm) operating system. For the life of me I cannot figure out how to get sieve scripts working correctly in a central directory location. Calling them from users’ home directories works fine (as described below). (Note: This system has recently been migrated from Cyrus IMAP, so some of the directories for a central location are very similar to what would find in a standard Cyrus IMAP installation.) If I set `sieve` to its default value of `file:~/sieve;active=~/.dovecot.sieve` in `conf.d/90-sieve.conf`, sieve works as expected. I have a file `~/sieve/default.sieve` and, as per documentation, I make a symbolic link `~/.dovecot.sieve` that points to that file. The sieve script runs, and I see a `default.svbin` either created or updated in the ~/sieve directories as emails arrive. Setting `sieve` to `file:~/lib/sieve;active=~/.dovecot.sieve` also works as expected. So this verifies I can change the directory where sieve scripts are stored. However, if I then set `sieve` to `file:/var/spool/dovecot/home/%1n/user/%n/sieve;active=file:/var/spool/dovecot/home/%1n/user/%n/.dovecot.sieve`, again a `default.sieve` in each of these user’s centralized `sieve` directories, sieve scripts silently fail to run. No messages of any kind found in any log files. So, with the same exact same configuration as one that is the default and as proven to working, with the single exception of changing the top-level directory (TLD) for the scripts, results in silent failure. Why? What I find particularly odd is that if I keep `sieve` set to this central directory location (i.e., no config changes), and `mv sieve/default.sieve sieve.tmp; rmdir sieve; mv sieve.tmp`, that is, have a *file* called `sieve` where the setting `sieve` points to (which, per docs and experience, should be a *directory*), the users’ sieve scripts *do* run, but with a warning along the lines of `Warning: sieve: file storage: Explicitly specified active script path `file:/var/spool/dovecot/home/m/user/morse/.dovecot.sieve' is ignored; storage path `/var/spool/dovecot/home/m/user/morse/sieve' is not a directory`. In the docs I see that `sieve` used to refer to a file (PidgeonHole Sieve v.0.31 or prior, I believe), and there is mention of a a `sieve_dir` setting (which I have *never* set or used). So my guess is that sieve working in this centralized TLD with `sieve` as a file rather than directory is due to support for some deprecated config / functionality. I have fiddle around with this for some hours, including setting and not setting `mail_home` to the central directory location (i.e., `mail_home` in `conf.d/10-mail.conf` set to the same value as `sieve` in `conf.d/90-sieve.conf`),to no avail. No matter what I do, I cannot get sieve scripts to run in a centralized directory location as they do under `/home`. The only exception is as just described in the preceding paragraph. But the solution only allows a user to have a single sieve script, and I imagine `managesieve` will not work properly is sieve is set up as described in the preceding paragraph. What am I missing or doing incorrectly? Any and all assistance most appreciated. Doug

2 3

lda-dupes-file not updated, when user over quota and sieve vacation enabled
by Christian Rößner 14 May '24

14 May '24

Hi, we have encountered an interesting behavior with users that have their mailboxes over quota while having sieve-vacation enabled. We do a temp fail, if a mailbox is over quota. Problem: -------- If a remote sender sends an email to such a user (over quota + vacation), Dovecot directly creates a response message and sends it back to the sender. So far so good. At the same time the original email cannot be stored in the users INBOX, which leads to a temp fail action. Now the email remains in a queue and whenever the queue manager tries to deliver the email again, the behavior starts again. Send vacation response and temp fail, until either the queue life time exceeds or the user has cleaned up his/her mailbox and the message can be stored. For the remote sender it means getting lots of vacation emails from the same recipient. For each retry one vacation message. Tracing: -------- We dig a little bit deeper and turned on logging to see what happens. Because the email cannot be put into the users INBOX, it keeps in a failure state. And because of this, the dupes-file is not updated for this particular sender. We are not sure, if this is a wanted behavior or not. But for a sender, it is really annoying to receive vacation messages on and on. Solution: --------- Unfortunately we could not find any settings to change this. So I come here and ask for your kindly help. At the moment of this writing I can not provide a doveconf -n output, but I hope you trust me that we have not done too many things wrong ;-) Christian Rößner -- Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Karl-Bröger-Str. 10, 36304 Alsfeld Fax: +49 6631 78823409, Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5

1 0