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


_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to