Files
bongo/docs/quotas.md
T
2026-07-23 21:12:30 +02:00

81 lines
3.5 KiB
Markdown

# Mail storage quotas
Bongo applies one optional mail-storage quota to each user Store. The limit
covers message objects in all of that user's mailboxes. Contacts, calendars,
configuration documents, authentication databases, Queue files, and Web state
are not charged to the mail quota.
The configured limit and current logical message size are stored in the same
per-user SQLite database as the mailbox metadata. SQLite triggers perform the
final check atomically, so concurrent SMTP delivery, IMAP APPEND, COPY, MOVE,
and Store writes cannot jointly cross a hard limit. A zero internal limit means
that no administrative quota root exists and is displayed as `unlimited` by
the administration tool.
## Administration
Show a user's usage and limit:
```console
bongo-admin user quota alice
```
Set a limit using bytes or a binary size suffix:
```console
bongo-admin user quota alice 10G
```
Remove the administrative limit:
```console
bongo-admin user quota alice unlimited
```
Accepted suffixes are `K`, `M`, `G`, `T`, and `P`, optionally followed by
`iB` or `B`. Lowering the limit below current usage is permitted, but every
operation which would increase charged storage remains rejected until enough
mail has been removed or the limit has been raised.
## Protocol behaviour
IMAP advertises `QUOTA` and `QUOTA=RES-STORAGE` and implements the RFC 9208
`GETQUOTA`, `GETQUOTAROOT`, `DELETED-STORAGE`, and `[OVERQUOTA]` responses.
The single quota root is the empty string and governs every mailbox in the
authenticated user's Store. Bongo does not advertise `QUOTASET`; only a local
administrator can change a limit. IMAP reports STORAGE in units of 1024
octets, while `bongo-admin` reports exact logical bytes.
POP3 has no standardized quota query command, and Cyrus POP3 follows the same
model. Bongo therefore does not invent a POP3 capability. POP3 accesses the
same quota-controlled Store: `DELE` only marks a message during the session,
`RSET` cancels those marks, and a successful `QUIT` performs the Store deletes
which release quota. A disconnected or failed POP3 update transaction releases
no quota.
Local SMTP/Queue delivery receives the Store's quota result and handles it as
the existing quota-exceeded delivery status. Normal SMTP delivery returns the
standard `5.2.2` mailbox-full status. Mail already owned by Queue after an
external POP3 or IMAP collection remains queued and is retried instead: only
complete messages which fit are delivered, while the remaining complete
messages wait until the user frees enough quota. Deleting mail through IMAP,
POP3, or the Web interface therefore affects one shared usage value.
The accounting value is the sum of stored logical message sizes. It is not a
filesystem free-space promise: filesystem allocation, metadata, SQLite files,
hard links, compression, snapshots, and Queue space can differ. Normal disk
space monitoring and Queue reserve settings remain necessary.
## Backup and restore
The portable `bongo-storetool store-backup` archive contains Store objects,
payloads and their portable metadata. Restoring it rebuilds the charged usage
from the restored mail sizes while preserving the target account's existing
administrative quota. A mailbox owner therefore cannot replace a limit by
restoring a user-controlled archive. Include the per-user Store database in a
complete server backup when the configured administrative limit itself must
be recovered.
Relevant standards are [RFC 9208](https://www.rfc-editor.org/rfc/rfc9208.html)
and [RFC 1939](https://www.rfc-editor.org/rfc/rfc1939.html).