bongo/ROADMAP.md

Bongo roadmap

0.7.0 implementation status (2026-07-16)

Completed foundations: CMake/CPack packaging, GCC/Clang warning cleanup, Python 3.14 compatibility, system vobject/dateutil migration, SMTP/IMAP/POP build targets, SPF/DKIM/DMARC/SRS libraries, GNU GSASL PLAIN/LOGIN support, RFC 5228 validation/ManageSieve scaffolding, systemd templates, and sanitizer test coverage. Native external-account collection and provider SMTP routing, the guarded internal relay, persistent user tasks, and personal text/HTML signatures with verified sender identities are also implemented.

Still required before the 0.7.0 release: persistent user filter editing, complete IMAP/POP/SMTP capability work, TOTP and app passwords, complete CalDAV/CardDAV behavior, interoperability tests, and distribution Ebuilds/packages. No release tag is valid until these items are implemented and tested.

Required for Bongo 0.7.0: modern mail protocols

• Separate SMTP relay on port 25 from authenticated submission on ports 587 (STARTTLS) and 465 (implicit TLS). Submission must require authentication by default and use its own relay and sender policies.
• Add an optional internal relay listener (port 26 by default) for appliances and trusted services. It must be disabled by default, bind independently and refuse to start without an explicit source-network allowlist.
• Configure the internal relay through the installation wizard, the web admin interface and the console configuration tool. All three must share one schema and validation for bind address, networks, normalization domain, explicit device mappings, verified DNS suffixes, TLS compatibility and rate limits.
• Add external mail accounts as per-user database objects, never global server configuration. One account combines inbound IMAP/POP collection settings, retention/deletion policy, folder mapping and duplicate tracking with its authenticated outbound SMTP identity. Store provider passwords, app passwords and SMTP tokens only in the encrypted credential store. Users manage their own accounts in web settings; administrators control policy and may assist through admin and console interfaces. Include provider connection tests, certificate verification, secret rotation and explicit Proton Bridge/SMTP-token modes.
• Detect mailing lists primarily from RFC 2919 List-ID and RFC 2369 List-Post headers. Expose filter conditions for any mailing list and for a specific canonical List-ID; existing move/copy actions then file messages in a user-selected mail folder.
• Show a per-user ! task when a new List-ID is first detected. From that task the user can create a folder rule, ignore it once, permanently disable future prompts for that List-ID, or delete the task. Deleting a task must never delete its message; message deletion is a separate explicit action. Persist task state by user and canonical List-ID so ignored/disabled prompts do not reappear, and provide equivalent controls in web settings.
• Provide a general per-user filter editor. Conditions include sender address, sender domain, recipient, subject, arbitrary headers, message size, mailing list/List-ID and membership of the sender in a contact group (for example, group Family). Actions include move/copy to a folder, forward, delete and stop processing. Validate every rule server-side and never grant the web process unrestricted write access to the system configuration store.
• Add per-user plain-text and HTML signatures to the restored web composer. Allow multiple signatures and select a default per sender identity or external account. Never append a personal signature a second time to mail composed by IMAP/SMTP clients. Keep PlusPack signatures as a separate, administrator-controlled organization disclaimer feature.
• Use RFC 5228 Sieve as the public filter import/export format and provide an RFC 5804 ManageSieve service on port 4190 with STARTTLS and secure SASL. Web filters, imported scripts and ManageSieve must share one parser, capability set, validator and active-script store; unsupported extensions must produce an explicit error rather than being silently discarded.
• Provide a native RFC 5230 vacation action and RFC 6131 vacation-seconds for the web out-of-office assistant. Bongo must own sender suppression, loop prevention, rate limiting, reply generation and audit logging; do not execute Mailutils' external vacation delivery module.
• Use GNU GSASL as the common authentication mechanism implementation for SMTP submission, IMAP, POP3 and ManageSieve. Keep authorization, app-password policy and auditing in Bongo callbacks; do not duplicate PLAIN, SCRAM or OAUTHBEARER protocol implementations in individual agents.
• Support SASL PLAIN and LOGIN over TLS, SASL initial responses, SCRAM-SHA-256, app passwords and optional OAUTHBEARER/EXTERNAL. Never advertise mechanisms that are unavailable or unsafe on the current connection.
• Add POP3 SASL and integrate its authentication with app-password policy.
• IMAP IDLE is implemented with store-event polling and a 29-minute renewal boundary. UIDPLUS (APPENDUID, COPYUID, UID EXPUNGE) and rollback-safe Store MOVE are implemented while retaining the legacy IMAP4 capability. Add SPECIAL-USE, LIST-EXTENDED and LITERAL+.
• Add IMAP ENABLE and UTF8=ACCEPT, then advertise IMAP4rev2 only after every mandatory rev2 behavior and interoperability test passes.
• Implement SMTPUTF8 end to end through submission, relay, LMTP, queue, DSN, DKIM and SRS handling.
• Add outbound certificate verification and policy support for DANE, MTA-STS, TLS-RPT and REQUIRETLS.
• Add CONDSTORE/QRESYNC, ESEARCH/SEARCHRES, SORT/THREAD, BINARY and APPENDLIMIT.
• Cover every advertised capability with protocol tests and Thunderbird interoperability tests.

Required for Bongo 0.7.0: authentication hardening

• Add optional TOTP two-factor authentication for the web interface and administration.
• Add single-display recovery codes and a secure recovery/reset workflow.
• Add individually revocable app passwords for IMAP, POP3, SMTP submission, CalDAV and CardDAV.
• Allow each app password to be restricted by service, expiry time and, optionally, source network.
• Store app passwords with Argon2id and encrypt TOTP secrets at rest. Never store or display reusable plaintext credentials.
• When 2FA is enabled, allow administrators to require app passwords and disable the account password for non-interactive protocols.
• Record creation, last use, service and source address without logging the credential itself.

Possible implementation dependencies are liboath, libargon2 and optional libqrencode. This work is a release requirement for Bongo 0.7.0 and must be implemented and tested after CalDAV/CardDAV and the web restoration, before packaging and release.

Groupware

• Complete CalDAV event discovery, synchronization and CRUD operations.
• Add CardDAV contacts using Bongo's existing address-book store.
• Add Thunderbird-oriented setup and RFC 6764 service discovery.
• Keep Outlook/MAPI/OpenChange integration deferred until after 0.7.0. Preserve stable service boundaries and identifiers in authentication, contacts, calendars, folders and filters so that a future MAPI compatibility layer can be added without coupling it to the web UI or replacing the core data model.

Deferred until after 0.7.0

The following historical features are useful references, but are explicitly outside the 0.7.0 release scope:

• Restore iTIP scheduling and invitation processing after CalDAV behavior and interoperability are complete. Reuse the retained itip agent only after a security and ownership review.
• Restore calendar alarms/reminders as a separately configurable service. The retained alarm source is a starting point, not release-ready code.
• Consider the old calendar-by-mail calcmd feature as an optional component; it must not be enabled by default until its parser and authorization model have been hardened.
• Add safe, documented backup, restore and portable user export tooling. Do not resurrect the removed bongo-backup or bongo-migrate implementations, which were removed as dangerous or obsolete.
• Add message full-text search using a maintained backend such as SQLite FTS5 or Xapian. Do not restore the removed bundled CLucene snapshot.
• Reintroduce selected PlusPack organization policies, including optional organization disclaimers/signatures and attachment rules, separately from users' personal signatures and only as explicit administrator features.
• Use the historical Sundial and Hawkeye code only as behavioral and data-model references. Their Python 2 web implementations and obsolete management stack must not return to the build.
• Keep Outlook/MAPI compatibility, SMS gateways and other niche connectors as separately evaluated post-0.7 projects rather than implicit core features.
• Keep the restored Dragonfly/Bongo appearance and original licensed assets in 0.7 while making its layout responsive and accessible. Evaluate a deliberate Material Design refresh for 0.8; do not mix that redesign into the 0.7 compatibility work or replace existing artwork with generated icons.
• For the 0.8 UI refresh, integrate Bulwark Webmail as a pinned, unmodified submodule. Apply only small generic upstream-candidate patches to a build copy, keep Bongo settings in a separate bundled plugin, and supply only the licensed Bongo logos, favicon and PWA icons through configuration. Keep Bulwark's layout, colours, themes and light/dark mode unchanged. Implement the minimum standard JMAP service required by the Webmail before replacing the classic interface; see docs/webmail-upstream.md.
• Extend external provider accounts beyond mail with optional calendar and contact services. Support read-only private iCalendar feed subscriptions as well as CalDAV/CardDAV synchronization where the provider offers it, and use OAuth instead of stored account passwords where required. Mail, calendar and contacts may share one provider preset and credential grant, but must remain independently enabled and revocable by the user.
• Complete JMAP Core (RFC 8620), JMAP Mail (RFC 8621) and JMAP Contacts (RFC 9610) for the 0.9 series as the modern primary synchronization API, building on the standards-conforming Webmail slice introduced for 0.8. Keep IMAP4rev1, POP3, CalDAV and CardDAV as compatibility protocols; do not remove them while major clients such as Thunderbird still depend on them. Track JMAP Calendars, but do not advertise its capability until the IETF specification is published and Bongo passes interoperability tests.

The removed MDB/MDB-XLDAP, DMC/statistics, ConnMgr/NMAP management, legacy logging, old mail proxy and incomplete Dragonfly history code are obsolete architecture and are not candidates for reactivation.

External library cleanup

• Prefer maintained system libraries over historical bundled snapshots.
• Keep libical as the native iCalendar parser/converter and update the minimum supported system version after cross-architecture testing.
• Bongo 0.7 uses system vobject/python-dateutil, Python's json and email standard libraries, and no longer ships the historical bundled copies.
• SimpleTAL remains temporarily embedded only for the legacy administration templates; replace that layer after the restored web administration UI has equivalent coverage.