47 lines
1.8 KiB
Plaintext
47 lines
1.8 KiB
Plaintext
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
|
|
|