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
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 -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Dear Stephan,
Thank you very much for your quick and helpful response.
Regarding point 1 (PCRE support), your comment that Ubuntu 24.04 is "likely stuck at a quite old version of Pigeonhole" raises a follow-up question:
From which version of Pigeonhole onwards is PCRE support included by default (i.e. compiled in without requiring an explicit --with-pcre flag)? And is there an official repository, PPA, or recommended way to obtain a more recent Pigeonhole/dovecot-sieve binary for Ubuntu 24.04 LTS that would include PCRE support out of the box?
Regarding point 2 (Return-Path / envelope test): thank you for the pointer. I understand that the envelope test would be the RFC-compliant alternative within Pigeonhole. However, since my ruleset runs on a Cyrus backend where the address test on Return-Path works fine, this would mean maintaining two different versions of the ruleset — one for production (Cyrus) and one for offline testing (Pigeonhole). That somewhat defeats the purpose of offline testing, so I mention it only for completeness.
The key question therefore remains whether a PCRE-enabled Pigeonhole binary is realistically obtainable for Ubuntu 24.04, as that would resolve the main blocker.
Thank you again for your time.
Best regards, Michael Merz
von meinem iPad Pro 4Gen gesendet
Am 09.07.2026 um 18:39 schrieb Stephan Bosch <stephan@rename-it.nl>:
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.
- 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-optionsshows 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.
- Return-Path in the
addresstestSeveral 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
headertest 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 -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
You can get 2.4.4 packages for ubuntu 24.04 from https://repo.dovecot.org
Aki
On 09/07/2026 22:21 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Dear Stephan,
Thank you very much for your quick and helpful response.
Regarding point 1 (PCRE support), your comment that Ubuntu 24.04 is "likely stuck at a quite old version of Pigeonhole" raises a follow-up question:
From which version of Pigeonhole onwards is PCRE support included by default (i.e. compiled in without requiring an explicit --with-pcre flag)? And is there an official repository, PPA, or recommended way to obtain a more recent Pigeonhole/dovecot-sieve binary for Ubuntu 24.04 LTS that would include PCRE support out of the box?
Regarding point 2 (Return-Path / envelope test): thank you for the pointer. I understand that the envelope test would be the RFC-compliant alternative within Pigeonhole. However, since my ruleset runs on a Cyrus backend where the address test on Return-Path works fine, this would mean maintaining two different versions of the ruleset — one for production (Cyrus) and one for offline testing (Pigeonhole). That somewhat defeats the purpose of offline testing, so I mention it only for completeness.
The key question therefore remains whether a PCRE-enabled Pigeonhole binary is realistically obtainable for Ubuntu 24.04, as that would resolve the main blocker.
Thank you again for your time.
Best regards, Michael Merz
von meinem iPad Pro 4Gen gesendet
Am 09.07.2026 um 18:39 schrieb Stephan Bosch <stephan@rename-it.nl>:
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.
- 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-optionsshows 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.
- Return-Path in the
addresstestSeveral 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
headertest 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 -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Hello Aki,
Thank you for the pointer to https://repo.dovecot.org. I have now installed Dovecot 2.4.4 from the official repository on Ubuntu 24.04 LTS (Noble) and can confirm that the packages are available and install correctly. However, checking the build options shows that PCRE support is not included:
$ dovecot --build-options Build options: ioloop=epoll notify=inotify experimental-imap4rev2 openssl io_block_size=8192 SQL driver plugins: mysql postgresql sqlite Passdb: ldap pam passwd passwd-file sql Userdb: ldap(plugin) passwd prefetch passwd-file sql
There is no PCRE entry, and sieve-test still rejects all (?i) inline flags in regex expressions with "invalid preceding regular expression". May I ask: is PCRE support intentionally not included in the official Dovecot/Pigeonhole packages, or is this an oversight in the build configuration? If PCRE is not planned to be included, is there a recommended alternative approach for achieving case-insensitive regex matching in Pigeonhole's sieve-test that would be compatible with Cyrus IMAPd's PCRE-based regex syntax?
Thank you again for your help. Best regards, Michael Merz michael.merz@wtnet.de
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 06:51 An: Michael Merz <michael.merz@wtnet.de>; Michael Merz via dovecot <dovecot@dovecot.org>; Stephan Bosch <stephan@rename-it.nl> Betreff: Re: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
You can get 2.4.4 packages for ubuntu 24.04 from https://repo.dovecot.org
Aki
On 09/07/2026 22:21 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Dear Stephan,
Thank you very much for your quick and helpful response.
Regarding point 1 (PCRE support), your comment that Ubuntu 24.04 is "likely stuck at a quite old version of Pigeonhole" raises a follow-up question:
From which version of Pigeonhole onwards is PCRE support included by default (i.e. compiled in without requiring an explicit --with-pcre flag)? And is there an official repository, PPA, or recommended way to obtain a more recent Pigeonhole/dovecot-sieve binary for Ubuntu 24.04 LTS that would include PCRE support out of the box?
Regarding point 2 (Return-Path / envelope test): thank you for the pointer. I understand that the envelope test would be the RFC-compliant alternative within Pigeonhole. However, since my ruleset runs on a Cyrus backend where the address test on Return-Path works fine, this would mean maintaining two different versions of the ruleset — one for production (Cyrus) and one for offline testing (Pigeonhole). That somewhat defeats the purpose of offline testing, so I mention it only for completeness.
The key question therefore remains whether a PCRE-enabled Pigeonhole binary is realistically obtainable for Ubuntu 24.04, as that would resolve the main blocker.
Thank you again for your time.
Best regards, Michael Merz
von meinem iPad Pro 4Gen gesendet
Am 09.07.2026 um 18:39 schrieb Stephan Bosch <stephan@rename-it.nl>:
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.
- 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-optionsshows 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.
- Return-Path in the
addresstestSeveral 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
headertest 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 -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Build options does not include all build options, unfortunately. "invalid preceding regular expression" means the PCRE is available, the error would be clear that there is no PCRE support if it was missing.
Can you provide the exact regular expression, and how you are using it?
Aki
On 10/07/2026 20:06 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Hello Aki,
Thank you for the pointer to https://repo.dovecot.org. I have now installed Dovecot 2.4.4 from the official repository on Ubuntu 24.04 LTS (Noble) and can confirm that the packages are available and install correctly. However, checking the build options shows that PCRE support is not included:
$ dovecot --build-options Build options: ioloop=epoll notify=inotify experimental-imap4rev2 openssl io_block_size=8192 SQL driver plugins: mysql postgresql sqlite Passdb: ldap pam passwd passwd-file sql Userdb: ldap(plugin) passwd prefetch passwd-file sql
There is no PCRE entry, and sieve-test still rejects all (?i) inline flags in regex expressions with "invalid preceding regular expression". May I ask: is PCRE support intentionally not included in the official Dovecot/Pigeonhole packages, or is this an oversight in the build configuration? If PCRE is not planned to be included, is there a recommended alternative approach for achieving case-insensitive regex matching in Pigeonhole's sieve-test that would be compatible with Cyrus IMAPd's PCRE-based regex syntax?
Thank you again for your help. Best regards, Michael Merz michael.merz@wtnet.de
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 06:51 An: Michael Merz <michael.merz@wtnet.de>; Michael Merz via dovecot <dovecot@dovecot.org>; Stephan Bosch <stephan@rename-it.nl> Betreff: Re: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
You can get 2.4.4 packages for ubuntu 24.04 from https://repo.dovecot.org
Aki
On 09/07/2026 22:21 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Dear Stephan,
Thank you very much for your quick and helpful response.
Regarding point 1 (PCRE support), your comment that Ubuntu 24.04 is "likely stuck at a quite old version of Pigeonhole" raises a follow-up question:
From which version of Pigeonhole onwards is PCRE support included by default (i.e. compiled in without requiring an explicit --with-pcre flag)? And is there an official repository, PPA, or recommended way to obtain a more recent Pigeonhole/dovecot-sieve binary for Ubuntu 24.04 LTS that would include PCRE support out of the box?
Regarding point 2 (Return-Path / envelope test): thank you for the pointer. I understand that the envelope test would be the RFC-compliant alternative within Pigeonhole. However, since my ruleset runs on a Cyrus backend where the address test on Return-Path works fine, this would mean maintaining two different versions of the ruleset — one for production (Cyrus) and one for offline testing (Pigeonhole). That somewhat defeats the purpose of offline testing, so I mention it only for completeness.
The key question therefore remains whether a PCRE-enabled Pigeonhole binary is realistically obtainable for Ubuntu 24.04, as that would resolve the main blocker.
Thank you again for your time.
Best regards, Michael Merz
von meinem iPad Pro 4Gen gesendet
Am 09.07.2026 um 18:39 schrieb Stephan Bosch <stephan@rename-it.nl>:
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.
- 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-optionsshows 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.
- Return-Path in the
addresstestSeveral 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
headertest 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 -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Hello Aki,
Thank you for the clarification — that is very encouraging news. Here are concrete examples of the regular expressions used in my ruleset, along with the sieve-test error messages they produce:
Example 1 — header :regex test:
if header :regex "X-Spam-Status" "(?i)score=[1-9]" {
Error: invalid regular expression '(?i)score=[1-9]' for regex match: invalid preceding regular expression
Example 2 — header :regex test:
if header :regex "from" "(?i)groups\.google\.com" {
Error: invalid regular expression '(?i)groups\.google\.com' for regex match: invalid preceding regular expression
Example 3 — header :regex test with anchoring:
if header :regex "subject" "^(?i)(re|fwd):" {
Error: invalid regular expression '^(?i)(re|fwd):' for regex match: invalid preceding regular expression
All errors follow the same pattern: the (?i) inline flag for case-insensitive matching is rejected regardless of its position in the expression or the header being tested.
The full require statement at the top of the script is:
require ["fileinto", "reject", "vacation", "regex", "copy", "body", "variables", "imap4flags", "editheader"];
sieve-test is invoked as follows:
sieve-test
-x "fileinto regex copy body variables imap4flags editheader"
-t /tmp/trace.txt
~/sieve-test/rules/v4_0_13.sieve
<mail.eml>
Dovecot version: 2:2.4.4-5+ubuntu24.04 (from repo.dovecot.org) Ubuntu: 24.04.3 LTS (Noble), WSL2
Thank you very much for looking into this.
Best regards, Michael Merz michael.merz@wtnet.de
Michael Merz Bargkoppel 15, 22844 Norderstedt Mobil 0172 4049171
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 19:16 An: michael.merz@wtnet.de; Michael Merz via dovecot <dovecot@dovecot.org> Cc: Stephan Bosch <stephan@rename-it.nl> Betreff: Re: AW: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
Build options does not include all build options, unfortunately. "invalid preceding regular expression" means the PCRE is available, the error would be clear that there is no PCRE support if it was missing.
Can you provide the exact regular expression, and how you are using it?
Aki
On 10/07/2026 20:06 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Hello Aki,
Thank you for the pointer to https://repo.dovecot.org. I have now installed Dovecot 2.4.4 from the official repository on Ubuntu 24.04 LTS (Noble) and can confirm that the packages are available and install correctly. However, checking the build options shows that PCRE support is not included:
$ dovecot --build-options Build options: ioloop=epoll notify=inotify experimental-imap4rev2 openssl io_block_size=8192 SQL driver plugins: mysql postgresql sqlite Passdb: ldap pam passwd passwd-file sql Userdb: ldap(plugin) passwd prefetch passwd-file sql
There is no PCRE entry, and sieve-test still rejects all (?i) inline flags in regex expressions with "invalid preceding regular expression". May I ask: is PCRE support intentionally not included in the official Dovecot/Pigeonhole packages, or is this an oversight in the build configuration? If PCRE is not planned to be included, is there a recommended alternative approach for achieving case-insensitive regex matching in Pigeonhole's sieve-test that would be compatible with Cyrus IMAPd's PCRE-based regex syntax?
Thank you again for your help. Best regards, Michael Merz michael.merz@wtnet.de
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 06:51 An: Michael Merz <michael.merz@wtnet.de>; Michael Merz via dovecot <dovecot@dovecot.org>; Stephan Bosch <stephan@rename-it.nl> Betreff: Re: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
You can get 2.4.4 packages for ubuntu 24.04 from https://repo.dovecot.org
Aki
On 09/07/2026 22:21 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Dear Stephan,
Thank you very much for your quick and helpful response.
Regarding point 1 (PCRE support), your comment that Ubuntu 24.04 is "likely stuck at a quite old version of Pigeonhole" raises a follow-up question:
From which version of Pigeonhole onwards is PCRE support included by default (i.e. compiled in without requiring an explicit --with-pcre flag)? And is there an official repository, PPA, or recommended way to obtain a more recent Pigeonhole/dovecot-sieve binary for Ubuntu 24.04 LTS that would include PCRE support out of the box?
Regarding point 2 (Return-Path / envelope test): thank you for the pointer. I understand that the envelope test would be the RFC-compliant alternative within Pigeonhole. However, since my ruleset runs on a Cyrus backend where the address test on Return-Path works fine, this would mean maintaining two different versions of the ruleset — one for production (Cyrus) and one for offline testing (Pigeonhole). That somewhat defeats the purpose of offline testing, so I mention it only for completeness.
The key question therefore remains whether a PCRE-enabled Pigeonhole binary is realistically obtainable for Ubuntu 24.04, as that would resolve the main blocker.
Thank you again for your time.
Best regards, Michael Merz
von meinem iPad Pro 4Gen gesendet
Am 09.07.2026 um 18:39 schrieb Stephan Bosch <stephan@rename-it.nl>:
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.
- 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-optionsshows 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.
- Return-Path in the
addresstestSeveral 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
headertest 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 -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
A sieve style of doing (?i) is
if header :regex :comparator "i;ascii-casemap" "from" "<regex>" { }
you can also use unicode-casemap for unicode.
Aki
On 10/07/2026 20:24 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Hello Aki,
Thank you for the clarification — that is very encouraging news. Here are concrete examples of the regular expressions used in my ruleset, along with the sieve-test error messages they produce:
Example 1 — header :regex test:
if header :regex "X-Spam-Status" "(?i)score=[1-9]" {
Error: invalid regular expression '(?i)score=[1-9]' for regex match: invalid preceding regular expression
Example 2 — header :regex test:
if header :regex "from" "(?i)groups\.google\.com" {
Error: invalid regular expression '(?i)groups\.google\.com' for regex match: invalid preceding regular expression
Example 3 — header :regex test with anchoring:
if header :regex "subject" "^(?i)(re|fwd):" {
Error: invalid regular expression '^(?i)(re|fwd):' for regex match: invalid preceding regular expression
All errors follow the same pattern: the (?i) inline flag for case-insensitive matching is rejected regardless of its position in the expression or the header being tested.
The full require statement at the top of the script is:
require ["fileinto", "reject", "vacation", "regex", "copy", "body", "variables", "imap4flags", "editheader"];
sieve-test is invoked as follows:
sieve-test
-x "fileinto regex copy body variables imap4flags editheader"
-t /tmp/trace.txt
~/sieve-test/rules/v4_0_13.sieve
<mail.eml>Dovecot version: 2:2.4.4-5+ubuntu24.04 (from repo.dovecot.org) Ubuntu: 24.04.3 LTS (Noble), WSL2
Thank you very much for looking into this.
Best regards, Michael Merz michael.merz@wtnet.de
Michael Merz Bargkoppel 15, 22844 Norderstedt Mobil 0172 4049171
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 19:16 An: michael.merz@wtnet.de; Michael Merz via dovecot <dovecot@dovecot.org> Cc: Stephan Bosch <stephan@rename-it.nl> Betreff: Re: AW: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
Build options does not include all build options, unfortunately. "invalid preceding regular expression" means the PCRE is available, the error would be clear that there is no PCRE support if it was missing.
Can you provide the exact regular expression, and how you are using it?
Aki
On 10/07/2026 20:06 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Hello Aki,
Thank you for the pointer to https://repo.dovecot.org. I have now installed Dovecot 2.4.4 from the official repository on Ubuntu 24.04 LTS (Noble) and can confirm that the packages are available and install correctly. However, checking the build options shows that PCRE support is not included:
$ dovecot --build-options Build options: ioloop=epoll notify=inotify experimental-imap4rev2 openssl io_block_size=8192 SQL driver plugins: mysql postgresql sqlite Passdb: ldap pam passwd passwd-file sql Userdb: ldap(plugin) passwd prefetch passwd-file sql
There is no PCRE entry, and sieve-test still rejects all (?i) inline flags in regex expressions with "invalid preceding regular expression". May I ask: is PCRE support intentionally not included in the official Dovecot/Pigeonhole packages, or is this an oversight in the build configuration? If PCRE is not planned to be included, is there a recommended alternative approach for achieving case-insensitive regex matching in Pigeonhole's sieve-test that would be compatible with Cyrus IMAPd's PCRE-based regex syntax?
Thank you again for your help. Best regards, Michael Merz michael.merz@wtnet.de
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 06:51 An: Michael Merz <michael.merz@wtnet.de>; Michael Merz via dovecot <dovecot@dovecot.org>; Stephan Bosch <stephan@rename-it.nl> Betreff: Re: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
You can get 2.4.4 packages for ubuntu 24.04 from https://repo.dovecot.org
Aki
On 09/07/2026 22:21 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Dear Stephan,
Thank you very much for your quick and helpful response.
Regarding point 1 (PCRE support), your comment that Ubuntu 24.04 is "likely stuck at a quite old version of Pigeonhole" raises a follow-up question:
From which version of Pigeonhole onwards is PCRE support included by default (i.e. compiled in without requiring an explicit --with-pcre flag)? And is there an official repository, PPA, or recommended way to obtain a more recent Pigeonhole/dovecot-sieve binary for Ubuntu 24.04 LTS that would include PCRE support out of the box?
Regarding point 2 (Return-Path / envelope test): thank you for the pointer. I understand that the envelope test would be the RFC-compliant alternative within Pigeonhole. However, since my ruleset runs on a Cyrus backend where the address test on Return-Path works fine, this would mean maintaining two different versions of the ruleset — one for production (Cyrus) and one for offline testing (Pigeonhole). That somewhat defeats the purpose of offline testing, so I mention it only for completeness.
The key question therefore remains whether a PCRE-enabled Pigeonhole binary is realistically obtainable for Ubuntu 24.04, as that would resolve the main blocker.
Thank you again for your time.
Best regards, Michael Merz
von meinem iPad Pro 4Gen gesendet
Am 09.07.2026 um 18:39 schrieb Stephan Bosch <stephan@rename-it.nl>:
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.
- 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-optionsshows 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.
- Return-Path in the
addresstestSeveral 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
headertest 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 -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Although I did test this:
MATCH_CASE("(?i)hello", "HELLO"),
MATCH_CASE("^(?i)\\[(.*)\\] (.*)$", "[acme-users] [fwd]: hello, world"),and did not get any complaints from the library itself. So there is some other reason for it to fail.
Aki
On 10/07/2026 20:40 EEST Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
A sieve style of doing (?i) is
if header :regex :comparator "i;ascii-casemap" "from" "<regex>" { }
you can also use unicode-casemap for unicode.
Aki
On 10/07/2026 20:24 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Hello Aki,
Thank you for the clarification — that is very encouraging news. Here are concrete examples of the regular expressions used in my ruleset, along with the sieve-test error messages they produce:
Example 1 — header :regex test:
if header :regex "X-Spam-Status" "(?i)score=[1-9]" {
Error: invalid regular expression '(?i)score=[1-9]' for regex match: invalid preceding regular expression
Example 2 — header :regex test:
if header :regex "from" "(?i)groups\.google\.com" {
Error: invalid regular expression '(?i)groups\.google\.com' for regex match: invalid preceding regular expression
Example 3 — header :regex test with anchoring:
if header :regex "subject" "^(?i)(re|fwd):" {
Error: invalid regular expression '^(?i)(re|fwd):' for regex match: invalid preceding regular expression
All errors follow the same pattern: the (?i) inline flag for case-insensitive matching is rejected regardless of its position in the expression or the header being tested.
The full require statement at the top of the script is:
require ["fileinto", "reject", "vacation", "regex", "copy", "body", "variables", "imap4flags", "editheader"];
sieve-test is invoked as follows:
sieve-test
-x "fileinto regex copy body variables imap4flags editheader"
-t /tmp/trace.txt
~/sieve-test/rules/v4_0_13.sieve
<mail.eml>Dovecot version: 2:2.4.4-5+ubuntu24.04 (from repo.dovecot.org) Ubuntu: 24.04.3 LTS (Noble), WSL2
Thank you very much for looking into this.
Best regards, Michael Merz michael.merz@wtnet.de
Michael Merz Bargkoppel 15, 22844 Norderstedt Mobil 0172 4049171
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 19:16 An: michael.merz@wtnet.de; Michael Merz via dovecot <dovecot@dovecot.org> Cc: Stephan Bosch <stephan@rename-it.nl> Betreff: Re: AW: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
Build options does not include all build options, unfortunately. "invalid preceding regular expression" means the PCRE is available, the error would be clear that there is no PCRE support if it was missing.
Can you provide the exact regular expression, and how you are using it?
Aki
On 10/07/2026 20:06 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Hello Aki,
Thank you for the pointer to https://repo.dovecot.org. I have now installed Dovecot 2.4.4 from the official repository on Ubuntu 24.04 LTS (Noble) and can confirm that the packages are available and install correctly. However, checking the build options shows that PCRE support is not included:
$ dovecot --build-options Build options: ioloop=epoll notify=inotify experimental-imap4rev2 openssl io_block_size=8192 SQL driver plugins: mysql postgresql sqlite Passdb: ldap pam passwd passwd-file sql Userdb: ldap(plugin) passwd prefetch passwd-file sql
There is no PCRE entry, and sieve-test still rejects all (?i) inline flags in regex expressions with "invalid preceding regular expression". May I ask: is PCRE support intentionally not included in the official Dovecot/Pigeonhole packages, or is this an oversight in the build configuration? If PCRE is not planned to be included, is there a recommended alternative approach for achieving case-insensitive regex matching in Pigeonhole's sieve-test that would be compatible with Cyrus IMAPd's PCRE-based regex syntax?
Thank you again for your help. Best regards, Michael Merz michael.merz@wtnet.de
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 06:51 An: Michael Merz <michael.merz@wtnet.de>; Michael Merz via dovecot <dovecot@dovecot.org>; Stephan Bosch <stephan@rename-it.nl> Betreff: Re: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
You can get 2.4.4 packages for ubuntu 24.04 from https://repo.dovecot.org
Aki
On 09/07/2026 22:21 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Dear Stephan,
Thank you very much for your quick and helpful response.
Regarding point 1 (PCRE support), your comment that Ubuntu 24.04 is "likely stuck at a quite old version of Pigeonhole" raises a follow-up question:
From which version of Pigeonhole onwards is PCRE support included by default (i.e. compiled in without requiring an explicit --with-pcre flag)? And is there an official repository, PPA, or recommended way to obtain a more recent Pigeonhole/dovecot-sieve binary for Ubuntu 24.04 LTS that would include PCRE support out of the box?
Regarding point 2 (Return-Path / envelope test): thank you for the pointer. I understand that the envelope test would be the RFC-compliant alternative within Pigeonhole. However, since my ruleset runs on a Cyrus backend where the address test on Return-Path works fine, this would mean maintaining two different versions of the ruleset — one for production (Cyrus) and one for offline testing (Pigeonhole). That somewhat defeats the purpose of offline testing, so I mention it only for completeness.
The key question therefore remains whether a PCRE-enabled Pigeonhole binary is realistically obtainable for Ubuntu 24.04, as that would resolve the main blocker.
Thank you again for your time.
Best regards, Michael Merz
von meinem iPad Pro 4Gen gesendet
Am 09.07.2026 um 18:39 schrieb Stephan Bosch <stephan@rename-it.nl>:
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.
- 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-optionsshows 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.
- Return-Path in the
addresstestSeveral 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
headertest 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 -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Hello Aki,
Good news: after installing Dovecot 2.4.4 from repo.dovecot.org, the (?i) regex errors are gone. PCRE appears to be working correctly now. However, sieve-test now fails with a different error:
sieve-test: Fatal: mail_driver not set and autodetection failed: Mail storage autodetection failed (home=/home/micha, mail_path=)
- Set mail_driver explicitly
I am invoking sieve-test as follows:
sieve-test
-x "fileinto regex copy body variables imap4flags editheader"
-e
-t /tmp/trace.txt
~/sieve-test/rules/v4_1_7.sieve
<mail.eml>
I have also tried -o mail_location=maildir:~/sieve-test/mailbox and -o plugin/mail_location=maildir:~/sieve-test/mailbox, both of which produce "Unknown setting" errors.
I am not running a Dovecot mail server — I am using sieve-test purely as an offline testing tool without any Dovecot server configuration.
Could you advise on the correct way to set mail_driver (or mail_location) for sieve-test 2.4.4 in a standalone/serverless context?
Thank you very much.
Best regards, Michael Merz michael.merz@wtnet.de
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 19:44 An: michael.merz@wtnet.de; Michael Merz via dovecot <dovecot@dovecot.org> Cc: Stephan Bosch <stephan@rename-it.nl> Betreff: Re: AW: AW: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
Although I did test this:
MATCH_CASE("(?i)hello", "HELLO"),
MATCH_CASE("^(?i)\\[(.*)\\] (.*)$", "[acme-users] [fwd]: hello, world"),and did not get any complaints from the library itself. So there is some other reason for it to fail.
Aki
On 10/07/2026 20:40 EEST Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
A sieve style of doing (?i) is
if header :regex :comparator "i;ascii-casemap" "from" "<regex>" { }
you can also use unicode-casemap for unicode.
Aki
On 10/07/2026 20:24 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Hello Aki,
Thank you for the clarification — that is very encouraging news. Here are concrete examples of the regular expressions used in my ruleset, along with the sieve-test error messages they produce:
Example 1 — header :regex test:
if header :regex "X-Spam-Status" "(?i)score=[1-9]" {
Error: invalid regular expression '(?i)score=[1-9]' for regex match: invalid preceding regular expression
Example 2 — header :regex test:
if header :regex "from" "(?i)groups\.google\.com" {
Error: invalid regular expression '(?i)groups\.google\.com' for regex match: invalid preceding regular expression
Example 3 — header :regex test with anchoring:
if header :regex "subject" "^(?i)(re|fwd):" {
Error: invalid regular expression '^(?i)(re|fwd):' for regex match: invalid preceding regular expression
All errors follow the same pattern: the (?i) inline flag for case-insensitive matching is rejected regardless of its position in the expression or the header being tested.
The full require statement at the top of the script is:
require ["fileinto", "reject", "vacation", "regex", "copy", "body", "variables", "imap4flags", "editheader"];
sieve-test is invoked as follows:
sieve-test
-x "fileinto regex copy body variables imap4flags editheader"
-t /tmp/trace.txt
~/sieve-test/rules/v4_0_13.sieve
<mail.eml>Dovecot version: 2:2.4.4-5+ubuntu24.04 (from repo.dovecot.org) Ubuntu: 24.04.3 LTS (Noble), WSL2
Thank you very much for looking into this.
Best regards, Michael Merz michael.merz@wtnet.de
Michael Merz Bargkoppel 15, 22844 Norderstedt Mobil 0172 4049171
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 19:16 An: michael.merz@wtnet.de; Michael Merz via dovecot <dovecot@dovecot.org> Cc: Stephan Bosch <stephan@rename-it.nl> Betreff: Re: AW: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
Build options does not include all build options, unfortunately. "invalid preceding regular expression" means the PCRE is available, the error would be clear that there is no PCRE support if it was missing.
Can you provide the exact regular expression, and how you are using it?
Aki
On 10/07/2026 20:06 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Hello Aki,
Thank you for the pointer to https://repo.dovecot.org. I have now installed Dovecot 2.4.4 from the official repository on Ubuntu 24.04 LTS (Noble) and can confirm that the packages are available and install correctly. However, checking the build options shows that PCRE support is not included:
$ dovecot --build-options Build options: ioloop=epoll notify=inotify experimental-imap4rev2 openssl io_block_size=8192 SQL driver plugins: mysql postgresql sqlite Passdb: ldap pam passwd passwd-file sql Userdb: ldap(plugin) passwd prefetch passwd-file sql
There is no PCRE entry, and sieve-test still rejects all (?i) inline flags in regex expressions with "invalid preceding regular expression". May I ask: is PCRE support intentionally not included in the official Dovecot/Pigeonhole packages, or is this an oversight in the build configuration? If PCRE is not planned to be included, is there a recommended alternative approach for achieving case-insensitive regex matching in Pigeonhole's sieve-test that would be compatible with Cyrus IMAPd's PCRE-based regex syntax?
Thank you again for your help. Best regards, Michael Merz michael.merz@wtnet.de
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 06:51 An: Michael Merz <michael.merz@wtnet.de>; Michael Merz via dovecot <dovecot@dovecot.org>; Stephan Bosch <stephan@rename-it.nl> Betreff: Re: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
You can get 2.4.4 packages for ubuntu 24.04 from https://repo.dovecot.org
Aki
On 09/07/2026 22:21 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Dear Stephan,
Thank you very much for your quick and helpful response.
Regarding point 1 (PCRE support), your comment that Ubuntu 24.04 is "likely stuck at a quite old version of Pigeonhole" raises a follow-up question:
From which version of Pigeonhole onwards is PCRE support included by default (i.e. compiled in without requiring an explicit --with-pcre flag)? And is there an official repository, PPA, or recommended way to obtain a more recent Pigeonhole/dovecot-sieve binary for Ubuntu 24.04 LTS that would include PCRE support out of the box?
Regarding point 2 (Return-Path / envelope test): thank you for the pointer. I understand that the envelope test would be the RFC-compliant alternative within Pigeonhole. However, since my ruleset runs on a Cyrus backend where the address test on Return-Path works fine, this would mean maintaining two different versions of the ruleset — one for production (Cyrus) and one for offline testing (Pigeonhole). That somewhat defeats the purpose of offline testing, so I mention it only for completeness.
The key question therefore remains whether a PCRE-enabled Pigeonhole binary is realistically obtainable for Ubuntu 24.04, as that would resolve the main blocker.
Thank you again for your time.
Best regards, Michael Merz
von meinem iPad Pro 4Gen gesendet
Am 09.07.2026 um 18:39 schrieb Stephan Bosch <stephan@rename-it.nl>:
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.
- 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-optionsshows 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.
- Return-Path in the
addresstestSeveral 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 forthe
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
headertest 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 -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Even if you use it standalone, having a small dovecot.conf file, configured, might work. Anyways, -o mail_driver=maildir (as it suggests) would help. mail_location was split into multiple settings in 2.4.
Aki
On 11/07/2026 10:15 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Hello Aki,
Good news: after installing Dovecot 2.4.4 from repo.dovecot.org, the (?i) regex errors are gone. PCRE appears to be working correctly now. However, sieve-test now fails with a different error:
sieve-test: Fatal: mail_driver not set and autodetection failed: Mail storage autodetection failed (home=/home/micha, mail_path=)
- Set mail_driver explicitly
I am invoking sieve-test as follows:
sieve-test
-x "fileinto regex copy body variables imap4flags editheader"
-e
-t /tmp/trace.txt
~/sieve-test/rules/v4_1_7.sieve
<mail.eml>I have also tried -o mail_location=maildir:~/sieve-test/mailbox and -o plugin/mail_location=maildir:~/sieve-test/mailbox, both of which produce "Unknown setting" errors.
I am not running a Dovecot mail server — I am using sieve-test purely as an offline testing tool without any Dovecot server configuration.
Could you advise on the correct way to set mail_driver (or mail_location) for sieve-test 2.4.4 in a standalone/serverless context?
Thank you very much.
Best regards, Michael Merz michael.merz@wtnet.de
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 19:44 An: michael.merz@wtnet.de; Michael Merz via dovecot <dovecot@dovecot.org> Cc: Stephan Bosch <stephan@rename-it.nl> Betreff: Re: AW: AW: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
Although I did test this:
MATCH_CASE("(?i)hello", "HELLO"), MATCH_CASE("^(?i)\\[(.*)\\] (.*)$", "[acme-users] [fwd]: hello, world"),and did not get any complaints from the library itself. So there is some other reason for it to fail.
Aki
On 10/07/2026 20:40 EEST Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
A sieve style of doing (?i) is
if header :regex :comparator "i;ascii-casemap" "from" "<regex>" { }
you can also use unicode-casemap for unicode.
Aki
On 10/07/2026 20:24 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Hello Aki,
Thank you for the clarification — that is very encouraging news. Here are concrete examples of the regular expressions used in my ruleset, along with the sieve-test error messages they produce:
Example 1 — header :regex test:
if header :regex "X-Spam-Status" "(?i)score=[1-9]" {
Error: invalid regular expression '(?i)score=[1-9]' for regex match: invalid preceding regular expression
Example 2 — header :regex test:
if header :regex "from" "(?i)groups\.google\.com" {
Error: invalid regular expression '(?i)groups\.google\.com' for regex match: invalid preceding regular expression
Example 3 — header :regex test with anchoring:
if header :regex "subject" "^(?i)(re|fwd):" {
Error: invalid regular expression '^(?i)(re|fwd):' for regex match: invalid preceding regular expression
All errors follow the same pattern: the (?i) inline flag for case-insensitive matching is rejected regardless of its position in the expression or the header being tested.
The full require statement at the top of the script is:
require ["fileinto", "reject", "vacation", "regex", "copy", "body", "variables", "imap4flags", "editheader"];
sieve-test is invoked as follows:
sieve-test
-x "fileinto regex copy body variables imap4flags editheader"
-t /tmp/trace.txt
~/sieve-test/rules/v4_0_13.sieve
<mail.eml>Dovecot version: 2:2.4.4-5+ubuntu24.04 (from repo.dovecot.org) Ubuntu: 24.04.3 LTS (Noble), WSL2
Thank you very much for looking into this.
Best regards, Michael Merz michael.merz@wtnet.de
Michael Merz Bargkoppel 15, 22844 Norderstedt Mobil 0172 4049171
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 19:16 An: michael.merz@wtnet.de; Michael Merz via dovecot <dovecot@dovecot.org> Cc: Stephan Bosch <stephan@rename-it.nl> Betreff: Re: AW: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
Build options does not include all build options, unfortunately. "invalid preceding regular expression" means the PCRE is available, the error would be clear that there is no PCRE support if it was missing.
Can you provide the exact regular expression, and how you are using it?
Aki
On 10/07/2026 20:06 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Hello Aki,
Thank you for the pointer to https://repo.dovecot.org. I have now installed Dovecot 2.4.4 from the official repository on Ubuntu 24.04 LTS (Noble) and can confirm that the packages are available and install correctly. However, checking the build options shows that PCRE support is not included:
$ dovecot --build-options Build options: ioloop=epoll notify=inotify experimental-imap4rev2 openssl io_block_size=8192 SQL driver plugins: mysql postgresql sqlite Passdb: ldap pam passwd passwd-file sql Userdb: ldap(plugin) passwd prefetch passwd-file sql
There is no PCRE entry, and sieve-test still rejects all (?i) inline flags in regex expressions with "invalid preceding regular expression". May I ask: is PCRE support intentionally not included in the official Dovecot/Pigeonhole packages, or is this an oversight in the build configuration? If PCRE is not planned to be included, is there a recommended alternative approach for achieving case-insensitive regex matching in Pigeonhole's sieve-test that would be compatible with Cyrus IMAPd's PCRE-based regex syntax?
Thank you again for your help. Best regards, Michael Merz michael.merz@wtnet.de
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 06:51 An: Michael Merz <michael.merz@wtnet.de>; Michael Merz via dovecot <dovecot@dovecot.org>; Stephan Bosch <stephan@rename-it.nl> Betreff: Re: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
You can get 2.4.4 packages for ubuntu 24.04 from https://repo.dovecot.org
Aki
On 09/07/2026 22:21 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Dear Stephan,
Thank you very much for your quick and helpful response.
Regarding point 1 (PCRE support), your comment that Ubuntu 24.04 is "likely stuck at a quite old version of Pigeonhole" raises a follow-up question:
From which version of Pigeonhole onwards is PCRE support included by default (i.e. compiled in without requiring an explicit --with-pcre flag)? And is there an official repository, PPA, or recommended way to obtain a more recent Pigeonhole/dovecot-sieve binary for Ubuntu 24.04 LTS that would include PCRE support out of the box?
Regarding point 2 (Return-Path / envelope test): thank you for the pointer. I understand that the envelope test would be the RFC-compliant alternative within Pigeonhole. However, since my ruleset runs on a Cyrus backend where the address test on Return-Path works fine, this would mean maintaining two different versions of the ruleset — one for production (Cyrus) and one for offline testing (Pigeonhole). That somewhat defeats the purpose of offline testing, so I mention it only for completeness.
The key question therefore remains whether a PCRE-enabled Pigeonhole binary is realistically obtainable for Ubuntu 24.04, as that would resolve the main blocker.
Thank you again for your time.
Best regards, Michael Merz
von meinem iPad Pro 4Gen gesendet
Am 09.07.2026 um 18:39 schrieb Stephan Bosch <stephan@rename-it.nl>:
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. > > > > Checkingdovecot --build-optionsshows 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
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 theheadertest 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 -- dovecot@dovecot.org To unsubscribe > send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Subject: Re: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
Hello Aki,
Great progress: after adding -o mail_driver=maildir, the (?i) PCRE errors are completely gone. Thank you! The only remaining issue is the return-path restriction in the address test:
error: specified header 'return-path' is not allowed for the address test.
This affects several rules in my ruleset that use constructs like:
if address :domain :is "return-path" "example.com" { }
As you mentioned earlier, the envelope test would be the RFC-compliant alternative. However, since my ruleset runs on a Cyrus IMAPd backend (which accepts return-path in the address test), switching to envelope would mean maintaining two separate versions of the ruleset — one for production and one for offline testing — which defeats the purpose.
Is there a sieve-test option (e.g. via -o or a config setting) that would allow or relax the return-path restriction in the address test, so that sieve-test can process the script without modification?
Thank you again for your continued support — we are very close to a working solution!
Best regards, Michael Merz michael.merz@wtnet.de
-----Ursprüngliche Nachricht----- Von: Aki Tuomi <aki.tuomi@open-xchange.com> Gesendet: Samstag, 11. Juli 2026 11:38 An: michael.merz@wtnet.de; Michael Merz via dovecot <dovecot@dovecot.org> Cc: Stephan Bosch <stephan@rename-it.nl> Betreff: Re: AW: AW: AW: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
Even if you use it standalone, having a small dovecot.conf file, configured, might work. Anyways, -o mail_driver=maildir (as it suggests) would help. mail_location was split into multiple settings in 2.4.
Aki
On 11/07/2026 10:15 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Hello Aki,
Good news: after installing Dovecot 2.4.4 from repo.dovecot.org, the (?i) regex errors are gone. PCRE appears to be working correctly now. However, sieve-test now fails with a different error:
sieve-test: Fatal: mail_driver not set and autodetection failed: Mail storage autodetection failed (home=/home/micha, mail_path=)
- Set mail_driver explicitly
I am invoking sieve-test as follows:
sieve-test
-x "fileinto regex copy body variables imap4flags editheader"
-e
-t /tmp/trace.txt
~/sieve-test/rules/v4_1_7.sieve
<mail.eml>I have also tried -o mail_location=maildir:~/sieve-test/mailbox and -o plugin/mail_location=maildir:~/sieve-test/mailbox, both of which produce "Unknown setting" errors.
I am not running a Dovecot mail server — I am using sieve-test purely as an offline testing tool without any Dovecot server configuration.
Could you advise on the correct way to set mail_driver (or mail_location) for sieve-test 2.4.4 in a standalone/serverless context?
Thank you very much.
Best regards, Michael Merz michael.merz@wtnet.de
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 19:44 An: michael.merz@wtnet.de; Michael Merz via dovecot <dovecot@dovecot.org> Cc: Stephan Bosch <stephan@rename-it.nl> Betreff: Re: AW: AW: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
Although I did test this:
MATCH_CASE("(?i)hello", "HELLO"), MATCH_CASE("^(?i)\\[(.*)\\] (.*)$", "[acme-users][fwd]: hello, world"),
and did not get any complaints from the library itself. So there is some other reason for it to fail.
Aki
On 10/07/2026 20:40 EEST Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
A sieve style of doing (?i) is
if header :regex :comparator "i;ascii-casemap" "from" "<regex>" { }
you can also use unicode-casemap for unicode.
Aki
On 10/07/2026 20:24 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Hello Aki,
Thank you for the clarification — that is very encouraging news. Here are concrete examples of the regular expressions used in my ruleset, along with the sieve-test error messages they produce:
Example 1 — header :regex test:
if header :regex "X-Spam-Status" "(?i)score=[1-9]" {
Error: invalid regular expression '(?i)score=[1-9]' for regex match: invalid preceding regular expression
Example 2 — header :regex test:
if header :regex "from" "(?i)groups\.google\.com" {
Error: invalid regular expression '(?i)groups\.google\.com' for regex match: invalid preceding regular expression
Example 3 — header :regex test with anchoring:
if header :regex "subject" "^(?i)(re|fwd):" {
Error: invalid regular expression '^(?i)(re|fwd):' for regex match: invalid preceding regular expression
All errors follow the same pattern: the (?i) inline flag for case-insensitive matching is rejected regardless of its position in the expression or the header being tested.
The full require statement at the top of the script is:
require ["fileinto", "reject", "vacation", "regex", "copy", "body", "variables", "imap4flags", "editheader"];
sieve-test is invoked as follows:
sieve-test
-x "fileinto regex copy body variables imap4flags editheader"
-t /tmp/trace.txt
~/sieve-test/rules/v4_0_13.sieve
<mail.eml>Dovecot version: 2:2.4.4-5+ubuntu24.04 (from repo.dovecot.org) Ubuntu: 24.04.3 LTS (Noble), WSL2
Thank you very much for looking into this.
Best regards, Michael Merz michael.merz@wtnet.de
Michael Merz Bargkoppel 15, 22844 Norderstedt Mobil 0172 4049171
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 19:16 An: michael.merz@wtnet.de; Michael Merz via dovecot <dovecot@dovecot.org> Cc: Stephan Bosch <stephan@rename-it.nl> Betreff: Re: AW: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
Build options does not include all build options, unfortunately. "invalid preceding regular expression" means the PCRE is available, the error would be clear that there is no PCRE support if it was missing.
Can you provide the exact regular expression, and how you are using it?
Aki
On 10/07/2026 20:06 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Hello Aki,
Thank you for the pointer to https://repo.dovecot.org. I have now installed Dovecot 2.4.4 from the official repository on Ubuntu 24.04 LTS (Noble) and can confirm that the packages are available and install correctly. However, checking the build options shows that PCRE support is not included:
$ dovecot --build-options Build options: ioloop=epoll notify=inotify experimental-imap4rev2 openssl io_block_size=8192 SQL driver plugins: mysql postgresql sqlite Passdb: ldap pam passwd passwd-file sql Userdb: ldap(plugin) passwd prefetch passwd-file sql
There is no PCRE entry, and sieve-test still rejects all (?i) inline flags in regex expressions with "invalid preceding regular expression". May I ask: is PCRE support intentionally not included in the official Dovecot/Pigeonhole packages, or is this an oversight in the build configuration? If PCRE is not planned to be included, is there a recommended alternative approach for achieving case-insensitive regex matching in Pigeonhole's sieve-test that would be compatible with Cyrus IMAPd's PCRE-based regex syntax?
Thank you again for your help. Best regards, Michael Merz michael.merz@wtnet.de
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 06:51 An: Michael Merz <michael.merz@wtnet.de>; Michael Merz via dovecot <dovecot@dovecot.org>; Stephan Bosch <stephan@rename-it.nl> Betreff: Re: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
You can get 2.4.4 packages for ubuntu 24.04 from https://repo.dovecot.org
Aki
On 09/07/2026 22:21 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Dear Stephan,
Thank you very much for your quick and helpful response.
Regarding point 1 (PCRE support), your comment that Ubuntu 24.04 is "likely stuck at a quite old version of Pigeonhole" raises a follow-up question:
From which version of Pigeonhole onwards is PCRE support included by default (i.e. compiled in without requiring an explicit --with-pcre flag)? And is there an official repository, PPA, or recommended way to obtain a more recent Pigeonhole/dovecot-sieve binary for Ubuntu 24.04 LTS that would include PCRE support out of the box?
Regarding point 2 (Return-Path / envelope test): thank you for the pointer. I understand that the envelope test would be the RFC-compliant alternative within Pigeonhole. However, since my ruleset runs on a Cyrus backend where the address test on Return-Path works fine, this would mean maintaining two different versions of the ruleset — one for production (Cyrus) and one for offline testing (Pigeonhole). That somewhat defeats the purpose of offline testing, so I mention it only for completeness.
The key question therefore remains whether a PCRE-enabled Pigeonhole binary is realistically obtainable for Ubuntu 24.04, as that would resolve the main blocker.
Thank you again for your time.
Best regards, Michael Merz
von meinem iPad Pro 4Gen gesendet
Am 09.07.2026 um 18:39 schrieb Stephan Bosch <stephan@rename-it.nl>:
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. > > > > Checkingdovecot --build-optionsshows 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
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 theheadertest 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 -- dovecot@dovecot.org To unsubscribe > send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Op 11-7-2026 om 12:28 schreef Michael Merz via dovecot:
Subject: Re: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
Hello Aki,
Great progress: after adding -o mail_driver=maildir, the (?i) PCRE errors are completely gone. Thank you! The only remaining issue is the return-path restriction in the address test:
error: specified header 'return-path' is not allowed for the address test.
This affects several rules in my ruleset that use constructs like:
if address :domain :is "return-path" "example.com" { }
As you mentioned earlier, the envelope test would be the RFC-compliant alternative. However, since my ruleset runs on a Cyrus IMAPd backend (which accepts return-path in the address test), switching to envelope would mean maintaining two separate versions of the ruleset — one for production and one for offline testing — which defeats the purpose.
Is there a sieve-test option (e.g. via -o or a config setting) that would allow or relax the return-path restriction in the address test, so that sieve-test can process the script without modification?
Thank you again for your continued support — we are very close to a working solution!
There are no such options to evade this check. However, currently you can still commit an atrocity like this:
require "regex"; require "variables";
set "hdr" "return-path";
if address "${hdr}" "frop@example.com" { discard; }
Still, since this is an omission, I cannot guarantee that this will remain possible in the future.
Regards,
Stephan.
Best regards, Michael Merz michael.merz@wtnet.de
-----Ursprüngliche Nachricht----- Von: Aki Tuomi <aki.tuomi@open-xchange.com> Gesendet: Samstag, 11. Juli 2026 11:38 An: michael.merz@wtnet.de; Michael Merz via dovecot <dovecot@dovecot.org> Cc: Stephan Bosch <stephan@rename-it.nl> Betreff: Re: AW: AW: AW: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
Even if you use it standalone, having a small dovecot.conf file, configured, might work. Anyways, -o mail_driver=maildir (as it suggests) would help. mail_location was split into multiple settings in 2.4.
Aki
On 11/07/2026 10:15 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Hello Aki,
Good news: after installing Dovecot 2.4.4 from repo.dovecot.org, the (?i) regex errors are gone. PCRE appears to be working correctly now. However, sieve-test now fails with a different error:
sieve-test: Fatal: mail_driver not set and autodetection failed: Mail storage autodetection failed (home=/home/micha, mail_path=)
- Set mail_driver explicitly
I am invoking sieve-test as follows:
sieve-test
-x "fileinto regex copy body variables imap4flags editheader"
-e
-t /tmp/trace.txt
~/sieve-test/rules/v4_1_7.sieve
<mail.eml>I have also tried -o mail_location=maildir:~/sieve-test/mailbox and -o plugin/mail_location=maildir:~/sieve-test/mailbox, both of which produce "Unknown setting" errors.
I am not running a Dovecot mail server — I am using sieve-test purely as an offline testing tool without any Dovecot server configuration.
Could you advise on the correct way to set mail_driver (or mail_location) for sieve-test 2.4.4 in a standalone/serverless context?
Thank you very much.
Best regards, Michael Merz michael.merz@wtnet.de
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 19:44 An: michael.merz@wtnet.de; Michael Merz via dovecot <dovecot@dovecot.org> Cc: Stephan Bosch <stephan@rename-it.nl> Betreff: Re: AW: AW: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
Although I did test this:
MATCH_CASE("(?i)hello", "HELLO"), MATCH_CASE("^(?i)\\[(.*)\\] (.*)$", "[acme-users][fwd]: hello, world"),
and did not get any complaints from the library itself. So there is some other reason for it to fail.
Aki
On 10/07/2026 20:40 EEST Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
A sieve style of doing (?i) is
if header :regex :comparator "i;ascii-casemap" "from" "<regex>" { }
you can also use unicode-casemap for unicode.
Aki
On 10/07/2026 20:24 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Hello Aki,
Thank you for the clarification — that is very encouraging news. Here are concrete examples of the regular expressions used in my ruleset, along with the sieve-test error messages they produce:
Example 1 — header :regex test:
if header :regex "X-Spam-Status" "(?i)score=[1-9]" {
Error: invalid regular expression '(?i)score=[1-9]' for regex match: invalid preceding regular expression
Example 2 — header :regex test:
if header :regex "from" "(?i)groups\.google\.com" {
Error: invalid regular expression '(?i)groups\.google\.com' for regex match: invalid preceding regular expression
Example 3 — header :regex test with anchoring:
if header :regex "subject" "^(?i)(re|fwd):" {
Error: invalid regular expression '^(?i)(re|fwd):' for regex match: invalid preceding regular expression
All errors follow the same pattern: the (?i) inline flag for case-insensitive matching is rejected regardless of its position in the expression or the header being tested.
The full require statement at the top of the script is:
require ["fileinto", "reject", "vacation", "regex", "copy", "body", "variables", "imap4flags", "editheader"];
sieve-test is invoked as follows:
sieve-test
-x "fileinto regex copy body variables imap4flags editheader"
-t /tmp/trace.txt
~/sieve-test/rules/v4_0_13.sieve
<mail.eml>Dovecot version: 2:2.4.4-5+ubuntu24.04 (from repo.dovecot.org) Ubuntu: 24.04.3 LTS (Noble), WSL2
Thank you very much for looking into this.
Best regards, Michael Merz michael.merz@wtnet.de
Michael Merz Bargkoppel 15, 22844 Norderstedt Mobil 0172 4049171
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 19:16 An: michael.merz@wtnet.de; Michael Merz via dovecot <dovecot@dovecot.org> Cc: Stephan Bosch <stephan@rename-it.nl> Betreff: Re: AW: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
Build options does not include all build options, unfortunately. "invalid preceding regular expression" means the PCRE is available, the error would be clear that there is no PCRE support if it was missing.
Can you provide the exact regular expression, and how you are using it?
Aki
On 10/07/2026 20:06 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Hello Aki,
Thank you for the pointer to https://repo.dovecot.org. I have now installed Dovecot 2.4.4 from the official repository on Ubuntu 24.04 LTS (Noble) and can confirm that the packages are available and install correctly. However, checking the build options shows that PCRE support is not included:
$ dovecot --build-options Build options: ioloop=epoll notify=inotify experimental-imap4rev2 openssl io_block_size=8192 SQL driver plugins: mysql postgresql sqlite Passdb: ldap pam passwd passwd-file sql Userdb: ldap(plugin) passwd prefetch passwd-file sql
There is no PCRE entry, and sieve-test still rejects all (?i) inline flags in regex expressions with "invalid preceding regular expression". May I ask: is PCRE support intentionally not included in the official Dovecot/Pigeonhole packages, or is this an oversight in the build configuration? If PCRE is not planned to be included, is there a recommended alternative approach for achieving case-insensitive regex matching in Pigeonhole's sieve-test that would be compatible with Cyrus IMAPd's PCRE-based regex syntax?
Thank you again for your help. Best regards, Michael Merz michael.merz@wtnet.de
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 06:51 An: Michael Merz <michael.merz@wtnet.de>; Michael Merz via dovecot <dovecot@dovecot.org>; Stephan Bosch <stephan@rename-it.nl> Betreff: Re: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
You can get 2.4.4 packages for ubuntu 24.04 from https://repo.dovecot.org
Aki
On 09/07/2026 22:21 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Dear Stephan,
Thank you very much for your quick and helpful response.
Regarding point 1 (PCRE support), your comment that Ubuntu 24.04 is "likely stuck at a quite old version of Pigeonhole" raises a follow-up question:
From which version of Pigeonhole onwards is PCRE support included by default (i.e. compiled in without requiring an explicit --with-pcre flag)? And is there an official repository, PPA, or recommended way to obtain a more recent Pigeonhole/dovecot-sieve binary for Ubuntu 24.04 LTS that would include PCRE support out of the box?
Regarding point 2 (Return-Path / envelope test): thank you for the pointer. I understand that the envelope test would be the RFC-compliant alternative within Pigeonhole. However, since my ruleset runs on a Cyrus backend where the address test on Return-Path works fine, this would mean maintaining two different versions of the ruleset — one for production (Cyrus) and one for offline testing (Pigeonhole). That somewhat defeats the purpose of offline testing, so I mention it only for completeness.
The key question therefore remains whether a PCRE-enabled Pigeonhole binary is realistically obtainable for Ubuntu 24.04, as that would resolve the main blocker.
Thank you again for your time.
Best regards, Michael Merz
von meinem iPad Pro 4Gen gesendet
> Am 09.07.2026 um 18:39 schrieb Stephan Bosch <stephan@rename-it.nl>: > > > 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. >> >> >> >> Checkingdovecot --build-optionsshows 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 theaddresstest >> >> >> >> 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 theheadertest 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 -- dovecot@dovecot.org To unsubscribe >> send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Stephan and Aki,
Thanks to both of you. I could finally set up an offline-test environment for sieve-test. It works and is of great help. I really appreciate your support. Best wishes Michael (and Claude AI who supported me in parallel)
-----Ursprüngliche Nachricht----- Von: Stephan Bosch via dovecot <dovecot@dovecot.org> Gesendet: Samstag, 11. Juli 2026 14:44 An: dovecot@dovecot.org Betreff: Re: AW: AW: AW: AW: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
Op 11-7-2026 om 12:28 schreef Michael Merz via dovecot:
Subject: Re: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
Hello Aki,
Great progress: after adding -o mail_driver=maildir, the (?i) PCRE errors are completely gone. Thank you! The only remaining issue is the return-path restriction in the address test:
error: specified header 'return-path' is not allowed for the address test.
This affects several rules in my ruleset that use constructs like:
if address :domain :is "return-path" "example.com" { }
As you mentioned earlier, the envelope test would be the RFC-compliant alternative. However, since my ruleset runs on a Cyrus IMAPd backend (which accepts return-path in the address test), switching to envelope would mean maintaining two separate versions of the ruleset — one for production and one for offline testing — which defeats the purpose.
Is there a sieve-test option (e.g. via -o or a config setting) that would allow or relax the return-path restriction in the address test, so that sieve-test can process the script without modification?
Thank you again for your continued support — we are very close to a working solution!
There are no such options to evade this check. However, currently you can still commit an atrocity like this:
require "regex"; require "variables";
set "hdr" "return-path";
if address "${hdr}" "frop@example.com" { discard; }
Still, since this is an omission, I cannot guarantee that this will remain possible in the future.
Regards,
Stephan.
Best regards, Michael Merz michael.merz@wtnet.de
-----Ursprüngliche Nachricht----- Von: Aki Tuomi <aki.tuomi@open-xchange.com> Gesendet: Samstag, 11. Juli 2026 11:38 An: michael.merz@wtnet.de; Michael Merz via dovecot <dovecot@dovecot.org> Cc: Stephan Bosch <stephan@rename-it.nl> Betreff: Re: AW: AW: AW: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
Even if you use it standalone, having a small dovecot.conf file, configured, might work. Anyways, -o mail_driver=maildir (as it suggests) would help. mail_location was split into multiple settings in 2.4.
Aki
On 11/07/2026 10:15 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Hello Aki,
Good news: after installing Dovecot 2.4.4 from repo.dovecot.org, the (?i) regex errors are gone. PCRE appears to be working correctly now. However, sieve-test now fails with a different error:
sieve-test: Fatal: mail_driver not set and autodetection failed: Mail storage autodetection failed (home=/home/micha, mail_path=)
- Set mail_driver explicitly
I am invoking sieve-test as follows:
sieve-test
-x "fileinto regex copy body variables imap4flags editheader"
-e
-t /tmp/trace.txt
~/sieve-test/rules/v4_1_7.sieve
<mail.eml>I have also tried -o mail_location=maildir:~/sieve-test/mailbox and -o plugin/mail_location=maildir:~/sieve-test/mailbox, both of which produce "Unknown setting" errors.
I am not running a Dovecot mail server — I am using sieve-test purely as an offline testing tool without any Dovecot server configuration.
Could you advise on the correct way to set mail_driver (or mail_location) for sieve-test 2.4.4 in a standalone/serverless context?
Thank you very much.
Best regards, Michael Merz michael.merz@wtnet.de
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 19:44 An: michael.merz@wtnet.de; Michael Merz via dovecot <dovecot@dovecot.org> Cc: Stephan Bosch <stephan@rename-it.nl> Betreff: Re: AW: AW: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
Although I did test this:
MATCH_CASE("(?i)hello", "HELLO"), MATCH_CASE("^(?i)\\[(.*)\\] (.*)$", "[acme-users][fwd]: hello, world"),
and did not get any complaints from the library itself. So there is some other reason for it to fail.
Aki
On 10/07/2026 20:40 EEST Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
A sieve style of doing (?i) is
if header :regex :comparator "i;ascii-casemap" "from" "<regex>" { }
you can also use unicode-casemap for unicode.
Aki
On 10/07/2026 20:24 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Hello Aki,
Thank you for the clarification — that is very encouraging news. Here are concrete examples of the regular expressions used in my ruleset, along with the sieve-test error messages they produce:
Example 1 — header :regex test:
if header :regex "X-Spam-Status" "(?i)score=[1-9]" {
Error: invalid regular expression '(?i)score=[1-9]' for regex match: invalid preceding regular expression
Example 2 — header :regex test:
if header :regex "from" "(?i)groups\.google\.com" {
Error: invalid regular expression '(?i)groups\.google\.com' for regex match: invalid preceding regular expression
Example 3 — header :regex test with anchoring:
if header :regex "subject" "^(?i)(re|fwd):" {
Error: invalid regular expression '^(?i)(re|fwd):' for regex match: invalid preceding regular expression
All errors follow the same pattern: the (?i) inline flag for case-insensitive matching is rejected regardless of its position in the expression or the header being tested.
The full require statement at the top of the script is:
require ["fileinto", "reject", "vacation", "regex", "copy", "body", "variables", "imap4flags", "editheader"];
sieve-test is invoked as follows:
sieve-test
-x "fileinto regex copy body variables imap4flags editheader"
-t /tmp/trace.txt
~/sieve-test/rules/v4_0_13.sieve
<mail.eml>Dovecot version: 2:2.4.4-5+ubuntu24.04 (from repo.dovecot.org) Ubuntu: 24.04.3 LTS (Noble), WSL2
Thank you very much for looking into this.
Best regards, Michael Merz michael.merz@wtnet.de
Michael Merz Bargkoppel 15, 22844 Norderstedt Mobil 0172 4049171
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 19:16 An: michael.merz@wtnet.de; Michael Merz via dovecot <dovecot@dovecot.org> Cc: Stephan Bosch <stephan@rename-it.nl> Betreff: Re: AW: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
Build options does not include all build options, unfortunately. "invalid preceding regular expression" means the PCRE is available, the error would be clear that there is no PCRE support if it was missing.
Can you provide the exact regular expression, and how you are using it?
Aki
On 10/07/2026 20:06 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Hello Aki,
Thank you for the pointer to https://repo.dovecot.org. I have now installed Dovecot 2.4.4 from the official repository on Ubuntu 24.04 LTS (Noble) and can confirm that the packages are available and install correctly. However, checking the build options shows that PCRE support is not included:
$ dovecot --build-options Build options: ioloop=epoll notify=inotify experimental-imap4rev2 openssl io_block_size=8192 SQL driver plugins: mysql postgresql sqlite Passdb: ldap pam passwd passwd-file sql Userdb: ldap(plugin) passwd prefetch passwd-file sql
There is no PCRE entry, and sieve-test still rejects all (?i) inline flags in regex expressions with "invalid preceding regular expression". May I ask: is PCRE support intentionally not included in the official Dovecot/Pigeonhole packages, or is this an oversight in the build configuration? If PCRE is not planned to be included, is there a recommended alternative approach for achieving case-insensitive regex matching in Pigeonhole's sieve-test that would be compatible with Cyrus IMAPd's PCRE-based regex syntax?
Thank you again for your help. Best regards, Michael Merz michael.merz@wtnet.de
-----Ursprüngliche Nachricht----- Von: Aki Tuomi via dovecot <dovecot@dovecot.org> Gesendet: Freitag, 10. Juli 2026 06:51 An: Michael Merz <michael.merz@wtnet.de>; Michael Merz via dovecot <dovecot@dovecot.org>; Stephan Bosch <stephan@rename-it.nl> Betreff: Re: sieve-test (Pigeonhole) on Ubuntu: PCRE support and address test restrictions on Return-Path
You can get 2.4.4 packages for ubuntu 24.04 from https://repo.dovecot.org
Aki
On 09/07/2026 22:21 EEST Michael Merz via dovecot <dovecot@dovecot.org> wrote:
Dear Stephan,
Thank you very much for your quick and helpful response.
Regarding point 1 (PCRE support), your comment that Ubuntu 24.04 is "likely stuck at a quite old version of Pigeonhole" raises a follow-up question:
From which version of Pigeonhole onwards is PCRE support included by default (i.e. compiled in without requiring an explicit --with-pcre flag)? And is there an official repository, PPA, or recommended way to obtain a more recent Pigeonhole/dovecot-sieve binary for Ubuntu 24.04 LTS that would include PCRE support out of the box?
Regarding point 2 (Return-Path / envelope test): thank you for the pointer. I understand that the envelope test would be the RFC-compliant alternative within Pigeonhole. However, since my ruleset runs on a Cyrus backend where the address test on Return-Path works fine, this would mean maintaining two different versions of the ruleset — one for production (Cyrus) and one for offline testing (Pigeonhole). That somewhat defeats the purpose of offline testing, so I mention it only for completeness.
The key question therefore remains whether a PCRE-enabled Pigeonhole binary is realistically obtainable for Ubuntu 24.04, as that would resolve the main blocker.
Thank you again for your time.
Best regards, Michael Merz
von meinem iPad Pro 4Gen gesendet
> Am 09.07.2026 um 18:39 schrieb Stephan Bosch <stephan@rename-it.nl>: > > > 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. >> >> >> >> Checkingdovecot --build-optionsshows 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 theaddresstest >> >> >> >> 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 theheadertest 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 -- dovecot@dovecot.org To unsubscribe send >> an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
participants (4)
-
Aki Tuomi
-
Michael Merz
-
michael.merz＠wtnet.de
-
Stephan Bosch