Class MailboxSearchReader

Namespace

MailFathom.Application.Emails.SearchEmails

Assembly

MailFathom.Application.dll

Searches the local mailbox copy for text and returns one bounded, ranked window of results.

public sealed class MailboxSearchReader

Inheritance

object

MailboxSearchReader

Inherited Members

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.ReferenceEquals(object, object)

object.ToString()

Remarks

The use case owns everything between an unvalidated request and a window: it normalizes and bounds the structured filters, validates the free text, refuses an account this deployment does not serve, and decides the effective result count and the snippet bounds. Storage does none of that, and no protocol adapter repeats it.

It reaches no mail server. A search answers from what synchronization has already stored and what extraction has already indexed, which is what keeps an MCP read independent of IMAP availability, and it reports how current that copy is instead of pretending it is live.

It answers lexically or hybridly according to what the instance can do at the moment of the call, and reports which in the result. Nothing about the request selects between them: retrieval quality is a deployment's decision, and a caller able to ask for the lexical ranking of a hybrid instance would be asking for worse results with no way to know it.

Beside the mode it reports what semantic retrieval can do at all, so a lexical answer says whether this instance never embeds or is currently unable to. A search never fails because an embedding provider did, and never returns an empty window in place of one it could not rank semantically.

Because the index covers body text only, a word that appears solely inside an attachment payload matches nothing here. That is a deliberate limit of text extraction rather than something this use case works around, and the feature documentation states it so the behavior is not surprising.

A window is one of the points mail content leaves this deployment, so where a sensitive-content scanner is switched on the content of a result is scanned before the result is returned, and a scanner that cannot answer refuses the search rather than serving it unscanned. The guard is here rather than at the protocol boundary for the reason the authorization above it is: a second entrypoint over this use case inherits it instead of repeating it.

Constructors

MailboxSearchReader(IEmailSearchIndexReader, SemanticEmailSearch, ISynchronizationFreshnessReader, MailboxScopeResolver, EmailSearchSnippetBounds, SensitiveContentEgressGuard, IMailboxReadTelemetry)

Initializes the use case.

Methods

SearchEmailsAsync(SearchEmailsRequest, CancellationToken)

Searches for one window of ranked emails and publishes it to a caller outside this process.