Howto: Extracting entire mails in mbox format from Zarafa [link]

Tux
A Zarafa groupware does workin complex setup you most likely have spam filtering software like Spamassassin running on the main MTA in front of Zarafa. Modern spam filters however need to be trained with ham and spam examples – and Zarafa has no simple way to export stored mails in a txt or mbox format, and the database does not store mails but mapi objects.

Luckily, a coworker of mine here at credativ has written a script to extract mails from a Zarafa to mbox as long as some header information are known: [Howto] Zarafa mail extraction.

Advertisements

Open Source Groupware checklists

TuxIn the last months and years I had to deal with various requirements people have regarding groupware ecosystems. Open Source solutions have matured in this area and this article highlights some needs, but also some common pitfalls.

Preface

In these days there are many excellent Open Source groupware solutions out there. Two well developed solutions I saw in several productive environments are Zarafa and Open-XChange. Both of them are ready to replace Exchange in various productive setups, and I have seen both being deployed successfully as either Exchange replacement or even as a fresh groupware installation for growing offices and working groups.

Also the connection to the mobile world is common as well these days – thanks to z-push and the likes. Yes, there are some licence issues and I would prefer to use a CalDav solution. But ActiveSync works with open source tools pretty well.

However, there are still weaknesses in the Open Source groupware ecosystem. A big one is the Open Source fat client. Most of the clients (Evolution, Thunderbird and Kmail) do not work flawlessly with the currently available Open Source groupwares. Most of the services these days move to web clients anyway, but it is sad to see that there is hardly a well working groupware server fat client setup out there.

For example, in my personal working spaces I do need to sync Evolution with Zarafa, and KMail with OX. And in both setups there are components which do not work at all.

The needs

To better estimate the quality of a groupware solution here is a list of what such a solution should be able to provide:

  • Multiple address books and their synchronisation.
  • Multiple calendars and their synchronisation.
  • Different user rights per calendar.
  • The ability to overlay different calendars on the client side.
  • E-Mail-Invitations for appointments.
  • Free/Busy lists for other users, visible in the calendar view.
  • Collision handling whenever the problem comes up.
  • Centralized web interface for all components,
  • Support for sync of ToDos.

There is no need that one server does that all on its own. The address book could be delivered by ldap, and there are good calendar servers out there like DAViCal.

But even if this list does look pretty normal, some of the points are not covered by the solutions out there. For example: You cannot share multiple calendars with your Zarafa server and your mobile phone without using some ugly hacks. Also, the collision handling is often automatically, the user does not even notice any problems. Another problem is that hardly any solution can sync ToDos properly. And, of course, hardly any of the solutions out there supports Linux based fat clients properly.

Some common tests and problems

But even if a groupware solutions states on paper that it fulfills all the mentioned needs, it might fail in the day-to-day routine. Thus here are some quick tests and common problems which can be checked on demo or test installations to get a first impression:

  • Are multiple-day, recurring events synced correctly?
  • Are multiple-day, recurring events still correct after changed again and again on both sides?
  • Create a calendar with 40k entries, and sync it. How long does the re-sync take after some changes?
  • Are ToDos synced together with their due dates?
  • Let user B alter calendar entries of user A and check if these changes are properly synced.
  • Create a collision on purpose: is the problem solved or is the entry doubled? Is the user notified of the collision?

As mentioned, this list is just to get a first impression. If you are going to become serious about a new groupware, you have to analyze your workflows, and test the groupware ecosystem against these. I must say that most often the biggest challenge actually was to comprehensively identify all workflows! So don’t underestimate the importance of that, and how much time that task takes.

And, with all these tests: keep in mind that sometimes flaws only begin to show under heavy load. Don’t test with two calendar entries and one address book entry and be happy because that minimum setup works!

The solution

As with most real world setups, you should work two-fold: first, check what features you really need, and compare them against the stated features of each groupware ecosystem. Afterwards, pick the survivors and test them against the workflows you have in your daily routine. Don’t trust and hope.