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;
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.

The JMAP Store design defines the one-Store architecture, compatibility metadata, migration, and release gates. The PWA and Push design 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 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.

11 KiB Raw Blame History