On Thursday 06 March 2003 16:40, Brian Kolaci wrote: > > 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.
That depends on what you want to do with it. If you want courier and vpopmail to use the same quota system so that both applications can enforce the same quota, then it does matter. And what is so wrong with that? Why are you so opposed to the idea of courier and vpopmail sharing the same quota system? I don't see that idea as anything but a good thing. Are you worried that I want YOU to implement it? I don't. Rest assured. I don't care if you do, but I'm not trying to convince you to implement anything. > 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. Again, that depends on what you're trying to accomplish. > > 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 Well, if it doesn't get the quota from vpopmail then it can't enforce the quota. That's not good. > 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. What are you talking about? maildirsize is already within the grasp of the user. And you're right, it's "re-evaluated". That means that any user with access can simply change the value up or down and their quota will be different as reported by vuserinfo. As far as I can tell, maildirsize is only recalculated from scratch when it doesn't exist. > > > > 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"? Any software that writes to a vpopmail maildir. > 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. I'm tempted to curse here. Of coarse I'm trying to mix qmail/vpopmail and courier! What else would I be trying to do? What do you think you're doing when you use courier for IMAP or POP3 access? You're mixing it. > > > 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. And that's what I'd like to change. I'd like courier to be able to read a userquota file, (just like it now reads 'maildirsize'), that contains the user quota for the Maildir. Then I think it would be a good idea for the 'userquota' file to include a reference to a 'domainquota' file (optionally) that contains the quota for the domain. Then, both courier and vpopmail would both be able to read the quota limits and enforce them. In addition, any other program could do the same. I can't see any security risks involved in that plan. Sure, it might be a wee bit slower than storing the quota in a database, but not by much. You open the file, you read the file, you close the file. Vpopmail could even cache the file contents in a database for quick future look ups and only re-read it in the event of a timestamp change. Courier could do the same. And suddenly "everyone" is enforcing the quota properly. > You can't just assume when user information is stored in > one place that software developed for another project will use it. I'm not assuming anything. I'm proposing that vpopmail could do this instead of what it currently does, and I'll talk with Mr. Sam about adding support to courier for the same thing. Heck, I'll write it. I don't care. I just think it's a good idea. > > > 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... Ok. I'm not really asking you to. > > > 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. I'm not. I wouldn't be. I'd be storing it in the exact same place that we store 'maildirsize' currently. > A quota is just another limit, as > is the other information used by qmailadmin. But currently it's a limit that only vpopmail can use. I'd like to see it available to other programs EASILY, without having to compile in a vpopmail library. Otherwise, I'll never be able to use other programs that directly manipulate my maildirs. > > Thanks, > > Brian -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net We are actively looking for companies that do a lot of long distance faxing and want to cut their long distance bill by up to 50%. Contact [EMAIL PROTECTED] for more info.
