Mario Fetka
3.5 KiB
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:
bongo-admin user quota alice
Set a limit using bytes or a binary size suffix:
bongo-admin user quota alice 10G
Remove the administrative limit:
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.