Many of you have anxiously anticipated the return of shared folder management in Kolab 3 - a feature that is often used for email addresses with multiple readers, such as perhaps a sales@company.com or info@example.org.

A large part of this functionality - as often requested - has been the ability to delegate to individual users the use of the recipient address associated with these shared folders.

Your sales representatives would read incoming sales@company.com email through a shared folder (say, shared/sales@example.org), and have the ability to not respond as themselves (i.e. with their own user email address as the envelope sender), but "on behalf of" sales@company.com, using that very address as the envelope sender.

I'm pleased to announce this functionality will be a part of Kolab 3.1 - I sat down yesterday, in my own time, and enabled the Kolab Web Administration Panel client interface and API to handle shared folders. Needless to say I also made sure that PyKolab (or, should I say, its setup-kolab utility for bootstrapping your brand new Kolab server) is aware of the changes required to Cyrus IMAP and Postfix.

To show off this shared folder functionality, I've created a screencast using a vanilla Kolab 3.0 deployment, and some magic commands to pull in the latest and greatest PyKolab and Kolab WAP directly from their respective GIT repositories.

Furthermore, yesterday's exercise brought me to also show off the new "dynamic distribution group" functionality - now exposed in the Kolab WAP, and re-inserted "allow" and "deny" recipients and senders to groups. You would, for example, create a kolab-users@example.org distribution group that, rather than a static list of members, holds a search query for all "(objectclass=kolabinetorgperson)" LDAP objects, hence creating a dynamic distribution group. Useful for announcements, but limit who can send to the distribution group using the "kolabAllowSMTPSender" attribute.

As written in my last blog, Kolab 3 for openSUSE almost ready for production. I set up test server for my company as well as for my private use and they're running - issues I encounterd have been fixed in the mean time.

Progress since week 9

• I did various fixes for kolab-cli and kolab-imap.
• kolab-scripts has been updated as well and makes installations a lot easier.
• 389-ds-base got a fix to also start its instances when started.
• 389-* has been pushed into network:ldap
• My test systems are up and running, the major features of Kolab 3 all seem to work (I still have to finish some tests)

All packages are built and packaged on OBS (server:Kolab:UNSTABLE and server:Kolab:Extras). The repositories can be easily added via zypper or YaST.

Tasks

• Wiki pages on opensuse.org need proper updates.
• There are plans to provide support for OpenLDAP - this includes schema, packages and dependencies.
• There are also new plans to provide support for Dovecot.
• Tests on my test systems have to be completed (including send/receive mails, tasks, calendars, ActiveSync and everything).

If you want to help, to contribute, to test Kolab 3 on openSUSE or if you encounter a bug, don't hesitate to contact me.

Today I'll summarize what happend the past two weeks - I was pretty busy and got Kolab 3 for openSUSE almost ready. Still a few things need to be taken care of: full testing is neccessary to ensure everything is working and pre-checks have to be implemented.

Progress since week 7

• libcalendaring is ready for SLE 11 SP2.
• libkolabxml builds on SLE 11 SP2 (with disabled php and mono bindings).
• libkolabxml 0.8.3 has been released.
• server:Kolab:Extras provides cyrus-imapd 2.3.18 with Kolab patches enabled and LDAP support.
• 389-ds now is build with OpenLDAP instead of mozldap, fixing bugs in 389-admin.
• perl-Mozilla-LDAP has also been rebuild with OpenLDAP instead of mozldap.
• An issue with saslauthd has been fixed, preventing users from authentificating.
• A package called kolab-scripts has been introduced to server:Kolab:UNSTABLE, (in near future) containing scripts to aid Kolab developers. Currently, this package only contains a script called prep-setup-kolab, that updates your system, checks for a valid FQDN and creates a certificate authority and server certificates. I'll try to include some handy scripts from git.kolabsys.com
• A few bugs in kolab-mta (preparing main.cf) have been fixed.
• Amavisd has been updated to 2.8.0 and has just been released with openSUSE 12.3-RC2.
• amavisd.conf.tpl has also been modified to match openSUSE configurations.
• kolab-syncroton has been updated to 2.1rc1.

All packages are built and packaged on OBS (server:Kolab:UNSTABLE and server:Kolab:Extras). The repositories can be easily added via zypper or YaST.

Note: Some of the new packages are currently not available in the repositories, as the build hosts are pretty busy with openSUSE 12.3 being released in less than two weeks.

Tasks

• It's still our wiki pages on opensuse.org - they need to be updated.
• There are plans to provide support for OpenLDAP - this includes schema, packages and dependencies.
• There are also new plans to provide support for Dovecot.
• Now that we're done with cyrus-imapd, it's time to have a look at postfix and verify, that this is working with Kolab on openSUSE.

If you want to help, to contribute, to test Kolab 3 on openSUSE or if you encounter a bug, don't hesitate to contact me.

During the last month of running Kolab 3.0 on my Debian server, I tweaked some settings for anti-spam fighting. Here is what I did and what you can do to have your Kolab 3.0 inboxes as spam-free as possible.

Greylisting

Stopping spam before it enters the queue is a good thing. One way to achieve this is Greylisting: Reject a triplet (sending host, sender address, recipient address) on the first deliver attempt with a temporary error (450 4.2.0 <tobias@tobrunet.ch>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/tobrunet.ch.html) and save this triplet. On the second delivery attempt check the triplet against the database and if it matches, allow this message to be delivered. This stops many spam senders because they only try it once. A correctly configured MTA tries it again after a few minutes and the mail is delivered.

A drawback of this mechanism is that an email which is sent for the first time has a longer delivery time and if you have impatient users, they won’t like it. It’s also possible to lose emails if the sending MTA is not correctly configured, but then the sending MTA has probably other problems and could be a spam sender.

Installing and configuring postgrey

Implementing Greylisting on Kolab 3.0 running on Debian is very easy:

1. Install postgrey: apt-get install postgrey
2. Add postgrey policy filter to Postfix by editing main.cf and adding check_policy_service inet:127.0.0.1:10023 to smtpd_recipient_restrictions at the end of the list (restart/reload postfix after this change)
3. Check you mail.logif postgrey is acting as expected:
   

   Feb 25 20:31:56 james postgrey[3211]: action=greylist, reason=new, client_name=mtasender.domain.com, client_address=123.52.23.32, sender=sender@domain.tld, recipient=tobias@tobrunet.ch

A nice Blog post on Debuntu explains some parameters which can be tweaked for postgrey

Spamassassin

On a default Debian installation, Spamassassin is not enabled in the Amavis configuration. This is too bad, because Spamassassin can help to stop many spam emails. To enable Spam scanning in Amavis, remove the comment before @bypass_spam_checks_maps in the file /etc/amavis/conf.d/15-content_filter_mode and restart amavis. Spamassassin has to be trained with spam and ham. There is some good documentation about that topic in Chapter 6. Combating Spam of the official Kolab 3.0 documentation.

Blacklists

RBL blacklists (Real-time Blackhole Lists) helps to block known spamming IP addresses at the SMTP conversation level. All configured Blacklists will be queried (using DNS) to check if the connecting IP of the MTA is listed on the Blacklist. The sending MTA is then blocked with a hard error, f.e. 554 5.7.1 Service unavailable; Client host [190.190.76.151] blocked using zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=190.190.76.151

RBL configuration

RBL blacklists are directly integrated into Postfix and are configured in main.cf:

submission_recipient_restrictions = [...] reject_rbl_client zen.spamhaus.org, reject_rbl_client ix.dnsbl.manitu.net, reject_rbl_client bl.spamcop.net, [...]

I’m using Spamhaus, IX and Spamcop blacklist at the moment, as I’ve made good experience with them. Wikipedia hosts a comprehensive comparison table of RBLs: http://en.wikipedia.org/wiki/Comparison_of_DNS_blacklists

Backup MX

One of the best things I could do in fighting spam was removing the backup MX record from DNS and not use any backup MX anymore.
The reason is the backup MX did not have any spam fighting technologies and did not know anything about the primary MX (available mail addresses, greylisting triplets, …). This is the case on many backup MX systems and spam sender know that. So they startet to send spam directly to the backup MX which accepts all mails without scanning and delivers it to the primary MX. The primary MX is then accepting mails from a well known good mail server and did not have the possibility to identify spam as good as if they were sent directly to the primary MX.

In my opinion a backup MX is not necessarily needed. A well configured MTA should retry sending messages for several days if it could no deliver it on the first attempt until it’s returned to the sender. The primary MX should be up again after a few hours or within a day, so there’s no need for a backup MX.

Anti-Virus

Scanning E-Mail for viruses should be done on the MTA to stop malware from entering the system. Virus scanning is done in Amavis using Clamav, but on Debian it’s disabled by default. To enable it, remove the comment before @@bypass_virus_checks_maps in the file /etc/amavis/conf.d/15-content_filter_mode and restart amavis. The user clamav needs to be added to the amavis group so that the permissions are correct (restart clamav and amavis).

Kolab 3 has built-in ActiveSync support, using Syncroton. It’s integrated into Roundcube, all settings can be done using the Webmail client. Installing it is very easy on Debian Wheezy: apt-get install kolab-syncroton

If Kolab 3 is already installed and configured (setup-kolab already done) the database needs to be imported by hand: mysql -p roundcube < /usr/share/doc/kolab-syncroton/syncroton.sql If kolab-syncroton is installed before running setup-kolab, the database will be populated with the tables.

To check if ActiveSync is working fine, open http://yourserver/Microsoft-Server-ActiveSync and log-in with an available account. It should display It works! Your userid is: 2 and your IP address is: x.x.x.x.
Logs are written to /var/log/roundcubemail and $rcmail_config['activesync_debug'] can be added to main.inc.php to increase logging.

Just add the account to the mobile device and all E-Mails, calendar entries and contacts will be synced. In Roundcube -> Settings -> Activesync the new device should appear and can be individually configured. It’s possible to set the device name and choose which folders should be synchronized.

Basically it works great, but there seems to be a bug when synchronizing with a modern Samsung Android device (such as a Galaxy Note or Galaxy S3). All E-Mails are marked as encrypted and can’t be read. A Bugreport about this is already filled.
Another problem I found is synchronizing contacts with a Nokia N9. It seems not possible. Maybe SyncEvolution will do it.

A few weeks ago, the OpenSource Groupware Kolab 3 has been released. It features a brand new Webmail client based on Roundcube (which is really very nice), a completely new web based administration panel (called WAP – Web Administration Panel), integrated ActiveSync with Syncroton and an updated storage format. Many other things are new, compared to older Kolab versions, but the greatest improvement under the hood – in my opinion – is the replacement of OpenPKG with distribution specific packages. This makes it much easier to deploy and update.

The people behind Kolab are working with Redhat, so the original packages are RPM based. But thanks to the great community, Debian packages for Wheezy are also already available. The official installation documentation covers Debian Wheezy already, but I’d like to provide my experience and a short installation How-To. This helps to have a quick installed up-and-running Kolab 3 installation running on Debian Wheezy.

Installation Steps

1. Install Debian Wheezy (It’s OK to use the 64Bit version)
2. Add the package sources to /etc/apt/sources.list.d/kolab-3.0.list
   

   deb http://mirror.kolabsys.com/pub/debian/kolab-3.0/ wheezy release updates
   deb-src http://mirror.kolabsys.com/pub/debian/kolab-3.0/ wheezy release updates

3. Prefer Kolab packages over the original ones. Add to /etc/apt/preferences.d/kolab
   

   Package: *
   Pin: origin mirror.kolabsys.com
   Pin-Priority: 501

4. Install packages (they are not signed!): aptitude update; aptitude install kolab
5. Provide a MySQL root password
6. Run setup-kolab
   • It’s easiest to accept all provided default settings
   • Choose “1: Existing MySQL server (with root password already set).” to enter the chosen MySQL root password
7. Check the installation, run kolab list-mailboxes  it should exit without an error. If you get the error cyruslib.CYRUSError: (10, 'LOGIN', 'Invalid user'), just restart the server to re-initialize all services (sometimes the installler does not restart all services)
8. Now you can login to WAP on http://<yourserver>/kolab-webadmin with the user “cn=Directory Manager” and the password provided during setup-kolab (“LDAP Directory Manager”)
9. Create a user and give him the role “kolab-admin”. This is now the Admin user for the domain

That’s it, the Kolab server is now up-and-running. Just change the MX record pointing to this server and Kolab will be happy to receive mails.

Today is a great day for user's freedom! Still, many people are storing their private data in the cloud on servers they have little reason to trust. They don't want to give others access to their data. It is just so convenient to have all your data available everywhere without hassle. Currently, you basically can choose to hand over your data to either Google or Apple. Companies on the other hand are locked into the Microsoft monopoly and find it very hard to migrate to Linux.

Taking Control of the Cloud

This is now changing, because today the Kolab Groupware Solution was released in Version 3 making it easy for you or an organization of your trust to set up a Kolab Server. You can access your data with your Smartphone (Android, iPhone, etc.) without the data being stored on third-party servers. There's also a web client that integrates Roundcube nicely and several other clients for your desktop with are available full offline-capabilities.

If you need a real Cloud that is more than just data storage with elasticity and scalability, then Kolab is also for you: All of its functional components can be scaled up and down separately based on the requirements. This enables you to set up your own private Cloud.

Escaping the Monopoly

Kolab development was initially funded by the German Federal Office for Information Security and built as a Free Software Microsoft Exchange killer. Now a company called Kolab Systems picked up the Open Source and is offering it as a product. They are competing directly with Microsoft and their goal is to get rid of the last barrier that keeps many companies and organizations from migrating to Linux Desktops: Outlook and Exchange. They do so by employing 100% Free Software and Open Standards allowing competition that grows an ecosystem in which Microsoft can not survive on the long term.

The best thing is: Every Dollar that this Free Software Company makes goes directly into the development of Free Software that you can use as you wish and even start your own business with. Unsatisfied with the poor quality of Open Source? Get yourself some professional Free Software pay for it and let everybody benefit from fixed bugs and new features! If you don't have this kind of money? Fine, just use the software for free and contribute in other ways!

Kolab Groupware has a strong focus on security, and data integrity - not just your own mailbox but the flow of traffic between you and your peers as well.

Please allow me to take the opportunity to explain to you some of the background of what Kolab Groupware does, and why. In this blog post, I'm zooming in on our use of the submission port (587).

There's a standard 3 ports associated with receiving email messages:

1. Port 25/tcp, or SMTP, which a mail exchanger uses to receive email from the Internet, and from other systems in your network that need to use this mail exchanger as their smarthost (conditions apply). Most commonly, port 25 accepts messages from the Internet for local recipients, or mail traffic from trusted systems inside your network, that are destined for the outside world.
   Typically, no authentication is required, and the envelope sender of a message is not guaranteed to actually be the real human being that would receive your reply should you reply to the envelope sender address.
2. Port 465/tcp, or SMTP with implicit SSL a.k.a. SMTPS a.k.a. SSMTP, which a mail exchanger rarely uses to receive messages from the internet, and only sometimes uses to receive messages from other systems on your network.
   Usually, the internal network is considered as trusted (to some extent). You would want to use SMTPS in networks where the network is not trusted, perhaps including requiring authentication using client-side SSL certificates. At the very least, the implicit SSL nature of SMTPS ensures the communication stream is encrypted.
3. Port 587/tcp, or Submission, which is intended for use by actual human beings. This is the service Kolab Groupware chooses to make use of.

You would not want to use ports 25 nor 465 for submission of data from your groupware users, because both usually include bluntly allowing what is called $mynetworks - the list of IP Address (Spaces) that are trusted networks.

To illustrate, consider the following; You have a LAMP stack that sends out notifications to subscribers via the SMTP port number 25 on localhost. The envelope sender could be something like apache@example.org or noreply@example.org. You would typically have configured (it may actually be the default configuration) "mynetworks = 127.0.0.0/8". The setting "smtpd_sender_restrictions" or "smtpd_recipient_restrictions" typically includes "permit_mynetworks".

Now you install an awesome webmail program called Roundcube, and you configure it to use localhost:25 as its SMTP server. Anyone able to log in to Roundcube is now able to configure an identity with any envelope sender address making messages sent out using that identity appears as if they were coming from that actual envelope sender.

So, joesmo@example.org could now send messages pretending to be the CEO of Example.org, Inc., simply by adding an identity of "The Bossman <ceo@example.org>", and would go completely unchecked while doing so.

What you can't do is restrict $mynetworks further than 127.0.0.0/8 - your LAMP stack would fail attempting to send messages to your subscribers.

You will want to use a service that does not trust *anyone*, *requires* authentication and *enforces* the user sending the message is authorized to send messages using the envelope sender address of the very message.

I say "authorized to send messages (...)", because one feature that you may need is delegation; the secretary sending a message or two on behalf of the bossman is not a very uncommon scenario.

This is where Kolab Groupware kicks in. We implement pieces of software you are probably already intimately familiar with, and then take it up a notch.

It will not accept messages appearing to originate from an envelope sender address that is within a local domain name space from anyone or anything, unless the actual sender is verifiably authorized to send using the envelope sender address the message will appear to have come from, or unless the sender system is explicitly trusted.

By means of a demo, at Kolab Systems itself, not only do we run a couple of Kolab Groupware deployments, but we also service some mailing lists for third party Free Software projects - hence I can only verify the actual envelope sender address, and not the domain name space:

$ (
>     sleep 1
>     echo "HELO $(hostname -f)"
>     echo "MAIL FROM: vanmeeuwen@kolabsys.com"
>     echo "RCPT TO: vanmeeuwen@kolabsys.com"
>     echo "DATA"
>     sleep 1
>     echo "Subject: Nice blog post, thanks"
>     echo "Hey there,"
>     echo ""
>     echo "I think your blog post is awesome."
>     echo "."
>     sleep 1
>     echo "QUIT"
> ) | telnet ext-mx01.kolabsys.com 25

Then do the same against your own SMTP server, with a set of address of your own.