Mails von Kolab 3.2 mit externem Mailserver des ISP versenden

Hallo.
Nachdem Kolab installiert ist, kann man mit mehreren Benutzern bereits intern Mailverkehr haben 🙂
Selbstverständlich reicht das aber nicht, man will ja auch anderen Leuten mail schicken können.

Ich habe meine Webseiten beim großen deutschen Hoster STRATO. Dank einiger Umbrüche in letzter Zeit gibts hier einiges zu beachten.
Exemplarisch beschreibe ich nun, wie man ausgehenden Mailverkehr über den Kunden-Mailserver bei Strato einrichtet.
Dabei werden die Mails genau so versandt, wie es ein Mailclient auch tuen würde, etwa Thunderbird oder Outlook.


Bei Strato gibt es zu beachten: Nach den Enthüllungen über die umfassenden Geheimdienstaktivitäten durch Edward Snowden hat Strato die eigenen Mailserver angepasst. Ab 01/2013 koennen nur noch Mailkonten angelegt werden, die Verschlüsselt per SSL kontaktiert werden müssen.

Dabei geht Strato weiter als andere Anbieter. Im gegensatz zu z.B. GMX, die eine unverschlüsselte Verbindung auf Port 578 mit nachfolgendem StartTLS Befehl (Umschalten auf verschlüsselte Kommunikation) anbieten, besteht Strato auf einer von Anfang an verschlüsselten Kommunikation.
Dazu soll der SMTP Server auf Port 465 mit einer SSL-Verbindung kontaktiert werden, bevor irgendetwas anderes passiert.
Dazu werden alle anderen verbindungsversuche über Port25 und 578 sofort nach zustandekommen ohne Fehlermeldung wieder abgebrochen.

Der bei Kolab verwendete Mailserver POSTFIX jedoch beherrscht kein SMTPS (SMTP over SSL) auf port 465 und wechselt trotz anderer configuration selbstständig auf das Verfahren StartTLS auf Port578, und wird dort vom Strato-server sofort wieder vor die Tür gesetzt.

Dieses Problem kann man nur lösen, wenn man die Kontaktaufnahme zum Strato-Server über einen Tunnel leitet, der bereits außerhalb des Mailservers die SSL-Verschlüsselung bereitstellt.
Dazu bietet sich das debian-Paket stunnel4 an.
Nach dem Installieren (z.B. per apt-get) muss die configuration angepasst werden:
Mit touch /etc/stunnel/stunnel.conf kann die konfigurationsdatei angelegt werden.
Ein editor (ebenfalls mit Rootrechten) kann dann die Datei bearbeiten.
(Ich verwende gerne den MC, wer sich noch mit dem legendären Norton Commander auskennt kommt auf anhieb damit zurecht)

Ich habe aus der Beispielconfig (siehe Readme) mir die passenden Zeilen herauskopiert und entsprechend angepasst:

; PID is created inside the chroot jail
pid = /stunnel4.pid

; Debugging stuff (may useful for troubleshooting)
;debug = 7
;output = /var/log/stunnel4/stunnel.log

; * Service defaults may also be specified in individual service sections *
; Disable support for insecure SSLv2 protocol
options = NO_SSLv2

; * Service definitions (remove all services for inetd mode) *
[strato-smtps]
client = yes
accept = 127.0.0.1:10010
connect = smtp.strato.de:465

Kurz zur Erläuterung: Der SSL-Tunnel-daemon lauscht auf der internen IP-Adresse 127.0.0.1 Port 10010 und schleust die ankommenden Daten durch den Tunnel auf die SSL-Verbindung zum Strato-SMTP-Server auf Port465.

Damit ist schon einmal die SMTPS-Verbindung eingerichtet.

Jetzt kommt der Mailserver an die Reihe:
Bei Strato ist man gezwungen, Mails mit der zur Authentifizierung passenden Mailadresse einzuliefern. Es werden keine Mails angenommen, die nicht von dem zum Nailaccount passenden Absender stammen. Will man so wie ich mehrere Mailadressen verwenden, muss man den Mailserver so einrichten, das er für jede Mailadresse das jeweils dazu gehörene Passwort verwendet.
Außerdem muss jeweils vor dem Mailversand die entsprechende Authentifizierung durchgeführt werden.
Das geht so:

/etc/postfix/main.cf

# See /usr/share/postfix/main.cf.dist for a commented, more complete version

# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA’s job.
append_dot_mydomain = no

# Uncomment the next line to generate „delayed mail“ warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = kolab.home.gafu.de

alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = ldap:/etc/postfix/ldap/mydestination.cf
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_command = procmail -a „$EXTENSION“
mailbox_size_limit = 0
recipient_delimiter = +
local_recipient_maps = ldap:/etc/postfix/ldap/local_recipient_maps.cf
inet_interfaces = all
transport_maps = ldap:/etc/postfix/ldap/transport_maps.cf, hash:/etc/postfix/transport
content_filter = smtp-amavis:[127.0.0.1]:10024
virtual_alias_maps = $alias_maps, ldap:/etc/postfix/ldap/virtual_alias_maps.cf, ldap:/etc/postfix/ldap/virtual_alias_maps_mailfor
warding.cf, ldap:/etc/postfix/ldap/virtual_alias_maps_sharedfolders.cf, ldap:/etc/postfix/ldap/mailenabled_distgroups.cf, ldap:/e
tc/postfix/ldap/mailenabled_dynamic_distgroups.cf
submission_sender_restrictions = reject_non_fqdn_sender, check_policy_service unix:private/submission_policy, permit_sasl_authent
icated, reject
submission_recipient_restrictions = check_policy_service unix:private/submission_policy, permit_sasl_authenticated, reject
submission_data_restrictions = check_policy_service unix:private/submission_policy

#incoming mail
smtpd_sender_login_maps = $relay_recipient_maps
smtpd_tls_auth_only = yes
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_pipelining, reject_rbl_client zen.spamhaus.org, reject_non_fqdn_r
ecipient, reject_invalid_helo_hostname, reject_unknown_recipient_domain, reject_unauth_destination, check_policy_service unix:pri
vate/recipient_policy_incoming, permit
smtpd_tls_security_level = may
smtpd_sasl_auth_enable = yes
smtpd_sender_restrictions = permit_mynetworks, check_policy_service unix:private/sender_policy_incoming

#outgoing mail
relayhost = [127.0.0.1]:10010
sender_canonical_maps = hash:/etc/postfix/sender_canonical
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
smtp_tls_security_level = may
smtp_sender_dependent_authentication = yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous noplaintext

Ich denke mit den kommentaren „incoming“ und „outgoing“, insbesondere letzterem kann jeder die entsprechenden Einträge auffinden.
Der letzte Absatz ist natürlich der entscheidende.
„sender_canonical_maps“ dient einem Mapping der E-Mail-adressen von den Lokalen Mailserveradressen auf die Adresse des Mailkonto bei Strato, ich nenne es jetzt „externe Adresse“
„sender_dependent_relayhost“ erlaubt die verwendung von verschiedenen externen Mailservern (also verschiedene Mailanbieter)
„sender_sasl_password_maps“ enthält die Passworte zu den externen Mailkonten.

Der Inhalt der Dateien ist folgender:
/etc/postfix/sender_canonical:
interne_mail_1@fqdn externe_mailadresse@externe_domain.com

/etc/postfix/sender_relay
interne_mail_1@fqdn [127.0.0.1]:10010

Ganz klar gehts hier in den Port des SSL-Tunnels, der zu smtp.strato.de:465 mit SSL weiterleitet.
Statt der IP können andere Mailserver von dritten Anbietern auch eingetragen werden, wenn man mehrere verwenden möchte.

/etc/postfix/sasl_passwd
externe_mail@externe_domain.com externe_mail@externe_domain.com:[ext_mailpw]

Um die Daten in ein für den Mailserver brauchbares Format zu bringen, müssen diese in Datenbanken umgewandelt werden. Außerdem ist der Tunnel zu starten und der Mailserver neu zu starten, um die Daten zu übernehmen:

/etc/init.d/stunnel4 start
cd /etc/postfix
postmap sasl_passwd
postmap sender_canonical
postmap sender_relay
/etc/init.d/postfix restart

Jetzt geht ausgehende Mail auch mit dem Strato-Mailserver. Gehts nicht, dann die Fehlerlogs mal durchsehen:
cat /var/log/mail.log | grep postfix

Viel Erfolg!

edit: Bei mir ist der Fehler „Destination Host unrechable“ beim Mail-versenden aufgetreten. Das lag daran, dass in der VM ipv6 lief, aber der Host nur für IPv4 konfiguriert ist. Daher kann es sinnvoll sein in der VM ebenfalls IPv6 zu deaktivieren.

Nachtrag: Die default-configuration von Postfix nimmt nur mails bis maximal 5 Mbyte an, sofern nichts anderes in der config steht. Sind mails, die mit Fetchmail abgeholt werden, größer, wird die mail nicht angenommen, und eine Mailer-Daemon (Bounce-) Mail versandt. Diese geht zurück an den Empfänger. Da die Absenderadresse nun MAILER-DAEMON@host ist, muss ggf. noch die Adresse entsprechend umgemappt werden, damit sie korrekt versendet werden kann. Alternativ können bouncemails abgestellt werden (werden dann statt an den Absender an der Postmaster versendet) oder bereits im Fetchmail die Mailgröße auf ein Maß beim abrufen beschränkt werden, die Postfix auf jeden fall annimmt.
Um die Postmaster Mails zugestellt zu bekommen, muss Root und / oder Postmaster als lokale zusätzliche (alias-)email-Adresse im Kolab-Webadmin einem Nutzerkonto hinzugefügt werden. Sonst entstehen weitere Bouncemails.

Ein Gedanke zu „Mails von Kolab 3.2 mit externem Mailserver des ISP versenden“

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert