Re: Future of Qmail-LDAP

Once I made an RPM, even the installation of qmail-ldap was easy -
custom patches et al. Getting the spec file right for the rpm was not
so simple, but it meant that I only needed to do the hard work once.

On Wed, Feb 3, 2010 at 7:29 PM, Edward Capriolo <[email protected]> wrote:
> 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.
>



-- 
Scott Ryan
http://bonoboslr.wordpress.com/