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
[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]
