81 lines
3.5 KiB
Markdown
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).
|