> So the domain quotas aren't stored in a file, but rather in whatever
> backend you happen to be using?
They are stored in either the .qmailadmin-limits file, or MySQL,
The "user" quota is stored in the "pw_shell" attribute of the
password entry for the user.
> I'd think that if the domain quotas could be stored in a file, that a
> could be made to the maildir++ standard. Perhaps the maildirsize file could
> a reference to the location of the domain quota file. This would be quite
> I'd think.
> What do you think?
> Either way, I think this functionality needs to be implemented in a way
> that Courier-IMAP and other programs can live with. It should be
> otherwise vpopmail will be implementing a feature that no-one else can
> realistically use without linking vpopmail's libraries into their code
> (which I mentioned in another thread as being a bit of a pain sometimes).
Yes, but I don't think that courier has a need or
care for domain based quotas, just as Bill said. Most people
use system quotas.
If you use courier, then you'll wind up using its own SQL
implementation (he doesn't use files either).
BTW, maildir++ quotas isn't really a "standard". First, there was
courier, where it started. Bill then updated vpopmail to also
conform since there's no down-side to it, but you can get benefit
Good luck trying to get everyone to swap to a file based system.
I personally like *everything* in the database rather than filesystem.
All the information (other than message store & cache info) is in the
database for easy backup/recovery.
I'd say we beat this topic to death though. Since you're using
maildrop, then why not create a patch for it. Then the patch itself
could be included in the vpopmail distribution, or kept separate as
its own distribution.