- dovecot - dovecot.org

Bug report: Pigeonhole Sieve delivery plugin fails to load in Dovecot 2.4 — undefined symbol mail_deliver_ctx_get_log_var_expand_table
by Developer Sub N Grill 08 Aug '26

08 Aug '26

Hello Dovecot Team, I am reporting what appears to be a packaging/ABI issue affecting the Pigeonhole Sieve delivery plugin in Dovecot 2.4. I have performed extensive diagnostics and would appreciate any guidance. Environment Operating System: Debian 13 (Trixie), amd64 Repository: Official Dovecot CE repository (repo.dovecot.org/ce-2.4-latest/debian/trixie) Installed package version:2:2.4.4-5+debian13 Installed packages: dovecot-core dovecot-sieve dovecot-lmtpd dovecot-imapd dovecot-pop3d dovecot-managesieved dovecot-pgsql All packages are installed at the exact same version. Problem Description When enabling the Sieve delivery plugin with: mail_plugins { sieve = yes } Dovecot fails to load the plugin with the following error: sievec: Fatal: Couldn't load required plugin /usr/lib/dovecot/modules/lib90_sieve_plugin.so: dlopen() failed: /usr/lib/dovecot/modules/lib90_sieve_plugin.so: undefined symbol: mail_deliver_ctx_get_log_var_expand_table As a result, message delivery fails entirely whenever the Sieve delivery plugin is enabled. Disabling the plugin restores normal mail delivery. Diagnostics Performed1. Package verification All installed packages are version 2:2.4.4-5+debian13 from the official Dovecot CE repository. There are no mixed package versions. 2. Symbol verification I searched for the symbol mail_deliver_ctx_get_log_var_expand_table throughout the Dovecot libraries. Results: nm -D on libdovecot-lda.so.0.0.0 → symbol not found readelf -sW on libdovecot-lda.so.0.0.0 → symbol not found Recursive search across all .so files under: /usr/lib/dovecot/ /usr/lib/x86_64-linux-gnu/dovecot/ → symbol not exported anywhere The symbol string exists inside both: lib90_sieve_plugin.so libdovecot-lda.so.0.0.0 but only as plain text (visible via grep), never as an exported ELF symbol. 3. Dependency verification ldd on lib90_sieve_plugin.so shows dependencies on: libdovecot-sieve.so.0 libdovecot-storage.so.0 libdovecot.so.0 It does not directly link against libdovecot-lda.so. 4. Standalone sievec Compiling a Sieve script works correctly: sievec /tmp/test.sieve Exit status is 0 as long as no configuration enables the Sieve delivery plugin. The failure only occurs once: mail_plugins { sieve = yes } is present in the configuration. Reproduced on a Clean Debian 13 Installation To rule out configuration or upgrade issues, I reproduced the exact same problem on a completely clean debian:13-slim container. I installed only the Debian stable packages: apt-get install dovecot-core dovecot-sieve dovecot-lmtpd (version 1:2.4.1+dfsg1-6+deb13u6) Using the same production configuration with: mail_plugins { sieve = yes } produces the exact same error: sievec: Fatal: Couldn't load required plugin ... undefined symbol: mail_deliver_ctx_get_log_var_expand_table This indicates the problem is not caused by: mixed package versions an upgrade issue local modifications custom configuration The issue reproduces consistently on both: Dovecot CE 2.4.4 Debian 13's packaged Dovecot 2.4.1 Questions Is mail_deliver_ctx_get_log_var_expand_table a new internal function that should be exported in Dovecot 2.4? Was there an ABI change affecting the Pigeonhole plugin? Is this a known issue in the Dovecot 2.4.x packages? If so, is a fix planned (for example, in 2.4.5)? Is there any recommended workaround for using Sieve during message delivery (e.g. moving spam to the Junk folder) while this issue is unresolved? I am trying to use the new Dovecot 2.4 configuration syntax (sieve_script_type, sieve_script_precedence, and sieve_script_path), since sieve_before and the plugin {} block were removed in 2.4. Thank you for your time. I would be happy to provide additional logs, the complete doveconf -n output, or a core dump if that would be helpful. Best regards, Miguel A Morales Server: Debian 13 (amd64) Dovecot: 2.4.4-5+debian13 Hello Dovecot Team, I am reporting what appears to be a packaging/ABI issue affecting the Pigeonhole Sieve delivery plugin in Dovecot 2.4. I have performed extensive diagnostics and would appreciate any guidance. Environment o Operating System: Debian 13 (Trixie), amd64 o Repository: Official Dovecot CE repository (repo.dovecot.org/ce-2.4-latest/debian/trixie) o Installed package version: 2:2.4.4-5+debian13 Installed packages: o dovecot-core o dovecot-sieve o dovecot-lmtpd o dovecot-imapd o dovecot-pop3d o dovecot-managesieved o dovecot-pgsql All packages are installed at the exact same version. Problem Description When enabling the Sieve delivery plugin with: mail_plugins { sieve = yes } Dovecot fails to load the plugin with the following error: sievec: Fatal: Couldn't load required plugin /usr/lib/dovecot/modules/lib90_sieve_plugin.so: dlopen() failed: /usr/lib/dovecot/modules/lib90_sieve_plugin.so: undefined symbol: mail_deliver_ctx_get_log_var_expand_table As a result, message delivery fails entirely whenever the Sieve delivery plugin is enabled. Disabling the plugin restores normal mail delivery. Diagnostics Performed 1. Package verification All installed packages are version 2:2.4.4-5+debian13 from the official Dovecot CE repository. There are no mixed package versions. 2. Symbol verification I searched for the symbol mail_deliver_ctx_get_log_var_expand_table throughout the Dovecot libraries. Results: o nm -D on libdovecot-lda.so.0.0.0 -> symbol not found o readelf -sW on libdovecot-lda.so.0.0.0 -> symbol not found o Recursive search across all .so files under: o /usr/lib/dovecot/ o /usr/lib/x86_64-linux-gnu/dovecot/ -> symbol not exported anywhere o The symbol string exists inside both: o lib90_sieve_plugin.so o libdovecot-lda.so.0.0.0 but only as plain text (visible via grep), never as an exported ELF symbol. 3. Dependency verification ldd on lib90_sieve_plugin.so shows dependencies on: o libdovecot-sieve.so.0 o libdovecot-storage.so.0 o libdovecot.so.0 It does not directly link against libdovecot-lda.so. 4. Standalone sievec Compiling a Sieve script works correctly: sievec /tmp/test.sieve Exit status is 0 as long as no configuration enables the Sieve delivery plugin. The failure only occurs once: mail_plugins { sieve = yes } is present in the configuration. Reproduced on a Clean Debian 13 Installation To rule out configuration or upgrade issues, I reproduced the exact same problem on a completely clean debian:13-slim container. I installed only the Debian stable packages: apt-get install dovecot-core dovecot-sieve dovecot-lmtpd (version 1:2.4.1+dfsg1-6+deb13u6) Using the same production configuration with: mail_plugins { sieve = yes } produces the exact same error: sievec: Fatal: Couldn't load required plugin ... undefined symbol: mail_deliver_ctx_get_log_var_expand_table This indicates the problem is not caused by: o mixed package versions o an upgrade issue o local modifications o custom configuration The issue reproduces consistently on both: o Dovecot CE 2.4.4 o Debian 13's packaged Dovecot 2.4.1 Questions 1. Is mail_deliver_ctx_get_log_var_expand_table a new internal function that should be exported in Dovecot 2.4? Was there an ABI change affecting the Pigeonhole plugin? 2. Is this a known issue in the Dovecot 2.4.x packages? If so, is a fix planned (for example, in 2.4.5)? 3. Is there any recommended workaround for using Sieve during message delivery (e.g. moving spam to the Junk folder) while this issue is unresolved? I am trying to use the new Dovecot 2.4 configuration syntax (sieve_script_type, sieve_script_precedence, and sieve_script_path), since sieve_before and the plugin {} block were removed in 2.4. Thank you for your time. I would be happy to provide additional logs, the complete doveconf -n output, or a core dump if that would be helpful. Best regards, Miguel A Morales Server: Debian 13 (amd64) Dovecot: 2.4.4-5+debian13

3 2

Can't connect to MySQL without SSL
by dovecot＠fagschlunger.at 08 Aug '26

08 Aug '26

Hi! I try to migrate from dovecot 2.3 to dovecot CE 2.4, but within a docker container. But I always get the following error from Dovecot CE: Error: auth: mysql(host.docker.internal): Connect failed to database (foobar): TLS/SSL error: self-signed certificate in certificate chain - waiting for 1 seconds before retry This is how I configured the mysql connection: mysql host.docker.internal { host = host.docker.internal port = 3306 user = ... password = ... dbname = foobar ssl = no } So MySQL runs on the host machine directly, not in a container - therefore I'm using "host.docker.internal" as an host. But I don't need SQL encryption, since both MySQL and Dovecot run on the same machine. So why the heck does it look like, Dovecot is trying to connect using SSL? Best regards, Billie

5 7

Re: [patch] proposed patch for managing timeouts on doveadm iteration with -A
by MK 07 Aug '26

07 Aug '26

>On 26. Jul 2026, at 0.17, John Fawcett via dovecot <dovecot(a)dovecot.org> wrote: >> >> Hi >> >> having further investigated the timeouts mentioned in the previous thread, I am submitting this patch as a potential solution. >> >> Basically with -A doveadm parameter, the 155 second timeout is applied to the whole end to end transaction. With -F parameter the 155 second >timeout is applied to each single user operation. Changing the logic of -A to follow -F looks a bit invasive. So this patch does more or less the >same thing, i.e. giving each user operation 155 seconds timeout, done in a different way. Whenever another username is returned, the timeout is >reset. >> >> PS I got help from Claude on this. > >Some further improvements via Fable - does this still fix your problems? > >commit 9deefd88b37d4e9bfecdf6bd1c9fa8a3f9d6b100 >Author: Timo Sirainen <timo.sirainen(a)open-xchange.com> >Date: Wed Aug 5 21:33:42 2026 +0000 > > lib-auth-client: Extend LIST request timeout whenever a username is returned > > The auth lookup timeout (155 seconds by default) was applied to the whole > LIST request, i.e. the entire user enumeration. With large installations > listing all users can easily take longer than that, causing e.g. > doveadm -A to fail with "Auth server request timed out". > > Reset the request's timeout whenever another username is returned. This > turns the timeout into a "no progress for N seconds" stall detector, > matching how independent short-lived per-user requests (e.g. as used when > iterating -F user files) never accumulate a single deadline across the > whole run. > > The timeout handling assumes that requests expire in creation order, so > extending is only allowed while the request is alone on its connection. > This is always the case for LIST, which is asserted at init already. Timo can you say in which upcoming version this patch will be included? Oliver

1 0

Detection of HAVE_MYSQL_SSL_VERIFY_SERVER_CERT is broken
by Tomas Volf 31 Jul '26

31 Jul '26

Hello, detection of HAVE_MYSQL_SSL_VERIFY_SERVER_CERT is currently broken, and the macro is never defined. The test program fails, but for incorrect reason. --8<---------------cut here---------------start------------->8--- conftest.c:140:20: error: expected declaration specifiers or '...' before ',' token 140 | _au_m4_changequote(,) | ^ conftest.c:140:21: error: expected declaration specifiers or '...' before ')' token 140 | _au_m4_changequote(,) | ^ In file included from /gnu/store/6lmd3apzkmhwzj3yn0inyj484m9qml6y-mariadb-connector-c-3.4.5/include/mariadb/mysql.h:35, from conftest.c:141: /gnu/store/7iwcvd0gjrfq6bj7zvf3r59baw6vib5a-gcc-14.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/14.3.0/include/stdarg.h:103:9: error: unknown type name '__gnuc_va_list' 103 | typedef __gnuc_va_list va_list; | ^~~~~~~~~~~~~~ --8<---------------cut here---------------end--------------->8--- Fix is to delete the only occurrence of _au_m4_changequote([,]) in the m4/want_mysql.m4 file. However, that will reveal a compilation error here: --8<---------------cut here---------------start------------->8--- #ifdef HAVE_MYSQL_SSL_VERIFY_SERVER_CERT int ssl_verify_server_cert = ssl_set->ssl_client_require_valid_cert ? 1 : 0; mysql_options(db->mysql, MYSQL_OPT_SSL_VERIFY_SERVER_CERT, (void *)&ssl_verify_server_cert); #endif #else --8<---------------cut here---------------end--------------->8--- Variable `ssl_set' does not exist and should be `db->ssl_set'. Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

1 0

Confusion about mailbox_list_layout=fs
by Roland Hieber 27 Jul '26

27 Jul '26

Hi, I am trying to understand how 'mailbox_list_layout = fs' is working when I have 'mail_driver = Maildir' (on Dovecot 2.4.1-4 from Debian trixie). If I look at 'doveconf -a', I see that 'mailbox_list_layout = fs' is already the default, however, the Maildirs from my freshly created test user are still created on disk in the format .INBOX.subfolder instead of INBOX/subfolder, which is in conflict with what the documentation says at <https://doc.dovecot.org/2.4.3/core/config/mailbox_formats/maildir.html#dire…>. However, if I set 'mailbox_list_layout = fs' *explicitely* in the global part of /etc/dovecot/conf.d/10-mail.conf, then delete all files and folders in the mail home of my test user, reload dovecot, send a test mail, and create a new subfolder for my test user in Thunderbird, the new subfolder gets created on disk as INBOX/subfolder, just like I expect. The behaviour is consistently reproducable in both directions: I also get maildirs with dots again after I delete mailbox_list_layout from 10-mail.conf, reload dovecot, and clear the mail home of my test user. What is going on here…? I don't see any change in 'doveconf -a' between these two use cases (the output is literally identical, and it's both showing 'mailbox_list_layout = fs'), and obviously it's missing from 'doveconf -n' because it's the default. I also found out that it is possible to override this setting per user by using the 'userdb_mailbox_list_layout' option in the extra fields of the userdb, but I'm not setting any extra fields there for my test user. Output of 'doveconf -n' (redacted where necessary) is attached. Regards, - Roland -- Roland Hieber, Pengutronix e.K. | rhi(a)pengutronix.de | Steuerwalder Str. 21 | https://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

2 2

Doveadm and iterate query
by Bogusław Juza 25 Jul '26

25 Jul '26

Hi! I have a problem with Dovecot on Debian 13: Dovecot 2.4.1, Debian Trixie > doveadm mailbox path -A INBOX >/dev/null doveadm(email@domain): Error: auth-master: userdb list: User listing returned failure doveadm: Error: cmd mailbox path: Failed to iterate through some users userdb sql { iterate_query = SELECT `email` AS `user` FROM `users` } In syslog file: dovecot: auth: Error: auth-worker: Aborted LIST request for *: Shutting down I have over 30k users in sql DB, doveadm with -A option is dying few second after start with this error, printing about 10% of users. I need much more time (FE command "doveadm expunge -A mailbox Spam savedbefore 3w" could run over 30 minutes). What I'm doing wrong? Bogusław Juza

5 12

Reporting a Patch needed: Fix-anvil-busy-loop-on-EPOLLHUP-when-a-multiplex-cha.patch
by David Lanning 24 Jul '26

24 Jul '26

The attached patch spec is what we had to deploy to cover the matter. The attached patch spec is what we had to deploy to cover the matter.

2 1

Strange characters in log file
by Doug Hardie 21 Jul '26

21 Jul '26

I am occasionally finding some strange characters in the log file. I have captured on entry that vi cannot handle. It simply won't go past this record. I suspect the issue is around 0347 in the record below. Any ideas how to prevent this from happening as it makes it difficult to find specific records in the log. vi is unable to delete the line with this issue. mail# head -1 imaplog.test | od -t x1c 0000000 4a 75 6c 20 31 37 20 30 32 3a 33 34 3a 35 35 20 J u l 1 7 0 2 : 3 4 : 5 5 0000020 6d 61 69 6c 20 64 6f 76 65 63 6f 74 5b 35 32 39 m a i l d o v e c o t [ 5 2 9 0000040 30 5d 3a 20 69 6d 61 70 28 64 6f 75 67 29 5b 31 0 ] : i m a p ( d o u g ) [ 1 0000060 30 2e 30 2e 31 2e 32 33 32 5d 3c 4e 74 79 78 52 0 . 0 . 1 . 2 3 2 ] < N t y x R 0000100 4d 74 57 4e 64 38 4b 41 41 48 6f 3e 3a 20 64 65 M t W N d 8 K A A H o > : d e 0000120 6c 65 74 65 3a 20 62 6f 78 3d 44 65 6c 65 74 65 l e t e : b o x = D e l e t e 0000140 64 20 4d 65 73 73 61 67 65 73 2c 20 75 69 64 3d d M e s s a g e s , u i d = 0000160 35 38 32 32 31 33 2c 20 6d 73 67 69 64 3d 3c 39 5 8 2 2 1 3 , m s g i d = < 9 0000200 31 30 35 30 36 39 31 2e 31 34 37 36 39 34 36 2e 1 0 5 0 6 9 1 . 1 4 7 6 9 4 6 . 0000220 31 37 38 33 35 38 37 39 33 35 37 36 36 40 6d 61 1 7 8 3 5 8 7 9 3 5 7 6 6 @ m a 0000240 72 6b 65 74 6f 2d 70 6c 61 74 66 6f 72 6d 2d 2d r k e t o - p l a t f o r m - - 0000260 65 6d 61 69 6c 2d 73 65 6e 64 65 72 2d 70 72 6f e m a i l - s e n d e r - p r o 0000300 64 2d 62 61 74 63 68 2d 63 6c 75 2e 2e 2e 2c 20 d - b a t c h - c l u . . . , 0000320 73 69 7a 65 3d 35 35 39 39 30 2c 20 66 72 6f 6d s i z e = 5 5 9 9 0 , f r o m 0000340 3d 57 4f 52 4c 44 e2 4d 2d 5e 40 4d 2d 5e 59 73 = W O R L D 342 M - ^ @ M - ^ Y s 0000360 20 54 69 6d 20 4c 61 6d 65 72 20 3c 65 64 69 74 T i m L a m e r < e d i t 0000400 6f 72 40 77 6e 67 2e 6f 72 67 3e 0a o r @ w n g . o r g > \n 0000414 -- Doug I am occasionally finding some strange characters in the log file. I have captured on entry that vi cannot handle. It simply won't go past this record. I suspect the issue is around 0347 in the record below. Any ideas how to prevent this from happening as it makes it difficult to find specific records in the log. vi is unable to delete the line with this issue. mail# head -1 imaplog.test | od -t x1c 0000000 4a 75 6c 20 31 37 20 30 32 3a 33 34 3a 35 35 20 J u l 1 7 0 2 : 3 4 : 5 5 0000020 6d 61 69 6c 20 64 6f 76 65 63 6f 74 5b 35 32 39 m a i l d o v e c o t [ 5 2 9 0000040 30 5d 3a 20 69 6d 61 70 28 64 6f 75 67 29 5b 31 0 ] : i m a p ( d o u g ) [ 1 0000060 30 2e 30 2e 31 2e 32 33 32 5d 3c 4e 74 79 78 52 0 . 0 . 1 . 2 3 2 ] < N t y x R 0000100 4d 74 57 4e 64 38 4b 41 41 48 6f 3e 3a 20 64 65 M t W N d 8 K A A H o > : d e 0000120 6c 65 74 65 3a 20 62 6f 78 3d 44 65 6c 65 74 65 l e t e : b o x = D e l e t e 0000140 64 20 4d 65 73 73 61 67 65 73 2c 20 75 69 64 3d d M e s s a g e s , u i d = 0000160 35 38 32 32 31 33 2c 20 6d 73 67 69 64 3d 3c 39 5 8 2 2 1 3 , m s g i d = < 9 0000200 31 30 35 30 36 39 31 2e 31 34 37 36 39 34 36 2e 1 0 5 0 6 9 1 . 1 4 7 6 9 4 6 . 0000220 31 37 38 33 35 38 37 39 33 35 37 36 36 40 6d 61 1 7 8 3 5 8 7 9 3 5 7 6 6 @ m a 0000240 72 6b 65 74 6f 2d 70 6c 61 74 66 6f 72 6d 2d 2d r k e t o - p l a t f o r m - - 0000260 65 6d 61 69 6c 2d 73 65 6e 64 65 72 2d 70 72 6f e m a i l - s e n d e r - p r o 0000300 64 2d 62 61 74 63 68 2d 63 6c 75 2e 2e 2e 2c 20 d - b a t c h - c l u . . . , 0000320 73 69 7a 65 3d 35 35 39 39 30 2c 20 66 72 6f 6d s i z e = 5 5 9 9 0 , f r o m 0000340 3d 57 4f 52 4c 44 e2 4d 2d 5e 40 4d 2d 5e 59 73 = W O R L D 342 M - ^ @ M - ^ Y s 0000360 20 54 69 6d 20 4c 61 6d 65 72 20 3c 65 64 69 74 T i m L a m e r < e d i t 0000400 6f 72 40 77 6e 67 2e 6f 72 67 3e 0a o r @ w n g . o r g > \n 0000414 -- Doug

2 4

AW: AW: [EXT] Re: doveadm backup / purge problems since migration from 2.3 to 2.4
by MK 21 Jul '26

21 Jul '26

>>> On 09/07/2026 13:30 EEST MK <dovecot-ml(a)mk.de> wrote: >>> >>> >>> >> On 09/07/2026 11:58 EEST MK via dovecot <dovecot(a)dovecot.org>> wrote: >>> >> >>> >> >>> >> Hi everyone, >>> >> >>> >> I have a two-server setup where all user data from the actively used server is periodically transferred to the second server using "doveadm >backup". For this, I currently use a script that caches a list of all users (containing only the usernames) via "doveadm user '*' " and then >executes the command "doveadm backup -u [username] tcp:1.2.3.4" (target host) for each user. I use a similarly structured script for a daily >"doveadm purge", where a purge is performed per user instead of a backup. >>> >> >>> >> Under version 2.3, I always ran both commands using the "-A" flag (doveadm purge -A and doveadm backup -A tcp:1.2.3.4). Since migrating >from Dovecot 2.3 to 2.4, this no longer works. When running the purge, the process always aborts after a certain number of users with the >following error message: >>> >> >>> >> doveadm(john(a)doe.de): Error: auth-master: userdb list: User listing returned failure >>> >> >>> >>> >>> >Try adding >>> > >>> >log_debug=category=auth >>> > >>> >and see if it can shed light one this. >>> >>> I'll add it to the config and get back next time the problem occurs. >>> >>> >> It's not the same User allways but after nearly the same time or amount of users the script has processed. >>> >> Since I couldn't identify the exact cause of the error and suspect it might be related to changes in how the SQL iterate query is >integrated in the 2.4 configuration (I use MySQL as the backend) I switched to the script described above. >>> >> >>> >> Then since is used the new script I have a non-reproducible issue. After the initial data transfer (when the target is still empty) the >amount of data is equal to the source. Then after one of the next transfers the data is twice as high. It is random as to which subsequent >transfer triggers this. When comparing the quotas on the source and target server, the output is identical on both. Even running `quota recalc` >makes no difference. If I check the user directories, I can see that the `storage` folder contains nearly double the number of files and used >disk space per user. >>> >> >>> >> My second problem is that when I run the purge script on the second server (target), it sometimes deletes all emails for all users, also >non-reproducible. Afterwards, all files under "storage" are gone, and the quota shows 0 emails. I did not have this issue with the exactly same >purge script on the first server which is the source for the backup. >>> >> >>> >>> >What does your purge script do? >>> >>> I have attached it so you can take a look. >>> Is it a known issue that the -A option doesn't work as well as it did in 2.3? >>> >>> >> >>And you are sure it's the purge doing it, and not running doveadm sync? > >If you mean delete everything, yes. There is nothing else running there. No other scripts, nothing other is accessing Dovecot. >A few times I have seen it live and the other times I can see in my logging that when the script starts the space is sinking and sinking near to >zero until the script ends. I'm logging the disk space every minute. > >It’s clear that these are two different problems right? (purge deletes everything and backup writes to mutch data) > >What do I have to search for in the logfiles if the problem oncours? What is interesting for you? The debug makes realy mutch log entries. Update to this. Since I activated the debugging on 09/07/2026 the problem did not occur again, really strange. I can't explain it sice I haven't changed anything other than enabling debugging. Oliver

1 0

Sieve vnd.dovecot.config extension does not work when mail is delivered to lmtp inet_listener but works when delivered to lmtp unix_listener
by DK 20 Jul '26

20 Jul '26

Hello. I have a strange problem with sieve scripts vnd.dovecot.config extension processing on newest dovecot 2.3 and 2.4. When I deliver mail via lmtp unix_listener sieve script can get sieve_env_* variable with no problem. However when I deliver mail via lmtp inet_listener sieve script can not get the same sieve_env_* variable. I deliver mails from postfix to lmtp inet_listener directly (not via haproxy). The same postfix is used when testing lmtp unix_listener mail delivery which works. Any clues what could be the cause of such problem? DK

2 3