[Kolab-devel] Mailinglist Manager sympa? Mailman?

[Bernhard Reiter]

Am Freitag, 30. Dezember 2005 13:01 schrieb Fabio Pietrosanti:
> Martin Konold ha scritto:
> >Technically I consider mailman to be more advanced but the language issue
> >remains. Though python is a mature language and I can easily imagine to
> > use it in more places.
>
> Let me say to consider the sympa mailing list manager
> http://www.sympa.org which is very stable (they are 5.1 release),
> written in perl, well integrated into ldap and with very advanced
> features such as "Dynamic Mailing List" and "S/MIME Mailing List".
>
> Integrated with ldap in two ways i'm going to describe:
>
> 1) Ldap autentication
>      Kolab users would be able to authenticate directly on sympa web
> admin interface using their password. In that way sympa webadmin
> interface functionality could be integrated directly within kolab
> webadmin interface. (It also support administration trough SOAP!)
>
> 2) Single Sign On
>     Allow very easy integration within other web framework of the sympa
> webadmin interface.
>
> 3) Dynamic Mailing List
>     I just added to the Sympa integration of the Kolab's Wiki the
> support of Dynamic Mailing List.
>     Dynamic Mailing Lists are a special kind of lists managed by sympa
> that use as a "source" for the "subscribed users" an ldap backend.
>     I already used the "Distribution List" of Kolab on a specific domain
> for Dynamic Mailing List, managed by sympa so i don't need to access
> sympa web interface but i can managed subscribed users directly from the
> kolab webadmin interface.
>    I added the dynamic mailing lists feature to  the wiki at the end of
> the page:
> http://wiki.kolab.org/index.php/Sympa_Mlist_Manager_Integration_Howto

I think all three point will quite easily be integrated with Mailman, too.

> >How much integration of mailman into Kolab should we aim for?
>
> Which are the main reasons to use mailman?

It is not using an RDBMs like sympa. ;-)

> Imho we should do a comparison of the various mailing lists managers to
> find out which is the better choice for the kolab strategy. (obviously i
> find out very well integrated and working sympa...) :>

We could also keep it modular for Kolab, as many features of Kolab are 
currently orthogonal to other components.
Also it is a question of what Kolab is targeting in principle,
people that want a project server (something like Gforge)
might better use this. Most of the time mailinglists are run when you have 
many external people involved. I guess I have to learn more about what
people actually want to use this for before I can really tell what would be a 
good solution.

Bernhard