Re: [vchkpw] Re: Untie vpopmail from qmail
Rick Widmer wrote: Christopher Chan wrote: See my reply to your other post. If vpopmail can also handle multiple system user accounts instead of just virtual domain mailboxes under a single system user...we can integrate with samba and other stuff. It can. OTOH the main reason I chose vpopmail is because I don't want to use any more system accounts than I have to. I know. System accounts, however, is how security for samba and other stuff work. !DSPAM:4a9cfb4732711016853307!
Re: [vchkpw] Re: Untie vpopmail from qmail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christopher Chan wrote: What I do see is a need for vpopmail to be able to give 'deliver' any data it needs to do its job (for instance maildir or mailbox, destination location, etc). At some point vpopmail might also include providing SIEVE filtering rules. I've often thought that vpopmail needed some sort of delivery script. I liked some of maildrop, but it's too bloated to be incorporated as is. If vpopmail can take things a bit beyond just say single system user and perhaps be able to handle 1) multi system user virtual domains and 2) It does handle multiple system users. It requires one core user. You can add domains and users to other user ids. vadddomain accepts -d, -i, and -g, all of which can be used to relocate a domain's directory, and re-assign it's UID and GID. massive multi system user management with an appropriate backend like pgsql, then I hope there is incentive for the dovecot guys to keep their relationship with vpopmail and not try to come up with their own management module. vpopmail has a PostgreSQL module, as well as a MySQL module, and the somewhat outdated, but probably still functional, Sybase and Oracle modules. Right now, postfix + dovecot + vpopmail looks pretty neat without getting too many different libraries/frameworks involved. If this can be taken a step further... I think adding specific support for external LDAs is easy enough to implement. As far as libraries, we could probably use EPS in support of any delivery script mechanism. - -- /* Matt Brookings m...@inter7.com GnuPG Key FAE0672C Software developer Systems technician Inter7 Internet Technologies, Inc. (815)776-9465 */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqdOTcACgkQIwet2/rgZyxS1QCcC8f413yZwjbiyo2eK6dBlifQ EWsAnR9zHNkwPQvROLYHwtxFrgVB/ory =LXdh -END PGP SIGNATURE-
Re: [vchkpw] Re: Untie vpopmail from qmail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christopher Chan wrote: Eric Shubert wrote: Tying these various authentication mechanisms together is a worthy objective, regardless of the implementation software (mysql vs pgsql vs ldap). The difficulty in any case is to merge the various schemas together. I believe that ldap has the best chance of accomplishing this, because of the 'standard' schemas that are available for it, and due to its nature as a directory vs a database. LDAP is simply a better fit for this type of application than a database (see http://www.openldap.org/doc/admin24/intro.html#LDAP%20vs%20RDBMS). I think the passwd based schema in place looks pretty good. Agreed. The passwd-based schema is pretty nice, and it's easily mapped to from other schemas. Regarding LDAP, I've been retooling the LDAP module for the 5.5 stable release. As I've probably said a few times in the past, I've been registering OIDs for the vpopmail schema. I also think that FreeIPA has the potential to become the defacto standard in this area. Making vpopmail able to co-operate/interface with FreeIPA could very well extend the lifetime of applications that rely on the vpopmail authentication mechanism. It might be feasible to develop a vpopmail plugin for FreeIPA at some point (possibly even now). I know that FreeIPA has a modular architecture such as this, but haven't yet looked at it in any detail. I have not had a good look at FreeIPA yet so no comment. Quick glances indicate that FreeIPA is a sort of authentication backend with rules. I don't see why this couldn't be supported, but like Christopher said, I'm not very familiar with FreeIPA, so I'm not sure about it's position to be the standard. Please excuse my obvious intrusion into the middle of this thread with replies to multiple people :) - -- /* Matt Brookings m...@inter7.com GnuPG Key FAE0672C Software developer Systems technician Inter7 Internet Technologies, Inc. (815)776-9465 */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqdOmIACgkQIwet2/rgZyxDVgCePQ7tJ6i5FzYpewV5f481jGN8 uWUAoJKykZrxxfmlKV4v33aPWbL2Wx46 =tszg -END PGP SIGNATURE-
Re: [vchkpw] Re: Untie vpopmail from qmail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Shubert wrote: I agree. The question is, which step further? I hope a little discussion here will help to clarify that question. Given vpopmail's roots as you mentioned, I'd like to see vpopmail's focus sharpened, strengthening it's role in the email server landscape. Agreed. This is definitely my current goal for my participation in the project. The 5.5 release gives us a good chance to add in many new features and admin-wishlist nods. If there is any time to discuss and implement new feature sets, it is now. Thanks to everyone for their participation in this, past and future. Yes, thanks to everyone! - -- /* Matt Brookings m...@inter7.com GnuPG Key FAE0672C Software developer Systems technician Inter7 Internet Technologies, Inc. (815)776-9465 */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqdO1IACgkQIwet2/rgZyyUhgCfeDmouyuME449cIVHkDNcgQEU rIIAnRl6JNNsgDjFIWg3TTNJsKbE1gok =I15d -END PGP SIGNATURE-
Re: [vchkpw] Re: Untie vpopmail from qmail
One large factor for me deciding to migrate to dovecot's lda ('deliver')
is to use SIEVE, which is under active development and is likely to
become a standard (imho). I see no point in creating another lda.
Yeah, with SIEVE support being found in Kmail and addons or plugins for
thunderbird and probably others...it kinda paves the way for a standard eh?
What I do see is a need for vpopmail to be able to give 'deliver' any
data it needs to do its job (for instance maildir or mailbox,
destination location, etc). At some point vpopmail might also include
providing SIEVE filtering rules.
The only problem I see at this point in time is how dependent vpopmail
is on others to make use of it. vpopmail started out as something to
fill out a need missing in the qmail toolchains. Even then, qmail did
not have everything (eg: no imap) and it is really nice that dovecot
added vpopmail support especially since Sam dropped vpopmail support
from courier toolchains.
If vpopmail can take things a bit beyond just say single system user and
perhaps be able to handle 1) multi system user virtual domains and 2)
massive multi system user management with an appropriate backend like
pgsql, then I hope there is incentive for the dovecot guys to keep their
relationship with vpopmail and not try to come up with their own
management module.
Right now, postfix + dovecot + vpopmail looks pretty neat without
getting too many different libraries/frameworks involved. If this can be
taken a step further...
!DSPAM:4a9c998632711698363575!
Re: [vchkpw] Re: Untie vpopmail from qmail
Eric Shubert wrote: Christopher Chan wrote: 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. I agree. Would you care to elaborate some about this? See my reply to your other post. If vpopmail can also handle multiple system user accounts instead of just virtual domain mailboxes under a single system user...we can integrate with samba and other stuff. 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. Tying these various authentication mechanisms together is a worthy objective, regardless of the implementation software (mysql vs pgsql vs ldap). The difficulty in any case is to merge the various schemas together. I believe that ldap has the best chance of accomplishing this, because of the 'standard' schemas that are available for it, and due to its nature as a directory vs a database. LDAP is simply a better fit for this type of application than a database (see http://www.openldap.org/doc/admin24/intro.html#LDAP%20vs%20RDBMS). I think the passwd based schema in place looks pretty good. I also think that FreeIPA has the potential to become the defacto standard in this area. Making vpopmail able to co-operate/interface with FreeIPA could very well extend the lifetime of applications that rely on the vpopmail authentication mechanism. It might be feasible to develop a vpopmail plugin for FreeIPA at some point (possibly even now). I know that FreeIPA has a modular architecture such as this, but haven't yet looked at it in any detail. I have not had a good look at FreeIPA yet so no comment. !DSPAM:4a9c9ad732711818917752!
Re: [vchkpw] Re: Untie vpopmail from qmail
Christopher Chan wrote: See my reply to your other post. If vpopmail can also handle multiple system user accounts instead of just virtual domain mailboxes under a single system user...we can integrate with samba and other stuff. It can. OTOH the main reason I chose vpopmail is because I don't want to use any more system accounts than I have to. Rick !DSPAM:4a9c9d5132713286262132!
Re: [vchkpw] Re: Untie vpopmail from qmail
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!
