Re: Complex virtual folder

At Fri, 04 Jan 2019 08:21:29 -0800, Erik Hetzner <[email protected]> wrote:
Subject: Re: Complex virtual folder
>
> I believe the intention is to keep the arguments to the OR search
> query properly separated when the arguments are themselves complex
> queries, e.g.:
>
> [23:52:30] <-- elmo-imap46 uid search CHARSET us-ascii OR  ( body foo ) ( from greg to john )
>
> (A query generate with: V OR body foo AND from greg to john)

Ah, yes, that makes a bit more sense.  The parenthesis around the first
search-key in your example above are unnecessary, but allowed, provided
they are not surrounded by extra spaces.

The ABNF from RFC3501 allows only very restrictive use of "SP" (space)
characters, with no repeats of SP allowed, and parenthesis may surround
one or more single-space-separated search-key elements, though the last
bit isn't written quite the way I would have written it.  Here's the
relevant bits, with the irrelevant bits removed:

search          = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key)
search-key      =
                  "OR" SP search-key SP search-key /
                  "(" search-key *(SP search-key) ")"

I would have written the last line as:

                  "(" 1*(SP search-key) ")"

(as per RFC 5234 Section 3.6)

I can confirm this would work with Cyrus IMAPd:

. SEARCH CHARSET us-ascii OR (BODY "foo") (FROM "greg" TO "wl-en")
* SEARCH 25 31 32 33 34 37 40 42 44 45 47 49 50 51 56 58 62 64 65 68 70 79 98 133 134 135 142 146 152 153 159 176 178 179 181 182 184 186 187
. OK Completed (39 msgs in 0.010 secs)
. SEARCH CHARSET us-ascii OR BODY foo (FROM greg TO wl-en)
* SEARCH 25 31 32 33 34 37 40 42 44 45 47 49 50 51 56 58 62 64 65 68 70 79 98 133 134 135 142 146 152 153 159 176 178 179 181 182 184 186 187
. OK Completed (39 msgs in 0.000 secs)


See how even extra spaces between search keys will foul it up:

. SEARCH CHARSET us-ascii OR  (BODY "foo")  (FROM "greg" TO "wl-en")
. BAD Invalid Search criteria


The Cyrus IMAP command parser is all hand-written C, with very strict
adherence to the RFC, and remaining relatively unchanged since 1994 (it
apparently already supported the enhancements added by RFC3501).

--
						Greg A. Woods
						Planix, Inc.

<[email protected]>       +1 250 762-7675        http://www.planix.com/

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCXDKOngAKCRBmfXG3eL/0
fzspAKC0J/BaYN1mEM3xTQwGa/SdB1PjIwCg10UPJtJ2U+dSJKe7uShkXaW2dy8=
=aHEV
-----END PGP SIGNATURE-----