Everything in Bichon is organized around accounts, and every account has one of three types. The type is not a flag or a setting: it decides what the account stores, whether it syncs, whether it accepts mail, and whether it can be written to at all. For the creation walkthrough and per-account settings, see Adding & Configuring Accounts.

IMAPCopy Anchor Link

The default. Bichon connects to a remote IMAP server, downloads mail into the archive, and keeps it in step with UID/UIDVALIDITY tracking. Archiving scope — a date cutoff, folder include/exclude rules, or an explicit folder list — is configured per account, along with optional proxy routing. Content-level filtering (senders, subjects, size, spam headers) is a separate per-account rule set — see Archive Filtering. See Quick Start for setup.

An IMAP account archives from a server; it is not a delivery destination. Mail cannot be imported into one, because an import would race the live sync pipeline.

NoSyncCopy Anchor Link

A local account that stores its own mail and never contacts a remote server. It is the target for every ingestion path that is not a live sync:

• Imports — EML, MBOX, PST, via CLI or WebUI. Only NoSync accounts can be import targets.
• SMTP delivery — the embedded SMTP receiver accepts mail only for NoSync accounts. Anything else is rejected at RCPT TO.
• Journal archives — a NoSync account created by SMTP journaling, marked with a journal role so it cannot be deleted by accident. Journaling itself is Pro / Enterprise only.

A NoSync account is a normal writable archive: you can search it, tag it, export from it and delete from it exactly like an IMAP account.

ViewCopy Anchor Link

A read-only, filter-scoped view over one or more other accounts. A view stores nothing. It has no mailboxes, no blobs, no index documents of its own — searching it searches its sources, with the view's filters applied.

Views exist to solve a specific problem: giving someone access to the mail that concerns them without giving them the whole account. A support team can be handed a view of the support mailbox filtered to their own address; an auditor can be given a view of several accounts filtered to one counterparty. The grant is expressed as an account they can search, and it is enforced below the API — not by hiding a UI.

Sources and filtersCopy Anchor Link

A view is a list of sources, each pairing a source account with its own filter:

Within one field the addresses are OR-ed; the two fields are AND-ed. An address must be a bare mailbox (user@example.com) — display-name forms and comma-separated lists are rejected. Matching is exact and case-insensitive.

Filters are deliberately address-only. Date ranges, folders, keywords and tags are not part of a view — narrowing those is the viewer's job, using search on top of the view's scope. A view can only ever narrow what the source already contains.

An empty filter means "the whole source account, read-only": that is a straightforward delegation, and it behaves differently from a filtered source in one important way (see below).

Views cannot chain. A source must not itself be a view, so there is no way to build a scope that is ambiguous or circular.

What a view can and cannot doCopy Anchor Link

Reading works through a view exactly as it does through an account: search, the message list, message detail, attachment preview and download, and the raw-content endpoints all honour the view's scope. Two boundaries are worth knowing:

• The thread view is not available through a view. Threads are reconstructed per source account, so a viewer without direct access to that account is told to use search instead.
• Raw EML download bypasses the view. It is gated on a direct permission on the source account, not on the view grant.

Aggregate features fail closed on filtered sources. Attachment search, the dashboard, analytics, bulk export and contact suggestions cannot evaluate an address filter, so they consider only unfiltered sources — a view with a filter contributes nothing to them, rather than leaking everything the filter was meant to exclude. Where that leaves a caller with nothing, the request is refused with an explanation rather than silently returning a partial answer.

Writing is not available at all. Deleting, tagging or repairing a message through a view is refused (or, for a target with no documents, is a no-op), and restoring messages to a server requires an IMAP account. The cleanest way to read the rule: a view grants reading, and nothing else.

Deleting a source accountCopy Anchor Link

An account that a view reads from cannot be deleted until it is removed from those views — Bichon names the views in the error rather than letting a grant silently point at nothing.

EditionsCopy Anchor Link

Views are a Pro/Enterprise feature; in the Community edition the account dialog is not offered. The check is made at three points, so a lapsed license degrades safely: creating a view, editing a view, and reading through a view are each gated. When a license lapses, views stop authorizing immediately — they do not linger as an open door.

Note that views count toward the account limit of your license, like every other account.

Creating a viewCopy Anchor Link

Create one from the accounts page (the button appears only on Pro). Choose the source accounts and, per source, the participant and recipient addresses that define the scope. Creating or editing a view requires the account:manage permission on every source account — a view cannot be used to widen your own access.

Granting someone else the view is a separate step: assign them data:read on the view account itself, exactly as you would for any other account. They will see the view as an account in their list; the messages it returns carry the source account's id, since that is where the mail actually lives.

Combining accounts (merging)Copy Anchor Link

Bichon has no merge operation. An account's type is fixed when it is created, and there is no endpoint or UI action that moves mail from one account into another. In particular, historical mail cannot be imported into an IMAP account and then kept up to date by the live sync — imports and SMTP delivery are restricted to NoSync accounts precisely so they never race a sync pipeline (see IMAP).

The common case — one mailbox whose history lives in a Takeout/MBOX/PST export and whose future mail arrives through IMAP — is therefore two accounts: a NoSync account holding the imported history, and an IMAP account syncing live mail.

To read and search both as one mailbox, create a View (Pro/Enterprise) with both accounts as sources and no filters. That is the supported way to present several accounts as a single searchable scope. Three consequences follow from how views work:

• The view is read-only. It grants reading and nothing else; it does not turn the two accounts into one writable account.
• Duplicates are not collapsed across accounts. If the import and the live account overlap in time, those messages appear once per source account, because index-level deduplication is scoped per (account, mailbox) — see Content Deduplication. Results also carry the source account's id, so the two copies remain distinguishable.
• Threads are not available through a view. Use search instead.

If you need a single writable account rather than a read-only view, all of the mail must exist on the source IMAP server so that one IMAP account can sync it; Bichon cannot fold an imported archive into an IMAP account.