Re: Complex virtual folder

Greg Bognar <[email protected]> Sat, 05 Jan 2019 22:48:25 +0100
Newsgroups gmane.mail.wanderlust.general
Message-ID <87k1ji4vyu.wl-greg.bognar__17216.0819908187$1546724891$gmane$org@startmail.com>
Searching for this error lead me to several (unrelated) reports, all of which
seemed to be about Exchange servers.  That reminded me that I tried the original
search on an Exchange server.  The command works without any problems on the
imap servers of Startmail.

So perhaps the problem is not with WL, but with the server?

On Fri  4 Jan 2019 at 00:23 Greg A. Woods wrote:
> At Thu, 03 Jan 2019 12:21:02 +0100, Greg Bognar <[email protected]> wrote:
> Subject: Complex virtual folder
> >
> > I'm trying to create a complex virtual folder by using the 'OR' keyword (i.e.,
> > OR From <keyword> To <keyword>).  However, I'm getting the following error (from
> > *Messages*):
> >
> > elmo-imap4-accept-ok: IMAP error: Command Argument Error. 11
> 
> I tried something similar with the 'AND' keyword (and flags with
> 'Flag'), but I also encountered an IMAP error.
> 
> 	elmo-imap4-accept-ok: IMAP error: Invalid Search criteria
> 
> (That's from my Cyrus IMAPd)
> 
> However because I was using 'AND' I had a work-around:  What I ended up
> doing was to create a nested virtual folder from within the first one:
> 
>     V Flag<CR> FirstFlag<CR> V Flag<CR> 2ndFlag<CR>
> 
> As a result I didn't try turning on IMAP debugging to see what was being
> sent to the server.
> 
> Interestingly just now when I tried it with a real "Flag" ("Important",
> aka IMAP "\Flagged") and a fake flag ("Answered"), it worked.  More
> about this below....
> 
> An "OR" of "From" strings to Gmail produces a slightly different error
> message, as might be expected:
> 
> 	elmo-imap4-accept-ok: IMAP error: Could not parse command
> 
> When I try an "OR" of "From" strings on my wl-en folder:
> 
> 	V OR<CR> From<CR> Greg<CR> From<CR> John<CR>
> 
> it again gives the same error:
> 
> 	elmo-imap4-accept-ok: IMAP error: Invalid Search criteria
> 
> But when I try with a direct IMAP command it works just fine:
> 
> . SELECT INBOX/Lists-IN/wl-en-l
> * FLAGS (\Answered \Flagged \Draft \Deleted \Seen $NotJunk $Junk JunkRecorded NotJunk $Forwarded Forwarded)
> * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen $NotJunk $Junk JunkRecorded NotJunk $Forwarded Forwarded \*)]
> * 181 EXISTS
> * 0 RECENT
> * OK [UIDVALIDITY 1197650871]
> * OK [UIDNEXT 2868]
> . OK [READ-WRITE] Completed
> . SEARCH OR FROM "Greg" FROM "John"
> * SEARCH 9 31 32 33 34 37 40 42 44 47 49 50 51 56 58 59 62 64 65 68 70 77 79 98 133 135 142 146 152 153 159 176 178 179 181
> . OK Completed (35 msgs in 0.000 secs)
> 
> So, there must be a bug in the elmo-imap4 code....
> 
> Indeed now with `elmo-imap4-debug' set I see:
> 
> [15:09:04] <-- elmo-imap4311 uid search CHARSET us-ascii OR  ( from Greg ) ( from John )
> [15:09:04] -> elmo-imap4311 BAD Invalid Search criteria
> 
> The parenthesis, if indeed they are being sent as they appear above, are
> invalid syntax for IMAPv4 "SEARCH".
> 
> I can also do direct (IMAP) "AND" and "OR" searches on flags:
> 
> . SEARCH KEYWORD NotJunk KEYWORD JunkRecorded
> * SEARCH
> . OK Completed (0 msgs in 0.000 secs)
> . SEARCH OR KEYWORD NotJunk KEYWORD JunkRecorded
> * SEARCH 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 80 88 93 94 95 98 102 103 104 115 116 118 119 122 123 126 127 128 129 130 132 133 134 135 139 140 146 147 149 150 152
> . OK Completed (84 msgs in 0.000 secs)
> 
> So, I'm reasonably certain elmo-imap4 is not writing valid SEARCH
> commands to the server.
> 
> 
> > Am I doing something wrong?
> 
> So, the summary to this long story...  I don't think you are doing
> anything wrong!
> 
> --
> 						Greg A. Woods
> 						Planix, Inc.
> 
> <[email protected]>       +1 250 762-7675        http://www.planix.com/
> [2 OpenPGP Digital Signature <application/pgp-signature (7bit)>]
> No public key for 667D71B778BFF47F created at 2019-01-04T00:23:50+0100 using DSA