73 lines
2.8 KiB
Markdown
73 lines
2.8 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.
|
|
|
|
## Message Protection Profiles
|
|
|
|
The product and security profile approved on 2026-08-04 makes S/MIME the first
|
|
institutional signing/encryption profile and OpenPGP an additional explicit
|
|
profile. Neither profile is implemented by treating protection as a local Mail
|
|
toggle:
|
|
|
|
- private-key custody belongs to an Encryption/KMS provider and usable private
|
|
keys are never persisted by Mail;
|
|
- recipient certificates and keys initially come from administered directory
|
|
or LDAP sources; opportunistic Internet discovery is deferred;
|
|
- required signing or encryption fails closed when material is missing,
|
|
expired, revoked, unverifiable, or its provider is unavailable;
|
|
- plaintext fallback is permitted only by an explicit, audited policy and is
|
|
never inferred from provider failure; and
|
|
- delivery evidence pins the signing identity, trust/revocation evidence,
|
|
algorithm suite, key version, and any explicit downgrade decision.
|
|
|
|
Provider-neutral S/MIME custody and interoperability fixtures are the first
|
|
implementation slice. OpenPGP uses the same no-silent-downgrade boundary after
|
|
the S/MIME profile is stable.
|
|
|
|
## 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.
|