sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
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.
I'd like to ask for some clarification on two points, in case I'm missing a configuration option.
- 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)?
- Return-Path in the
addresstest
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?
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
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.
I'd like to ask for some clarification on two points, in case I'm missing a configuration option.
- 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)?
- Return-Path in the
addresstest
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?
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
participants (1)
-
michael.merz@wtnet.de