Re: [vchkpw] Further thoughts on my localrelay patch
On 2007-01-02, at 1018, Joshua Megerman wrote: So we now have the question: What is the best way to proceed. I think that I would like to see the following changes made to the whole "roaming users" functionality in Vpopmail: 1) Document that the auth-before-smtp RELAYCLIENT="" functionality is deprecated, and schedule it for removal 6-12 months down the line. if i'm reading this right, you're proposing that the entire "pop before smtp" functionality go away? so that nothing other than POP3 happens when somebody logs into the POP3 service, and there would be no dynamic changes to the access control list of the SMTP service at all? and vpopmail's documentation would explicitly tell people "thou shalt use SMTP AUTH" from now on? awesome. i just became one of your biggest fans. and for the time being, i think having an access control file attached to the POP3/IMAP services, which uses variables to tell when a given IP should trigger the update process, makes a lot more sense than trying to build a bunch of logic into vchkpw.c... just have it check for the presence and/or absence of environment variables, and let the external scripting control what does and does not go into that file. for example, the script could read the static smtpd access control file and find any IP blocks with RELAYCLIENT defined on them- and then copy those blocks to the POP3/IMAP access control file... and then the logic in vchkpw.c would bypass any updating if it saw a RELAYCLIENT variable in the environment. 2) Hijack the --enable-roaming-users config line to allow a different default set of tcpserver flags to be added. For now, the default would be '--enable-roaming-users="RELAYCLIENT=\"\",RBLSMTPD=\"\""', but once #1 is finalized the RELAYCLIENT part would be removed. there does need to be a way to set what gets added to the smtpd access control file for dynamic entries. i'm not sure that highjacking an existing option is the right way to do it, nor do i think it should be a configure option. i think it makes more sense to let it be configured at run time- something like "read the first line of a ~vpopmail/etc/_ file" and use that. also, you would want to add something other than just RELAYCLIENT to your dynamic lines, maybe something like "VPOPMAIL_DYNAMIC=\"1\"", so that the script which reads the smtpd access control list would recognize that as an entry which was dynamically added, and ignore it. but the overall idea is to minimize the amount of code you're changing in vpopmail itself, and make the whole "update the cdb file" process an externally driven thing. (yes, i'm actually thinking of the same "separation of functions" idea that i used when wrote the "onchange" patch- when the time comes it checks for the existence of a script, and if so, it runs it. anything beyond that is up to the script, and therefore requires no further changes to vpopmail itself.) This will preserve the ability to run vpopmail in exactly the same manner as it currently is, but move in the direction of eliminating auth-before-smtp relaying as the default method AND improving the ability to use auth-before-smtp for other access control methods. Plus, it gives people options without requiring them to be set if they don't use them. Thoughts? actually, yes... i just had an even better idea, the ultimate in flexibility. just as my "onchange" patch calls a ~vpopmail/etc/onchange script whenever something changes about the accounts, what about calling a ~vpopmail/etc/onauth script whenever somebody authenticates, and just leaving vpopmail's direct involvement at that? look at the 5.4.18 source code for the call_onchange() function (at the end of vpopmail.c), see how it works, and how it gets called from various places in the code. then consider writing a call_onauth() function similar to that, and then calling it from the appropriate place(s?) in vchkpw.c. then the whole process of modifying the smtp server's access control, and the logic behind when you do and don't update the list, all becomes part of the external scripting. this "onauth" script could also be used to drive a situation where somebody wants to log authentications to some other storage media, like a database- or to update a "last auth" timer in a database or LDAP server, or for any number of other purposes. then, you would write some kind of external script to manage the whole process of building the smtp access control file. that scripting could do whatever checking of static entries you like, and you can play with different scenarios in terms of making it work, without having to do any further patches to vpopmail. the only thing to keep in mind is that the "onauth" script itself needs to run as quickly as possible, because whatever service the user is logging into, is waiting for it to finish. this is why my own "onchange" script
Re: [vchkpw] Further thoughts on my localrelay patch
> On 2007-01-02, at 1018, Joshua Megerman wrote: >> >> So we now have the question: What is the best way to proceed. I >> think >> that I would like to see the following changes made to the whole >> "roaming >> users" functionality in Vpopmail: >> >> 1) Document that the auth-before-smtp RELAYCLIENT="" functionality is >> deprecated, and schedule it for removal 6-12 months down the line. > > if i'm reading this right, you're proposing that the entire "pop > before smtp" functionality go away? so that nothing other than POP3 > happens when somebody logs into the POP3 service, and there would be > no dynamic changes to the access control list of the SMTP service at > all? and vpopmail's documentation would explicitly tell people "thou > shalt use SMTP AUTH" from now on? > > awesome. i just became one of your biggest fans. > Whoa... I wasn't expecting that... Just don't send me flowers or anything, OK? :) > and for the time being, i think having an access control file > attached to the POP3/IMAP services, which uses variables to tell when > a given IP should trigger the update process, makes a lot more sense > than trying to build a bunch of logic into vchkpw.c... just have it > check for the presence and/or absence of environment variables, and > let the external scripting control what does and does not go into > that file. > OK, I think I'm seeing where you're going with this, and while it'll take a little design work (not to mention some help with different backends - I only use MySQL right now), I'm game. > for example, the script could read the static smtpd access control > file and find any IP blocks with RELAYCLIENT defined on them- and > then copy those blocks to the POP3/IMAP access control file... and > then the logic in vchkpw.c would bypass any updating if it saw a > RELAYCLIENT variable in the environment. > Maybe - we'll see what works out the best after I do a detailed design on it. >> 2) Hijack the --enable-roaming-users config line to allow a different >> default set of tcpserver flags to be added. For now, the default >> would be >> '--enable-roaming-users="RELAYCLIENT=\"\",RBLSMTPD=\"\""', but once >> #1 is >> finalized the RELAYCLIENT part would be removed. > > there does need to be a way to set what gets added to the smtpd > access control file for dynamic entries. i'm not sure that > highjacking an existing option is the right way to do it, nor do i > think it should be a configure option. i think it makes more sense to > let it be configured at run time- something like "read the first line > of a ~vpopmail/etc/_ file" and use that. > Well, I was thinking that a simple way to do it under the current struction was to have --enable-roaming-users="XXX" set the default, compile-time directive, and then be able to override it at runtime (thus keeping the current behavior without any changes). But forcing runtime configuration works too, as long as it's well documented . > also, you would want to add something other than just RELAYCLIENT to > your dynamic lines, maybe something like "VPOPMAIL_DYNAMIC=\"1\"", so > that the script which reads the smtpd access control list would > recognize that as an entry which was dynamically added, and ignore it. > > but the overall idea is to minimize the amount of code you're > changing in vpopmail itself, and make the whole "update the cdb file" > process an externally driven thing. (yes, i'm actually thinking of > the same "separation of functions" idea that i used when wrote the > "onchange" patch- when the time comes it checks for the existence of > a script, and if so, it runs it. anything beyond that is up to the > script, and therefore requires no further changes to vpopmail itself.) > If we're taking the info out of vchkpw and moving it into an external process, we can design it right from the ground up. This may involve redesigning the relay table to add more info, or have some additional tables to do lookups in, but I'm already starting to get some ideas... >> This will preserve the ability to run vpopmail in exactly the same >> manner >> as it currently is, but move in the direction of eliminating >> auth-before-smtp relaying as the default method AND improving the >> ability >> to use auth-before-smtp for other access control methods. Plus, it >> gives >> people options without requiring them to be set if they don't use >> them. >> >> Thoughts? > > actually, yes... i just had an even better idea, the ultimate in > flexibility. > > just as my "onchange" patch calls a ~vpopmail/etc/onchange script > whenever something changes about the accounts, what about calling a > ~vpopmail/etc/onauth script whenever somebody authenticates, and just > leaving vpopmail's direct involvement at that? > Clean, simple, flexible. I like it. :) > look at the 5.4.18 source code for the call_onchange() function (at > the end of vpopmail.c), see how it works, and how it gets called from > various places in the code. then consider writing a call_onaut
Re: [vchkpw] Further thoughts on my localrelay patch
Josh just as curiosity what will they mega patch for qmail include? Thanks, Remo Joshua Megerman wrote: > Whoa... I wasn't expecting that... Just don't send me flowers or > anything, OK? :) > > OK, I think I'm seeing where you're going with this, and while it'll take > a little design work (not to mention some help with different backends - I > only use MySQL right now), I'm game. > > Maybe - we'll see what works out the best after I do a detailed design on it. > > Well, I was thinking that a simple way to do it under the current > struction was to have --enable-roaming-users="XXX" set the default, > compile-time directive, and then be able to override it at runtime (thus > keeping the current behavior without any changes). But forcing runtime > configuration works too, as long as it's well documented . > > If we're taking the info out of vchkpw and moving it into an external > process, we can design it right from the ground up. This may involve > redesigning the relay table to add more info, or have some additional > tables to do lookups in, but I'm already starting to get some ideas... > > Clean, simple, flexible. I like it. :) > > Will do (once it's out :)) - I'm a little busy working on a couple of > other things, like releasing my Uber-Mega-qmail patch set (the patches are > done, but documenting them takes time... :), but I'll add this to the > queue. Since the patch isn't going into 5.4.18 anyway, there's time. > > By default, vpopmail logs the last auth for most backends. This could > handle that as well. > > *nod* > > Alternatively, vpopmail could just write to the pipe itself, but the > onauth script is a cleaner method. Basically, I'd send 4 tokens to the > service: user, domain, IP, timestamp. It can handle the rest. > > It should be able to run as vpopmail, since the tcp.smtp.cdb file is owned > by vpopmail, and that's what gets used by qmail-smtpd. vchkpw runs as > vpopmail, and it handles it all now, so I don't see a need for root access > here. > > Agreed. And it makes alternative development/hooks easier too. > > I'd appreciate the help on the daemon, although just giving me the sampe > code of your daemon would probably be good enough. I have a very long > history of looking at other peoples' code and taking just the parts I need > for whatever I happen to be working on - it's how I learned C in the first > place 15 years ago... :) > > Josh
Re: [vchkpw] Further thoughts on my localrelay patch
> Josh just as curiosity what will they mega patch for qmail include? > Funny you should ask... >> Will do (once it's out :)) - I'm a little busy working on a couple of >> other things, like releasing my Uber-Mega-qmail patch set (the patches >> are >> done, but documenting them takes time... :), but I'll add this to the ^^^ I'm writing up the real documentation now - I have my patchlog, but it's hopelessly inadequate to provide to outside persons. I'll post both here and to the qmail list when I finish the docs/setup, which will hopefully be sometime this week. Until then, I ask for your patience :) Josh -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] Further thoughts on my localrelay patch
On 2007-01-03, at 1436, Joshua Megerman wrote: look at the 5.4.18 source code for the call_onchange() function (at the end of vpopmail.c), see how it works, and how it gets called from various places in the code. then consider writing a call_onauth() function similar to that, and then calling it from the appropriate place(s?) in vchkpw.c. Will do (once it's out :)) it's out. i'm running it now. wait- rick, did you forget to announce it on this list, or is it not for general consumption yet? i downloaded it from sourceforge and it works fine, including the onchange stuff. - I'm a little busy working on a couple of other things, like releasing my Uber-Mega-qmail patch set (the patches are done, but documenting them takes time... :), but I'll add this to the queue. Since the patch isn't going into 5.4.18 anyway, there's time. so you've got a qmail mega-patch as well? i'm starting to wonder who DOESN'T have one anymore... mine: http://qmail.jms1.net/patches/combined-details.shtml the only thing to keep in mind is that the "onauth" script itself needs to run as quickly as possible, because whatever service the user is logging into, is waiting for it to finish. this is why my own "onchange" script simply sends its command line arguments to a named pipe, where an "update-qmail" service is waiting for the data... that service actually does all of the work while the script exits and vpopmail lets the user get back to what they were doing. Alternatively, vpopmail could just write to the pipe itself, but the onauth script is a cleaner method. Basically, I'd send 4 tokens to the service: user, domain, IP, timestamp. It can handle the rest. if you want to split user and domain apart like that, sure... my preference would be to keep them together, as one opaque item- that way if you have a hybrid mixed system of vpopmail and system accounts, the API doesn't need to change to support "no such thing as a domain"... and if you do need them separately, it's easy enough to split the one datum on the "@" character. as for vpopmail writing the pipe directly... that was suggested for the onchange patch as well- and shot down very quickly, by myself and by tom. the argument is/was that most people understand how shell scripts work, but very few people understand named pipes- and while anybody can write a shell script, not everybody will be doing anything complex enough to need to involve pipes. some people may do things with unix sockets, TCP or UDP sockets, semaphores, mutices (plural of "mutex"), or any number of other things... running a shell script leaves people with the ability to choose their own IPC mechanism, rather than forcing them to run a named pipe watcher service. it's all about flexibility. and then you could write a dedicated service, to run under daemontools, which would track which IP's are authorized and their timeout values, and would rebuild the smtp access control file whenever it needs to be changed... it could even run as root if needed (which it probably would, if it's going to be updating the smtp service's access control file.) It should be able to run as vpopmail, since the tcp.smtp.cdb file is owned by vpopmail, and that's what gets used by qmail-smtpd. vchkpw runs as vpopmail, and it handles it all now, so I don't see a need for root access here. not everybody runs their entire mail system as the vpopmail user (in fact i don't run ANY of it as the vpopmail user- for clients who use vchkpw to handle SMTP AUTH, i have the vchkpw binary setuid/setgid to the vpopmail user, but that's it.) and since other programs (qmailadmin, vpopmaild, or some as-yet- unknown program in the future) might also end up calling this function, i think it's safer to not assume anything about what userid will be running the "onauth" script itself. if the script is signalling a service, obviously run the service as the userid which makes the most sense for the situation- but the "onauth" script itself needs to be executable by any userid on the system. I'd appreciate the help on the daemon, although just giving me the sampe code of your daemon would probably be good enough. I have a very long history of looking at other peoples' code and taking just the parts I need for whatever I happen to be working on - it's how I learned C in the first place 15 years ago... :) it's actually written in perl, believe it or not... but it should translate to C easily enough, if you're so inclined. i can see keeping a hash in memory, the IP pointing to an expire time, and every time an IP authenticates, the expire time is replaced with "now plus 30 minutes"... it would periodically build a new list, leaving out any expired IPs, and if the new list of IPs (not their timeout values) is different from the old list, it would write out new files and call "tcprules" as needed. part of writing out new files would be wri
Re: [vchkpw] Further thoughts on my localrelay patch
On Jan 3, 2007, at 10:48 AM, John Simpson wrote: there does need to be a way to set what gets added to the smtpd access control file for dynamic entries. i'm not sure that highjacking an existing option is the right way to do it, nor do i think it should be a configure option. i think it makes more sense to let it be configured at run time- something like "read the first line of a ~vpopmail/etc/_ file" and use that. I like the idea of an environment variable -- no overhead from reading it from a file every time vchkpw runs. You can also customize it per connection if necessary. -- Tom Collins - [EMAIL PROTECTED] Vpopmail - virtual domains for qmail: http://vpopmail.sf.net/ QmailAdmin - web interface for Vpopmail: http://qmailadmin.sf.net/
Re: [vchkpw] Further thoughts on my localrelay patch
> it's out. i'm running it now. > > wait- rick, did you forget to announce it on this list, or is it not > for general consumption yet? i downloaded it from sourceforge and it > works fine, including the onchange stuff. > Huh - so it is. Posted 12/30/06. Maybe I misunderstood the last message about what patches would be in it, but I definitely don't remember an "official" announcement. I'll have to grab it and check it out. >> - I'm a little busy working on a couple of >> other things, like releasing my Uber-Mega-qmail patch set (the >> patches are >> done, but documenting them takes time... :), but I'll add this to the >> queue. Since the patch isn't going into 5.4.18 anyway, there's time. > > so you've got a qmail mega-patch as well? i'm starting to wonder who > DOESN'T have one anymore... > > mine: http://qmail.jms1.net/patches/combined-details.shtml > I'm quite familiar with it - I've even used one of the small patches on your site (the date-localtime patch), although I'm not sure if you wrote it or not (there's no credit in the file itself, and I've seen it credited to 2 different people out there, neither of them you. But nevertheless qmail.org links the patch on your site, even if the link is stale these days...). We each have our own philosophies about what we want and how we implement it. I've also written about 25% of the patches I use, either from scratch or as updates to existing patches (since often updating to a new version of someone else's patch can require restarting the whole patch process...) >> Alternatively, vpopmail could just write to the pipe itself, but the >> onauth script is a cleaner method. Basically, I'd send 4 tokens to >> the >> service: user, domain, IP, timestamp. It can handle the rest. > > if you want to split user and domain apart like that, sure... my > preference would be to keep them together, as one opaque item- that > way if you have a hybrid mixed system of vpopmail and system > accounts, the API doesn't need to change to support "no such thing as > a domain"... and if you do need them separately, it's easy enough to > split the one datum on the "@" character. > I believe vchkpw already splits them, but I'm not sure. It's easy enough to pass them in whatever form vchkpw has them natively. > as for vpopmail writing the pipe directly... that was suggested for > the onchange patch as well- and shot down very quickly, by myself and > by tom. the argument is/was that most people understand how shell > scripts work, but very few people understand named pipes- and while > anybody can write a shell script, not everybody will be doing > anything complex enough to need to involve pipes. some people may do > things with unix sockets, TCP or UDP sockets, semaphores, mutices > (plural of "mutex"), or any number of other things... running a shell > script leaves people with the ability to choose their own IPC > mechanism, rather than forcing them to run a named pipe watcher > service. it's all about flexibility. > Makes sense - I was already leaning that way anyway. >> It should be able to run as vpopmail, since the tcp.smtp.cdb file >> is owned >> by vpopmail, and that's what gets used by qmail-smtpd. vchkpw runs as >> vpopmail, and it handles it all now, so I don't see a need for root >> access >> here. > > not everybody runs their entire mail system as the vpopmail user (in > fact i don't run ANY of it as the vpopmail user- for clients who use > vchkpw to handle SMTP AUTH, i have the vchkpw binary setuid/setgid to > the vpopmail user, but that's it.) > They don't need to - if they're using vpopmail's cdb file, it needs to be writable by vpopmail and just readable by whatever user(s) tcpserver is running as. And if the onchange script is called by vchkpw, it'll run as vpopmail since it's a child process. Now, you could choose to run the daemon as a different user for other reasons, and just give vpopmail write access to the pipe, but if you're duplicating the current onauth behavior for updating the tcp.smtp.cdb, theres no good reason not to run as vpopmail that I can see. > and since other programs (qmailadmin, vpopmaild, or some as-yet- > unknown program in the future) might also end up calling this > function, i think it's safer to not assume anything about what userid > will be running the "onauth" script itself. if the script is > signalling a service, obviously run the service as the userid which > makes the most sense for the situation- but the "onauth" script > itself needs to be executable by any userid on the system. > I'm not sure I see the onauth system being used as generically as the onchange one - I definitely see how onchange needs to be available for a variety of functions, but onauth probably is a niche function, albeit an important one... >> I'd appreciate the help on the daemon, although just giving me the >> sampe >> code of your daemon would probably be good enough. I have a very long >> history of looking at other peoples' code and t
[vchkpw] maildrop, vpopmail, and quotas
We are running vpopmail 5.4.10, qmailadmin 1.2.9, and maildrop 1.5.3 on Debian. This is one of those cross-software questions, but I'm posting to the vpopmail list because vdelivermail seems to be part of the issue. We are seeing a strange problem with maildrop and quotas. When a user gets over quota, maildrop and vdelivermail go crazy and spawn of hundreds or thousands of processes. We have qmailadmin set so that when you check the "Enable Spam" box for a user, it puts this in the .qmail file: |preline /usr/local/bin/maildrop /etc/mailfilter We use Sqwebmail as a web interface for filter setup. I was looking for a solution, and found this patch, but I'm not sure that it has anything to do with our issue. http://www.mail-archive.com/vchkpw@inter7.com/msg24317.html I don't really care if someone gets a message or two over the quota or if part of a message makes it go over quota, but I don't want thousands of processes running when someone has filters and hits a quota. Our qmail does use the chkuser patch and we use simscan. Thanks for any suggestions... Trey
Re: [vchkpw] Further thoughts on my localrelay patch
On 2007-01-03, at 1625, Joshua Megerman wrote: ... I've even used one of the small patches on your site (the date- localtime patch), although I'm not sure if you wrote it or not (there's no credit in the file itself, and I've seen it credited to 2 different people out there, neither of them you. i didn't write it. i found it floating around on the internet years ago. i wish i did know who wrote it, i owe them a beer for saving my job a little bit easier every time i've had to tear through headers over the years... But nevertheless qmail.org links the patch on your site, even if the link is stale these days...). i didn't realize qmail.org was linking to my site at all. every time i've asked russell about adding a link to one of my scripts or patches, i've basically been ignored- i figured i wasn't a member of their "good old boys club", so it wasn't worth my time to worry about it. I believe vchkpw already splits them, but I'm not sure. It's easy enough to pass them in whatever form vchkpw has them natively. vchkpw splits them internally. the checkpassword standard calls for them to be together. either way, it's a minor issue- but there may come a point in the future where a program other than vchkpw may wish to use the "onauth" mechanism when certain services authenticate (courier-authlib comes to mind) and they may not support the concept of separate mailbox id and domain name the same way that vpopmail does. i know that vchkpw RECEIVES them as one single opaque item from qmail- smtpd, qmail-popup, or any other checkpassword-compliant program. either way it's a minor issue at this point... unless you're writing the API in your head already? now i'm really interested in seeing where you take this... again, feel free to bounce questions or ideas off of me. Thanks - it's a little overwhelming to get so many kudos from established players when I'm still so new here (even if I have been dabbling for a long time). i recognize "smart" when i see it. and the fact that you've understood everything i've thrown out there, and come back with intelligent answers and counter-ideas, tells me that you're smart. that's all it is. and for the record, i don't consider myself to be "established". knowledgable, yes, but... i don't even have a real link on the qmail.org site, and i'm not in google's top ten results for "qmail" (at least i don't *think* i am... no, i'm #22.) the only reason i'm even listed as a developer for vpopmail is because i've sent in a fair number of good patches- tom invited me (yes, i'm honored) but i have yet to actually check anything into the CVS repository at all (rick has been doing that for me, since he knows how to write the "configure" script and i don't.) so don't feel overhwelmed by me... i'm just some guy who wrote a web site that a lot of people find useful, who knows how to write code, who's been building, running, and now consulting for ISPs for a long time, and who's getting tired of consulting and thinking seriously about jumping back into the full-time job market (and is willing to relocate for the right offer, hint hint anybody...) | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ <[EMAIL PROTECTED]> | | http://video.google.com/videoplay?docid=-4312730277175242198 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] maildrop, vpopmail, and quotas
Trey Nolen wrote: We are running vpopmail 5.4.10, qmailadmin 1.2.9, and maildrop 1.5.3 on Debian. This is one of those cross-software questions, but I'm posting to the vpopmail list because vdelivermail seems to be part of the issue. We are seeing a strange problem with maildrop and quotas. When a user gets over quota, maildrop and vdelivermail go crazy and spawn of hundreds or thousands of processes. We have qmailadmin set so that when you check the "Enable Spam" box for a user, it puts this in the .qmail file: |preline /usr/local/bin/maildrop /etc/mailfilter We use Sqwebmail as a web interface for filter setup. Hi, We do something similar here without a problem. Two things you don't mention though... Are you using the quota check feature of chkuser ? ie CHKUSER_MBXQUOTA="97" in tcp.smtp or as a env variable in /service/qmail-smtpd/run Have you compiled maildrop with quota support ? ie ./configure --enable-maildirquota Regards, Rick
RE: [vchkpw] maildrop, vpopmail, and quotas
> Trey Nolen wrote: > > We are running vpopmail 5.4.10, qmailadmin 1.2.9, and > maildrop 1.5.3 on > > When a > user gets over > > quota, maildrop and vdelivermail go crazy and spawn of > hundreds or thousands > > of processes.> > We do something similar here without a problem. > > Two things you don't mention though... > > Are you using the quota check feature of chkuser ? > > ie CHKUSER_MBXQUOTA="97" in tcp.smtp or as a env variable in > /service/qmail-smtpd/run > > > Have you compiled maildrop with quota support ? > > ie ./configure --enable-maildirquota > No to both questions. I will implement both of those to see if it fixes the issue. Thanks! Trey
[vchkpw] vpopmail 5.4.18 released
http://vpopmail.sf.net/ 5.4.18 - released 31-Dec-06 Release Notes: NOTE: MySQL users will have to update their database structure following the notes in the file UPGRADE. ChangeLog: 5.4.18 - released 30-Dec-06 Joshua Megerman (offsides) - SQL backend fixes - NOTE: Requires database changes. See UPGRADE for 5.4.18. [1619489] - MySQL Tablename Backquotes - Add back quotes around table names so MySQL will allow names that start with a digit. [1619491] Drew - add .qmail-extension ability to vdelivermail - mods to Delivered-To: header to support .qmail-extension John Simpson - onchange - call a script when users or domains are changed see README.onchange. - cslogin - Compact and silent login options for vpopmaild note: don't blame John for problems in this, I changed a lot to make it fit with other changes. rww Tijs Zwinkels - vmysql: add missing mysql_free_result to fix mem leak. Tom Collins - vdelivermail: Add missing loop check. - vchangepw: Minor changes to Peter's error checking. Rick Widmer (rwidmer) - Multiple changes to vpopmaild: Add rename_file command. Expert mode works in vmoduser. Commands that are not yet implemented say so. Blank input lines are not an error in vpopmaild. Separate help before and after login in vpopmaild. Allow 3 tries to login to vpopmaild. Clean up if add_user fails because of bad user data. Add termination code (.) to get_lastauth return. Number the error messages (XXX) in vpopmaild If invalid option is sent in set_limits, show warning - Add various patches from others listed below: Peter Pentchev (roamer) - Various sanity checks and minor optimizations [1573292] - Fix child handling - waitpid and sys/wait.h [1573288] - Dynamicallly allocate sortdata[] in vpopmail.c [1573287] - Include ctype.h in the PostgreSQL backend [1573284] - Set SHELL in vdelivermail before executing external programs [1573280] - Some more error checking in vchangepw [1573277] - Improve the vpopmaild documentation [1573269] - Clean cdb files in the distclean target [1573267] - Optional building as non-root [1573266] Trent Lloyd (lathiat) - Add vailas add/delete/list support to vpopmaild [1555398] - Refresh assign cache if a domain is deleted [1529744] Bill Shupp - Add user_count function to vpopmaild - Add stat_file function to vpopmaild Please note this is my first attempt at releasing software on SourceForge, so I have made it a development release. If you have any problems with this release, please report them on the [EMAIL PROTECTED] list. Thanks, Rick p.s. Extra thanks to John who reminded me that this list needs a copy too! I thought I sent it... :)
