Aufbau des Mailserver

Der Begriff Mailserver ist nicht ganz eindeutig, da im Prinzip schon ein einfacher SMTP-Server (Postfix, Exim, Sendmail) ein Mailserver ist. Die Bezeichnung Mail-Transfer-Agent (MTA) ist für einen SMTP-Server zutreffender und beschreibt die Funktion schon sehr gut. Ein SMTP-Server transportiert die Mails lediglich zu einem anderem SMTP-Server oder, falls die Mail für den Mailserver selbst bestimmt ist, die Mail wird an den Mail-Delivery-Agent weitergeleitet (z.B. Dovecot), welcher die Mail dann dem entsprechendem Postfach zuweist. Der Benutzer hat dann die Möglichkeit, die Mail mit seinem Mail-User-Agent (der Client, z.B. Thunderbird oder K-9 Mail) abzurufen.

Voraussetzungen für den Mailserver

Ich gehe hier, wie in der Überschrift erwähnt, von einem vollständigen Mailserver mit MTA und MDA aus. Eingesetzt werden der VirtualMailManager, Postfix, Dovecot und PostgreSQL. Auf die PostgreSQL Datenbank greifen dann alle Anwendungen zu.

Ich setze für den Mailserver Debian 8 ein, welches glücklicherweise alle notwendigen Pakete in den Paketquellen bereitstellt. Abgesehen hiervon sind noch ein paar Dinge absolut notwendig:

• statische IP Adresse
• Hostname als A-Record im DNS, welcher auf die IP Adresse verweist
• Reverse-DNS (PTR) Eintrag (kann durch den Provider der IP Adresse vorgenommen werden; manchmal über die Weboberfläche des Providers/Hosters möglich)
• MX-Record mit dem Hostnamens des Mailserver im DNS für die Zone (Domain), welche Mails empfangen/senden soll
• Ein SSL-Zertifikat (Tipp: kostenlose Zertifikate gbit es bei Let’s Encrypt)
• Einige TCP-Ports in der Firewall öffnen (hängt von den eingesetzten Protokollen ab):
  • 25: SMTP
  • 465: SMTPS
  • 587: Submission (für SMTP-Verbindung der Clients empfohlen)
  • 110: POP3
  • 995:  POP3S
  • 143: IMAP
  • 993: IMAPS

Im Prinzip funktioniert der Mail-Transport auch mit einer dynamischen IP-Adresse und ohne Reverse-DNS Eintrag, aber kein vernünftiger Mail-Server akzeptiert E-Mails von solchen Servern. Eine Ausnahme bilden in der Regel authentifizierte Clients, sonst könnten die meisten Benutzer keine E-Mails versenden.

Installation der Software

Als Debian 8 Jessie Nutzer brauche ich im Gegensatz zu älteren Distributionen keine Pakete mehr selbst bauen, die Installation ist also einfach:

apt-get install vmm postgresql postgresql-client postfix postfix-pgsql dovecot-core dovecot-lmtpd dovecot-pgsql dovecot-pop3d dovecot-imapd dovecot-sieve

Konfiguration der Software

Ich empfehle jedem, der VMM einsetzen möchte, sich die VMM Dokumentation sehr ausführlich durchzulesen. Dort sind alle notwendigen Schritte erklärt, man muss nur ein wenig aufpassen, dass man nicht ausversehen Teile der Konfiguration für Dovecot 1.x übernimmt, da auch diese ältere Version unterstützt wird und sich in der Dokumentation wiederfindet. Ich beschreibe die Konfiguration hier bewusst nicht, da es im Prinzip auf Copy & Paste hinauslaufen würde.

Auf zwei Dinge möchte ich noch hinweisen:

Erstens verwendet VMM unter Debian standardmäßig SHA512-CRYPT, um Kennwörter abzuspeichern. Bei einigen Clients ist das leider problematisch, weswegen ich in der

/etc/vmm/vmm.cfg

password_scheme = CRAM-MD5

Generell können aber verschiedene Verfahren für die Speicherung der Kennwörter verwendet werden, diese Einstellung beeinfluss lediglich den Standard von VMM.

Zweitens bietet es sich an, automatisch ein Postmaster Postfach anzulegen, falls man hierfür keinen Alias verwenden möchte. Dies kann in der gleichen Konfigurationsdatei eingestellt werden.

auto_postmaster = true

Benutzung und Test

Wenn alles installiert und konfiguriert ist, sollte man verifizieren, dass alles wie gewünscht funktioniert. Zuerst kann man

vmm v

root@mail:~# vmm v
vmm, version 0.6.2 (from 01.02.2014)
Python 2.7.9 on Linux

Copyright (c) 2007-2014 Pascal Volk <user+vmm@localhost.localdomain.org>
vmm is free software and comes with ABSOLUTELY NO WARRANTY.

Als nächstes fügt man eine Domain und ein Postfach hinzu:

vmm da example.org
vmm ua foobar@example.org

Treten hierbei keine Fehler auf, sollte VMM korrekt mit der Datenbank kommunizieren können. Es ist außerdem sehr zu Empfehlen, postmaster@example.org als eigenständiges Postfach oder als Alias anzulegen, da dies eine reservierte Adresse ist, die auf jedem Mailserver verfügbar sein sollte. Den angelegten Nutzer kann man nun mit dem eben vergebenen Passwort in einen Mail-Client eintragen. Ab hier sollte man in einem Terminal den Befehl

tail -f /var/log/mail.log

Die DNS-Records können übrigens leicht und schnell mit

dig

# MX Record für Doamin überprüfen.
# Hierbei sollte auch gleich der A-Record aufgelöst werden
dig mx example.org
# Der A-Record kann auch manuell aufgelöst werden
dig mail.exmaple.org
# Der Reverse-DNS (PTR) Record muss dann auf mail.example.org zeigen 
dig -x 192.168.1.1

Eine Test-Mail kann auch schnell auf der Konsole versendet werden:

echo "Das ist ein Test." | mail -s Test foobar@example.org

Treten in der

mail.log

Wer nur einen Web- und Mailserver benötigt und den Aufwand gering halten möchte, der greift zu den fertigen Angeboten eines der vielen Anbieter hierfür. Ich möchte aber möglichst viel Flexibilität, Dinge selbst entscheiden und festlegen können und dabei noch etwas lernen. Primär benötige ich nur Web- Mail- und XMPP-Server, aber auch die notwendigen DNS Server möchte ich selbst betreiben.

Die Wahl der Distribution

Bisher habe ich CentOS 6 eingesetzt, welches inzwischen recht eingestaubt ist. Eine Aktualisierung auf CentOS 7 war für mich ebenfalls keine Option, da mir Debian 8 inzwischen deutlich besser gefällt, aktuellere Pakete und eine größere Paketauswahl bietet. Zumindest bin ich beim Betrieb anderer Debian Installation deutlich seltener auf Probleme gestoßen, die durch fehlende oder alte Pakete verurascht wurden. Außerdem ist Debian bei mir zu Hause aufgrund diverser Raspberry Pis inzwischen deutlich in der Überzahl, was die Administration der übrigen Server ein wenig vereinheitlichen sollte.

Domain-Registrar und DNS Server

Meine Domains habe ich inzwischen zu INWX umgezogen, da diese erstens die Verwendung eigener DNS Server ermöglichen und zweitens DNSSEC unterstützen. Den notwendigen Dnskey muss man zwar (noch) per Mail übermitteln, da dies aber nur selten notwendig ist, sehe ich darin kein Problem.

Einer der DNS Server läuft (noch) bei active-servers, der zweite bei Hetzner. Als DNS Server setze ich PowerDNS mit einer klassischen Master-Slave Konfiguration und AXFR ein. Alternativ bestünde die Möglichkeit, die DNS-Server mit einer Datenbankreplikation zu synchronisieren. Zur Verwaltung setze ich Poweradmin in Version 2.1.8 ein, welches zwar noch nicht als stable released wurde, aber bereits fehlerfrei DNSSEC unterstützt.

Mailserver

Aus gutem Grund habe ich mich nicht sofort von active-servers verabschiedet. Mein alter Mailserver lief dort und ich wusste, dass meine IP Adresse auf keiner Blacklist ist. Sollte man einen neuen Mail-Server planen oder einen bestehenden umziehen, muss erstens an die Reverse-DNS Einträge, eventuelle SPF-Records und an eine Blacklist Prüfung gedacht werden. Bei einigen Hostern kann es vorkommen, dass der „Vorbesitzer“ der IP Adresse (meist unbewusst) eine Spam-Schleuder betrieben hat.

Ich setze Dovecot und Postfix jeweils mit einem PostgreSQL Backend ein. Gestützt und Verwaltet wird das ganze durch den VirtualMailManager, auf den ich vor Jahren gestoßen bin und immer noch sehr mag. Domains, Konten, Aliase und andere Einstellungen lassen sich bequem über die Konsole verwalten. Eine grafische Oberfläche besitzt der VirtualMailManager nicht, das ist in meiem Fall aber auch nicht nötig.

Für die Überprüfung der E-Mails auf Spam und Viren setze ich, wie viele andere auch, ClamAV und Spamassassin ein. Im Unterschied zum alten Server setze ich dank der hilfreichen Beiträge von Thomas Leister hierfür nun amavis ein, was für mich eine saubere und übersichtliche Lösung ergibt.

Nachdem SPF, DKIM und DMARC wieder vollständig eingerichtet und konfiguriert sind, ist das nächste große Thema, das ich angehen möchte, die Erreicheiner einer höheren Verfügbarkeit. Einen zweiten Mailserver (sprich SMTP-Server als 2. MX) einzusetzen, ist einfach. Viel interessanter finde ich die zusätzliche Synchronisation von Dovecot (dsync) und der VMM-Datenbank (PostgreSQL Replikation), wodurch eine gewisse Ausfallsicherheit erreicht werden kann.

Webserver

Ein Server mit etwas mehr Leistung bildet bei mir den Webserver, um diesen Blog, Feedreader, ownCloud und ein paar kleinere Webanwendungen und statische Webseiten zu beherbergen. Hier setze ich ganz klassisch den Apache Server ein, da ich mit dessen Konfiguration recht vertraut bin. Als performanter Nachfolger wird ja gerne nginx empfohlen. Das ist auch für mich eine interessante Option, wenn ich einmal die Zeit zur Migration habe.

Backups

Wie ich erst kürzlich feststellen musste, darf man bei Backups wohl nur sich selbst vertrauen. Momentan habe ich Server bei active-servers und Hetzner. Bei active-servers besteht gegen Aufpreis die Möglichkeit, täglich ein VM-Backup ausführen zu lassen. Bei Hetzner besteht diese Möglichkeit nicht, es kann entweder manuell ein Snapshot erstellt werden oder Backup-Speicherplatz dazugebucht werden. Ich vermute, dass Hetzner seine Storages ein wenig besser im Griff hat als active-servers, aber um auf Nummer Sicher zu gehen, führe ich dateibasierte inkrementelle Backups mit rsnapshot auf einem Strato vServer ausreichendem Speicherplatz aus.

Monitoring

Bei dem Thema komme ich momentan etwas schleppend voran. Ich möchte distribtued Monitoring einsetzen, da ich auch meine Geräte zu hause überwachen möchte. Bisher habe ich hierfür Shinken eingesetzt, was mir einen zentralen Punkt für die Konfiguration, Mail-Versand und Einsicht in die Status der Server geboten hat. Für die Überwachung der heimischen Geräte konnte dann ein Raspberry Pi eingesetzt werden. Ähnliches schwebt mir jetzt auch vor, allerdings auf Basis von Icinga2, welches ich aufgrund des anderen Konzepts im Gegensatz zu allen anderen nagioiden Systemen sehr spannend finde.

Motivation

Warum eigentlich dieser hohe Aufwand? Natürlich würde ich auch ohne all diese Dinge überleben können und eine E-Mail Adresse bei einem entsprechendenn Anbieter würde natürlich ebenso gut funktionieren. Wenn ich eine entsprechende Internetanbindung hätte, würde ich sogar (fast) alle Dienste bei mir zu Hause betreiben, was sogar einen noch höheren Aufwand bedeuten würde. Ein Grund ist der Datenschutz. Natürlich liegen in diesem Fall die Daten quer in Deutschland verteilt, aber wenigstens gibt es hier keine Automatismen, die meine Daten algorithmisch durchsuchen, auswerten oder weitergeben. Der zweite Grund ist meine Neugier und der Wunsch, etwas dazuzulernen. Ich lerne am besten etwas, wenn ich es selbst mache.