> >When a message arrives and is delivered by vdelivermail,
> >the quotas are enforced. It also updates the maildirsize
> >file (and uses the maildir++ naming conventions) thereby
> >updating the maildir++ quota usage that is shared amongst
> >all maildir++ compatible software.
> >
> > From what I understand of maildir++, all the programs like
> >the POP, IMAP, and any maildir++ compatable software should
> >maintain the maildirsize file(s) for each folder, including
> >INBOX, so the usage should remain the same when moving messages
> >between folders. The usage should be restored when deleting
> >a message.
>
> It's all right when you receive messages because all the check is done in
> the receiving phase (vedelivermail). All right the same if you move
> messages between folders (sizes don't change).
>
> But what happens when you create messages with sqwebmail or squirrelmail &
> courier, or copy them to a remote IMAP server from your local folder?
>
> When you create a message or upload an attach, and keep them inside your
> "Sent" folder, vdelivermail is not used, so single users may create and
> store messages until their personal ".maildirsize" let them do it. So they
> may overflow domain quota.
>
> Tonino
>
I don't believe the "Sent" folder keeps track of any size.
I looked and don't see any "maildirsize" files in "Sent" folders.
So it doesn't look like it counts against either user or domain
quotas. You'll have to take a look at the spec to be sure.
I don't believe the Trash folder keeps track of size either.
It does, I'm sure. You may disable it (for example in sqwebmail and likely courier), but if you're a provider you're going to control all the space customers are wasting (specially if they are webmail users), including "Sent", "Trash" and additional folders.
In any case, you can use system quotas if you want to bypass any/all of this to make sure everything is accounted for.
These problems must be highlighted much more, because people may think this "vpopmail domain quota" feature could solve all problems transparently, and this is not true.
I think this feature may be a first step, but must be followed by coherent changes in other packages, before it may be used in an integrated environment.
Ciao,
Tonino
