MBOX-Line: From brong at fastmail.fm  Wed Apr  8 05:28:56 2015
To: imap-protocol@u.washington.edu
From: Bron Gondwana <brong@fastmail.fm>
Date: Fri Jun  8 12:34:54 2018
Subject: [Imap-protocol] SEARCH semantics
In-Reply-To: <c94a9300-489f-4fca-87e6-992ccc1221e8@gulbrandsen.priv.no>
References: <55246A71.27553.323D151D@David.Harris.pmail.gen.nz>
	<c94a9300-489f-4fca-87e6-992ccc1221e8@gulbrandsen.priv.no>
Message-ID: <1428496136.932088.250634641.1291461C@webmail.messagingengine.com>

On Wed, Apr 8, 2015, at 06:05 PM, Arnt Gulbrandsen wrote:
> David Harris writes:
> > 3: The following search is valid, according to the syntax in RFC3501:
> >
> >    xx SEARCH OR OR <exp1> <exp2> <exp3>
> >
> > and allows an OR expression to cover three terms instead of 
> > just two. As such, it 
> > seems quite useful, but it would certainly have mystified my 
> > old search code (it was 
> > rubbish, as I've pointed out), and I was wondering how 
> > generally safe it would be to 
> > use this type of expression?
> 
> I've seen this kind of thing many times, e.g. OR OR FROM x TO x CC x, and I 
> think it's fairly widely used. IIRC the Symantec IMAP proxy uses nested ORs 
> en masse.
> 
> I agree about the vagueness with regard to searching. My best advice is to 
> do what seems useful to users, and make searching inclusive rather than 
> exact.

An important thing to be aware of - if you have iPhone users. iOS since version 7
has done a BODY search on every folder if you do a search.  That's prohibitively
expensive if you're scanning emails every time.

We implemented fuzzy matching support, and we just do a client quirk (that's right,
we use ID for evil) to turn a regular BODY search into a FUZZY body search,
because the alternative is a shitty experience for iPhone users.

Bron.

-- 
  Bron Gondwana
  brong@fastmail.fm