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.

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)?

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?

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.

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)?

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?

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