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?


  > 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 

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?


  > 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 

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


Reply via email to