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.

2.8 KiB Raw Blame History