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 BrookingsGnuPG 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
-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 BrookingsGnuPG 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 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 BrookingsGnuPG 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-
[vchkpw] Re: Untie vpopmail from qmail
Christopher Chan wrote:
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?
I neglected to mention that there are already more than a handful of
RFCs related to Sieve. See
http://en.wikipedia.org/wiki/Sieve_(mail_filtering_language)
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.
I don't see this necessarily as a problem. Applications will choose to
provide hooks for vpopmail as they see fit. The factors which make
vpopmail a good choice (existing infrastructure, modularity, stability,
etc.) will drive other applications to use it (or not).
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.
I was happy to see vpopmail support in dovecot as well. While the
elimination of vpopmail support in courier was a large factor in
deciding to replace it with dovecot as the stock IMAP service in
qmail-toaster (http://www.qmailtoater.com), we've seen nice performance
improvements with dovecot over courier as well. Add in the Sieve factor,
and the decision to use dovecot is any easy one.
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.
I think that ldap provides the scalable backend you're looking for.
I'd be surprised if the dovecot developers attempt to develop their own
management module. It's outside of their scope.
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 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.
Thanks to everyone for their participation in this, past and future.
--
-Eric 'shubes'
!DSPAM:4a9d2dc232711270229179!
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
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
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
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!
[vchkpw] Re: Untie vpopmail from qmail
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? 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 I figured vmail was probably taken. I'm not familiar with it, also I should check it out. 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. 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 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. -- -Eric 'shubes' !DSPAM:4a9bdff832712105046433!
[vchkpw] Re: Untie vpopmail from qmail
Christopher Chan wrote:
Matt Brookings wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christopher Chan wrote:
Right now I can use either maildrop or dovecot's lda with postfix. No
injecting into a qmail queue for final delivery into the vpopmail mail
store. Are you saying you would like a vpopmail lda for postfix?
Something that supports dot-qmail rather than whatever maildrop or
dovecot provides?
I'm not specifically saying anything. I was more interested in what
others thought,
and was paving the way by saying that we have no objections.
Do you have any objections you'd like to discuss?
Nope. I have no objections at all to vpopmail getting a lda for postfix
and can do things dot-qmail like. After all, you won't get that with
maildrop or dovecot's lda. I would just like to point out, however, that
if one goes the dovecot lda route, they get to benefit from the SIEVE
support that dovecot has as an addon. If you are going to create your
own lda for postfix, you might want to also consider whether you want to
keep things as they are with respects to rule generation (currently
web-based only? been a while...) or whether you want to try to get SIEVE
support by providing an interface for pop3/imap4 solutions or something...
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.
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.
--
-Eric 'shubes'
!DSPAM:4a9bdacb32718821810722!
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!
[vchkpw] Re: Untie vpopmail from qmail
Matt Brookings wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christopher Chan wrote:
Right now I can use either maildrop or dovecot's lda with postfix. No
injecting into a qmail queue for final delivery into the vpopmail mail
store. Are you saying you would like a vpopmail lda for postfix?
Something that supports dot-qmail rather than whatever maildrop or
dovecot provides?
I'm not specifically saying anything. I was more interested in what others
thought,
and was paving the way by saying that we have no objections.
Do you have any objections you'd like to discuss?
- --
/*
Matt BrookingsGnuPG Key FAE0672C
Software developer Systems technician
Inter7 Internet Technologies, Inc. (815)776-9465
*/
I like Christopher's approach. I'm personally looking to migrate to
dovecot's LDA ('deliver') in place of maildrop.
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).
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.
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.
Critique welcome.
--
-Eric 'shubes'
!DSPAM:4a98008932713185712739!
[vchkpw] Re: Untie vpopmail from qmail
Christopher Chan wrote: Eric Shubert wrote: Christopher, Will you report your findings here, or at least links to the pertinent archive posts? I'm curious about this, but not enough so to do the searching. Which part are you curious about? postfix 'directly' hitting the vpopmail mail store and using the /var/qmail/control/* files for configuration or trying to untie vpopmail from qmail? Untying vpopmail from qmail. -- -Eric 'shubes' !DSPAM:4a96a74132711668415081!
Re: [vchkpw] Re: Untie vpopmail from qmail
Eric Shubert wrote: Christopher, Will you report your findings here, or at least links to the pertinent archive posts? I'm curious about this, but not enough so to do the searching. Which part are you curious about? postfix 'directly' hitting the vpopmail mail store and using the /var/qmail/control/* files for configuration or trying to untie vpopmail from qmail? !DSPAM:4a968dad32713845539307!
[vchkpw] Re: Untie vpopmail from qmail
Christopher, Will you report your findings here, or at least links to the pertinent archive posts? I'm curious about this, but not enough so to do the searching. Tren Blackburn wrote: This has been gone over a few times in the past. Search the archives for the technical reasons. But every time this question comes up it's been a "no". t - Original Message - From: Christopher Chan To: vchkpw@inter7.com Sent: Wed Aug 26 20:16:40 2009 Subject: [vchkpw] Untie vpopmail from qmail Hello all, Is this at all possible? Right now I use postfix and I only have a qmail queue just for vpopmail to install but qmail is otherwise not at all involved. cheers, Christopher -- -Eric 'shubes' !DSPAM:4a9678ca32711151996267!
