Security And Controls

Authentication Boundaries

Clerk authentication is deployed for the human dashboard. A short-lived Clerk session is verified against LiteMX's pinned key, issuer, and allowed web origins before POST /dashboard-api/bootstrap can bind the Clerk subject to a LiteMX account.

API, CLI, and MCP access use LiteMX-owned bearer tokens. These trust boundaries are intentionally disjoint: Clerk sessions are not accepted by /api/* or /mcp, and LiteMX API tokens do not become dashboard sessions. Email address, display name, signup order, and request-supplied account fields do not determine account ownership.

Scoped Tokens

LiteMX tokens separate capabilities such as:

• Listing mailboxes.
• Reading messages.
• Searching messages.
• Creating drafts.
• Sending drafts.
• Reading audit logs.

Read scope does not imply send scope. Tokens can also be restricted to named mailboxes, while account-wide address and forwarding inventory changes require an unrestricted mailbox grant. Revoking a token prevents future API, CLI, and MCP use.

Verified Forwarding Destinations

A destination inbox moves through pending, verified, and disabled states. LiteMX stores a hash of each expiring one-time verification challenge and never returns the raw challenge in destination responses. Forwarding cannot be enabled until the destination is verified.

General challenge delivery is not implemented yet. For founder dogfood only, an exact server-configured email on the founder account can be marked verified immediately. A Clerk profile email is not treated as proof of inbox ownership.

Signed Reverse Replies

Every forwarded message receives an expiring reverse-reply address on LiteMX's dedicated reply domain. Its token is HMAC-signed and bound to the account, mailbox, verified destination, original correspondent, source message, and thread. Only the token hash is stored; the raw token exists in the provider-bound Reply-To address.

A reverse reply is relayed only when every check passes:

• It arrived through the trusted AWS SES event path, not direct or simulated ingress.
• SES reports an exact DMARC PASS verdict.
• The sender exactly matches the destination still verified for that mailbox.
• The mailbox binding remains enabled.
• The signed token is valid, unexpired, unrevoked, and matches the original correspondent and thread.

A missing provider verdict, non-PASS DMARC result, different sender, stale token, or changed binding fails closed without relaying mail.

Disablement And Revocation

Disabling mailbox forwarding makes its existing reverse-reply addresses unusable because an enabled binding is required at relay time. Disabling a destination clears any pending verification challenge, disables every mailbox binding that uses it, and explicitly revokes its reverse-reply aliases. Disabling a mailbox marks its inbound and outbound capabilities disabled while retaining message and audit history under the retention policy.

Current Attachment Constraints

Attachments are not yet carried through the existing-inbox loop. LiteMX stores attachments from incoming customer mail, but the forwarded copy omits their bytes and includes an attachment-count notice. A reverse reply containing an attachment is rejected and is not relayed to the original correspondent.

Use text or HTML-only messages for current testing. These controls have passed one production text-only round trip, but two more founder-domain passes and attachment handling remain on the full dogfood checklist.

Audit Logs

LiteMX records CLI/API/MCP actions in D1 audit events, including message reads, searches, draft creation, send attempts, successful sends, blocked sends, and token lifecycle events.

litemx audit list [--mailbox <mailbox>] [--action <action>] [--resource-type <type>] [--limit <n>]

Mailbox-scoped tokens only read audit rows tied to their granted mailboxes.

Retention

The Worker cron runs daily and applies the v0 retention policy. Message content is deleted after each mailbox retention window, defaulting to 60 days, while metadata and audit rows are kept longer for operational history.

• Raw MIME, text bodies, HTML bodies, and attachment objects are removed from R2.
• Message rows remain as metadata with sender, recipients, subject, thread id, mailbox id, and timestamps.
• Attachment rows are tombstoned and hidden from normal message reads.
• Message metadata and audit rows are pruned after 365 days.
• Each cleanup run writes a retention.cleanup audit event.

Outbound Controls

• Explicit send scope.
• Recipient limits per message.
• Daily send limits per mailbox and per account.
• Monthly send limits per account.
• Provider bounce and complaint suppression.
• Fast disablement for abusive domains, mailboxes, tokens, or accounts.

LiteMX supports ordinary correspondence and transactional mail. Permission-based marketing requires a future isolated broadcast mode with consent, unsubscribe, suppression, and metering. Cold-outreach automation, spam, phishing, and purchased or scraped recipient lists are prohibited.

Plan Send Limits

Provider account permission is separate from domain verification. LiteMX can receive provider-ingested mail while one outbound adapter is unavailable and later assign the verified domain to another permitted route.