Bug 173880 - Cyrus give client invalid over quota error under certain circumstances
Summary: Cyrus give client invalid over quota error under certain circumstances
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: cyrus-imapd
Version: 4.0
Hardware: i386
OS: Linux
Target Milestone: ---
: ---
Assignee: Petr Rockai
QA Contact: Brian Brock
Depends On:
Blocks: 176344
TreeView+ depends on / blocked
Reported: 2005-11-22 02:44 UTC by Gary W. Smith
Modified: 2007-11-30 22:07 UTC (History)
6 users (show)

Clone Of:
Last Closed: 2007-05-01 17:15:25 UTC

Attachments (Terms of Use)
Modifies 3 files to help out with the quota patch (4.07 KB, patch)
2005-11-22 09:08 UTC, Gary W. Smith
no flags Details | Diff
patch to fix overflow quota on cyrus-imapd-2.2.12-3gral / cyrus-imapd-2.2.12-3.RHEL4.1 (23.95 KB, patch)
2006-06-30 07:37 UTC, jean-sebastien Hubert
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0258 normal SHIPPED_LIVE cyrus-imapd bug fix update 2007-05-01 17:14:55 UTC

Description Gary W. Smith 2005-11-22 02:44:01 UTC
Description of problem:
When the quota is set for 2,000,000 (which ends up being 2gb) there is no 
error.  Setting the quota to 5,000,000 (or 5gb) the clients receive an over 
quota error and all delivery stops.  Setting it to 7,000,000 (or 7gb) seems to 
cure the problem.  There seems to be some problem witht he math being used in 
the original quota patch.

Version-Release number of selected component (if applicable): cyrus-imapd-

How reproducible: Every time

Steps to Reproduce:
1. create an email account with a 2gb quota and fill it 90%
2. set quota to 5gb
3. test with Outlook or Horde web based client (or any client that is imap 
quota compliant).
Actual results:
Client received over quota message.  Verified quota user of 36%.  Mail was 
returned for being over quota.

I reverted the quota settings back and then played with them for a little 
while to find out that the error was based in blocks.

Expected results:
Client should not have been presented with any quota message.

Additional info:

I verfied this with outlook express and horde web based client.  Both clients 
support imap quota reporting.  Both clients supported the results printed 

Problem was first reported by a user that was getting over quota limits on an 
account with 1.8gb.  We had recently updated the account to allow for 5gb of 
mail.  We verified that account had plenty of space (5gb or 5,000,000 
available).  Some accounts that have only a couple hundred MB of mail with the 
5GB quota do not show this syptom.  

I understand that the quota patch does a divide by 1024 to work around the 
32but int issue.  It seems that the quota check math has some type of bug in 






It's not a production down situation if we pick an arbitrarily large good 
number but this defeats quota management.

Here is the error that we receive when we the server receivs an email:

Nov 21 18:17:37 cyrustest lmtpunix[21925]: accepted connection
Nov 21 18:17:37 cyrustest lmtpunix[21925]: lmtp connection preauth'd as postman
Nov 21 18:17:37 cyrustest master[21960]: about to exec /usr/lib/cyrus-
Nov 21 18:17:37 cyrustest lmtpunix[21925]: verify_user(user.test16) failed: 
Over quota
Nov 21 18:17:37 cyrustest lmtpunix[21960]: executed
Nov 21 18:17:37 cyrustest postfix/pipe[21804]: DAA4638129: 
to=<test16@localhost>, relay=cyrus, delay=0, status=deferred (temporary 

Comment 1 Gary W. Smith 2005-11-22 05:10:36 UTC
I tracked down the function call in the log file and I think I have found the 
root problem.  Here is the code fragment /imap/append.c

if (m.quota.limit >= 0 && quotacheck >= 0 &&
           m.quota.used + quotacheck > 
           ((unsigned) m.quota.limit * QUOTA_UNITS)) {
           r = IMAP_QUOTA_EXCEEDED;

If you see, m.quota.limit is being multiplied by quota_units which can results 
in an overflow which, if it's 1 over max would be 0.

So, 10,000,000 (or 10gb based on the 1024 quota_units multiplier would give a 
theoretical quota of 1,400,000 (or 1.4gb) which would be under the 1.8gb of 
space being used by the accounts in question.  So, from here we can calculate 
numbers that would always cause a threshold error based on the current quota 
usage in the user account.  

This seems to have been fixed in cyrus cvs 
bin/cvsweb.cgi/src/cyrus/imap/append.c.diff?r1=1.102&r2= but missed 
in this implementation.

Comment 2 Gary W. Smith 2005-11-22 05:22:39 UTC
One last comment, it appears that the fix was made back in February by the 
cyrus team on the 1.102 thread but it does not exist in the 1.107 thread.  I'm 
not sure if they didn't port the change forward, have a reason not to port it 
forward or if they just botched it.


You will see that the 1.102 change is never (by nine months) than the version 
for the newer 1.107 tree.

Comment 3 Gary W. Smith 2005-11-22 09:08:28 UTC
Created attachment 121333 [details]
Modifies 3 files to help out with the quota patch

This patch is not optimized.  I assumed a possible div/0 and then realized they
didn't check anywhere else. 

The authors did a couple multiplications that would easily exceed the 32 bit
integer.  Instead of multiplying the affected values I have just divided the
other values to bring them down to the same value expected by the rest of the
application.  This value is only used for comparison to see if the quota has
been exceeded.

This might have already been fixed in a later version of Cyrus but I didn't
want to merge tree's to cause more problems.  This patch seems to fix our
problem in development but I'm also not sure if it covers all of the possibly
cases that might throw a quota exception.  YMMV

Comment 4 jean-sebastien Hubert 2006-02-23 10:59:11 UTC
The bug seems to be fixed here -> 
It's a very very evil bug, specially when we use Groupware like kolab !

Comment 5 Gary W. Smith 2006-02-23 16:59:22 UTC
My patch seems to work but I will check out theirs as well.  I just don't want 
to implement something in production that will popup another issue.  What is 
concerning is that this bug fix is for 2.2.6 and yet it still isn't in the 
upstream 2.2.10 package.  

But I do like thier approach though.  It will just take some testing.

Comment 6 jean-sebastien Hubert 2006-02-23 17:13:28 UTC
the problem is clearly a overflow of the (long) type.
So, use a (long long) is, I think, the simplest way.
I think this bug is very important, because cyrus-imapd is used by kolab, so
large account is a frequent case (256 accounts in my case :)
The only "workaround" is to disable quotas ... not a good idea I think.

Maybe Redhat should quickly start testing this patch or take contact with the
cyrus-imap dev team.

Comment 8 Petr Rockai 2006-05-30 16:45:39 UTC
The proposed patch (which uses division instead of multiplication) may be 
not 100% correct, but nothing serious i believe. The other option is to go 
with long long for arithmetic as this should work on all our supported 

Comment 11 jean-sebastien Hubert 2006-06-30 07:37:06 UTC
Created attachment 131783 [details]
patch to fix overflow quota on cyrus-imapd-2.2.12-3gral / cyrus-imapd-2.2.12-3.RHEL4.1

Comment 12 jean-sebastien Hubert 2006-07-05 05:59:56 UTC
The patch id=131783 (a modified version of
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2690) is curretly tested in a
production server (300 users), hope it will work ...

Comment 13 jean-sebastien Hubert 2006-07-05 07:58:57 UTC
(In reply to comment #12)
> The patch id=131783 (a modified version of
> https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2690) is curretly tested in a
> production server (300 users), hope it will work ...

Does not work: because of conflict with patchs:

Comment 14 RHEL Product and Program Management 2006-08-18 16:59:58 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update

Comment 21 jean-sebastien Hubert 2007-02-06 06:58:38 UTC
Any news? patchs for test?

Comment 22 Red Hat Bugzilla 2007-05-01 17:15:25 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Comment 23 jean-sebastien Hubert 2007-05-02 11:37:10 UTC
Warning: when the cyrus-imapd is updated (on i386 32bit system) to version
cyrus-imapd-2.2.12-8.1.RHEL4 the quota file is corrupt!
Before this version, quotas are encoded in 32bits, now 64 ... so the problem is
The only solution is to log in "cyrus" user, and launch theses commands:

/usr/lib/cyrus-imapd/reconstruct  (could take a long time)
/usr/lib/cyrus-imapd/quota -f 
now the quotas are ok.
Maybe it should be useful to add this warning in a bulletin or upgrade notice.


jean-sebastien Hubert.

Note You need to log in before you can comment on or make changes to this bug.