[dovecot] Re: quotas again

[Mark E. Mallett]

On Mon, Apr 21, 2003 at 06:53:53PM +0300, Timo Sirainen wrote:
> On Mon, 2003-04-21 at 17:47, Mark E. Mallett wrote:
> > A couple of notes about quotas-- I know this has been brought up
> > before but the negative effects that occur when a user is over quota
> > are still disconcerting.
> > 
> > Ideally it would be best if a user could at least delete mail when in
> > an over-quota condition.  One would think it would be enough to simply
> > ignore errors creating the index files (and use an in-memory index).
> > However, another problem is that the mere renaming of a file from the
> > new/ directory to the cur/ directory can cause an over-quota error if
> > the cur/ directory has to be expanded.  We see these errors in the
> > maillog followed by an "I/O leak" message, e.g.:
> 
> Hmm. I'm not sure how to fix this properly. I can of course just ignore
> those files in new/, but then user can't delete those messages. Maybe I
> should allow keeping the files in new/ in out-of-disk-space conditions..

I would think so.  If a file can't be renamed to cur/ because of
expanding the directory, there are already a bunch of files in cur/ .
Allowing some deletion would help before they have to pick up the phone
and have somebody intervene.


> uidlist file is also problematic. If there's no disk space to build new
> one, the UIDs can't be permanently saved. Or worse, they could be reused
> for different messages breaking client's cache.

Yeah- trouble is if there are quotas enabled at all, people are going
to hit them.  The first time a person gets over quota they are either
going to learn to manage the mailbox, or they are going to request (and
probably get) more space if they have a real need for it.  However
it's likely to keep happening.

Unfortunately using filesystem quotas for mailboxes has problems.  At
one point we had a mail delivery quota system here that was not related
to filesystem quotas (i.e. the mail delivery agent would arrange not to
deliver mail to a mailbox that was at its limit, and would in fact
insert a single warning note instead)-- however filesystem quotas were
not in effect, so it was possible to manipulate the mailbox via the
POP or IMAP interface.  This was under sendmail, though, and I have
not yet thought about doing something similar under qmail.

mm