Hi Timo,

[snipped possible scenario's]

> OK. 3) is the best idea :) But it requires a few changes to
> make it work.
I wouldn't expect it to work out of the box :)

But if I read your suggestions right, you propose a "fixed" change in the maildir functions that call the quota update functions if necessary. So perhaps we should make a quota_enabled = yes|no flag int the config file, and use that? I would still be trying to make the quota update functions for you, and try to put them in.

> Actually, I think this is exactly how I want quota and ACLs
> to be implemented. No extra interface changes for either one of them.
>
> For quota, you'd want to do something like:
>
> expunge(): nothing special, just update the quota file after expunges
Expunge should recalculate the whole mailfolder?

> save_next(): Check data istream's size and if it's over quota, fail.

Ok. So this one can be "easy". Just check if mailsize + current usage < max_quota. :)

> copy(): this is somewhat problematic, if there wasn't the
> maildir hardlinks you wouldn't have to touch it at all..

A copy can duplicate a message in the same store, but do hardlinks work on nfs? If not, we should add the message to the quota list. And maybe we should just add size of the email anyway, it won't be that much of a loss to the user, and it would save us a lot of checking. :)

And how about a user that has no quota file (yet), can we "recreate" them? Maybe do a quota lookup for the user (database or file)? This can be done using a module I guess, so it could be "user configurable".

Regards,

Maikel Verheijen.