dpkg -l pykolab

ii pykolab 0.8.10-0~kolab2 all Kolab Groupware daemon and utilities

Hello devs,

fresh Kolab 16 Installation on Debian 9 Stretch does not work "Out of the Box".

I did a "standard" Debian Stretch installation + SSH service - nothing more.
Adjusted /etc/hosts.
Adjusted /etc/hostname.
Added Kolab Repo and key, apt-get update, apt-get upgrade, apt-get install kolab.

Debian asked me for postfix configuration > i answered with "no configuration".
After all packages were installed I ran setup-kolab and answered all questions > OK.

Logged into kolab-webadmin and added a kolab mail-user > OK.
Logged into webmal (Roundcube) and tried to send mail to myself > Error.

First error I found in /var/log/mail.log was that transport.db was missing.
OK > postmap /etc/postfix/transport > fixed.
Second error I found was something about "submission premature error".
I did not find any solution to this so I changed roundcubes smtp_port from 587 to 25.
Tried to send the mail again > another error.
Checked /var/log/mail.log > TLS error > TLS is enforced.
Checked /etc/postfix/main.cf > no "smtpd_tls_cert_file" and no "smtpd_tls_key_file".
Added them pointing to Debian standard /etc/ssl/certs/ssl-cert-snakeoil.pem and /etc/ssl/private/ssl-cert-snakeoil.key.
Tried to send the mail again > SUCCESS.

Some things went wrong during setup-kolab.
After that I checked tls certs and keys for imapd, guam, etc.

Guam and Cyrus use /etc/ssl/private/cyrus-imapd.pem for key and cert - why not buildin snakeoil?
This cert was generated for "localhost.localdomain" - why not FQDN of host?
This cert ist only 365 day valid - why?

Please don't misunderstand me, but...

1. having different certs for different services on same server makes no sense in manner of administration.
2. why not use buildin solution > snakeoil.
3. Sure - these ones should be replaced with "real" ones but not necessary even in production environments where you have a reverse proxy holding all certs for all servers and ease adminstration. changing selfsigned certificates every year is a no-go.

Checked /usr/lib/python2.7/dist-packages/pykolab/setup/setup_mta.py to find out why the cert and key where not enabled in postfix.

cat /usr/lib/python2.7/dist-packages/pykolab/setup/setup_mta.py| grep tls

        "smtpd_tls_auth_only": "yes",
        "smtpd_tls_security_level": "may",
        "smtp_tls_security_level": "may",
if os.path.isfile('/etc/pki/tls/certs/make-dummy-cert') and not os.path.isfile('/etc/pki/tls/private/localhost.pem'):
    subprocess.call(['/etc/pki/tls/certs/make-dummy-cert', '/etc/pki/tls/private/localhost.pem'])
if os.path.isfile('/etc/pki/tls/private/localhost.pem'):
    postfix_main_settings['smtpd_tls_cert_file'] = "/etc/pki/tls/private/localhost.pem"
    postfix_main_settings['smtpd_tls_key_file'] = "/etc/pki/tls/private/localhost.pem"

Again "different" cert and key and it fails because these paths are used on "rpm" based distros I think but not "apt" based like Debian/Ubuntu.

These little bugs really kill the out-of-the-box experience but can easily be fixed in the kolab templates and python setup scripts.

When I have more time I will look into the submission problem - also I don't like submission.
Is submission necessary/mandatory for something else?