Re: [vchkpw] How to bypass quota
On 2006-04-14, at 0426, Olivier JUDITH wrote: I use qmail + vpopmail + courrier-imap ... and i have activated quota for each users to 100M . It work fine fine but, some users would like to be prevent when their Maildir box size is greater than quota and continue to receive their mail. Can i do that ? so what you're saying is that some users want to have no quota at all. that's almost always more of a business decision than a technical decision. the technical end is easy- change or remove the quota as needed. however, somebody with authority has to decide that it's okay to do this. and if the powers that be decide that they don't want to allow this, or that they will if the client pays more money, but the client doesn't want to pay, then the client needs to learn to not leave so much of their mail on the server. if they don't move some of their stored messages off of the server, then the quota mechanism will continue to block incoming messages when their mailbox is full. somebody with the appropriate authority needs to make a decision... the options are to raise or remove the quota for that mailbox, or tell the user to do a better job of managing their quota. -- | John M. Simpson - KG4ZOW - Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | -- | Mac OS X proves that it's easier to make UNIX | | pretty than it is to make Windows secure. | -- PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] Force Auth from all but localhost
On 2006-04-14, at 0338, Sascha Ebach wrote: how can I enforce that everybody (except localhost) has to authenticate via smtp auth. my combined patch, version 6 or newer, includes this functionality. http://qmail.jms1.net/patches/combined.shtml you can export a REQUIRE_AUTH=1 environment variable in the /service/ ___/run script to enable this for all IP addresses, and then add ,REQUIRE_AUTH=0 to the end of the appropriate line(s) in the tcpserver access control file (which is usually /etc/tcp/smtp or /etc/ tcp.smtp.) be sure to read the entire page- there are a LOT of patches rolled into the combined patch. you may find other features that you would like to use, or you may find features that you don't need. for the most part, i tried to add the patches in such a way that if you don't activate them (by creating a certain file or a certain environment variable) qmail will act as closely as possible to the way djb's original qmail programs act. and if you have any questions about it, feel free to ask- either use this list, or use the qmailrocks.org mailing list (but not the qmailrocks.org install directions... there are easier ways to beat your head against the wall.) -- | John M. Simpson - KG4ZOW - Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | -- | Mac OS X proves that it's easier to make UNIX | | pretty than it is to make Windows secure. | -- PGP.sig Description: This is a digitally signed message part
[vchkpw] ONCHANGE behavior
John Simpson Robin Bowes Do you really want the onchange function to be called three times on an add_domain operation, and two times on an add_user operation? I find it problematic that you are notified of the mod_user before the add_user, and personally would prefer only one call per operation. (That means you have to assume the postmaster user was added when you add a domain.) At the very least I would like to block the mod_user notification in an add_user operation. I think it is a good idea to block the add_user [EMAIL PROTECTED] operation on an add_domain too. I'll handle coding it if it is ok with you two. Finally, is there anything I should add to the readme file? README.onchange --- If --enable-onchange-script is added to the ./configure command many vpopmail commands, and calls into the library will call the script ~vpopmail/etc/onchange when they have completed execution. When the script is called, it will be passed the following values on the command line to indicate what was changed. add_user[EMAIL PROTECTED] del_user mod_user add_domain domain del_domain add_alias_domain valias_insert [EMAIL PROTECTED] valias_remove valias_delete This is based on the onchange.2 patch by John Simpson. Rick Widmer changed ./configure.in so the onchange code is only compiled when specified at ./configure time. --- Is there anything else I should do with 5.5 before I try to release it? Rick
[vchkpw] Re: ONCHANGE behavior
Rick Widmer wrote: John Simpson Robin Bowes Do you really want the onchange function to be called three times on an add_domain operation, and two times on an add_user operation? I find it problematic that you are notified of the mod_user before the add_user, and personally would prefer only one call per operation. (That means you have to assume the postmaster user was added when you add a domain.) At the very least I would like to block the mod_user notification in an add_user operation. I think it is a good idea to block the add_user [EMAIL PROTECTED] operation on an add_domain too. I'll handle coding it if it is ok with you two. Rick, I must admit I've not actually looked at John's code. However, my thoughts (based on your comments) are as follows: add_user should be called as well as add_domain when a new domain is created - these are separate actions that happen to both occur when you first create a domain. I don't really have a problem with both mod_user and add_user triggering in an add_user operation. What happens to cause mod_user to trigger as well as add_user? I guess the user is added and then modified - the password is set, perhaps? BUt I would need to look at the code to see what actually happens. Bottom line; If the user is being added and then modified then it makes sense to have both hooks triggered. Why do you want to change this? What is the problem you are trying to solve? README.onchange --- If --enable-onchange-script is added to the ./configure command many vpopmail commands, and calls into the library will call the script ~vpopmail/etc/onchange when they have completed execution. When the script is called, it will be passed the following values on the command line to indicate what was changed. add_user[EMAIL PROTECTED] del_user mod_user add_domaindomain del_domain add_alias_domain Does there need to be a del_alias_domin hook? How about a mod_domain, or mod_alias_domain (not sure if these two would be necessary)? valias_insert[EMAIL PROTECTED] valias_remove valias_delete What's the difference between valias_remove and valias_delete ? Does there need to be a valias_mod? Why is this not add_valias, del_valias? (to make it the same as the user/domain hooks) ? R.
Re: [vchkpw] Force Auth from all but localhost
On 2006-04-15, at 1003, Remo Mattei wrote: John Simpson wrote: On 2006-04-14, at 0338, Sascha Ebach wrote: how can I enforce that everybody (except localhost) has to authenticate via smtp auth. my combined patch, version 6 or newer, includes this functionality. http://qmail.jms1.net/patches/combined.shtml I wonder if you have a similar patch like chkuser in your combined patch. i wonder why you haven't read the web page to see if it's in there or not. -- | John M. Simpson - KG4ZOW - Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | -- | Mac OS X proves that it's easier to make UNIX | | pretty than it is to make Windows secure. | -- PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] Re: ONCHANGE behavior
Robin Bowes wrote: Rick Widmer wrote: John Simpson Robin Bowes Do you really want the onchange function to be called three times on an add_domain operation, and two times on an add_user operation? I find it problematic that you are notified of the mod_user before the add_user, and personally would prefer only one call per operation. (That means you have to assume the postmaster user was added when you add a domain.) At the very least I would like to block the mod_user notification in an add_user operation. I think it is a good idea to block the add_user [EMAIL PROTECTED] operation on an add_domain too. I'll handle coding it if it is ok with you two. Rick, I must admit I've not actually looked at John's code. However, my thoughts (based on your comments) are as follows: add_user should be called as well as add_domain when a new domain is created - these are separate actions that happen to both occur when you first create a domain. I can see that, on the other hand you already know when you write your response to an add_domain that the postmaster user was created. Do you really need to exec the script a second time to handle the postmaster as a separate operation? There is quite a bit of overhead with PHP and Perl starting up the script. (I'll be using PHP.) I don't really have a problem with both mod_user and add_user triggering in an add_user operation. What happens to cause mod_user to trigger as well as add_user? I believe adduser() calls moduser() to store the data about the user in the vpasswd file, or the database. I guess the user is added and then modified - the password is set, perhaps? BUt I would need to look at the code to see what actually happens. Bottom line; If the user is being added and then modified then it makes sense to have both hooks triggered. Actually according to the calls of the script the user was modded before it was added. Why do you want to change this? Because it seems wasteful to me to call the script three times just to add a domain, or twice to add a user. In the case of the user the mod_user comes before the add_user, so the user data is not completely updated when the script is called for mod_user. By the time the script is called for add_user the mod_user data is available so you can look it up and act accordingly. Specifically when the initial mod_user exec happens the quota, sqwebmail_pass file, and last_auth processing has not been done yet. (Possibly more, I did not trace out the vauth_adduser() call that actually does the work.) What is the problem you are trying to solve? No real problem, just something I consider wasteful of resources. For example, if all you are doing is rebuilding a validrcptto database currently you are doing it three times every time you add a domain. Two of them are instantly thrown away as soon as they finish. add_domaindomain del_domain add_alias_domain Does there need to be a del_alias_domin hook? How about a mod_domain, or mod_alias_domain (not sure if these two would be necessary)? Delete of an alias is done with del_domain, naming the alias. Mod_domain might be valuable. There may be a problem here since you can't tell from the script if it is an alias or a whole domain. Maybe it should name the parent domain if an alias was deleted, or name the aliases if the parent is deleted. valias_insert[EMAIL PROTECTED] valias_remove valias_delete What's the difference between valias_remove and valias_delete ? Assume an alias [EMAIL PROTECTED] that forwards to [EMAIL PROTECTED] and [EMAIL PROTECTED] valias_remove [EMAIL PROTECTED] would indicate that the alias no longer forwards to [EMAIL PROTECTED] valias_delete [EMAIL PROTECTED] would indicate the alias was removed entirely. Does there need to be a valias_mod? There is no such thing, just combinations of the above. Why is this not add_valias, del_valias? (to make it the same as the user/domain hooks) ? I don't know. John? Rick
Re: [vchkpw] ONCHANGE behavior
On 2006-04-15, at 1756, Rick Widmer wrote: Do you really want the onchange function to be called three times on an add_domain operation, and two times on an add_user operation? I find it problematic that you are notified of the mod_user before the add_user, and personally would prefer only one call per operation. (That means you have to assume the postmaster user was added when you add a domain.) i noticed that in my testing... once is to add the domain itself, once to add the postmaster mailbox, and once to set the quota for the postmaster mailbox. (vauth_setquota calls vauth_setpw, and i wanted vauth_setpw to trigger the notify because i'm building an auth.cdb of mailbox names and passwords, and need to rebuild whenever a password changes.) maybe vauth_setpw() could be modified to only call call_onchange() if the PASSWORD field was changed... but there may be future uses of the onchange mechanism where people may want to track quota changes as well, so i'm not convinced that's a good idea either. i'm thinking it would limit the future flexibility of the onchange mechanism if we remove this notification, and i'm all about maximum flexibility. and if this means that adding a domain results in the onchange script being run three times, that tells me that the onchange script needs to do little more than send a signal somewhere, and some other process needs to do the real work so that whatever program called the vpopmail library functions can get back to doing its thing. At the very least I would like to block the mod_user notification in an add_user operation. I think it is a good idea to block the add_user [EMAIL PROTECTED] operation on an add_domain too. I'll handle coding it if it is ok with you two. honestly, what i'm doing with the onchange script is simple: echo $* /tmp/update-qmail where /tmp/update-qmail is a named pipe. i have a daemontools service which waits for input on this pipe, and does its thing (checks the timestamps of various files and runs qmail-newu if needed, runs qmail- newmrh if needed, sends a HUP to qmail-send if needed, rebuilds validrcptto.cdb if needed, and now rebuilds auth.cdb if needed) after a five second delay. this means that unless something is really slow on the system, the first notification will cause the work to be done after the third notification has been sent. which means that whatever smarts are needed in order to prevent a certain piece of work from being done twice, would need to be done within the onchange script itself, or within whatever process the script sends its signal to. i'm currently doing this using the five- second delay before starting work, and then reading and ignoring any pending data on the pipe when that first work unit is done. however, i plan to teach the service to recognize the patterns, so that if it sees an add_domain xyz, it will ignore any add_user [EMAIL PROTECTED] and mod_user [EMAIL PROTECTED] messages which arrive less than ten seconds later. in any event, i think that the add_user notification for the postmaster mailbox itself needs to stay there. i have seen some really strange situations... many times i've seen people delete postmaster mailboxes after using vusermod to give some other mailbox domain-admin rights, under the theory that by using a different name for the postmaster account, they are preventing a dictionary attack on the postmaster password from succeeding (which is the same idea as renaming the Administrator account on a windoze machine, and done for the same reasons, usually by windoze administrators who are learning about security through a trial by fire.) and who knows, at some point in the future, the idea may catch on and we may want to allow a way to create domains with the first mailbox (which has domain-admin rights) having a name other than postmaster. writing onchange scripts which assume that every add_domain involves a mailbox named postmaster makes this kind of change harder to do. having two onchange calls, one for the domain and one for the mailbox, makes it possible to write this kind of change without having to worry about peoples' existing onchange scripts- just have the one for the domain ONLY do the activities needed to create a domain in whatever external system you are updating, and have the one for the mailbox ONLY do the activities needed for creating a new mailbox. i'm all about maintaining as much flexibility as possible. my recommendation is to leave it the way it is. Finally, is there anything I should add to the readme file? ... This is based on the onchange.2 patch by John Simpson. Rick Widmer changed ./configure.in so the onchange code is only compiled when specified at ./configure time. -- - Is there anything else I should do with 5.5 before I try to
Re: [vchkpw] Re: ONCHANGE behavior
On 2006-04-15, at 1917, Rick Widmer wrote: Robin Bowes wrote: I must admit I've not actually looked at John's code. However, my thoughts (based on your comments) are as follows: add_user should be called as well as add_domain when a new domain is created - these are separate actions that happen to both occur when you first create a domain. I can see that, on the other hand you already know when you write your response to an add_domain that the postmaster user was created. Do you really need to exec the script a second time to handle the postmaster as a separate operation? There is quite a bit of overhead with PHP and Perl starting up the script. (I'll be using PHP.) for now, you know that a postmaster mailbox was created. this may change in the future, if the idea of using a name other than postmaster catches on (as it is starting to, especially among windoze admins who are just learning that it's a good idea to change their Administrator accounts to have some other name.) i think it makes sense for the add_user notification to be separate from the add_domain notification. I don't really have a problem with both mod_user and add_user triggering in an add_user operation. What happens to cause mod_user to trigger as well as add_user? I believe adduser() calls moduser() to store the data about the user in the vpasswd file, or the database. i just walked the code- after vadduser() actually creates the mailbox, it sets a quota, which calls vauth_setquota(), which calls vauth_setpw() to re-write the vauth entry with the shell field (which contains the quota) changed. they're showing up out of order because i'm calling call_onchange() at the very end of vadduser(), when it should probably happen right after the call to vauth_adduser() and before the call to vauth_setquota(). rick, i've just updated the patch so that it happens in the correct order. there is now an onchange.3 patch, and for your use, there is an onchange.2-3 patch which just moves the code. the direct URL for the upgrade patch is... http://qmail.jms1.net/patches/vpopmail-5.4.15-onchange.2-3.patch Why do you want to change this? Because it seems wasteful to me to call the script three times just to add a domain, or twice to add a user. In the case of the user the mod_user comes before the add_user, so the user data is not completely updated when the script is called for mod_user. By the time the script is called for add_user the mod_user data is available so you can look it up and act accordingly. Specifically when the initial mod_user exec happens the quota, sqwebmail_pass file, and last_auth processing has not been done yet. (Possibly more, I did not trace out the vauth_adduser() call that actually does the work.) i can understand this. however, since the call_onchange() function waits for the script to complete, it is up to you as the author of an onchange script to make it run as quickly as possible. as i explained before, my onchange script sends its command line arguments to a named pipe and exits, and the service which is listening to the other end of that pipe does all of the work. for me, the trick is dealing with the fact that input may arrive on the pipe at any time- including three notifications within the space of a second. i know that (for my purposes) if an add_domain xyz message arrives, for example, that i can wait 10 seconds before doing anything (to give the vpopmail program time to finish and send any other messages), and that any add_mailbox [EMAIL PROTECTED] or mod_user [EMAIL PROTECTED] messages which arrive less than 5 seconds after i'm done can be safely ignored. What is the problem you are trying to solve? No real problem, just something I consider wasteful of resources. For example, if all you are doing is rebuilding a validrcptto database currently you are doing it three times every time you add a domain. Two of them are instantly thrown away as soon as they finish. actually, i'm not- but you do have a point. whoever writes an onchange script does need to worry about this issue- but i don't think it's right to give up the flexibility in order to not have to write proper onchange scripts. add_domaindomain del_domain add_alias_domain Does there need to be a del_alias_domin hook? How about a mod_domain, or mod_alias_domain (not sure if these two would be necessary)? Delete of an alias is done with del_domain, naming the alias. Mod_domain might be valuable. There may be a problem here since you can't tell from the script if it is an alias or a whole domain. Maybe it should name the parent domain if an alias was deleted, or name the aliases if the parent is deleted. or name both the alias and the real domains if an alias is deleted, as opposed to naming just the real domain if a real domain is deleted. basically, the first word after del_domain
Re: [vchkpw] ONCHANGE behavior
John Simpson wrote: On 2006-04-15, at 1756, Rick Widmer wrote: Do you really want the onchange function to be called three times on an add_domain operation, and two times on an add_user operation? I find it problematic that you are notified of the mod_user before the add_user, and personally would prefer only one call per operation. (That means you have to assume the postmaster user was added when you add a domain.) i noticed that in my testing... once is to add the domain itself, once to add the postmaster mailbox, and once to set the quota for the postmaster mailbox. (vauth_setquota calls vauth_setpw, and i wanted vauth_setpw to trigger the notify because i'm building an auth.cdb of mailbox names and passwords, and need to rebuild whenever a password changes.) maybe vauth_setpw() could be modified to only call call_onchange() if the PASSWORD field was changed... but there may be future uses of the onchange mechanism where people may want to track quota changes as well, so i'm not convinced that's a good idea either. i'm thinking it would limit the future flexibility of the onchange mechanism if we remove this notification, and i'm all about maximum flexibility. My intent is to make it so adding a domain calls the script once, reporting that the domain was added. Adding a user calls the script once, reporting that the user was added. Modifying a user or domain calls the script once, reporting the modification. I agree we want to know when a modify command is executed by the user, we just don't need to know if it happened as part of adding a user or domain. honestly, what i'm doing with the onchange script is simple: echo $* /tmp/update-qmail where /tmp/update-qmail is a named pipe. i have a daemontools service which waits for input on this pipe, and does its thing (checks the timestamps of various files and runs qmail-newu if needed, runs qmail- newmrh if needed, sends a HUP to qmail-send if needed, rebuilds validrcptto.cdb if needed, and now rebuilds auth.cdb if needed) after a five second delay. this means that unless something is really slow on the system, the first notification will cause the work to be done after the third notification has been sent. Are you going to document that somewhere? Its a cool idea. I'm just going to write a script that tweaks the file structure, sends a pair of welcome messages and writes a log entry. Unless your structure is well documented and easy to find, I bet that's what most people end up doing. It really doesn't matter to you if you get one or three calls when someone runs vadddomain. Right? which means that whatever smarts are needed in order to prevent a certain piece of work from being done twice, would need to be done within the onchange script itself, or within whatever process the script sends its signal to. That is exactly what I want to prevent. It feels like a support nightmare to me. Its not that hard to make vpopmail only make one call to the script per transaction. i have seen some really strange situations... many times i've seen people delete postmaster mailboxes after using vusermod to give some other mailbox domain-admin rights, I see no problem with that. You will get: add-domain example.com - when they run vadddomain add-user [EMAIL PROTECTED] - when they run vadduser mod-user [EMAIL PROTECTED] - when they run vmoduser del-user [EMAIL PROTECTED] - when they run vdeluser instead of add-domain example.com mod-user [EMAIL PROTECTED] * add-user [EMAIL PROTECTED] * - when they run vadddomain mod-user [EMAIL PROTECTED] * add-user [EMAIL PROTECTED] - when they run vadduser mod-user [EMAIL PROTECTED] - when they run vmoduser del-user [EMAIL PROTECTED] - when they run vdeluser Can you keep a straight face and tell me the * lines are anything but noise? :) under the theory that by using a different name for the postmaster account, they are preventing a dictionary attack on the postmaster password from succeeding (which is the same idea as renaming the Administrator account on a windoze machine, and done for the same reasons, usually by windoze administrators who are learning about security through a trial by fire.) I understand the theory, but the you are supposed to have a postmaster account to receive administrative traffic. On the other hand I must admit mine only gets cleaned out every few months. and who knows, at some point in the future, the idea may catch on and we may want to allow a way to create domains with the first mailbox (which has domain-admin rights) having a name other than postmaster. Yes, but we shouldn't be making it too easy for people to violate the RFC's. The guys over on the qmail mailing list are mad enough at us over the way we use users/assign. I don't think you will find any developer support for not creating the postmaster user automatically. writing
Re: [vchkpw] ONCHANGE behavior
Sorry, when I got your last message I missed one point... Rick Widmer wrote: John Simpson wrote: (1) please include the URL http://qmail.jms1.net/patches/ vpopmail.shtml in the file, so that poeple can easily find the documentation i have written (and will be maintaining) for it. i'll be watching this mailing list for any problems which people may have with it, and if any problems seem to show up on a regular basis, i will write a FAQ for those problems, either on this page, or as a new page linked from this one. I will certainly add the URL to the README file, but I believe once it becomes part of vpopmail it needs to be fully documented within vpopmail. Rick
Re: [vchkpw] Re: ONCHANGE behavior
John Simpson wrote: i can understand this. however, since the call_onchange() function waits for the script to complete, it is up to you as the author of an onchange script to make it run as quickly as possible. as i explained before, my onchange script sends its command line arguments to a named pipe and exits, and the service which is listening to the other end of that pipe does all of the work. I'd rather wait on the entire process to finish so I know there were no errors in the operation before I report the job done. Oh well, it works just fine both ways. Good job! for me, the trick is dealing with the fact that input may arrive on the pipe at any time- including three notifications within the space of a second. i know that (for my purposes) if an add_domain xyz message arrives, for example, that i can wait 10 seconds before doing anything (to give the vpopmail program time to finish and send any other messages), and that any add_mailbox [EMAIL PROTECTED] or mod_user [EMAIL PROTECTED] messages which arrive less than 5 seconds after i'm done can be safely ignored. It seems to me it is much easier to eliminate the noise at the source. if the onchange script needs to know whether the user's request affected a real or alias domain, simply look to see if there IS another domain listed afterward- if so, the first one was an alias and the second one is the real domain that the alias pointed to. is this something that needs to be in there? if so, i'll write it in. I don't see any value in reporting a delete operation after the fact, other than to log it. On the other hand it might be a good idea to move the script before the delete. That would give you a chance to take a snapshot of the resource usage right before delete, or maybe make a backup. I do think it is a good idea to name the parent domain if you delete an alias domain, even if I don't know how someone would use it today. If nothing else it will make my log entries look nicer. If you've already got it worked out, go ahead and send me a patch. If not you've described it well enough, it will be easy enough to do. Why is this not add_valias, del_valias? (to make it the same as the user/domain hooks) ? I don't know. John? the idea was that the names were are all the same as vpopmaild commands. however, these functions don't exist in vpopmaild, so i used the names of the actual functions within the vpopmail source code. Sounds reasonable to me. I believe the reason they don't appear in the daemon yet is because the cdb back end doesn't support them. It gets worse, the way a cdb file and a database handle the data are quite different and we need to add an order field to the database to make it able to store entries in a fixed order and add functions to the cdb back end to support the valias calls. someday... would it be better to use the vpopmail function names for all of the notifications, so that they are all consistent? if so, now is the time to make the decision, since nobody (as far as i know) has written any onchange scripts which would look for specific strings. I don't really care. Robin - what do you think the names should be? As far as I'm concerned, all I need is a complete list in front of me when I sit down to write the script. Rick -- KD7VKZ
Re: [vchkpw] Re: ONCHANGE behavior
On Apr 15, 2006, at 4:17 PM, Rick Widmer wrote: I believe adduser() calls moduser() to store the data about the user in the vpasswd file, or the database. My recollection is that it calls moduser to set the quota. The original adduser() API in the backends didn't allow for setting a quota when added. It should be possible to rectify this by adding a new API to each backend to add a user with a quota. Initially, it could just be a stub that does adduser(); moduser();. We would want to fix it to add the user in one shot, but that would require code customized to each back end. -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/
[vchkpw] ONCHANGE in CVS
I've just committed John Simpson's onchange patch. I've added the ability to enable it with --enable-onchange-script, and a file README.onchange. I've also suppressed a few calls to the script that I considered redundant. It should be available in anonymous CVS within a couple of hours. Tom: Is there any reason I can't put this on a live server. It is based on 5.4.16, so are there any major problems left in that? Rick
Re: [vchkpw] ONCHANGE behavior
On 2006-04-15, at 2152, Rick Widmer wrote: Rick Widmer wrote: John Simpson wrote: (1) please include the URL http://qmail.jms1.net/patches/ vpopmail.shtml in the file, so that poeple can easily find the documentation i have written (and will be maintaining) for it. i'll be watching this mailing list for any problems which people may have with it, and if any problems seem to show up on a regular basis, i will write a FAQ for those problems, either on this page, or as a new page linked from this one. I will certainly add the URL to the README file, but I believe once it becomes part of vpopmail it needs to be fully documented within vpopmail. i agree, it certainly needs to be documented there- especially once it becomes part of a non-beta version. however, until then (and afterwards) i want to make sure that everybody using the patch is aware of where it started, and can avail themselves of whatever other documentation i may add to it in the future. i can see this not being necessary at some point in the future, but i would like my URL to stay in there because not everybody in the world is going to upgrade right away, and i plan to continue to offer the patches for the benefit of people who may not want to fully upgrade to a newer version of vpopmail. (i know, who would be that crazy, but remember- a very high percentage of my site's visitors find me because of qmailrocks...) -- | John M. Simpson - KG4ZOW - Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | -- | Mac OS X proves that it's easier to make UNIX | | pretty than it is to make Windows secure. | -- PGP.sig Description: This is a digitally signed message part
