Quota.

[John Wade]

Hi Rob,

Thanks for replying,  you folks at Carnegie Mellon have created a fantastic
tool and we certainly appreciate your work and dedication.

Rob Siemborski wrote:

> On Fri, 20 Jun 2003, John Wade wrote:
>
> > I was thinking about this yesterday as I worked with our help desk folks
> > to mollify another angry user who could not figure out how to manage
> > their mailbox and ended up over quota.   While I agree with the design
> > of Cyrus in principle (delete in place and expunge), in practice, there
> > are enough mail clients that use the "move to trash" model and an
> > expectation in the user community that this is how computers work (based
> > on the delete model in both the Windows and Macintosh worlds) that I
> > think I need to figure out a way to accomodate them.
>
> There are ways to implement a trash folder within the delete/expunge
> model.  (Through a virtual folder, for example).  This is much better for
> interoperability between clients, and has been discussed to death on IETF
> lists.
>

Sounds appealing as a future direction.

>
> >  When we upgrade our Cyrus version to 2.1.x or 2.2 later this summer,
> > (curently on 2.0.16) I was planning to see if I could put a patch
> > together to have COPY not enforce quotas.   Or maybe for the really
> > paranoid, not enforce quotas if the destination mailbox is
> > user.<username>.Trash )     This would seem to solve most of the "move
> > to trash" delete quota problems.  While I could see ways that this could
> > lead to abuse of the mail server,  I think for the vast majority of
> >  users, the shutdown of delivery of new messages woul be sufficient
> > incentive to fix the over quota status and the risk of abuse is
> > relatively small/
>
> Since the IMAP Server has no concept of a trash mailbox, this doesn't make
> any sense.
>

After thinking about this further, I would not special case the Trash
mailbox,  I would simply remove the requirement that a  COPY command check the
quota before copying a message from one mailbox to another.   The quota check
would still occur on deliver or on append, just not on copy.    This means
that no new messages can enter the inbox from the client or MTA.  The only
danger is from messages copied from a mailbox with a different quota root, but
the users will continue to receive over quota alerts and no new message until
they go back under quota.

>
> > Does anyone have any thoughts on this idea?  Is this a really bad idea?
>
> Yes.

Point taken :-)

>
>
> > Any tips on where in the code to look?  I spent a few minutes looking at
> > imapd.c, index.c and append.c in 2.0.16 and I am guessing that if I
> > change the quotacheck argument to -1 in the append_setup call in
> > index_copy it will bypass the quota check on copy.   Have not actually
> > tried this yet.
>
> I suspect a simple implementation that just does this will break the quota
> subsystem.  (You also need to be sure to not affect quota roots when you
> expunge the trash folder, etc)
>

I just tried this fix in 2.0.16 and it appears to work properly.  The "ignore
quota" option is already in place on append_setup to allow the lmtpd to
deliver to overquota mailboxes, I am just extending this to work with imapd
copy command execution.  None of this interferes with the recording of quotas
when the message is actually copied.

The behavior I  see with the patch in place is that when I first login to an
overquota mailbox, the client receives the "Over Quota"  IMAP alert.   (I
modified the error message to suggest that the user delete messages and/or
empty the trash.)      The client can still copy files from one mailbox to
another, including moving to trash and then trigger a delete/expunge to empty
the trash.    The client can not copy messages from the local mail to the imap
server or append new messages into a Sent folder.    Mail delivery is deferred
in the MTA until the overquota condition is rectified.

> If you really care about trying to support this sort of behavior, why not
> set a separate quotaroot on user.foo.trash?  This doesn't require the
> server to have special handling of random user mailboxes, and has less
> questions from a server implementation perspective.

This was my first thought a year ago and I played with it extensively.   ( I
hate to hack a beautiful system like Cyrus without good reason)  The problem
with the separate quota root on the trash mailbox is that many novice users
don't know about the need to empty (delete/expunge) the Trash mailbox.   As a
result, they are happily moving messages to trash and then they start getting
a quota warning message from the Trash mailbox.    Since the IMAP alert does
not specify the mailbox that the quota warning applies to, the user assumes
that it is the inbox and continues to try and delete messages until they go
over quota on trash,  at that point, they call the help desk since they can no
longer delete messages.    No real gain in user satisfaction although
experienced users may try to empty the trash and thus resolve the problem on
their own.

I don't think my fix should be a standard part of Cyrus, but for those of us
who want to support clients with move to trash biases, it seems like it could
be a helpful patch.  I don't really see the downside for us except the
vulnerabilty to malicious users copying messages from other mailboxes outside
of their own quota root to use up all of our disk space.

Thanks,
John