[vchkpw] new quota support question
Howdy list, I'm just wondering a few things about the new domain wide quotas: Are these quotas implemented in vdelivermail? Or are they implemented with system quotas? Will I still be able to use maildrop to filter my mail? When are the quotas recalculated? (If maildrop deletes a message, will it throw the quotas off?) Thanks! -- 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.
Re: [vchkpw] new quota support question
Howdy list, I'm just wondering a few things about the new domain wide quotas: Are these quotas implemented in vdelivermail? Yes. Or are they implemented with system quotas? You can do that also if you wish, however you'll need to supply your own scripts for that. Will I still be able to use maildrop to filter my mail? I'm unsure about maildrop. If it delivers the mail via vdelivermail, then yes, but if it writes directly to the file system, it needs to be patched to enforce the quotas. I've updated libvpopmail.a to include the quota code, so you should be able to patch it if needed. When are the quotas recalculated? (If maildrop deletes a message, will it throw the quotas off?) The domain quota code recalculates the quota each time on the fly. One big benefit now is its use of the maildirsize files, if they're there. This is a big performance gain. But if you don't have anything creating maintaining these files (and they don't exist), then the performance would be pretty bad if people leave mail on server, and you constantly have to sum up thousands of files. I haven't used maildrop, and I see the maildirsize files in each user's Maildir so I assume vdelivermail is maintaining them. You'll need to try it out and see what kind of performance you get. In my copy, I have syslog()'s logging the clock over these and I typically see about 0.001s when the cache files are there, and up to 7s when they're not (but then they suddenly appear, so it must be creating them by default). The 7 seconds was due to a user with a few thousand messages still in there and no maildirsize file. Thanks, Brian
Re: [vchkpw] new quota support question
On Thursday 06 March 2003 09:49, Brian Kolaci wrote: Howdy list, I'm just wondering a few things about the new domain wide quotas: Are these quotas implemented in vdelivermail? Yes. Ok. Or are they implemented with system quotas? You can do that also if you wish, however you'll need to supply your own scripts for that. So, basically, no? What would I have to supply to use system quotas? Will I still be able to use maildrop to filter my mail? I'm unsure about maildrop. If it delivers the mail via vdelivermail, then yes, but if it writes directly to the file system, it needs to be patched to enforce the quotas. I've updated libvpopmail.a to include the quota code, so you should be able to patch it if needed. Maildrop is maildir++ compatible. I assume that this new code deviates from the maildir++ standard? When are the quotas recalculated? (If maildrop deletes a message, will it throw the quotas off?) The domain quota code recalculates the quota each time on the fly. One big benefit now is its use of the maildirsize files, if they're there. This is a big performance gain. But if you don't have anything creating maintaining these files (and they don't exist), then the performance would be pretty bad if people leave mail on server, and you constantly have to sum up thousands of files. I haven't used maildrop, and I see the maildirsize files in each user's Maildir so I assume vdelivermail is maintaining them. You'll need to try it out and see what kind of performance you get. In my copy, I have syslog()'s logging the clock over these and I typically see about 0.001s when the cache files are there, and up to 7s when they're not (but then they suddenly appear, so it must be creating them by default). The 7 seconds was due to a user with a few thousand messages still in there and no maildirsize file. OK. So, when vdelivermail delivers a message to the maildir, it just modify's the quota based on the email's size, correct? It doesn't actually recalculate the entire quota? What happens when an IMAP or POP server deletes a message from the maildir? Is the quota then incorrect? I use Courier-IMAP. Is there a way to recalculate a user's maildir quota via command line? (For instance, so that all of my user's quotas could be recalculated at 4 AM from scratch via a shell script or Perl script?) Thanks for all the info! 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.
Re: [vchkpw] new quota support question
Or are they implemented with system quotas? You can do that also if you wish, however you'll need to supply your own scripts for that. So, basically, no? What would I have to supply to use system quotas? If you wish to use system quota's, you'll need to write a script to update the system quota. I'm on solaris, so I use a script that sends some commands to edquota. On linux, it may be different. Will I still be able to use maildrop to filter my mail? I'm unsure about maildrop. If it delivers the mail via vdelivermail, then yes, but if it writes directly to the file system, it needs to be patched to enforce the quotas. I've updated libvpopmail.a to include the quota code, so you should be able to patch it if needed. Maildrop is maildir++ compatible. I assume that this new code deviates from the maildir++ standard? Yes, however only for user quotas. There's no concept of domain quotas in courier that I'm aware of. This code is maildir++ compliant, but now vdelivermail uses the limits API to retrieve the per-domain limits (disk quota max msg count) and enforce it by making a check at the current usage (which calculates usage by summing up the usage for each mailbox within a domain). When are the quotas recalculated? (If maildrop deletes a message, will it throw the quotas off?) The domain quota code recalculates the quota each time on the fly. One big benefit now is its use of the maildirsize files, if they're there. This is a big performance gain. But if you don't have anything creating maintaining these files (and they don't exist), then the performance would be pretty bad if people leave mail on server, and you constantly have to sum up thousands of files. I haven't used maildrop, and I see the maildirsize files in each user's Maildir so I assume vdelivermail is maintaining them. You'll need to try it out and see what kind of performance you get. In my copy, I have syslog()'s logging the clock over these and I typically see about 0.001s when the cache files are there, and up to 7s when they're not (but then they suddenly appear, so it must be creating them by default). The 7 seconds was due to a user with a few thousand messages still in there and no maildirsize file. OK. So, when vdelivermail delivers a message to the maildir, it just modify's the quota based on the email's size, correct? It doesn't actually recalculate the entire quota? I believe it checks if the file is there and recalulates the entire maildir if its missiing. If its there, it just appends the quota information to the maildirsize file. What happens when an IMAP or POP server deletes a message from the maildir? Is the quota then incorrect? I use Courier-IMAP. I use courier-imap as well as the courier pop3 daemon. I believe the imap server recalculates the quota for the maildir. I'm not sure whether it recalculates the whole user maildir, or just removes one entry from the file. You'll have to check the code. Is there a way to recalculate a user's maildir quota via command line? (For instance, so that all of my user's quotas could be recalculated at 4 AM from scratch via a shell script or Perl script?) Not that I'm aware of. I think you automatically get it if its not there during a delivery. Since maildrop is part of courier (I assume it is), then it probably manages the maildirsize files already as vdelivermail does. It probably enforces user quotas, but I'm not sure. It won't enforce domain quotas without patching it to retrieve enforce a domain level quota. You'll need the vget_limits() function from the vpopmail library for that. Thanks for all the info! No prob. Good luck. Brian
[vchkpw] vpopmail 5.3.19
Wednesday March 05 2003 11:47, Bill Shupp wrote to All: BS I've posted a new devel version, 5.3.19. Please help test Still no user expiry feature? KS KARICO Business Services Toronto, ON Canada http://www.karico.ca
RE: [vchkpw] vpopmail 5.3.19
I Have it installed on 2 machines now and works fine. REMO -Original Message- From: Kari Suomela [mailto:[EMAIL PROTECTED] Sent: Thursday, March 06, 2003 9:11 AM To: [EMAIL PROTECTED] Subject: [vchkpw] vpopmail 5.3.19 Wednesday March 05 2003 11:47, Bill Shupp wrote to All: BS I've posted a new devel version, 5.3.19. Please help test Still no user expiry feature? KS KARICO Business Services Toronto, ON Canada http://www.karico.ca
Re: [vchkpw] vpopmail 5.3.19
On Thursday, March 6, 2003, at 08:11 AM, Kari Suomela wrote: Wednesday March 05 2003 11:47, Bill Shupp wrote to All: BS I've posted a new devel version, 5.3.19. Please help test Still no user expiry feature? What are you talking about? It sounds like you're complaining about some feature you're expecting. Did you contribute a patch that was missed? Please elaborate. There is vdeloldusers, but that is based on lack of authentication, rather than timed expiration. Regards, Bill Shupp
Re: [vchkpw] vpopmail 5.3.19
Wednesday March 05 2003 11:47, Bill Shupp wrote to All: BS I've posted a new devel version, 5.3.19. Please help test Still no user expiry feature? Have you written it yet? When you write it, then you should post the patch to the list. It would be reviewed, tested, then possibly/probably added to the release. Brian KS KARICO Business Services Toronto, ON Canada http://www.karico.ca
Re: [vchkpw] new quota support question
On Thursday, March 6, 2003, at 06:16 AM, Jesse Guardiani wrote: Howdy list, I'm just wondering a few things about the new domain wide quotas: Are these quotas implemented in vdelivermail? Or are they implemented with system quotas? Will I still be able to use maildrop to filter my mail? I addresses the above questions in README.quotas. Please take the time to read it before posting to the list, that's why I took the time to write it. When are the quotas recalculated? (If maildrop deletes a message, will it throw the quotas off?) It calculates based on maildirsize files, which greatly increases performance. (Brian's original implementation used a du like function that delayed delivery by as much as several seconds). So it does follow the Maildir++ standard, it's just a cumulative approach. Regards, Bill Shupp
Re: [vchkpw] new quota support question
On Thursday 06 March 2003 11:28, Bill Shupp wrote: On Thursday, March 6, 2003, at 06:16 AM, Jesse Guardiani wrote: Howdy list, I'm just wondering a few things about the new domain wide quotas: Are these quotas implemented in vdelivermail? Or are they implemented with system quotas? Will I still be able to use maildrop to filter my mail? I addresses the above questions in README.quotas. Please take the time to read it before posting to the list, that's why I took the time to write it. Thanks, Bill, but Brian was kind enough to answer most of my questions directly. Last time I checked, mailing lists were a good place for open discussion. When are the quotas recalculated? (If maildrop deletes a message, will it throw the quotas off?) It calculates based on maildirsize files, which greatly increases performance. (Brian's original implementation used a du like function that delayed delivery by as much as several seconds). So it does follow the Maildir++ standard, it's just a cumulative approach. Yes, and using maildrop will totally keep domain based quotas from working properly. Looks like someone needs to patch the courier-imap and friends. Any takers? I'm swamped. Regards, Bill Shupp -- 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.
Re: [vchkpw] new quota support question
On Thursday, March 6, 2003, at 10:05 AM, Jesse Guardiani wrote: Thanks, Bill, but Brian was kind enough to answer most of my questions directly. Last time I checked, mailing lists were a good place for open discussion. Of course they are. But reading documentation can reduce unnecessary traffic, too. Especially when the ChangeLog clearly indicates that new documentation is available on the changes you discovered in the ChangeLog. Yes, and using maildrop will totally keep domain based quotas from working properly. Looks like someone needs to patch the courier-imap and friends. I'd be curious to see if Mr. Sam accepts such patches. I personally think that this new non-system domain quota feature is unnecessary, when system quotas are available, easily implemented, and a better solution. But enough people seemed to want it for some reason, and Brian did a very nice job of implementing it cleanly with his other vlimits functions, so I included it in my devel version. Notice that Ken has not yet signed off on this, so there's no guarantee that it will make it in the official release, anyway. So you might hold off on patching anything else, unless you (or anyone else) are prepared to maintain it. Regards, Bill Shupp
Re: [vchkpw] new quota support question
On Thursday 06 March 2003 13:20, Bill Shupp wrote: On Thursday, March 6, 2003, at 10:05 AM, Jesse Guardiani wrote: snip I'd be curious to see if Mr. Sam accepts such patches. I personally think that this new non-system domain quota feature is unnecessary, when system quotas are available, easily implemented, and a better solution. But enough people seemed to want it for some reason, and Brian did a very nice job of implementing it cleanly with his other vlimits functions, so I included it in my devel version. Notice that Ken has not yet signed off on this, so there's no guarantee that it will make it in the official release, anyway. So you might hold off on patching anything else, unless you (or anyone else) are prepared to maintain it. Noted. I personally hope it makes production. Sounds like a good idea to me, it just seems to require a ratification to the maildir++ standard. Regards, Bill Shupp -- 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.
[vchkpw] Vqadmin + Domain quotas
Hi all
I found domain quotas so fine that I slightly hacked vqadmin 2.3.5 to
support domain quotas. Please verify and use if you like it :-)
It's diff -u format
Solt
- cut here
diff -u -r vqadmin-2.3.5/domain.c vqadmin-2.3.5-solt/domain.c
--- vqadmin-2.3.5/domain.c Thu Jan 9 21:17:15 2003
+++ vqadmin-2.3.5-solt/domain.c Thu Mar 6 00:06:55 2003
-48,6 +48,7
char *lresponder = NULL;
char *llists = NULL;
char *quota = NULL;
+ char *default_quota = NULL;
char *upop = NULL;
char *uimap = NULL;
char *udialup = NULL;
-75,6 +76,7
llists = cgi_is_var(llists);
quota = cgi_is_var(quota);
+ default_quota = cgi_is_var(default_quota);
upop= cgi_is_var(upop);
uimap = cgi_is_var(uimap);
udialup = cgi_is_var(udialup);
-127,7 +129,10
fprintf(fs, maxmailinglists: %s\n, llists);
if (quota!=NULL strlen(quota)0)
-fprintf(fs,default_quota: %s\n,quota);
+fprintf(fs,quota: %s\n,quota);
+
+ if (default_quota!=NULL strlen(default_quota)0)
+fprintf(fs,default_quota: %s\n,default_quota);
if (upop!=NULL) fprintf(fs, disable_pop\n);
if (uimap!=NULL) fprintf(fs, disable_imap\n);
-207,6 +212,7
char *lresponder = NULL;
char *llists = NULL;
char *quota = NULL;
+ char *default_quota = NULL;
char *upop = NULL;
char *uimap = NULL;
char *udialup = NULL;
-238,6 +244,7
lresponder = cgi_is_var(lresponder);
llists = cgi_is_var(llists);
quota = cgi_is_var(quota);
+ default_quota = cgi_is_var(default_quota);
upop= cgi_is_var(upop);
uimap = cgi_is_var(uimap);
udialup = cgi_is_var(udialup);
-261,8 +268,10
fprintf(fs, maxautoresponders: %s\n, lresponder);
if ( llists!=NULL strlen(llists) 0 )
fprintf(fs, maxmailinglists: %s\n, llists);
+ if (default_quota!=NULL strlen(default_quota)0)
+fprintf(fs,default_quota: %s\n,default_quota);
if (quota!=NULL strlen(quota)0)
-fprintf(fs,default_quota: %s\n,quota);
+fprintf(fs,quota: %s\n,quota);
if (upop!=NULL) fprintf(fs, disable_pop\n);
if (uimap!=NULL) fprintf(fs, disable_imap\n);
-365,7 +374,7
} else if ( strcmp(tmpstr1, default_quota) == 0 ) {
if ( (tmpstr2 = strtok(NULL,TOKENS))==NULL) continue;
-global_par(MQ, tmpstr2);
+global_par(QD, tmpstr2);
} else if ( strcmp(tmpstr1, disable_pop) == 0 ) {
global_par(MP, checked);
diff -u -r vqadmin-2.3.5/html/add_domain.html
vqadmin-2.3.5-solt/html/add_domain.html
--- vqadmin-2.3.5/html/add_domain.html Fri Feb 14 19:49:02 2003
+++ vqadmin-2.3.5-solt/html/add_domain.html Thu Mar 6 00:03:14 2003
-36,6 +36,8
td class=clsInfo#-050/td/tr
trtd class=clsLabelR#-039/td
tdinput type=text name=quota size=10
title=#-039/td/tr
+trtd class=clsLabelR#-039 default/td
+tdinput type=text name=default_quota size=10
+ title=#-039/td/tr
/table
table border=0 cellspacing=0 cellpadding=0
diff -u -r vqadmin-2.3.5/html/mod_domain.html
vqadmin-2.3.5-solt/html/mod_domain.html
--- vqadmin-2.3.5/html/mod_domain.html Fri Feb 14 19:49:51 2003
+++ vqadmin-2.3.5-solt/html/mod_domain.html Thu Mar 6 00:07:47 2003
-53,6 +53,8
td class=clsInfo#-050/td/tr
trtd class=clsLabelR#-039/td
tdinput type=text name=quota value=$-MQ size=10
title=#-039/td/tr
+trtd class=clsLabelR#-039 default/td
+tdinput type=text name=default_quota value=$-QD size=10
+ title=#-039/td/tr
/table
table border=0 cellspacing=0 cellpadding=0
trtdinput TYPE=checkbox NAME=upop id=upop$-MP
title=#-042label for=upop title=#-042#-042/label/td/tr
diff -u -r vqadmin-2.3.5/html/vqadmin.css
vqadmin-2.3.5-solt/html/vqadmin.css
--- vqadmin-2.3.5/html/vqadmin.css Thu Jan 9 22:41:37 2003
+++ vqadmin-2.3.5-solt/html/vqadmin.css Thu Mar 6 00:09:42 2003
-19,9 +19,9
BODY {
margin : 10px 0px 0px 10px;
-background-color : #5255F6;
+background-color : #5255a6;
color : #FF;
- font: normal normal normal 12pt/normal Verdana, Geneva, Arial,
Helvetica, sans-serif;
+ font: normal normal normal 11px/normal Verdana, Geneva, Arial,
+Helvetica, sans-serif;
}
HR {
-31,17 +31,17
}
input {
- font: normal normal normal 12pt/normal Courier New, Courier,
monospace;
+ font: normal normal normal 11px/normal Courier New, Courier,
+monospace;
color: #00;
}
TD {
- font: normal normal normal 12pt/normal Verdana, Geneva, Arial,
Helvetica, sans-serif;
+ font: normal normal normal 11px/normal Verdana, Geneva, Arial,
+Helvetica, sans-serif;
color: #FF;
}
TH {
- font: normal normal normal 12pt/normal Verdana, Geneva, Arial,
Helvetica, sans-serif;
+ font: normal normal normal 11px/normal Verdana, Geneva, Arial,
+Helvetica, sans-serif;
color: #FF;
}
-67,10 +67,10
.clsMessage {
background-color: transparent;
color: #FF;
- font-size: 12pt;
+
Re: [vchkpw] new quota support question
I'd be curious to see if Mr. Sam accepts such patches. I personally think that this new non-system domain quota feature is unnecessary, when system quotas are available, easily implemented, and a better solution. But enough people seemed to want it for some reason, and Brian did a very nice job of implementing it cleanly with his other vlimits functions, so I included it in my devel version. Notice that Ken has not yet signed off on this, so there's no guarantee that it will make it in the official release, anyway. So you might hold off on patching anything else, unless you (or anyone else) are prepared to maintain it. Noted. I personally hope it makes production. Sounds like a good idea to me, it just seems to require a ratification to the maildir++ standard. Seems unlikely. courier has no provision to store domain quotas, only user quotas. Like I said in my last email, it requires getting the domain quota from somewhere, and vdelivermail uses the vget_limits() API out of libvpopmail.a. Brian
Re: [vchkpw] new quota support question
So the domain quotas aren't stored in a file, but rather in whatever database backend you happen to be using? They are stored in either the .qmailadmin-limits file, or MySQL, if enabled. 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 ratification could be made to the maildir++ standard. Perhaps the maildirsize file could contain a reference to the location of the domain quota file. This would be quite flexible 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 standardized, 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 from it. 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. Brian
Re: [vchkpw] new quota support question
On Thursday 06 March 2003 14:15, Brian Kolaci wrote: So the domain quotas aren't stored in a file, but rather in whatever snip 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. Could you clarify something for me? 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? 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. 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? 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. 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) 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'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. 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.
[vchkpw] tcp.smtp file perms/owns for -enable-roaming-users?
Hello, Apologies if this is already answered elsewhere -- I didn't see it. What should the file permissions and ownership be for the tcprules tcp.smtp file in order to enable vpopmail pop-before-smtp roaming user support? In other words, for qmail/vpopmail to temporarily add an IP address for pop-before-stmp temp-relay support, what setup do I need? Thank you, -ben Benjamin Tomhave, Senior Systems Engineer [EMAIL PROTECTED] Sofast Communications www.sofast.net
[vchkpw] Problem....
I am running several domains and I have one domain that when you try to send e-mail to the postmaster account, the only account defined, it get a relay denied message. Any help ?
[vchkpw] domain problem
I installed vpopmail on a server, then moved to a new box and moved data over. 1 thing i missed was the user account, the vpopmail user was 97 on one box and is 89 on the other. I have a domain that I cannot add or delete. I changed the file permissions on the domain's folder but that didn't help. When I do a vdominfo it shows that domain as owned by the old user acount, #97. Even if I mv the folder for that domain out of the domains directory, it still shows up in vdominfo. If I use vdomdel it says that domain doesn't exist, if I try to create is, it says it's already there. Where else is virtual domain info kept? -- jake
RE: [vchkpw] domain problem
In /var/qmail/users/assign. You'll notice that the uid/gid of vpopmail is in that file, change it to the new uid/gid of the vpopmail user then run /var/qmail/bin/qmail-newu -Clayton -Original Message- From: jake [mailto:[EMAIL PROTECTED] Sent: Thursday, March 06, 2003 1:30 PM To: [EMAIL PROTECTED] Subject: [vchkpw] domain problem I installed vpopmail on a server, then moved to a new box and moved data over. 1 thing i missed was the user account, the vpopmail user was 97 on one box and is 89 on the other. I have a domain that I cannot add or delete. I changed the file permissions on the domain's folder but that didn't help. When I do a vdominfo it shows that domain as owned by the old user acount, #97. Even if I mv the folder for that domain out of the domains directory, it still shows up in vdominfo. If I use vdomdel it says that domain doesn't exist, if I try to create is, it says it's already there. Where else is virtual domain info kept? -- jake
Re: [vchkpw] domain problem
Hi, In /var/qmail/users/assign Regards, Rick - Original Message - From: jake [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 06, 2003 4:30 PM Subject: [vchkpw] domain problem I installed vpopmail on a server, then moved to a new box and moved data over. 1 thing i missed was the user account, the vpopmail user was 97 on one box and is 89 on the other. I have a domain that I cannot add or delete. I changed the file permissions on the domain's folder but that didn't help. When I do a vdominfo it shows that domain as owned by the old user acount, #97. Even if I mv the folder for that domain out of the domains directory, it still shows up in vdominfo. If I use vdomdel it says that domain doesn't exist, if I try to create is, it says it's already there. Where else is virtual domain info kept? -- jake
Re: [vchkpw] new quota support question
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
Re: [vchkpw] new quota support question
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
RE: [vchkpw] new quota support question
-Original Message- From: Jesse Guardiani [mailto:[EMAIL PROTECTED] Sent: Friday, 7 March 2003 9:09 AM To: [EMAIL PROTECTED] Subject: Re: [vchkpw] new quota support question As far as I can tell, maildirsize is only recalculated from scratch when it doesn't exist. The maildirsize file is totally recalc'ed periodically You can read about this at http://inter7.com/courierimap/README.maildirquota.html Look for the section titled : Calculating the quota for a Maildir++ Michael.
Re: [vchkpw] Problem....
Hi, I am running several domains and I have one domain that when you try to send e-mail to the postmaster account, the only account defined, it get a relay denied message. Domain is missing from rcpthosts/morercpthosts. claudio -- Claudio Nieder . mailto:[EMAIL PROTECTED] . http://www.inodes.ch iNodes AG . Friesenbergstrasse 3 . CH-8055 Zürich . +41 43 960 0066
Re: [vchkpw] Problem....
Unfortunately it is in the file rcpthosts. Any other ideas ?? I am fresh out. On Thu, 6 Mar 2003 23:57:17 +0100, Claudio Nieder [EMAIL PROTECTED] wrote: Hi, I am running several domains and I have one domain that when you try to send e-mail to the postmaster account, the only account defined, it get a relay denied message. Domain is missing from rcpthosts/morercpthosts. claudio
Re: [vchkpw] new quota support question
On Thursday, March 6, 2003, at 01:40 PM, Brian Kolaci wrote: 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. The important thing to remember is that Sam's approach now is to set the quota with maildirmake -q. The quota is stored ONLY in the maildirsize file itself. It is the responsibility of any Maildir++ aware applications to honor the quota established in that file. I only used pw_shell for backwards compatibility with the old vpopmail quotas. Regards, Bill Shupp
Re: [vchkpw] vpopmail 5.3.19
Complaining? Just asking a question. Not an unreasonable wish, either! You come across as if you're entitled to the feature in this release. Why not ask nicely instead of a half-sarcastic quip? I think that's what everyone's picking up on. Regards, Andrew
[vchkpw] learn code only in vchkpw?
Hi, After battling with --enable-learn-passwords=y for a couple of hours it seems to me that learn passwords only works with the vchkpw utility. I.e. it isn't part of the libvpopmail library so isn't included in authvchkpw if you are using courier-imap/pop3. Is this correct? This is an annoying way of doing things. cheers, iain.
Re: [vchkpw] new quota support question
- Original Message - From: Bill Shupp [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 06, 2003 6:56 PM Subject: Re: [vchkpw] new quota support question On Thursday, March 6, 2003, at 01:40 PM, Brian Kolaci wrote: 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. The important thing to remember is that Sam's approach now is to set the quota with maildirmake -q. The quota is stored ONLY in the maildirsize file itself. It is the responsibility of any Maildir++ aware applications to honor the quota established in that file. I only used pw_shell for backwards compatibility with the old vpopmail quotas. OK OK. Brian had me thinking that the quota was stored in a database with all of that talk about pw_shell and limits API calls. I now see that (as I originally thought), the quota is actually stored in the 'maildirsize' file. (I opened it up and looked at it in my maildir) I haven't read enough about 'maildirmake -q', so I don't know if that program actually makes USE of the quota stored in 'maildirsize', but at least now I know that the 'user' quota CAN be read by third party programs. SO: Would anyone be opposed to moving the 'domain' quota out of the qmailadmin limits file (I'm assuming it's stored there since Brian said it was) and into a separate 'domainquota' file? We could then add a line to each user's 'maildirsize' file that gives the file location of 'domainquota', and I could talk with Sam, or write a patch that allows courier-IMAP and maildrop to use the 'domainquota' file as well as the 'maildirsize' file if it exists in the 'maildirsize' file. This would instantly solve my problem with maildrop and courier not being compatible with the new domain wide quotas, AND it would make Sam more likely to accept the code since it doesn't deal with vpopmail specific files like the qmailadmin limits file. Is there ANYTHING I am still wrong about? Does the above make sense? What do you think, Bill? Thanks for having patience with me! Regards, Bill Shupp
