add-ideas/govoplan-mail
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

Sync wiki from project files

Albrecht Degering
2026-07-09 12:34:36 +02:00
parent 9557b44673
commit ce55533849
3 changed files with 73 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
Codex-Project-Index.md

@@ -5,3 +5,4 @@
This page is generated from repository and product-directory project files.
- [Repo-README](Repo-README) - `/mnt/DATA/git/govoplan-mail/README.md`
- [Repo-docs-MAIL-PROTOCOL-ROADMAP](Repo-docs-MAIL-PROTOCOL-ROADMAP) - `/mnt/DATA/git/govoplan-mail/docs/MAIL_PROTOCOL_ROADMAP.md`

17
Repo-README.md

@@ -1,4 +1,4 @@
<!-- codex-wiki-sync:ff2ec077f7ec5c5d857c3379 -->
<!-- codex-wiki-sync:d8151662f7ed0ba554199c1f -->
> Mirrored from `/mnt/DATA/git/govoplan-mail/README.md`.
> Origin: `repository`.
@@ -57,7 +57,20 @@ Frontend package:
@govoplan/mail-webui
```
The campaign module depends on this module for sending, append-to-Sent behavior, profile selection, and read-only mailbox inspection.
The campaign module consumes `mail.campaign_delivery` for sending,
append-to-Sent behavior, profile selection, and policy checks. Mail does not
import campaign internals; campaign-scoped policy and owner context are resolved
through the core `campaigns.mailPolicyContext` capability when the campaign
module is installed.
Development mailbox routes are registered by the mail module only when the
core runtime is in `dev` mode and `dev_mailbox_api_enabled` is enabled. Core
does not contribute these routes directly.
POP3 and JMAP are deferred. The protocol decision is documented in
[docs/MAIL_PROTOCOL_ROADMAP.md](docs/MAIL_PROTOCOL_ROADMAP.md): stabilize
SMTP/IMAP first, prefer JMAP for modern mailbox sync/search later, and add POP3
only for explicit legacy-download requirements.
Platform RBAC and governance rules are documented in `govoplan-core/docs/`.

57
Repo-docs-MAIL-PROTOCOL-ROADMAP.md Normal file

@@ -0,0 +1,57 @@
<!-- codex-wiki-sync:4b23dd9ca1e75c81edfd3053 -->
> Mirrored from `/mnt/DATA/git/govoplan-mail/docs/MAIL_PROTOCOL_ROADMAP.md`.
> Origin: `repository`.
> Active tasks and changing state belong in Gitea issues; this wiki page is durable project context.
---
# 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.