Re: Future of Qmail-LDAP
Edward Capriolo <[email protected]>
| Newsgroups | gmane.mail.qmail.ldap |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Feb 3, 2010 at 11:55 AM, Russell Simpkins <[email protected]> wrote: > Hugo, > > I would love to see more work done on qmail-ldap. I compile my own and run > with dovecot and squirrelmail. I have tried netqmail and the qmail toaster > for other projects and found each decent. I have read through a lot of > qmail-rocks. > > I'm guessing that no one has done anything because qmail-ldap just works. > > It might be nice to pull together a more formal version of qmail-ldap as > it's own project with goals that will gather interest. Maybe with a goal > to clean up and simplify setup, configuration and > management/administration and maybe bringing together the best of whats > out there. I don't really care for the admin tools of toaster. They're > better than none but leave a lot to be desired. I really like qmail, but > it does lack the wrapping that zimbra appears to have. I'm guessing they > could have just as easily used qmail instead of zimbra. > > One issue with qmail caused possibly by the lack of a gpl is that there > are so many 3rd party solutions and options it can be very hard for people > to even bother with qmail-ldap. You have a variety of people that > implemented rbl, spam checking etc that it can be very time consuming to > pull together a good qmail-ldap solution. I had to put it all in a script > just to keep up with it. Setting up qmail to work with spam filters is an > example, there isn't one feature that can be configured for all. > > I would like to see a modular project that had qmail at its core with a > set of easily added/configured set of modules similar in fashion to how > Apache or PHP is built. A project like that could attract interest if the > core was architected well enough to standardize how features are added to > a new qmail. That way, if someone was to come up with a new anti-spam > package, it could be created as a new module that would be easy to add in > because the API is clearly defined. > > Again, I really like qmail-ldap and hope that it is here to stay. > > > Russ > > >>One issue with qmail caused possibly by the lack of a gpl is that there >>are so many 3rd party solutions and options it can be very hard for people >>to even bother with qmail-ldap. Upstream QMAIL has been moved to public domain. So now you should be able to effectively packaged, hacked, redistributed, etc. Before the rigid requirements were stopping this. I definitely feel your pain. Getting QMAIL setup was a long and painful romp across the internet of follow the link to this guys patch, follow the link to that guys patch. Incomplete documentation about this guys toaster, that guys toaster, Qmail LDAP did a great job of bundling all of the relevant packages I needed. But the issue of patches with conflicts comes up and getting everything merged into a stable mainline.