Re: [vchkpw] vpopmail as a daemon
On Tuesday 25 February 2003 02:56, Dave Weiner wrote: > On Sunday 23 February 2003 21:56, Jesse Guardiani wrote: > > OK. Again, I admit lack of experience here. But, it still seems like a > > vpopmail specific protocol would be faster than transfering and modifying > > files over NFS. Does everyone really think that NFS would be faster? > > First off, I've designed and built 2 different qmail+vpopmail clusters, > using different platforms (Sun and Linux), both using NFS (EMC and > RaidZone), and they both work like champs. OK. So, you don't think that a vpopmail specific protocol would save a little overhead? If that is everyone's general conception, then: ok. Works for me. Thanks for the feedback people! Jesse > > Ok, as to your question. NFS is optimized for sending the data for the > network and writing it to disk, or reading the data from disk and pushing > it back out. Your vpopmail daemon would have to do the same thing -- > accept the message via a network port and then write it to the disk. > Sounds a lot like NFS to me. Why not go with the mature protocol? > > > Thanks for the reply. > > > > Jesse -- 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] vpopmail as a daemon
On Tuesday 25 February 2003 03:10, Doug Clements wrote: > If you don't mind my asking, why don't you care for NFS? I just never heard anything good about it. Honest misconception I suppose. > > --Doug > > - Original Message - > From: "Jesse Guardiani" <[EMAIL PROTECTED]> > To: "Doug Clements" <[EMAIL PROTECTED]>; "vpopmail" > <[EMAIL PROTECTED]> > Sent: Sunday, February 23, 2003 4:36 PM > Subject: Re: [vchkpw] vpopmail as a daemon > > > You're right. I don't care for NFS. > > That's why I suggested this. -- 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] vpopmail as a daemon
If you don't mind my asking, why don't you care for NFS? --Doug - Original Message - From: "Jesse Guardiani" <[EMAIL PROTECTED]> To: "Doug Clements" <[EMAIL PROTECTED]>; "vpopmail" <[EMAIL PROTECTED]> Sent: Sunday, February 23, 2003 4:36 PM Subject: Re: [vchkpw] vpopmail as a daemon > You're right. I don't care for NFS. > That's why I suggested this.
Re: [vchkpw] vpopmail as a daemon
On Sunday 23 February 2003 21:56, Jesse Guardiani wrote: > OK. Again, I admit lack of experience here. But, it still seems like a > vpopmail specific protocol would be faster than transfering and modifying > files over NFS. Does everyone really think that NFS would be faster? First off, I've designed and built 2 different qmail+vpopmail clusters, using different platforms (Sun and Linux), both using NFS (EMC and RaidZone), and they both work like champs. Ok, as to your question. NFS is optimized for sending the data for the network and writing it to disk, or reading the data from disk and pushing it back out. Your vpopmail daemon would have to do the same thing -- accept the message via a network port and then write it to the disk. Sounds a lot like NFS to me. Why not go with the mature protocol? > Thanks for the reply. > > Jesse
Re: [vchkpw] vpopmail as a daemon
How about this for an Idea. Since I believe that we all agree in the power of Qmail and its superiority over the other systems. I think that we leave that portion of Qmail and Vpopmail alone. As a suggestion I think that Jesse did bring up some valid points when it comes to the administration of Vpopmail. I believe that some middle ground exists on this issue. Vpopmail could benefit from a more flexible set of webbased tools. As a user of Qmailadmin I like the unified design and the security of not having to run my web server as the vpopmail user(It lacks the ease of integration into perl/php based web email frontends). On the other hand the vpopmail.pm file gives me some of the flexibility that I want when it comes to integration with a web based mail frontend but has the security issues to contend with. I have looked at the php vpopmail extensions and while they have great flexibility you are forced to give on security. Having a flexible/secure web based control tool would allow you to have the speed/security of Qmail, the power/expandablity of Vpopmail. I submit that having an admin daemon running on your Vpopmail server would solve this. You could submit calls from the webased interface of your choice giving you the flexibility of integrating Vpopmail seamlessly into your web systems. I agree that some of this functionallity exists with the Mysql integration of Vpopmail 1) the ability to change users passwords 2) Alias/Forward support with valias (This precludes the use of qmailadmin for any alias/forward creation) as the .qmail file takes precedence ) 3) creation of new users (you either send them a welcome email or wait for the first message to arrive for that user to create the dir structure) This is just my 2cents worth of input on the topic Thanks On Mon, 2003-02-24 at 03:38, Paul Theodoropoulos wrote: > At 12:01 AM 02-24-2003, [EMAIL PROTECTED] wrote: > > > >Hi !! > > > > > If you dislike NFS, then why did you go with qmail to begin with? > > > That was the target for qmail. To use NFS without file locking. > > > >I hope this never reaches djb since I'm 100% sure he never > >thougth qmail to be designed for "Network Failure System"... :-) > > he didn' t design qmail for NFS. however, he designed Maildir specifically > for NFS, and it's an integral part of qmail. > > qmail and NFS play together in harmony. production systems I built back in > 1998 are still up and running (though i no longer work for that company), > running qmail on dual Sun E4500's, behind redundant Big/IP's, with the > filestore on clustered Netapps, NFS mounted over gigabit to the E4500's. > still running like a top. NFS has come a long way since qmail 0.91 was > released back in 1996. > > > Paul Theodoropoulos > http://www.anastrophe.com > http://folding.stanford.edu > The Nicest Misanthrope on the Net > -- Ron Culler
Re: [vchkpw] vpopmail as a daemon
At 12:01 AM 02-24-2003, [EMAIL PROTECTED] wrote: Hi !! > If you dislike NFS, then why did you go with qmail to begin with? > That was the target for qmail. To use NFS without file locking. I hope this never reaches djb since I'm 100% sure he never thougth qmail to be designed for "Network Failure System"... :-) he didn' t design qmail for NFS. however, he designed Maildir specifically for NFS, and it's an integral part of qmail. qmail and NFS play together in harmony. production systems I built back in 1998 are still up and running (though i no longer work for that company), running qmail on dual Sun E4500's, behind redundant Big/IP's, with the filestore on clustered Netapps, NFS mounted over gigabit to the E4500's. still running like a top. NFS has come a long way since qmail 0.91 was released back in 1996. Paul Theodoropoulos http://www.anastrophe.com http://folding.stanford.edu The Nicest Misanthrope on the Net
Re: [vchkpw] vpopmail as a daemon
Hi !! > If you dislike NFS, then why did you go with qmail to begin with? > That was the target for qmail. To use NFS without file locking. I hope this never reaches djb since I'm 100% sure he never thougth qmail to be designed for "Network Failure System"... :-) =d0Mi=
Re: [vchkpw] vpopmail as a daemon
- Original Message - From: "Brian Kolaci" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, February 23, 2003 9:02 PM Subject: Re: [vchkpw] vpopmail as a daemon > > Like I said before, we already have the daemons. That's > qmail-smtpd, authdaemond, and the POP & IMAP daemons. The only > thing left is the admin stuff, which is where I worry about security. I was under the impression that authdaemond doesn't work very well with vpopmail. We constantly have to tell people to disable it on the sqwebmail list. > > If you dislike NFS, then why did you go with qmail to begin with? > That was the target for qmail. To use NFS without file locking. In > any case, you still can easily get by without NFS, but replace it > with a webserver and/or sshd. I don't think that's a fair statement. Qmail is a great alternative to sendmail even without NFS. > > > > > Also, I'll note here that I don't yet have need for a cluster, and have > never implemented/used a vpopmail+NFS cluster. Therefore, I > > realize that vpopmail+NFS may very well be an excellent solution, and that I > may just have an incorrect idea in my head regarding > > the speed and overhead that is required to run NFS. > > There have been *many* improvements to NFS. The latest is very feature > rich, has hooks for security, etc. NFS is a good thing, especially > if you start looking at the alternatives (i.e. NetBIOS). OK. Again, I admit lack of experience here. But, it still seems like a vpopmail specific protocol would be faster than transfering and modifying files over NFS. Does everyone really think that NFS would be faster? Thanks for the reply. Jesse > > > > Brian > Galaxy Networks, Inc. > > > >
Re: [vchkpw] vpopmail as a daemon
> > Well, I don't see the need. vpopmail was made for qmail. > > Qmail invokes vpopmail using vdelivermail. > > > > What exactly would you daemonize? > > Authentication and access to vpopmail control functions. Creating users, domains, aliases, etc... > > Of coarse parts of vpopmail wouldn't run as a daemon because qmail doesn't work that way. I suppose I wasn't clear about what I > thought might be a candidate for 'daemonization'. > Like I said before, we already have the daemons. That's qmail-smtpd, authdaemond, and the POP & IMAP daemons. The only thing left is the admin stuff, which is where I worry about security. > - > > OK. I get the feeling that the vpopmail daemon idea isn't very popular. As I mentioned before, I just threw it out there to get some > feed back, and now that I have, I realize that I haven't thought it through all the way yet. > > A protocol would have to be developed for external apps to talk with vpopmail, and while such a protocol could be designed 'for the > future', so that current apps wouldn't break with future versions of vpopmail, I'm not sure that it would be worth it in the end. > > As I mentioned before, I strongly dislike NFS. I think a vpopmail specific protocol could be engineered that would have a much > higher efficiency than vpopmail+NFS, but that's as far as I've thought it through. If you dislike NFS, then why did you go with qmail to begin with? That was the target for qmail. To use NFS without file locking. In any case, you still can easily get by without NFS, but replace it with a webserver and/or sshd. > > Also, I'll note here that I don't yet have need for a cluster, and have never implemented/used a vpopmail+NFS cluster. Therefore, I > realize that vpopmail+NFS may very well be an excellent solution, and that I may just have an incorrect idea in my head regarding > the speed and overhead that is required to run NFS. There have been *many* improvements to NFS. The latest is very feature rich, has hooks for security, etc. NFS is a good thing, especially if you start looking at the alternatives (i.e. NetBIOS). > > So... with that in mind, I'm going to conclude that I don't have enough experience or knowledge to really debate the pros and cons > of a vpopmail daemon. > > If everyone could shift their attention to the 'vpopmail extension modules' thread, I would still like to discuss some things about > that idea. (And I DO have enough experience and knowledge to have an intelligent discussion about it!) > > Thanks for the comments! > > And thanks for reading! > > Jesse > > > > You would only want to > > make a daemon for things that are used *very* frequently > > and you need the extra speed. The only thing I see is > > authentication, for which you can use authdaemond from > > courier. This works very well with vpopmail (and my patched > > code works with the IP mapping and open_smtp). > > > > I've included my comments below: > > > > > > > Greetings list, > > > > > > I'm sure people have considered this before, but I'd like to collect > > everyone's thoughts on the idea I'm about to present: > > > > > > VPopMail as a daemon > > > > > > What does everyone think about the possibility of turning vpopmail into a > > daemon? Complete with network ports and the like. It would > > > allow for a much more distributed architecture, IMHO. > > > > > > Currently, if someone wants to run qmailadmin on a separate web server, they > > have to create an NFS share, right? > > > > Thats one option, and at least its already secure. You can > > also run an additional webserver on the back-end system and have > > your main webserver proxy requests to it. Still secure. > > > > > > > > Wouldn't it make a lot of sense to provide a vpopmail network protocol that > > allows connections from remote administrative utilities? > > > > No. > > > > > > > > Possibly even implement support for vpopmail clusters (although I'm thinking > > you'd have to have a crazy amount of users to need a > > > cluster! Vpopmail is pretty darn efficient.) > > > > You can already do this. > > > > > > > > Administrative programs like qmailadmin and vqadmin would benefit by not > > having to be run on the primary mail server, but I highly > > > doubt that the majority of web traffic comes from the admin CGIs. > > > > They don't need to be run from the primary mailserver if you use NFS, > > but its better if you do run a secondary webserver on the mailserver > > just for qmailadmin. You can then proxy to it from your primary webserver. > > The admin programs may benefit, but I don't think you're buying much > > by moving the admin functions to a daemon. You would, however, be > > giving hackers yet another w
Re: [vchkpw] vpopmail as a daemon
- Original Message - From: "Brian Kolaci" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, February 23, 2003 8:13 PM Subject: Re: [vchkpw] vpopmail as a daemon > > Hi, > > Well, I don't see the need. vpopmail was made for qmail. > Qmail invokes vpopmail using vdelivermail. > > What exactly would you daemonize? Authentication and access to vpopmail control functions. Creating users, domains, aliases, etc... Of coarse parts of vpopmail wouldn't run as a daemon because qmail doesn't work that way. I suppose I wasn't clear about what I thought might be a candidate for 'daemonization'. - OK. I get the feeling that the vpopmail daemon idea isn't very popular. As I mentioned before, I just threw it out there to get some feed back, and now that I have, I realize that I haven't thought it through all the way yet. A protocol would have to be developed for external apps to talk with vpopmail, and while such a protocol could be designed 'for the future', so that current apps wouldn't break with future versions of vpopmail, I'm not sure that it would be worth it in the end. As I mentioned before, I strongly dislike NFS. I think a vpopmail specific protocol could be engineered that would have a much higher efficiency than vpopmail+NFS, but that's as far as I've thought it through. Also, I'll note here that I don't yet have need for a cluster, and have never implemented/used a vpopmail+NFS cluster. Therefore, I realize that vpopmail+NFS may very well be an excellent solution, and that I may just have an incorrect idea in my head regarding the speed and overhead that is required to run NFS. So... with that in mind, I'm going to conclude that I don't have enough experience or knowledge to really debate the pros and cons of a vpopmail daemon. If everyone could shift their attention to the 'vpopmail extension modules' thread, I would still like to discuss some things about that idea. (And I DO have enough experience and knowledge to have an intelligent discussion about it!) Thanks for the comments! And thanks for reading! Jesse > You would only want to > make a daemon for things that are used *very* frequently > and you need the extra speed. The only thing I see is > authentication, for which you can use authdaemond from > courier. This works very well with vpopmail (and my patched > code works with the IP mapping and open_smtp). > > I've included my comments below: > > > > Greetings list, > > > > I'm sure people have considered this before, but I'd like to collect > everyone's thoughts on the idea I'm about to present: > > > > VPopMail as a daemon > > > > What does everyone think about the possibility of turning vpopmail into a > daemon? Complete with network ports and the like. It would > > allow for a much more distributed architecture, IMHO. > > > > Currently, if someone wants to run qmailadmin on a separate web server, they > have to create an NFS share, right? > > Thats one option, and at least its already secure. You can > also run an additional webserver on the back-end system and have > your main webserver proxy requests to it. Still secure. > > > > > Wouldn't it make a lot of sense to provide a vpopmail network protocol that > allows connections from remote administrative utilities? > > No. > > > > > Possibly even implement support for vpopmail clusters (although I'm thinking > you'd have to have a crazy amount of users to need a > > cluster! Vpopmail is pretty darn efficient.) > > You can already do this. > > > > > Administrative programs like qmailadmin and vqadmin would benefit by not > having to be run on the primary mail server, but I highly > > doubt that the majority of web traffic comes from the admin CGIs. > > They don't need to be run from the primary mailserver if you use NFS, > but its better if you do run a secondary webserver on the mailserver > just for qmailadmin. You can then proxy to it from your primary webserver. > The admin programs may benefit, but I don't think you're buying much > by moving the admin functions to a daemon. You would, however, be > giving hackers yet another way to cause havoc. > > > > > Programs like sqwebmail would benefit by not having to be recompiled every > time vpopmail is upgraded. The port protocol wouldn't > > change much between versions, and developers could maintain backward > compatibility. > > You typically don't need to update sqwebmail since not mu
Re: [vchkpw] vpopmail as a daemon
Hi, Well, I don't see the need. vpopmail was made for qmail. Qmail invokes vpopmail using vdelivermail. What exactly would you daemonize? You would only want to make a daemon for things that are used *very* frequently and you need the extra speed. The only thing I see is authentication, for which you can use authdaemond from courier. This works very well with vpopmail (and my patched code works with the IP mapping and open_smtp). I've included my comments below: > Greetings list, > > I'm sure people have considered this before, but I'd like to collect everyone's thoughts on the idea I'm about to present: > > VPopMail as a daemon > > What does everyone think about the possibility of turning vpopmail into a daemon? Complete with network ports and the like. It would > allow for a much more distributed architecture, IMHO. > > Currently, if someone wants to run qmailadmin on a separate web server, they have to create an NFS share, right? Thats one option, and at least its already secure. You can also run an additional webserver on the back-end system and have your main webserver proxy requests to it. Still secure. > > Wouldn't it make a lot of sense to provide a vpopmail network protocol that allows connections from remote administrative utilities? No. > > Possibly even implement support for vpopmail clusters (although I'm thinking you'd have to have a crazy amount of users to need a > cluster! Vpopmail is pretty darn efficient.) You can already do this. > > Administrative programs like qmailadmin and vqadmin would benefit by not having to be run on the primary mail server, but I highly > doubt that the majority of web traffic comes from the admin CGIs. They don't need to be run from the primary mailserver if you use NFS, but its better if you do run a secondary webserver on the mailserver just for qmailadmin. You can then proxy to it from your primary webserver. The admin programs may benefit, but I don't think you're buying much by moving the admin functions to a daemon. You would, however, be giving hackers yet another way to cause havoc. > > Programs like sqwebmail would benefit by not having to be recompiled every time vpopmail is upgraded. The port protocol wouldn't > change much between versions, and developers could maintain backward compatibility. You typically don't need to update sqwebmail since not much would change to affect this program. Same thing for IMP (nothing would ever have to change as it uses IMAP). > > Sqwebmail WOULDN'T be able to run on a separate server, as it accesses maildirs directly, but at least administration, upgrades, and > general package stability would likely improve a bit. I don't see any improvement. > > Who knows. One might even be able to implement a maildir access protocol. But that would probably just duplicate the functionality > of the IMAP protocol. Right, that would be a waste of time. > > Can anyone else think of a good reason why vpopmail might benefit from being made into a daemon? No. > > Can anyone think of a really good reason why it shouldn't? (Other than the time it would take to code everything.) Sure. Security. You can implement the security into your webserver above and beyond the qmailadmin security. Another is that there would be another point of failure. If anything, this just adds more lines of code, and to what benefit? For the admin interfaces (which is the only place I can see the daemon doing anything)? > > I'm just thinking aloud here, but I'd like to hear everyone's ideas on the matter. Sorry, but I think its a pretty bad idea, at least for this piece of software. I'm typically for having daemons around, but for the places they're needed, they're already there. Vpopmail is currently just a set of API's in a library plus a delivery agent. There's some utility programs that come with it, but still its mainly a set of API's. Now what I'd like to see happen is integrate java API's and make qmailadmin and vqadmin into webapps. Its already on my list of "todo's", but pretty far down... Brian
Re: [vchkpw] vpopmail as a daemon
- Original Message - From: "Anders Brander" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, February 23, 2003 6:15 PM Subject: Re: [vchkpw] vpopmail as a daemon > Hi, > > On Sunday 23 February 2003 19:03, Jesse Guardiani wrote: > > What does everyone think about the possibility of turning vpopmail > > into a daemon? Complete with network ports and the like. It would > > allow for a much more distributed architecture, IMHO. > > How about: > ssh -l vpopmail your.mailserver.com ~/bin/vadddomain foobar.com password > and so on? > > Wouldn't that help? It would probably work... but I doubt it would be very efficient. Thanks for the reply! Jesse > > /Anders > > >
Re: [vchkpw] vpopmail as a daemon
You're right. I don't care for NFS. That's why I suggested this. 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. - Original Message - From: "Doug Clements" <[EMAIL PROTECTED]> To: "Jesse Guardiani" <[EMAIL PROTECTED]>; "vpopmail" <[EMAIL PROTECTED]> Sent: Sunday, February 23, 2003 4:04 PM Subject: Re: [vchkpw] vpopmail as a daemon > - Original Message - > From: "Jesse Guardiani" <[EMAIL PROTECTED]> > To: "vpopmail" <[EMAIL PROTECTED]> > Sent: Sunday, February 23, 2003 10:03 AM > Subject: [vchkpw] vpopmail as a daemon > > > > Greetings list, > > > > I'm sure people have considered this before, but I'd like to collect > everyone's thoughts on the idea I'm about to present: > > > > VPopMail as a daemon > > > > What does everyone think about the possibility of turning vpopmail into a > daemon? Complete with network ports and the like. It would > > allow for a much more distributed architecture, IMHO. > > > > Currently, if someone wants to run qmailadmin on a separate web server, > they have to create an NFS share, right? > > What's wrong with that? > > > Wouldn't it make a lot of sense to provide a vpopmail network protocol > that allows connections from remote administrative utilities? > > You mean something that takes requests over the network and stores user > information in a database? > > > Possibly even implement support for vpopmail clusters (although I'm > thinking you'd have to have a crazy amount of users to need a > > cluster! Vpopmail is pretty darn efficient.) > > I've already got a cluster. It works great. > > > Programs like sqwebmail would benefit by not having to be recompiled every > time vpopmail is upgraded. The port protocol wouldn't > > change much between versions, and developers could maintain backward > compatibility. > > The only time you need to recompile sqwebmail is if the storage format for > the users change. At this point, you'd also need to recompile the software > that talks over the network. Either way you lose. > > > Sqwebmail WOULDN'T be able to run on a separate server, as it accesses > maildirs directly, but at least administration, upgrades, and > > general package stability would likely improve a bit. > > My sqwebmail install is distributed across machines. Works great. > > The general idea is "less code is going to have less bugs", not "more code > is going to have less bugs". > > > Who knows. One might even be able to implement a maildir access protocol. > But that would probably just duplicate the functionality > > of the IMAP protocol. > > Now that would just be silly. > > > Can anyone else think of a good reason why vpopmail might benefit from > being made into a daemon? > > Only if you were for some reason religiously opposed to using NFS to > accomplish all the things above. Then again, you could use samba or afs. So > no, I can't think of a good reason. > > > Can anyone think of a really good reason why it shouldn't? (Other than the > time it would take to code everything.) > > It's too complicated for something that's already small, fast, and simple. > None of the things you suggest can't already be done, or don't really need > to be done. > > --Doug > > >
Re: [vchkpw] vpopmail as a daemon
Hi, On Sunday 23 February 2003 19:03, Jesse Guardiani wrote: > What does everyone think about the possibility of turning vpopmail > into a daemon? Complete with network ports and the like. It would > allow for a much more distributed architecture, IMHO. How about: ssh -l vpopmail your.mailserver.com ~/bin/vadddomain foobar.com password and so on? Wouldn't that help? /Anders
Re: [vchkpw] vpopmail as a daemon
On Sunday 23 February 2003 19:26, Ron Culler wrote: > I agree with that it would make life alot easier to integrate other > web-based email apps. I currently use vpopmail with a mysql backend and > have compiled in the valias support. This works great except that if I > use qmailadmin I loose the valias(mysql) support as it only creates a > .qmail file in the users Maildir. Having the ability to integrate the > functionality of qmailadmin into what ever web front-end that you wish > using the lang. of your choice would be great. > i've just started writing something similar to the daemon of vmailmgr. it would allow you to add/modify/delete domains, users, aliases.. the reason why i'm doing this, is simply: i want to do all these things from my php frontend. AND: it do _not_ want to run apache as vpopmail user. until now i've accomplished this by writing to a "jobs" mysql table and read this every 30 minutes from a cron job running as vpopmail user. -- Best Regards, Justin
RE: [vchkpw] vpopmail as a daemon
I think this is a very bad idea and I'm not sure if it even possible. How can vpopmail interact with qmail if it runs as a deamon process ?? The whole idea of qmail is very simple and almost everything goes into a pipeline. This gives an easy way to write own modules/filters which can be added to the pipe. ok, I'm not 10th-graded-black-belt coder so You may excuse me if I'm wrong but I cant see this possible without rewriting qmail itself... What about qmailadmin, webmail and other stuff ?? We already have SQL backend and it works great ! We can share the work between one or more SQL servers running on remote computers. Qmailadmin need access to filesystem, so does sqwebmail and that's bad. I think the best solution is to make vpopmail config, users, aliases etc completely sqlbased so we never need to create symlinks or .qmail-files or whatever limits etc... the second step is to rewrite qmailadmin so it only operates on backend (sql) level. That way we can run qmailadmin on whatever machine, wherever in the world. The only thing we need is access to sql backend. Or if You like, You could easily write Your own "mailadmin" in PHP ! same thing with webmail. With courier-IMAP running on the mailserver You can use any webmail client that undertand IMAP. Or write Your own webmail client !! Thanks for reading. =d0Mi= > Original Message - > Date: 23-Feb-2003 18:59:40 +0100 > From: Jesse Guardiani <[EMAIL PROTECTED]> > To: vpopmail <[EMAIL PROTECTED]> > Subject: [vchkpw] vpopmail as a daemon > > Greetings list, > > I'm sure people have considered this before, but I'd like to collect everyone's thoughts on the idea I'm about to present: > > VPopMail as a daemon > > What does everyone think about the possibility of turning vpopmail into a daemon? Complete with network ports and the like. It would > allow for a much more distributed architecture, IMHO. > > Currently, if someone wants to run qmailadmin on a separate web server, they have to create an NFS share, right? > > Wouldn't it make a lot of sense to provide a vpopmail network protocol that allows connections from remote administrative utilities? > > Possibly even implement support for vpopmail clusters (although I'm thinking you'd have to have a crazy amount of users to need a > cluster! Vpopmail is pretty darn efficient.) > > Administrative programs like qmailadmin and vqadmin would benefit by not having to be run on the primary mail server, but I highly > doubt that the majority of web traffic comes from the admin CGIs. > > Programs like sqwebmail would benefit by not having to be recompiled every time vpopmail is upgraded. The port protocol wouldn't > change much between versions, and developers could maintain backward compatibility. > > Sqwebmail WOULDN'T be able to run on a separate server, as it accesses maildirs directly, but at least administration, upgrades, and > general package stability would likely improve a bit. > > Who knows. One might even be able to implement a maildir access protocol. But that would probably just duplicate the functionality > of the IMAP protocol. > > Can anyone else think of a good reason why vpopmail might benefit from being made into a daemon? > > Can anyone think of a really good reason why it shouldn't? (Other than the time it would take to code everything.) > > I'm just thinking aloud here, but I'd like to hear everyone's ideas on the matter. > > 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] vpopmail as a daemon
- Original Message - From: "Jesse Guardiani" <[EMAIL PROTECTED]> To: "vpopmail" <[EMAIL PROTECTED]> Sent: Sunday, February 23, 2003 10:03 AM Subject: [vchkpw] vpopmail as a daemon > Greetings list, > > I'm sure people have considered this before, but I'd like to collect everyone's thoughts on the idea I'm about to present: > > VPopMail as a daemon > > What does everyone think about the possibility of turning vpopmail into a daemon? Complete with network ports and the like. It would > allow for a much more distributed architecture, IMHO. > > Currently, if someone wants to run qmailadmin on a separate web server, they have to create an NFS share, right? What's wrong with that? > Wouldn't it make a lot of sense to provide a vpopmail network protocol that allows connections from remote administrative utilities? You mean something that takes requests over the network and stores user information in a database? > Possibly even implement support for vpopmail clusters (although I'm thinking you'd have to have a crazy amount of users to need a > cluster! Vpopmail is pretty darn efficient.) I've already got a cluster. It works great. > Programs like sqwebmail would benefit by not having to be recompiled every time vpopmail is upgraded. The port protocol wouldn't > change much between versions, and developers could maintain backward compatibility. The only time you need to recompile sqwebmail is if the storage format for the users change. At this point, you'd also need to recompile the software that talks over the network. Either way you lose. > Sqwebmail WOULDN'T be able to run on a separate server, as it accesses maildirs directly, but at least administration, upgrades, and > general package stability would likely improve a bit. My sqwebmail install is distributed across machines. Works great. The general idea is "less code is going to have less bugs", not "more code is going to have less bugs". > Who knows. One might even be able to implement a maildir access protocol. But that would probably just duplicate the functionality > of the IMAP protocol. Now that would just be silly. > Can anyone else think of a good reason why vpopmail might benefit from being made into a daemon? Only if you were for some reason religiously opposed to using NFS to accomplish all the things above. Then again, you could use samba or afs. So no, I can't think of a good reason. > Can anyone think of a really good reason why it shouldn't? (Other than the time it would take to code everything.) It's too complicated for something that's already small, fast, and simple. None of the things you suggest can't already be done, or don't really need to be done. --Doug
Re: [vchkpw] vpopmail as a daemon
I agree with that it would make life alot easier to integrate other web-based email apps. I currently use vpopmail with a mysql backend and have compiled in the valias support. This works great except that if I use qmailadmin I loose the valias(mysql) support as it only creates a .qmail file in the users Maildir. Having the ability to integrate the functionality of qmailadmin into what ever web front-end that you wish using the lang. of your choice would be great. On Sun, 2003-02-23 at 13:03, Jesse Guardiani wrote: > Greetings list, > > I'm sure people have considered this before, but I'd like to collect everyone's > thoughts on the idea I'm about to present: > > VPopMail as a daemon > > What does everyone think about the possibility of turning vpopmail into a daemon? > Complete with network ports and the like. It would > allow for a much more distributed architecture, IMHO. > > Currently, if someone wants to run qmailadmin on a separate web server, they have to > create an NFS share, right? > > Wouldn't it make a lot of sense to provide a vpopmail network protocol that allows > connections from remote administrative utilities? > > Possibly even implement support for vpopmail clusters (although I'm thinking you'd > have to have a crazy amount of users to need a > cluster! Vpopmail is pretty darn efficient.) > > Administrative programs like qmailadmin and vqadmin would benefit by not having to > be run on the primary mail server, but I highly > doubt that the majority of web traffic comes from the admin CGIs. > > Programs like sqwebmail would benefit by not having to be recompiled every time > vpopmail is upgraded. The port protocol wouldn't > change much between versions, and developers could maintain backward compatibility. > > Sqwebmail WOULDN'T be able to run on a separate server, as it accesses maildirs > directly, but at least administration, upgrades, and > general package stability would likely improve a bit. > > Who knows. One might even be able to implement a maildir access protocol. But that > would probably just duplicate the functionality > of the IMAP protocol. > > Can anyone else think of a good reason why vpopmail might benefit from being made > into a daemon? > > Can anyone think of a really good reason why it shouldn't? (Other than the time it > would take to code everything.) > > I'm just thinking aloud here, but I'd like to hear everyone's ideas on the matter. > > 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. > -- Ron Culler <[EMAIL PROTECTED]>
Re: [vchkpw] vpopmail as a daemon
Using MySQL or LDAP for your backend would make it easy to share the work load of qmailadmin and other things on other systems. -John - Original Message - From: "Jesse Guardiani" <[EMAIL PROTECTED]> To: "vpopmail" <[EMAIL PROTECTED]> Sent: Sunday, February 23, 2003 10:03 AM Subject: [vchkpw] vpopmail as a daemon > Greetings list, > > I'm sure people have considered this before, but I'd like to collect everyone's thoughts on the idea I'm about to present: > > VPopMail as a daemon > > What does everyone think about the possibility of turning vpopmail into a daemon? Complete with network ports and the like. It would > allow for a much more distributed architecture, IMHO. > > Currently, if someone wants to run qmailadmin on a separate web server, they have to create an NFS share, right? > > Wouldn't it make a lot of sense to provide a vpopmail network protocol that allows connections from remote administrative utilities? > > Possibly even implement support for vpopmail clusters (although I'm thinking you'd have to have a crazy amount of users to need a > cluster! Vpopmail is pretty darn efficient.) > > Administrative programs like qmailadmin and vqadmin would benefit by not having to be run on the primary mail server, but I highly > doubt that the majority of web traffic comes from the admin CGIs. > > Programs like sqwebmail would benefit by not having to be recompiled every time vpopmail is upgraded. The port protocol wouldn't > change much between versions, and developers could maintain backward compatibility. > > Sqwebmail WOULDN'T be able to run on a separate server, as it accesses maildirs directly, but at least administration, upgrades, and > general package stability would likely improve a bit. > > Who knows. One might even be able to implement a maildir access protocol. But that would probably just duplicate the functionality > of the IMAP protocol. > > Can anyone else think of a good reason why vpopmail might benefit from bei ng made into a daemon? > > Can anyone think of a really good reason why it shouldn't? (Other than the time it would take to code everything.) > > I'm just thinking aloud here, but I'd like to hear everyone's ideas on the matter. > > 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. > > > >
