Mario Fetka
58 lines
3.3 KiB
Markdown
58 lines
3.3 KiB
Markdown
# 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).
|