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 <[email protected]> Gesendet: Samstag, 11. Juli 2026 14:44 An: [email protected] 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}" "[email protected]" { discard; } Still, since this is an omission, I cannot guarantee that this will remain possible in the future. Regards, Stephan. > > Best regards, > Michael Merz > [email protected] > > -----Ursprüngliche Nachricht----- > Von: Aki Tuomi <[email protected]> > Gesendet: Samstag, 11. Juli 2026 11:38 > An: [email protected]; Michael Merz via dovecot > <[email protected]> > Cc: Stephan Bosch <[email protected]> > 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 <[email protected]> >> 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 >> [email protected] >> >> -----Ursprüngliche Nachricht----- >> Von: Aki Tuomi via dovecot <[email protected]> >> Gesendet: Freitag, 10. Juli 2026 19:44 >> An: [email protected]; Michael Merz via dovecot >> <[email protected]> >> Cc: Stephan Bosch <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >>>> 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 >>>> [email protected] >>>> >>>> Michael Merz >>>> Bargkoppel 15, 22844 Norderstedt >>>> Mobil 0172 4049171 >>>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: Aki Tuomi via dovecot <[email protected]> >>>> Gesendet: Freitag, 10. Juli 2026 19:16 >>>> An: [email protected]; Michael Merz via dovecot >>>> <[email protected]> >>>> Cc: Stephan Bosch <[email protected]> >>>> 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 <[email protected]> >>>>> 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 >>>>> [email protected] >>>>> >>>>> -----Ursprüngliche Nachricht----- >>>>> Von: Aki Tuomi via dovecot <[email protected]> >>>>> Gesendet: Freitag, 10. Juli 2026 06:51 >>>>> An: Michael Merz <[email protected]>; Michael Merz via dovecot >>>>> <[email protected]>; Stephan Bosch <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 <[email protected]>: >>>>>>> >>>>>>> >>>>>>> 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 -- [email protected] To unsubscribe send >>>>>>>> an email to [email protected] >>>>>> _______________________________________________ >>>>>> dovecot mailing list -- [email protected] To unsubscribe send >>>>>> an email to [email protected] >>>>> _______________________________________________ >>>>> dovecot mailing list -- [email protected] To unsubscribe send an >>>>> email to [email protected] >>>>> >>>>> _______________________________________________ >>>>> dovecot mailing list -- [email protected] To unsubscribe send an >>>>> email to [email protected] >>>> _______________________________________________ >>>> dovecot mailing list -- [email protected] To unsubscribe send an >>>> email to [email protected] >>>> >>>> _______________________________________________ >>>> dovecot mailing list -- [email protected] To unsubscribe send an >>>> email to [email protected] >> _______________________________________________ >> dovecot mailing list -- [email protected] To unsubscribe send an >> email to [email protected] >> >> _______________________________________________ >> dovecot mailing list -- [email protected] To unsubscribe send an >> email to [email protected] > _______________________________________________ > dovecot mailing list -- [email protected] To unsubscribe send an > email to [email protected] _______________________________________________ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
