Quick review of mailserv, the OpenBSD Mail server project

       1248 words, 6 minutes

My actual Mail system is running OpenBSD. I use the good old “put the bits together and rule the configuration files” way. But there are some times when I fell like a Web GUI would be nice. I never liked solutions like Zimbra or Zarafa so much because they were quite restrictive bundles - it terms of which backend could be use. But that’s what they’re selled for: bundles.

Let’s have a look at what mailserv does and how.


The installation is quite straight forward. Have a look at the “How to install” section on the main page of the project. Basically, you have to install a bare OpenBSD system (I used 5.1/i386 on VMware Fusion) and the GIT binary package, synchronize the GIT source tree and run the installation script. That script will take care of installing the required dependancies, using binary packages.

First thing that doesn’t look so good to me is that it installs a lot of things on a production server. And it installs both back-end and front-end services (Mail, Web, Postfix, ClamAV, Dovecot, MySQL, NGinx, PHP, Ruby…).

The installation script let’s you choose whether to use PHP 5.2 or 5.3 packages. AFAIK, 5.2 is not maintained any more and is more sensible to security.

Then, all the post-configuration is printed on stout but will be drowned inside the long output of packages adding.

At the end of the installation process, you have to create “an Administrator to the system” and are then advertised to “browse to port 4200 to continue setting up Mailserv”.

The management GUI

Once the installation is done, browse to https://server_ip:4200/ and enter the administrator credentials.

The dashboard gives you summary of the system state. You get system metrics, running processes and mail statistics. BTW, it seems all the post-configuration steps have been done automatically as Postfix, for example, is running properly on the system. Having a look at root’s crontab, you’ll notice a rrdmon-poll script that is supposed to update the various RRD databases.

The “Statistics” page is an AWstats output for E-mail processing.

It will be updated every 15 minutes from the cron-stats script configured in root’s crontab.

From the “System” menu, you can manage the administrative accounts. Those accounts seem to have the same privileges as the “admin” user that was created during installation. And they are not created in the passwd system but in the MySQL database. If you use the mailadmin/mailadmin credentials to log-in the DB system, you’ll notice a “mail” database and its “admins” table containing your admin credentials… with password stored clear… hum… cough cough…

You can also change the hostname, network and DNS configuration from the Web GUI. Although the network configuration seem pretty simple ; no bridge, no carp, no alt, no trunk.

The NTP can be configured from the GUI too. The strange thing was that ntpd was running, as I configured it from the installation wizard, but was not “enabled” from the GUI. The timezone was correct though as was the NTP server I configured. If you check the “enable” checkbox and save the settings, the ntpd.conf is updated and the ntpd daemon is restarted. Note that you will loose comments for “listen” and “sensor” keywords.

The “Logs” menu entry prints a set of log files that can be scrolled and copy/paste from the GUI.

You can use the search feature of your browser to look for a particular thing ; but are limited to its (regexp) capacity.

The “Certificate” menu entry shows current installed certificate. You can upload a certificate from there and/or issue a CSR. The “Common Name” field cannot be changed ; it is set to hostname. You won’t be able to create a CSR from there if you need the public service name to be different from the actual hostname.

Finally, the “System” menu provides an item to shutdown or reboot the server.

The “Mailserver” menu will guide you to the e-mail server configuration.

Mailserver configuration

The “Mailserver” menu is where you’ll be able to configure e-mail domains and users, anti spam and UCE configuration and mail transport.

From the “Users & Domains” menu, you can define your mail domains, users and aliases.

The management is indeed very simple. “Edit” a domain to modify it’s name and quotas. “Manage” a domain to add/remove/modify its users and aliases. Users and aliases can be imported from CSV: the CSV format is “name,fullname,password,quota” and is explained when you click the “Import CSV” button.

In case you have thousands of users, a “Search” option allows to highlight a particular account.

The “Antispam Configuration” is quite simple.

One feature I used to use with SpamAssassin is the language content allow/block. It was very useful when you only want to receive email for one or two languages.

You can create “Whitelisted Servers” from the “Greylisting” menu although I didn’t get why I would do this as there doesn’t seem to be any greylist system configured… There’s a sqlgrey daemon running but postfix doesn’t seem to be linked with it.

The “Mail Routing” section allows to configure mail transport.

Unfortunately, it doesn’t allow transport for domain that you didn’t configure in the “Domains” section. So you first have to register the domain, with or without users/aliases, before being allowed to setup the routing.

The user GUI

Managing e-mail is one thing. But what about reading e-mail. You’re supposed to browse to https://server_ip/ and be redirected to some /webmail/ sub-directory. In my case, I got a “502 Bad Gateway” error. According to the (“httpd.err”) logs, I faced the “unix:/tmp/php.sock failed (2: No such file or directory) while connecting to upstream” error…

I issued a god restart php on the SSH console but that didn’t solved the issue. The problem was that I was running PHP 5.3 and Mailserv configuration expected 5.2… Fixing php.god was the solution.

Then, I was taught but Roundcube that “suhosin.session.encrypt” was to be disabled… Once disabled in php.ini, the Roundcube interface complained about not being able to connect to the database… Remember those post-configuration messages during binary packages install? You have to link the PHP modules if you want to use them…

Once corrected, you can log in using the user credentials you configured in the admin panel. Use the user’s email as a login.

Nothing particular here since you know Roundcube. Like it for what it is, hate it because of the features it does not have ; like Cal server access, CardDAV or shared LDAP address book …


Short story: I won’t use this!

Long story: I must admit that the management interface is far better than Webmin ; easier to use and much more pretty.

But there are many things that are missing, like service management, for example. Weird also are some technical choice: why not using native spamd(8) or httpd(8) ; although nginx(8) might come in base soon. There are a few a security issues (clear password in MySQL, suhosin encryption disabled, no pf rules) that really seem weird for an OpenBSD base. There are still a few bugs left (like NTP or PHP version) that requires to drop to the console. Finally, you can’t use external SQL or LDAP sources ; which stops any integration in the enterprise. I’m not a company but I want to split back-end and front-end services.

If a were a developer, I would add the “remote repository” feature first. Then replace Roundcube with SOGo ; it is supported on OpenBSD and has much more features than RC.