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]
