[Dovecot] Filesystem Quota Enhancement Patch

[Scott Alter]

> 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 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):
> 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, 
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.

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:
> 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 
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