[dovecot] Re: quota

Mike Machado mike at innercite.com
Wed May 7 19:04:12 EEST 2003

Believe me, over quota conditions is a major source of ISP support
headaches. Entire systems have been designed around trying to manage
this very issue.

I think doing something special under this unique condition to at least
allow some messages to be deleted is acceptable as long as it does not
corrupt mail, even if it includes forcing a client logout.

As a side thought, couldn't you delete the message from the mailbox,
THEN update the UID list, because at that point you would be able to
write to the file?

On Tue, 2003-05-06 at 19:56, Timo Sirainen wrote:
> On Tue, 2003-05-06 at 16:50, Sebastian Pachuta wrote:
> > second, there is a problem when user exceed their quota
> Yes, there's several problems. Biggest one is what to do if we can't
> update dovecot-uidlist file.
> If we continued normally but without storing the UIDs permanently, then
> expunged some messages, logged out and logged in again, the UIDs are
> different from last time and that breaks client's cache.
> If we just overwrote next-UID field in dovecot-uidlist we'd get new UIDs
> next time which is fine, except if client selects the mailbox multiple
> times it gets different UIDs for the messages. That probably breaks some
> clients (OE I think).
> One kludgy solution is to overwrite next-UID field only when messages
> are expunged and then force all clients that have selected the mailbox
> to log out.
> Overwriting next-UID isn't too safe either since readers don't do any
> kind of locking for the file, but I'd hope writing 1-10 bytes is usually
> atomic? Well, we could use fcntl() locking in out-of-diskspace
> conditions but I'm not sure if it's worth it..
Mike Machado
mike at innercite.com
InnerCite Inc.
Engineering Director / CTO

Return-Path: dovecot-bounces at procontrol.fi
Received: from danu.procontrol.fi (localhost [])
	by danu.procontrol.fi (Postfix) with ESMTP
	id 5980E239A8; Mon, 12 May 2003 17:56:53 +0300 (EEST)
X-Original-To: dovecot at procontrol.fi
Delivered-To: dovecot at procontrol.fi
Received: from nssg.mitel.com (mail.e-smith.com [])
	by danu.procontrol.fi (Postfix) with SMTP id 57BCC238D1
	for <dovecot at procontrol.fi>; Mon, 12 May 2003 17:56:52 +0300 (EEST)
Received: (qmail 21878 invoked by uid 404); 12 May 2003 14:56:51 -0000
Received: from charlieb-dovecot at e-smith.com by tripe.nssg.mitel.com with
	qmail-scanner; 12 May 2003 10:56:50 -0000
Received: from allspice-core.nssg.mitel.com (HELO e-smith.com) (
  by tripe.nssg.mitel.com ( with SMTP; 12 May 2003 14:56:50 -0000
Received: (qmail 11560 invoked from network); 12 May 2003 14:56:50 -0000
Received: from vegemite.nssg.mitel.com (
  by allspice.nssg.mitel.com with QMQP; 12 May 2003 14:56:50 -0000
Received: from localhost (sendmail-bs at
  by localhost with SMTP; 12 May 2003 15:01:14 -0000
Date: Mon, 12 May 2003 11:01:14 -0400 (EDT)
From: Charlie Brady <charlieb-dovecot at e-smith.com>
X-X-Sender: charlieb at vegemite.nssg.mitel.com
To: Timo Sirainen <tss at iki.fi>
Subject: Re: [dovecot] Re: Design thought - Retention of reworked mbox files
In-Reply-To: <1052701549.5227.415.camel at hurina>
Message-ID: <Pine.LNX.4.44.0305121100120.18840-100000 at vegemite.nssg.mitel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: dovecot at procontrol.fi
X-BeenThere: dovecot at procontrol.fi
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Dovecot Mailing List <dovecot.procontrol.fi>
List-Unsubscribe: <http://procontrol.fi/cgi-bin/mailman/listinfo/dovecot>,
	<mailto:dovecot-request at procontrol.fi?subject=unsubscribe>
List-Archive: <http://procontrol.fi/pipermail/dovecot>
List-Post: <mailto:dovecot at procontrol.fi>
List-Help: <mailto:dovecot-request at procontrol.fi?subject=help>
List-Subscribe: <http://procontrol.fi/cgi-bin/mailman/listinfo/dovecot>,
	<mailto:dovecot-request at procontrol.fi?subject=subscribe>
Sender: dovecot-bounces at procontrol.fi
Errors-To: dovecot-bounces at procontrol.fi

On 12 May 2003, Timo Sirainen wrote:

> On Mon, 2003-05-12 at 02:05, Tim Hunt wrote:
> > Would it be possible to keep a backup copy of an mbox mail file any time it 
> > needs to be substantionally rebuilt - for an example before an expunge. This 
> > behaviour could be controlled by the config file, since it would most likely 
> > only be used in development and testing environments.
> If it's only for debugging, I guess I could then just save a copy of it.

Presumably the other reason you'd want it would be for mailbox integrity. 
But if you are concerned about that, you'd be using maildir, wouldn't you?


More information about the dovecot mailing list