[Howto] Sort spam mails to the junk folder in Zarafa

Groupware setups like Zarafa often leave the spam scanning to external tools – but still has to sort the tagged mails. This article shows two ways of sorting and filtering tagged spam mails in Zarafa.

Imagine the pretty common setup where the actual spam filtering is done on a separate MTA. In such cases the spam is scanned and tagged, but the groupware system, here Zarafa, has to sort the mail to the appropriate folders. For example, an e-mail header spam tag created by Spamassassin looks like:

X-Spam-Flag: YES
X-Spam-Score: 64.448
X-Spam-Level: ****************************************************************
X-Spam-Status: Yes, score=64.448 tagged_above=-999 required=6.2
	tests=[ADVANCE_FEE_2_NEW_MONEY=0.992, ADVANCE_FEE_3_NEW=2.734,

The question is how the groupware can auto-sort such mails – Zarafa knows (at least) two ways to accomplish that aim.

The first is to use Procmail, Maildrop or similar tools to check the mails for such tags: all mails are delivered from the separate MTA to Procmail, which forwards all mails to the zarafa-dagent. However, while normal mails are just forwarded to the normal zarafa-dagent without any options, spam mails are forwarded with the option zarafa-dagent -j. That way, zarafa-dagent knows that the mails are spam, and sorts them into the Junk folders. The Procmail configuration for that is for example:

:0 w
* ^X-Spam-Flag: YES
| /usr/bin/zarafa-dagent -j $1

:0 w
| /usr/bin/zarafa-dagent $1

The second way – which I prefer – is to tell zarafa-dagent to look for the spam tag itself. The Dagent can be configured to search for a spam tag flag sorting these mails into the Junk folder automatically. The configuration is done in /etc/zarafa/dagent.cfg:

spam_header_name = X-Spam-Flag
spam_header_value = yes

Please note that the values are case-insensitive.

Which method you use highly depends on your actual groupware setup: in case you already have a Procmail/Maildrop/Whatnot setup you might want to use the first method since it can easily be integrated with the existing setup. In case you do not have or do not want to introduce another layer like Procmail, you should go with the latter method. Also, the latter method is independent of the rest of the setup – so even with a working Procmail setup you might want to use the latter method to have it out of your mind.

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

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.

[Howto] Syncing multiple calendars between Android and Zarafa

Android_robotSyncing multiple calendards between Zarafa (or any other groupware) and Android over ActiveSync is not possible due to limitation in Android. However, Zarafa can export calendars via CalDav, and there is an Android apps which adds CalDav calendars to the native calendar system.

Background: ActiveSync and CalDav

ActiveSync is the Microsoft way of syncing data, and is well established in the business ecosystems and thus also in groupware sync solutions like z-push. However, sharing multiple calendars via ActiveSync is not possible with Android without any special hacks. Additionally, ActiveSync is patented and copyrighted and as as result for each device which is able to sync via ActiveSync a fee is payed to Microsoft.

CalDav on the other hand is an open standard for syncing data, available to everyone for free. Unfortunately, it is not natively supported by Android although many groupware solutions provide support for it. But there are 3rd party apps to add CalDav support to Android.


The zarafa support for CalDav is quickly added by installing the zarafa-ical package. Here is for example the package description on a CentOS/Fedora system:

$ rpm -qi zarafa-ical
The zarafa-ical package includes the Zarafa iCal/CalDAV gateway service
to enable users to access their calendar using iCalendar (RFC 2445/5545)
or CalDAV (RFC 4791) compliant clients. The iCal/CalDAV gateway service
can be configured to listen for HTTP and HTTPS requests.

The configuration is done in /etc/zarafa/ical.cfg. The only really interesting part is if you want to enable ical over TLS or not. After everything is set up, try to reach the calendars of your system via web browser, the address should look similar to https://www.example.net:8443/caldav/testuser/Calendar. Afterwards, create some more calendars to verify later on that everything worked.

Many other groupware solutions offer CalDav support as well, the setup should be equal similar. The beauty in CalDav is that it does not contain any special magic.


Once Zarafa is set up, you can configure the Android client. As mentioned before, Android does not provide native CalDav support, thus a 3rd party app is required. I made quite good experiences with the app CalDav sync beta. While the app does cost 2,55 €, the author does promise to open source the app once it has matured enough.

After the app was installed, you just enter user credentials and server URL and are ready to go:

The synced calendars show up in the Android calendar overview natively, and can be re-used in any calendar app out there which accesses the default Android calendar store:

That’s it, you can now sync all calendars you want, even carious task lists, to your Android mobile phone. It works pretty well for my own Zarafa setup, but we’ve also tested it at credativ with dedicated calendar server in a productive environment.


As a result, the sync between multiple calendars in Zarafa and Android does work now flawlessly. An additional bonus is that you are free to choose the colors of the calendars, in contrast to the ActiveSync implementation where you are stuck with a random color. 🙂

Besides, CalDav is also implemented in groupware fat clients like Thunderbird, KDE’s Kmail and Gnome’s Evolution, and you can now access all data via the same interface.

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.


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.