Rob Siemborski rjs3 at andrew.cmu.edu
Fri Jun 20 10:03:26 EDT 2003

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

>  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 enfore 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.

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


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

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.


Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper

More information about the Info-cyrus mailing list