I would like to see some discussion about this as well. I think that examining the role of vpopmail in today's email landscape has merit. I'm not intimately familiar with vpopmail's history, but I have used it a bit as part of the qmail-toaster (see http://www.qmailtoater.com).

vpopmail has potential beyond just email.



It might be useful to start with what vpopmail is not. It's not an MTA, an MDA, nor MSA (submission), although it interfaces with all of them. In my mind, vpopmail is an authentication store, which handles mail related data in support of virtual domains and users. Sort of a Mail Authentication Agent. It handles all of the data related to implementing virtual email services (domains and users), although it doesn't handle an email itself. It also provides APIs/interfaces for the various other Mail Agents (MTAs, MDAs, etc), so that they can obtain the data they need to operate according to the data stored in vpopmail. Perhaps vdommail or simply vmail would have been a more appropriate name. I kinda like the former as vdom rhymes with freedom.

vmail is taken i believe...Bruce Guenter's multi system user virtual domain solution whereas vpopmail started out as a single system user virtual domain solution


How's this for starters?

In the future (months), I would like to see qmailadmin and vqadmin consolidated into a single package in support of vpopmail. I don't see any purpose in having 2 separate web applications.

Longer term (years), I'd like to see vpopmail interface with a FreeIPA back end server.

Funny that, some time ago I was thinking of the possibility of tying things into the mysql (or whatever database vpopmail handles like pgsql - pgsql support is as current as mysql support now right?) vpopmail database...like samba, apache...but yours is slightly different. I noticed all the columns that are passwd structure based that were not quite having their full potential being used.

!DSPAM:4a9b414f32713689764762!

Reply via email to