Could not complete request over quota errors
Marc Groot Koerkamp
marc at its-projects.nl
Wed Jul 30 20:43:09 EDT 2003
Andrew Morgan said:
> On Wed, 30 Jul 2003, Marc Groot Koerkamp wrote:
>> Andre Nicholson said:
>> > I run into this problem **all of the time** with my users. What's
>> > happening, if you use
>> > a Trash folder, is that the message is first /copied/ to the Trash
>> > and then if
>> > successful the original message is deleted. Why isn't it just moved??
>> > it SquirrelMail
>> > or Cyrus that's the cause?
>> It's IMAP. RFC 3501 does not support the move command so we have to copy
>> the message. Of course we could fake it by doing client side move which
>> means buffer the message in mem or temporarely write it do file, delete,
>> expunge, and append the message in our buffer to the Trash folder but
>> that sounds not save to me.
>> Cyrus supports the quota extension so maybe we can in the future check
>> quota before we move messages to trash and do some proper error handling
>> but don't excpect it on short notice. In the future SM 2 version we also
>> have ALERT information and probably we should display it to the user
>> because the ALERT message regarding QUOTA will be present when 90 % of
>> quota is exceeded (if I'm correct).
>> Ideal situation would be that the QUOTA extension is rewritten in order
>> set individual QUOTA on children mailboxes of QUOTAROOT so you can set
>> INBOX.Trash QUOTA to unlimited and still have QUOTA enabled on INBOX and
>> the other children mailboxes. But that's not part of RFC 2087. Maybe a
>> nice job for cyrus to come with a new RFC for this :)
> So why not just set a really large quota on the Trash folder? You could
> do something like:
> setquota user.testuser STORAGE 102400
> setquota user.testuser.Trash STORAGE 1024000
> That would give the user a 100MB quota for normal mail and a 1GB quota for
> their Trash folder.
> Or am I missing something? :)
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)
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.
More information about the Info-cyrus