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]
