roundcube's picture

Roundcube Webmail 1.2-beta out now

We’re proud to announce that the beta release of the next major version 1.2 of
Roundcube webmail is out now for download and testing. With this milestone
we introduce new features primarily focusing on security and PGP encryption:

  • PHP7 compatibility
  • PGP encryption
  • Drag-n-drop attachments from mail preview to compose window
  • Mail messages searching with predefined date interval
  • Improved security measures to protect from brute-force attacks

And of course plenty of small improvements and bug fixes.

The PGP encryption support in Roundcube comes with two options:


The integration of this browser plugin for Firefox
and Chrome comes out of the box in Roundcube 1.2 and is enabled if the Mailvelope
API is detected in a user’s browser. See the Mailvelope documentation
how to enable it for your site.

Read more about the Mailvelope integration
and how this looks like.

Enigma plugin

This Roundcube plugin adds server-side PGP encryption features to Roundcube. Enabling this
means that users need to fully trust the webmail server as encryption is done on the server
(using GnuPG) and private keys are also stored there.

In order to activate server-side PGP encryption for all your users, the ‘enigma’
plugin, which is shipped with this package, has to be enabled in the Roundcube config.
See the plugin’s README for details.

Also read this blogpost
about the Enigma plugin and how it works.

IMPORTANT: with this version, we finally deprecate some old Roundcube library functions.
Please test your plugins thoroughly and look for deprecation warnings in the logs.

See the complete Changelog at
and download the new packages from

And That’s the Last of CentOS

Today, I’ve turned off our last two CentOS systems, and now we run Red Hat Enterprise Linux 100% (minus the Fedora workstations), because, you know, amateur-hour be gone!

Regretfully, they were firewalls, meaning at some point a unicorn somewhere may have felt the network failing over. Twice.

What About The Nulecule?

Somebody mentions to me that “struggles” may be a big word for such a small problem, and that mentioning Nulecule in the same breath may not be fair at all.

That person, Joe Brockmeier, is correct, and I hereby pledge to buy him a beer — as I know Joe loves beer — does FOSDEM work for you Joe?

My earlier blog post did not give you any insight on what, how or why I struggled with Nulecule, nor whether the struggle is with Nulecule specifically or orchestrating too many containers with few too many micro-services as a whole.

My Nulecule application is Kolab — the full application suite. It depends on a number of other applications which are principally valid Nulecule applications in their own right. Examples include MongoDB, MariaDB, PostgreSQL, HAProxy, 389 Directory Services, FreeIPA, and such and so forth.

Some of these have existing Docker images. Nulecule applications are available for some of these, or are easily made in to Nulecule applications. Some are slightly harder to encapsulate however, and I’ll take one example to illustrate the point; 389 Directory Server.

Complex and Custom: 389 DS

A default 389 Directory Server installation falls just short of what Kolab requires or desires to become fully and properly functional;

  • Schema extensions provide additional functionality,
  • Anonymous binds should not be allowed,
  • ACLs should be more restrictive,
  • Better passwords should be allowed than only 7-bit ones,
  • Access logging is I/O intensive and less important than Audit logging,
  • Additional indexes on attributes included in the schema extensions need to be created,
  • Service- and Administration accounts and roles need to be created.

To facilitate this particular form of setting up 389 Directory Server, we currently ship our own version of /usr/share/data/dirsrv/template.ldif, in which we substitute some values during initial startup.

The Nulecule Struggles

I’m working on enabling continuous deployment with help of Nulecule, so that I can have my developer’s edges as well as a series of central environments entertain deployment based on the same triggers.

For those of you outside the inner circle, Nulecule is supposed to abstract deployment to different cloud orchestration providers, whether vanilla Docker, something assisted by Kubernetes, or something as fancy as OpenShift.

In the Kolab Groupware world, orchestration of micro-services is no new challenge. We operate many, many environments that deploy “micro-services” based on (fat) VMs, but the way this works based on (thin) containers is different — there’s no running Puppet inside a container, for instance, or if there is, you’re doing it wrong.

So, aside from the fact we know what our micro-services are across the application suite, the trick is in the orchestration. I have some 25-30 micro-services that require access to a service account’s credentials, because we do not normally allow anonymous binds against LDAP (any exploit anywhere would open you up to reconnaissance otherwise). Currently, setting one container to hold and configure those credentials in a canonical authentication and authorization database and distributing those credentials to the other 24-29 containers doesn’t seem possible without the user or administrator installing Kolab using containers specifying the credentials 25-30 times over.

On a similar note, it is currently not possible to specify what volumes for a Docker container are actually supposed to be persistent storage.

The point to take from this is to appreciate that Kolab is often at the forefront of technologies that have little to do with bouncing back and forth some emails among people that just so happen to share a calendar — in this case specifically, we’re abusing our use-case’s requirements with regards to orchestration to direct the conversation about a unified format to describe such requirements.

Some Roundcube UI improvements on Files

Recently I implemented a couple of improvements that are related with files storage. It’s better access rights support and storage integration with more components.

Add attachments “from could”

It was already possible to attach files from file storage in email compose page. Now you can also get files “from cloud” in event and task creation/editing forms.

Figure 1. “From cloud” button in event dialog.


Read-only folders

As for now the user interface where folders from file storage were used wasn’t aware of folder access rights. Now it’s changed. Chwala API provides information about access rights. So, the folders list displays a locker icon for read-only folders. Also, when you use “Save to cloud” feature, the list will contain a list of writable folders only. Additionally, any write operations (like file upload, delete or move) are prevented by the UI, which means e.g. some buttons are inactive in read-only folders.

Figure 1. “From cloud” button in event dialog.


Kolab, SSO and Second Factors

Kolab Groupware is a collaboration suite establishing the integration of various applications you know already; Most prominently, these include 389 Directory Server, Postfix, Cyrus IMAP and Roundcube. Together, these applications would comprise a simple mail system that, in terms of functionality, would fall short of “groupware” and “collaboration” functionality.

Side-note: Cyrus IMAP has added CalDAV, CardDAV and WebDAV capabilities, encroaching on the territory Kolab otherwise occupied, rather exclusively, for as far as the world of Free Software is concerned. As such, Cyrus IMAP provides more of the groupware functionality than I initially stated, but does not provide ActiveSync capabilities, a web-mail client interface, Resource Management, and many other facilities included with Kolab Groupware. Inversely, however, Kolab is going to need to show to be the most adaptable, and applaud and welcome and embrace these developments in Cyrus IMAP, rather than attempt to compete with it somehow.

This blog post is about Single Sign-On and second factor authentication, however, and where and how these fit in with Kolab.

First, we need to clarify the terminology, because SSO and 2-factor authentication both mean different things to different people.

Single Sign-On

Single Sign-On is the functionality in which a complete infrastructure of services provided allows you to authenticate precisely once, and only ever once, from which point on forward you are trusted to have identified yourself — contrary to where you can use the same credentials over and over against different services, but you have to fill out and submit your credentials again and again to create valid sessions.

The ability to use the same credentials everywhere is usually achieved by making individual applications use the same authentication and authorization database in very much the same way — usually LDAP in some form or the other, or a SQL database. In principle your credentials fly over the wire time and time again in exactly the same way they would otherwise, they just happen to be the same credentials every time.

A Flask Mega-Tutorial: Intermezzo II

I now have a bit more information on what it is I will be achieving, and I wanted to share the roadmap and horizon of the project I’m undertaking.

The software development project is called PACK — a portal or panel for administration of Kolab Groupware. For our current most important deployment, Kolab Now, this involves customers and accounting features. This would include, for example, a Web Administration Panel and a Customer Control Panel.

For the purpose of this intermezzo, we’ll simply state that some parts of the overall application suite address different needs for different audiences in different deployments. To illustrate, an on-premises installation likely has little need for third parties to be able to autonomously register themselves as customers. However, depending on the internal accounting practices of such organization, a department may need to fork over part of its budget to the IT department for providing them with collaboration services.

That being said, I’m in for quite a lengthy and complex project. On the horizon may be a rather complete encapsulation of quite a few too many things to include in a first few milestones.

As I’ve mentioned before, I’m following my own learning curve. There’s some troublesome areas in Flask and its extensions, where modelling of the applications to include multiple features based on multiple extensions is tricky. One such example is including localization (l10n), internationalization (i18n), themes, assets and caching in to one application.

Furthermore, the extent to which we wish to include features makes it very difficult to come up with a data model and database design that encapsulates everything.

So, where do we get started? Well, the use-cases that are top of mind are limited to those we have for Kolab Now and Kolab Enterprise. This means we let individual users register or sign up, and subscribe to entitlements on product offerings. This includes a nice little range of offerings, such as;

Timotheus Pokorra's picture

New Roundcube 1.1.3 release for Kolab 3.4 Updates

There has been a new release of Roundcube:

I noticed that because Epel already has version 1.1.3, but Kolab 3.4 Updates still has 1.1.2. Now there is an installation conflict, because yum wants to use the epel version, but that leads to other conflicts.

A temporary solution is to exclude all roundcubemail* packages in the epel repo file:

sed -i "s#enabled=1#enabled=1\nexclude=roundcubemail*#g" /etc/yum.repos.d/epel.repo

The proper solution is to upgrade the roundcubemail package for Kolab 3.4 Updates on OBS.

I was slightly confused which tarball to use, and Daniel Hoffend aka dhoffend helped me out:

Enigma plugin (PGP encryption)

In this article I described how we implemented client-side encryption in Roundcube using Mailvelope. There’s another approach for encryption, it is the Enigma plugin. It implements all the functionality using server-side GNUPG software. So, the big difference in these is that: Mailvelope keeps your keys in the browser, Enigma stores them on the server. In the current state Enigma however, has a lot more features.

Installation and settings

To use Enigma just enable it as any other plugin. Then in Preferences > Settings > Encryption you’ll see a set of options that will give you possibility to enable/disable encryption-related features.

NOTE: As keys are stored on the server, make sure the directory used as a storage has proper permissions, and it’s good to move it somewhere out of the location accessible from the web (even if secured by .htaccess rules).

Figure 1. Encryption preferences section.

Keys management

To manage your keys goto Settings > PGP Keys. There you can generate a new key pair or import keys. See the following screenshots for more details.

Figure 2. Key generation form.

Figure 3. Key information frame.

Mailvelope integration (PGP encryption)

The most valuable feature of incoming Roundcube 1.2 release is PGP encryption support. There are two independent solutions for this, Enigma plugin and Mailvelope. In this article I’ll describe what we achived with Mailvelope. The integration code was mostly written by Thomas Brüderli and only slightly improved/fixed by me.

It looks like Mailvelope is the best (if not only) solution for encryption in a web browser. It’s based on OpenPGP.js that is an implementation of PGP encryption in JavaScript. Mailvelope is distributed as Chrome and Firefox extensions. It supports some email services like GMail, it also provides an API for programmers. And this is the way we decided to integrate it with Roundcube.

Mailvelope installation

For more info goto Mailvelope documentation. To have it working with Roundcube you have to install the extension in your browser, then goto your Roundcube webmail and using Mailvelope “Add” button add your page to list of mail providers. One last required step is to enable API use on the provider edit page.

Compose an encrypted message

If Roundcube detects enabled Mailvelope, new button will appear in compose toolbar. It may be disabled in HTML mode, so switch to plain text. If you click it Mailvelope frame will appear. There you can write your message and add attachments. As you notice on the screenshot some features are disabled. Unfortunately, at the moment we can do much more with the Mailvelope textarea. Note: to send an encrypted message you first have to import/generate a private key in Mailvelope settings.

Figure 1. Message compose screen with enabled encryption frame.

When you try to send a mail to an address for which no public key was found in the Mailvelope database (keyring), you will be provided with possibility to search public key servers and import the keys.