Re: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path

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]