Groupware

How to install Kopano Groupware from scratch on Ubuntu – 2022 Guide

Table of Contents

Background

Kopano is a wonderful groupware application that can fit nicely as a nice intermediate groupware solution between traditional shared hosting IMAP/POP3 mailboxes, and full blown (expensive) public cloud services such as Google Workspace and Microsoft 365. What Kopano brings to the table is calendar and contact sharing, public folders to store notes and tasks, and a very attractive web interface.

Kopano has a paid tier but it’s also open source which means that with quite a lot of effort you can also install it yourself and have your very own groupware server. The problem is some of official initial install documentation for Kopano is structured around using their paid tier. The other problem with the Kopano installation documentation is it’s kind of agnostic, so the official guides presents so many differing options. Also then you visit their forums, you kind of get the idea that if you’re using the heart of Kopano you’re good to go, but if you want to do something a bit special, you’re on your own.

The aim of this guide to make some assumptions and to show install it using the open source way. We’ll do it on Ubuntu and use MySQL and Apache and keep things as stock as possible. The tutorial serves as a masterclass for today’s modern hosting technologies. Make no mistake – this is a big adventure – and you probably only want to do it if you are an experienced systems administrator or if you want to become one.

Along the way you’ll learn to install and set up the following technologies on Ubuntu 20.04:

Kopano
- Let’s Encrypt integration for the Gateway
- Working with multiple domains on the same server
MariaDB
- Kopano integration
Postfix
- Link MariaDB with Postfix so that Postfix authenticates against Kopano
- SSL/TLS/SASL configuration
  - Let’s Encrypt integration
Apache with PHP support
- Let’s Encrypt support with automatic renewal
SpamAssassin
Fail2ban

You’ll also perform these Kopano actions:

Create test users
Turn on debug logging for the Postfix integration of the Kopano Gateway
Perform various tests along the way to see how things are moving along
Learn about default hosting security and how to harden a system

We really love Kopano and their product, so if you’re not up for a massive systems administration mission, rather just buy their software.

Prerequisites

You’ll need a properly configured full qualified hostname. Check by using hostname -f

hostname -f

We also recommend setting up a DNS record for the Kopano host including a reverse (PTR) record

curl ifconfig.me
dig +short @1.1.1.1 -x a.b.c.d

If you want a working system, also add an MX record for your test domain(s).

dig +short @1.1.1.1 MX example.com

Installation Guide

Kopano Community Repositories

Kopano doesn’t have .DEB installation files that comes part of a distribution so you have to download the archives of the desired nightly build.

This has already been greatly simplified by this script on Github.:

wget -O - https://raw.githubusercontent.com/thctlo/Kopano/master/get-kopano-community.sh | sudo bash

The script will create local .deb files in /srv/repo/kopano/amd64 for the Kopano installation and also link us to the Z-Push repository which we’ll need to get ActiveSync working.

Apache and PHP

First we’ll install Apache and PHP. Kopano can use different web servers but because we’re dealing with a huge ecosystem and many different settings we’re settling on Apache for this guide. Using Apache also means we’ve got pre-built plugins available for Let’s Encrypt and Z-Push which are essential to avoid excessive configuration.

apt -y install apache2 libapache2-mod-php7.4

MariaDB Server

Although Kopano can probably use MySQL instead of MariaDB Server, we’ve settled for MariaDB because it’s the same as the official Kopano Ubuntu installation guide. There are some useful shortcuts for permissions in the documentation that just works better with MariaDB.

apt -y install mariadb-server

Configure MariaDB Server

MariaDB server needs some configuration. This has to be done before installing Kopano Server, because by default Kopano Server will try to connect to MariaDB and will fail if this configuration has not been done.

We’ll perform the following tasks:

Secure the MariaDB installation
Create a kopano database
Grant access to the database for a unix_socket

When securing the server, accept all defaults, and be sure to make a note of the password:

mysql_secure_installation

Create a database called kopano

mysql -e "create database kopano;"

Create a login for the Kopano Server. This special login will use the MySQL unix_socket method to connect:

mysql -e "GRANT ALL PRIVILEGES on kopano.* to 'kopano'@'localhost' IDENTIFIED via unix_socket;"

In the next section of our installation guide, we’re going to install Postfix. Postfix will have a special configuration section that will allow it to talk to Kopano and hand off email. For this to work, we need some additional MySQL privileges.

By default the root user specified above won’t have access to the kopano database, so you have to add that permission. Replace secret with your own password:

mysql -e "GRANT ALL PRIVILEGES on kopano.* to 'root'@'localhost' IDENTIFIED BY 'secret' with grant option;"

Postfix Part 1

Part 1 will address our ActiveSync implementation.

We’ll install Postfix with Postfix MySQL support. Postfix will prompt to find out what kind of setup, be sure to choose the default option presented Internet Site:

apt -y install postfix postfix-mysql

Configure Postfix for MySQL Support

To make Postfix communicate with MySQL for Kopano authentication requests, edit /etc/postfix/main.cf and look for configuration options alias_maps and alias_database. Below these two, add the following lines:

alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
virtual_mailbox_maps = mysql:/etc/postfix/mysql-users.cf
virtual_transport = lmtp:127.0.0.1:2003

The above file will reference another file that has to be created, namely /etc/postfix/mysql-users.cf

Create it like below, and be sure to add the MySQL password which was saved in a previous step by replacing secret below:

user = root
password = secret
hosts = 127.0.0.1
dbname = kopano
query = select value from objectproperty where objectid=(select objectid from objectproperty where value='%s' limit 1) and propname='loginname';

Configure Postfix for Multiple Domains

If your Kopano installation is going to be serving two or more domains, you need to add additional configuration directives to main.cf.

These directives are:

virtual_alias_maps = mysql:/etc/postfix/mysql-users.cf
virtual_mailbox_domains = example.com, second-domain.com, third-domain.com

If you don’t do this, sending to another domain on your server might end up giving the following error:

Recipient address rejected: User unknown in local recipient table

Modification of `mydestination`

You might get `status=bounced (unknown user: “xyz”)` message in the Postfix log file if you are trying to deliver email to the Postfix integration instead of Kopano.

To fix this, reduce the mydestination configuration parameter in `main.cf` to exclude your hostname if your hostname will also be an email domain.

# mydestination = $myhostname, host.example.com, localhost.example.com, , localhost
mydestination = localhost.example.com, , localhost

In the example above, we’re telling Postfix to not deliver email addresses to the same domain name as the hostname, but rather resolve those email addresses via `virtual_mailbox_domains`. To do this we removed $myhostname and host.example.com.

Since we’ve added quite a few new entries to Postfix, now is a good time to restart it:

service postfix reload

Keep on tailing the Postfix log file because Kopano is tightly integrated into it by way of logging it’s own events there. If you want to follow along and see if things are working nicely, do this in a separate terminal:

tail -f /var/log/mail.log

There’s still quite a bit of Postfix configuration to be done, but for ActiveSync to work we don’t yet need it so let’s move on to the other parts of the system.

SSL

Apache

Since Apache was installed with all defaults, getting it to work with Lets Encrypt free SSL certificates is a breeze. All that doesn’t happen is that certbot doesn’t detect the URL we are using for Kopano but we can enter that manually.

Follow the instructions below to get a shiny new SSL certificate for your newly minted server.

First:

apt -y install certbot python3-certbot-apache

certbot

Accept the terms, decide about sharing your email with EFF, and then input your domain name.
At this point certbot should retrieve a new certificate for your server.
The final question relates to whether or not to redirect HTTP traffic to HTTPS. I always choose yes (#2) here.

At this point HTTPS to your server should be working.

Certbot for multiple Domains

Certbot was designed to easily work with multiple domains – provided your system is set up in a default manner. After you ran certbot a new file was created, which we can append to so that multiple SSL certificates can be obtained for our setup.

To get certbot to recognize your other domains, edit the file created by certbot:

vi /etc/apache2/sites-available/000-default-le-ssl.conf

That file will only exist if you’ve done things exactly in the sequence of this tutorial. Let’s Encrypt created that file so that your Apache can serve server SSL certificates.

Inside that file you’ll find the primary domain for which certbot has retrieved an SSL certificate. Add these lines to that file:

ServerName example.com
ServerAlias mail.domain2.com
ServerAlias mail.domain3.com

In this example, we have a primary hostname for our main installation, but we also want email certificates for two additional domains of users who are going to connect to our server. We’re using mail.@ because their websites are hosted elsewhere. In this specific example, Kopano will only be doing email.

Run certbot again to pick up these additional domain names.

certbot

There is an option to Expand the existing certificate, choose this.

Viola! Now you have SSL for all your Apache domains.

A note about the server’s hostname

If you don’t retrieve additional SSL certificates and you have different domain names connecting to the Kopano server, users won’t be able to use their actual domain names to connect to the server, rather, they would need to connect hostname of the server itself. Also ActiveSync will only properly connect if you’re connecting to the server’s real name as it requires SSL and we should bind the SSL certificate to the server’s known names if possible.

Let’s encrypt uses the following directories to store certificates:

/etc/letsencrypt/live/example.com/fullchain.pem
/etc/letsencrypt/live/example.com/privkey.pem

We’re going to stick with their default locations because then Lets Encrypt automatic renewals will be a breeze.

To see if Certbot is going to automatically renew, run this command and study the output:

systemctl status certbot.timer

You should see this:

systemd[1]: Started Run certbot twice daily.

Certbot’s creates a check process by creating a crontab for the certbot user, which can be seen here:

cat /etc/cron.d/certbot

What you’ll notice when you output that file that no cronjob is needed if you’re using systemd, since cronjob.timer till be used. So now, in theory, you’ll never have an issue with Apache SSL renewals 🙂

Postfix SSL

Configure Postfix to use the Let’s Encrypt Certificate:

sudo postconf -e 'smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem'
sudo postconf -e 'smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem'

Install Kopano Applications

The groundwork has been laid, so now you are ready to install the Kopano applications. This installation is greatly simplified because we’re using Apache so we’ll also download Z-Push Apache config and Autodiscover scripts.

apt -y install kopano-server-packages kopano-webapp z-push-kopano z-push-config-apache z-push-autodiscover z-push-config-apache-autodiscover

The Kopano services will now automatically start up.

Configure Kopano Server MariaDB Access

If you’ve been tailing /var/log/mail.log`, you’ll notice that Kopano-Server doesn’t know how to log into MariaDB:

# service kopano-server status
...
Jun 08 04:33:08 kopano-test2 kopano-server[16345]: mysql_real_connect: Access denied for user 'root'@'localhost'

Let's fix that:

The reason is the server configuration has to be told how to access MariaDB. Edit /etc/kopano/server.cfg and uncomment the mysql_password and mysql_database lines:

#database_engine = mysql
#mysql_host = localhost
#mysql_port = 3306
#mysql_user = root
mysql_password = secret
mysql_database = kopano

Now that Kopano know how to communicate with MySQL, you can restart all the services:

service kopano-* restart

or individually:

service kopano-gateway restart
service kopano-server restart
service kopano-spooler restart
service kopano-dagent restart
service kopano-ical restart
service kopano-monitor restart

The first time Kopano starts, it will create it’s own database and you’ll be informed about this in the log file:

Tables missing inside database: no access (80070005)

Kopano Gateway Configuration

Incoming Email Port Configuration

To recap, incoming email ports are defined as:

SMTP = 25
POP3 = 110
POP3S = 995 (SSL)
IMAP = 143
IMAPS = 993 (SSL)

Outgoing email ports are:

SMTP = 25
SMTPS = 587 (Submission / encrypted using STARTTLS)
SMTPS = 465 (encrypted using SSL)

We don’t have to do anything to get port 25 working as it’s available out of the box with Postfix. Since both POP3 and IMAP are unsecured getting them to work is also relatively easy. Our energy will be spent to get Kopano and the Postfix system to work with the secure protocols.

Enable Kopano to Accept POP3 and IMAP

Edit the following file to get Kopano to accept connections on email ports. Remember this section is only if you’re not planning on sticking with ActiveSync only.

File /etc/kopano/gateway.cfg

pop3_listen = *:110
pop3s_listen = *:995
imap_listen = *:143
imaps_listen = *:993

Kopano Gateway SSL

This is one of the more complex parts of the configuration because we want to use Lets Encrypt, and we want automatic renewals, but we don’t want to be stuck with files all the show and permissions issues.

The first step to get the Gateway to recognize the certificates is to uncomment these files in /etc/kopano/gateway.cfg:

# File with RSA key for SSL
ssl_private_key_file = /etc/kopano/gateway/privkey.pem
#File with certificate for SSL
ssl_certificate_file = /etc/kopano/gateway/cert.pem

Here is a sequence based on this forum post that seems to work:

mkdir /etc/kopano/gateway
ln -s /etc/letsencrypt/live/kopano-host.example.com/privkey.pem /etc/kopano/gateway/privkey.pem
ln -s /etc/letsencrypt/live/kopano-host.example.com/cert.pem /etc/kopano/gateway/cert.pem

If you restart the gateway now, you’ll encounter the following permissions problem:

ECChannel::HrSetCtx(): cannot open key file /etc/kopano/gateway/privkey.pem: Permission denied
Error loading SSL context, POP3S and IMAPS will be disabled

It appears Kopano Gateway can’t read the file the default live and archive directories that Lets Encrypt creates doesn’t provide sufficient permissions. The workaround is this:

chmod 755 /etc/letsencrypt/live/ -R
chmod 755 /etc/letsencrypt/archive/ -R

Please note on highly secure systems this might be problematic so please let us know if the comments if you have a better solution.

Next restart the Gateway:

service kopano-gateway restart

What about STARTTLS and SASLAuthd and email hacker security?

Postfix is an incredibly powerful MTA but out of the box it doesn’t have most of the requisite modern day security protocols enabled and configured that one might use. Having said that, if you’re going for a pure Kopano ActiveSync groupware setup, you might not even be interested in enabling this additional configuration. Right now we have a working system that should be perfectly find if you’re just going to be doing ActiveSync.

In our case, we prefer to turn these on. The main reason is if we migrate existing clients we can use IMAPSYNC to bring them across, and then later simply update their configuration to use the Microsoft Exchange compatible configuration.

One caveat with enabling many new protocols on your server is that you have to keep security in mind. The moment your server’s ports are available with things like SSH and POP3 and IMAP and SMTP you will get many hackers with automated scripts trying to breach your system. So although enabling more ports might sound like a good idea, if you don’t add tools such as Fail2ban you’re in for a whole lot of trouble. We’ll cover Fail2ban later in the guide.

Enabling iCal

By default Kopano’s iCal server isn’t listening. To enable it, edit the /etc/kopano/ical.cfg file and add the following line:

ical_listen = *:8080
icals_listen = *:8443

Set your server timezone:

server_timezone = Europe/Amsterdam

Create symbolic links to the Let’s Encrypt certificate:

mkdir /etc/kopano/ical
ln -s /etc/letsencrypt/live/host.example.com/privkey.pem /etc/kopano/ical/privkey.pem
ln -s /etc/letsencrypt/live/host.example.com/cert.pem /etc/kopano/gateway/cert.pem

Enable Kopano Webapp Apache Integration

Installing Kopano Webapp created an Apache module that we can enable now. This module specifies that the Webapp should use a PHP MAPI plugin and the site won’t be visible before you enable this module.

If you want to see the file, it’s /etc/php/7.4/mods-available/kopano.ini

The content of this file is:

; Enable MAPI extension module
extension=mapi.so

Do this to enable it:

phpenmod kopano
service apache2 reload

There is a MAPI extension that Z-Push uses to do ActiveSync magic. This needs to be linked to Apache. Create a file /etc/php/7.4/mods-available/kopano.ini with the following content:

; Enable MAPI extension module
extension=mapi.so
; Adding path with php mapi classes to include dir
include_path="${include_path}:/usr/share/kopano/php"

Now get Apache to use this module:

phpenmod kopano

Configure Kopano & Postfix

At this point you are almost ready to test the installation but for these additional configuration settings:

Kopano disables some key features by default. If we’re going both the ActiveSync and POP3/IMAP route, we want to avoid that.
Postfix needs SSL in place to get Kopano to accept SSL connections.
Postfix doesn’t know about our domain yet. For us to test, we have to tell the Postfix virtual maps to do a local lookup for our email domain before handing it off to kopano-dagent

Edit disabled_features

vi /etc/kopano/server.cfg

Make disabled_features blank like so:

# Disable features for users. This list is space separated.
# Currently valid values: imap pop3 mobile outlook webapp
#disabled_features = imap pop3
disabled_features =

Now restart the Kopano server service for the setting to take effect:

service kopano-server restart

Enabling the public store

By default Kopano doesn’t enable the public store. This leads to all kinds of errors in the log file such as the one below:

[ERROR ] kopano - Unable to publish freebusy information: public store not found

Run this command to get rid of the error:

# /usr/sbin/kopano-admin -s
The selected option is deprecated in this utility.
Forwarding call to: `/usr/sbin/kopano-storeadm -h default: -P`.
The store has been created.
Store GUID is xyz

Postfix Configuration

Next we’ll move on enabling ports 25, 587 and 465 to work with Postfix.

25 is a special case – all we need to do here is make sure our Kopano does password authentication instead of Postfix’s native handling

Configuring outgoing ports 587 and 465 to work

To get Postfix to accept port 587 and 465 connections, a number of steps need to be taken.

Postfix must already know about our Lets Encrypt Certificate as we’ve done in a prior step.

SASL need to be installed and set up with remote idmap (rimap) support.

service postfix restart

Install SASL with rimap

apt -y install libsasl2-modules sasl2-bin

Next configure /etc/default/saslauthd:

START=yes
MECHANISMS="rimap"
MECH_OPTIONS="127.0.0.1"
OPTIONS="-r -c -m /var/spool/postfix/var/run/saslauthd"

Now configure Postfix to set the run directory using dkpg-statoverride and ‘root’ user:

dpkg-statoverride --add root sasl 750 /var/spool/postfix/var/run/saslauthd

Add postfix to the saslauth group:

# adduser postfix sasl
Adding user `postfix' to group `sasl' ...
Adding user postfix to group sasl
Done.

Create a file /etc/postfix/sasl/smtpd.conf and add:

pwcheck_method: saslauthd
mech_list: plain login

Next we’ll configure Postfix `/etc/postfix/master.cf` for Submission (port 587) and SMTPS (port 465).

On our MTA which is all at defaults we simply uncommented the lines below:

submission inet n - y - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_tls_auth_only=yes
-o smtpd_reject_unlisted_recipient=no
-o smtpd_client_restrictions=$mua_client_restrictions
-o smtpd_helo_restrictions=$mua_helo_restrictions
-o smtpd_sender_restrictions=$mua_sender_restrictions
-o smtpd_recipient_restrictions=
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
smtps inet n - y - - smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_reject_unlisted_recipient=no
-o smtpd_client_restrictions=$mua_client_restrictions
-o smtpd_helo_restrictions=$mua_helo_restrictions
-o smtpd_sender_restrictions=$mua_sender_restrictions
-o smtpd_recipient_restrictions=
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING

For extra security, do this (taking note of the indentation):

smtpd      pass  -       -       y       -       -       smtpd
    -o smtpd_sasl_auth_enable=no

Next we’ll add a few settings to Postfix to make it understand that we’re now using SASL auth:

postconf -e "smtpd_sasl_auth_enable = yes"
postconf -e "smtpd_sasl_path = smtpd"

Finally let’s restart both Postfix and saslauthd:

service postfix restart
service saslauthd restart

Spamassassin

Setting up SpamAssassin to work with Kopano

These days it would be irresponsible to set up an email server without serious SPAM protection. Fortunately the industry standard SpamAssassin is available for Postfix and we can do a stock implementation which just works with Kopano.

First install SpamAssassin.

apt -y install spamassassin spamc

Please note: Running sa-compile may take a long time.

Next add a disabled login user. When doing this, just press enter for all the prompts.

adduser spamd --disabled-login

Enable the service:

update-rc.d spamassassin enable

Edit default spamassassin file and change the `OPTIONS` and `CRON` settings:

vi /etc/default/spamassassin

Options should be this:

OPTIONS="--create-prefs --max-children 5 --username spamd --helper-home-dir /home/spamd/ -s /home/spamd/spamd.log"

Also enable CRON = 1

Modify Postfix to understand Spamassassin

Edit /etc/postfix/master.cf and add these lines just below smtp like so. Please note the two spaces indentation before -o is key.

smtp inet n - y - - smtpd
   -o content_filter=spamassassin
spamassassin unix - n n - - pipe user=spamd argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}

Start the service:

service spamassassin start

Set up your SPF record

As of 2022 Google isn’t friendly towards domains that do not have SPF set up. SPF can have many variations, but if you want an easy SPF record that “just works” then use this one:

v=spf1 mx a -all

Fail2ban

Installing

Ubuntu already comes with UFW so using Fail2ban should be a no brainer for the standard email ports and ActiveSync (Z-Push).

Start here:

apt -y install fail2ban

General Configuration

Copy the default config:

cp /etc/fail2ban/jail.{conf,local}

Filter Configuration

Z-Push

As you can see from the comments, also remember to update this file before z-push fail2ban events will work:

vi /etc/z-push/z-push.conf.php

In there, specify:

define('LOGAUTHFAIL', true);

Fail2ban won’t start up if a log file doesn’t exist, so do this:

touch /var/log/z-push/z-push-error.log
chown www-data:www-data /var/log/z-push/z-push-error.log

Add a filter for Z-Push by creating the following file /etc/fail2ban/filter.d/z-push.conf

# FILE : /etc/fail2ban/filter.d/z-push.conf
# Fail2Ban configuration file

[INCLUDES]
before = common.conf

[Definition]
# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values:  TEXT
#

failregex = IP: <HOST> failed to authenticate user

ignoreregex =

Kopano Gateway

Add a filter for Kopano Gateway by creating the following file /etc/fail2ban/filter.d/kopano-gateway.conf

# /etc/fail2ban/filter.d/kopano-gateway.conf

[INCLUDES]

before = common.conf

[Definition]
# Option: failregex
# Notes.: regex to match the password failures messages in the logfile. The
# host must be matched by a group named "host". The tag "<HOST>" can
# be used for standard IP/hostname matching and is only an alias for
# (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values: TEXT
#
failregex = Failed to login from <HOST> with invalid username
Failed to login from <HOST>:[0-9]{2,5} with invalid username

ignoreregex =

Postfix SASL

# Fail2Ban filter for postfix authentication failures
[INCLUDES]
before = common.conf
[Definition]
_daemon = postfix/smtpd
failregex = ^%(__prefix_line)swarning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(: [ A-Za-z0-9+/]*={0,2})?\s*$

Local Jail Configuration

This file references the Z-Push,Kopano Gateway, and SASL filters we have just created:

[kopano-gateway]
enabled = true
port = smtp,ssmtp,submission,imap2,imap3,imaps,pop3,pop3s
filter = kopano-gateway
banaction = ufw

[z-push]
enabled = true
port = http,https
filter = z-push
banaction = ufw-all
# also enable define('LOGAUTHFAIL', true); in z-push/config.php or /etc/z-push/z-push.conf.php
logpath  = /var/log/z-push/z-push-error.log
maxretry = 3
bantime  = 84600

# https://bobcares.com/blog/fail2ban-postfix-sasl/
[sasl]
enabled = true
port = smtp
filter = postfix-sasl
logpath = /var/log/mail.log
maxretry = 5

The Z-Push jail uses a variant of ufw, so add this:

# UFW file /etc/fail2ban/action.d/ufw-all.conf
# Fail2Ban configuration file ufw-all.conf
#
# We add the rules to ufw for better control and management
#

[Definition]
actionstart =
actionstop =
actioncheck =
actionban = ufw insert 1 deny from <ip> to any
actionunban = ufw delete deny from <ip> to any

As a final step, restart the fail2ban service:

service fail2ban restart

Test by tailing /var/log/fail2ban.log

Testing the Installation

Before heading over to SSL, let’s test the installation at this point. There is still a lot of work to be done, but testing the installation now will mean that if we have any issues we don’t get ourselves too deep further down and we can focus on what has been done already.

Apache & Z-Push & Webapp & Z-Push

Apache should be running at http://your-domain.com/
Kopano Webapp should be running at http://your-domain.com/webapp
Z-Push should prompt for username and password is you access this url: http://your-domain.com/Microsoft-Server-ActiveSync

If you had trouble with Apache and SSL, you can temporary disable secure cookies for the Webapp test.

Disable secure cookies?

This step is only required if you want to test your installation before the installation of SSL. Be sure to enable it again after installation of SSL.

To disable secure cookies:

Edit /etc/kopano/webapp/config.php

Change the value below from true to false:

define("SECURE_COOKIES", false);

No restart is required when changing this setting.

User Testing

Creating a Test User

Run the following command to create a test user:

kopano-admin -c [email protected] -p secret -e [email protected] -f "First Name Last Name"

To see the new test user, use this command:

kopano-admin -l

If all went according to plan, you can now log into the Webapp interface a send a test message to an external recipient. Bonus, if the MX records for the domain you’re sending from is also properly pointing to your Kopano server, you will receive a reply back. As usual, tail /var/log/mail.info to see the messages going to and from.

If things don’t work out quite as expected, or you don’t want to use the Webapp to send a test message, following the next section to send a test message using the command line. This can be super useful when diagnosing email sending problems.

Send yourself a message using the command line

The command sequence below show you how to send a test message using the command line. Please note the final . is needed to end the conversation with the SMTP server.

# telnet localhost smtp
mail from:[email protected]
rcpt to:[email protected]
data
Subject:hello world
hi
.

You can also retrieve the message from the command line:

Log into a POP3 Mailbox from the command line

Next, use the telnet command sequence below to see if you can log in as the user:

telnet localhost pop3
user [email protected]
pass secret
list
quit

Congratulations! You now have a working Groupware server that can send and receive email.

Removing the Test User

Since having test users on an email system is a really bad idea, it’s prudent to remove your test user once you’re sure testing is working:

kopano-admin -d [email protected]

Testing SSL Email Ports

To test SSL on port 993 or 995, use these commands:

openssl s_client -connect 127.0.0.1:993
openssl s_client -connect 127.0.0.1:995

You should get these messages:

* OK [CAPABILITY IMAP4rev1 LITERAL+ AUTH=PLAIN] IMAP gateway ready

and

+OK POP3 gateway ready` messages.

Testing Spamassassin

You can easily test a Spamassassin installation by sending an email to a recipient with the following text anywhere in the body:

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

Sending an email with the above text should always cause the message to end up directly in the Junk E-mail folder.

To see if everything went according to plan, check the /home/spamd/spamd.log file. This test message will produce the following:

spamd: identified spam (998.9/5.0) for spamd:1001 in 0.6 seconds, 4749 bytes.
Sat Jun 11 15:35:20 2022 [32918] info: spamd: result: Y 998 - DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,GTUBE,HTML_MESSAGE,RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE scantime=0.6,size=4749,user=spamd,uid=1001,required_score=5.0,rhost=::1,raddr=::1,rport=33336,mid=<CAGgNXakSR+muFmcHnFYu9FZy=XGVcegAV8FdkU50JG3Lvd6mYA@mail.gmail.com>,autolearn=no autolearn_force=no

iCal Testing

Thunderbird has great calendar integration. Use your username and these URLs for testing:

http://server.example.com:8080/caldav/[email protected]/calendar
https://server.example.com:8443/caldav/[email protected]/calendar

Autodiscovery

Autodiscovery for Outlook doesn’t work because it expects an Exchange server, not an ActiveSystem implementation. You have to configure the settings manually.

Troubleshooting

Tail the Postfix log file

Kopano has incredible logging, and as luck has it most of it goes to the Postfix log. To see what’s happening, use the following command:

tail -f /var/log/mail.log

POP3 not enabled for user “[email protected]”

Make sure you have set disabled_features to blank. Also make sure you have restarted kopano-server after changing that setting. See here for more information.

How to Turn on Kopano Gateway and Server Logging

What’s really cool about Kopano is it logs most of it’s actions in the email log, so you have one log file to look at for problems.

I normally turn up the the Kopano Gateway configuration log level during testing:

Edit /etc/kopano/gateway.cfg and uncomment this line:

log_level = 6

HTTP Error 400 – Bad Request

You might experience HTTP Error 400 – Bad Request when you access /webapp.

To remedy, be sure to check if you have disabled secure cookies.

SASL

Make sure you have added postfix to the sasl group otherwise you’ll get the errors below when sending email:

Jun 9 11:21:09 kopano-test postfix/smtpd[24759]: warning: SASL authentication failure: cannot connect to saslauthd server: Permission denied
Jun 9 11:21:09 kopano-test postfix/smtpd[24759]: warning: SASL authentication failure: Password verification failed
Jun 9 11:21:09 kopano-test postfix/smtpd[24759]: warning: a-b-c-d.ip.internet.co.za[a.b.c.d]: SASL PLAIN authentication failed: generic failure

OpenSUSE Servname not supported for ai_socktype

If you get this:

postfix/master[5309]: fatal: 0.0.0.0:smtps: Servname not supported for ai_socktype

On a OpenSuSE server when you enable smtps in postfix master.cf file. The reason for the error is that the definition of the smtps port in /etc/services is missing.

Solution

Edit the /etc/services file, or create it if it doesn’t exist.

vi /etc/services

and add the following lines:

smtps 465/tcp # Secure SMTP
smtps 465/udp # Secure SMTP

Restart Postfix.

587 STARTTLS on OpenSUSE Tumbleweed

During a recent troubleshooting session we had to get STARTTLS / SSL working on Port 587. Tumbleweed has a well configured Postfix service already so only a few steps are required to make it work at least for port 587. As usual, make sure you add the SSL certificates to Postfix. Next,

Install and configure cyrus-sasl-saslauthd

You’ll need this package to get SASL working:

zypper install cyrus-sasl-saslauthd

Then backup the file in `/etc/sysconfig/saslauthd` and replace it’s contents with the following:

SASLAUTHD_AUTHMECH=rimap
SASLAUTHD_THREADS=5 # This should already be selected
SASLAUTHD_PARAMS="-c -r -O 127.0.0.1"

The above settings will ensure that when SASL authentication requests come in, it’s handed off the the Kopano server.

Update master.cf

Next, in your /etc/postfix/master.cf file, uncomment the section for submission. On our system, it looks like this (four items remains commented):

submission inet n - n - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
# -o content_filter=smtp:[127.0.0.1]:10024
-o smtpd_sasl_auth_enable=yes
-o smtpd_tls_auth_only=yes
-o smtpd_reject_unlisted_recipient=no
# -o smtpd_reject_unlisted_recipient=no
# -o smtpd_helo_restrictions=$mua_helo_restrictions
# -o smtpd_sender_restrictions=$mua_sender_restrictions
-o smtpd_recipient_restrictions=
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING

Then finally, also uncommend this line:

tlsmgr unix - - n 1000? 1 tlsmgr

If you don’t uncomment the above line, you’ll get this error when connecting with STARTTLS:

Sep 05 20:37:25 host postfix/submission/smtpd[9901]: warning: connect to private/tlsmgr: Connection refused
Sep 05 20:37:25 host postfix/submission/smtpd[9901]: warning: problem talking to server private/tlsmgr: Connection refused
Sep 05 20:37:26 host postfix/submission/smtpd[9901]: warning: connect to private/tlsmgr: Connection refused
Sep 05 20:37:26 host postfix/submission/smtpd[9901]: warning: problem talking to server private/tlsmgr: Connection refused
Sep 05 20:37:26 host postfix/submission/smtpd[9901]: warning: no entropy for TLS key generation: disabling TLS support

Reference

https://forums.opensuse.org/showthread.php/495195-OS13-1-Postfix-and-STARTTLS

127.0.01 Connection Refused