IMAP Search Behavior When Enabled Through Indexing and Search Service

Skip to end of metadata
Go to start of metadata

IMAP Search Behavior When Enabled Through Indexing and Search Service

The Indexing and Search Service (ISS) implementation and Messaging Server IMAP SEARCH implementation differ in their results in several ways. These differences come from fundamentally distinct approaches to the problems of search. The RFC 3501 standard is based on a simple substring comparison, while more recently developed search systems such as ISS and Google are based on indexing and lookup. The former is simple but expensive when searching large amounts of data, while the latter is specifically designed to speed up searches over massive amounts of data, at the expense of lost matching capability.

The following descriptions explain the current differences in the results when you use the ISS interface to perform the search.

Topics:

Substring Matches

The IMAP standard (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.

The ISS implementation of search is not based on comparing substrings of the field. Rather, it is based on indexing technology, which intentionally ignores parts of the field string and uses index lookup for string comparisons to dramatically speed up the search process.

The following table contains examples of search strings that match when using Messaging Server IMAP SEARCH but do not match when using ISS.

IMAP SEARCH Strings That Do Not Match to ISS Search

Query Reason for ISS Nonmatch
+subject:, Punctuation marks are ignored.
+body:the Many small stopwords (such as "the") are ignored.
+to:geo Full tokens, not substrings, are matched (for example George, Georg, Georgie, Ingeo).

These examples are all standard conformant queries. These are fundamental differences. Some queries could be modified by ISS to support the last example (by using stems and/or wildcards). In general, though, a string match does not occur because too much information is thrown away.

Quoted Phrases

The Messaging Server IMAP SEARCH "collapses" white spaces whereas ISS does not. For example, searching for "rent or buy" in Messaging Server IMAP SEARCH returns results containing "rentorbuy" but ISS does not return such results.

Searches in Foreign Alphabets

A search including an accented character (foreign alphabet) returns only an exact match on that character in ISS. Messaging Server IMAP SEARCH returns a match on the character with and without the accent.

Which Searches Are Handled by ISS and Which Searches Are Handled Internally by IMAP SEARCH

The ISS interface does not map all IMAP SEARCH queries:

  • Searches containing only "BODY," "TEXT," "TO," "FROM," "CC," "BCC," and "SUBJECT" fields are translated into ISS searches.
  • Searches that contain "OLDER," "YOUNGER," "HEADER," "ANNOTATION," or "MODSEQ" fields are not sent to ISS.
  • Any search that contains nested "OR" clauses is not sent to ISS.
  • Finally, any other fields in a search query cause the Messaging Server IMAP SEARCH implementation to perform the search.
Note
Currently, you either enable or do not enable ISS on IMAP for all search queries. You cannot select a finer granularity of search method, at the client, query, or account level, to use both ISS and Messaging Server IMAP SEARCH features in the same IMAP server.

For more information about constructing ISS search queries, see Indexing and Search Service Query and Sort Criteria Summary.

Handling Search Errors and Timeouts

The search is performed by IMAP SEARCH under the following conditions, even if the search query would normally be an ISS search:

  • If ISS encounters an error, for example, a user has not yet been indexed
  • If the ISS search query times out
Labels:
indexsearchservice indexsearchservice Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.