# Protocol overview

Bongo keeps compatibility with older standards where that can be done without
weakening the default policy, while advertising modern extensions only when
their handlers and tests are present.

## Mail transport

The SMTP server supports classic SMTP and ESMTP with `SIZE`, `PIPELINING`,
`8BITMIME`, DSN, `CHUNKING`/bounded `BDAT`, optional `SMTPUTF8`, STARTTLS,
SASL authentication, and `REQUIRETLS` on TLS-capable listeners. `BINARYMIME`
is deliberately not advertised or accepted. Authenticated submission and
implicit TLS use listener-specific policy; Internet delivery uses
opportunistic STARTTLS unless REQUIRETLS, DNSSEC-authenticated DANE, or an
RFC 8461 MTA-STS destination policy requires authenticated TLS.

LMTP transports are available for local downstream services such as Mailman.
Trusted SMTP/LMTP peers can receive original-client metadata through
negotiated `XCLIENT` or `XFORWARD`, or through explicitly configured fallback
headers. Incoming HAProxy PROXY v1/v2 is a separate, source-restricted
connection feature.

See [smtp.md](smtp.md), [tls.md](tls.md), and
[mail-authentication.md](mail-authentication.md).

## Mail access

IMAP advertises `IMAP4rev2`, `IMAP4rev1`, and legacy `IMAP4`, plus the
implemented capabilities documented in [imap.md](imap.md). This preserves
basic access for old clients while allowing modern UTF-8 mailbox and message
handling after `ENABLE UTF8=ACCEPT`.

POP3 implements the normal transaction commands and advertises `TOP`,
`RESP-CODES`, `AUTH-RESP-CODE`, `PIPELINING`, `EXPIRE NEVER`, `UIDL`, and
`UTF8`. STLS is offered before authentication; SASL and password login are
advertised only according to the TLS policy. POP3S provides implicit TLS.
After a successful `UTF8` command, `STLS` is no longer advertised and is
rejected so that the negotiated UTF-8 session state cannot cross into TLS.
Both IMAP STARTTLS and POP3 STLS discard buffered cleartext before negotiating
TLS.

Mail-storage limits are enforced by the shared Store for SMTP delivery, IMAP,
POP3, Web access, and external collection. IMAP exposes RFC 9208 quota queries;
POP3 has no standardized quota command and releases charged storage only when
its `QUIT` update transaction successfully commits marked deletions. See
[POP3 and POP3S](pop3.md) and [Mail storage quotas](quotas.md).

## Server-side filtering

ManageSieve uses TCP 4190 and implements the RFC 5804 management commands,
including script upload, activation, listing, retrieval, rename, deletion,
space checks, and syntax checks. The Sieve engine reports `fileinto`,
`envelope`, `body`, `variables`, `vacation`, and `vacation-seconds` support.
Authentication mechanisms are obtained from the shared GNU GSASL policy and
are offered after TLS.

Thunderbird and other ManageSieve clients can update the active script
without depending on the Web interface. Later interfaces, including a future
JMAP implementation, must operate on the same user filter model rather than
inventing incompatible rules.

See [Sieve filtering and ManageSieve](sieve.md) for listener, command,
storage, and vacation behaviour.

## Web, calendars, and contacts

The Python 3 Web service provides Webmail and user settings. CalDAV exposes
calendars using iCalendar data, and CardDAV exposes address books using vCard
data. External HTTPS is normally supplied by a reverse proxy; the Bongo Web
listener itself defaults to HTTP on loopback.

See [Webmail and user administration](web.md) and
[CalDAV and CardDAV](dav.md) for the current 0.7 interfaces.

JMAP and Exchange/MAPI protocols are not part of Bongo 0.7. JMAP is planned
for 0.9 after the mail protocols and Store API are stable. Native
Exchange/Outlook compatibility remains research beyond that milestone.

## Private Bongo protocols

The Store and Queue protocols coordinate local Bongo agents. They are not
public client protocols and have no Internet compatibility promise. Bind them
to a private interface and firewall ports 689 and 8670 from clients.
Queue durability and retry policy are described in
[Queue, routing, and delivery](queue.md).

## Authentication and message security

Mail protocols share GNU GSASL and the same Bongo account/app-password
policy. Password mechanisms are not exposed on an unencrypted connection.
Optional TOTP protects the master login; app passwords keep non-interactive
clients usable. SPF, DKIM, and DMARC authenticate incoming domain claims;
outgoing DKIM and SRS cover signing and forwarding. None of these replaces TLS
or user authentication.