# IMAP compatibility and international mail

Bongo 0.7 advertises `IMAP4rev2`, `IMAP4rev1`, and the original `IMAP4`
capability. The compatibility capabilities are intentional: clients which do
not understand rev2 can continue to use the older command and mailbox-name
rules. Existing modified UTF-7 mailbox names therefore remain supported until
the client explicitly enables UTF-8.

The server also advertises the extensions it implements, including `ENABLE`,
`ID`, `IDLE`, `NAMESPACE`, `UIDPLUS`, `MOVE`, `SPECIAL-USE`,
`CREATE-SPECIAL-USE`, `LIST-EXTENDED`, `LIST-STATUS`, `STATUS=SIZE`,
`LITERAL+`, `APPENDLIMIT`, and `UTF8=ACCEPT`. Capability tests keep this list
in step with the command handlers; an extension must not be advertised merely
because a client might expect it.

Modern clients can issue `ENABLE UTF8=ACCEPT` in the authenticated state.
After that command Bongo accepts normalized UTF-8 mailbox names and UTF-8 in
quoted strings, returns UTF-8 mailbox names from LIST, LSUB and STATUS, and
rejects malformed UTF-8. Control, delete, line-separator and
paragraph-separator code points are forbidden in mailbox names. SEARCH with
an explicit CHARSET is rejected after UTF-8 has been enabled, as required by
the extension.

Internationalized messages are appended with the RFC 6855 `UTF8 (~{size})`
data form. Bongo buffers at most the advertised `APPENDLIMIT`, validates the
header before committing the message to the store, and rejects malformed
UTF-8. A normal APPEND containing an eight-bit header receives `NO [CANNOT]`;
the UTF8 data form is accepted only after `ENABLE UTF8=ACCEPT`.

A legacy client never receives raw internationalized header fields in an
IMAP response. Safe metadata such as UID, flags, internal date and message
size remains available. A request that would expose a UTF-8 header receives
`NO [CANNOT]` with an instruction to enable UTF-8. This explicit policy avoids
silently corrupting addresses or invalidating DKIM signatures through an
ad-hoc downgrade.

AUTH capabilities are generated from the GNU GSASL mechanisms which Bongo
has actually enabled. Password mechanisms are advertised only on a TLS
connection; unencrypted connections offer STARTTLS and keep LOGIN disabled.
STARTTLS rejects arguments and repeated or post-authentication use, discards
already buffered cleartext before the TLS handshake, and closes the connection
without attempting a plaintext IMAP response if negotiation fails. A client
which ignores `LOGINDISABLED` receives a tagged `NO` without a password lookup.

The RFC 9208 `QUOTA` extension reports the authenticated user's optional
mail-storage limit through `GETQUOTA` and `GETQUOTAROOT`. Bongo advertises
`QUOTA=RES-STORAGE`, supports `DELETED-STORAGE`, and returns `[OVERQUOTA]` for
APPEND, COPY, or MOVE growth rejected by the Store. It intentionally does not
advertise `QUOTASET`; limits are administered with `bongo-admin user quota`.
See [Mail storage quotas](quotas.md).

Relevant standards are [RFC 9051](https://www.rfc-editor.org/rfc/rfc9051.html),
[RFC 3501](https://www.rfc-editor.org/rfc/rfc3501.html),
[RFC 5161](https://www.rfc-editor.org/rfc/rfc5161.html),
[RFC 5198](https://www.rfc-editor.org/rfc/rfc5198.html), and
[RFC 6855](https://www.rfc-editor.org/rfc/rfc6855.html), and
[RFC 9208](https://www.rfc-editor.org/rfc/rfc9208.html).