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