1.7 KiB
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.