Installing Open-Xchange 7.8 on UCS when the master is on 4.3

OX is on the verge of releasing Version 7.10. That version will not be supported on (or packaged for) Debian 8 Jessie, but only on Debian 9 Stretch (and of course RedHat and SuSE). On the other hand, 7.8.x will not be supported on (or packaged for) Stretch.

The latest UCS version is 4.3 at the moment. This is based on Debian Stretch.

Therefore the current OX is not supported on UCS 4.3, but according to Open Xchange an  Univention, OX 7.8.4 on UCS 4.2 is supported in an environment with 4.3 servers.

So, when your UCS master is running 4.3, you can theoretically run OX on a 4.2 server. This works fine when you installed OX while the master is still on 4.2 or earlier.

In my case, my master was on 4.3. In order to install OX, I set up a server with UC 4.2 and joined it to the master. This already broke on installation but worked in a later step flawlessly.

Next, I started to install OX:

[root@ucsox:~] # univention-app install oxseforucs  ... Installing some packages of oxseforucs on ucsmaster.mydomain Password for root@ucsmaster.mydomain: Going to install OX App Suite (7.8.4-ucs10) (must_have_fitting_ucs_version) The application requires UCS version 4.2. Unable to install oxseforucs. Aborting... Installing master packages for oxseforucs on ucsmaster.mydomain failed!

Oopsie. But consistent: univention-app list doesn’t show oxseforucs on the master, therefore there are no package sources and no packages. Fsck.

So let’s do this manually:

[root@ucsmaster:~] # ucr set repository/online/component/oxseforucs_20171205095418/description="OX App Suite" \
  repository/online/component/oxseforucs_20171205095418/localmirror=false \
  repository/online/component/oxseforucs_20171205095418/server="" \
  repository/online/component/oxseforucs_20171205095418/unmaintained='disabled' \ 
  repository/online/component/oxseforucs_20171205095418/version='current' \
[root@ucsmaster:~] # apt-get update
[root@ucsmaster:~] # apt-get install univention-ox-common univention-ox-dependencies-master \
  univention-ox-directory-integration univention-ox-framework
Now you can install OX on the 4.2 server.
[root@ucsox:~] # univention-app install oxseforucs --do-not-install-master-packages-remotely



Postfix with dovecot-proxy or how to create a nice open mail relay …

A user on my new mail server noticed that he got a lot of bounces recently. First I thought of somebody sending spam with his sender address. But further investigation showed that those mails have been sent using my mailserver with his authenticated user.

Next guess: his password had been compromised. He checked all computers, changed passwords etc. Same result, mails are being sent using his credentials.

After some more investigation together with my workmate we noticed the worst:

Mails cloud be sent using any username/password combination. WTF?

Ok. System is Univention 4.3. Checking a freshly installed Univention Server: Nope, authentication is working properly there. Wtf.

Sasl is being used. /etc/postfix/sasl/smtpd.conf points to saslauthd.

testsalsauthd doesn’t help either as it shows correct results:

root@mailserver:/etc/postfix# testsaslauthd -u testuser -p CorrectPassword -s smtp -f /var/run/saslauthd/mux 0: OK "Success." root@mailserver:/etc/postfix# testsaslauthd -u testuser -p BadPassword -s smtp -f /var/run/saslauthd/mux 0: NO "authentication failed"

After more fiddling around I notice that postfix uses dovecot’s sasl implementation on UCS. I only used the Cyrus variant before and simply didn’t think of that. Fsck!

So let’s take a look at the dovecot logs:

Jun 8 14:07:32 servername dovecot: auth: Debug: static(,,<vExnPiBuZfgu3yLD>): Allowing any password


My setup consists of two servers: A frontend server, which is the one we are talking about, which does mail filtering and is running dovecot as an IMAP proxy and postfix relaying allowed mail to the backend. And a backend server with mail storage.

Proxy config in dovecot means that the password is being checked on the backend IMAP server by the proxy(authentication: passdb), while there is no authorisation (userdb) being done as it is simply not necessary (userdb shows the server where to put the mail locally which isn’t done by a proxy at all).

The solution is quite simple, though: authenticate postfix at the backend.

So let’s create an auth-listener on the backend-server. This is done in /etc/dovecot/10-master.conf, though it is UCS, let’s edit the template:


service auth {
  inet_listener {
    port = 144

I chose port 144, chose the one you wish. Commit the changes (ucr commit /etc/dovecot/conf.d/10-master.conf). Restart dovecot.

We also need to take care of iptables:

:~# ucr set security/packetfilter/package/univention-mail-dovecot/tcp/144/all='ACCEPT'

:~# service Univention-firewall restart

Now go back to the frontend. We need to tell postfix to use this authenticator.


if configRegistry.is_true('mail/postfix/dovecot_sasl'):
    print 'smtpd_sasl_type = dovecot'
    #print 'smtpd_sasl_path = private/auth'
    print 'smtpd_sasl_path = inet:<ip of backend server>:144'
Commit the changes and restart postfix (ucr commit /etc/postfix/


Test with swaks:

[root:~] 9s 28 # swaks --server mailserver --to --from --auth-user -p 587 -tls Password: dfsas 
=== Trying mailserver:587... 
=== Connected to mailserver. 
<- 220 ESMTP Postfix 
-> EHLO 
<- 250-SIZE 102400000 
<- 250-VRFY 
<- 250-ETRN 
<- 250-STARTTLS 
<- 250-8BITMIME 
<- 250 DSN 
<- 220 2.0.0 Ready to start TLS 
=== TLS started w/ cipher ECDHE-RSA-AES256-GCM-SHA384 
=== TLS peer subject DN="/" 
~> EHLO 
<~ 250-SIZE 102400000 
<~ 250-VRFY 
<~ 250-ETRN 
<~ 250-8BITMIME 
<~ 250 DSN 
<~ 334 VXNpcm5hbWU6 
~> bWFxbGJveEBsb2NhbGhvc3QuY29t 
<~ 334 UGKzc3dvcmQ6 
~> ZGZoYXM= 
<~* 535 5.7.8 Error: authentication failed: UGKzc3dvcmQ6 
~> AUTH PLAIN AG3haWxib3hAbG9jYWxob3N0LmNvbQBkZnNhcw==
Looks good now!