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
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.
> ---- 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
> 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
> Jesse Guardiani, Systems Administrator
> WingNET Internet Services,
> P.O. Box 2605 // Cleveland, TN 37320-2605
> 423-559-LINK (v) 423-559-5145 (f)
> 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.