bongo/docs/roadmap.md

# Roadmap to Bongo 1.0

This roadmap combines the still useful goals from the historical Bongo 1.0
plan with the work in the maintained tree. It describes release intent, not a
promise that an unfinished item is already safe for production.

The guiding constraints are:

- keep Bongo an integrated, understandable server for power users, homelabs,
  and small organisations;
- preserve open protocols and old-client interoperability where it does not
  weaken secure defaults;
- use one Store, account model, filter model, and administration path;
- retain the familiar Web design through 0.7, then redesign from the complete
  feature set rather than inventing a second product;
- keep the server in C and the Web interface in Python 3; no Ruby rewrite is
  part of the plan.

## 0.7.0: modernised, testable foundation

The 0.7 release line finishes the forward port before a final tag is made:

- CMake/CPack packaging split by subtree, FHS paths, systemd/OpenRC support,
  current dependencies, GCC/Clang warning cleanup, sanitizer runs, and
  32-bit/ARM portability checks;
- SMTP receive/send, submission, LMTP, opportunistic and required TLS policy,
  trusted port 26 device relay, PROXY v1/v2, XCLIENT/XFORWARD, and explicit
  fallback client-address headers;
- IMAP4rev2, IMAP4rev1, legacy IMAP4, POP3/POP3S, ManageSieve, UTF-8 handling,
  and Store operations required by those protocols;
- SPF, DKIM, DMARC, SRS, ClamAV, SpamAssassin, Sieve, vacation, and structured
  authentication logs suitable for Fail2ban;
- Argon2id passwords, optional TOTP and recovery codes, app passwords, LDAP/AD
  authentication and provisioning, outage cache administration, aliases, and
  safe user rename;
- Python 3 Webmail, restored classic assets, safe HTML mail rendering,
  CalDAV/CardDAV, user tasks, filters, signatures, identities, and external
  POP3/IMAP account collection with matching SMTP relays;
- guided curses setup, validated curses administration, provider presets,
  reverse-proxy/scanner examples, manual pages, and maintained documentation.

The tag is gated on a clean local staged installation, agent startup, account
setup, end-to-end local delivery, public SMTP scenarios, IMAP/POP3/ManageSieve,
Web/CalDAV/CardDAV, scanner failure modes, upgrade handling, GCC and Clang,
sanitizers, and package QA. IPv6 and JMAP are intentionally not 0.7 features.

`CHUNKING`/`BDAT` is supported for normal MIME messages. `BINARYMIME` remains
unadvertised until Queue, Store, authentication/filter agents, and outbound
delivery have an end-to-end binary-safe path and interoperability tests.

## 0.8: complete and reorganise the Web experience

0.8 uses the feature-complete 0.7 interface as the inventory for a responsive,
simple redesign:

- organise account, identity, external-provider, filter, signature, TOTP,
  app-password, task, quarantine, calendar, and contact settings coherently;
- complete the user and Web administration surfaces without replacing the
  validated command-line/TUI tools;
- improve the composer, quoting, contact selection, mailing-list actions,
  search, timezone handling, diagnostics, and accessible error messages;
- introduce one user-defined tag model with names, colours, icons, ordering,
  and assignments across mail, calendar events, contacts, and tasks; expose
  mail tags as IMAP keywords while retaining the standard flagged/starred
  marker for old clients;
- offer a unified activity view where messages, appointments, contacts, and
  actionable notices can be filtered and marked consistently, while retaining
  their distinct Store types and protocol semantics;
- complete calendar sharing, invitations, free/busy, delegation, and resource
  calendars such as rooms;
- make the complete Web interface an installable PWA with a manifest,
  responsive standalone navigation, a strictly scoped Service Worker,
  cache-safe upgrades, offline/error recovery, foreground notifications, and
  a transport-neutral notification/state contract ready for later Web Push;
  private mail, calendar, contact, task, quarantine, authentication, and
  administration responses are never placed in a persistent offline cache,
  and 0.9 must not require another Web application rewrite;
- provide clear restart/reload indications, service health, queue summaries,
  scanner state, useful logs, and safe certificate deployment hooks;
- finish maintained translations and the gettext workflow.

The Bulwark Webmail information architecture is a useful 0.8 UX reference for
the mail, calendar, contacts, settings, and administration surfaces. Bongo
will adapt the interaction model to its own Store and protocols, with an
independent implementation and Bongo-compatible artwork/licensing; the 0.7
server does not acquire a JMAP or Stalwart dependency from that reference.

The classic Bongo/Dragonfly visual identity and usable existing artwork stay
available. A small progressive-enhancement library such as HTMX may be used
only when its stable release, licence, packaging, and long-term maintenance
fit Bongo; it is not a reason to rewrite working server code.

## 0.9: new protocol and network generation

0.9 introduces changes which must be coherent across the whole server:

- IPv6 for listeners, ACLs, rate limits, DNS, SPF, logs, PROXY metadata,
  trusted relay mapping, Fail2ban, and setup validation;
- a full JMAP service backed by the existing Store: Core, Mail, Submission,
  MDN, Sieve, Quotas, Contacts/JSContact, Calendars/JSCalendar, Blob
  Management, VAPID Web Push, principals, and the common sharing model, while
  retaining IMAP/POP3/SMTP, CalDAV, and CardDAV for old and current clients;
- shared files and mailboxes through the JMAP FileNode and mail-sharing
  extensions once their Standards Track specifications are stable; draft
  versions may be exercised behind experimental capabilities but are not part
  of the supported 0.9 interoperability contract;
- authenticated external CalDAV/provider calendar sync, building on the
  HTTPS iCalendar URL subscriptions already available in 0.7 and reusing the
  external-account identity and credential model;
- stable migration and compatibility APIs needed by the Web redesign and
  future clients.

The [JMAP Store design](jmap.md) defines the one-Store architecture,
compatibility metadata, migration, and release gates. The
[PWA and Push design](web-pwa.md) makes the installable 0.8 Web application a
prerequisite for 0.9 background notifications.

Native Exchange/MAPI or ActiveSync compatibility remains research after the
open-protocol work. It is not a 0.9 or 1.0 release gate.

## 1.0: product readiness and federation-friendly identity

1.0 closes the historical product goals and makes the supported deployment
contract explicit:

- complete virtual-domain, domain-alias, address-alias, forwarding, shared
  mailbox, calendar-sharing, resource, and delegation administration;
- finish full Web and TUI administration for accounts, agents, listeners,
  certificates, domains, aliases, queue state, logs, health, and upgrades;
- provide reproducible migration, backup, restore, disaster-recovery, and
  large-mailbox procedures with performance and integrity tests;
- run protocol interoperability, malformed-input, open-relay, authentication,
  mail-authentication, fuzzing, sanitizer, and external mail-server test suites;
- redesign the complete message pipeline for arbitrary binary payloads and
  enable SMTP `BINARYMIME` only after receive, Queue, Store, filters, signing,
  and outbound `BDAT` delivery pass byte-for-byte interoperability tests;
- complete a documented security review and threat model before the stable
  release;
- stabilise configuration schemas, Store-facing APIs, upgrade rules, and
  distribution packages.

### OAuth for external mail providers

User-configured freemail accounts gain OAuth 2.0 provider linking in addition
to password authentication. Provider presets describe authorization, token,
revocation, IMAP/POP3, and SMTP endpoints and required scopes. The Web flow
uses Authorization Code with PKCE; encrypted refresh tokens are rotated and
revocable. Mail connections use provider-supported SASL `OAUTHBEARER` or
`XOAUTH2`, with a clear per-provider fallback only when OAuth is unavailable.
No provider password or token appears in a command line or log.

Incoming collection and outgoing identity stay coupled to the same user-owned
external account, including mailbox target, source-deletion policy, sender
verification, and task/error reporting. OAuth support is implemented as part
of Bongo's account model, not by requiring Fetchmail or a separate relay
service.

### Authelia and OIDC master login

Authelia can be selected as an optional OpenID Connect source for the Bongo
master login alongside local and LDAP authentication. Integration uses OIDC
discovery, Authorization Code with PKCE, strict issuer/audience/redirect
validation, signed state and nonce values, and explicit group/claim mapping
for account provisioning and administrator roles.

OIDC supplies an interactive master sign-in; Bongo does not collect or relay
the Authelia password. IMAP, POP3, SMTP, and ManageSieve continue to use
service-scoped Bongo app passwords, so mail remains available during a bounded
identity-provider outage. Recovery, cache lifetime, forced revocation, and
local emergency-administrator policy must be configurable and audited. TOTP at
Authelia and Bongo must not accidentally require two redundant second-factor
prompts unless the administrator explicitly chooses that policy.

## Historical 1.0 goals retained

| Historical milestone or requirement | Current destination |
| --- | --- |
| Antispam, antivirus, CLI configuration, and reviewed logging | 0.7 foundation; 1.0 operational/security validation |
| Web administration, command tools, virtual domains, aliases, and forwarding | 0.7 TUI/base model; 0.8 UI; 1.0 completion |
| CalDAV and internationalisation | 0.7 base protocol; 0.8 sharing/UI/translations |
| Calendar sharing, invitations, free/busy, and resource calendars | 0.8 and 1.0 completion |
| User preferences, better composer, contacts, search, and mailing-list actions | 0.7 base features; 0.8 UX completion |
| Useful diagnostics, queue management, service statistics, and logs | 0.7 tools; 0.8 UI; 1.0 operational gate |
| Security review before stable release | Mandatory 1.0 gate |

The old milestone labels and dates were planning history, not current release
dates. Their product goals remain where they still make sense; obsolete
implementation advice does not.

## Explicitly excluded directions

- no WeBongo/RBongo or other Ruby rewrite;
- no return to Python 2, mod_python, Autotools, or a bundled managed slapd;
- no insecure SSL/TLS protocol enabled by default;
- no dependency on Rspamd, Fetchmail, Postfix, or Dovecot for core advertised
  Bongo features;
- no claim of an extension merely because another server implements it.