51 lines
1.7 KiB
Markdown
51 lines
1.7 KiB
Markdown
# 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.
|