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
