Co jsme našli, co jsme opravili a co žádné nastavení neodstraní.What we found, what we fixed, and what no configuration removes.

Version audited: 0.4.0 (2026-09-05). Fixes shipped as 0.4.1 and 0.4.2 (2026-09-06). Published at https://mailmcp.ai/audit.

Sections 13 to 18 are addenda written for releases 0.8.0 (Outlook and Microsoft 365 over Microsoft Graph), 0.10.0 (triage and bulk clean-up), 0.11.0 (follow-ups, snooze, templates, confirmed sends and unsubscribe), 0.12.0 (the clickable inbox), 0.13.0 (protection levels) and 0.9.1 (usage statistics and MCP request counting; never released on its own, shipped with 0.13.0). They were not part of the reviews described in section 1; they document the new components to the same standard so the tables in sections 3 and 9 stay true.

1. What this is, and what it is not

This is an internal, AI-assisted audit commissioned by the author of mailmcp. Sixteen independent review agents (Claude Fable 5.1 for cryptography, OAuth, the mail layer and the threat model; Claude Opus 5 and Claude Sonnet 5 for the remaining areas) each examined one part of the system read-only, with file and line evidence, and several of them reproduced their findings by executing the real code against a local mail server. A second, independent review by a different model family (OpenAI Codex with GPT-6 Astra) followed the same brief on the code after the first round of fixes; its findings, and what they changed, are in section 12.

It is not a third-party penetration test and nobody outside the project signed it. It is published so that you can read what was found, what was fixed, what was deliberately left as is, and what no configuration can remove. Every High finding from both reviews was fixed before publication (releases 0.4.1 and 0.4.2, all with regression tests); the Medium findings were fixed or are listed as accepted trade-offs with the reason. Fixes are claimed against commits in the repository, and section 12 records one case where the second reviewer caught a fix that had been described but not actually shipped.

2. The system in one page

mailmcp connects an AI assistant (ChatGPT, Claude, Cursor, VS Code, Gemini CLI) to your mailboxes over IMAP and SMTP through the Model Context Protocol. Since 0.8.0 Outlook.com and Microsoft 365 mailboxes take a second path instead: a Microsoft sign-in and Microsoft Graph over HTTPS, with no password anywhere (section 13). There are three ways to run it.

• Shared server (mailmcp.ai or any server run by someone else). The server holds one master key. You create a token in your browser: the browser encrypts your mailbox settings with a random key K (AES-256-GCM), the server seals K under its master key and hands it back, and the token is mmt1.<sealed K>.<encrypted settings>. Whoever holds only the token cannot decrypt it. Whoever holds only the master key has no data. The server combines the two while it serves your request, decrypts your settings in memory, opens IMAP/SMTP to your provider, and keeps nothing on disk. Decrypted settings stay in memory for at most 15 minutes after your last request.
• Your own deployment (Vercel one-click, Docker, a VPS). The same code, your own master key. Your organization is the operator.
• Local (Claude Desktop extension, Claude Code). No server, no OAuth, no links; settings live on your machine.

Everything else derives from the master key: OAuth codes and tokens, dynamically registered client ids, one-hour attachment download links, one-hour upload links. The server is stateless: no database, no session store, no revocation list. Capabilities (read, draft, send, modify, trash, and since 0.11 unsubscribe and host-only sending) are stored inside the encrypted settings per mailbox and enforced on every call; tools that no mailbox permits are not offered to the assistant at all. Sending is off by default and, when on, limited to an allowlist of addresses or domains.

3. Who sees what

Parties and the three ways of running mailmcp. A = shared server run by the vendor, B = your own deployment, C = local.

What is where:

4. Findings

Sixteen reviews produced 6 High, about 30 Medium and about 40 Low or informational findings, with overlaps; the second-model review added 5 High and 15 Medium, again with overlaps. All High and most Medium findings were fixed in 0.4.1 and 0.4.2 before this document was published. The remaining Medium findings are accepted trade-offs and are listed with the reason.

4.1 Fixed in 0.4.1 and 0.4.2

4.2 Accepted trade-offs (not changed, with the reason)

4.3 Open recommendations (roadmap)

• Per-response CSP nonces instead of script-src 'unsafe-inline' (defence in depth; no injection point was found).
• Publish SHA-256 sums with every release; sign them.
• A bounded refresh-token chain age; an optional deny list for access tokens on long-running Node deployments.
• Move CI into .github/workflows (blocked by a token scope) and run pnpm audit there; one transitive build-time dependency (tmp, via the extension packer) has two advisories that never reach the runtime bundle.
• An explicit Vercel function duration and a streaming /files response.
• Tests for a mailbox with read off and send on, for the rate limiter end to end, and for cache eviction.
• A privacy notice and imprint on the vendor's site.

5. Properties verified as true

Each of these was checked in the code and, where marked, executed.

• Mailbox passwords are encrypted in the browser with AES-256-GCM before anything leaves it; the server receives only the 32-byte key at token creation, never the settings. (executed)
• A token alone does not yield passwords: unsealing needs the token and the edit password, which no assistant ever sees; the edit password is hashed with PBKDF2-SHA256 at 600 000 iterations in the browser and the server refuses fewer than 100 000. (executed)
• The server has no database and writes no user data to disk; configuration comes from environment variables or a startup file; OAuth artefacts are self-contained encrypted tokens. Nothing in the logs contains tokens, passwords or message text.
• Every key derived from the master key has its own purpose (seal, code, access, refresh, file, sign); ciphertexts cannot be replayed across layers; IVs are random per encryption; there is no padding oracle. (executed)
• PKCE S256 is mandatory; authorization codes live 3 minutes and are bound to client, redirect URI, PKCE challenge, host and user token; redirect URIs match exactly; error responses never redirect; the login form has a SameSite=Strict CSRF cookie compared in constant time. (executed)
• Client metadata documents are fetched with SSRF hardening: HTTPS only, port 443, no IP literals, private and loopback ranges refused on every DNS answer, the connection pinned to the vetted address, no redirects, 64 KB cap. (executed)
• Recipient strings that could expand into several SMTP recipients are refused; the SMTP envelope is built only from validated bare addresses; an empty allowlist refuses to send; domain rules do not match look-alike domains. (executed)
• Certificate validation is never disabled; every provider preset uses TLS or STARTTLS; IMAP commands cannot be injected through folder names, search strings or part ids.
• Permanent deletion of mail is not implemented: trash moves to the Trash folder, moves to Junk/Spam need the delete capability, and moves to Outlook's Recoverable Items (which Outlook purges) are refused. mailmcp removes only messages it wrote itself (staged uploads and superseded signatures, identified by their marker header) and a draft it has just sent, and only with UID EXPUNGE of exactly those messages, after the server accepted the \Deleted flag; a server without UIDPLUS keeps them (tombstoned uploads and signatures, the draft untouched). On Gmail an expunged message leaves the folder but stays in All Mail (Gmail's default expunge behaviour). A server with neither MOVE nor UIDPLUS refuses moves instead of risking other messages. (since 0.13.0; built as a 0.9 hotfix that was never released on its own)
• Runtimes are isolated per token; a token can never reach another token's mailboxes, uploads or cache entries. (executed, end to end)
• Local file attachments (Claude Desktop) are confined to policy.attachment_dirs with real-path resolution and a separator-aware prefix check. (executed)
• The licence is verified offline with Ed25519 against an embedded public key; the licence check never contacts the author; there is no telemetry beyond the daily usage-statistics ping described in section 18 (opt-out MAILMCP_NO_STATS=1, no request at all with MAILMCP_NO_UPDATE_CHECK=1).
• The prebuilt distribution and the Claude Desktop extension contain no secrets, source maps or local paths; no secret has ever been committed to the repository. (executed)
• Security headers on every response: HSTS, nosniff, X-Frame-Options DENY, CSP with frame-ancestors 'none', base-uri 'none', form-action limited to the server and the registered client, Referrer-Policy strict-origin-when-cross-origin, no-store on pages that show or take secrets. (verified live)

6. Residual risks no configuration removes

1. The AI vendor sees every tool result and keeps it under its own retention policy.
2. The operator's process holds your decrypted settings in memory while serving you and for up to 15 minutes after. "Stores nothing" is a property of this code, not a cryptographic guarantee; a modified server could store anything.
3. Stateless credentials cannot be revoked individually. Delete the app password at your provider to end access at once.
4. A token issued with broad permissions stays valid after you issue a narrower one.
5. Visible instructions inside e-mails still reach the model. Sanitization removes hidden text and prevents the framing from being forged; it cannot stop a model from complying with text it can read. The allowlist, the hourly limit and the absence of permanent deletion bound the damage.
6. Throttles and replay guards are per instance on serverless hosting.
7. One-hour links are bearer credentials that appear in hosting logs and browser history.
8. Plain-text IMAP/SMTP (tls: none) can be selected deliberately; presets never do.
9. Whatever the assistant reads can leave through the assistant itself: its reply, or any other tool the user has enabled in ChatGPT or Claude. The permissions bound what mailmcp will do after a successful injection (no sending outside the allowlist, no permanent deletion); they cannot bound what the model does with content it has already read. That is the connector's edge, not a setting: connect only mailboxes whose content the assistant may see.

7. Why your own deployment is the best option for a company

1. You own the kill switch. Every credential on the server derives from the master key. Rotating it invalidates every token, OAuth token and link at once. On the shared server that lever belongs to the vendor.
2. You remove the unverifiable honest-operator assumption. During every request the operator's process holds your users' passwords and mail in memory. Nothing in the protocol lets a user verify what code a remote operator runs. On your deployment the operator is you, under your change control.
3. The blast radius is yours alone. The vendor's project also holds the licence signing key and the tokens of everyone who tried the free server. An incident there is everyone's incident.
4. You control registration and offboarding. MAILMCP_INVITE_CODE closes token creation; your Google Workspace or Microsoft 365 admin can revoke app passwords per user, which is the real revocation path in this stateless design.
5. You choose the hosting party and region. Vercel sees the master key and plaintext requests after TLS termination. You pick the region, enable deployment protection and audit logs, or run the Docker image on your own hardware where no third party sees memory. That is what a DPO will ask for: a named processor under your DPA.
6. No dependency on the vendor's uptime or business continuity. The licence verifies offline; the Deploy button clones the distribution into your GitHub; the running code is yours even if the vendor disappears. Tokens on a shared server die with it.
7. You review updates. Updates reach you only when you pull a tag. The source code is not provided (EULA 1.1); the statutory rights of a lawful user under § 66 of the Czech Copyright Act stay untouched.
8. You tune the policy. Owner configuration sets token lifetimes, rate limits, attachment limits and can pin owner mailboxes.

What you give up: the Unlimited licence (€149, one-time) plus hosting (Vercel Hobby is non-commercial, so Pro or a small VPS), and someone who watches the distribution repository and redeploys; security fixes do not arrive by themselves.

When the shared server is reasonable: trying the product, and individuals whose concern is "I do not want OpenAI or Anthropic holding my Google account" and who trust a small Czech vendor about as much as their hosting. Use read and draft only, set an edit password, and prefer OAuth over pasting the token into config files.

When local is best: one person, one machine, Claude Desktop or Claude Code. No server, no operator, no links. The trade: passwords sit on the machine, and binary attachments go through the AI vendor as base64. Not available for ChatGPT or claude.ai on the web.

8. Notes for data protection officers

• Data categories touched: mailbox credentials (encrypted in the browser, decrypted in server memory per request), addresses and names of correspondents, message text, attachment names and, on request, contents, uploaded outgoing files (staged in the user's own mailbox), IP addresses (in-memory throttles and hosting logs), OAuth tokens (stateless, encrypted), licence buyer name and e-mail fingerprint.
• Roles: on the vendor's shared server the vendor is a processor and Vercel a sub-processor; on your own deployment your organization processes for itself and the author receives only the daily update check and usage-statistics ping (section 18); the AI vendor and the mail provider are separate controllers in every option.
• Sub-processors and recipients: the AI vendor (every tool result), Vercel (execution, logs, memory), the mail provider (IMAP/SMTP sign-ins from the server's egress address), Google Fonts (visitor IP on page loads), Vercel Web Analytics on the vendor's instance only (aggregate page views, cookieless), Stripe (purchases; merchant of record since 0.6.0, previously Lemon Squeezy), GitHub (downloads), Upstash (the vendor's usage-statistics counts since 0.9.1, EU region Frankfurt; section 18).
• Data subject rights: there is no account and no stored profile. Erasure is deleting the app password and discarding the token; since 0.11 mailmcp also leaves records, folders, labels and categories in the owner's own mailbox, which the owner removes as described in /docs, "Removing what mailmcp keeps in your mailbox". Content already sent to the AI vendor is governed by that vendor's terms.
• What to document: records of processing naming the AI vendor, the host and the mail provider; Article 28 agreements with Vercel and with the AI vendor (zero-retention or enterprise terms change the analysis); a DPIA, since correspondence contains third parties' data and may contain special categories; a legal basis for correspondents' data; employment-law groundwork for staff mailboxes; user instructions about prompt injection and about what the AI vendor sees.
• Statements you can rely on are in section 5; the licence text contains no data-protection terms and does not replace a processing agreement.

9. Limits and defaults

0.7.0: the free tier caps new tokens at 2 mailboxes (seals carry iat; older seals keep 5). The seal may carry a licence key (lic) verified per request with its expiry. Nothing new is stored.

0.9.0 (mailmcp.ai subscription; like section 13, this paragraph was written after the reviews in section 1 and was not part of them): subscription keys (tier hosted: the Stripe subscription id, the seat number and an expiry of the paid period's end plus 30 days, no personal data) are sealed in the token and verified offline whenever the server builds a runtime for the token (its first request on an instance, and again after an idle runtime was dropped). Only a server started with MAILMCP_HOSTED=1 honours them, and distribution builds never do (the switch is compiled out); a subscription key never licenses a server of its own. Keys are issued only for invoice periods Stripe reports as paid; /claim?session_id= shows the keys of the first period only, later keys arrive by e-mail, and the e-mail re-send is throttled per IP address and per purchase address. /api/unseal now also returns the sealed key to whoever holds the token and its edit password; /api/relicense replaces the key with the token alone and gains no mail access: it answers with the new token only, never with the mailbox settings, so it gives nothing the token did not already give. Free-tier tokens are held to 10 sends per hour per mailbox by the server, whatever their configuration says, and subscription tokens to 50, shared by all tokens made with the same seat's key. Revocation works through the MAILMCP_REVOKED denylist (whole subscriptions or single seats), which takes effect on redeploy (instances of the previous deployment, and the runtimes they cached, keep the old licence until they end); this closes finding 7 of the 2026-09-23 security review for the subscription (a refunded or disputed subscription stops working), while a refunded one-time Personal or Unlimited key still works offline and can still be claimed, so for those the finding stays open. Finding 5 of that review (the send-limiter map was cleared at 5 000 entries, resetting every quota) is fixed: the oldest entry is evicted instead. Nothing new is stored.

10. What the test suite proves

88 automated tests: unit tests without network for cryptography, sanitization, policies, licensing, the purchase flow (Lemon Squeezy at the time of the audit, Stripe since 0.6.0) and the full OAuth flow; end-to-end tests against a real IMAP/SMTP server (GreenMail in Docker) for stdio and HTTP transports, shared multi-user mode, attachments in and out, uploads, forwarding, drafts and the ChatGPT connector contract. They prove the request-shaped attacks are handled: recipient smuggling, CSRF, PKCE and replay, SSRF against metadata and loopback addresses, tenant isolation, licence caps enforced server-side against client-built tokens, hidden-text stripping, delimiter forging through file names, path traversal for local attachments, tampered links. They do not prove behaviour under sustained load or across several serverless instances.

11. How the pages were corrected

The reviews compared every claim on the public pages with the code. Accurate: encryption in the browser, no database, offline licence verification, allowlist-only sending, no permanent deletion, one payment, 60-day refund (14 days since 0.6.1), tier limits. Corrected: the memory window (15 minutes, not "during the request"), what the operator can see, which attachments enter the chat, what hidden-text stripping guarantees, and the nature of this audit. Claims about the official Gmail and Outlook connectors of ChatGPT and Claude describe those vendors' documentation as of September 2026 and cannot be verified from this code.

12. Independent second-model review

OpenAI Codex (GPT-6 Astra, high reasoning, read-only sandbox) received the same brief and worked from the repository after the first round of fixes. Its report ran to 26 findings. It confirmed the cryptographic construction, the OAuth protections, the recipient and envelope handling and the Bcc stripping, and it found no cross-tenant access path. Its top ten, and what happened to each:

Also fixed from its list: the source Docker build broken by the audit page, webhook events marked as handled before success, release assets overwritten under an existing tag, the local-file check-then-open race, the missing forward tool for draft-only configurations, invalid HTML entities throwing, and quadratic work on deeply nested HTML. Left as documented trade-offs: per-instance code replay guards, concurrent send_draft duplicates, generating a configuration on a third party's setup page.

Its independent opinion on deployment matched section 7: a company should run its own deployment, provided it maintains it, with restricted egress, conservative capabilities and narrowly scoped mailbox credentials, and it should not treat the split-key design as a substitute for those controls. The sentence "I would not rely on the present split-key marketing or published fixed claims as substitutes for those controls" is quoted here on purpose: the pages were reworded, and this document states fixes against released versions with tests.

Lesson recorded for the project: every fix in this report is tied to a test that reproduces the original problem, and a release is not called fixed until that test passes in the shipped version.

13. Addendum: Microsoft Graph and the sign-in relay (0.8.0)

Written for release 0.8.0, after the reviews in section 1. Outlook.com and Microsoft 365 mailboxes do not use IMAP or SMTP: Microsoft rejects passwords on most accounts. Instead the user signs in at Microsoft and mailmcp holds a refresh token.

Components. src/mail/msauth.ts (device-code and token-endpoint calls, MsTokenSource with an in-memory rotation cache and error mapping), src/mail/graph.ts (GraphAccount, the second implementation of the Mailbox interface, talking to graph.microsoft.com/v1.0), the routes /api/ms/config, /api/ms/start, /api/ms/callback, /api/ms/device and /api/ms/poll next to /api/seal, the sign-in UI in the setup page, and src/mail/ms-reseal.ts (the rolling re-seal on our own OAuth refresh).

What is stored: nothing. As everywhere else in this codebase there is no database and no disk write. The Microsoft refresh token is encrypted in the browser into the user token exactly like a mailbox password; rotated refresh tokens and access tokens exist only in the process that obtained them. At sign-in the server relays the refresh token once from Microsoft to the browser (a same-origin postMessage from the popup callback page, or the answer to a poll) and keeps no copy.

Lifetimes.

Hardening. The Graph and login hosts are fixed constants, never derived from user input, so an oauth2 mailbox names no host an attacker could choose. Every path segment is encodeURIComponent-ed and every query string is built with URLSearchParams. All three POST routes require content-type: application/json, so a cross-origin form cannot drive them. /api/ms/device is counted in the sign-in throttle (5 per address and 60 overall per 15 minutes) only once the invite gate has passed; /api/ms/start, which asks Microsoft nothing, is limited to 10 per address with no overall cap (since 0.8.1), so a wrong invite code costs the caller's own address one of ten attempts and never the shared budget; /api/ms/poll has a budget of its own (250 per address per 15 minutes, against the roughly 180 polls a real sign-in makes), because the poll counter and the poll spacing live inside the reference and an in-memory replay guard is empty after a cold start; /api/ms/callback is counted at 20 per address, with no overall cap since 0.8.1. As in the rest of the design these counters are per process, so on serverless hosting the real budget is multiplied by the number of live instances. Permanent deletion stays impossible: the only DELETE /me/messages/{id} calls target the uploads folder for uploads and the signature folder for the signature prune, each only for messages carrying the matching X-Mailmcp-Upload or X-Mailmcp-Signature marker header, the same rule the IMAP path uses. Bodies from Graph pass through the same sanitizer and the same untrusted wrapper.

Accepted risks.

14. Addendum: triage and bulk clean-up (0.10.0)

Written for release 0.10.0, after the reviews in section 1 and not part of them. The release was built and reviewed block by block by AI agents (Claude) against a written plan, with every fix tied to a test; that is the same kind of internal, AI-assisted review as the rest of this document, not a third-party audit.

New tools. triage, awaiting_replies and digest read message headers only (List-Id, List-Post, List-Unsubscribe, Precedence, Auto-Submitted, X-Autoreply, iCalendar parts, Outlook Focused/Other and the last-verb property), never bodies, and never set \Seen (IMAP BODY.PEEK[HEADER.FIELDS …]). The classification reasons are a fixed vocabulary, so no text a sender wrote reaches the model through them; subjects and senders pass through the same header sanitizer as everywhere else. bulk_preview and bulk_apply archive, mark read, label, move or trash many messages at once.

State: still none. 0.10 writes nothing to disk, to a database or to the mailbox. A bulk confirmation and a digest cursor are sealed refs (compact JWE, dir + A256GCM) that travel with the assistant's call: purpose-specific keys derived from the master key (oauth-confirm, oauth-cursor, distinct from the OAuth and file keys), the purpose also as the JWT subject, the principal in its own claim (derived from the token's sealed blob key, so it survives Microsoft re-seals and relicensing, and owner for owner mode and Claude Desktop), and the account. A confirmation never opens as a cursor, a ref sealed for one token never opens for another, and without MAILMCP_KEY the keys are random per process (refs then work only on that process; stdio logs this once).

Approval mode A only. A confirmation binds the operation: the ref carries the account, the action, the label, the destination, the absolute criteria (relative dates are resolved once, at the preview), the tier, and the exact members. bulk_apply also takes the action, the account and the count as plain arguments that must equal the sealed values, so the client's approval dialog shows what is being approved instead of an opaque string; the ref stays the authority. It expires after 10 minutes. It does not prove that a person saw the preview: a model, or a scheduled run, can preview and apply at once. The instructions, the prompts, /llms.txt and /docs tell the assistant to show the preview and ask, and tell the owner to "always allow" bulk_preview (read-only) but never bulk_apply, and to keep bulk_apply out of scheduled tasks. The server cannot tell a scheduled call from an interactive one.

Exact identity. On IMAP the confirmation seals the folder's UIDVALIDITY and the uid set itself (packed; 500 scattered uids fit a 4,000-character ref). On Outlook, immutable ids are too long to seal, so the confirmation carries the query that found the members, the preview instant and 32-bit SHA-256 prefixes of the member ids; bulk_apply re-runs the query bounded by receivedDateTime ≤ preview instant and keeps the candidates whose hash was sealed. The query is narrowed to the time span of the members actually sealed (after the plan cap and after shortening; it ends with the newest member's whole second, because Exchange reports receivedDateTime in whole seconds but filters on the stored milliseconds), and an exact sender is part of Graph's filter. If more candidates match than were sealed, or one sealed hash is matched by two candidates, the whole batch is refused; fewer is fine (the missing ones are reported as gone). One case cannot be detected: a member that left the folder after the preview while a message outside the preview, inside the same span and matching the same criteria, has the same 32-bit hash prefix. That message would be acted on in its place. The odds are about one in 4.3 billion per departed member and candidate in the span (for explicit ids, every message of the folder in that span is a candidate); the action stays recoverable (nothing is deleted), and the message must still pass the per-member checks below. A batch whose confirmation would not fit is shortened at preview time and says so. Apply revalidates every member before touching it: still in the source (IMAP: UIDVALIDITY and the uid; Outlook: the parent folder id), not flagged now when flagged mail was excluded, not read now when only unread mail was selected, not already done. Members are only ever dropped. A message delivered or unflagged after the preview is never touched.

Replay. A used confirmation is refused by the same instance (an in-memory set, like OAuth codes; the text names the batch). It counts as used only once every check has passed, and a refusal before anything changed (a rebuilt folder, a plan change, a transient error) leaves it valid. Another serverless instance does not know it was used, and a replay there is harmless: every member has already left the source (gone) or is already in the target state (already done), and nothing outside the sealed set can be touched. Cross-instance single use needs state and is left to a later release.

Safe mutations. Every IMAP move, including the bulk ones, goes through src/mail/imap-safe.ts (UID MOVE, or UID COPY + verified copy + \Deleted + UID EXPUNGE of exactly those uids); a lint test fails the build if messageMove, messageCopy, messageDelete, exec, a \Deleted store or CLOSE appear anywhere else. A server with neither MOVE nor UIDPLUS refuses archive, move and trash before anything changes; mark read and labels still work. On Outlook every member is one request through the per-mailbox semaphore (three in flight), never $batch; category changes read the @odata.etag and PATCH with If-Match, rereading on 412. Nothing is permanently deleted: trash is a move to Trash (Gmail and Outlook empty it after about 30 days; the preview says so), moves and labels to Junk/Spam need delete (a Gmail label is compared with the account's own Trash and Spam folders from LIST, so [Google Mail]/… and localized names count too), Recoverable Items is refused. On Gmail a bulk move out of All Mail is refused, because Gmail may delete a message that loses its last label there, depending on the account's IMAP expunge setting.

Reserved names. mailmcp-uploads, mailmcp-state, mailmcp-templates, mailmcp-snoozed and mailmcp-live-test (the last path segment, either delimiter, any case) are refused as move destinations and as sources of any change, and mailmcp/… or those names are refused as labels or categories. On Outlook a reserved folder is recognised by name, by id and by the message's parent folder; a reserved folder below a parent is recognised by id only once a folder listing has named it.

Deadlines. Each new tool call runs under one budget from request receipt (50 s over HTTP, under Vercel's 60 s limit; 120 s on stdio). Queue wait, connect and every IMAP command and Graph request share it; an IMAP command still running at expiry is stopped by closing the connection. Reads keep 5 s to answer and report partial coverage; bulk_apply starts a chunk (250 IMAP uids or 25 Outlook messages) only while 12 s remain, and a chunk still in flight at expiry is reported as unknown_outcome ("The mail server did not confirm the last step. Nothing was deleted. Run bulk_preview with the same criteria"), never retried silently. With account: "all", four mailboxes run in parallel, each with its own share of the time; one that times out reports its error and the others answer. Header bytes per call are capped at 4 MB.

Limits. triage: newest 60 per mailbox (at most 200), since at most 30 days back; 50 items listed per bucket, 15 for newsletter, lists and automated (counts cover all). awaiting_replies: Sent 500, inbound 2,000 per IMAP folder or 4,000 Outlook rows; Outlook headers are read for at most 25 candidate replies per call. digest: 500 headers per mailbox per call, cursor valid 30 days, at most 4,096 characters. Bulk: 50 per call on Free, 500 paid, at most 100 explicit uids, 1,000 candidates examined per scan window (continued with scan_from), confirmation valid 10 minutes.

Known limitations.

15. Addendum: follow-ups, snooze, templates, confirmed sends and unsubscribe (0.11.0)

Written for release 0.11.0, after the reviews in section 1 and not part of them. Like 0.10, the release was built and reviewed block by block by AI agents (Claude) against a written plan, with every fix tied to a test; an internal, AI-assisted review, not a third-party audit.

State in the mailbox, never on the server. 0.11 is the first release that keeps state, and all of it is in the owner's own mailbox: follow-up, snooze, bulk-journal, send-claim and draft-provenance records in mailmcp-state, snoozed mail in mailmcp-snoozed, templates in mailmcp-templates. A record is one message whose body is JSON and whose X-Mailmcp-Mac header is an HMAC-SHA256 over the kind, the key, the Message-ID, the mailbox address, created and the exact decoded body. Records are authority only when they verify; an unverified record is listed as such and is never cleared, woken, superseded or deleted unattended.

The state key. policy.state_secret in the configuration, or, when absent, stateSecretOf(configKey) = HKDF-SHA256(configKey, salt "mailmcp-state", info "state-secret"), where the configuration key is the one that decrypts the configuration (the token's sealed blob key; MAILMCP_KEY in owner mode and Claude Desktop). The per-mailbox HMAC key is HKDF-SHA256(secret, salt "mailmcp-state", info "v2\0" + lower-cased address); the account id is not an input, so renaming an account keeps its records and changing its address orphans them (the owner's way back is wake_snoozed orphans=true and discard_unverified=true, which move to INBOX and to Trash, never expunge). The setup page writes state_secret into every new configuration and keeps it on Edit. Without any key (a plaintext developer configuration) bulk clean-up runs as in 0.10 without a journal and says so; setting follow-ups or snoozes, saving templates, provenance and mode B refuse or skip; clearing, waking and listing still run.

Recognition by location. A message is treated as a record only where it sits: an IMAP path of a record folder, a Gmail X-GM-LABELS entry of a record label, a Graph parentFolderId of a record folder; in Trash only when it also carries the record header and a @mailmcp.invalid Message-ID (tombstones). A message delivered to INBOX with a forged X-Mailmcp-State header stays visible in every read tool, and a record can never hide ordinary mail. Records in the record folders are refused by every generic read tool. The Date header is used only as a coarse index for the due query: a client that rewrites it can hide a record from that query, never make one verify. mailmcp removes only its own verified records: on Gmail by moving them to Trash (tombstones), elsewhere by their exact identity (on IMAP through the safe-mutation path). A tombstoned record restored from Trash or Outlook's Recoverable Items verifies again; restoring it needs access to the mailbox, which already allows everything the record could do.

Record-first follow-ups and snooze. Setting writes an intent record (with the prior flag state), then sets the markers and reads them back (a server may answer OK to a STORE and keep nothing), then writes a completion record with the markers actually present, then tombstones older records of the same key in the total order (created, Message-ID). Clearing trusts markers only from a completion and restores the prior flag only if it is still ours; a flag the owner changed afterwards is left alone. Snooze writes its intent before the move and its completion after; a wake finds the message by its identities (Message-ID, X-GM-MSGID, Graph id, UIDVALIDITY + uid), and two concurrent wakes move it once. Snooze moves one message, never its conversation. On Outlook the record keeps the exact due time and clearing compares against Outlook's read-back of the flag; spike S3 found the due time accepted and read back exactly, and what Outlook's clients show for it is checked in E5.

Bulk journal and undo. bulk_apply writes an intent (the exact members resolved at apply) before the first change and a completion after; an interrupted batch is reconciled from the mailbox on the next call or by bulk_preview batch= (read-only: status never writes). Undo (paid, 7 days) acts only on members found by exact identity: the uid within the recorded UIDVALIDITY, the Graph id or the Gmail X-GM-MSGID. A member found only by Message-ID could be the owner's own copy and is left alone and reported. A member the owner changed after the batch is left alone. A flag action (mark read, label, Gmail archive) whose completion had to be reconciled after an interruption is never reversed: mailmcp cannot tell its own change from one the owner made after the crash. If two runs of one batch both proceeded (a completion not yet visible in a lagging Outlook listing), status and undo merge their outcomes per member, so an all-skipped duplicate never hides the run that did the work. On Outlook the journal records a mark-read member as unread without a request (the preview selected unread mail only) and leaves a label's prior state unknown.

Send fingerprints. Draft tools return a fingerprint of the stored draft (IMAP: the appended bytes; Graph: one read of $value after creation), computed over the parsed message: bare lower-cased addresses including Bcc, the decoded subject, SHA-256 of the transfer-decoded text and HTML parts and of every attachment, and the source (reply, forward). send_draft with expect_fingerprint re-reads and refuses a draft that changed ("The draft changed since it was shown; nothing was sent."). On Graph, /send does not honour If-Match (spike S5), so the re-read is the guard; the window between that read and the send remains. Fingerprints are computed per request and never stored. Every send path strips X-Mailmcp-* headers before the wire: mailmcp adds no header to mail it sends, and draft provenance is a record, not a header.

Mode B: host-mediated confirmation (MRTR). On a modern-era request from a client that declares form elicitation and is listed as clientName@protocolVersion (the list ships empty; MAILMCP_ELICITATION_HOSTS can only add entries), a send, a confirmed bulk apply, an undo or an unsubscribe first returns input_required with a server-built dialog and a sealed requestState (purpose key oauth-mrtr, the tool, a hash of the canonical arguments, the fingerprint, the principal, the account, 10 minutes). The SDK's requestState.verify hook checks integrity only (a tampered state is a -32602 protocol error); expiry, arguments, principal and fingerprint are checked by the tool and answered in words. legacyShim: false was chosen deliberately: a legacy-era client never receives input_required (the SDK answers -32603), which matters only on stdio, where the era comes from the envelope. The dialog lists totals and every address (IDN domains in punycode, the subject quoted and labelled as coming from the draft, bidi controls removed); if the full text does not fit 300 characters no dialog is offered and a draft is saved. The retry must reproduce the same message fingerprint and the same dialog text (its hash is sealed too), so a Bcc added after the dialog is refused even where Exchange's stored MIME would not show it, and send_draft sends only against the fingerprint the owner confirmed; a message without a fingerprint gets no dialog. Single use across instances is a send-claim record keyed by the confirmation's jti: written, re-read, and only the earliest claim proceeds, and a tie in the server's order (Graph orders by creation time in whole seconds) makes both refuse, so a confirmation sends at most once or not at all. On Outlook send_draft claims first on the draft itself: a PATCH of a mailmcp property with If-Match on the etag seen at the dialog, writing a value unique to that attempt (Exchange accepts a stale etag when a PATCH writes the value already stored, seen live) and reading it back, so a second instance gets a 412, or finds another value, and sends nothing. Sends without a stored draft (send_message, reply_send, forward_message) keep the record claim and read it again after 1.5 s on Outlook; Graph's listing lag has no bound, so a small window remains there, bounded in practice by the in-process replay guard; a replay on any instance answers "This confirmation was already used; nothing was sent again." Mode B never widens policy: every check the tool makes without it runs first. clientInfo.name is self-reported, so the host list protects against a misbehaving model inside an honest host, not against a client that holds the token and lies.

Host-only sending. A mailbox set to send only after the dialog is stored as send: false plus send_host_only: true, so 0.10 and older copies refuse to send from it instead of sending without the dialog. On clients without mode B its sends become drafts and send_draft leaves the draft. It requires the draft capability.

Unsubscribe trust boundary. mailmcp relies only on an authentication verdict it can attribute to the owner's own provider:

The one-click POST is sent only when every condition holds on a fresh read of the complete header block (at most 64 KB; a longer one is manual): the trusted header is the topmost one; it has exactly one dkim=pass identifying exactly one signature (header.b as a prefix of at least 8 characters, else header.d + header.s); that signature's h= covers List-Unsubscribe and List-Unsubscribe-Post; each header occurs once; List-Unsubscribe-Post is List-Unsubscribe=One-Click with exactly one HTTPS URI of at most 2,048 characters, without userinfo, fragment, IP literal or a port other than 443; the URI's host is the signer's d= or below it, and d= is not a bare public suffix (a valid signature from attacker.example cannot unsubscribe the owner at victim.example); the message is not in Drafts, Sent or a mailmcp folder (APPENDed mail carries no provider verdict); and the mailbox has the unsubscribe capability, which is off by default. The dry run shows only the host and names the verified signer as the sender. Execute re-evaluates everything and requires the URL, the signature, the Message-ID and the UIDVALIDITY to equal the sealed values. The POST goes to an address vetted and pinned like the CIMD fetch, carries only List-Unsubscribe=One-Click as multipart/form-data, no cookies, follows no redirect (a 3xx is not a confirmation), and runs under one 5-second deadline over DNS, connect, TLS, request and response, reading at most 8 KB; 20 per hour per mailbox. This trusts the provider's verification; mailmcp does not verify DKIM itself.

Recovery mode. An expired mailmcp.ai subscription token with more mailboxes than the Free cap signs in and runs only the recovery set on all its mailboxes (listing accounts, follow-ups and templates, clearing follow-ups, cancelling and waking snoozes, deleting templates, batch status); every other tool answers with the renewal steps. The set is a table checked at registration, so a new tool is refused in recovery mode unless listed.

Known limitations.

16. Addendum: the clickable inbox (MCP Apps, 0.12.0)

Written for release 0.12.0, after the reviews in section 1 and not part of them. Like 0.10 and 0.11, the release was built and reviewed block by block by AI agents (Claude, with a separate security reviewer on the server side and on the widget) against a written plan, with every fix tied to a test; an internal, AI-assisted review, not a third-party audit.

The resource. One MCP Apps page, ui://mailmcp/app.html with MIME type text/html;profile=mcp-app, is registered on every transport (HTTP, stdio, the MCPB, recovery mode included) unless the configuration turns the panels off (0.13.0). It is a generated, committed string (src/http/app-bundle.ts, built deterministically by scripts/build-app.mjs), never served by an HTTP route, so dist copies, Docker and the MCPB serve the same bytes. Its _meta.ui declares empty CSP lists (connectDomains: [], resourceDomains: []) and no permissions; the listing and the content item carry the same metadata. Nine tools point at it with _meta.ui.resourceUri: triage, digest, search_messages, get_thread, create_draft, reply_draft, bulk_preview, bulk_apply, unsubscribe. No tool is app-only and no tool was added: the model sees 33 tools, as in 0.11. Since 0.13.0 five tools point at it (triage, digest, create_draft, reply_draft, bulk_preview); the other four answer as in 0.11, and a configuration with policy.ui: "off" registers neither the page nor any _meta.ui.

The meta CSP. The page's first <head> element is its own Content-Security-Policy: default-src 'none'; script-src 'sha256-…'; style-src 'sha256-…'; img-src data:; font-src data:; connect-src 'none'; frame-src 'none'; worker-src 'none'; manifest-src 'none'; form-action 'none'; base-uri 'none', with the hashes of the one inline script and the one inline style. It is defence in depth under the host's own sandbox and CSP. zod is switched to jitless before anything else loads, so no eval is needed. A test asserts the tag is first, the hashes match and no unsafe- source appears. The browser suite counts every request the frame attempts, including ones the CSP blocks, and requires zero.

No Claude domain; the OpenAI origin only when trustworthy. _meta.ui.domain is never set: Claude derives the sandbox domain from the exact URL the user entered and refuses to render on a mismatch, and the page makes no network calls that would need a stable origin. For ChatGPT, _meta['openai/widgetDomain'] carries the server's own origin only when it is https:, not loopback or private, and comes from MAILMCP_PUBLIC_URL, Vercel or a trusted proxy (MAILMCP_TRUST_PROXY=1); otherwise it is omitted, so a self-hosted server behind an untrusted proxy never advertises an internal address. stdio never sets it. A wrong value can only affect ChatGPT's rendering, never a text result.

Allowed links. The page opens exactly one kind of link, through one function (safeOpen, the only caller of the host's openLink): an attachment download link taken from a get_attachment result, https: (or http: on loopback), with the path /files?r=<16–9000 safe characters> and no other query (0.13: Vercel refuses paths over ~2 KB) or the older /files/<16–4096 safe characters> without a query, no userinfo or fragment, and the origin of the first such link pinned for the session. Everything else is refused and the chip says "Ask the assistant to save it". The Claude directory entry lists https://mailmcp.ai; self-hosted copies get Claude's confirmation prompt for every link.

Mail text never becomes markup or navigation. Every mail-derived string reaches the DOM as a Text node through one helper that removes control characters and the invisible and bidi set of sanitize.ts; mail-derived elements are dir="auto" and isolated, so a subject cannot reorder a neighbouring button label. Links in mail stay text and remote images are never loaded. A lint over the widget sources (with a fixture per rule) forbids innerHTML and every other markup sink, window.open, location, .href =, .src =, srcdoc, creating a, form, iframe, img, link or script elements, non-literal attribute names, on* property handlers, script-dispatched clicks, and any tool call outside the single click gateway.

Model-channel templates. The page writes into the conversation (ui/message) and the model context (ui/update-model-context) only through fixed builders that accept account ids, uids (IMAP numbers or Graph ids of [A-Za-z0-9_=+/-], at most 512 characters), plain folder names, counts and batch ids, and throw on anything else. The one free text is what the owner types into "Ask for changes" (at most 2,000 characters, the field starts empty). No subject, sender, address or mail text can reach either channel (a property test over 1,000 hostile rows). Model-context updates are best effort and never the only way the model learns of an action.

_meta versus structuredContent. Every UI result keeps its 0.11 content text and structuredContent byte for byte (snapshot test on IMAP- and Graph-shaped fakes), plus structuredContent.kind from a fixed vocabulary. Everything else the page needs (the draft card, account labels and capability flags, as_of) goes into the result's _meta['mailmcp/ui'], which hosts document as going to the widget and not the model. Because a host may forward _meta to the model after all, it follows the same rules as content: header strings through sanitizeLine, the card's text inside the untrusted-content markers (the page strips exactly those two lines), and only text mailmcp can attribute to the owner is shown as the owner's: the reply part (or a forward's comment) when the provenance split adds up. The quoted or forwarded message is named by its recorded sender, date and subject, and at most its first 600 characters travel separately, inside the same markers, shown collapsed. Without _meta the page renders what structuredContent already exposes and shows no Send.

The draft card, and refresh before arm. The card is built from the parse of the stored draft, the same parse send_draft fingerprints, so it shows every recipient including Bcc, every attachment and the sending identity. Its Send is disabled whenever the shared pre-check (src/mail/send-precheck.ts, also used by send_draft: read, send, attachments policy, size, recipients, allowlist including Bcc) refuses, when a send of the draft is recorded (already_sent: after every send a sent record keyed by the draft's Message-ID, which send_draft also refuses on, so a draft left in Drafts is never sent twice), when mailmcp's record cannot show the owner's own text or name the quoted message (unreviewable, also from the first card when the configuration has no records key), and when the draft has an HTML part mailmcp did not generate from the text itself (html_differs: the record keeps the hash of generated HTML only; any HTML the assistant supplies, or any HTML changed afterwards, disarms, because the card cannot show HTML). The first click calls get_message, which returns a fresh card for a draft in Drafts (only to clients that declare MCP Apps support, or whose request carries no capabilities, and for drafts within max_download_bytes, the whole result within 60,000 characters), and arms only if the fingerprint, account, uid, recipients and attachments are unchanged; the second click calls send_draft with that fingerprint, which the server checks again. Any other action, a new result, a theme change or Back disarms. A card replayed from an old conversation is never sent from what it showed; a send is shown as "Sent" only on send_draft's success shape, never on an input_required answer. Bulk actions follow the same pattern: the first click previews per (account, folder) group, the second applies with each group's own confirmation, a preview older than 9 minutes (confirmations live 10) is run again, and a preview that returns after the selection changed never arms. Handlers that render results call no tool (lint and a browser test).

The postMessage target. The ext-apps transport checks event.source on what it receives, but sends with the target origin "*": card payloads and tool results go to whatever origin the parent frame has. The page cannot pin the host's origin across hosts, so it relies on the host's sandbox; the payloads are the same data the host already holds from the tool result.

Hosts may skip their own per-tool prompts for widget calls. A host that asks before a model's tool call may not ask before a call from the page. Then the gates are the page's two clicks and the server's checks, which are the same as for any model call.

Mode A plus UI. A call from the page is an ordinary tools/call that the server cannot tell from a model's. Every policy runs exactly as for the model: capabilities, the allowlist including Bcc, the rate limit, the tier, the fingerprint, and host-only sending. _meta.ui.visibility is not used and is never treated as authorisation. The card is not a confirmation: the model can send the same draft within the owner's rules; only a mailbox set to send after the app's dialog (send_host_only) makes a send wait for the owner.

Third-party code in the bundle. The page bundles the App client of @modelcontextprotocol/ext-apps 2.0.3, tree-shaken against the repository's own @modelcontextprotocol/client and core 2.0.0 and zod 4.5.4, so every copy is pinned by our lockfile and covered by pnpm audit (the upstream app-with-deps build, which embeds its own copies, is not used). The page is 653,518 bytes, under a budget of 660,616 (the measured client plus 80 KB for our code) and a cap of 716,800. ext-apps and playwright-core 1.63.0 (the browser test suite) are development dependencies only; neither is a runtime dependency of the server.

Gate outcomes. schedule_send (Outlook send later) and respond_invite (invitation replies) were planned behind feasibility tests. The schedule_send test ran before 0.13.0 and failed (Microsoft 365 cannot cancel a deferred send), so the tool was dropped; Outlook send later stays a scheduled-task recipe. The respond_invite test was not run and the tool is deferred. Neither is registered, and the release notes say so. The owner tested the panels in the Claude app before release, which led to the 0.13.0 narrowing to five tools and the per-token switch; the remaining host behaviour (_meta forwarding, prompts, fonts, the CSP in each host) was not checked host by host, so the /docs host table still says "(to be verified)" and problems are expected from user reports.

In-card editing deferred. A revise_draft tool that edits the draft from the card was designed and deferred to a later release (it is not in 0.13.0). The review of its design found problems a safe edit has to solve first: header injection and encoding in a hand-written splice, recovering the quote from text-only offsets, signature images after a signature change, Exchange re-rendering stored drafts (which would refuse every edit after the first), the IMAP selection after an APPEND, a crash window between writing the new draft and retiring the old one, and concurrent edits. The card is read-only apart from Send; "Ask for changes" asks the assistant for a new draft, and the earlier draft stays in Drafts.

Related changes. create_draft and reply_draft return a uid on IMAP servers without UIDPLUS (a fresh SELECT, then the Message-ID); every draft mailmcp saves gets a provenance record; send_draft refuses an Outlook draft larger than max_download_bytes instead of reading it whole; forward_message with as_draft no longer returns the forwarded body outside the untrusted-content markers.

Known limitations.

Review before release. A release-wide /recheck by Claude agents ran on the 0.12 work (record docs/replan/audit/2026-09-30-134346-recheck-0d6700e.md): no Critical finding; the Important findings (among them hidden HTML passing the card and a double send after a replayed card) were fixed with tests before 0.13.0. No independent second-model pass of this addendum was run.

17. Addendum: protection levels (0.13.0)

Written for release 0.13.0, after the reviews in section 1 and not part of them. Like 0.10 to 0.12, the release was built and reviewed block by block by AI agents (Claude, with a separate security reviewer) against a written plan and specification, with every fix tied to a test; an internal, AI-assisted review, not a third-party audit.

Threat model. A verification email (a one-time code, a sign-in link, a password reset) is a bearer credential delivered to the inbox. An assistant connected to mailmcp holds private data, reads untrusted content and has ways out: the send tools, and the client's own web fetch and link rendering. Published attacks make an assistant read such a code and pass it on. 0.13 removes the private-data leg for that subset of mail: the mailmcp server, not the model, decides per mailbox which verification emails the assistant may see, before any tool result is built. It does not make the rest of the mailbox safe to read (section 6 still applies).

The setting. accounts[i].capabilities.protection: off, basic (codes, sign-in links, recovery), standard (plus security alerts, and redaction of codes and sign-in links in other mail), strict (plus bank and payment mail) or {level: "custom", categories}. It lives only in the sealed configuration; no tool argument, prompt, resource or _meta field can lower it or ask for hidden mail. Parsing is lenient and fails closed: an unknown level or type is read as Strict, and a configuration without the field is Off, reported as set: false by list_accounts. New mailboxes on the setup page start at Standard. Changing the level creates a new token; the old token (and OAuth grants of up to 90 days) keeps the old level, so every page, the CHANGELOG and the setup page pair the change with replacing the token in every assistant. There is no server-wide minimum level. One mailbox entered twice with different levels would let the assistant read through the lower one; the setup page warns about that, and list_accounts shows every level.

The classifier. src/mail/protect.ts and protect-rules.ts are pure functions: English and Czech rules, headers first (subject, sender, the One-Time-Code header), then the body, NFKC plus a confusable fold with an offset map, invisible characters stripped before matching. Categories are a union: a message hidden by any selected category is hidden. At most 256 KB of each text and 4 KB of a subject are analysed; text beyond that is never returned (it is cut with the usual truncation note) and paths that send bytes onward treat a truncated text as unanalysed. Length never hides a message on its own. Meeting passcodes stay visible. A body code counts only next to a verification keyword, or next to the generic word "code"/"kód" (any case) when no qualifier makes it another kind of code (booking, reservation, order, customer, access, error, voucher …); a sign-in word right before or after the keyword ("customer login code", "kód pro přihlášení", "kód pro vstup do internetového bankovnictví", "přístupový kód do aplikace") overrides the qualifier, because a code for signing in is a login code. Amounts with decimals never count. Next to a bank or payment sender the weak words never mean codes: "Potvrzení platby" is banking (Strict only), while a bank's code mail is caught by its verification phrase or the code in its subject. A message is hidden whole by its body only when it comes from a table sender, an automated or role address, or carries a precise or strong phrase in its subject; mail from a person is only redacted. These precision rules came from the release recheck, which measured booking codes, invoice amounts and colleague mail being redacted or hidden at the default level; every changed corpus pin is listed in the release report. The rules version is reported as rules in list_accounts.

The decorator. Every mailbox the runtime hands to a tool is wrapped in ProtectedMailbox (src/mail/protected-mailbox.ts), whatever its level. Its table is typed Record<keyof Mailbox, MethodPolicy>, so a new backend method does not compile until it has a policy. The kinds: pass (no foreign content, each with a written reason: folder lists, record storage, positions, markers, bulk members already selected under protection); byRef (a method naming a message reads that message's header facts first, so the body of header-hidden mail is never downloaded, and at hiding levels mutations also run the body pass); mask (the housekeeping reads used by wake and follow-ups return hidden rows with subject and sender blanked, never dropped, so moving mail back keeps working); rows (triage and digest scans drop hidden rows and count them); body (message, thread, reply context, writing samples and draft inspection: header check, body pass, redaction); keep (search and bulk resolution: the backend applies the predicate before counting, sampling or paging, and stamps the result; an unstamped result has its total discarded and is logged as protect_unstamped). Facts ride on results under a non-enumerable symbol and are answered by position.

Two kinds of hidden. Header-hidden mail is left out of listings and refused by id without its body being read. Body-hidden mail (the headers look ordinary, the body is a verification email) is refused wherever a body is returned or sent, and by the destructive single-message operations (trash, modify, snooze, set a follow-up), which read the body at hiding levels. Plain listings may show a body-hidden row's headers.

Fail closed. At every level except Off: missing facts, a failed header fetch, a message that cannot be found, and an unknown level all count as hidden or unchecked, with one refusal text ("could not find or check this message…"). Unchecked rows are counted separately from hidden ones. The folder a caller names never exempts a message from classification: only the backend says whether a message sits in one of mailmcp's reserved folders (Graph from its parent folder id, IMAP from the folder it opened), and Graph read paths also refuse a named reserved folder the message is not in. The first review found that a by-id call on Outlook naming mailmcp-uploads skipped the check and returned the body unfiltered; it was fixed before release and is covered by a test of every by-reference tool on the real Graph and IMAP backends.

Searches and the oracle. The model controls the query, so any result that depends on hidden or redacted content would let it read a code digit by digit. Plain listings (folder, dates, flags only) skip header-hidden rows, keep the backend's total and report hidden_by_protection. Content queries (any query, from, to, subject, every Gmail raw query) skip header-hidden rows and body-check every remaining candidate, dropping body-hidden rows and, at redacting levels, every row where redaction would fire, whether or not the query touches those words; they report no hidden count. The body check reads the same text the redaction analyses: on IMAP both alternatives (the HTML, sanitised and with hidden text kept, and the plain part, which SEARCH TEXT matches too), each part up to 1 MB; on Graph the whole body. A candidate whose part is longer than 1 MB, or whose text is longer than the 256 KB that is analysed, is left out, since it could not be checked whole. The server's search also matches inside attachments, so the pass reads them too, within bounds (five parts of at most 1 MB each): text parts with their charset, attached mail (its own header and body pass; a hidden one is not looked into) and PDF text layers through the extractor; pictures, sound and video hold no searchable text. A candidate whose body or analysed attachment is hidden or would be redacted is dropped. When some part could not be analysed, the candidate is kept only if every query word shows in its analysed text (subject, sender, analysed body and attachments, and file names the level lets out unchanged), so nothing unanalysed can change the answer. A file name the level would hide or change counts as not analysed, since servers match names too. A query with a negation ("-word", NOT), a wildcard or an operator other than the header, state, label, date and size operators can make the server's own answer depend on an attachment or a name (it excluded or matched there), so such a query keeps only candidates with no attachment at all. Accepted residue: the check compares words as substrings of the analysed text, while servers match whole words or word prefixes; the two can differ on a word, but the difference depends only on analysed text, never on a hidden part. The release recheck found the earlier gap as a digit-by-digit oracle on a code inside an attached verification mail; a test now compares the answers with that mail attached and with a harmless one. The walk stops once offset + limit + 1 rows are visible, as plain listings do; the exact visible total is reported only when the walk ran out of matches, otherwise the total is the end of the page with total_exact: false, so a total never depends on how many bodies were dropped. Every search result from a protected account carries one constant line built from the account id and the setting only, byte-identical whether anything was hidden or not. A test compares whole content-query results between a mailbox with hidden, body-hidden and redaction-fired matches and one without, on the fake backend and on Dovecot. The comparison runs on the fake, on the real IMAP and Graph backends (over test doubles of the servers) and on Dovecot, with up to 100 matches at offsets 0 and 40. Accepted residue, stated here: each call examines at most offset + limit + 1 + 200 rows and reads at most offset + limit + 1 + 40 bodies, and hitting either bound yields total_exact: false; that happens with or without a secret only when more than 40 candidates in the window are dropped, and it can say "many matches were left out" but never what they contain; plain listings bisected by date reveal when hidden mail arrived; get_thread reveals that a thread has hidden members through coverage.hidden_by_protection. Response times can differ with the number of bodies checked; the model does not see latency, so this is accepted.

Redaction and bytes that leave. From Standard up (and Custom with codes, links or recovery), code tokens near a code keyword become [code removed] and sign-in URLs [sign-in link removed] in returned text and in reply quotes (quote HTML is rebuilt from the redacted text when redaction fired or an original link matches). The bytes of mail where redaction fires, or that could not be analysed, never leave: forward_message, send_draft (bound to the draft's fingerprint), attachment references in compose and get_attachment refuse, and /files answers 403. Text-like parts, PDF text layers and nested message/rfc822 parts (three levels deep, deeper refuses) are classified themselves, and an attachment's name is shown, downloaded, forwarded and attached only as the level lets it out ("(hidden by the protection level)" otherwise). A part is classified by the stricter of its declared type, its file name and its first bytes, so an attached mail or a text file sent as application/octet-stream is checked as mail or text; text is decoded with its declared charset, and a NUL left after decoding counts as not analysed. Attachment names are classified like subjects (Graph names an attached item after its subject; Gmail's forward-as-attachment calls it "<subject>.eml"): a hidden name is replaced with "(hidden by the protection level)" in message, thread and card listings, and codes are removed from the others at redacting levels. The text an onward path checks is read up to one character past the analysed 256 KB, so a longer text counts as not analysed; on IMAP a text part longer than the 4 MB read is flagged as cut. A PDF whose text layer could not be read (another extraction running, a timeout, the size or page cap, a parse error) does not leave either; only a PDF with no text layer at all (a scan) passes, as a binary attachment does. Such refusals say the message "could not be checked" rather than that it holds a code. Text the model composes in send_message and reply_send is not scanned: the owner may dictate a code on purpose. The draft card shows the reason protected and does not send.

Bulk. Header-hidden mail is never selected, sampled or counted by bulk_preview. Body-hidden mail can be moved (never deleted) by a bulk action, because selection is header-only; this is accepted. The confirm ref binds a hash of the protection setting, so an apply after a changed setting is refused. That matters most in owner mode, where the principal is the constant owner: without the hash a ref issued before a configuration change would stay valid. A 0.12 ref, which carries no hash, is accepted only for accounts at Off.

Microsoft Graph. Thread listings request the internet headers; rows without them are classified with known: false, which is more cautious and can make the same message visible in one call and hidden in the next. A search, triage or digest row whose headers were not read (beyond the per-call header fallback) cannot rule out a One-Time-Code header, so at a level that hides codes it is left out and counted as unchecked. The $search window is at most 1,000 rows; a full window with too few visible rows gives total_exact: false.

Download links. A /files/… link stays a bearer URL for one hour: an assistant with web fetch can read what it points at. Links are issued only for mail that passed the checks above, and /docs says so.

Binary attachments. Images and office files attached to visible, unredacted mail are not scanned; a code inside a screenshot passes.

Confusables. NFKC folds full-width and compatibility forms, and a fixed map folds common Cyrillic and Greek look-alike letters to Latin; other look-alike characters are not caught.

Records, Sent rows and Outlook flags. Follow-up and snooze records, awaiting items and Outlook flag rows are read without the decorator; every subject or counterpart a tool takes from them goes through the same header rules first. Rows of list_followups, the digest's due follow-ups and snoozes, and wake_snoozed are also checked against the message where it sits now, header and body (one batched header read, a body read only where the body pass could hide it): a record written at Off cannot name mail hidden by a One-Time-Code header or by its body. A row whose message cannot be found or checked in time is shown as hidden. The draft card keeps the quoted source's One-Time-Code fact in its record. Writing samples (list_templates samples) get the body pass too. Hidden mail still wakes and follow-ups on it still clear; results report it only as a count.

Nothing stored, nothing logged. Classification runs in memory while answering. The only log lines are protect_unchecked (account id, method, error class, count) and protect_unstamped; no subject, sender, code or URL is logged. A leak walk calls every tool in tools/list plus the accounts and app resources with canaries in every field of hidden fixtures and in the body, code and link of body-hidden and redacted ones, and fails on any canary in any serialised result.

Rollback is fail-open. A 0.12 server does not know the field and shows everything again, verification emails included; the CHANGELOG says so. Upgrading again restores the level from the configuration.

Known limitations.

Review before release. Two security reviews and a release-wide /recheck by Claude agents ran on the 0.13 work (record docs/replan/audit/2026-10-01-003426-recheck-9feb4b6.md): the recheck found a Critical search oracle (server-side search reading attached mail and query operators), fixed with "with vs. without the hidden part" probes on every backend before release, and its Important findings were fixed with tests. No independent second-model pass of this addendum was run.

18. Addendum: Usage statistics and MCP request counting (0.9.1, shipped in 0.13.0)

Written for release 0.9.1 (developed as 0.9.1, never released on its own, shipped in 0.13.0), after the reviews in section 1 and like section 13 not part of them. Two features, both statistics only. B counts running self-hosted copies: every copy sends at most one small request a day to mailmcp.ai, which is also its update check. A counts MCP requests on the vendor's own server mailmcp.ai as Vercel Web Analytics events. Code: src/stats/ping.ts (sender, ships in every build), src/stats/receiver.ts, src/stats/store.ts, src/http/stats-page.ts and src/stats/mcp-events.ts (vendor only, absent from the distribution, see "Dist boundary"). The public description with the exact request, the switches and the numbers is https://mailmcp.ai/stats.

Data flow (B).

Data flow (A). Only on mailmcp.ai with MAILMCP_MCP_EVENTS set, and only from a Vercel production deployment. Counted: initialize, tools/list and tools/call messages of a POST to /mcp (of a batch at most the first 10) and requests refused before MCP (401, unlicensed 503; at most 60 per instance and hour). Not counted: notifications, ping, server/discover and subscriptions/listen (the newer stateless protocol's first requests, sent instead of initialize: such clients appear only through tools/list and tools/call; owner ruling for 0.13.0), resources/*, prompts/*, calls of unknown tools; a body without a declared length (chunked) or declared larger than 64 KB is not inspected (its tools/call messages are still counted from the tool result). The event name is mcp <method>; the properties are the tool name if it is one of the server's own tools (- for other methods) and "<client family> <outcome>", where the family comes from a fixed list (ChatGPT, Claude, Claude Code, Cursor, other) and the outcome is ok, error or refused. The event goes to <public origin>/_vercel/insights/event with a fixed user agent and ts rounded down to the hour; no client IP, cookie, client user agent, token or content is forwarded. The raw client name and user agent are logged only with MAILMCP_STATS_DEBUG=1 on a deployment that also sets MAILMCP_STATS_NAMESPACE (the test project).

Can an installation be identified? (amended threat review)

Legitimate-interest assessment (Art. 6(1)(f) GDPR).

• *Purpose.* Know how many copies run, which versions and runtimes to support, when an old version can be retired, and which MCP features and clients are used on mailmcp.ai, to plan support and security fixes.
• *Necessity.* There is no account or licence server that could answer this; the licence check is offline by design. A daily request with enumerated fields is the least data that yields daily- and monthly-active counts. Alternatives rejected: a server-side hash of the IP address (processes the address for statistics, collapses copies behind NAT), exact sets of digests (would keep a monthly pseudonym per copy for a month), tier or geography fields (can single out a buyer).
• *Balancing.* No identifier; marginal counts only; the raw digest never reaches storage; retention bounded (hashes 48 h / 40 days, aggregates 400 days / 25 months); what is sent and the totals are public; the request is easy to see (one start-up log line) and to switch off. Server operators run infrastructure and reasonably expect an update check; the ping is disclosed in the changelog before upgrading, in /privacy, the README and the EULA draft.
• *Safeguards.* MAILMCP_NO_STATS=1, DO_NOT_TRACK=1, MAILMCP_NO_UPDATE_CHECK=1 (no request at all; "Check for updates" in Claude Desktop), each accepting 1, true, yes or on; CI and source builds never send, Vercel preview deployments send only the version check; the switch is the Art. 21 objection.
• *Desktop copies opt in.* Claude Desktop and other stdio copies run on a person's computer, where Art. 5(3) ePrivacy (§ 89 of Czech Act 127/2005) reads broadly. Their statistics are off unless the user ticks "Anonymous usage statistics" or sets MAILMCP_STATS=1; an empty or unexpanded setting counts as off, so upgrades stay off. They keep the body-less update check.

Dist boundary. The receiver, the store, /stats and the MCP events are loaded by dynamic import() behind an inline process.env.MAILMCP_DIST !== '1' check in createApp, which esbuild folds away in the dist and MCPB builds. Each vendor module carries a marker string (the prefix is deliberately not quoted here, because this audit is itself bundled into the distribution); scripts/vendor-guard.mjs, called from build-dist.mjs and build-mcpb.mjs, fails the build if any bundle contains one, if a bundle lacks the sender or names the geo header, if the MCPB manifest's statistics setting is not off by default or its "Check for updates" setting is missing, or if the Dockerfile lacks MAILMCP_RUNTIME=docker. A dist copy answers 404 on /api/ping, /api/version and /stats even with MAILMCP_STATS_RECEIVER=1 (checked on the built dist/node.js).

Residual risks.