Bekanntlich bietet SMTP von Haus aus keine Authentifizierungsmechanismen. Zweifelsohne hat die Verfügbarkeit nicht authentifizierender SMTP-Server, sogenannter offener Relays, der heute allgegenwärtigen Spam-Problematik enormen Vorschub geleistet. Wer wie in unserem Beispiel einen eigenen Mailserver mit direkter Internetanbindung plant, muss sich daher Gedanken über die Authentifizierung seiner Clients machen, sofern es sich nicht um Hosts aus den eigenen Netz handelt. Die SASL-Bibliotheken haben sich in diesem Zusammenhang über die Jahre als zuverlässige SMTP-AUTH-Lösung bewährt und existieren sowohl in einer Implementation für Cyrus als auch für Dovecot. SASL lässt sich mit folgenden Directiven in
»/etc/postfix/main.cf
«
aktivieren:
smtpd_sasl_auth_enable = yes smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_local_domain = $mydomain
Dabei legt
»smtpd_sasl_type
«
die Art der SASL-Implementierung fest,
»smtpd_sasl_path
«
den Pfad zum Authentifizierungs-Daemon. Achtung: Die Pfadangabe zum SASL-Daemon erfolgt hier aus den geschilderten Gründen relativ, weil Postfix im Beispiel auf Basis von Ubuntu (Debian) zum Einsatz kommt und daher im Chroot-Modus läuft. Der Einsatz der Dovecot-SASL-Bibliotheken und -Module sorgt dafür, dass nur solche Clients E-Mails über den konfigurierten SMTP-Server versenden dürfen, die sich vorher erfolgreich bei diesem authentifiziert haben. Postfix-seitig genügt dazu das gezeigte Aktivieren von Dovecot SASL, weil Dovecot dann die gesamte Authentifizierung selbst übernimmt.
SASL sorgt zwar dafür, dass sich Clients gegenüber dem SMTP-Server authentifizieren können, die eigentlichen Zugangsdaten gehen aber ohne weitere Konfiguration im Klartext beziehungsweise Base64 kodiert über die Leitung. Daher ist es für einen sicheren Mailserver auf jeden Fall unumgänglich, die gesamte Kommunikation zwischen Client und Server mit TLS zu verschlüsseln. Damit Postfix TLS verwendet, muss der Administrator die Datei
»/etc/postfix/main.cf
«
um einige Direktiven erweitern. Zunächst schaltet die Anweisung
»smtpd_use_tls=yes
«
die TLS-Verschlüsselung ein. Das auf den ersten Blick tolerante Security-Level
smtpd_tls_security_level = may
ist leider meist nötig, weil es sonst nicht möglich wäre, E-Mails von Mailservern ohne TLS-Unterstützung anzunehmen. Insofern ist der Parameter auch nur mit
»may
«
wirklich sinnvoll, wenngleich
»encrypt
«
konsequenter wäre. Daher ist auch
»smtpd_tls_auth_only = no
«
folgerichtig. Danach folgen die Pfade zu den Zertifikats- und Schlüsseldateien.
smtpd_tls_cert_file=/etc/ssl/certs/Zertifikat.pem smtpd_tls_key_file=/etc/ssl/private/Schluessel.key
Außerdem muss der Admin die folgenden beiden TLS-spezifischen Zeilen in die
»main.cf
«
einfügen:
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtpd_tls_received_header = yes tls_random_source = dev:/dev/urandom
Was die SSL-Zertifikate angeht, spricht nichts dagegen, ein freies Zertifikat, etwa von CAcert, zu verwenden. Hat der Admin beispielsweise ein CAcert-Zertifikat generiert, das für alle Hosts der Domain
»meinefirma.de
«
gültig ist, muss er das Zertifikat
»
Zertifikat
.pem
«
nach
»/etc/ssl/certs
«
und die zugehörigen privaten Schlüssel
»
Schluessel
.key
«
nach
»/etc/ssl/private
«
kopieren und darf danach nicht vergessen, den privaten Schlüssel vor Lesezugriffen Dritter zu schützen (
»chmod 0600
«
).
Selbstverständlich spricht auch nichts dagegen, mit OpenSSL selbst temporär gültige lokale Zertifikaten zu verwenden. So erstellt etwa
openssl genrsa -out mail.key 2048
einen privaten RSA-Schlüssel mit 2048 Bit Länge und
openssl req -new -key mail.key -out mail.csr
erstellt einen sogenannten CSR (Certificate Signing Request), der die Funktion eines public key, erweitert um einige zusätzlichen Informationen, übernimmt. Hier muss der Admin nur darauf achten, bei der Frage nach dem Common Name (CN) den gewünschten vollständigen Hostnamen einzutragen (zum Beispiel
»mail.meinefirma.de
«
). Mit
openssl x509 -req -days 365 -in mail.csr -out mail.cert -signkey mail.key
kann der Admin dann ein selbst signierten Zertifikat mit einer Gültigkeit von 365 Tagen erzeugen.