Feature Search

English · Tiếng Việt · 中文

Search

SkimMail searches in two tiers. Cache is a local full-text index and is instant. Server additionally asks your mail server, which is slower and can find mail SkimMail never downloaded. You choose between them with the two tabs under the search box.

Since 1.13.0 search returns your own mail only, and choosing Server in the unified inbox says what it needs instead of quietly answering a different question. 1.14.0 finished the job: 1.13.0 scoped what the server tier returns, not what it does — see below.

Cache — the default

Every message SkimMail has synced is in a local full-text index. Typing in the search box queries that index and nothing leaves the machine.

What it matches:

• the subject and the sender address, and nothing else. Message bodies are not indexed — the index has a column for them and SkimMail deliberately writes it empty, so searching for a phrase you remember from inside a message will not find it.
• word prefixes. inv matches invoice; typing more terms narrows the result, because all terms must match.

The result list is capped at 200 messages, newest first.

The tag: operator

Since 1.16.0. Type tag: followed by a tag name to filter by it — tag:finance, or tag:finance invoice to search within a tag, or tag:"to read" if the tag has a space. A bare tag: with nothing after it is left as ordinary text, so it does not clear your filter mid-keystroke.

It is parsed in the browser, before the query reaches the server, because the server's own tokenizer strips punctuation — sent as-is, tag:finance would reach the index as two ordinary words matching neither, not as an error. That is also why it is the only operator: there is no from:, no has:, no before: here, and adding one is a decision the product has not made, not an oversight.

Using it does the same thing as clicking a tag chip: it sets the tag filter that has existed since 1.4.1. tag:finance on its own — no other text — is a filter, not a search, and returns the same list the chip would. Typing free text alongside it searches within that filtered set, in either tier. The tag chip now stays visible in the toolbar while you search, so a filter can no longer narrow your results without you seeing why. See Tags for what a tag is and how one gets applied.

Server — one mailbox at a time

Press the Server tab and SkimMail also asks the mail server itself, which knows about mail older or larger than your local sync window.

• It searches the account's INBOX only.
• Matching headers are fetched into the cache, so they behave like any other message afterwards, and the rows that were genuinely new are tagged FROM SERVER in the result list.
• If the provider search fails — the account is offline, its egress is down, the server does not support the query — the failure is logged and you still get the cache results. It degrades rather than erroring.

It needs exactly one account. Searching the server across a unified inbox would mean opening one connection per mailbox, so SkimMail does not do it.

Until 1.13.0 the tab still looked active in the unified inbox and silently returned cache-only results. Now it shows a notice — "Server search runs one mailbox at a time, so the unified inbox cannot use it. Pick an account and this search re-runs there:" — followed by a button per account. Pressing one switches to that account and re-runs the same query as a server search.

Search is per-user — 1.13.0 for the results, 1.14.0 for the connection

On a multi-user instance before 1.13.0, the search box returned matches from every account on the server: subjects, sender addresses, preview lines and any cached AI summary. Any signed-in person could read them, including a viewer, which is the lowest role there is — and by naming another user's account id in the request they could aim the search at one particular person's mailbox.

1.13.0 restricts both halves of the query — which messages the index may return, and which rows may then be loaded — to accounts the asking user owns.

That fixed what the route returns and not what it does. The Server tier does more than read the index: it opens the named account's IMAP connection, using that account's saved password and its network route, runs your search string against the live mailbox, and writes the fetched headers into the database. Until 1.14.0 that path took the account id straight from the request without checking it. The results never came back to the caller — 1.13.0 had already scoped the index query — but the connection was still opened and the rows were still written, in somebody else's name. The account Test connection button had the same shape. Both are fixed in 1.14.0.

Single-user instances were never affected; there was nobody else's mailbox to open. If more than one person signs in to your instance, be on 1.14.0. See Users and roles.

Limits

Cache tier searches	subject + sender address
Server tier searches	the account's INBOX, through the provider
Result cap	200
Query syntax	terms are prefix-matched and AND-ed; the one operator is tag: (1.16.0), which takes quotes for a tag with a space
Scope	your own accounts only — results 1.13.0, the provider connection itself 1.14.0

• No message bodies, no attachment contents, no attachment names.
• No filter besides tag:. No from:, no date range, no "unread only", no sort control.
• Muted and snoozed mail is included. The inbox hides both; search answers the question you asked. See Muted and VIP senders.
• Full-text search behaves differently on MySQL than on SQLite and Postgres. MySQL is labelled Experimental in the setup wizard, and this is one of the reasons. See Configuration.
• A server search writes to your cache. Matching headers are stored, which is what makes them appear in ordinary lists afterwards; it also means a server search costs a provider connection.

What it does not do

• It does not search what you never synced, from the Cache tab. That is what the Server tab is for, and only for the INBOX of one account.
• It does not search folders other than INBOX on the server tier, even though the cache tier happily returns matches from every folder it has.
• It does not save searches, and there is no search history.
• It does not rank by relevance. Results are newest first, always.

See also

• Starred — the other way to get back to a message you remember marking
• Tags — what a tag is, and how the tag: operator sets the same filter as clicking a chip
• Users and roles — the per-user boundary this now respects
• Configuration — SYNC_DEPTH_DAYS, and the database dialects

---

SkimMail · skimmail@base101.app · 2026-09-15 · commit 767741a