Subject: QUOTA extension on imapd

From: "Daniel Fritzler" <[email-masked]>
Date: Thu, 1 Nov 2001 13:56:22 -0300

Hi there,

I'm developing a mail client that supports the IMAP4 QUOTA extension
(RFC2087), but while I was testing my client with imapd, I found out
that it does not support this extension.

Is someone working on a RFC2087 implementation for imapd?

I don't need imapd to maintain the quota, just storing the quota value
and reporting mailbox disk usage will be enough for me.

Thank you very much.

Daniel Fritzler

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Thu, 1 Nov 2001 09:26:04 -0800 (PST)

It is difficult to implement the QUOTA extension in a meaningful way in imapd.
Since imapd uses the underlying UNIX filesystem, this means that quotas also
come from the UNIX filesystem.

In most UNIX systems quotas are per-user instead of per-directory or per-file.
The QUOTA extension, on the other hand, assumes that quotas are associated
with a particular level of hierarchy.  What this means is that UNIX quotas
can't be expressed well as QUOTA extension quotas and vice versa.

An additional problem is that setting quotas is a privileged operation on most
UNIX systems, so that part of the QUOTA extension isn't implementable either.

Last but not least, there is no common standard for quotas on UNIX.  Different
UNIX systems have different incompatible system calls to access and manipulate
quotas.

The bottom line is that any attempt to implement the QUOTA extension in imapd
would result in only the smallest subset, which will report quotas that aren't
particularly meaningful and will change continually in ways that an IMAP
client would have no way of understanding (because quotas aren't allocated the
way the QUOTA extension discusses).

The underlying problem is that, unfortunately, both the ACL and the QUOTA
extensions were designed with the AFS data store model in mind, and with
inadequate effort to ensure general applicability with other data stores.
Fixing the design of these extensions is going to take a lot of work.  Fixing
ACL has already consumed years of effort without any resolution in sight, and
that seems to be of higher priority that QUOTA.

---

From: "Daniel Fritzler" <[email-masked]>
Date: Thu, 1 Nov 2001 18:09:07 -0300

Hi Mark,

Thank you for your prompt reply.

What do you think about imapd handling quotas internally without relying
on the filesystem quotas?
For instance, imapd could maintain internal quota tables and check the
disk usage before allowing an APPEND or COPY. Also, a patch for procmail
(or other MDA) could be created that implements the quota also reading
imapd's internal quota tables.

What I have in mind is to implement a file called ~/.quotas storing
something like:

#Qroot  Resource Units_allowed Units_used
""  STORAGE    10   1
""  MESSAGES  5     3

Thanks,
Daniel

> -----Original Message-----
> From: Mark Crispin [mailto:[email-masked]] On 
> Behalf Of Mark Crispin
> Sent: Thursday, November 01, 2001 2:26 PM
> To: Daniel Fritzler
> Cc: [email-masked]
> Subject: re: QUOTA extension on imapd
> 
> 
> It is difficult to implement the QUOTA extension in a 
> meaningful way in imapd. Since imapd uses the underlying UNIX 
> filesystem, this means that quotas also come from the UNIX filesystem.
> 
> In most UNIX systems quotas are per-user instead of 
> per-directory or per-file. The QUOTA extension, on the other 
> hand, assumes that quotas are associated with a particular 
> level of hierarchy.  What this means is that UNIX quotas 
> An additional problem is that setting quotas is a privileged 
> operation on most UNIX systems, so that part of the QUOTA 
> extension isn't implementable either.
> 
> Last but not least, there is no common standard for quotas on 
> UNIX.  Different UNIX systems have different incompatible 
> system calls to access and manipulate quotas.
> 
> The bottom line is that any attempt to implement the QUOTA 
> extension in imapd would result in only the smallest subset, 
> which will report quotas that aren't particularly meaningful 
> and will change continually in ways that an IMAP client would 
> have no way of understanding (because quotas aren't allocated 
> the way the QUOTA extension discusses).
> 
> The underlying problem is that, unfortunately, both the ACL 
> and the QUOTA extensions were designed with the AFS data 
> store model in mind, and with inadequate effort to ensure 
> general applicability with other data stores. Fixing the 
> design of these extensions is going to take a lot of work.  
> Fixing ACL has already consumed years of effort without any 
> resolution in sight, and that seems to be of higher priority 
> that QUOTA.
> 
>

---

From: Mark Crispin <[email-masked]>
Date: Thu, 1 Nov 2001 14:41:19 -0800 (PST)

> on the filesystem quotas?

That's a good question.

One of UW imapd's target platforms are systems which allows shell access.  In
fact, UW imapd is probably the only IMAP server which is suitable for such a
system.  Any internal handling of quotas by UW imapd is meaningless in such a
system.

I am very reluctant to commit UW imapd to an IMAP-only server design, given
that all the other IMAP servers out there are in that business.  The primary
business of UW imapd is the business of "play ball with your UNIX system".