Quota.

[Rob Siemborski]

On Fri, 20 Jun 2003, John Wade wrote:

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

It actually winds up not beeing that efficient.  A "real" solution would
name a specific standard name for a trash folder (like INBOX is for
incoming mail).  There are political reasons that make this difficult.

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

Ok, that should be fine then (though, I'm still wary of disabling quotas
at all).

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

Ok, so maybe it makes sense to change the message to "over quota in
quotaroot x."  This is definately a reasonable change.

> No real gain in user satisfaction although experienced users may try to
> empty the trash and thus resolve the problem on their own.

By this reasoning, if a person gets an "I'm over quota message" in the
your system, they start to move messages to their trash folder.  They
don't get any warnings when copying the messages, but since they never
expunge the trash folder, they are still over quota, and left wondering
why their mail is never delivered.

Is this really preferable?

Certainly, the trash having its own quota root makes the situation
resolvable by the user within the means of their client (as opposed to
forcing them to use a client which uses the traditional delete/expunge
model to remedy the situation), which seems like an improvement.

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

Personally, that seems like a pretty gross security violiation, even if
you limit the number of folders someone can write to.  Maybe you want to
say "copying within a quota root doesn't check the quota".

I'll file a bug on amending the quota warnings to include the mailbox name
(of course, this only helps if they ever select the mailbox).

-Rob

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