# Mail Protocol Roadmap

GovOPlaN Mail currently focuses on SMTP sending and IMAP mailbox access. POP3
and JMAP are deferred until the IMAP mailbox MVP is stable.

## Current Baseline

- SMTP is the send protocol.
- IMAP is the read/append protocol.
- Mail profile policy, encrypted credentials, mailbox folder parsing, test
  buttons, and read-only mailbox UI are built around SMTP and IMAP.

This baseline matches the first production use case: send campaign mail, append
sent copies when configured, and inspect mailboxes read-only.

## JMAP

JMAP is the preferred future sync/search protocol where target mail servers
support it.

Reasons:

- HTTP/JSON transport fits the platform API style better than stateful IMAP
- efficient mailbox state sync and changes endpoints
- modern search and thread models
- better fit for browser-facing mailbox UX through a server proxy

JMAP should be added only after:

- the IMAP mailbox MVP has stable folder/message pagination behavior
- mail profile policy can express protocol-specific availability
- mailbox UI can handle protocol-neutral folder/message DTOs
- test infrastructure includes at least one reliable JMAP server target

## POP3

POP3 should remain legacy-only.

Add it only when a concrete deployment requires mailbox download from a server
that cannot offer IMAP or JMAP. POP3 is a poor fit for the normal GovOPlaN
mailbox UX because it has limited folder, sync, and server-side state semantics.

If implemented, POP3 should be scoped to explicit download/import workflows, not
general mailbox browsing.

## Decision

Do not add POP3 or JMAP now. Stabilize SMTP/IMAP first, design protocol-neutral
mailbox DTOs, then prefer JMAP for modern servers and reserve POP3 for explicit
legacy download requirements.