Bevor wir daran gehen einen Mailserver zu installieren sollten wir uns über den genauen Einsatz und vor allem die Rahmenbedingungen Gedanken machen. Klar, ein Mailserver soll Mails verarbeiten. Die Frage ist aber vielmehr, wie soll denn unser Mailserver Emails an externe Konten zustellen. Also Email-Adressen, die nicht innerhalb der Email-Domäne (domain.org) des Mailservers liegen. Hierfür gibt es zwei Methoden. Entweder unser Mailserver stellt die Emails direkt an die Fremde Domäne zu oder aber man bedient sich eines sogenannten Smarthosts für die Zustellung. Hierbei versendet der Mailserver die Email nicht direkt an den Zielserver, sondern übergibt diese zunächst an einen (vertrauenswürdigen) Mailserver, der diese Email dann weiterleitet.
Hintergrund für die Verwendung eines Smarthosts ist, dass fast alle Emailserver keine Emails von Servern mit dynamischer IP Adresse annehmen. Denn in der Regel sind solche Server nichts weiter als Spamversender, in der Regel gekaperter Rechner, die als Spamschleudern dienen. Leider betrifft dieses Problem auch „saubere“ Mailserver wie z.B. meinen eigenen. Gut 80% der Emails, die man versucht direkt zu zustellen kommen nicht an. Daher habe ich mich entschieden, mir einen Anbieter zu suchen, der nach Authentifizierung durch einen entsprechenden Benutzeraccount Mail-Relaying zulässt. Also das versenden von Emails für einen Fremden Server. Die meisten Freemailer bieten diesen Dienst nicht an. Es gibt aber einige, wenige erfreuliche Ausnahmen. So zum Beispiel der Mailserver von Arcor, den auch ich als Smarthost benutzte.
Ob man die ausgehenden Emails verschlüsselt übertragen sollte, darüber sind sich viele uneins und es gibt in den Foren reichlich kontroverse Diskussionen zu dem Thema. Man sollte jedoch folgende Argumente einfach mal näher betrachten: Selbst wenn die Strecke zwischen meinem Server und dem Relay des Providers X verschlüsselt ist kann mir niemand garantieren, dass auch der nachgeschaltete Provider die Emails über einen verschlüsselten Kanal weiterleitet. Die große Masse der Mailserver tut das aus gut nachvollziehbaren Gründen nicht. Zum einen Kostet Verschlüsselung zunächst einmal Rechenzeit. Und diese kann je nach Transfervolumen (Mails/s) nicht unerheblich ausfallen. In der Regel wird das Transfervolumen durch die verschlüsselte Strecke auch noch größer. Zusätzlich zu der Rechenzeit, die der verschlüsselte Kanal benötigt steigt also auch noch die Netzlast. Und bei den Kosten kenne gerade Freemailer keinen Spaß. Trotz allem empfehle ich jedem verschlüsselte Verbindungen zu nutzen und diese auch anzubieten. Denn immerhin gehen sonst in der Regel auch die Passwörter der Mailserver-Benutzer unverschlüsselt über die Leitung. Und das will mit Sicherheit niemand. Gerade wenn es sich um den User handelt, den man als Relay benutzt.
Jetzt aber genug der Theorie! 🙂
Standardmäßig verwendet Debian den SMTP Server Exim, dieser ist auch in der Regel bei einer minimalen Grundinstallation – so wie unsere – mitinstalliert. Allerdings in einer abgespeckten Version, die nicht die kompletten Fähigkeiten von Exim abbilden kann (Paket exim-deamon-light ist installiert).
Zunächst stellen wir aber mittels apt sicher, dass wir auch auf aktuelle Paket-Quellen zugreifen und somit die neusten verfügbaren gepatchten Programme installieren:
apt-get update
Da wir vorhaben unseren Mailserver auf der Basis von Postfix aufzusetzen und Exim daher nicht mehr benötigen können wir getrost alle Exim-Pakete deinstallieren. Hierfür bietet sich entweder apt auf der Kommandozeile an oder das Programm Aptitude, mit dem man bequem in einem Programm mit Text-Menüführung die Pakete auswählen kann und sich z.B. auch noch einige Infos zu den Paketen anzeigen lassen kann. Die nötige Eingabe auf der Kommandozeile um Exim zu deinstallieren lautet:
apt-get remove --purge exim4*
Remove macht genau das, was man erwartet. Es deinstalliert die Pakete. Mittels der Option –purge sagen wir apt, dass es auch sämtliche Konfigurationsdateien etc. zu dem Programm gleich mit deinstallieren soll. Mit Aptitude geht es ähnlich simple. Entweder man hangelt sich durch das Menü oder man tippt den Shortcut „/“ für die Suche ein. In dem Suchfenster geben wir jetzt unseren nicht mehr benötigten „exim4“ ein. Mit der Taste „n“ (next) springt man zum nächsten Treffer. Mittels „-“ kann man ein Paket für die Deinstallation markieren, „+“ markiert ein Paket für die Installation. Mit „q“ kann man Aptitude beenden und mittels „g“ kann man dafür sorgen, dass die vorgemerkten Änderungen umgesetzt werden, also die Programme deinstalliert oder installiert werden.
Nachdem die Pakete deinstalliert sind können wir nun mit der Installation von Postfix starten. Hierfür lassen wir apt zunächst die benötigten Programme installieren:
apt-get install postfix sasl2-bin libsasl2-modules policyd-weight postfix-bld postfix-doc postfix-pcre postfix-gld procmail
Die Installation wird nicht sehr lange dauern, da die Pakete erfreulich schlank gehalten sind.
Da es sich bei meinem System um ein sehr kleines handelt und ich den Administrationsaufwand so gering wie möglich halten wollte habe ich mich dazu entschieden, dass jede Email-Adresse einen Linux Account auf dem Server voraussetzt. Außerdem sollen die Mails nicht unter /var/mails etc. abgelegt werden, sondern dediziert für jeden User in seinem Home-Verzeichnis. Somit kann man durch einfaches sichern des Homeverzeichnis alle Daten des Benutzers inkl. der Emails backupen.
Die Benutzer legt man einfach mit dem Befehl „adduser“ an. Das sieht dann so aus:
adduser mailbenutzer1
Der Rest geht dann von allein. Das Programm fragt einige Daten wie Name und Passwort für den Benutzer ab und legt diesen anschließend an. In der Standardeinstellung bekommt der angelegte Benutzer sein Home-Verzeichnis unter /home erzeugt.
Nun kann es durchaus sein, dass man keinen Benutzer mit dem Benutzernamen vorname.nachname anlegen möchte, nur damit man eine Email an die Email-Adresse an vorname.nachname@domain.org schicken kann. Hier kommen die Aliase ins Spiel. So ist es zum Beispiel möglich einen Alias für den angelegten Benutzer „hans“ zu hinterlegen, der es ermöglicht, eine Email an „hans.mueller@domain.org“ zu schicken. Der Mailserver erkennt, dass es sich bei der Email-Adresse nicht um ein real existierendes Konto handelt und leitet die Email intern an das für den Alias vorgesehene Konto.
Die Aliase pflegt man in der Datei /etc/aliases. Diese wird wie folgt aufgebaut:
server:~# cat /etc/aliases # /etc/aliases mailer-daemon: postmaster postmaster: root nobody: root
Es ist durchaus möglich, für einen Alias zwei oder mehr real existierende Konten zu hinterlegen. So kann man etwa Meldungen an den user root – der nebenbei ein real existierender Account ist! – an einen anderen oder mehrere andere Konten weiterleiten lassen.
Die eigentliche Konfiguration von Postfix erstreckt sich über lediglich 2 Dateien. Diese findet man in der Regel unter /etc/postfix- main.cf und master.cf. Über die Main-Datei wird Postfix mit Anweisungen und Verhaltensregeln versorgt, die Master-Datei steuert Parameter für die diversen Prozesse von Postfix. Die Anweisungen in der Main-Datei nimmt Postfix immer nach der Syntax „Anweisung = Wert“ entgegen. Als Wert können auch mehrere Werte angegeben werden. Diese werden dann entweder per Komma oder Leerzeichen getrennt angegeben werden.
Beginnen wir mit dem Anpassen der Konfigurationsdatei main.cf. Die folgenden Anweisungen werden nur in der main.cf eingetragen. Die master.cf werden wir später gesondert betrachten. Zunächst suchen wir folgende Zeile in der main.cf und ersetzen diese dann wie folgt:
alt: mailbox_command = procmail -a "$EXTENSION"
neu: mailbox_command = procmail -a "$EXTENSION" DEFAULT=$HOME/mails/
Die Anpassung sorgt dafür, dass procmail die Emails nicht unter /var/mail ablegt, sondern wie gewünscht im Home-Verzeichnis des entsprechenden Benutzers im Unterordner mails.
myhostname = host.domain.org
Mittles dem Parameter myhostname wird der Name des Mailservers festgelegt. Man sollte den Hostnamen unbedingt als Voll-Qualifizierten Namen angeben (FQDN). Das beudeutet sowohl den Hostnamen des Servers als auch dessen zugehörige Domain (hostname.domain).
mydomain = domain.org,
Dieser Parameter gibt Postfix den Domainnamen an, für den er sich verantwortlich zeigt. Sollte dieser Parameter nicht angegeben werden, ermittelt Postfix den Domainnamen automatisch aus der Hosts.
alias_maps = hash:/etc/aliases
Hier teilt man Postfix mit, in welcher Datei hinterlegt ist, wie Email-Adressen und Aliases zugewiesen werden. Sollten an der Datei Änderungen vorgenommen worden sein, so muss man Postfix dies mitteilen.
postalias /etc/aliases
Durch diesen Befehl wird die Hashtable, die Postfix benutzt aktualisiert.
alias_database = hash:/etc/aliases
Der Parameter zeigt Postfix den Ort der zu verwendenden Hashtable an.
myorigin = /etc/mailname
Gibt Postfix den Domainnamen für ein Masquerading des Envelopes oder Header ein.
mydestination = $myhostname, localhost.$mydomain, $mydomain, $localhost,
Mit diesem Parameter geben wird geben wir Postfix alle Domains mit, für die er Emails annehmen soll. Soll Postfix mehrere verschiedene Domains verwalten, so verwendet man in der Regel den Parameter virtual_alias_domains.
smtpd_banner = $myhostname ESMTP Mailserver
Hier kann man den Begrüßungstext angeben, den Postfix beim Verbindungsaufbau anzeigen soll. Aus Sicherheitsgründen sollte man es vermeiden das Produkt und die Versionsnummer mit auszugeben. Eventuell betreibt man eine ältere Version der Software, die ungepatchte Sicherheitslöcher aufweist. Hierauf muss man einen potentiellen Angreifer natürlich nicht noch extra aufmerksam machen.
mailbox_size_limit = 11240000
Die Größe der Mailbox lässt sich mit diesem Parameter beschränken. Der Einsatz ist vor allem in Verbindung mit Mailquoten sinnvoll. (Die Angabe erfolgt in Bytes ~ 10.72 MB)
message_size_limit = 10240000
Die maximale Emailgröße die der Mailserver akzeptiert lässt sich mit diesem Parameter beeinflussen.
smtpd_helo_required = yes
Der Mailserver erfordert ein ehlo oder helo bei der Verbindungsinitiierung.
smtpd_helo_restrictions = reject_invalid_hostname
Falsche Hostnamen (Syntax) beim HELO bzw. EHLO Kommando werden nicht akzeptiert.
smtpd_recipient_restrictions = permit_mynetworks, reject_unknown_recipient_domain, permit_sasl_authenticated, reject_unauth_destination
Hiermit werden Regeln für den Client festgelegt, an die er sich bei der Kommunikation zu halten hat.
permit_mynetworks: Hiermit kann man Mail relaying erlauben. Achtung, standardmäßig sollte hier nur das lokale Loopback Netzwerk 127.0.0.0/8 eingetragen sein.
reject_unknown_recipient_domain: Nur Domains mit gültigem A Record oder MX Record der Empfängerdomain werden akzeptiert.
permit_sasl_authenticated: Mail relaying wird erlaubt, wenn man sich per saslauthd authentifiziert hat.
reject_unauth_destination: Die Anfrage wird abgelehnt, wenn keine der folgenden Bedingungen zutrifft:
- Die Domain oder eine Subdomain der Domain ist unter $relay_domains angegeben
- Der Mailserver ist das endgültige Ziel der ankommenden e-mail
smtpd_sender_restrictions = reject_unknown_address
Erlaubt nur Mails von einem Client, wenn die Domain einen korrekten A oder MX Record hat.
smtpd_client_restrictions = reject_invalid_hostname
Gibt an von welchen Clients SMTP Verbindungen akzeptiert werden
reject_invalid_hostname: Ungültige Hostnamen werden zurückgewiesen
strict_rfc821_envelopes = yes
E-mail Adressen müssen RFC 821 konform (<mail@domain.org>) angegeben werden.
home_mailbox = mails/
Sorgt dafür, dass im Home-Verzeichnis des entsprechenden Benutzers ein Verzeichnis mails erstellt wird, das die Emails im Maildir Format speichert.
Mit dieser Grundkonfiguration könnte man Postfix schon in Betrieb nehmen. Soviel zur Theorie. In der Praxis fehlt uns allerdings noch die ein oder andere Kleinigkeit. So zum Beispiel SASL (Simple Authentication and Security Layer), TLS (Transport Layer Security) und eventuell Virtual Domain Support zum Verarbeiten mehrere Domains.
Die Integration von amavisd-new und den von amavis verwendeten Tools werde ich gesondert behandeln. Ebenso wie die Konfiguration von procmail und dovecot als IMAP und oder POP3 Server.
Wir benutzten SASL innerhalb dieses How-to’s um die Authentifizierung der Clients zu managen. Damit unsere Passwörter nicht unverschlüsselt über die Leitung gehen und im schlimmsten Fall jemand diese mitlesen kann werden wir einen verschlüsselten Zugang einrichten. Hierfür werden wir SASL mittels TLS unter die Arme greifen. Mehr zur Konfiguration dann später. Dies ist insbesondere beim Zugriff über einen öffentlichen Hotspot wichtig. Die Authentifizierung wird erst eingeleitet, nachdem wir eine verschlüsselte Verbindung zu dem Mailserver aufgebaut haben. Somit ist gewährleistet, dass die Passwörter optimal geschützt übertragen werden (wenn wir den verschlüsselten Kanal anfordern!).
Hier nun die nötige Konfiguration von SASL:
smtpd_sasl_auth_enable = yes
SASL für den SMTP Daemon aktivieren.
smtpd_sasl_security_options = noanonymous
Anonymous login deaktivieren.
smtpd_sasl_local_domain =
Bei diesem Parameter darf keine Domäne angegeben werden. Sollte man hier doch eine Domäne hinterlegen wollen, so muss jeder Benutzer beim Login den kompletten Domänenamen an den Benutzer anhängen. Anstatt mailuser/passwort müsste man also mailuser@domain.org/passwort für den Login verwenden.
smtp_sasl_auth_enable = yes
Mit diesem Parameter weisen wir Postfix an SASL nicht nur für den SMTP Daemon zu aktivieren, sondern auch für den SMTP Client des Servers. Diese Option ist besonders wichtig, wenn man mit einem Smarthost arbeitet! (yes)
broken_sasl_auth_clients = yes
Diese Zeile dient als Workarround für Mailclients, die sich nicht an die RFC 2554 Vorgaben halten. In der Regel sind dies leider oft (ältere) Microsoft Produkte und somit die breite Masse der eingesetzten Mailclients.
Jetzt müssen wir noch dafür sorgen, dass der saslauth-deamon läuft. Ich gehe davon aus, dass Postfix aufgrund der Standard Installation unter Debian in einer chroot Umgebung läuft. Die Konfigurationsdateien müssen daher in einem für Postfix erreichbaren Verzeichnis abgelegt werden. Ob Postfix wirklich in einer chroot-Installation daher kommt lässt sich z.B. über die Datei master.cf verifizieren.
smtp inet n - >y< - 100 smtpd
Sollte hier > < ein "y" bzw. "-" stehen, dann wird Postfix in der chroot-Umgebung betrieben. Sollte bei der Debian Standard Installation nichts verändert worden sein sollte dies der Fall sein. Die > < Zeichen gehören nicht in die Konfigurationsdatei sondern dienen nur zur Visualisierung!
Beginnen wir nun mit der Konfiguration des saslauth-daemons: Unter /etc/postfix/ erstellen wir ein Verzeichnis "sasl“ und erstellen in diesem die Datei "smtpd.conf" Die Datei wird dann mit folgendem Inhalt gefüllt:
saslauthd_path: /var/run/saslauthd/mux
pwcheck_method: saslauthd
mech_list: plain login
Außerdem müssen wir den Benutzer „postfix“ zum Mitglied der Gruppe „sasl“ machen, damit Postfix auf sasl zurückgreifen kann. Die erledigt zum Beispiel folgender Befehl:
adduser postfix sasl
Zusätzlich müssen wir in dem Verzeichnis /var/spool/postfix/ ein Unterverzeichnis namens „saslauthd“ erstellen. Dies geschieht mittels:
mkdir -p /var/spool/postfix/var/run/saslauthd dpkg-statoverride --add root sasl 710 /var/spool/postfix/var/run/saslauthd
Wenn die Verzeichnisse angelegt sind und mittels dpkg vor Veränderungen durch Updates geschützt sind konfigurieren wir die Standardeinstellungen des Deamons unter /etc/default. Hierz müssen wir die Datei „/etc/default/saslauthd“ modifizieren:
START=yes
MECHANISMS="shadow"
OPTIONS="-m /var/spool/postfix/var/run/saslauthd"
PWDIR="/var/spool/postfix/var/run/saslauthd"
PIDFILE="/var/spool/postfix/var/run/${NAME}/saslauthd.pid"
Nachdem wir Postfix nun mit SASL-Parametern versorgt haben müssen wir noch für die Verschlüsslung sorgen. Hier bedienen wir uns dem Standard TLS:
smtpd_tls_cert_file = /etc/postfix/mail.cert
Teilt Postfix den Pfad zu dem zu verwendenden Zertifikat für die Verschlüsslung mit.
smtpd_tls_key_file = /etc/postfix/mail.key
Gibt Postfix den Pfad zu dem Private Keyfile an.
Sollten wir noch keine Zertifikate haben die wir einsetzen können müssen wir diesen natürlich zunächst noch anlegen. Die Pfade kann man nach eigenem ermessen ändern. Wichtig ist jedoch das man die Zertifikate über Berechtigungen schützt – besonders den Private Key. Dieser sollte nur vom Besitzer lesbar sein (chmod 600 mail.key).
openssl genrsa -out mail.key 2048
RSA Schlüssel mit 2048 Bit Länge erstellen.
openssl req -new -key mail.key -out mail.csr
Wir weisen openssl an, einen CSR (Certificate Signing Request) zu erstellen. Der Common Name (CN) muss auf den FQDN des Server gesetzt werden, also den vollqualifizierten Namen (mailserver.domain.org). Trägt man hier einen anderen Namen ein gibt es Probleme bei der Überprüfung des Zertifikats durch den Client (der aufgerufene Hostname passt dann nicht zu dem im Zertifikat hinterlegten Namen).
openssl x509 -req -days 3800-in mail.csr -out mail.cert -signkey mail.key
Wir weisen openssl an ein selbst signiertes Zertifikat zu erstellen, dass 3800 Tage gültig ist.
Folgende Parameter werden wieder in der main.cf gesetzt:
smtpd_use_tls = yes
Aktivieren von TLS.
smtpd_enforce_tls = no
TLS wird zwar aktiviert, die Verwendung ist aber kein zwingend notwendig. Da die meisten Server diese Option nicht nutzen werden bieten wir neben der TLS-Verbindung eine unverschlüsselten Kanal an.
smtpd_tls_auth_only = yes
Es dürfen sich nur Clients authentifizieren, die eine TLS gesicherte Verbindung zum Mailserver aufgebaut haben. Somit kann unser Server nicht als Open Relay missbraucht werden und womöglich im Auftrag fremder Personen SPAM verschicken.
Kommen wir nun zur Konfiguration von virtuellen Domains. Ich selbst benutze diese nicht mehr, will aber der „Vollständigkeit“ auf die Verwendung hinweisen. Auch für die Accounts der virtuellen Domains benötigen wir jeweils einen realen Account im Linux. Die Parameter beziehen sich wie schon die vorigen auf die main.cf.
virtual_alias_domains = subdomain.org, subdomain2.org, subdomain3.org
Hier geben wir virtuelle Domains an, bei bedarf durch Komma getrennt.
virtual_alias_maps = hash:/etc/postfix/virtual_domains
Mit der Datei virtual_domains geben wir Postfix Auskunft über das Mapping der Adressen auf die Benutzerkonten. Aufgebaut wird die Datei nach folgenden Schema:
mailuser@subdomain.org linuxuser1
spam@subdomain2.org root
Nachdem wir die Datei angelegt oder modifiziert haben müssen wir Postfix dies wieder mitteilen. Dies erledigt ein postmap /etc/postfix/virtual_domains für uns.
virtual_mailbox_limit = 10240000
Auch bei den virtuellen Accounts können wir Quotawerte setzen.
Postfix ist mit der aktuellen Konfiguration bereits einsatzfähig. Die kleinen Helferlein werden dann im nächsten Howto beschrieben. Das „Feintunig“ folgt dann im erweiterten Howto zu Postfix.