Could not complete request over quota errors

[John Wade]

The solution I came up with was to hack cyrus to use the ignore quota mechanism
(normally used by lmtpd) when copying to INBOX.Trash.    (Just a couple of
lines of code see the diff below)  I know Rob doesn't like this solution and it
is a security risk, since a malicious user could fill up a Trash mailbox until
disk space is exhausted.  It does seem like a better solution than putting an
infinite quota on quota root INBOX.Trash, since my fix prevents mail delivery
when over quota, but still allows users to copy to Trash.   We have been using
this for a while and it is working well for us.

To quote from my previous message to the list:
--------------------------------------------------------------------------------------

For my own personal quota problems, I finally gave up and against Rob's better
judgement,  I removed the quota enforcement on COPY to any mailbox whose name
contains ".Trash".   I put a separate cron script in place to email me if it
finds
any users who are at more than 200% of there quota to catch any malicious
users.
This seems to be working well so far, although it is a kluge with security
risks.

diff index.c index.c.org
1220,1228c1220
< /* next lines changed to allow copy to Trash when usr over quota */
< /* jwidera jwade 6/27/03 lets users "move to Trash" when over quota */
<
<     if ( strstr(name,".Trash") ) {
<        r = append_setup(&append_mailbox, name, MAILBOX_FORMAT_NORMAL,
<                    imapd_userid, imapd_authstate, ACL_INSERT, -1);
<     }
<     else {
<        r = append_setup(&append_mailbox, name, MAILBOX_FORMAT_NORMAL,
---
>     r = append_setup(&append_mailbox, name, MAILBOX_FORMAT_NORMAL,
1230d1221
<     }
-------------------------------------------------------------------
Use it or disregard as you see fit.

Enjoy,
John


Marc Groot Koerkamp wrote:

> Rob Siemborski said:
> > On Thu, 31 Jul 2003, Marc Groot Koerkamp wrote:
> >
> >> What happens when I create a sub of inbox. What quota does apply to that
> >> sub or does the sub has no quota?
> >>
> >> according the rfc:
> >>    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.
> >>
> >> that make me think that INBOX and INBOX.Trash share the same named quota
> >> and therefor raising the quota on inbox.Trash doesn't help. (I could be
> >> wrong, I never used quotas)
> >
> > No, some implementations might inheret, others might override (that is, a
> > new quota root would override all previous roots).  Cyrus does the later.
> >
>
> Ok thnx for the clarification. I'll start experimenting with it.
>
> >> But to come back to the QUOTA idea. It's probably not a good idea. Much
> >> better would be to write an RFC for IMAP MOVE. But that's discussed
> >> before
> >> if I'm correct.
> >
> > IMAP MOVE is very difficult in IMAP for a variety of reasons.  One is
> > transactionality,  One is preservation of UIDs (which is important if you
> > want to undo a move).
> >
> > Here's a previous thread:
> >
> > http://www.washington.edu/imap/listarch/current/msg00629.html
> >
>
> OK, I forget the move idea. So we are back to where we started. The client
> should notify the user that it needs to empty Trash first or offer
> permanent delete by setting the flag and expunge the individual message by
> using it's uid (in case of UIDPLUS)
>
> Regards,
>
> Marc Groot Koerkamp.