Subject: UW imapd bug in handling UNKEYWORD searches

From: Mark Crispin <[email-masked]>
Date: Tue, 19 Aug 2003 22:26:15 -0700 (PDT)

We recently discovered a longstanding bug in the c-client library, and
hence in UW imapd, having to do with searches which have multiple
UNKEYWORD specifiers.

The bug is that a search command such as:
	tag SEARCH UNKEYWORD foo UNKEYWORD bar
is implemented internally as if the command was:
	tag SEARCH NOT (KEYWORD foo KEYWORD bar)

AND and NOT are not commutative.  Oops...  :-(

We discovered that when one of my co-workers observed that multiple
UNKEYWORD criteria in a SEARCH seemed to be ORing instead of ANDing.

This is fixed in the latest imap-2003 development snapshot, but it will
probably take a long time before older versions of c-client and imapd are
rooted out.  If your client does not support keywords, or does not ever do
a SEARCH with more than one UNKEYWORD specification.  Since nobody has
ever reported this before, probably nobody does such a thing.

Fortunately, there is a workaround.  Instead of using UNKEYWORD, use NOT
KEYWORD, e.g.
	tag SEARCH NOT KEYWORD foo NOT KEYWORD bar
which will work in both broken and fixed versions of UW imapd.

If, by some misfortune, your client does multiple UNKEYWORD and depends
upon the broken behavior (and never was used with a working server...),
you need to use OR, e.g.:
	tag SEARCH OR UNKEYWORD foo UNKEYWORD bar

A simple
	tag SEARCH UNKEYWORD foo
works just fine in all versions.  The problem is only if you do more than
one.

-- a very embarassed Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
-- 
-----------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/imap-list.html
-----------------------------------------------------------------