Mario Fetka
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 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.
Relevant standards are RFC 9051, RFC 3501, RFC 5161, RFC 5198, and RFC 6855.