By

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:

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:

Now you can install OX on the 4.2 server.

Done

 

By

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:

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:

Oopsie.

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:

/etc/univention/templates/files/etc/dovecot/conf.d/10-master.conf

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:

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

/etc/univention/templates/files/etc/postfix/main.cf.d/60_tls

Done.

Test with swaks:

Looks good now!