-
Spenden über Flattr:
-
Amazon Partnerlinks:
Dieses Dokument beschreibt die Einrichtung eines Mailservers für Shared-Hosting Umgebungen auf einem System mit einer festen IP-Adresse. Das Ziel dieses Dokumentes
ist es ein System zu schaffen das über folgenden Eigenschaften verfügt:
- Empfangen und speichern von Mails für die Benutzer, auch mit SSL sowie über das Message Submission Protokoll
- Das Abrufen der Mails über IMAP und POP3 (auch SSL) für die Benutzer ermöglichen
- Einen Webmail-Dienst anbieten
- Spam Mails wenn möglich ablehnen oder zumindest markieren
- Erreichbarkeit über IPv6
Dieses Dokument schildert eine Mailserver-Konfiguration mit virtuellen Domains und einem MySQL-Backend. Die Verwaltung wird durch VBoxAdm ermöglicht. Das beschriebene Setup basiert in Teilen auf meinem älteren Exim Tutorial, dem ISP-Mail Tutorial von C. Haas sowie dem Postifx Buch von Peer Heinlein. In der Regel wird so ein Setup auf einem, oder mehreren, Rootservern betrieben.
Dieses Dokument richtet sich durchaus an Postfix Neulinge, allerdings werden einige grundlegende Erfahrungen mit Linux/UNIX vorausgesetzt. Folgende Techniken und Protokolle werden im Laufe der Einrichtung berührt werden, daher sollten Sie damit grundlegend vertraut sein:
- Eine SQL Datenbank wird für die Benutzerinformationen verwendet. Insb. MySQL.
- SMTP, für den Empfang und die Einlieferung von Mails.
- POP3 sowie IMAP für den Abruf von Mails.
- Debian GNU/Linux, Paketverwaltung, Administration, etc.
Dieses Dokument kann keine vollständige Einführung in die zugrunde liegenden Themen ersetzen. Sollten während dem Lesen fragen auftauchen empfehle ich sich in den einschlägigen Quellen zu den Hintergründen zu informieren und dann die Bearbeitung des Tutorial fortzusetzen.
Diese Konfiguration baut auf die folgenden Komponenten auf, fast alle sind als Debian Pakete in den offiziellen Repositories enthalten:
- Postfix nimmt Mails aus dem Internet via SMTP entgegen und ermöglicht es authentifizierten Benutzern Mails zu verschicken
- Dovecot, stellt die Postfächer auf dem Server über POP3 und IMAP zum Abruf bereit
- MySQL, verwaltet die Benutzerinformationen
- SpamAssassin, bewertet die ein kommenden Nachrichten nach einem Punktesystem auf den Spamgehalt.
- Postgrey, blockt viele einfach gestrickte Spam Bots
- Lighttpd oder Apache 2, für Webmail und Mailbox Webinterface
- Roundcube Webmail für Webmail und zum Verwalten von Passwörtern, Abwesenheitsbenachrichtigungen sowie Sieve Filtern.
- Verwaltung der Postfächer über einen Webbrowser mittels VBoxAdm
Auf klassischen UNIX-Systemen ist dem System genau ein Hostname (z.b. server) in eine Domäne (z.b. doe.org) zugeordnet woraus genau ein FQDN (Fully-Qualified-Domain-Name) folgt (z.b. server.domain.tld).
Die auf diesem System existierendem Benutzerkonten bilden zusammen mit dem FQDN und einem @ als Trennzeichen die öffentliche Email Adresse. Also etwas wie john@zeus.dfn.de.
Auf diesen Systemen werden die eintreffenden Nachrichten i.d.R. unter /var/mail/benutzer oder im Home des Benutzers abgespeichert. Da die Benutzer
auf einem klassischen Webhosting System aber gar keine Systemkonten haben sollen ist dieser Ansatz in diesem Fall unpraktisch. Viele Hoster bevorzugen es
die Benutzerzugänge in einer Datenbank, also so etwas wie MySQL, PostgreSQL oder auch LDAP, zu speichern. Da diese Benutzer dem System erst einmal nicht bekannt
sind muss man dem Mailserver beibringen. Ein Ansatz wäre die Benutzerkonten von Hand in eine Textdatei einzutragen. Da dies von Hand zu kompliziert und zeitaufwändig wäre,
ist es wünschenswert, dass der Mailserver quasi in Echtzeit die Benutzerdatenbank abfragen kann um dort die Benutzerkonten auszulesen.
Darüber hinaus benötigt der Mailserver noch eine Datenbank der Domains für die er zuständig ist. Es bietet sich an diese im gleichen Format wie die Benutzerdaten
abzulegen.
| Id |
Domain |
Aktiv |
|---|
| 0 |
domain.de |
yes |
| 1 |
domain.com |
no |
| 2 |
domain.net |
yes |
| 3 |
server.tld |
yes |
| n |
... |
|
Da die Datenbank in diesem Setup nur die Informationen über die Postfächer, nicht jedoch die Mails, abspeichert benötigt der Mailserver
noch Informationen über den Speicherort des Postfaches im Dateisystem. Für das speichern von Postfächern gibt es zwei verbreitete - und noch ein paar
nicht so weit verbreitete - Formate. Dies ist zum einen das klassische Mbox Format und das etwas neuere Maildir Format. Beide Formate
haben Vor- und Nachteile, ich bevorzuge hier Maildir. Unter anderem weil es besser mit meinem Backupsystem kooperiert. Ab Dovecot Version 2.0 verspricht das Dovecot eigene Format dbox die Vorteile von Mbox und Maildir zu vereinen. Aktuell (Stand: Ende 2010) ist Dovecot 2.0 allerdings noch in der Beta-Phase.
Ich verwende
ein inkrementelles Backup das auf rsync aufbaut. Da beim Mbox Format alle Nachrichten eines Postfaches in einer Datei gespeichert werden,
würde das bedeuten, dass bei geringfügigen Änderungen die komplette Mailbox erneut gesichert würde. Maildir spart mir hier einfach
Speicherplatz.
Die Speicherung der Postfächer erfolgt in meinem Setup unter dem Pfad /srv/vmail/domain.tld/benutzer. Die Struktur des Pfades wird dem MTA (Exim oder Postfix) und dem Mailserver (Dovecot oder Courier)
fest in der Konfiguration vorgegeben und die variablen Teile, also Domain und Benutzer, werden dann zur Laufzeit anhand der Informationen aus der Datenbank
ergänzt.
Ein Speicherung der Daten in einer SQL-Datenbank ermöglicht eine einfache Verwaltung der Daten über ein Webfrontend das so ohne erweiterte Berechtigungen auskommt.
MySQL wurde nur gewählt weil sich darauf von allen relevanten Programmen problemlos zugreifen lässt. Eine Nutzung von PostgreSQL oder einer anderen SQL-Datenbank
wäre mit Sicherheit auch möglich. Die Umsetzung bleibt dem geneigten Leser überlassen.
Zum Thema Greylisting gibt es viele Gegensätzliche Meinungen. Die einen preisen es als Wundermittel gegen Spam die anderen stellen seine Wirksamkeit in Frage und einige Nutzer
können nicht mit den dadurch entstehenden Verzögerungen leben. Fakt ist, dass die Spam-Belastung meiner Systeme nach dem aktivieren von Greylisting um über 90% zurückgegangen ist. Inzwischen ist
zwar zu beobachten, dass wieder mehr Spam durch das Greylisting durchkommt, aber solange ich noch einen positiven Effekt feststellen kann werde ich Greylisting weiterhin einsetzen. Wen die Nachteile von Greylisting - verzögerte Zustellung und zusätzlicher Ressourcenbedarf - stören, der kann das dargestellte Setup ohne Probleme auch ohne Greylisting umsetzen.
Für das Ablegen der Benutzerdaten und Domains gibt es vier relevante Datenbank Schemata. Zwei davon werden zum speichern der zuständigen Domains verwendet, eines für die
Informationen über die Postfächer und eines für die Weiterleitungen. Was die Datenbankschema angeht ist man im Grund sehr flexibel. Es wäre durchaus auch möglich ein komibiniertes Schemata
für Postfächer und Weiterleitungen zu verwenden und die Domains in einer Datenbank zu speichern.
mailboxes:
| Feld |
Typ |
Beschreibung |
|---|
| id |
int(16) |
Primärschlüssel, auto_increment |
| domain_id |
int(16) |
Der Domainteil der Adresse, verweist auf die Tabelle Domains |
| local_part |
varchar(255) |
Der Benutzerteil der Adresse |
| password |
varchar(255) |
Das Passwort im Klartext |
| name |
varchar(255) |
Ein Benutzerdefinierter Name |
| is_active |
tinyint(1) |
Account aktiv? |
| max_msg_size |
int(16) |
Größenbeschränkung pro Mailbox |
| is_on_vacation |
tinyint(1) |
Auto-Responder aktiv? |
| vacation_subj |
varchar(255) |
Betreff für den Auto-Responder |
| vacation_msg |
text |
Text für den Auto-Responder |
| quota |
int(16) |
Quote für das Postfach |
| is_domainadmin |
tinyint(1) |
Domainadministrator |
| is_superadmin |
tinyint(1) |
Site-Administrator |
| sa_active |
tinyint(1) |
SpamAssassin Aktiv |
| sa_kill_score |
decimal(5,2) |
Maximaler SA Score |
aliases:
| Feld |
Typ |
Beschreibung |
|---|
| id |
int(16) |
Primärschlüssel, auto_increment |
| domain_id |
int(16) |
Der Domainteil der Adresse, verweist auf die Tabelle Domains |
| local_part |
varchar(255) |
Der Benutzerteil der Adresse |
| goto |
varchar(255) |
Das Weiterleitungsziel |
| is_active |
tinyint(1) |
Account aktiv? |
domains:
| Feld |
Typ |
Beschreibung |
|---|
| id |
int(16) |
Primärschlüssel, auto_increment |
| name |
varchar(255) |
Domainname (FQDN) |
| is_active |
tinyint(1) |
Aktiv? |
domain_aliases:
| Feld |
Typ |
Beschreibung |
|---|
| id |
int(16) |
Primärschlüssel, auto_increment |
| name |
varchar(255) |
Domainname (FQDN) |
| domain_id |
int(16) |
Ziel-Domain |
| is_active |
tinyint(1) |
Aktiv? |
Vor der Einrichtung der benötigten Pakete sollten Sie zunächst sicherstellen, dass ihr System über einen korrekten Hostnamen verfügt. Dies lässt sich in den
Dateien /etc/hostname und /etc/hosts festlegen. Wenn das Kommando hostname --fqdn den korrekten, voll-qualifizierten, Hostname ausgibt, dann ist diese Einstellung in Ordnung.
Falsch wäre folgender Eintrag:
192.168.0.1 hostname hostname.domain.tld
Der korrekte Eintrag:
192.168.0.1 hostname.domain.tld hostname
Legen Sie zunächst das Verzeichnis /srv/vmail an und vergeben Sie korrekte Zugriffsrechte:
mkdir -p /srv/vmail
adduser --system --home /srv/vmail --no-create-home --group --disabled-password vmail
chown -R vmail:vmail /srv/vmail
chmod 700 /srv/vmail
Der einfachste Weg VBoxAdm unter Debian zu installieren ist das Paket aus dem VBoxAdm Repository.
Dazu muss einen neuen Paketquelle in die Datei sources.list von Apt eingetragen werden und der
öffentliche Schlüssel importiert werden.
$> echo "deb http://packages.gauner.org/ squeeze main contrib non-free" >> /etc/apt/sources.list
$> gpg --keyserver x-hkp://gpg-keyserver.de --search-key D31FA054C85AEFAC
$> gpg --export D31FA054C85AEFAC | apt-key add -
Das Repository enthällt auch ein Backport von libcrypt-generatepassword-perl für Debian lenny.
Die meisten der benötigten Pakete lassen sich einfach über Debians Paketverwaltung nachinstallieren. Manuell müssen nur der Webmailer und die Verwaltungsoberfläche nachinstalliert werden. Da diese beiden Pakete in PHP5 geschrieben sind werden hierfür noch ein Webserver - am besten Lighttpd - sowie eine PHP5 Installation benötigt. Wichtig zu erwähnen ist in diesem Zusammenhang, dass der Webserver nicht unbedingt auf dem Mailserver System laufen muss. Es ist also möglich ein System auf zu setzen, das lediglich als Mailserver fungiert.
Zunächst wird nun Postfix installiert:
$> aptitude install postfix postfix-pcre postfix-mysql
Wenn der Mailserver auch POP3 und IMAP anbieten soll benötigen wir noch Dovecot mit POP3 und IMAP Support.
$> aptitude install dovecot-imapd dovecot-pop3d
Es ist auch möglich nur eines der beiden Protokolle zu unterstützen. Wenn Sie z.B. nicht genug Ressourcen für einen IMAP-Server haben, dann lassen Sie dovecot-imapd einfach weg. Im folgenden gehe ich davon aus, dass Sie beiden Protokolle unterstützen wollen.
Wenn Sie den Datenbankserver auf dem gleichen System laufen lassen wollen installieren Sie noch das entsprechende Paket:
$> aptitude install mysql-server-5.1
Nach meiner Erfahrung spricht nichts dagegen. Wenn Sie allerdings schon über einen leistungsfähigen Datenbankserver in Ihrem Netzwerk verfügen kann es Sinn machen stattdessen diesen zu verwenden. Dann entfällt die Installation dieses Paketes natürlich.
Wenn Sie SpamAssassin einsetzten möchten um die hereinkommenden Mails zu klassifizieren, installieren Sie noch die folgenden Pakete nach:
$> aptitude install pyzor razor spamassassin dcc-client
Hier sind die Pakete pyzor, razor und dcc-client optional, jedoch können dadurch die Erkennungsleistungen erheblich verbessert werden.
Wenn Sie Greylisting verwenden möchten benötigen Sie noch das Postgrey Paket:
$> aptitude install postgrey
Anschließend muss der Postgrey Port in der Datei /etc/default/postgrey noch auf 60000 geändert werden.
Wenn Sie die PHP basierten Pakete installieren möchten, sollten Sie nun den Lighttpd Webserver und PHP5 installieren.
$> aptitude install lighttpd php5-cgi php5-mcrypt php5-mysql phpmyadmin
PhpMyAdmin ist komplett optional, kann die Einrichtung und Verwaltung der Datenbank aber deutlich erleichtern. Alternativ zu Lighttpd kann natürlich auch der Apache Webserver verwendet werden.
Für die Absicherung der Verbindungen des Mailserver wird noch das OpenSSL Paket benötigt um die entsprechenden Zertifikate zu erzeugen:
$> aptitude install openssl
Nun wird noch die Verwaltungsoberfläche VBoxAdm installiert. Die enthaltenen Skripte und Datenbank Schema werden im folgenden benötigt um dem Setup-Vorschlag zu folgen.
$> aptitude install vboxadm
Das Paket vboxadm zieht über die Paketabhängigkeiten die Pakete vboxadm-cgi (Weboberfläche), vboxadm-common (Gemeinsam genutzte Bibliotheken und Skripte) sowie vboxadm-sa (Anti-Spam Proxy) und vboxadm-ma (Mailarchive) nach.
Bei der Installation frage ein Debconf Skript den zu konfigurierenden Webserver ab. Wählen Sie hier lighttpd aus.
Jedem der beteiligten Programme, das Zugriff auf die Datenbank benötigt, müssen die entsprechenden Verbindungsinformationen mitgeteilt werden. Zunächst müssen jedoch die Datenbank und die Benutzer angelegt werden.
Jetzt müssen zunächst die Datenbank und ein entsprechender Benutzer erstellt werden. Dies geht sehr einfach über PhpMyAdmin oder alternativ per Hand.
$> mysql -uroot -p
Sie werden jetzt nach dem während der Mysql Installation erstellten root Passwort gefragt. In der MySQL Konsole legen Sie nun bitte die Datenbank an.
mysql> CREATE DATABASE vboxadm;
mysql> CREATE DATABASE roundcube;
Zunächst wird Postfix mit den Datenbankinformationen ausgestattet. Dazu muss jeder der Datenbank Mappings unter /etc/postfix/maps bearbeitet werden. Die Informationen stehen gleich zu Beginn der Dateien.
user = postfix
password = DBPASS
hosts = localhost
dbname = vbxoadm
Die Query Zeile sollte unverändert bleiben.
Danach muss auch Dovecot wissen wie er sich zur Datenbank verbinden kann. Diese Informationen werden in der dovecot-sql.conf eingetragen.
driver = mysql
connect = host=localhost dbname=DBNAME user=DBUSER password=DBPASS
Nachdem die Datenbank angelegt ist, müssen nun die Datenbanktabellen erstellt werden. Dazu reicht es aus einfach die gegebenen Schemata zu importieren. Entweder die Datei doc/mysql/schema.sql (aus der Quelldistribution, unter Debian zu finden als /usr/share/doc/vboxadm-common/examples/mysql/schema.sql) importieren, oder die Tabellen über den MySQL Client von Hand anlegen.
Wie bereits weiter oben beschrieben, enthält die Tabelle mailboxes alle Informationen über die Postfächer:
CREATE TABLE IF NOT EXISTS `mailboxes` (
`id` int(16) NOT NULL AUTO_INCREMENT,
`domain_id` int(16) NOT NULL,
`local_part` varchar(255) NOT NULL,
`password` varchar(255) NOT NULL,
`name` varchar(255) NOT NULL,
`is_active` tinyint(1) NOT NULL,
`max_msg_size` int(16) NOT NULL,
`is_on_vacation` tinyint(1) NOT NULL,
`vacation_subj` varchar(255) NOT NULL,
`vacation_msg` text NOT NULL,
`quota` int(16) NOT NULL,
`is_domainadmin` tinyint(1) NOT NULL,
`is_superadmin` tinyint(1) NOT NULL,
`sa_active` tinyint(1) NOT NULL,
`sa_kill_score` decimal(5,2) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `domain_id` (`domain_id`,`local_part`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Die Tabelle aliases enthält die Weiterleitungen:
CREATE TABLE IF NOT EXISTS `aliases` (
`id` int(16) NOT NULL AUTO_INCREMENT,
`domain_id` int(16) NOT NULL,
`local_part` varchar(255) NOT NULL,
`goto` varchar(255) NOT NULL,
`is_active` tinyint(1) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `domain_id` (`domain_id`,`local_part`),
KEY `active` (`is_active`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ALTER TABLE `aliases`
ADD CONSTRAINT `aliases_ibfk_1` FOREIGN KEY (`domain_id`) REFERENCES `domains` (`id`) ON DELETE CASCADE ON UPDATE CASCADE;
Die Tabellen für die Domains sind fast identisch. Die Tabelle domains enthält die Domains, die Tabelle domain_aliases die Domain Aliase:
CREATE TABLE IF NOT EXISTS `domains` (
`id` int(16) NOT NULL AUTO_INCREMENT,
`name` varchar(255) NOT NULL,
`is_active` tinyint(1) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `name` (`name`),
KEY `active` (`is_active`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ALTER TABLE `mailboxes`
ADD CONSTRAINT `mailboxes_ibfk_1` FOREIGN KEY (`domain_id`) REFERENCES `domains` (`id`) ON DELETE CASCADE ON UPDATE CASCADE;
CREATE TABLE IF NOT EXISTS `domain_aliases` (
`id` int(16) NOT NULL AUTO_INCREMENT,
`name` varchar(255) NOT NULL,
`domain_id` int(16) NOT NULL,
`is_active` tinyint(1) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `name` (`name`),
KEY `active` (`is_active`),
KEY `domain_id` (`domain_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ALTER TABLE `domain_aliases`
ADD CONSTRAINT `domain_aliases_ibfk_1` FOREIGN KEY (`domain_id`) REFERENCES `domains` (`id`) ON DELETE CASCADE ON UPDATE CASCADE;
Zum Schluss brauchen wir noch zwei Hilfstabellen. Eine für das Aktions-Log der Weboberfläche und eine für den Autoresponder.
CREATE TABLE IF NOT EXISTS `log` (
`ts` datetime NOT NULL,
`msg` text NOT NULL
) ENGINE=ARCHIVE DEFAULT CHARSET=utf8;
CREATE TABLE IF NOT EXISTS `vacation_notify` (
`on_vacation` varchar(255) NOT NULL,
`notified` varchar(255) NOT NULL,
`notified_at` datetime NOT NULL,
PRIMARY KEY (`on_vacation`,`notified`),
KEY `notified_at` (`notified_at`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Die Foreign Key Constraints sorgen dafür, dass die Datenbank immer in einem konsistenten Zustand ist. Wird z.B. eine Domain gelöscht so sorgt die Datenbank dafür, dass auch alle abhängigen Postfächer entfernt werden. Daher Vorsicht beim löschen von Einträgen aus den übergeordneten Tabellen.
Nun müssen noch die Benutzer angelegt werden, bitte erzeugen Sie die Passwörter mit z.B. pwgen 12.:
mysql> GRANT ALL ON vboxadm.* TO 'vboxadm'@'localhost' IDENTIFIED BY '<PASSWORD>';
mysql> GRANT SELECT ON vboxadm.* TO 'postfix'@'localhost' IDENTIFIED BY '<PASSWORD>';
mysql> GRANT SELECT ON vboxadm.mailboxes TO 'dovecot'@'localhost' IDENTIFIED BY '<PASSWORD>';
mysql> GRANT SELECT ON vboxadm.domains TO 'dovecot'@'localhost' IDENTIFIED BY '<PASSWORD>';
mysql> GRANT ALL ON roundcube.* TO 'roundcube'@'localhost' IDENTIFIED BY '<PASSWORD>';
mysql> GRANT SELECT,UPDATE ON vboxadm.mailboxes TO 'vboxadm_user'@'localhost' IDENTIFIED BY '<PASSWORD>';
mysql> GRANT SELECT ON vboxadm.domains TO 'vboxadm_user'@'localhost' IDENTIFIED BY '<PASSWORD>';
mysql> FLUSH PRIVILEGES;
Die Datenbankabfragen für Postfix werden in den einzelnen Map Dateien definiert damit sie sich leicht ändern lassen und die restliche Konfigurationsdatei nicht unnötig aufgebläht wird. Ich werde hier kurz auf die einzelnen Abfragen eingehen. Natürlich können die SQL Abfragen beliebig angepasst werden wenn ein anderes Datenbankschema zugrunde gelegt wird. Lediglich die Rückgabewerte müssen unverändert erhalten bleiben.
Die hier vorgestellten Maps-Dateien können aus dem Verzeichnis /usr/share/doc/vboxadm-common/examples/postfix/maps nach /etc/postfix/maps/ kopiert werden. Alternativ kann das Verzeichnis von Hand angelegt und die Abfragen in die entsprechenden Dateien eingetragen werden.
Die Abfrage in der Datei virtual_alias_domain_mailbox_maps.cf stellt fest ob der Benutzer als Alias einer Domain existiert.:
SELECT CONCAT(d.name, '/', m.local_part) AS maildir FROM domains AS d LEFT JOIN mailboxes AS m ON m.domain_id = d.id LEFT JOIN domain_aliases AS da ON da.domain_id = d.id WHERE da.name = '%d' AND m.local_part = '%u' AND d.is_active AND m.is_active
Die Abfrage in der Datei virtual_alias_domain_maps stellt fest ob der Empfänger ein Alias unter einer Alias-Domain ist.:
SELECT goto FROM aliases AS a LEFT JOIN domains AS d ON a.domain_id = d.id LEFT JOIN domain_aliases AS da ON da.domain_id = d.id WHERE da.name = '%d' AND a.local_part = '%u' AND a.is_active AND d.is_active AND da.is_active
Die Abfrage in der Datei virtual_alias_maps.cf stellt fest ob der Empfänger ein normaler Alias ist.:
SELECT goto FROM aliases AS a LEFT JOIN domains AS d ON a.domain_id = d.id WHERE d.name = '%d' AND a.local_part = '%u' AND a.is_active AND d.is_active
Die Abfrage in der Datei virtual_domain_alias_maps.cf stellt fest ob die Zieldomain eine Alias-Domain ist.:
SELECT name FROM domain_aliases WHERE name = '%s' AND is_active
Die Abfrage in der Datei virtual_domain_maps.cf stellt einfach fest ob die Zieldomain eine normale, virtuelle Domain ist.:
SELECT name FROM domains WHERE name = '%s' AND is_active
Die wohl am häufigsten aufgerufene Abfrage stellt fest ob es sich bei einer gegebenen Adresse um ein lokales Postfach handelt. Diese Abfrage wird bei jeder ankommenden Nachricht abgesetzt. Diese Abfrage gehört in die Datei virutal_mailbox_maps.cf.:
SELECT CONCAT(d.name, '/', m.local_part) AS maildir FROM domains AS d LEFT JOIN mailboxes AS m ON m.domain_id = d.id WHERE d.name = '%d' AND m.local_part = '%u' AND d.is_active AND m.is_active
Die letzte Abfrage in der Datei virtual_vacation_alias_maps.cf etabliert die Autoresponder Funktionalität. Ist ein Benutzer als abwesend markiert wird hierüber dynamisch eine Weiterleitung erzeugt die die Nachricht dem Autoresponder zustellt.:
SELECT CONCAT(ma.local_part,'@',d.name,',',ma.local_part,'#',d.name,'@autoreply.domain.tld') AS goto FROM mailboxes AS ma LEFT JOIN domains AS d ON ma.domain_id = d.id WHERE is_on_vacation AND d.name = '%d' AND ma.local_part = '%u'
Der interessante Punkt bei dieser Abfrage ist, dass die Rückgabe dem Format user@domain.tld,user#domain.tld@autoreply.domain.tld entspricht, d.h. eine Weiterleitung an zwei Adressen: Die eigentliche Mailbox und den Autoresponder. Ohne die Mailbox vor dem Komma zu wiederholen würde die Nachricht nur dem Autoresponder zugestellt werden und nicht in die Mailbox kopiert.
Damit ist die definition der MySQL-Abfragen für Postfix abgeschlossen. Weiter unten wird der konkrete Einsatz der einzelnen Abfragen besprochen. Hier folgen nun noch die zwei relevanten Abfragen für die POP3- und IMAP-Server Dovecot. Er benötigt zum einen die Möglichkeit das Passwort des Benutzers abzufragen und zum anderen eine Möglichkeit den Aufbewahrungsort der Maildirs zur ermitteln. Da für Dovecot eine statische Userdb verwendet wird, siehe unten, wird nur die Passwort Abfrage benötgit. Die Abfrage liefert ein Ergebnis der folgenden Form zurück.
password_query = SELECT CONCAT(m.local_part, '@', d.name) AS user, m.password AS password FROM mailboxes AS m LEFT JOIN domains AS d ON m.domain_id = d.id WHERE m.local_part = '%n' AND d.name = '%d' AND m.is_active AND d.is_active
Um die Übertragung zwischen dem Mailserver und den Benutzern auf der einen Seite sowie anderen Mailservern auf der anderen Seite abzusichern ist es sinnvoll verschlüsselte Verbindungen mittels Secure-Socket-Layer, kurz SSL, zu verwenden. Die notwendigen Funktionalität bringen die verwendeten Programme schon mit, nur die entsprechenden Schlüssel und Zertifikate müssen noch erstellt werden. Für Details zum Thema PKI sei auf Wikipedia und RFC3280 verwiesen.
Für die Erzeugung der benötigten Schlüsselpaare wird openssl benötigt. Dies sollten Sie im Schritt Installation der benötigten Pakete bereits installiert haben.
Zunächst wird ein privater Schüssel unter dem Namen private.key angelegt. Hier können Sie natürlich auch einen anderen Namen wählen. Als Schlüssellänge empfiehlt sich 1024 oder 2048.:
openssl genrsa -out private.key 2048
Danach kann daraus der Certificate Signing Request (CSR) erzeugt werden:
openssl req -new -key private.key -out server.domain.csr
Hierbei wird OpenSSL die X.509 Informationen zu Ihrer Person abfragen.
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]:Hesse
Locality Name (eg, city) []:Frankfurt
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Internet Widgits Pty Ltd
Organizational Unit Name (eg, section) []:CA
Common Name (eg, YOUR name) []:server.domain.tld
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Diese Angaben müssen - je nach Policy Ihrer CA - der Wahrheit entsprechen und ggf. eindeutig nachprüfbar sein. Wichtig ist hier insbesondere der Punkt Common Name. Hier müssen Sie den Hostname (FQDN) Ihres Mailserver eintragen. Wichtig ist auch, dass dieser Hostname sowohl über DNS als auch über Reverse DNS auflösbar ist. Auf die Angabe eines Passwortes sollte man hier verzichten. Dies ist zwar ein möglicher Angriffsweg, aber wenn Sie hier ein Passwort angeben müssen Sie dieses entweder in die Konfigurationsdateien eintragen, was auch keine zusätzliche Sicherheit bietet, oder es bei jedem Neustart der Dienste von Hand eingeben. Es ist Ihre Entscheidung.
Dieser CSR kann jetzt dazu verwendet werden um ein richtiges Zertifikat bei einer Certification Authority (CA) zu bestellen. Je nach Einsatzzweck des Servers können Sie entweder ein selbstsigniertes Zertifikat, ein kostenloses Zertifikat von CACert oder StartSSL oder ein kostenpflichtiges Zertifikat von VeriSign, Thawte, etc. erstehen.
Wenn Sie ein selbstsigniertes Zertifikat verwenden wollen, können Sie sich an folgendem Tutorial orientieren.
Nachdem Sie das Zertifikat erhalten haben legen Sie es unter /etc/ssl/certs/server.domain.tld ab. Den dazugehörigen privaten Schlüssel speichern Sie unter /etc/ssl/private/server.key. Notieren Sie sich diese Pfade, sie werden später benötigt.
Eventuell ist es notwendig, dass Sie die Zugriffsrechte für /etc/ssl/private/ anpassen. Entweder erlauben Sie mit:
chmod o+x /etc/ssl/private
beliebigen Benutzern in dieses Verzeichnis zu wechseln oder Sie speichern den private Key im Postfix Konfigurationsverzeichnis unter /etc/postfix.
Als Basis für Ihre Postfix Konfiguration verwenden Sie am besten das bereitgestellte Template. Alle Stellen die von Ihnen geändert werden müssen sind mit einem CHANGEME markiert. Hier folgt eine Schritt-für-Schritt Besprechung der relevanten Optionen. Zunächst die main.cf, danach die master.cf Datei.
In der Datei main.cf werden alle wichtigen Konfigurationsoptionen von Postfix definiert.
Zunächst müssen Sie sichergehen, dass der Hostname korrekt gesetzt ist. In der Datei /etc/mailname sollte der korrekte Hostname (FQDN) des Mailservers stehen. Dieser Name sollte konsistent per DNS und Reverse-DNS auflösbar sein. D.h. eine DNS Abfrage auf den primary Hostname sollte die IP-Adresse ergeben unter der der Mailserver arbeitet und eine Reverse-DNS Abfrage auf diese IP-Adresse wieder den FQDN.:
$> dig +short hostname.domain.tld
$> dig +short -x <Mailserver-IP>
In der Variable mydestination definieren wir alle Domains für die Postifx lokal zuständig ist, d.h. alle Domains deren Postfächer von der aktuellen Postfix Instanz zugestellt werden. Diesem Feld kommt in der hier vorgestellten Konfiguration nur eine untergeordnete Bedeutung zu, da die meisten Domains über die MySQL Tabellen verwaltet werden. Dafür ist die Variable virtual_mailbox_domains zuständig. Dort definieren Sie den Typ der Map und die Map selbst:
virtual_mailbox_domains =
proxy:mysql:/etc/postfix/maps/virtual_domain_maps.cf,
proxy:mysql:/etc/postfix/maps/virtual_domain_alias_maps.cf
Mit der Option inet_interfaces wird festgelegt auf welchen Netzwerkschnittstellen der Mailserver verfügbar sein soll. Die einfachste Lösung ist hier einfach all anzugeben, damit Postfix auf allen lokalen Schnittstellen lauscht.:
inet_interfaces = all
Wenn Sie ein funktionierendes IPv6 Setup inkl. Reverse-DNS haben, dann können Sie die Option inet_protocols ebenfalls auf all setzen, sonst auf ipv4.:
inet_protocols = all
Über die Option mynetworks werden vertrauenswürdige Netze für den Versand freigeschaltet (siehe auch restriction permit_mynetworks). Dort sollte auf jeden Fall der lokale Host und ggf. das lokale Subnetz eingetragen werden.
Die Virtuellen Mailboxen werden über die Optionsfamiliy virtual_* konfiguriert. Damit das vorgeschlagene Setup wie beschrieben funktioniert müssen die Benuter und Gruppen IDs angepasst werden. virtual_minimum_uid wird auf die User-ID des System-Benutzers vmail gesetzt. virtual_uid_maps auf static:UID(vmail), wobei UID(vmail) ebenfalls durch die Benutzer ID des Benutzers vmail ersetzt werden muss. Analog dazu wird virtual_gid_maps auf static:GID(vmail) gesetzt, wobei GID(vmail) die Gruppen-ID von vmail bezeichnet.
Damit Postfix die oben konfigurierten MySQL-Maps für die virtuellen Domains verwendet, werden die Direktiven virtual_mailbox_domains, virtual_mailbox_maps sowie virtual_alias_maps wie hier gezeigt konfiguriert:
virtual_mailbox_domains =
proxy:mysql:/etc/postfix/maps/virtual_domain_maps.cf,
proxy:mysql:/etc/postfix/maps/virtual_domain_alias_maps.cf
virtual_mailbox_maps =
proxy:mysql:/etc/postfix/maps/virtual_mailbox_maps.cf,
proxy:mysql:/etc/postfix/maps/virtual_alias_domain_mailbox_maps.cf
virtual_alias_maps =
proxy:mysql:/etc/postfix/maps/virtual_alias_maps.cf,
proxy:mysql:/etc/postfix/maps/virtual_alias_domain_maps.cf,
proxy:mysql:/etc/postfix/maps/virtual_vacation_alias_maps.cf
Über virtual_transport = dovecot wird Postfix mitgeteilt, dass der in der master.cf konfigurierte Transport mit dem Namen dovecot für die Zustellung der virtuellen Mailboxen verwendet wird. Damit der Dovecot LDA funktioniert darf er immer nur eine Mail auf einmal von Postfix bekommen, daher wird dovecot_destination_recipient_limit auf den Wert 1 gesetzt.
Damit authentifizierte Benutzer über unseren Server Mails verschicken können verwenden wir die permit_sasl_authenticated in den smtpd_recipient_restrictions zusammen mit smtpd_sasl_auth_type = dovecot und smtpd_sasl_path = private/auth. Damit authenifiziert Postfix mittels SASL gegen Dovecot.
Der wohl wichtigste Abschnitt in der main.cf sind die smtpd_recipient_restrictions die detailiert festlegen von wem Postfix welche Art von Mails über seine SMTP Ports entgegen nimmt. Die Restrictions hier zunächst in voller Länge und weiter unten folgt dann die Erklärung Stück für Stück.
smtpd_recipient_restrictions =
# Allow Postmaster, Abuse and other imporant role accounts
check_recipient_access btree:/etc/postfix/maps/access_recipient-rfc,
# White- and Blacklisting
check_client_access btree:/etc/postfix/maps/access_client,
check_helo_access btree:/etc/postfix/maps/access_helo,
check_sender_access btree:/etc/postfix/maps/access_sender,
check_recipient_access btree:/etc/postfix/maps/access_recipient,
# Allow no malformed mails
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
# Allow our authed. users
permit_sasl_authenticated,
permit_mynetworks,
# These rejects may have to be disalbed, watch your logs
reject_invalid_helo_hostname,
reject_unknown_helo_hostname,
reject_non_fqdn_helo_hostname,
reject_unknown_client_hostname,
reject_unknown_reverse_client_hostname,
# check RBLs
reject_rbl_client ix.dnsbl.manitu.net,
reject_rbl_client zen.spamhaus.org,
# reject_rbl_client bl.spamcop.net,
# reject_rbl_client dnsbl.njabl.org,
# reject_rbl_client list.dsbl.org,
# reject_rhsbl_client blackhole.securitysage.com,
# reject_rhsbl_sender dsn.rfc-ignorant.org
# Greylisting
check_policy_service inet:127.0.0.1:60000,
# Backup-MX: test existing relay recipients dynamically
# reject_unverified_recipient,
# Backup-MX: allow
# permit_mx_backup,
# No other relaying
reject_unauth_destination,
# Policyd-Weight
check_policy_service inet:127.0.0.1:12525,
# allow the rest
permit
Zunächst stellen wir sicher, dass sog. Role-Accounts wie sie in diversen RFC definiert sind immer angenommen werden. Das Mißachten dieser Regel kann dazu führen, dass der Mailserver auf diversen Blacklisten landet, wichtige Benachrichtigungen nicht mehr zugestellt werden können und der Versand insgesamt deutlich negativ beeinträchtigt wird. Dies erledigt die erste check_recipient_access Zeile.
Die nächsten vier check_*_access Regeln verweisen im Moment auf leere Dateien. Diese existieren, damit Sie ggf. schnell und unkompliziert Mails anhand dieser Regeln zulassen ober blocken können.
Um unnötige Bounces zu vermeiden und es Spam Versendern nicht zu leicht zu machen weisen wir mit den nächsten vier Regeln Postfix an die Header der Mails auf grundlegende Syntax Regeln zu überprüfen.
Bis hier hin müssen alle Mails die Regeln durchlaufen, aber jetzt lassen wir die ersten Mails zu: Mittels permit_sasl_authenticated Benutzer die sich mit ihren Zugangsdaten authentifiziert haben sowie die Hosts aus mynetworks. Für diese ist die Abarbeitung der Regeln damit zu Ende und die Mail wird angenommen. Für alle anderen Mails geht die Verarbeitung weiter.
Alle anderen Mails, d.h. jene von nicht vertrauenswürdigen Hosts, werden weiteren Head-Checks unterworfen und der einliefernde Host anhand von Realtime Blocklists (RBL, reject_rbl_client) geprüft. Ist ein Mailserver in einer aktiven RBLs gelistet werden dessen Mails direkt abgelehnt.
Danach kommen die teuren Tests. Greylisting, zwar umstritten aber auf meinen Systemen bewährt, filtert immer noch einen großen Teil Spam heraus. Danach werden Relays, d.h. Mails für die unser Mailserver nicht zuständig ist, herausgefiltert und dann noch Policyd-Weight per check_policy_service eingebunden. Policyd-Weight kombiniert, ähnlich SpamAssassin, verschiedene Kriterien und blockt eine Mail gegebenenfalls.
Alles was bis dahin nicht gefiltert wurde wird mittels permit angenommen.
In der Datei master.cf werden die Prozesse definiert die von Postfix überwacht und benutzt werden.
Der Standardport für SMTP ist 25, daher muss der Mailserver hier auf jeden Fall lauschen wenn er von anderen Systemen Nachrichten empfangen will. Port 587 ist ein neuerer Port, definiert vom Message Submission Protokoll das eine Unterscheidung zwischen dem Nachrichtenaustausch zwischen Mailservern und einliefernden Clients bieten will. Auf Port 587 sollen die Clients nur authentifizierte Übertragungen von Clients über SMTP annehmen.:
smtp inet n - - - - smtpd
-o smtpd_proxy_filter=localhost:10024
submission inet n - - - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
-o smtpd_proxy_filter=localhost:10024
smtps inet n - - - - smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
-o smtpd_proxy_filter=localhost:10024
Wichtig ist hier insbesondere die Angabe des smtpd_proxy_filter. Dieser sorgt, im Gegensatz zu content-filter in der main.cf, dafür, dass Postfix Pre-Queue filtert, d.h. bevor ein Absender ein 250 OK als Antwort auf sein DATA Kommando erhällt. Als Filter setzen wir hier den VBoxAdm SMTP-Proxy ein, dazu unten mehr.
In diesem Zusammenhang ist noch zu beachten, dass der Proxy Filter eine Möglichkeit hat die gefilterten Mails wieder an unseren Postfix abzuliefern ohne, dass die Mails erneut gefiltert werden. Dazu dienen die Zeilen ab:
127.0.0.1:10025 inet n - - - - smtpd
-o content_filter=
[...]
Zwei weitere Anpassungen an der master.cf sind interessant. Der dovecot Transport sowie der vacation Transport.:
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${user}@${domain}
vacation unix - n n - - pipe
flags=Rq user=vboxadm:vboxadm argv=/usr/lib/vboxadm/vacation -s ${sender} -r ${recipient}
Den Dovecot Transport haben wir in der main.cf als virtual_transport benutzt, hier wird er definiert. Der Vacation Transport wird für den Autoresponder benötigt.
Postfix ist in der Lage die Nachrichten für die lokalen Benutzer direkt zuzustellen, da er das Maildir Format unterstüzt. Er fungiert also per Voreinstellung sowohl als MTA (Mail-Transfer-Agent) als auch als LDA (Local Delivery Agent). Dovecot bringt jedoch einen eigenen LDA mit, der einige Vorteile gegenüber der eingebauten Funktionalität von Postfix bietet. Der wichtigste Unterschied ist wohl die Unterstützung der Sieve Filtersprache, die eine Server-seitige Filterung der Nachrichten ermöglicht. Insbesondere Ihre IMAP-Nutzer werden diese Funktionalität zu schätzen wissen.
Den Postfix Teil dazu haben wir bereits im letzten Abschnitt konfiguriert, die Konfiguration für Dovecot ist unten zu sehen. Die postmaster_address sollten Sie natürlich anpassen.
protocol lda {
postmaster_address = postmaster@domain.tld
mail_plugins = quota
auth_socket_path = /var/run/dovecot/auth-master
mail_plugins = sieve
log_path = /srv/vmail/dovecot-deliver.log
}
Nachdem Sie den Mailserver konfiguriert haben, sollten Sie nun testen ob er auch funktioniert. Dazu kann man händisch mit Hilfe von Telnet eine SMTP Sitzung simulieren.
$> telnet localhost 25
Darauf hin sollte sich der Server bei Ihnen vorstellen:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 server.domain.tld ESMTP Postfix (Debian/GNU)
Jetzt ist Postfix bereit SMTP Befehle engegen zu nehmen. Zunächst müssen wir uns mittels EHLO vorstellen.
EHLO localhost.localdomain
Danach gibt Postfix preis welche Funktionen er anbietet:
250-server.domain.tld
250-PIPELINING
250-SIZE 26214400
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
Den Absender angeben:
MAIL FROM: <jane@domain.tld>
Ein positiver Statuscode (2xx)? Gut. Dann weiter.
250 2.1.0 Ok
Den Empfänger angeben.
RCPT TO: <john@domain.tld>
250 2.1.5 Ok
Wieder ein positivert Statuscode? Mit DATA leiten wir den Datenteil ein. Ab hier folgt dann unsere Nachricht.
DATA
354 End data with <CR><LF>.<CR><LF>
Der Text der Mail.
Hallo John Doe,
ich wollte mich nur mal bei dir melden.
.
250 2.0.0 Ok: queued as BC38117B1F
So, das wars. Wieder ein positiver Statuscode bedeutet, dass Postfix die Nachricht angenommen hat.
In der Datei /var/log/mail.log kann man überprüfen ob die Nachricht korrekt zugestellt wurde.
Dec 22 16:25:35 server postfix/smtpd[1397]: connect from localhost[127.0.0.2]
Dec 22 16:26:19 server postfix/smtpd[1406]: connect from localhost[127.0.0.1]
Dec 22 16:26:19 server postfix/smtpd[1397]: NOQUEUE: client=localhost[127.0.0.2]
Dec 22 16:26:19 server postfix/smtpd[1406]: BC38117B1F: client=localhost[127.0.0.1]
Dec 22 16:26:26 server vboxadm-smtpproxy[1278]: clean message (unknown) (1.74/2.50) from <jane@domain.tld> for <john@domain.tld> in 0.11 s, 190 bytes. rules hit: ALL_TRUSTED,MISSING_DATE,MISSING_HEADERS,MISSING_MID
Dec 22 16:26:26 server postfix/cleanup[1407]: BC38117B1F: message-id=<>
Dec 22 16:26:26 server postfix/qmgr[1274]: BC38117B1F: from=<jane@domain.tld>, size=620, nrcpt=1 (queue active)
Dec 22 16:26:26 server postfix/smtpd[1397]: proxy-accept: END-OF-MESSAGE: 250 2.0.0 Ok: queued as BC38117B1F; from=<jane@domain.tld> to=<john@domain.tld> proto=ESMTP helo=<localhost.localdomain>
Dec 22 16:26:26 server postfix/smtpd[1406]: disconnect from localhost[127.0.0.1]
Dec 22 16:26:26 server postfix/pipe[1408]: BC38117B1F: to=<john@domain.tld>, relay=dovecot, delay=6.8, delays=6.6/0.02/0/0.18, dsn=2.0.0, status=sent (delivered via dovecot service)
Dec 22 16:26:26 server postfix/qmgr[1274]: BC38117B1F: removed
Dec 22 16:26:27 server postfix/smtpd[1397]: disconnect from localhost[127.0.0.2]
Die Dovecot Konfiguration ist zwar vom Autor aus sehr ausführlich und vorbildlich kommentiert, aber die Menge an Informationen kann verwirrend wirken. Daher gehe ich hier auf die wichtigen Abschnitte ein. Der Abschnitt protocols sollte um die POP3 Protokolle ergänzt werden.:
protocols = imap imaps pop3 pop3s managesieve
In der Listen Anweisung wird festegelegt auf welcher Interface der Server lauschen soll. Im Abschnitt Logging sollte man unter log_path einen Pfad zur Logdatei angeben, da alles Ausgaben sonst im syslog landen, was schnell recht unübersichtlich werden kann.
log_path = /var/log/dovecot.log
Auf diese Datei sollten Sie ein chown dovecot:dovecot /var/log/dovecot.log sowie ein chmod 770 /var/log/dovecot.log ausführen, damit Dovecots Unterprozesse problemlos in die Logdatei schreiben können.
Wenn Sie sich für ein Setup mit SSL Zertifikaten entschieden haben, dann aktivieren Sie die entsprechende Option und geben Dovecot über ssl_cert_file und ssl_key_file den Pfad zu Ihrem Schlüsselpaar an.
ssl_disable = no
ssl_cert_file = /etc/ssl/certs/server.domain.tld.crt
ssl_key_file = /etc/ssl/private/server.domain.tld.key
Die anderen SSL Optionen können Sie einfach so übernehmen. Als nächstes sollten Sie die Option login_greeting anpassen.
login_greeting = server.tld Mailserver (powered by Dovecot) ready.
Hier tragen Sie am besten den Hostnamen Ihres Servers ein. Mit der Option mail_location teilen Sie dovecot mit wo Ihre Postfächer liegen. Wenn Sie der hier beschriebenen Verzeichnisstruktur gefolgt sind, dann lautet diese Zeile wie folgt:
mail_location = maildir:/srv/vmail/%d/%n/Maildir
Im einzelnen bedeutet dies, dass Sie maildir verwenden und die entsprechenden Verzeichnisse unter dem Pfad /srv/vmail/<domain>/<local_part>/Maildir liegen. Die Variable %d wird von dovecot durch die Domain ersetzt, die Variable %n durch den lokalen Teil der Adresse. Die nun folgenden Einstellungen zum Namespace können Sie einfach übernehmen, genau wie die weitern Optionen bis zu first_valid_uid. Dies muss angepasst werden. Da in dem vorgestellten Setup keine echten Benutzer für den Mailempfang angelegt werden, befinden sich alle Postfächer in Besitz von vmail. Dieser Benutzer hat z.B. die Benutzer ID 8. Finden Sie die korrekte ID über die Datei /etc/passwd heraus. Daher müssen Sie den Bereich der gültigen UIDs wie folgt anpassen:
first_valid_uid = 8
last_valid_uid = 8
Die weiteren Einstellungen zu IMAP und POP3 können Sie einfach so übernehmen. Die Optionen im Abschnitt protocol lda sollten Sie wie in Nachrichten mit dem Dovecot Delivery Agent (LDA) zustellen beschrieben anpassen.
Der nächste interessante Abschnitt ist auth default. Hier deaktivieren Sie den Abschnitt passdb passwd-file sowie alle weiteren bis aus passdb sql. Die einzige Option für diesen Abschnitt ist der Pfad zur SQL Konfiguration. Deren Konfiguration wird später betrachtet.
passdb sql {
args = /etc/dovecot/dovecot-sql.conf
}
Die Abschnitte zu userdb müssen ebenfalls alle auskommentiert werden, bis aus die folgenden:
userdb passwd {
}
userdb static {
args = uid=9 gid=8 home=/srv/vmail/%d/%n allow_all_users=yes
}
Damit Dovecots LDA deliver arbeiten kann muss noch der entsprechende Socket aktiviert werden:
socket listen {
master {
path = /var/run/dovecot/auth-master
mode = 0600
user = vmail # User running Dovecot LDA
}
client {
path = /var/spool/postfix/private/auth
mode = 0600
user = postfix
group = postfix
}
}
Nach der Hauptkonfiguration in dovecot.conf fehlt noch die Konfiguration der SQL Abfragen in dovecot-sql.conf. Diese wurde bereits im Abschnitt Verbindung zur Datenbank besprochen.
Damit ist die Konfiguration von Dovecot abgeschlossen.
Das POP3 Protokoll ist recht simpel, so dass Sie den Empfang von Nachrichten über POP3 problemlos per Hand testen können.
$> telnet localhost 110
Nachdem Sie sich verbunden haben werden Sie von dovecot begrüßt.
Trying 192.168.0.1...
Connected to server.domain.tld.
Escape character is '^]'.
+OK server.domain.tld Mailserver (powered by Dovecot) ready.
Der Server ist jetzt Bereit. Jetzt kann man sich einloggen.
user john@domain.tld
Der Server sollte den Benutzernamen akzeptieren.
+OK
Dann muss noch das Passwort angegeben werden.
pass pass
Wenn der Server das Passwort akzeptiert sind Sie eingeloggt.
+OK Logged in.
Jetzt kann man sich eine Liste der Nachrichten im Postfach anzeigen lassen.
list
Dovecot teilt nun mit wieviele Nachrichten vorhanden sind.
+OK 1 messages:
1 2958
.
Mit retr kann man die Nachrichten abrufen. Holen Sie die erste Nachricht.
retr 1
Jetzt liefert Ihnen dovecot die Nachricht.
+OK 2958 octets
[Hier folgt die Nachricht]
Nach erledigter Arbeit können Sie sich ausloggen.
quit
Was von Dovecot nochmal bestätigt wird.
+OK Logging out.
Connection closed by foreign host.
Das das IMAP Protokoll etwas komplizierter als SMTP oder POP3 ist empfiehlt es sich hierfür mutt oder einen anderen Client zu benutzen.
mutt -f ./Maildir
Aber Sie können es natürlich auch gerne von Hand versuchen.
$> telnet localhost 143
Trying 127.0.0.1...
Connected to server.domain.tld.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS STARTTLS AUTH=PLAIN] server.domain.tld Mailserver (powered by Dovecot) ready.
Gut, der Server anwortet. Jetzt können wir uns anmelden.
1 login john@domain.tld password
Wenn Benutzername und Passwort stimmen, sollte der Server ein OK liefern.
1 OK Logged in.
Jetzt lassen Sie sich die vorhandenen Nachrichten anzeigen.
2 list "" "*"
* LIST (\HasNoChildren) "." "INBOX"
2 OK List completed.
Wählen Sie jetzt den Posteingang (INBOX) aus:
3 select "INBOX"
Daraufhin erhalten Sie automatisch einige Informationen über diesen Ordner:
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft Junk NonJunk $FORWARDED $TODO $WATCHED $IGNORED)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft Junk NonJunk $FORWARDED $TODO $WATCHED $IGNORED \*)] Flags permitted.
* 1 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1158586288] UIDs valid
* OK [UIDNEXT 136835] Predicted next UID
3 OK [READ-WRITE] Select completed.
Anhand der dritten Zeile (* 1 EXISTS) können Sie sehen, dass eine Nachricht vorliegt. Rufen Sie diese nun ab.
4 fetch 1 all
Sie erhalten nun zunächst nur ein paar Informationen über die Nachricht, nicht jedoch den Nachrichtentext.
* 1 FETCH (FLAGS (\Seen) INTERNALDATE "17-Apr-2008 09:23:44 +0200" RFC822.SIZE 2958 ENVELOPE ("Thu, 17 Apr 2008 00:02:40 -0400" "Subject" (("Hello" NIL "Jeo" "jeo@ceo.org")) (("Hello" NIL "Jeo" "jeo@ceo.org")) (("Hello" NIL "Jeo" "jeo@ceo.org")) ((NIL NIL "ceo" "ceo.org")) NIL NIL NIL "<CEO.20080417.564403.001.1208404960@ceo.org>"))
4 OK Fetch completed.
Den Text müssen Sie explizit anfordern:
5 fetch 1 body[]
Jetzt liefert Dovecot Ihnen den kompleten Inhalt zurück:
* 1 FETCH (BODY[] {486}
[Nachrichtentext]
5 OK Fetch completed.
Sie können sich jetzt abmelden.
6 logout
Dovecot verabschieded sich noch von Ihnen und schließt dann die Verbindung.
* BYE Logging out
6 OK Logout completed.
Connection closed by foreign host.
Wenn alle Vorarbeiten abgeschlossen sind sollte die Installation der webbasierten Postfix Managementoberfläche VBoxAdm schnell von der Hand gehen. Zunächst müssen die Datenbankinformationen eingetragen und einige allgemeine Einstellungen vorgenommen werden. Öffnen Sie dazu die Datei /etc/vboxadm/vboxadm.conf in einem Editor Ihrer Wahl.
Die Konfigurationsdatei folgt den Stil von ini-Dateien. Sie ist in Abschnitte eingeteilt die mit eckigen Klammern eingeleitet werden, z.B. der Abschnitt [default]. Dieser Teil gilt für alle Komponenten von VBoxAdm und jede Komponente die weitere Optionen benötigt hat noch einen eigenen Abschnitt.
Setzen Sie zunächst im Abschnitt default die Datenbankzugangsdaten ein.
dbuser=vboxadm
dbpass=<PASSWORD>
dbdb=vboxadm
dbhost=localhost
Natürlich müssen Sie hier den MySQL Benutzer und das entsprechende Passwort verwenden das Sie vorhin angelegt haben.
Der SMTP-Proxy ist sowohl für die Spam Erkennung mittels SpamAssassin als auch für individuelle Größenbeschränkungen zuständig. Er ist als Pre-Forking Server implementiert, ähnlich dem Apache HTTP-Server. D.h. dass auf Vorrat eine gewisse Anzahl an Prozessen erzeugt werden die auf Verbindungen warten und nach eine gewissen Anzahl von verarbeiteten Anfragen die Arbeit einstellen und durch eine frische Instanz ersetzt werden.
Die meisten Optionen können unverändert übernommen werden, lediglich max_msg_size sollte nach Ihren Vorlieben angepasst werden. Es handelt sich dabei um die maximale Nachrichtengröße in MB. Die Optionen min_servers, max_servers und max_requests können Sie verwenden um das PreFork-Verhalten zu tunenen wenn Sie den Proxy einige Zeit im Einsatz hatten.
Um den Proxy zu aktivieren muss noch die Variable START_SMTPPROXY in der Datei /etc/default/vboxadm-sa auf true gesetzt werden. Danach einfach /etc/init.d/vboxadm-sa start ausführen um den Proxy zu starten.
Damit das Webinterface benutzt werden kann muss noch ein initialer Site-Admin angelegt werden; alle weiteren lassen sich dann über das Webinterface anlegen.
$> /usr/bin/vboxadm mailbox add your.name@domain.tld --bootstrap -a 1 --siteadmin=1
Der Benutzername und das Passwort können später genutzt werden um sich in die Weboberfläche einzuloggen.
Greylisting ist ein Verfahren um Spam Mails vor der Einlieferung abzuwehren. Es macht sich die Tatsache zu Nutze, dass die meisten Spamschleudern das SMTP Protokoll nicht korrekt implementieren. Die meisten Spam Versender versuchen einfach die Mails so schnell wie möglich zu verschicken. Das SMTP Protokoll sieht jedoch auch vor, dass ein Server dem Absender einen temporären Fehler liefert und der Absender es nach einer gewissen Zeitspanne erneut versuchen soll. Die meisten Spam-MTAs geben hier sofort auf und versuchen nicht erneut die Nachricht zuzustellen. Die regulären MTAs implementieren das Protokoll jedoch meistens korrekt und versuchen nach einigen Minuten erneut die Nachricht zuzustellen.
Der Greylisting Daemon postgrey merkt sich alle Kombinationen aus Zieladresse und Absender IP. Beim ersten Versuch wird der MTA einen temporären Fehler liefern, nach einer gewissen Wartezeit wird die Nachricht dann akzeptiert. Dies gilt auch für alle weiteren Nachrichten von dem gleichen Absender in einem gewissen Zeitraum.
Die Voreinstellung ist 35 Tage, mag-age in der Konfigurationsdatei /etc/default/postgrey. Die Wartezeit bevor eine Nachricht nach dem ersten Versuch angenommen wird ist 5 Minuten voreingestellt und kann über delay angepasst werden. Über die Datei /etc/postgrey/whitelist_clients lassen sich Mailserver angeben die niemals durch Greylisting blockiert werden sollen. Hier kann man z.B. wichtige Kunden oder als problematisch bekannte Absender eintragen.
Als Webmail Client bietet sich Roundcube aufgrund der unkomplizierten Einrichtung, des guten Funktionsumfanges und der ansprechenden Oberfläche an. Natürlich kann man sattdessen auch Horde/IMP oder einen andere Webmail Lösung verwenden, aber ich rate zu Roundcube. Vor allem auch da die Integration der Benutzeroberfläche nur für Roundcube entwickelt wurde.
Die Installation von Roundcube ist einfach und unkompliziert.
Als erstes müssen noch einige Pakete nachinstalliert werden die für den Einsatz von Roundcube notwendig sind.
$> aptitude install php5-cgi php5-mysql php5-mcrypt php5-imap php5-intl
Damit sich Roundcube einrichten lässt muss noch die Option suhosin.session.encrypt in der Datei /etc/php5/conf.d/suhosin.ini auf off gesetzt werden.
Legen Sie nun das Verzeichnis /opt/roundcube an und laden Sie dort die neuste Version von Rounbdcube herunter. Anschließend wird das Archiv entpackt und ein Symlink auf current angelegt. Dann legen Sie einen Ordner config an in dem Sie später die Roundcube Konfiguration speichern. Diese wird dann in den eigentlichen Roundcube Ordner verlinkt. Diese Symlink Konstruktion erlaubt später einfach Upgrades von Roundcube.
Natürlich können Sie auch die Roundcube Version verwenden die mit Debian ausgeliefert wird, aber bei sich schnell ändernden Webapplikationen finde ich es oft angenehmer die Upstream Version direkt zu verwenden.
Den Link zum Download findet man auf der Homepage von Roundcube.
$> mkdir - /opt/roundcube/config
$> cd /opt/roundcube
$> wget <URL>
$> tar xvfj roundcube-XXX.tar.bz2
$> ln -s roundcube-XXX/ current/
$> touch config/db.inc.php
$> touch config/main.inc.php
$> ln -s config/db.inc.php current/config/db.inc.php
$> ln -s config/main.inc.php current/config/main.inc.php
Am besten erzeugen Sie die Roundcube Konfiguration über den Installer. Rufen Sie dazu Roundcube über Ihren Webserver auf, z.B. http://roundcube.domain.tld/installer/. Folgen Sie den Anleitungen und speichern Sie die Dateien `db.inc.php und main.inc.php unter /opt/roundcube/config/ ab.
Nachdem die Installation abgeschlossen ist sollten Sie das Verzeichnis installer/ entfernen.
Damit ist die Einrichtung von Roundcube auch schon abgeschlossen und das Webmail-Interface kann über den Webserver aufgerufen werden.
Da es als Overkill anmutet für die Benutzeraktionen (Passwort ändern, Urlaubsnachricht setzen) ein eigenen Webinterface zu bauen oder umständlich diese Funktion in das bestehende Interface einzubauen wurden diese Funktionen über ein Roundcube Plugin umgesetzt. Nach der Konfiguration können alle Benutzer einfach über das Menü Einstellungen in Roundcube ihr Passwort ändern und ihre Abwesenheitsnachricht setzen.
Das dafür notwendige Plugin wird mit VBoxAdm mitgeliefert. Es befindet sich unter /usr/share/doc/vboxadm-common/examples/roundcube-plugin-vboxadm.tar.gz.
Entpacken Sie diese Datei in den Ordner /opt/roundcube/current/plugins.
$> cd /opt/roundcube/current/plugins
$> tar xvzf /usr/share/doc/vboxadm-common/examples/roundcube-plugin-vboxadm.tar.gz
Kopieren Sie die Datei /opt/roundcube/current/plugins/vboxadm/config.inc.php.dist nach /opt/roundcube/current/plugins/vboxadm/config.inc.php und setzen dort in den DSN die zuvor angelegten MySQL Zugangsdaten ein.
Um auch das Mangesieve Plugin zum verwalten der Sieve Filter Regeln zu verwenden kopieren Sie noch die Datei /opt/roundcube/current/plugins/managesieve/config.inc.php.dist nach /opt/roundcube/current/plugins/managesieve/config.inc.php.
Abschließend sind noch die Plugins in der Datei /opt/roundcube/config/main.inc.php zu aktivieren.
$rcmail_config['plugins'] = array('managesieve', 'vboxadm');
- Überprüfen Sie /var/log/mail.log
- Überprüfen Sie /var/vmail/dovecot.log
- Fragen Sie in #debian (auf Englisch) bzw. #debian.de (auf Deutsch) im Freenode
- Stellen Sie sicher, dass sie Debian "squeeze" verwenden
- Wenden Sie sich an den Autor (Deutsch oder Englisch).
Wer mit meinem Tutorial gar nicht glücklich wird, dem helfen vielleicht die folgenden Links weiter.
Hier können Sie VBoxAdm einschließlich der beschriebenen Konfiguration als Paket herunterladen: VBoxAdm Download.
F: Muss man die Maildir-Verzeichnisse selbst erstellen oder geschieht dies automatisch?
A: Die Maildir-Verzeichnisse werden automatisch von deliver beim ausliefern der ersten Nachricht angelegt.
F: Kann man POP3 und POP3S parallel verwenden?
A: Ja, das ist möglich in der vorgestellten Konfiguration aktiviert.
F: Benötigt man einen Backup-MX?
A: Nein, nicht unbedingt. Es gibt sogar Meinungen, dass ein Backup-MX mehr Probleme als Nutzen bereitet. Das SMTP Protokoll legt fest, dass ein Mailserver für ca. 3 Tage versuchen soll eine Nachricht auszuliefern, falls ein Server nicht erreichbar ist.
