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 a 0.8 UI refresh, evaluate a pinned, self-hosted HTMX release with
  server-rendered HTML fragments instead of adopting a large client-side SPA
  stack. Never require a public CDN at runtime, and retain a functional
  hyperlink/form baseline where practical.
- 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.
- Target JMAP Core (RFC 8620), JMAP Mail (RFC 8621) and JMAP Contacts
  (RFC 9610) for the 0.9 series as the modern primary synchronization API.
  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.