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]
