Build options does not include all build options, unfortunately. "invalid preceding regular expression" means the PCRE is available, the error would be clear that there is no PCRE support if it was missing.
Can you provide the exact regular expression, and how you are using it? Aki > On 10/07/2026 20:06 EEST Michael Merz via dovecot <[email protected]> wrote: > > > Hello Aki, > > Thank you for the pointer to https://repo.dovecot.org. > I have now installed Dovecot 2.4.4 from the official repository on Ubuntu > 24.04 LTS (Noble) and can confirm that the packages are available and install > correctly. > However, checking the build options shows that PCRE support is not included: > > $ dovecot --build-options > Build options: ioloop=epoll notify=inotify experimental-imap4rev2 openssl > io_block_size=8192 > SQL driver plugins: mysql postgresql sqlite > Passdb: ldap pam passwd passwd-file sql > Userdb: ldap(plugin) passwd prefetch passwd-file sql > > There is no PCRE entry, and sieve-test still rejects all (?i) inline flags in > regex expressions with "invalid preceding regular expression". > May I ask: is PCRE support intentionally not included in the official > Dovecot/Pigeonhole packages, or is this an oversight in the build > configuration? > If PCRE is not planned to be included, is there a recommended alternative > approach for achieving case-insensitive regex matching in Pigeonhole's > sieve-test that would be compatible with Cyrus IMAPd's PCRE-based regex > syntax? > > Thank you again for your help. > Best regards, > Michael Merz > [email protected] > > -----Ursprüngliche Nachricht----- > Von: Aki Tuomi via dovecot <[email protected]> > Gesendet: Freitag, 10. Juli 2026 06:51 > An: Michael Merz <[email protected]>; Michael Merz via dovecot > <[email protected]>; Stephan Bosch <[email protected]> > Betreff: Re: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test > restrictions on Return-Path > > You can get 2.4.4 packages for ubuntu 24.04 from https://repo.dovecot.org > > Aki > > > On 09/07/2026 22:21 EEST Michael Merz via dovecot <[email protected]> > > wrote: > > > > > > Dear Stephan, > > > > Thank you very much for your quick and helpful response. > > > > Regarding point 1 (PCRE support), your comment that Ubuntu 24.04 is "likely > > stuck at a quite old version of Pigeonhole" raises a follow-up question: > > > > From which version of Pigeonhole onwards is PCRE support included by > > default (i.e. compiled in without requiring an explicit --with-pcre flag)? > > And is there an official repository, PPA, or recommended way to obtain a > > more recent Pigeonhole/dovecot-sieve binary for Ubuntu 24.04 LTS that would > > include PCRE support out of the box? > > > > Regarding point 2 (Return-Path / envelope test): thank you for the pointer. > > I understand that the envelope test would be the RFC-compliant alternative > > within Pigeonhole. However, since my ruleset runs on a Cyrus backend where > > the address test on Return-Path works fine, this would mean maintaining two > > different versions of the ruleset — one for production (Cyrus) and one for > > offline testing (Pigeonhole). That somewhat defeats the purpose of offline > > testing, so I mention it only for completeness. > > > > The key question therefore remains whether a PCRE-enabled Pigeonhole binary > > is realistically obtainable for Ubuntu 24.04, as that would resolve the > > main blocker. > > > > Thank you again for your time. > > > > Best regards, > > Michael Merz > > > > von meinem iPad Pro 4Gen gesendet > > > > > Am 09.07.2026 um 18:39 schrieb Stephan Bosch <[email protected]>: > > > > > > > > > Op 29-6-2026 om 09:56 schreef michael.merz--- via dovecot: > > >> Hello, > > >> > > >> > > >> > > >> I've been evaluating sieve-test (Pigeonhole, dovecot-sieve package, > > >> version 2.3.21, as shipped with Ubuntu 24.04 LTS) as an offline > > >> testing > > >> tool for a personal Sieve ruleset that currently runs on a Cyrus > > >> IMAPd/CMU > > >> Sieve 3.0 backend. > > > > > > > > > Different implementation and design choices will mean that Dovecot has a > > > different opinion what is a valid Sieve script and how it is to be > > > evaluated than Cyrus, making this problematic. > > > > > > > > >> I'd like to ask for some clarification on two points, in case I'm > > >> missing > > >> a configuration option. > > >> > > >> > > >> > > >> 1) PCRE support > > >> > > >> > > >> > > >> My ruleset makes extensive use of the `(?i)` inline case-insensitivity > > >> flag within :regex tests, which is valid under PCRE (as used by > > >> Cyrus). > > >> > > >> When running sieve-test, I get: > > >> > > >> > > >> > > >> error: invalid regular expression '(?i)...' for regex match: > > >> > > >> invalid preceding regular expression. > > >> > > >> > > >> > > >> Checking `dovecot --build-options` shows no PCRE entry, which > > >> suggests the > > >> Ubuntu-packaged binary was compiled without --with-pcre and falls > > >> back to > > >> POSIX extended regex. > > >> > > >> > > >> > > >> Question: Is PCRE support in Pigeonhole's regex extension purely a > > >> compile-time decision (i.e. something that would need to be addressed > > >> at > > >> the distribution packaging level, not via runtime configuration), or > > >> is > > >> there a runtime way to enable PCRE matching that I might have missed > > >> (e.g. > > >> via -o, sieve_extensions, or similar)? > > > > > > > > > It is strictly compile-time configured. I didn't implement the PCRE > > > migration myself, but I don't think there is a POSIX regex fallback for > > > it. This likely means your Ubuntu version is still stuck at a quite old > > > version of Pigeonhole. > > > > > > > > >> 2) Return-Path in the `address` test > > >> > > >> > > >> > > >> Several of my rules use: > > >> > > >> > > >> > > >> address :domain :is "return-path" "..." > > >> > > >> > > >> > > >> Cyrus accepts this. Pigeonhole's sieve-test rejects it with: > > >> > > >> > > >> > > >> error: specified header 'return-path' is not allowed for the > > >> > > >> address test. > > >> > > >> > > >> > > >> I understand this is likely an RFC 5228 strictness difference (Cyrus > > >> being > > >> more permissive than the RFC requires). > > >> > > >> Is there a recommended alternative within Sieve itself to achieve the > > >> same > > >> effect (testing the address portion of Return-Path) while staying > > >> within > > >> what Pigeonhole accepts -- e.g. via the `header` test combined with > > >> some > > >> address-parsing approach, or via the envelope test instead? > > > > > > > > > Envelope test is best if you want to use address matching. > > > > > > > > >> For context: I'm not running a Dovecot mail server myself. > > >> > > >> I'm using sieve-test purely as an offline syntax/behaviour > > >> verification > > >> tool before deploying ruleset changes to a separate Cyrus-based > > >> production > > >> system. > > >> > > >> I understand this is a bit of an unusual use case, so any guidance on > > >> whether Pigeonhole is well suited for this kind of > > >> cross-implementation > > >> testing at all would also be appreciated. > > >> > > >> > > >> > > >> Thank you for your time and for maintaining Pigeonhole. > > >> > > >> > > >> > > >> Best regards, > > >> > > >> Michael Merz > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> 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] > > _______________________________________________ > 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] _______________________________________________ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
