Files
bongo/docs/imap.md
T
Mario Fetka 5897512fd9 Modernize Bongo protocols and administration
Complete the current IMAP, POP3, SMTP and proxy protocol work; add the validated setup and administration UI, packaging examples, tests, and maintained roadmap/documentation for the 0.7 development line.
2026-07-18 04:26:00 +02:00

2.5 KiB

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 Cyrus SASL mechanisms which Bongo has actually enabled. Password mechanisms are advertised only on a TLS connection; unencrypted connections offer STARTTLS and keep LOGIN disabled.

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