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;
• complete calendar sharing, invitations, free/busy, delegation, and resource calendars such as rooms;
• 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 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;
• JMAP mail, submission, contacts, and calendars backed by the existing Store, while retaining IMAP/POP3/SMTP for old and current clients;
• scheduled external CalDAV calendar subscriptions and provider calendar sync, reusing the external-account identity and credential model;
• stable migration and compatibility APIs needed by the Web redesign and future clients.

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.