Cross-Mailbox Search: RFC, CLI and API Guide

Cross-mailbox search usually starts with a simple request: find the same message, phrase, or sender across several inboxes. The safe implementation depends on where those mailboxes live, how often the search runs, and whether the result may become evidence or trigger deletion.

For an occasional administrator-led investigation, use the platform's native search or eDiscovery tool. For a recurring product workflow, query each authorised mailbox through an API, record the scope and cursor for every pass, and keep notification separate from state reconciliation.

Choose the method by mailbox platform

This distinction prevents a common mistake: treating every cross-mailbox job as the same query with different syntax. An incident response purge, a legal discovery export, and an agent checking customer mailboxes need different authority, audit records, and failure handling.

RFC 6237 was replaced by RFC 7377

RFC 6237 introduced an experimental IMAP4 multimailbox SEARCH extension in 2011. RFC 7377 later obsoleted it and defined the standards-track MULTISEARCH capability. A client must check the server's advertised capabilities before sending the command; ordinary IMAP SEARCH still applies only to the selected mailbox.

The current extension lets a client send ESEARCH with source options such as mailboxes, subtree, or personal. Responses carry mailbox and UID validity correlators, so results remain tied to the mailbox that produced them. If the server implements IMAP ACLs, the user needs read rights for every searched mailbox, and mailboxes without sufficient rights are omitted.

C: A1 ESEARCH IN (mailboxes "Inbox" "Archive") subject "invoice"

Treat an omitted mailbox as a scope result that needs review. It may mean the mailbox did not match, was not selectable, or was outside the authenticated user's rights. Your audit record should capture the requested scope and the returned scope separately.

Zimbra zmmboxsearch is useful for bounded admin work

The Zimbra Collaboration 8.8.15 administrator guide documents zmmboxsearch for searching messages and attachments across a comma-separated mailbox list. The required arguments are --mbox and --query; --dir writes matched messages to a directory. The default result limit is 25, and --offset controls where the next result page begins.

zmmboxsearch -m user1@example.com,user2@example.com -q "in:inbox subject:invoice" -d /var/tmp/review

Pilot the command with a small authorised mailbox set, compare the returned count with a manual sample, and page until the result set is exhausted. Use a controlled output location and preserve the query, mailbox list, execution time, result count, and file hashes when the export may be reviewed later.

Exchange Online searches belong in Purview eDiscovery

Microsoft's current guidance places organisation-wide mailbox search in Purview eDiscovery. A case can search Exchange Online mailboxes, show statistics and samples, place content on hold, and export results. The older Export-Mailbox examples belong to Exchange Server 2007 and should not be copied into a current Exchange Online runbook.

Deletion deserves its own reviewed workflow. Microsoft's current search-and-delete process uses eDiscovery permissions and a tightly scoped query. Never add an old -DeleteContent flag to an unverified search pipeline or assume that a successful preview proves the purge scope is safe.

Keep the search auditable

The quiet failures matter most. Default limits can truncate a result set, an ACL can remove a mailbox from scope, and a timeout can leave a batch incomplete without making the first page look wrong. Count first where the platform supports it, page deterministically, and record partial completion as a failure that needs recovery.

When a mailbox API is the better fit

Use an API when the search is part of software that runs repeatedly rather than a one-off administrator task. The Sendmux Mailbox API can filter GET /mailbox/messages, count matches with GET /mailbox/messages/count, and return previews through GET /mailbox/messages/search-snippets. These endpoints target one mailbox per request.

Connected-app tokens may be granted several mailboxes. A client can list the granted set with GET /mailbox/mailboxes, pass one selected mailbox_id on each request, and iterate with bounded concurrency. Sendmux does not currently expose one cross-mailbox search API call, so the client owns fan-out, per-mailbox cursors, retries, and result aggregation.

For recurring searches, store one checkpoint per mailbox. A failed request should resume from that mailbox's last accepted cursor without repeating completed work elsewhere. Keep the original query and grant snapshot with the aggregate result so a later reviewer can see exactly which mailboxes were included.

A safe rollout sequence

Start with two authorised mailboxes and one query whose expected matches you can verify manually. Confirm permissions, limits, paging, export location, and audit output. Then increase the batch size while watching latency and error rates. Before any deletion path goes live, require a separate approval step and test the recovery procedure on non-production data.

The practical dividing line is repetition. Native tools and eDiscovery fit controlled human investigations. A mailbox API fits a service that must run the same bounded search reliably, provided the client preserves per-mailbox scope instead of pretending several inboxes are one undifferentiated store.

Primary references

The protocol details come from RFC 7377, which obsoletes RFC 6237. Zimbra syntax and defaults come from the Zimbra Collaboration 8.8.15 Administrator Guide. Exchange Online guidance comes from Microsoft Purview eDiscovery. Current Sendmux request scope and filters are documented in mailbox targeting and message search and batch operations.