Re: undocumented changed behavior of 2.4.3 (possible bug report)

Aki Tuomi via dovecot <[email protected]> Tue, 21 Apr 2026 14:46:49 +0300 (EEST)
Newsgroups gmane.mail.imap.dovecot
Message-ID <696798436.6782.1776772009243@appsuite-pro-sync-core-mw-groupware-0.appsuite-pro-sync-core-mw-hazelcast-headless.appsuite-dev.svc.cluster.local>
For one, it's documented:

https://doc.dovecot.org/2.4.3/core/config/auth/databases/ldap.html#ldap_base

this is to avoid LDAP injection attack on authentication, CVE-2026-27860

But you're right, it should've been in the 2.4.x page. 

The matches change we have to check, matching was changed due to certain patterns causing assert crashes.

Aki

> On 21/04/2026 14:37 EEST Patrick Cernko via dovecot <[email protected]> wrote:
> 
>  
> Hello Dovecot-Devs, hello list,
> 
> while upgrading my Dovecot 2.4.2 setup to 2.4.3 I observed two instances of changed 
> behavior. I could not find notes about those issues in the corresponding 
> documentation (https://doc.dovecot.org/2.4.3/installation/upgrade/2.4-to-2.4.x.html) 
> or release notes:
> 
> 1. I had to change
> 
> userdb_ldap_iterate_filter = 
> (&(objectClass=posixAccount)%{if(protocol,"eq","pop3","(istIsMemberOf=POP3-users)","")})
> to
> userdb_ldap_iterate_filter = 
> (&(objectClass=posixAccount)%{if(protocol,"eq","pop3","(istIsMemberOf=POP3-users)","")|safe)
> 
> otherwise the characters '()=' in the "true"-case of the condition got somehow 
> "quoted" with escaped ASCII codes, which led to a broken LDAP filter string.
> 
> Maybe you could add some documentation (in "Upgrading" as well as "Settings 
> Variables") about that?
> 
> 
> 2. The behavior of sieve matches using ":matches" has changed:
> 
> Example email (only the relevant header):
> List-Id: Dovecot Mailing List <dovecot.dovecot.org>
> 
> Example Sieve script:
> if header :matches "List-Id" "*<dovecot*.dovecot.org>" {
>    fileinto "dovecot";
> }
> 
> In 2.4.2 (and earlier) the example email matched the condition and got stored in the 
> dovecot folder, while in 2.4.3 the condition does NOT match. As a workaround I added 
> a '*' at the end of the match ("*<dovecot*.dovecot.org>*") to get my mails stored 
> correctly again.
> 
> Is this changed behavior for Sieve intentional or a bug? In case of a bug, could you 
> please provide a fix?
> 
> In case of intentional behavior:
> * Could you please explain the intention? Why was it necessary?
> * What would be the correct fix for the sieve example to match a List-Id header that 
> ENDS WITH ".dovecot.org>"?
> * I assume, that other users on my servers will run into similar problems once I 
> upgrade their servers. Is it possible to detect such problematic matches in Sieve 
> scripts? E.g. "all matches without a trailing '*' are affected", ...
> This would give me a chance, to inform my users or even fix their scripts in advance.
> 
> Best regards,
> -- 
> Patrick Cernko <[email protected]> +49 681 9325 5815
> Joint Scientific IT and Technical Service
> Max-Planck-Institute für Informatik & Softwaresysteme
> 
> _______________________________________________
> dovecot mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]