I guess for v1.0 that's fine, but do you think for CVS HEAD this could be done using two quotaroots? Do clients even understand more than one quota root?

There are a few considerations that need to be made regarding support for multiple quotaroots. I believe that this will require the modification of the imap_quota plugin first in order to accommodate a mapping between namespaces and quotaroots (more below). I've been reading over RFC 2087 (IMAP4 QUOTA extension), and have a few considerations and possibilities. I do not know if there are any clients that support multiple quotaroots, but that doesn't mean Dovecot shouldn't be standards compliant. If I have time, I will attempt to hack Dovecot to return multiple quotaroots and see how Thunderbird responds.

I first want to call to your attention the presence of a draft of a new RFC which has long expired - http://www.melnikov.ca/mel/Drafts/draft-cridland-imap-quota-00.txt. It would have addressed all of these issues, but I guess it never caught on. Since we're stuck with RFC 2087, here are my thoughts.

The [quota root] is followed by a S-expression format list of the resource usage and limits of the quota root. The list contains zero or more triplets. Each triplet conatins a resource name, the current usage of the resource, and the resource limit. If I interpreted this RFC correctly, there could theoretically be multiple storage and message resource limits for each quotaroot. So,

The first possibility is to have only one quotaroot for each namespace and return multiple of the same resources for the quota. Since both the user and group quotas apply to the same quotaroot, they theoretically could both be returned. From the RFC (5.1 QUOTA Response): there could be a response like: "* QUOTA "" (STORAGE 10 512 STORAGE 123 6000 STORAGE 45 50 MESSAGE 5 20)". This could be used to show both user and group quotas in 1 quotaroot, plus additional quota information coming from different sources (fs, dict, maildir, dirsize) all in one quotaroot. The downside is that there is no differentiation between which quota comes from where (user vs. group & fs vs dict vs maildir vs dirsize). Also, this might not be what the author of the RFC had in mind, and it may never be supported by any clients.

Each mailbox has zero or more implementation-defined named "quota roots". Each quota root has zero or more resource limits. All mailboxes that share the same named quota root share the resource limits of the quota root. This is pretty ambiguous. A problem with the current specifications is

Assuming that we cannot proceed with multiple of the same resources, we need to define what exactly a quotaroot is. The RFC (3 Introduction and Overview) says: that there is no mapping between mailboxes and quotaroots. I assume that currently, it works by equating one quotaroot to each namespace with the quotaroot named for the namespace. I know that Dovecot does not yet fully support this even, but if this is the case, to support multiple quotaroots in a namespace, we would need to define the quotaroots for each namespace in the Dovecot config file. Otherwise, there is no way to support multiple quotaroots for any namespace.

Once quotaroots are named, it is then necessary to define the limits of the quotaroot and where to get the quota from (fs, maildir, dict, dirsize). This could be done also in each namespace section, or it could be kept in the plugin section. This can get complicated because ideally, you would be able to specify the name of the quotaroot, the backend, and which resource to use. This is also true of filesystem quotas, since we want the user and group quotas to be in different quotaroots. Also, some quotaroots may be used in multiple namespaces (such as multiple namespaces on a single filesystem). For example:

namespace private { prefix = location = maildir:~/Maildir quotaroots = userroot grouproot } namespace private { prefix = "#moremail/"
location = maildir:~/mail quotaroot = moremailroot userroot grouproot } plugin { quota = userroot:fs:storage=user:messages=user grouproot:fs:storage=group:messages=group moremailroot:maildir:storage=10240 }

I do not think it would be possible to have a maildir or dirsize backends span multiple namespaces. For filesystem-based quotas, assuming that a namespace is only on one filesystem (does not span across multiple partitions), it could span partitions.

To begin to tackle this big change, I would recommend first adding a quotaroots variable to the config file. Then, use this quotaroot to look up where to get the quota from rather than just taking it blindly from the plugins section regardless of the namespace. After this, the dirsize, dict, and maildir quota plugins should with with little modification. The fs quota plugin will require a little modification, as the resources are not currently passed from the conf file to the plugin.

On the other hand for the filesystem quotas, you could make the configuration like "quota = quotaroot:fs:source=user" or "quota = quotaroot:fs:source=group", and just pass the source to the plugin. The storage and messages would both always be returned, because if they are present on the filesystem, they exist and do not need to be hidden.

Another (possibly more difficult) option for filesystem-based quotas is to leave the config file like "quota = quotaroot:fs" and have the quota-fs backend return 2 quotaroots automatically if there are both user and group quotas (and rename the quotaroot to quotaroot-user and quotaroot-group).

These are my suggestions. I'm not sure what the major changes are to the CVS HEAD branch, but I think there needs to be a way to map quotaroots to namespaces. To answer your question, the filesystem quota backend probably could return 2 quotaroots without too much modification, but it would be a hack...and I wouldn't want the next version of Dovecot to start off with some hacks to get the job done!

-Scott