Mario Fetka
c868762546
BODY[]<start.length>, BODY[HEADER]<...>, and BODY[TEXT]<...> partial ranges are implemented server-side (src/agents/imap/fetch.c) but had zero test coverage anywhere. contrib/testing/imap-fetch-partial-check.py verifies each partial range against a self-consistent reference (a full, non-partial FETCH of the same section first): a prefix, a middle range, a length longer than what remains clamping to the rest of the section rather than erroring, and an offset beyond the section's size returning an empty literal rather than an error. Confirmed empirically that a FETCH request's partial spec always requires both start and length (RFC 3501 6.4.5) -- the bare "<number>" form only ever appears in the server's response, not as something a client can send; Bongo correctly rejects it with BAD, which the test's first draft caught. Wired into ctest via contrib/testing/CMakeLists.txt's bongo_add_live_test(). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bongo documentation
This directory is the maintained documentation for the Bongo development tree. It replaces operational advice from the archived project website where paths, dependencies, security policy, or implementation status no longer match the current code.
Bongo 0.7 is still under development. A feature listed here is available in the tree, but a public server should be staged and tested before it replaces an existing mail system. The roadmap distinguishes completed, partial, and planned work.
Start here
- Architecture describes the agents and data flow.
- Administration covers setup, validation, services, accounts, and routine checks.
- Directory layout lists current FHS paths.
- Ports distinguishes public, private, and optional listeners.
- Protocols gives the supported protocol overview.
- Client compatibility describes realistic client expectations.
- Storage and backup explains where mail and metadata live.
- JMAP and the Store defines the future canonical object model, protocol mappings, and migration contract.
- Upstream Webmail integration defines the pinned Bulwark submodule, upstreamable patch queue, Bongo settings plugin and the minimum JMAP boundary required before the 0.8 Web replacement.
- Web PWA and Push staging separates the installable 0.8 Web application from the complete 0.9 JMAP/VAPID background-notification contract.
- Development covers CMake, tests, sanitizers, and timezone maintenance.
- Upstream mail-server test suites records which Dovecot, Cyrus, and Postfix tests can run against Bongo and which provide reference vectors only.
- Bongo 0.7.0 release test matrix is the mandatory three-pass gate before the 0.7.0 tag.
- Roadmap merges the useful historical 1.0 goals with the current 0.7 through 1.0 plan.
Security and mail operation
- Guided setup
- TLS policy
- Authentication, TOTP, LDAP, and app passwords
- SMTP, submission, LMTP, and trusted relay
- IMAP compatibility
- POP3 and POP3S
- Sieve filtering and ManageSieve
- Webmail and user administration
- CalDAV and CardDAV
- Queue, routing, and delivery
- Mail storage quotas
- SPF, DKIM, DMARC, and SRS
- SpamAssassin and ClamAV
- HAProxy PROXY protocol
- External account collection
Installed manual pages document individual commands and agents. Begin with
bongo-setup(1), bongo-config(1), bongo-admin(1), bongo-manager(1), and
bongoagents(8).
Historical material
The archived Bongo project documentation is a provenance source for the architecture and original 1.0 product goals. The current roadmap retains goals which are still useful, including virtual domains, calendar sharing, internationalisation, administration, diagnostics, and a formal security review.
Do not use the historical site as an installation manual. Its Autotools, Python 2/mod_python, managed LDAP, filesystem, browser, and SSL instructions are obsolete. The current implementation remains a C server with a Python 3 Web interface. Experimental Ruby rewrites are not part of the product or its roadmap.