Dovecot’s Built‑In Quota Plugin: Why, How, and When to Use It

Problem: Growing Mailboxes Without Limits

Many mail providers grow from a handful of users to thousands. Without a hard cap on mailbox size, a single user can fill the server’s storage, causing slow IMAP/POP3 responses, failed deliveries, or even downtime. A simple, reliable quota system is therefore essential.

Thesis: Dovecot’s Quota Plugin Is a Practical, Low‑Overhead Solution

Dovecot ships with a quota plugin that supports multiple backends (file‑based, SQL, LDAP) and can enforce both size and message‑count limits per mailbox or globally. It integrates transparently with existing IMAP/POP3 workflows, automatically rejecting new mail once a quota is hit. For most providers, this feature is the easiest way to guarantee storage limits without adding third‑party tools.

How the Quota Plugin Works

The plugin tracks usage in a lightweight SQLite database (or in a SQL table if you choose the SQL backend). On every message delivery, Dovecot queries the current usage and compares it against the configured limit. If the limit is exceeded, the delivery is aborted with a 552 5.3.4 Requested mail action aborted: exceeded storage allocation (or a similar error code). The check happens inside the delivery pipeline, so the user never receives the oversized message.

Choosing a Backend

• File‑based backend – Simple to set up; each user gets a quota file in their maildir. Good for small to medium deployments.
• SQL backend – Stores usage in a relational table. Recommended for large deployments where many quota checks occur; avoids the file‑system bottleneck.
• LDAP backend – Keeps quota attributes in LDAP entries. Useful if you already store user attributes in LDAP.

Basic Configuration

# /etc/dovecot/dovecot.conf

# Enable the quota plugin
plugin {
  quota = "/var/lib/dovecot/quota.sqlite"
  quota_rule = *:storage=1G
  quota_rule = *:messages=1000
}

# If you prefer SQL:
#plugin {
#  quota = sql:/etc/dovecot/dovecot-sql.conf.ext
#}

In the example above, every mailbox is limited to 1 GB of data and 1,000 messages. The wildcard * applies the rule to all users; you can replace it with a domain (e.g., example.com) or a user pattern.

Per‑User Overrides

To give a particular user a higher quota, add a line in userdb or passdb:

# /etc/dovecot/dovecot.conf
userdb {
  driver = passwd
  args = /etc/passwd
  # Override for alice@example.com
  user = alice@example.com
  quota_rule = storage=5G
}

After changing configuration, reload Dovecot: systemctl reload dovecot (root required).

Worked Example: Enforcing a 100 MB Quota for a Domain

1. Set up the file‑based backend. Ensure /var/lib/dovecot/quota.sqlite exists and is writable by the dovecot user.
2. Configure the domain rule. Edit dovecot.conf to include:

   plugin {
     quota_rule = example.com:storage=100M
   }
   

3. Reload Dovecot. sudo systemctl reload dovecot
4. Verify limits. Run:

   doveadm quota -u user@example.com
   

   Expect output showing 100M as the limit and current usage.
5. Test enforcement. Send a 90 MB attachment to user@example.com – delivery should succeed. Then send another 20 MB attachment – Dovecot should reject it with the 552 error.
6. Check logs. Look in /var/log/dovecot.log for entries like Quota limit exceeded to confirm the plugin triggered.

Trade‑Offs and Limitations

• Performance on high‑traffic boxes. Every message triggers a quota check. On servers with thousands of users, the file‑based backend can become a bottleneck. Switching to the SQL backend mitigates this by using indexed queries.
• Initial database creation. If you forget to create the quota database or give it wrong permissions, no quotas will be enforced and users may see unexpected delivery failures.
• Granularity. The plugin tracks size and message count but not other metrics (e.g., mailbox age). For more complex policies you may need a custom solution.

Actionable Next Steps

1. Decide on a backend based on your user count and existing infrastructure.
2. Add the plugin section to dovecot.conf and reload.
3. Use doveadm quota to audit current usage and limits.
4. Implement a monitoring script that watches /var/log/dovecot.log for quota failures and alerts admins.
5. Document the quota policy in your user handbook so recipients know when their mailbox will be full.

With these steps, you’ll have a robust, built‑in quota system that scales with your user base and protects your storage infrastructure.