64 lines
2.6 KiB
Plaintext
64 lines
2.6 KiB
Plaintext
MBOX-Line: From David.Harris at pmail.gen.nz Tue Apr 7 16:38:25 2015
|
|
To: imap-protocol@u.washington.edu
|
|
From: David Harris <David.Harris@pmail.gen.nz>
|
|
Date: Fri Jun 8 12:34:54 2018
|
|
Subject: [Imap-protocol] SEARCH semantics
|
|
Message-ID: <55246A71.27553.323D151D@David.Harris.pmail.gen.nz>
|
|
|
|
I'm in the process of completely rewriting the SEARCH logic in my IMAP server -
|
|
the old code was done in a hurry and was, quite frankly, ridiculously bad, but that's
|
|
another story.
|
|
|
|
As I get into testing cases, I've come across a number of areas where RFC3501
|
|
and the various sub-documents that I know about are... uh, "vague". I'd like to get a
|
|
take on how other implementors view them.
|
|
|
|
1: BODY: When a SEARCH BODY expression is issued, how should "BODY" be
|
|
interpreted? Is there an assumption that the server should choose the best
|
|
candidate for a displayable message body, parse and normalize it, then search
|
|
that? Or should it simply be taken as a raw scan of the message? How much
|
|
unarmouring and character set normalization is assumed?
|
|
|
|
2: Headers: when any of the header search expressions is issued, is the
|
|
assumption that the raw header should be searched, or should RFC2047
|
|
encoded-words be reduced and normalized before attempting the comparison?
|
|
|
|
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?
|
|
|
|
4: I'm pretty sure I'm right on this one, but the following expression:
|
|
|
|
xx SEARCH OR (<exp1> <exp2> <exp3>) exp4
|
|
|
|
will only result in a match if either <exp4> is a match, or ALL of <exp1>, <exp2>
|
|
and <exp3> are a match. Could someone wiser than me confirm this? I'm
|
|
assuming there is no way to perform a search with a long list of OR conditions
|
|
without doing a lot of calisthenics on the search string (multiple OR conditions
|
|
strung together).
|
|
|
|
I apologize if any of these are dealt with in RFCs outside RFC3501 - I struggle to
|
|
keep track of all the various sub-documents relating to the protocol these days.
|
|
|
|
Thanks in advance for any advice.
|
|
|
|
Cheers!
|
|
|
|
-- David --
|
|
|
|
------------------ David Harris -+- Pegasus Mail ----------------------
|
|
Box 5451, Dunedin, New Zealand | e-mail: David.Harris@pmail.gen.nz
|
|
Phone: +64 3 453-6880 | Fax: +64 3 453-6612
|
|
|
|
Schoolboy howler for the day:
|
|
"A census taker is the man who goes from home to home
|
|
increasing the population."
|
|
|
|
|
|
|