# LiteMX Security

LiteMX separates human dashboard authentication from API, CLI, and MCP authorization.

Human dashboard auth is planned through Clerk. API, CLI, and MCP access use LiteMX-owned scoped tokens because mailbox-level access is a core product boundary.

## Scoped Tokens

Tokens should be restricted by mailbox and action. A useful token model supports:

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

Read scope does not imply send scope.

## Audit Logs

LiteMX records CLI/API/MCP actions in D1 audit events. Audited actions include:

- Message reads.
- Searches.
- Draft creation.
- Send attempts.
- Successful sends.
- Blocked sends.
- Token creation and revocation.

Operators can inspect audit history from the terminal:

```sh
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

Retention controls cost and liability. Lower-cost plans should delete message bodies and attachments sooner, while preserving metadata and audit logs long enough for operational history.

The Worker cron runs daily and applies the v0 retention policy:

- Message content is deleted after each mailbox retention window, defaulting to 60 days.
- Raw MIME, text bodies, HTML bodies, and attachment objects are removed from R2.
- Message rows are kept as metadata with sender, recipients, subject, thread id, mailbox id, timestamps, and `deletedContentAt`.
- Attachment rows are tombstoned with `deletedAt` 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 with a `system` actor and deletion counts.
- The founder admin token can run the same cleanup path manually with `litemx retention run` for testing.

## Outbound Controls

Outbound sending should be protected with:

- Explicit send scope.
- Recipient limits per message.
- Daily send limits per mailbox.
- Daily send limits per account.
- Monthly send limits per account.
- Provider bounce and complaint suppression.
- Fast disablement for abusive domains, mailboxes, tokens, or accounts.
- Provider abstraction so LiteMX can use AWS SES first and keep optional/legacy provider paths for domains that already use Cloudflare DNS.

LiteMX is not for bulk marketing, newsletters, cold outreach, lead generation, or purchased recipient lists. See the sending policy, anti-spam policy, acceptable use terms, and bounce/complaint handling pages before enabling outbound sending.

Current plan-level outbound caps are:

| Plan | Per mailbox/day | Per account/day | Per account/month | Recipients/message |
| --- | ---: | ---: | ---: | ---: |
| Free | 100 | 100 | 500 | 10 |
| Starter | 300 | 300 | 3,000 | 10 |
| Scale | 1,000 | 1,000 | 15,000 | 10 |

AWS SES production access is separate from domain verification. LiteMX can receive provider-ingested mail while SES outbound remains blocked for arbitrary external recipients if AWS keeps the account in sandbox or denies production access.