----- 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 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 > > >
