Herzlich willkommen zurück bei der Artikelreihe „Der eigene Mailserver“.
Der erste Artikel dieser Reihe handelte von dem zu Grunde liegenden Serverbetriebssystem, dem Remote-Zugriff über SSH und der Installation der ersten Pakete.
In dieser Ausgabe geht es vor allem um die folgenden drei Punkte:
- Erwerb und Installation eines SSL/TLS Zertifikats.
- Grundlegende Konfiguration von Postfix, so dass E-Mails versendet und empfangen werden und Postfix mit Dovecot zusammenarbeitet.
- Grundlegende Konfiguration von Dovecot. Es werden drei virtuelle Benutzer und Mailverzeichnisse angelegt.
Und los geht’s!
Eine Sache noch…
Im ersten Artikel dieser Reihe habe ich geschrieben, dass der Betrieb eines Mailservers im Internet eine verantwortungsvolle Aufgabe ist. Dabei habe ich darauf hingewiesen, dass man stets die Sicherheit des eigenen Systems im Blick haben sollte. Daher ist es, denke ich, ein guter Zeitpunkt, an dieser Stelle zu prüfen, ob es Updates für den eigenen Server gibt und diese zu installieren.
Bei einem Ubuntu Server kann dies ganz einfach mit dem folgenden Befehl durchgeführt werden.
:~$ sudo apt-get update && sudo apt-get upgrade
SSL/TLS Zertifikat
Bei der Installation von Postfix und Dovecot im letzten Artikel wurde gefragt, ob man ein selbstsigniertes Zertifikat für Dovecot nutzen möchte. Dies habe ich verneint. Denn für einen Mailserver im Internet benötigt man ein gültiges und vertrauenswürdiges Zertifikat.
Gültig und vertrauenswürdig bedeutet in diesem Fall, dass das Zertifikat von einer anerkannten Zertifizierungsstelle ausgegeben wurde. Dieses Zertifikat wird vom Mailserver genutzt, um sich anderen Mailservern gegenüber zu identifizieren. Selbstsignierte Zertifikate oder jene der gemeinschaftlichen Zertifizierungsstelle CAcert werden von anderen Mailservern in der Regel nicht akzeptiert.
Zum Glück gibt es für Privatpersonen die Möglichkeit, kostenlos ein SSL/TLS Zertifikat z.B. bei der Zertifizierungsstelle StartSSL[1. StartSSL] zu erhalten. Da ich noch kein Zertifikat besitze, werde ich im folgenden die Schritte dokumentieren, um ein Zertifikat von StartSSL zu erhalten. Für die folgenden Schritte muss JavaScript im Webbrowser aktiviert sein.
Wer bereits über ein gültiges und vertrauenswürdiges Zertifikat verfügt, kann dieses natürlich auch verwenden und diesen Abschnitt überspringen.
Mit der Express Lane geht es weiter zum nächsten Schritt, wo die Daten zur Person abgefragt werden und die CA Policy akzeptiert werden muss. Anschließend erhält man einen Authentifizierungscode per E-Mail.
Die Authentifizierung bei StartSSL erfolgt nicht wie gewohnt mit Benutzername und Passwort, sondern mittels eines Client-Zertifikats, welches mit Hilfe des Webbrowsers generiert und anschließend im Browser installiert wird.
- Generierung des privaten Schlüssels
- Installation des Client Zertifikats
- Abschluss der Installtion
Anschließend ist man direkt in seinem Account angemeldet und durchläuft den Assistenten, um die eigene Domain zu verifizieren. Man folgt der Express Lane, bis man bei folgendem Schritt angelangt ist. Den privaten Schlüssel sollte man tunlichst nicht auf dieser Seite generieren![2. Privaten Schlüssel erstellen]
Den privaten Schlüssel sollte man immer auf einem der eigenen Systeme generieren. Dieser gehört niemals in die Hände von Dritten. Auch nicht in die einer Zertifizierungsstelle. Daher erstellen wir den privaten Schlüssel und den Certificate Signing Request (CSR) auf dem eigenen Server.
Da für die folgenden Schritte root-Rechte benötigt werden, wechseln wir mit folgendem Kommando den Benutzer, um uns die Arbeit ein wenig zu erleichtern.
johndoe@server:~$ sudo su root@server:/home/johndoe#
Nun erstellt man mit dem folgenden Befehl den privaten Schlüssel. Dieser wird als domainname-private-ssl.key gespeichert.
root@server:/home/johndoe# openssl genrsa -out /home/johndoe/domainname-private-ssl.key 4096
Die Angabe 4096 stellt die Stärke bzw. Länge des Schlüssels in Bit dar. Achtung: Schlüssel mit einer Länge von unter 2048 Bit gelten heute nicht mehr als sicher.
Nun kann mit dem nächsten Befehl der CSR erstellt werden. Die Angaben im Code unten stellen dabei Beispiele dar. Beim Common Name ist der Name einzutragen, unter dem der Server später im Internet erreichbar sein wird. Es wird kein „challenge password“ vergeben. Dies müsste später bei jedem Neustart des Webservers eingegeben werden oder im Klartext in einer Textdatei hinterlegt werden. Der erste Fall ist extrem unpraktisch und der zweite extrem unsicher.
root@server:/home/johndoe# openssl req -new -key domainname-private-ssl.key -out /home/johndoe/domainname.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:DE State or Province Name (full name) [Some-State]:Nordrhein-Westfalen Locality Name (eg, city) []:. Organization Name (eg, company) [Internet Widgits Pty Ltd]:. Organizational Unit Name (eg, section) []:. Common Name (e.g. server FQDN or YOUR name) []:server.domainname.tld Email Address []:webmaster@domainname.tld Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: johndoe@server:/home/johndoe#
Den Inhalt des CSR kopiert man nun in das Eingabefeld des Certification Wizard von StartSSL. Man befolgt die weiteren Schritte des Assistenten und am Ende wird das neu erstellte SSL-Zertifikat angezeigt. Dieses kopieren wir nun in die Datei /etc/ssl/private/ssl-cert-mail-yourdomain.pem. Verwendet man dabei einen Editor wie vim, nutzt man :set paste, bevor man den Text des Zertifikats einfügt. Den im vorhergehenden Schritt erstellten privaten Schlüssel und den CSR kopiert man ebenfalls in das Verzeichnis /etc/ssl/private. Jetzt lädt man noch das Intermediate Zertifikat von StartSSL mittels des folgenden Befehls in das gleiche Verzeichnis herunter.
root@server:/home/johndoe# cd /etc/ssl/private/ root@server:/etc/ssl/private# wget https://www.startssl.com/certs/sub.class1.server.ca.pem --2014-12-20 14:09:08-- https://www.startssl.com/certs/sub.class1.server.ca.pem Resolving www.startssl.com (www.startssl.com)... 192.116.242.20 Connecting to www.startssl.com (www.startssl.com)|192.116.242.20|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 2212 (2,2K) [application/x509-ca-cert] Saving to: ‘sub.class1.server.ca.pem’ 100%[========================================================================================================================================>] 2.212 --.-K/s in 0s 2014-12-20 14:09:09 (63,3 MB/s) - ‘sub.class1.server.ca.pem’ saved [2212/2212] root@server:/etc/ssl/private#
Als nächstes verknüpft man das Zertifikat mit dem Intermediate-Zertifikat der Zertifizierungsstelle zu einem sogenannten „chain-certificate“. Das sind zwei Zertifikate in einer Datei. Dies ermöglicht es einem Client, die komplette Zertifizierungskette zu überprüfen.
:/etc/ssl/private# cat ssl-cert-mail-domainname.pem sub.class1.server.ca.pem > ssl-chain-mail-domainname.pem
Das soeben erstelle Zertifikat wird später sowohl für Postfix, als auch für Dovecot benutzt. Doch bevor wir fortfahren, schützen wir noch unseren privaten Schlüssel vor unbefugtem Zugriff, indem wir einzig dem root-Benutzer Leserechte auf diese Datei einräumen.
chmod 400 my-it-brain-private-ssl.key
Jetzt wo ich alle Zertifikate in der Reihe habe, geht es an die Konfiguration von Postfix.
/etc/postfix/main.cf
Los geht’s mit:
$ sudo vim /etc/postfix/main.cf
Im Folgenden wird die main.cf
dargestellt, wie sie nach der Bearbeitung aussieht. Diese Datei ist nicht für Copy & Paste geeignet. Zum einen funktioniert die Datei nicht und zum Anderen möchte man ja auch erst verstehen, was dort passiert ist. Wer in die Tiefen der Postfix Konfiguration eintauchen möchte, dem sei die offizielle Dokumentation ans Herz gelegt.[3. Postfix Documentation] Die wesentlichen Elemente der Konfigurationsdatei werden im Folgenden näher beschrieben.
# 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 ## Customized smtpd parameters smtpd_banner = $myhostname ESMTP smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, reject_unknown_helo_hostname, permit smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_client_hostname, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_sender smtpd_sender_restrictions = reject_unknown_sender_domain, reject_sender_login_mismatch, reject_unknown_sender_domain smtpd_sender_login_maps = $virtual_mailbox_maps ## Dealing with rejection: use permanent 550 errors to stop retries unknown_address_reject_code = 550 unknown_hostname_reject_code = 550 unknown_client_reject_code = 550 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_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. smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination myhostname = mx.domainname.de alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = /etc/mailname mydestination = mx.domainname.de, domainname.de, h2381200.stratoserver.net, localhost.stratoserver.net, localhost, localhost.domainname.de relayhost = mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 mailbox_command = /usr/lib/dovecot/deliver -c /etc/dovecot/dovecot.conf -m "${EXTENSION}" mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all home_mailbox = Maildir/ smtpd_sasl_auth_enable = yes smtpd_sasl_type = dovecot smtpd_sasl_path = private/dovecot-auth smtpd_sasl_authenticated_header = yes smtpd_sasl_security_options = noanonymous smtpd_sasl_local_domain = $myhostname broken_sasl_auth_clients = yes smtp_use_tls = yes smtpd_tls_received_header = yes smtpd_tls_mandatory_protocols = SSLv3, TLSv1 smtpd_tls_mandatory_ciphers = medium smtpd_tls_auth_only = yes tls_random_source = dev:/dev/urandom ## customized TLS parameters smtpd_tls_ask_ccert = yes smtpd_tls_cert_file = /etc/ssl/private/ssl-chain-mail-domainname.pem smtpd_tls_key_file = /etc/ssl/private/domainname-private-ssl.key smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt smtpd_tls_ciphers = high smtpd_tls_loglevel = 1 smtpd_tls_security_level = may smtpd_tls_session_cache_timeout = 3600s ## Customized Dovecot and virtual user-specific settings canonical_maps = hash:/etc/postfix/canonical home_mailbox = Maildir/ message_size_limit = 104857600 virtual_alias_maps = hash:/etc/postfix/virtual virtual_mailbox_domains = hash:/etc/postfix/virtual-mailbox-domains virtual_mailbox_maps = hash:/etc/postfix/virtual-mailbox-users virtual_transport = dovecot ## This setting will generate an error if you restart Postfix before ## adding the appropriate service definition in master.cf, so make ## sure to get that taken care of! dovecot_destination_recipient_limit = 1 ## Other customized mail server settings default_destination_concurrency_limit = 5 disable_vrfy_command = yes relay_destination_concurrency_limit = 1 smtp_tls_note_starttls_offer = yes
Ziemlich zu Beginn der Konfigurationsdatei steht die Variable myorigin
. Diese enthält den Namen des Mailservers. Auf einem debianbasierten System steht dieser Name in der Datei /etc/mailname.
Es gibt einige smtpd_sasl
Optionen in der Datei. SASL ist das Protokoll, über welches Dovcot und Postfix miteinander kommunizieren. Dank des unter Ubuntu verfügbaren Metapakets mail-stack-delivery
, welches im letzten Artikel installiert wurde, ist der Großteil der Konfiguration bereits erledigt.
myhostname
, mydestination
und mynetworks
definieren, wer der Mailserver ist und wo (in welchem Netz) sich dieser befindet. Die erste Variable sollte als erstes den FQDN enthalten und nachfolgend einige alternative Namen, unter denen der Mailserver erreichbar ist. Die letzte Variable enthält die Netzadresse in CIDR-Notation. Ihr Wert kann meist so belassen werden, wie man ihn vorfindet.
Mit den smtpd
Parametern geht es ans Eingemachte. Denn diese Parameter nehmen direkten Einfluss auf die Arbeitsweise des Mailservers.
Die Option smtpd_banner
legt fest, wie sich der Server gegenüber anderen Mailservern identifiziert. Bei Ubuntu enthält diese Option meist noch die Variablen $myhostname
und $mail_name
zusammen mit dem Zusatz Ubuntu
. Um möglichen Angreifern so wenig wie möglich über das eigene System zu verraten, kann diese Option auf das absolut notwendige Minimum gekürzt werden.
smtpd_banner = $myhostname ESMTP
smtpd_helo_required = yes
sorgt dafür, dass sich andere SMTP-Server erst identifizieren müssen, bevor Postfix SMTP-Kommandos von diesen akzeptiert. Mit Hilfe dieser und der nächsten Option wird festgelegt, wie Postfix entscheidet, ob Mails akzeptiert oder abgewiesen werden. So wird mit smtpd_helo_restrictions
festgelegt, welche HELO Nachrichten akzeptiert werden. permit_mynetworks
legt fest, dass Clients aus dem eigenen Netz übermitteln dürfen, was sie wollen. Die übrigen Optionen sind weitestgehend selbsterklärend. Sie weisen den Mailserver an, allen Servern, die einen Namen übermitteln, der nicht über einen DNS-Lookup aufgelöst werden kann, das internationale Zeichen der Freundschaft zu zeigen.
SSL/TLS
Jetzt wird das SSL Zertifikat eingebaut. Zuerst wird mit der Option smtpd_tls_ask_ccert = yes
festgelegt, dass Postfix andere Server auffordert, sich mit einem Zertifikat zu identifizieren. Die beiden Optionen smtpd_tls_cert_file
und smtpd_tls_key_file
enthalten den vollständigen Pfad zum SSL-Zertifikat und der Datei mit dem privaten Schlüssel, welcher zum Zertifikat gehört. smtpd_tls_CAfile
enthält den vollständigen Pfad /etc/ssl/certs/ca-certificates.crt
und hilft Postfix, die Zertifikate anderer Server zu überprüfen.
Die Option smtp_tls_ciphers = high
verbietet Postfix, schwache Verschlüsselungs-Chiffren zu verwenden. smtpd_tls_security_level = may
weist Postfix an, SSL/TLS zu verwenden, wenn der entfernte Server dies ebenfalls unterstützt. Damit folgt die Konfiguration dem RFC 2487.
master.cf
Es gibt noch eine Konfigurationsdatei, welche bearbeitet werden muss. /etc/postfix/master.cf steuert, wie Postfix mit anderen Diensten, wie z.B. Dovecot, interagiert. Hier wird festgelegt, dass Postfix auch auf Port 587 auf eingehende E-Mails lauscht und wie er sich mit Dovecot verbindet. Dazu sind zwei Änderungen notwendig.
Die folgende Zeile ist durch Entfernen des #
einzukommentieren:
#submission inet n - - - - smtpd
Am Ende der Datei wird der folgende Code eingefügt. Wichtig dabei ist, den Zeileneinzug der zweiten und dritten Zeile beizubehalten:
dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f ${sender} -d ${recipient}
Map Files
In den Postfix Konfigurationsdateien finden sich Verweise auf „maps“ und „hashes“. Dies sind Orte, wo Postfix Informationen speichert. Diese werden im Folgenden näher erläutert.
Die Datei /etc/aliases legt fest, welche lokalen Benutzerkonten welchen E-Mail Adressen zugeordnet sind. Damit kann gesteuert werden, an welche E-Mail Adressen Statusmeldungen gesendet werden, die von unterschiedlichen Anwendungen generiert werden. Ich habe meine Datei nach dem folgenden Muster aufgebaut:
postmaster: webmaster@yourdomain.com root: webmaster@yourdomain.com www-data: webmaster@yourdomain.com
Damit werden alle lokalen Mails an eine echte E-Mail Adresse gesendet.
Postfix liest seine Informationen jedoch aus einer Binärdatei. Diese wird mit dem folgenden Befehl erstellt.
sudo newaliases
Virtuelle Benutzer
Jetzt geht es darum, wie Postfix entscheidet, wie und wohin er E-Mails zustellt.
Zuerst wird die Datei /etc/postfix/virtual-mailbox-domains erstellt, welche die Domain(s) beinhaltet, für die der Mailserver zuständig ist. Der Inhalt der Datei ist simpel und sieht wie folgt aus.
yourdomain.tld OK
Aus dieser Map machen wir mit dem folgenden Kommando eine Hash-Datei.
postmap /etc/postfix/virtual-mailbox-domains
Als nächstes wird die Datei /etc/postfix/virtual-mailbox-users erstellt, welche Postfix mitteilt, für welche Benutzer er zuständig ist. Diese Datei besteht aus zwei Spalten. Ganz einfach ausgedrückt wird damit sichergestellt, dass wenn man sich als „name@domainname.tld“ am Dovecot anmeldet, Postfix weiß, dass man E-Mails von der Adresse „name@domainname.tld“ aus versenden darf.
Beispielinhalt der Datei:
you@domainname.tld you@domainname.tld postbot@domainname.tld postbot@domainname.tld webmaster@domainname.tld webmaster@domainname.tld
Wenn die Datei angelegt ist, führt man erneut das postmap
-Kommando aus.
postmap /etc/postfix/virtual-mailbox-users
Zuletzt wird noch die Map /etc/postfix/virtual erstellt. Mit Hilfe dieser Map können Alias-E-Mail Adressen den echten E-Mail Adressen zugeordnet werden. Die Aliase stehen dabei in der ersten, die ihnen zugeordneten „echten“ E-Mail Adressen in der zweiten Spalte.
Beispiel:
you@domainname.tld you@domainname.tld postbot@domainname.tld postbot@domainname.tld webmaster@domainname.tld webmaster@domainname.tld postmaster@domainname.tld webmaster@domainname.tld root@mail.domainname.tld webmaster@domainname.tld root@domainname.tld webmaster@domainname.tld abuse@domainname.tld webmaster@domainname.tld hostmaster@domainname.tld webmaster@domainname.tld
Benötigt man eine sogenannte Catch-All Adresse, fügt man noch folgende Zeile in die soeben erstellte Datei ein:
@domainname.tld you@domainname.tld
Ist man mit der Erstellung der Datei fertig, ist es wieder Zeit für postmap
:
postmap /etc/postfix/virtual
Ok. Zeit kurz durchzuatmen. Als nächstes legen wir einen Benutzer und ein Verzeichnis an, wo die Mails für unsere virtuellen Benutzer abgelegt werden. Ich halte mich hier an das Tutorial von ars technica und verwende für den benötigten lokalen Benutzer ebenfalls die UID 5000 und die GID 5000.[4. Lee Hutchinsoen: Taking e-mail back, part 2: Arming your server with Postfix and Dovecot:
Our self-hosting e-mail series continues as we get our ducks—and doves—in a row.] Im Dateisystem des Linux Root-Servers existiert bereits das Verzeichnis /var/mail. Hier landen die Mails für die lokalen Benutzer des Systems. Hier wird auch ein Verzeichnis angelegt, wo zukünftig alle Mails der virtuellen Benutzer landen. Dazu werden die beiden folgenden Befehle in einer root shell ausgeführt.
groupadd -g 5000 vmail useradd -g vmail -u 5000 vmail -d /var/mail/vmail -m
Jetzt geht es Dovecot an den Kragen.
Als erstes öffnet man die Datei /etc/dovecot/conf.d/10-ssl.conf und kommentiert die Zeilen 12 und 13 aus. Dies erspart Ärger mit der SSL-Konfiguration. Schließlich soll das eigens für den Mailserver erstellte SSL-Zertifikat verwendet werden.
Bevor es an die eigentliche Konfiguration geht, werden noch einige Zeilen in ein paar anderen Konfigurationsdateien auskommentiert, damit die Konfiguration später nicht durch diese Optionen überschrieben wird.
- Zeile
mail_location
in 10-mail.conf auskommentieren - Zeile
auth_mechanisms = plain
in 10-auth.conf auskommentieren - Die Sektion
passdb
in der Datei auth-system.conf.ext auskommentieren - Die Sektion
userdb
in der Datei auth-systems.conf.ext ebenfalls auskommentieren
Ist das erledigt, geht es nun der Datei 99-mail-stack-delivery.conf an den Kragen. Nach der Bearbeitung sollte diese wie folgt aussehen.
# /etc/dovecot/conf.d/99-mail-stack-delivery.conf
# Some general options
protocols = imap sieve
disable_plaintext_auth = yes
ssl = yes
ssl_cert = </etc/ssl/private/ssl-chain-mail-cert.pem
ssl_key = </etc/ssl/private/private-ssl.key
ssl_client_ca_dir = /etc/ssl/certs
ssl_cipher_list = ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:R
SA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS
mail_home = /var/mail/vmail/%d/%n
mail_location = maildir:/var/mail/vmail/%d/%n/mail:LAYOUT=fs
auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@
# IMAP configuration
protocol imap {
mail_max_userip_connections = 10
imap_client_workarounds = delay-newmail tb-extra-mailbox-sep
}
# LDA configuration
protocol lda {
postmaster_address = webmaster@my-it-brain.de
mail_plugins = sieve
quota_full_tempfail = yes
deliver_log_format = msgid=%m: %$
rejection_reason = Your message to <%t> was automatically rejected:%n%r
}
# Managesieve configuration
#protocol managesieve {
#listen = 127.0.0.1:2000
#login_executable = /usr/lib/dovecot/managesieve-login
#mail_executable = /usr/lib/dovecot/managesieve
#managesieve_max_line_length = 65536
#}
# Plugins configuration
plugin {
sieve=~/.dovecot.sieve
sieve_dir=~/sieve
sieve_before = /var/mail/vmail/sieve-before
sieve_after = /var/mail/vmail/sieve-after
}
# Authentication configuration
auth_mechanisms = plain login
passdb {
driver = passwd-file
args = username_format=%u scheme=ssha512 /etc/dovecot/passwd.db
deny = no
master = no
pass = no
skip = never
result_failure = continue
result_internalfail = continue
result_success = return-ok
}
userdb {
driver = static
args = uid=5000 gid=5000 home=/var/mail/vmail/%d/%n
}
# Log all failed authentication attempts
auth_verbose=yes
service auth {
# Postfix smtp-auth
unix_listener /var/spool/postfix/private/dovecot-auth {
mode = 0660
user = postfix
group = postfix
}
}
Was ist hier alles passiert?
Als Erstes wurde das POP3 Protokoll entfernt, da ich nur IMAP und Sieve nutzen werde. Sieve ermöglicht die Erstellung umfangreicher und flexibler Mailfilter-Regeln. Doch mehr dazu in Teil 3.
Als Nächstes wird SSL aktiviert und Dovecot der Ort des SSL-Zertifikats, des privaten Schlüssels und das Verzeichnis mit den Zertifikaten der Root CAs mitgeteilt.
Die mail_home
und mail_location
Direktiven legen fest, wo Dovecot die E-Mails zustellt. Hier sind zwei Variablen enthalten. „%d“ steht für die genutzte Maildomain. „%n“ steht für den Namen der virtuellen Benutzer. Dies bedeutet, dass eine E-Mail an „webmaster@domainname.tld“ im Verzeichnis /var/mail/vmail/domainname.tld/webmaster zugestellt wird.
Die mail_location
Direktive legt fest, dass das „maildir“ Format[5. Wikipedia: Maildir] genutzt wird. Das bedeutet, der Posteingang und weitere Verzeichnisse existieren auf dem Server in Form ganz normaler Verzeichnisse. Maildir ist eines von zwei weit verbreiteten E-Mail Speicherverfahren. Das andere ist MBOX, welches alle Nachrichten in einer einzigen langen Datei speichert. Ich habe mich für die Verwendung von Maildir entschieden, da ich so besser einzelne Nachrichten auf der Kommandozeile behandeln kann. Dies ist von Vorteil bei der Konfiguration und dem Training des Anti-Spam Systems in Teil 3 dieser Artikelreihe.
In der Sektion passdb
wird definiert, wie und wo die Passwörter der virtuellen Benutzer gespeichert werden. Die Optionen in dieser Sektion stellen sicher, dass ein Benutzer, der ein falsches Passwort eingibt, keinen Zugriff auf ein Postfach erhält.
Mit den Optionen unter userdb
wird festgelegt, dass ein virtueller Benutzer namens „vmail“ verwendet wird.
Bevor die Konfiguration von Dovecot beendet werden kann, sind noch die Passwörter für die virtuellen Benutzer zu vergeben, so dass diese sich mit einem Mailclient mit dem Server verbinden können, um E-Mails zu versenden und zu empfangen. Die Passwörter werden in diesem Fall in der verschlüsselten Datei /etc/dovecot/passwd.db gespeichert. Die Passwörter werden interaktiv in der Konsole generiert, damit sie nicht in der Bash-History gespeichert werden. Dabei hilft das doveadm Tool:
doveadm pw -s SSHA512
Das Tool fordert dazu auf, ein Passwort einzugeben und dieses zu bestätigen. Anschließend gibt es den verschlüsselten und gesalzenen String aus. Anschließend wird die Datei /etc/dovecot/passwd.db erstellt und nach diesem Muster gefüllt:
you@yourdomain.com:{SSHA512}OeR5ulGD3LZ0OHuj9muNqSvKB7hxsxnTquSd8AjK8QXrtOAGqxhxdRs093CzcuaX1PXmOkBGXbQCftYc0tpbo83uZ7Y= postbot@yourdomain.com:{SSHA512}BPhYH6qtRAtcpCpHxZ919HAve7GGYc4QIIGPIIPCQ2JHhsfVJkzbEsITNL9dvf20YsPNec68LjfLi+TXwS35RrOnElE= webmaster@yourdomain.com:{SSHA512}o0LG4pTPeHkTZDvqeQufuULcY07YPb2EyA46M5yYtZOAcLI2k4Ee7ADkHSePl/mYdinapCkc7ZEYDvOsi3wg/ungtos=
Jede Zeile startet mit der E-Mail Adresse des dazugehörigen E-Mail Kontos, gefolgt von einem Doppelpunkt und dem kompletten String für das verschlüsselte Passwort.
Der Posteingang und alles Andere
Die wirklich letzte zu bearbeitende Datei ist 15-mailboxes.conf, wo konfiguriert wird, welche Verzeichnisse für jeden virtuellen Benutzer erstellt werden. Hier wird sichergestellt, dass jeder Benutzer seinen eigenen Gesendet-, Entwürfe-, Spam-Ordner und Papierkorb bekommt. Es befinden sich bereits Ordnerdefinitionen in dieser Datei. Diesen fügen wir die Zeile auto = subscribe
hinzu. Die Datei sollte ohne Kommentare in etwa wie folgt aussehen:
namespace inbox { mailbox Drafts { special_use = \Drafts auto = subscribe } mailbox Junk { special_use = \Junk auto = subscribe } mailbox Trash { special_use = \Trash auto = subscribe } mailbox Sent { special_use = \Sent auto = subscribe } }
Dovecot wird neugestartet und anschließend testet man die Konfiguration mit
dovecot -n
Ähnelt die Ausgabe der folgenden, ist alles korrekt.
$ dovecot -n # 2.2.9: /etc/dovecot/dovecot.conf # OS: Linux 3.13.0-042stab092.3 x86_64 Ubuntu 14.04.1 LTS reiserfs auth_mechanisms = plain login auth_verbose = yes mail_home = /var/mail/vmail/%d/%n mail_location = maildir:/var/mail/vmail/%d/%n/mail:LAYOUT=fs managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave namespace inbox { inbox = yes location = mailbox Drafts { auto = subscribe special_use = \Drafts } mailbox Junk { auto = subscribe special_use = \Junk } mailbox Sent { auto = subscribe special_use = \Sent } mailbox Trash { auto = subscribe special_use = \Trash } prefix = } passdb { args = username_format=%u scheme=ssha512 /etc/dovecot/passwd.db driver = passwd-file } plugin { sieve = ~/.dovecot.sieve sieve_after = /var/mail/vmail/sieve-after sieve_before = /var/mail/vmail/sieve-before sieve_dir = ~/sieve } protocols = imap sieve service auth { unix_listener /var/spool/postfix/private/dovecot-auth { group = postfix mode = 0660 user = postfix } } ssl_cert = was automatically rejected:%n%r } protocol imap { imap_client_workarounds = delay-newmail tb-extra-mailbox-sep mail_max_userip_connections = 10 }
Damit ist das Ende von Teil 2 erreicht. Postfix und Dovecot sind fast vollständig konfiguriert. Was ist noch zu tun?
In Teil 3 dieser Artikelreihe geht es um DNS. Es werden DNS Einträge benötigt, damit Clients den Mailserver finden und auch E-Mails an den richtigen Server geroutet werden können. Außerdem wird es noch um ein paar spezielle DNS-Records gehen, die anderen Servern beweisen sollen, dass wir legitime E-Mails und keinen Spam versenden.
Ebenfalls wird es um eine Anti-Spam Lösung gehen. Spamassassin in Kombination mit einem Virenscanner. Der Mailserver wird nochmal auf Herz und Nieren geprüft und dann im großen weiten Internet bekannt gemacht.
Zum guten Schluss geht es in Teil 4 darum, wie der Webmailer Roundcube installiert und konfiguriert wird. Dieser Teil ist optional, da der Webserver bereist am Ende von Teil 3 fertig für den produktiven Einsatz ist. Aber mal ehrlich, was ist ein Mailsystem schon ohne Webmail?
Bis nächste Woche.
Hallo,
Du schreibst:
[…]
Die mail_home und mail_location Direktiven legen fest, wo Dovecot die E-Mails zustellt
[…]
In dem Listing darüber kann ich die nicht finden. Was übersehe ich?
Grüße,
Boris
Hallo Boris,
danke für den Hinweis. Da sind mir tatsächlich einige Zeilen der Konfiguration abhanden gekommen. Ich habe das Listing gerade mit der Live-Konfiguration auf meinem Mailserver abgeglichen.
Die aktuelle Konfiguration habe ich direkt im Artikel im Abschnitt „Jetzt geht es Dovecot an den Kragen“ eingefügt.
MfG
JohnDoe
Pingback: Der eigene Mailserver – TLS-Migration zu Let’s Encrypt | My-IT-Brain
Hallo,
Kommt der 3.Teil noch, oder übersehe ich den?
lg ronald
Hallo ronald,
hier findest du die folgenden Artikel:
Viele Grüße
Jörg
SUPER DAAAANKE! liebe Grüße Ronald!
Hallo, ich weiß nicht ob ich nur einen Knopf im Kopf habe, oder in der Konfiguration was fehlt… Wo wird definiert, dass sich die Dovecot-User am Postfix authentifizieren können? Ich habe zwar jetzt funktionierende Dovecot User, werde aber von Postfix mit den Usern abgelehnt…
Hallo ronald,
grundsätzlich wird die Benutzerkonfiguration im Abschnitt Virtuelle Benutzer und im direkt vorhergehenden Absatz „master.cf“ beschrieben.
Es ist jedoch noch nicht ganz verständlich was genau bei dir noch nicht funktioniert. Versuchst du dich mit einem Mailclient (MUA) an Dovecot anzumelden, um E-Mails aus den IMAP-Ordnern abzurufen? Oder möchtest du dich am Postfix authentifizieren, um eine E-Mail zu versenden? Was steht in den den Logs der beteiligten Dienste? Wie lautet die Fehlermeldung, die du bekommst?
Viele Grüße
Jörg
Lieber Jörg!
Danke für die Antwort. In dem Fall war der Fehler der übermüdete Admin der den Client falsch geconft hat!!! ;-)
Liebe Grüße aus Wien!
Ronald
Hallo,
ich habe die gesamte Artikelreihe durchgearbeitet. Mails von anderen werden bereits empfangen und können über imap abgerufen werden. Beim Senden habe ich allerdings noch ein Problem. Es sieht so aus als würde bei der Passwortprüfung die Domain im Nutzername verloren gehen. Irgendwelche Ideen woran das liegen könnte oder welchen Parameter ich eventuell doch falsch gesetzt habe?
Auszug aus dem Log:
postfix/smtpd[21274]: connect from unknown[IP_Client]
postfix/smtpd[21274]: Anonymous TLS connection established from unknown[IP_Client]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
dovecot: auth: Debug: auth client connected (pid=0)
dovecot: auth: Debug: client in: AUTH#0111#011PLAIN#011service=smtp#011nologin#011lip=IP_Server#011rip=IP_Client#011secured#011resp=
dovecot: auth: Debug: passwd-file(mail,IP_client): lookup: user=mail file=/etc/dovecot/passwd.db
dovecot: auth: passwd-file(mail,IP_client): unknown user
postfix/smtpd[21274]: warning: unknown[IP_client]: SASL PLAIN authentication failed:
dovecot: auth: Debug: client passdb out: FAIL#0111#011user=mail
Bei imap steht wie es sein sollte „passwd-file(mail@domain.tld,IP_client)“ im log.
Liebe Grüße und Lob für die tolle Artikelreihe
Marcel
Hallo Marcel,
leider ist dieser Fehler bei mir nicht aufgetreten und ich habe auch keine Lösung dafür zur Hand. Evtl. hilft es wenn du die Konfiguration noch einmal in aller Ruhe überprüfst. Sollte sich dabei kein Tippfehler finden, könntest du dich an ein Forum wie z.B. ubuntuusers.de wenden. Ich betreibe diesen Blog allein und kann hier leider keinen Support leisten.
Viele Grüße
Jörg
Hallo,
kurzum komme ich gleich zur sache.
im abschnitt: 99-mail-stack-delivery.conf
gibt es ein Darstellungsfehler welches sich auf die Konfiguration von DOVECOT fehlerhaft auswirkt.
Zeile 09 – 10:
ssl_cipher_list = ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS
führt der zeilenumbruch zu einem Fatal Error KA ob an mir liegt aber wenn ich den umbruch entferne läft alles ohne fehler.
Korekt:
ssl_cipher_list = ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS
Ich hoffe konte Helfen.
MfG Denisu
Zeile 09 – 10:
ssl_cipher_list = ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:R#—-HIER
Zeilenumbruch
HIER—-#SA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS
Hallo Jörg,
vielen Dank für deine super Anleitung!
In den main.cf Parametern scheint mir etwas zu fehlen. Beim Testen ist mir aufgefallen, dass mein Drucker/Scanner beim Senden von Scan-to-email Scanergebnissen zurückgewiesen wird mit „Helo command rejected: need fully-qualified hostname;“
Beim Suchen ist mir folgendes aufgefallen:
Die Zeile smtpd_helo_restrictions endet mit „permit“
smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, reject_unknown_helo_hostname, >>>>permit<<<>>>permit_sasl_authenticated<<<<, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, reject_unknown_helo_hostname
…und nun funktioniert das Senden von Scans über meinen Mailserver.
Viele Grüße,
Joachim
…hier ist etwas durcheinander geraten:
ALT:
smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, reject_unknown_helo_hostname, >>>>permit<<>>permit_sasl_authenticated<<<<, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, reject_unknown_helo_hostname
Joachim
Hallo Jörg,
für Umlaut-Domains muss in die Datei
/etc/postfix/main.cf
der Eintrag
smtputf8_enable = no
mit aufgenommen werden. Nur mit diesem Eintrag sendet bspw. gmail Punycode. Wenn der Eintrag fehlt, sendet gmail den Umlaut und das führt beim Setup zum Fehler, bzw. die E-Mail kommt nicht an. Gefunden hier:
https://gehirn-mag.net/das-xn-mrchen-bua-vom-punycode/?unapproved=155&moderation-hash=64047414caee535cf159f8a180954d58#comment-155
Lieben Gruß
Jens