Quota Configuration

This configuration applies only to Spring wiring.

Consult quota.xml in GIT to get some examples and hints.

Use this configuration to define the type of quota storage used to persist the quotas.

This allow you to configure the behaviour of your James server in regard of the RFC 2087 Quotas.

RFC 2087 introduces Quotas. A quota is related to a resource. In James, resources are MESSAGE (message count) and STORAGE (size occupied by the messages in bytes). A quota is composed of two values. The first one is the maximum value related to the value. The second one is the current value of the resource. Quota are handled for a Quota Root, a (potentially configurable group of mailboxes.

The goal of RFC-2087 and related James implementation is to forbid users to exceed a given value for available resources.

James' implementation is split in different components, and each one of them gets its own responsibility:

  • Quota Root Resolver: This component is responsible of the correspondence between mailboxes and QUOTA ROOT. A default implementation is available and simply group mailboxes in QUOTA ROOT on the base of the owner name.
  • Quota Manager: This component retrieves quota associated with a QUOTA ROOT. A store implementation is available and relies on other components. A fake implementation is available in order to add no overhead.
  • Max Quota Manager: This component retrieves maximum values associated with quotas and gives a way to potentially (depending on the implementation) update these per QUOTA ROOT maximum values. Four implementations are available for now. A NoQuotaManager implementation is read only and returns UNLIMITED maximum values. FixedMaxQuotaManager returns one and only one value for all user. You can configure these maximum values threw the configuration files. A InMemoryPerUserMaxQuotaManager allows you to configure quota for each QUOTA ROOT. Note that it needs to be done threw configuration to be persistent. We provide some other implementation: A JPA implementation allows to store maximum quota values in a SQL database.
  • Current Quota Manager: This component can be omitted if you are running a fake QUOTA manager. inmemory implementation is an event updated cache on top of a Quota calculator (that fetches every e-mail metadata of every mailboxes belonging to the QUOTA ROOT: it is expensive). Jpa implementation is also available.
  • Quota Updater: This components allows to update current quota values. A fake implementation is available. A real, event base solution also exists.

To choose the implementation you want for the given components you want simply have a look to the quota.xml file.

Quota integration consists of:

  • Checks in the message manager. An operation that will bring the QUOTA ROOT over quota will be dropped. APPEND and COPY operations are concerned.
  • A matcher is available (IsOverQuota) to better respond to client sending e-mail via SMTP to an over quota mailbox (and prevent the e-mail from being stored in MailRepositories). This matcher just performs a call to the Quota Manager, and is efficient.
  • A user can consult his Quotas using RFC 2087 IMAP commands. Note that SETQUOTA command is disabled. No quota configuration can be done threw IMAP.
  • CLI authorises an admin to consult and manage ones quotas.

The administration of QUOTAs can be done:

  • Threw configuration file. Note that this is required to persist a change made to the inmemory or fixed Max Quota Manager. It needs a James reboot to take effect. Finally, using configuration file for setting maximum quota values will override CLI set values. Avoid this option this persistent Max Quota Manager (for instance JPA)
  • Threw the CLI: offers immediate configuration changes on quota maximum values. Note that if you are using either a fixed or inmemory Max QUota Manager, your changes need to be done to the XML configuration to be persisted.