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