Kolab Server Wishlist
From Kolab wiki
Kolab2 WishList
Check the kolab roadmap first, before submitting your wishses here.
submitted wishes
- Support for Jabber or irc to output group messages or calendar events
- Recent screenshots
- Integration of Jabber (Jabberd 2 with ldap authentication and Berkeley DB storage as this does not add additional dependencies)
- Make fetchmail into a standard kolab service
- Create a graphical config section for fetchmail
- Nice interface for sieve (like Ingo from Horde) integrated in the Kolab web-interface. This would be helpful when you want to use another webmail client like roundcubemail or s.th. similar
- Per-User Spam-Settings. I know, there are some possibilities/patches available for amavisd. Of course this should be tweakable from the kolab web-interface (This should go further than just editing the spam-core and subject tag. Whitelisting and Blacklisting should be part of it, for example)
- Maybe one could find a solution for an online-backup.. other than just mounting a lvm-snapshot.
- Adding SMTP-Auth for the mail-relay to the web-interface.. This shouldn't be so difficult
- I think a Kolab Palm Connector would be great
wishes under discussion
Central storing of all data in a database
- Storing especially the emails, calenderevents, etc in a Database. Additionally the connecting should be crypted for security reasons
- The great advantage will be that all data can be stored on a different server behind the DMZ
DNS zone administration, possibly with a web GUI
- Doing the complete DNS admin task in the Kolab web admin gui is currently beyond our scope but we shall make sure that Kolab integrates well with some other LDAP based DNS admin solution
firewall/iptables administration/filtering/shaping
- Overkill IMHO, Kolab's goal is mail/calendaring, not firewalling or DNS server controlling ;)
- overkill now, absolutely, but when kolab becomes multi-domain, it will need some dns tuning I guess. About routing, I think it could be nice to have some integrated tunneling ability beetween kolab servers and slaves, or some VPN tricks for clients.
Integrated support for a mailing-list manager (mailman ?)
- Pro:
- Integrating of something like mailman is an excellent idea mainly because people tend to abuse distribution lists otherwise.
- mailman is mature
- Con:
- It adds a python dependency on Kolab
Note: There is the Sympa_Mlist_Manager_Integration_Howto since the Sympa MList Manager is Perl-based. Developers are working on a default integration.
Ability to list groups that user is in, using webgui
Fully working, will not beat you up and steal your lunch, webclient
"Native" Windows client that is OSS and not outlook
Price of outlook can be very restrictive for smaller companies that use windows.
Ability to change user's sieve scripts logged in as maintainer
- Support for DRAC (pop/imap before SMTP) I have modified my own Kolab to support it, it was not too difficult. Just a couple of settings changes, compilation of the DRAC daemon and compile cyrus with DRAC support.
Integrated tar/gz/bz backup of mailboxes and configuration files plus cron scheduling
A simple script, with optional cron scheduling, that stops the cyrusdb, creates a compressed tar archive at a user defined location, then restarts the cyrusdb service.
Answer: When you have a small installation, the rsync backup on a running cyrus will be rather fast and the inconsistencies minimal. When you have a big installation you should think of creating an lvm partition (logical volume manager) for your kolab. Thus you can generate snapshots of your installation while it continues to run. You can mount such a snapshot and make a backup right away without stopping the cyrus service. IMHO it is more important to keep cyrus running than to guarantee 100,00% consistency. If you need to restore due to a crash you're loosing data anyway. In that situation it's better to have a nearly up-to-date backup than to have a 100.00% consistent backup. Possible data inconsistencies are not a problem to kolab.
Administrate different domains on one machine
Items for the next major version (3.x)
What I would like to see for a next version (3.x),
- apache2 instead of apache
Martin Konold Mainly up to what OpenPKG will be offering in the near future. It has my full support though. Main hurdle will be if the LDAP Apache modules is working properly (It used to be broken with Apache2)
- postfix-2.3 (assuming it has been released by that time). As it comes with functionality required by kolab
Martin Konold Mainly up to what OpenPKG will be offering in the near future. I would really prefer to get rid of our patches
- Renaming of the phplibdir and webserverdir from 'admin' to 'kolab'.
Martin Konold This should be easily doable as it does not affect the clients.
- Perhaps the usage of current horde (components) and not the ones from cvs
Martin Konold Actually we should only maintain patches in our CVS not a copy. Keeping a copy is wrong by design (forking)
- No (email folders) under post in, but just straight under the server
Martin Konold This is easily implemented by the server (alt hierarchy operator), but needs support by the clients. I support this move as an option.
- Middle name support, see issue 606
- The possibility to configure cachedimap and regular imap per email folder, or seperate for the kolab groupware folders (always cached imap) and the email folders (cached or regular imap).
Martin Konold This is pure client feature though not easy to implement
- The possibility that email folder settings just like: 'order by group' are stored on the imap server.
Martin Konold Yes, we need yet another imap annotation for that.
- XML/RPC or SOAP interface.
- Planning for integration with Active Directory in the upcoming Samba versions - centralised authentication and distribution lists/groups the major advantage. Doing that would bring Kolab another step closer to being an exchange replacement.
