Mail Protocol Roadmap

GovOPlaN Mail focuses on SMTP sending and IMAP mailbox access. It also provides an explicitly enabled, bounded POP3 legacy-import path. JMAP remains deferred until the IMAP mailbox MVP and protocol-neutral mailbox contract are stable.

Current Baseline

SMTP is the send protocol.
IMAP is the read/append protocol.
POP3 is an optional legacy migration source, never a general mailbox protocol or default profile endpoint.
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 remains legacy-only. The bounded import slice is available when a concrete deployment must retire a mailbox that cannot offer IMAP or JMAP.

It is disabled until an administrator creates a dedicated POP3 endpoint and sets legacy_import_enabled. The endpoint has its own encrypted credential, connection/TLS/authentication diagnostics, maximum message and batch sizes, preview body limit, and a separate allow_delete_after_import policy. Stable UIDL support is mandatory; Mail refuses import when a provider cannot supply it.

Preview and ordinary import are non-destructive. Selected messages become encrypted pending_review records with a content digest, pinned transport revision, source UIDL, and audit evidence. Repeating a UIDL reports a duplicate. Provider deletion requires both endpoint policy and mail:pop3:delete, is chosen separately per batch, and runs only after the local import and its audit event commit. A disconnect while POP3 QUIT commits deletions becomes outcome_unknown and is never retried blindly.

POP3 does not supply folder, flag, thread, search, or synchronization semantics. It is therefore excluded from the normal mailbox UI and from the recommended ongoing Mail profile. Configuration-package export/import remains SMTP-focused; legacy source rollout is an explicit operational action.

Decision

Keep the implemented POP3 surface limited to governed legacy import. Do not expand it into mailbox browsing. Design protocol-neutral mailbox DTOs and prefer JMAP for future modern synchronization/search support.

4.0 KiB Raw Blame History