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

This is a multipart message in MIME format.

--===============7400323106071417507==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0005_01DD07AD.7E6E2FF0"
Content-Language: de

This is a multipart message in MIME format.

------=_NextPart_000_0005_01DD07AD.7E6E2FF0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

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

 


------=_NextPart_000_0005_01DD07AD.7E6E2FF0
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

   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



------=_NextPart_000_0005_01DD07AD.7E6E2FF0--


--===============7400323106071417507==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============7400323106071417507==--