wasm-demo/demo/ermis-f/imap-protocol/cur/1600095006.22592.mbox:2,S

46 lines
1.9 KiB
Plaintext

MBOX-Line: From imap at maclean.com Thu Apr 9 08:29:08 2015
To: imap-protocol@u.washington.edu
From: Pete Maclean <imap@maclean.com>
Date: Fri Jun 8 12:34:54 2018
Subject: [Imap-protocol] SEARCH semantics
In-Reply-To: <5526983D.4000503@isode.com>
References: <201504091259.t39CxfHJ007474@mxout24.cac.washington.edu>
<5526983D.4000503@isode.com>
Message-ID: <mailman.23.1528486494.22076.imap-protocol@mailman13.u.washington.edu>
Hmm, maybe I got it wrong. I don't recall what originally led me to
think that SEARCH was supposed to be strictly string-based but I do
observe that RFC 3501 states:
In all search keys that use strings, a message matches the key if
the string is a substring of the field. The matching is
case-insensitive.
At 11:18 AM 4/9/2015, Alexey Melnikov wrote:
>On 09/04/2015 13:59, Pete Maclean wrote:
>>If I understand them correctly, using such an indexer means
>>providing a word-based search. Now, as I noted in another message,
>>that might be a very good choice these days since that is what a
>>lot of people are accustomed to. But IMAP promises a string-based
>>search for which you would want to use hashes based on n-grams instead.
>I was under impression that Mark Crispin thought that being more
>flexible when searching (i.e. using word-based search) was quite
>acceptable according to RFC 3501.
>
>>At 02:31 PM 4/8/2015, Hoa V. Dinh wrote:
>>>You probably want to use a full text indexer such as Lucene /
>>>Elastic Search in this case.
>>>It will prevent the server from iterating on each email.
>>>
>>>--
>>>Hoa V. Dinh
>>>
>>>On Wednesday, April 8, 2015 at 5:28 AM, Bron Gondwana wrote:
>>>>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.