bongo/docs/imap.md

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.

Relevant standards are RFC 9051, RFC 3501, RFC 5161, RFC 5198, and RFC 6855, and RFC 9208.