> If vpopmail stores the actual user quota in a database, and the maildirsize
  > file just stores the current size of the maildir (which IS a file based
  > system, BTW), then doesn't that mean that Maildrop has NEVER been capable
  > of enforcing maildir++ with vpopmail?

I guess I wasn't explicit enough.  I assumed people already
knew how the quota's are stored.  The "user quota" for vpopmail
is stored in the pw_shell attribute of the vqpasswd structure.
Where this information is stored (db, cdb, file) doesn't matter.
You use an API to get at it.  In courier, a different place is used.
The "domain quota" is now currently stored in the qmailadmin limits
information, which is now retrieved using the vget_limits() function.
Again, where it is actually stored doesn't matter.

Now the "usage" of maildir++ quotas is stored in the filename.  There
is a cache file in the Maildir called maildirsize that caches all the
file sizes in one file.

  > 
  > All of the docs on the web seem to suggest that maildrop IS compatible with
  > maildir++. Does "compatible" in that sense only mean that maildrop can
  > manipulate the maildirsize file? But that it doesn't actually have a clue
  > when a user's quota is exceeded? I guess I never understood that properly.

I'm sure it is "compatible" in that sense.  I don't know the rules
of how it enforces the quota nor where it gets the user quota from.
I doubt it gets it from vpopmail and the vqpasswd file as vdelivermail 
does, but I may be wrong.

  > Also, I don't see why implementing "soft" quotas with another file inside
  > the maildir would be such a bad idea. The maildirsize file is already
  > vulnerable to user modification, so it ONLY works when the user doesn't
  > have shell access to their own maildir. Also, EMAIL is backed up from the
  > file system, so what's wrong with backing up the quota that applies to that
  > email with it?

The maildirsize file is auto-recreated or re-evaluated when mail
is deleted.  I don't think putting the quotas within the grasp
of the user is a good idea.

  > > 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.
  > 
  > Sure, I could do that, but then I'd have to maintain a patch, and that's
  > messy. I'd much rather implement a standard that everyone can work with.

What exactly is "everyone"?  Its just vpopmail & courier.  You just
happen to have a specialized installation that is using both.  It
sounds like for you, the features of courier outweigh the features
of vpopmail, so you should probably just convert to courier
and not use vpopmail.  If you think the features of vpopmail are
more important, then think about putting what you like better in
courier into vpopmail.  You're trying to mix qmail/vpopmail and
courier.

  > Please bare with me here. I'm starting to realize that I didn't really
  > understand how these quotas work, and that there is a great possibility
  > that maildrop was never really capable of enforcing maildir++ quotas
  > (because maildir++ doesn't really have much to do with the quota itself,
  > but rather the size of the maildir)

True.  It may enforce it, however I would say with its own user storage
and rules.  You can't just assume when user information is stored in
one place that software developed for another project will use it.

  > I really need a way to filter email on the server side, so unless that
  > functionality makes it's way into vdelivermail in the near future, I'd
  > really like to discuss the possibility of expanding the maildir++
  > specification to include user and domain quotas.

I don't even want to touch that...

  > I'd be willing to write code for this too, so it's not like you're talking
  > to someone who's just mouthing off and whining for functionality. This
  > is how Open Source works: When a developer has an itch, he scratches it,
  > and everyone benefits, right?
  > 
  > Lets talk. If you're willing to help me hammer out an idea that works,
  > then I'll pitch it to Mr. Sam. If we do a good job and it makes sense,
  > then I doubt he'll object as long as I do most of the coding and he
  > doesn't have to.

Sorry, but I still don't think you should store limits information
within control of end users.  A quota is just another limit, as
is the other information used by qmailadmin.

Thanks,

Brian


Reply via email to