Back to workaround.org | English | Deutsch

Tutorial: ISP-ähnlicher Email Service mit Debian-Sarge und Postfix 2.1

Dipl.-Inform. Christoph Haas

Patrick Jäger

Deutsche Übersetzung

$Rev$

Die aktuellste Version dieses Tutorials finden Sie unter http://workaround.org. Möglicherweise hinkt diese Übersetzung etwas der englischen Version hinterher. Wenn Sie dieses Dokument auch zur Verfügung stellen möchten, stellen Sie bitte sicher, daß Ihre Kopie immer aktuell ist.

Dieses Tutorial dürfen Sie wahlweise unter den Bedingungen der Creative Commons License Sharealike Version 2.5 oder den Bedingungen der GNU General Public License 2.0 verwenden. Bitte lesen Sie diese sorgfältig, bevor Sie Auszüge aus meiner Anleitung in Ihren eigenen Dokumenten verwenden. Respektieren Sie das Copyright. Und zu guter Letzt: bitte veröffentlichen Sie diese Anleitung nicht noch irgendwo anders - sie fühlt sich wohl hier.
Revision History
2004-07-22
Komplette Überarbeitung. Achtung: Das Datenbank-Layout wurde komplett geändert. Das Dokument liegt jetzt im docbook-Format vor.
2005-04-25
Der Pfad zur Maildir hat sich von user@domain/ zu domain/user/ geändert. Zum MySQL-Server kann auf der IP-Adresse 127.0.0.1 anstelle der IP-Adresse der Ethernet-Karte verbunden werden. Information über die Erstellung der Datenbank hinzugefügt. Pre-Cleanup zu master.cf hinzugefügt. Amavis kann virtuelle Domänen jetzt auch nachschlagen und die Revisionsnummern kommen aus Subversion.
2005-06-30
Das Skriptschnippselchen zum Spamlernen wurde korrigiert, und "pre-cleanup" in master.cf habe ich weggenommen.
2005-07-05
Aliase wurden bisher sowohl vor der Übergabe einer eMail an AMaViS als auch beim Wieder-Einfügen in das Postfix System ausgewertet. Mit der Einführung von receive_override_option=no_address_mappings wird erreicht, daß dies nur noch bei der Rückgabe an Postfix geschieht.

Abstract

Sie haben wahrscheinlich auch schon Web-Hoster gesehen, die Ihnen zusätzlich zu einer Domain auch die Möglichkeit anbieten, eine gewisse Anzahl unterschiedlicher eMail-Adressen in dieser Domain zu nutzen. Und wahrscheinlich haben sie sich auch schon gewundert, wie diese Unmenge von Domains verwaltet wird. Denn mit Sicherheit ist es nicht so, dass alle Aliase von Hand in Postfix' main.cf eingetragen werden. Zwei Konfigurationsmöglichkeiten von Postfix erlauben aber die Vereinfachung dieser Aufgaben:

  • Virtuelle Domänen

    Zusätzlich zu der Domain, die sie als lokale Domäne (Domain) für Ihren Rechner verwenden (wahrscheinlich haben Sie diese in /etc/defaultdomain eingetragen) können Sie hiermit eMails für andere Domänen empfangen - so genannte virtuelle Domänen. Netterweise ist die Anzahl der Domänen, für die man eMails mit Postfix empfangen kann, nicht begrenzt.

  • Datenbank-Abfragen

    Es ist nicht nötig, Informationen über Benutzer und eMail-Adressen in Textdateien abzuspeichern - Postfix beherrscht Datenbankabfragen zu üblichen DBMS wie MySQL oder PostrgreSQL. Dieser Ansatz ist deshalb sehr interessant, weil man hierfür eine grafische Oberfläche als Webinterface schreiben kann und damit sogar den Benutzern selbst die Verwaltung ihrer eMail-Adressen möglich machen kann.

Diese Anleitung ist als Einführung in die Grundlagen für eine solche Konfiguration gedacht. Wenn Sie alle Schritte, die hier beschrieben werden, sorgfältig umsetzen, haben Sie am Ende eine Mail-Server der tausende von Domänen und Benutzern beherbergen kann. Einige der damit verbundenen Fähigkeiten:

  • POP3/IMAP-Zugriff für die Benutzer
  • Webmail-Zugang
  • Virus-Überprüfung
  • SPAM-Vermeidung
  • Sicherer SMTP-Zugang für Dial-Up Benutzer
  • Einfache Domänen-Verwaltung

Nichtsdestotrotz: ich versuche zwar, Sie so weit es geht an die Hand zu nehmen, aber von ein paar Sachen sollten Sie zumindest schon gehört haben:

  • MySQL (Anlegen einer Datenbank, Zugriffsrechte für Benutzer definieren, Syntax einer SQL-Abfrage)
  • SMTP, POP3, IMAP (ein minimales Verständnis dieser Protokolle)
  • Basiskenntnisse der Konfiguration von Postfix (Sie sollten mit der main.cf-Datei vertraut sein)
  • Debian/Linux (auch hier sollten sie grundlegende Befehle zur Software-Installation und Systemadministration kennen)

[Important]
Das Tutorial wurde überarbeitet und einige Punkte haben sich ein wenig geändert. Ich habe es zwar sorgfältig überprüft, trotzdem kann es sein, dass sich in diesem Dokument noch einige Fehler befinden. Bei Zweifel oder Unklarheit schlage ich vor, dass Sie hier in alten Versionen nachschlagen. Bei Fehlern schicken Sie mir doch bitte eine eMail an mich. Sollten Sie die Umstellungen von einer alten Fassung dieses Tutorials vornehmen, folgen Sie bitte der Anleitung unter dem Punkt Wir kommen von einer alten Version dieses Tutorials....
[Important]
Dieses Tutorial wurde für Debian-Sarge geschrieben. Sollten Sie anstatt dessen Woody verwenden, lesen Sie bitte anstatt dessen das Tutorial für Postfix 1.x und Woody.

Table of Contents

Die einzelnen Komponenten
Was sind Zuordnungen?
Wie funktionieren virtuelle Domänen?
Schritt 1: Installation der benötigten Debian Pakete
Schritt 2: Anlegen der Datenbank
Schritt 3: Definition der Tabellen
Domänen
Weiterleitungen
Benutzer
Schritt 4: Festlegen der Datenbankzuordnungen
mysql-virtual_domains.cf
mysql-virtual_forwardings.cf
mysql-virtual_mailboxes.cf
mysql-virtual_email2email.cf
Schritt 5: Anlegen eines vmail-Benutzers
Schritt 6: Editieren von main.cf
Mal eben testen
Schritt 7: Wir bringen Postfix SMTP-Auth bei - oder: Postfix lernt SASL
Wir bringen Postfix bei, SASL/MySQL zu verwenden
TLS zur Verschlüsselung von SMTP-Verbindungen nutzen
Schritt 8: Einrichten von POP3 und IMAP
Nochmal kurz testen...
Schritt 9: Ein wenig ausgiebiger testen...
domains
users
Schritt 10: Wir füttern unsere Datenbank
Für jede neue Domäne...
>Für jeden neuen Benutzer...
Für jede neue Weiterleitung...
Eingehende eMail auf Viren untersuchen(optional)
AMaViS-Einführung
Einrichtung von AMaViS
Postfix mit AMaViS bekannt machen
Wie funktioniert der content_filter eigentlich?
Und jetzt noch ein bißchen Trainig für SpamAssassin
Webmail einrichten und anbieten
Mailing listen mit Mailman
Fehlersuche
Fehlermeldungen
MySQL-Fehlersuche
Hilfe im IRC
Wir kommen von einer alten Version dieses Tutorials...
E-Mails beim Zustellen mit Hilfe von Maildrop filtern
Danksagungen
Worauf Sie gespannt sein dürfen... Etch!
Ergänzungen von Lesern und Anwendern

Die einzelnen Komponenten

Das komplette System basiert auf unterschiedlichen Software-Komponenten, die so miteinander bekannt gemacht werden, dass das komplette System problemlos funktioniert. Folgende Komponenten übernehmen Verantwortung:

  • Postfix: Der MTA (Mail Transfer Agent - also der, der eMail vom Absender zum Empfänger transportiert) empfängt die eMails über SMTP (Simple Mail Transfer Protocol) und speichert diese eMails dann an unterschiedlichen Plätzen auf Ihrer Festplatte.
  • MySQL: Der Datenbankserver, der Informationen über Domänen, Mail-Weiterleitungen, Benutzer und Paßwörter speichert und hierüber das Verhalten von Postfix steuert.
  • Courier: Courier ist ebenso wie Postfix ein eigenständiger Mailserver - wir werden allerdings nur seine POP3 und IMAP Funktionen verwenden, um damit auf die Postfächer zuzugreifen.
  • SASL (eine Bibliothek von cyrus): Anhand dieser Bibliotheken machen wir es möglich, dass Benutzer, die sich nicht innerhalb eines vertrauenswürdigen Netzwerkes befinden, sich trotzdem bei Postfix authentifizieren können. So können Sie auch von außerhalb - also zum Beispiel von einem Einwahlrechner - eMails versenden. Das ist deshalb nötig, weil Postfix aus Sicherheitsgründen nur aus einem bestimmten Bereich des Netzwerkes ohne weiteres eMails entgegen nehmen wird.
  • AMaViS: "A Mail Virus Scanner" - arbeitet als Filter in Postfix und ermöglicht die Untersuchung eingehender eMails auf SPAM und Viren.
  • phpmyadmin: Ein Webinterface zur Verwaltung von MySQL-Datenbanken - etwas komfortabler als die Verwendung von 'mysql' als Kommandozeileninterface.

Und jetzt noch für alle, die große Überblicksbilder mögen:

Was sind Zuordnungen?

Kurz gesagt wird bei einer Zuordnung ("mapping") ein Wert einem anderen zugewiesen. Sie kennen wahrscheinlich die Datei /etc/aliases, in der eMail-Weiterleitungen für Ihre Domäne eingetragen sind. Eine klassische Zeile sieht so aus:

postmaster: root

Hiermit sagen wir Postfix, dass alle eMails an postmaster@ihre-domain.tld an root@ihre-domain.tld weitergeleitet werden sollen. Die linke Seite - also Postmaster - wird normalerweise LHS (kommt aus dem englischen, da steht das für "left-hand side") und die rechte Seite - also root - konsequenterweise RHS (wie "right-hand side") genannt. Merken Sie sich das - es sind häufig verwendete Abkürzungen wenn über Zuordnungen gesprochen wird.

Achtung: Normalerweise haben Zuordnungstabellendateien (nettes Wort, oder?) keine ":" auf der linken Seite - aber die /etc/aliases ist ein Spezialfall, sowohl aus historischen als auch aus Kompatibilitätsgründen. Außerdem ist diese Datei auch aus einem anderen Grund noch ein Spezialfall: er wird nicht wie üblich mit postmap, sondern mit newaliases übersetzt. Das ist also eigentlich ein ziemlich unpraktisches Beispiel - aber es sollte trotzdem verdeutlichen, was gemeint ist ;-).

Wenn Sie also Postfix einfach mal so aus der Hüfte aufsetzen, werden sie mit Sicherheit mit Dateien wie oben beschrieben anfangen. Sie schreiben die Zuordnungen in die Datei und rufen dann postmap ihre-datei für ihre-datei auf. Das erzeugt eine Hash-Datei names "ihre-datei.db" für Ihre Datei, die Sie dann aus Postfix als Zuordnung mit hash:dateiname benutzen können. Und wahrscheinlich haben Sie als aufmerksamer Leser auch schon bemerkt, dass die Standard alias-Tabelle mit alias_maps = "hash:/etc/aliases" eingebunden wird. hash: steht übrigens für diese spezielle Methode auf Dateien diesen Formates zuzugreifen.

In meiner Konfiguration ersetze ich Textdateien durch MySQL-Tabellen - das ermöglicht einen flexibleren Umgang mit den Daten. Da nun aber Datenbanktabellen im allgemeinen mehr als nur zwei Spalten enthalten, müssen wir Postfix irgendwie verraten, welche Spalte die LHS und welche die RHS ist. Das können wir wie folgt in einfachen Textdateien erreichen:

user = provider_admin
password = DomAKg07
dbname = provider
table = virtual_mailboxes
select_field = mailbox
where_field = email
hosts = 127.0.0.1

Wenn wir diese Datei jetzt als "/etc/postfix/mysql_virtual_mailboxes.cf" abspeichern, können wir also eine Zuordnung der Form "virtual_mailbox_maps=mysql:/etc/postfix/mysql_virtual_mailboxes.cf" verwenden. Das "where_field" entspricht in diesem Fall der LHS, und das "select_field" der RHS unserer Zuordnung - in diesem Fall bedeutet das eine Zuordnung der Spalte email zu der Spalte mailbox. Das Feld user beinhaltent den Benutzernamen für die Datenbank dbname, die mit dem in password definierten Paßwort auf dem Rechner hosts befragt wird.

Wie funktionieren virtuelle Domänen?

Zunächst möchte ich ein paar generelle Worte zu Virtuellen Domänen in Postfix sagen (mit Postfix 1.x - ein wenig veraltet - funktionieren virtuele Domänen noch etwas anders), denn eine fehlerhafte Konfiguration wird Sie außer Haaren auch noch Zeit kosten. Es gibt also zwei unterschiedliche Formen von Domänen:

  • Lokale Domänen

    Alle Domänen in mydestination in Ihrer main.cf werden als lokale Domänen behandelt. Ihre Standard-Domäne (höchstwahrscheinlich in /etc/defaultdomain) ist im Normalfall Ihre lokale Domäne, und eMails an lokale Domänen werden an Systembenutzer zugestellt - das sind die, die in /etc/passwd stehen. Das heißt aber auch, dass diese eMail nach /var/mail ausgeliefert werden.

  • Virtuelle Domänen

    Ihr Mail-Server empfängt eMails für weitere Domänen - virtuelle Domänen genannt. Virtuelle Domänen sind sehr flexibel, da man keinen Systembenutzer für jeden einzelnen eMail-Benutzer benötigt - daraus folgt, dass Ihr System eine Unmenge von eMail-Benutzern vollkommen unproblematisch verwalten kann. Für diesen Zweck verwende ich in dieser Anleitung SQL-Zuordnungen.

    Da uns das aber noch nicht komplex genug ist, gibt es zwei unterschiedlich Formen von Virtuellen Domänen:

    • Virtual Alias Domains - (virtuelle Alias-Domänen)

      Eine virtuelle Alias-Domäne könnte man verwenden, um eMails von einer bestimmten eMail-Adresse an eine andere eMail-Adresse weiterzuleiten. Der Nachteil ist, dass man damit keine eMails so empfangen kann, dass sie an einem bestimmten Ort auf der Festplatte gespeichert werden. Daher werde ich das hier nicht weiter verwenden. Man kann diese Funktion auch über virtual_alias_maps erreichen, die als allgemeine Tabellen für eMail-Weiterleitungen gedacht sind - hier können wir sogar eMails für lokale Domänen umleiten.

    • Virtual Mailbox Domains (virtuelle Mailbox-Domänen)

      Eine virtuelle Mailbox-Domäne ermöglicht es, eMails für Adressen einer bestimmten Domäne zu empfangen und auf der Festplatte abzuspeichern. Auch hier ist es uns wieder möglich, anhand von Zuordnungen in virtual_alias_maps eine eMail an eine andere eMail-Adresse in einer beliebigen Domäne weiterzuleiten. Das Ganze ist lediglich ein Parameter mit dem wir Postfix verraten, wie der Großteil der Adressen für diese Domäne gehandhabt werden soll. Übrigens wird die Zuordnungstabelle virtual_mailbox_maps dafür genutzt, festzustellen, wo auf der Festplatte eine eMail abgespeichert werden soll.

    Und jetzt noch was ganz wichtiges: eine Domäne ist entweder eine lokale Domäne virtuelle Alias-Domäne oder eine virtuelle Mailbox-Domäne. Wenn eine Domäne zur zweiten Kategorie gehört, dann können sie eMails an diese Domäne nie auf ihrem Server empfangen. Wenn Sie allerdings virtual_alias_maps verwenden, können Sie Aliase und Weiterleitungen für beide Arten von virtuellen Domänen benutzen. Wir schlußfolgern also: virtual_mailbox_domains sind normalerweise die bessere - weil flexiblere - Wahl.

[Important]
Eine Domäne kann nur entweder virtuell oder lokal sein - beides gleichzeitig geht nicht! Wenn also auch die Standard-Domäne virtuell sein soll, dann löschen Sie diese aus mydestination und lassen Sie diese Einstellung entweder leer oder setzen Sie höchstens auf "mydestination=localhost". Emails an Adressen der Form root@localhost werden dann also an root auf diesem System zugestellt.

Außerdem empfehle ich Ihnen, bei Gelegenheit auch die von Postfix zur Verfügung gestellte Dokumentation zu virtuellen Domänen zu lesen - sie finden Sie in /usr/share/doc/postfix/VIRTUAL_README.gz.

Schritt 1: Installation der benötigten Debian Pakete

Pakete, die Sie auf jeden Fall benötigen:

  • postfix (In debconf wählen Sie bitte "Nur lokale Zustellung" aus)
  • postfix-mysql
  • postfix-doc

Wenn Sie den MySQL-Server auf dem selben Rechner installieren möchten:

  • mysql-server (für MySQL 3.x/4.0) oder mysql-server-4.1 (für MySQL4.1)

Für POP3- und IMAP-Zugriff brauchen Sie außerdem:

  • courier-authdaemon
  • courier-authmysql
  • courier-pop (für unverschlüsselten POP3 Zugriff)
  • courier-pop-ssl (für SSL-verschlüsselten POP3 Zugriff)
  • courier-imap (für unverschlüsselten IMAP Zugriff)
  • courier-imap-ssl (für SSL-verschlüsselten IMAP Zugriff)

Wenn Sie außerdem noch SMTP-Auth für Dial-Up Benutzer einrichten möchten:

  • postfix-tls (für verschlüsselte SMTP-Authentifizierung)
  • libsasl2 (die Cyrus SASL Bibliothek)
  • libsasl2-modules (die Mechanismen für die SASL Bibliothek)
  • libsasl2-modules-sql
  • openssl (um ein Zertifikat zu erstellen)

Für die Untersuchung eingehender eMail auf SPAM und Viren:

  • amavisd-new
  • spamassassin
  • clamav
  • clamav-daemon
  • zoo
  • unzip
  • unarj
  • lha (in non-free!)

Und last but not least der Webmail-Zugriff:

  • squirrelmail

Nicht unbedingt nötig, aber sehr nützlich:

  • phpmyadmin (Web-Interface für die bequeme Administration von MySQL-Datenbanken)

Schritt 2: Anlegen der Datenbank

Für die benötigten Zuordnungstabellen müssen wir in MySQL eine Datenbank anlegen. Wenn Sie Erfahrung im Umgang mit MySQL haben können Sie das natürlich von der Kommandozeile aus mit dem mysql-Befehl erledigen. Ich würde Ihnen allerdings empfehlen, hierfür phpmyadmin zu benutzen. Die Entscheidung überlasse ich Ihnen.

Tip: wenn der MySQL-Server zum ersten Mal gestartet wird, können Sie auf die Datenbanken als Benutzer 'root' ohne Paßwort zugreifen. Sie sollten zunächst ein Paßwort für diesen Benutzer anlegen:

mysqladmin -u root password Ihr-mysql-paßwort

Legen Sie zunächst eine Datenbank an. Ich nenne sie 'provider', da ich damit später noch mehr machen möchte, als nur eMail-Konten darin zu speichern (was allerdings den Rahmen dieser Einführung definitiv sprengen würde). Sie können das entweder in phpmyadmin oder aber auf der Kommandozeile wie folgt erledigen:

mysqladmin -u [username] -p -h [hostname] create provider

Sie müssen nun eine neuen Datenbankbenutzer anlegen, der Nur-Lese-Zugriff auf die Datenbank "provider" für Ihre eMail-Daten hat. Öffnen Sie hierfür eine Verbindung zu ihrem MySQL-Server:

mysql -u root -p

...und geben Sie folgendes Kommando ein, sobald Sie den MySQL-Prompt mysql> sehen:

grant select on provider.* to provider_admin@localhost identified by 'your-password';

Dadurch wird ein neuer Benutzer namens provider_admin für die Datenbank angelegt, der lediglich die 'SELECT'-Berichtung für die Datenbank provider hat. Ersetzen Sie bitte your-password mit einem Paßwort Ihrer Wahl - automatisch erzeugen können Sie eines mit dem Kommando pwgen -s 16 (Hierzu müssen Sie allerdings das Kommando aptitude install pwgen ausführen. Schlußendlich müssen Sie die Zugriffsberechtigungen noch neu laden:

flush privileges;

Schritt 3: Definition der Tabellen

Jetzt haben Sie zwar eine Datenbank - aber eine leere Datenbank ist ziemlich nutzlos. Also brauchen wir noch Tabellen, damit wir in die Datenbank auch noch reinschreiben können, was wir Postfix später abfragen lassen wollen. Falls Sie das Kommandozeilen-Programm mysql benutzen, starten Sie dieses. Darin öffnen Sie dann mittels

USE provider;

die Datenbank 'provdier, damit hierin die Tabellen angelegt werden.

Domänen

Die erste Tabelle, die wir anlegen, wird nicht mehr als eine langweilige Spalte für Domänen beinhalten - genauer gesagt, für jede virtuelle Domäne gibt es eine Zeile in dieser Spalte.

CREATE TABLE domains (
domain varchar(50) NOT NULL,
PRIMARY KEY (domain) )
TYPE=MyISAM;

Weiterleitungen

Mit der Tabelle 'forwardings' können wir eMails für eine bestimmte eMail-Adresse an eine andere eMail-Adresse weiterleiten. Das funktioniert sogar für lokale Domänen. Anlegen können wir die Tabelle mit folgendem SQL-Befehl:

CREATE TABLE forwardings (
source varchar(80) NOT NULL,
destination TEXT NOT NULL,
PRIMARY KEY (source) )
TYPE=MyISAM;

Benutzer

Und schlussendlich noch die Tabelle 'users' - sie enthält Informationen und Paßwörter für den Zugriff auf eMails über POP3 und IMAP. Im Allgemeinen haben die Benutzer die Angewohnheit, die Sicherheit von Passwörtern nicht sehr ernst zu nehmen - zum Leid der Systemadministratoren. Schauen Sie doch einmal unter die Schreibtischunterlage ihres Vorgesetzten - wahrscheinlich finden Sie hier alle seine Paßwörter. Also enthält diese Tabelle exakt zwei Spalten: die eMail-Adresse ('email') und das zugehörige Passwort. Anhand der Spalte 'email' werden wir außerdem bestimmen, wo wir die eMails abspeichern und wie der Benutzername lautet. Hierfür also noch ein letzter SQL-Befehl zum Anlegen dieser Tabelle:

CREATE TABLE users (
email varchar(80) NOT NULL,
password varchar(20) NOT NULL,
PRIMARY KEY (email)
) TYPE=MyISAM;

Schritt 4: Festlegen der Datenbankzuordnungen

Bis hierhin ist ja wohl dann alles soweit gut gegangen - aber da Sie ja aufmerksam sind und auch mitdenken, fragen Sie sich wahrscheinlich, ob Postfix mindestens genauso aufmerksam wie Sie ist, und beobachtet hat, dass es neue Plätze zum Auffinden von Informationen gibt. Ich muß Sie enttäuschen: so schlau ist Postfix leider nicht. Wir müssen es Postfix also noch irgendwie beibringen. Dazu müssen wir in /etc/postfix die folgenden vier Dateien anlegen:

[Important]
Postfix arbeitet teilweise innerhalb eines chroot-Verzeichnisses. (/var/spool/postfix) und kann daher keine Dateien außerhalb dieses Verzeichnisses lesen. Normalerweise - wenn ein MySQL-Server auf dem gleichen Rechner betrieben wird, wie Postfix - wird man seine Anfragen durch eine sogenannte Socket-Datei an MySQL stellen (/var/run/mysqld/mysqld.sock. Logischerweise kann Postfix das aber nicht. Nun haben Sie zwei Möglichkeiten:
  • Sie verschieben die Socket-Datei
  • oder Sie verwenden Netzwerkzugriffe über TCP über das lo-Interface.
Letzteres bedeutet aber auch, dass nicht nur Postfix über das Netzwerk mit ihrem MySQL reden kann - was theoretisch ein Sicherheitsloch sein kann, allerdings sind Zugriffe, die nicht von Ihrem eigenen Rechner kommen, nicht möglich.

(In der nächsten Version dieses Tutorials wird sich das zu einem cleveren mount-Eintrag für den MySQL-Socket in /etc/fstab ändern.)

mysql-virtual_domains.cf

Diese einfache Zuordnung von Domänennamen (LHS) zu dem Wort 'virtual' (RHS) wird für 'virtuelle mailbox-Domänen verwendet. In diesem Fall ist eigentlich nur die linke Seite von Bedeutung, allerdings gilt das erst seit Postfix v2.x, im Fall von Postfix v1.x mußte die rechte Seite dieser Zuordnung 'virtual' sein, so dass ich diesen Wert aus mehr oder weniger nostalgischen Gründen beibehalten habe. Für Postfix v2.x ist die rechte Seite dieser Tabelle nicht mehr von Bedeutung - sie können es also meinetwegen auf Erbeer-Bananen-Milch-Shake-gemischt-mit-Tequila-Sunrise setzen, wenn Sie möchten.

Legen Sie die Datei so wie Sie sie unten dargestellt sehen an, und ersetzen Sie die '...' mit dem Zugriffspaßwort für die Datenbank. Verwenden sie nicht "localhost" als Servername, da das dazu führen würde, dass Postfix versuchen würde, über den Socket von MySQL auf die Datenbank zuzugreifen. Verwenden Sie anstatt dessen einen Hostnamen oder eine IP-Adresse, wenn der MySQL-Server auf Ihrem Rechner arbeitet, können Sie als IP-Adresse 127.0.0.1 nutzen.

user = provider_admin
password = ...
dbname = provider
table = domains
select_field = 'virtual'
where_field = domain
hosts = 127.0.0.1

mysql-virtual_forwardings.cf

Die Einträge in dieser Tabelle ('forwardings') verwendet Postfix dafür, eMails für die Adresse in der linken Spalte ('source') an die eMail-Adresse in der rechten Spalte ('destination') weiterzuleiten. Wir verwenden diese Tabelle für die virtual_alias_maps-Zuordnung.

user = provider_admin
password = ...
dbname = provider
table = forwardings
select_field = destination
where_field = source
hosts = 127.0.0.1

mysql-virtual_mailboxes.cf

In dieser Datei erklären wir Postfix, wo es für die einzelnen eMail-Adressen die eMails ablegen soll. Später werden wir diese Zuordnungen für virtual_mailbox_maps verwenden. Postfix wird sich für eine bestimmte eMail-Adresse ('email' - LHS) die Mailbox ('mailbox' - RHS) aus unserer Tabelle heraussuchen. Wenn Sie an den Eintrag in Mailbox einen / anhängen, wird Postfix die eMail nicht in einer mailbox-Datei ablegen, sondern anstatt dessen ein Verzeichnis für die eMails anlegen - um mehr darüber zu erfahren, sollten Sie sich mit der sogenannten 'Maildir'-Technik beschäftigen. Wichtig ist für uns an dieser Stelle allerdings vor allem, dass wir den / anhängen, da wir Maildirs für Courier IMAP und POP3-Dienste brauchen.

user = provider_admin
password = ...
dbname = provider
table = users
select_field = CONCAT(SUBSTRING_INDEX(email,'@',-1),'/',SUBSTRING_INDEX(email,'@',1),'/')
where_field = email
hosts = 127.0.0.1

mysql-virtual_email2email.cf

Einer der Fallstricke von virtuellen Domänen sind sogenannte catch-all-Adressen. Im Klartext heißt das: in der Forwarding-Tabelle steht eine Weiterleitung der Form "@domain.com"->"service@domain.com", die dazu führt, dass alle eMails, die an irgendeinen Empfänger dieser Domain geschickt werden, an die eMail-Adresse service@domain.com ausgeliefert werden, wenn wir nur @domain.com, aber nicht alle eMail-Adressen in dieser Domain zuordnen - und das, obwohl die eMail-Adresse in virtual_mailbox_maps aufgelistet ist.

Hier ordnen wir alle eMail-Adressen in der users-Tabelle sich selbst zu, um das oben beschriebene Problem zu umgehen. Klingt komisch, ist aber so. :)

user = provider_admin
password = ...
dbname = provider
table = users
select_field = email
where_field = email
hosts = 127.0.0.1
[Important]
Sie müssen unbedingt sicherstellen, dass auf diese Dateien niemand anders als root selbst zugreifen kann. Ansonsten kann jeder Benutzer ihres Systems das Passwort für den Zugriff auf diese Datenbank im Klartext in diesen Dateien lesen. Führen Sie hierzu das Kommando "chmod o= /etc/postfix/mysql-virtual_*.cf" aus. Diese Dateien müssen wir jetzt noch so beackern, daß sie zum einen der Gruppe postfix gehören, und zum anderen müssen wir ein bißchen an den Zugriffsrechten rumbasteln. Also: "chgrp postfix /etc/postfix/mysql-virtual_*.cf" und "chmod u=rw,g=r,o= /etc/postfix/mysql-virtual_*.cf".

Schritt 5: Anlegen eines vmail-Benutzers

Mit dem hier beschriebenen System können Sie eMails für tausende von Benutzern speichern - wahrscheinlich wollen Sie aber nicht allen Benutzer auch eine UID (user ID = Benutzer-ID) zuweisen. Daher empfehle ich Ihnen, einen Benutzer anlegen, der Besitzer aller virtuell angelegten Mailboxen wird.

Hierfür müssen Sie lediglich folgendes Kommando in einer shell ausführen:

groupadd -g 5000 vmail
useradd -g vmail -u 5000 vmail -d /home/vmail -m
[Important]
Anmerkung: die Zahl 5000 ist die zu vergebene UID - sie müssen natürlich sicher stellen, dass diese UID noch nicht in Benutzung ist - sollte sie schon vergeben sein, benutzen Sie bitte eine andere UID.

Schritt 6: Editieren von main.cf

Die Hauptkonfigurationsdatei von Postfix ist /etc/postfix/main.cf. Ich werde hier nur die grundsätzlich notwendigen Einstellungen für virtuelle Domänen beschreiben. Werfen Sie also Ihre alte main.cf nicht weg. Sie werden wahrscheinlich die Konfiguration an anderen Stellen noch anpassen wollen, also kann ich hier keine komplette Konfiguration zur Verfügung stellen.

ParameterBedeutung
inet_interfaces = allDebian nutzt hier als Standard loopback-only. Wir wollen ja aber eigentlich mehr im Sinne eines ISPs arbeiten - wir müssen also auch nach außen ein bißchen zuhören - daher sollten wir diesen Parameter auf 'all' setzen, oder einfach gleich ganz weg lassen, denn 'all' ist bei Postfix Standard.
myhostname = ... Stellen Sie sicher, dass sich hier ihr FQDN (Fully Qualified Domain Name) befindet - für genaueres: schauen Sie doch bei Gelegenheit mal auf der Postfix Seite zum Thema 'myhostname' vorbei.
mydestination = ... Tragen Sie hier alle Domänen ein, die lokal zugestellt werden sollen, aber auf keinen Fall virtuelle Domänen. Auch hier gilt wie immer: Postfix stellt zu den Parametern Dokumentation bereit.
mynetworks = ... Tragen Sie hier die IP-Bereiche ein, aus denen Rechner über ihren Server eMails versenden dürfen. Höchstwahrscheinlich wird es sich hierbei um ihr lokales Netzwerk handeln. Und Sie haben sichs wahrscheinlich schon gedacht: es gibt auch hierzu Dokumentation.
virtual_alias_domains = Dieser Parameter wird von uns als nicht gesetzt vorausgesetzt. Wir verwenden virtual alias domains nicht. Wenn Sie die Standardeinstellung belassen haben, sollte dieser Parameter auf virtual_alias_maps eingestellt sein - für Abwärtskompatibilität zu älteren Postfix-Versionen. Und - es wird ja jetzt wohl kaum noch einen überraschen, auch hierzu stellt Postfix wieder Dokumentation bereit.
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual_forwardings.cf mysql:/etc/postfix/mysql-virtual_email2email.cf Dieser Parameter setzt allgemeine Umleitungen von eMail-Adressen. Hier können Sie eine eMail-Adresse an eine andere weiterleiten oder auch alle eMails für eine Domain an eine bestimmter eMail-Adresse weiterleiten. Diese Information werden in der Tabelle 'forwardings' gespeichert. Jede auf der linken Seite der Zuordnung zu findende eMail-Adresse wird umgeschrieben in die Adresse auf der rechten Seite. Wenn Sie auf der rechten Seite mehrere eMail-Adressen eintragen wollen, trennen sie diese durch Kommas. Außerdem verwende ich die mysql-virtual_email2email.cf Zuordnung, um jede Adresse sich selbst zuzuordnen. Das klingt zwar ziemlich blöde, aber wird dringend benötigt wenn Sie Catch-All-Adressen verwenden. Beachten Sie hierzu unter umständen nochmals den Abschnitt the mysql-virtual_email2email mapping file to see what's in that mapping file. See also its definition in the Postfix documentation.
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual_domains.cf Die Liste der virtuellen Domänen aus der `domains` Tabelle. Ein bißchen mehr hierzu bei Wietse Venema selbst.
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual_mailboxes.cf Auch dies ist eine wichtige Zuordnung - zugeordnet werden hier eMail-Adressen zu Speicherorten von eMail-Postfächern auf Ihrer Festplatte. Diese Speicherorte sind relativ zu virtual_mailbox_base. Auch hierzu hat Wietse was geschrieben
virtual_mailbox_base = /home/vmail Der Pfad, wo eMail-Postfächer von Benutzern gespeichert werden. Was genau das heißt, kann man bei Postfix nachlesen
virtual_uid_maps = static:5000 Sie sollten Postfix verraten, wem die eMail-Postfächer gehören - die Benutzer ID des Benutzers, dem Sie das zuordnen wollen (steht in /etc/passwd). Setzen Sie es bitte auf die Benutzer-ID von dem Benutzer "vmail", den Sie gerade angelegt haben. Mehr dazu bei Postfix selbst.
virtual_gid_maps = static:5000 Dasselbe nochmals für die Gruppen-ID. Und wie zum Benutzer so auch zu den Gruppen...
smtpd_sasl_auth_enable = yes Hier aktivieren wir die Benutzer-Authentifizierung über SASL. Und die Postfix Dokumentation
broken_sasl_auth_clients = yes Es gibt ein paar etwas seltsame eMail-Programme (manche nennen das auch kaputt), die eine im mindesten veraltete Technik nutzen, um rauszufinden, ob der Server Benutzerauthentifizierung kann - die wollen wir auch glücklich machen. Wer hat was von Outlook gesagt? :) Die Postfix Dokumentation beschäftigt sich allerindgs zumindest mit kaputten eMail-Programmen.
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination Diese Regeln werden angewendet, wenn eine neue eMail bei ihrem Server ankommt - sie überprüfen, wer über ihren Server überhaupt eMails verschicken darf. permit_mynetworks genehmigt das für alle, die von einem Rechner aus mynetworks eMail einliefern. permit_sasl_authenticated erlaubt das jedem, der sich gegenüber uns authentifiziert hat. Und außerdem darf natürlich jeder, der an relay_domains oder an eine lokale Domäne eine eMail verschicken will, die auch abgeben. Aber lassen wir doch einfach Postfix zum Thema smtp_recipient_restrictions zu Wort kommen.
smtpd_use_tls = yes Authentifizierte SMTP Verbindungen verschlüsseln wir mit SSL - was das heißt, verrät uns die Postfix Dokumentation
smtpd_tls_cert_file = /etc/postfix/smtpd.cert Der Ort, an dem wir unsere SSL Zertifikate ablegen - anlegen werden wir die später noch... Auch fürs Zertifikat gibts der Postfix Dokumentation.
smtpd_tls_key_file = /etc/postfix/smtpd.key Und zu guter Letzt noch der Speicherort des privaten SSL-Schlüssels für TLS. Mehr Infos wie üblich in der Postfix Dokumentation.

Mal eben testen

Geben Sie in der Shell /etc/init.d/postfix restart und postfix check ein. Sollten keine Warnungen angezeigt werden, sind Sie mit diesem Teil fertig.

Schritt 7: Wir bringen Postfix SMTP-Auth bei - oder: Postfix lernt SASL

Ihre Benutzer holen eMails via POP3 ab - aber wie versenden Ihre Benutzer eMails? Aus Sicherheitsgründen erlaubt Postfix nur den Benutzern, die in mynetworks definiert wurden, den Versand von eMails. Und normalerweise wird Ihr eMail-Server ansonsten nur eMails für seine eigenen Domänen annehmen. Würden Sie jedem erlauben, über Ihren eMail-Server eMails an jede mögliche eMail-Adresse zu versenden - sie würden damit ein sogenanntes Offenes Relais zur Verfügung stellen, etwas, was von Spammern nur zu gerne benutzt wird, um ihren Müll zu versenden. Also müssen wir uns einen Weg einfallen lassen, Benutzern, die gerade nicht in mynetworks sind, eine Möglichkeit zur Authentifizierung zu geben - sprich: Benutzername und Paßwort anzugeben. Wenn diese Daten korrekt sind, können sie genau wie die Benutzer in mynetworks eMails versenden. Glücklicherweise haben fast alle eMail-Programme die Möglichkeit, das zu nutzen.

Die Einrichtung von authentifiziertem SMTP ist ziemlich einfach. Das einzige Hindernis ist die Tatsache, dass Debians Postfix standardmäßig in einem chroot in /var/spool/postfixarbeitet.

Wir bringen Postfix bei, SASL/MySQL zu verwenden

Wie ich schon einmal sagte, verwendet Postfix die Cyrus SASL Bibliothek für authentifiziertes SMTP. Also müssen wir ihm beibringen, wie er auf die gespeicherten Daten (Benutzernamen und Paßwörter) zugreifen kann. Das ist eine relativ einfache Angelegenheit: Editieren Sie einfach die SASL-Konfigurationsdatei in /etc/postfix/sasl/smtpd.conf:

pwcheck_method: auxprop
auxprop_plugin: sql
mech_list: plain login cram-md5 digest-md5
sql_engine: mysql
sql_hostnames: 127.0.0.1
sql_user: provider_admin
sql_passwd: ...
sql_database: provider
sql_select: select password from users where email='%u@%r'
[Important]
Sie wissen schon: immer auf die Berechtigungen achten. Hier und jetzt heißt das: chown root:postfix /etc/postfix/sasl/smtpd.conf and chmod u=rw,g=r,o= /etc/postfix/sasl/smtpd.conf.

(Sollten Sie mit SASL Probleme haben, schlage ich vor, dass Sie noch die Zeile "log_level: 7" anhängen. Dadurch erhalten Sie in den Logdateien ausführlichere Informationen, die Ihnen vielleicht helfen, die Ursache für die Fehlfunktion zu finden.)

TLS zur Verschlüsselung von SMTP-Verbindungen nutzen

Ein wichtiger Bestandteil der Konfiguration ist die Verschlüsselung einer SMTP-Sitzung. Wenn Sie diese nicht verschlüsseln, können Benutzername und Passwort außerordentlich unsicher übertragen werden. Es gibt eMail-Programme, die tatsächlich noch Klartext-Authentifizierungsmethoden nutzen. Also nochmal: verschlüsseln Sie SMTP-Verbindungen mit TLS. TLS ist die Abkürzung für "Transport Layer Security" (RFC2246) - kurz gesagt: SSL (Secure Socket Layer) wird für die Verschlüsselung der Verbindungen zwischen mobilem Benutzer und Mail-Server verwendet.

Als erstes brauchen Sie natürlich ein SSL-Zertifikat. Sie wollen Ihr Lieblings-Trustcenter aber nicht für ein Zertifikat bezahlen? Benutzen Sie eben ein eigenes Zertifikat. (Kleine Randnotiz: ich frage mich sowieso, wie Geld etwas vertauenswürdiger macht.) Der einzige Nachteil eines eigenen Zertifikats: das eMail-Programm wird Ihre CA (certificate authority) noch nicht kennen und daher den Benutzer warnen. Entweder müssen Ihre Benutzer diese Warnung ignorieren, oder aber das Zertifikat auf ihren Rechnern installieren. (Bei Outlook kann man diese Warnung nicht ignorieren. Sie müssen hier das Zertifikat vorher als vertrauenswürdige CA installiert haben.)

Um ein Zertifikat zu erstellen, das zehn Jahre für den Rechnernamen smtpd.domain.tld gültig ist, geben Sie folgenden Befehl ein:

openssl req -new -outform PEM -out /etc/postfix/smtpd.cert -newkey rsa:2048 \
-nodes -keyout /etc/postfix/smtpd.key -keyform PEM -days 3650 -x509

openssl wird Ihnen dann ein paar Fragen zu den Details für Ihr Zertifikat stellen. Eigentlich ist es egal, was Sie eingeben - Sie müssen nur irgendwas eingeben. Mit einer Ausnahme: "Common Name" muss der Rechnername Ihres Mailservers sein. Das sieht zum Beispiel dann so aus:

Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Hamburg
Locality Name (eg, city) []:Hamburg
Organization Name (eg, company) [Internet Widgits Pty Ltd]:workaround.org email services
Organizational Unit Name (eg, section) []:Master of Disaster
Common Name (eg, YOUR name) []:smtp.domain.tld
Email Address []:postmaster@domain.tld

Einen kurzen Moment später werden Sie zwei neue Dateien haben: "smtpd.key" (der geheime Schlüssel) und "smtpd.cert" (das Zertifikat).

[Important]
Stellen Sie sicher, dass der Schlüssel nicht für alle Systembenutzer lesbar ist: chmod u=rw,g=r,o= /etc/postfix/smtpd.key und chown root:postfix /etc/postfix/smtpd.key

Schritt 8: Einrichten von POP3 und IMAP

Einen großen Teil des Einrichtens haben wir jetzt hinter uns. Allerdings wollen wir ja Benutzer glücklich machen - und Benutzer, die ihre Mails nicht lesen können, sind nicht glücklich. Also müssen wir wohl noch POP3 und IMAP einrichten. Als erstes müssen Sie dazu /etc/courier/authdaemonrc editieren - ändern Sie die Option "authmodulelist" in "authmysql". Also etwa so:

authmodulelist="authmysql"

Außerdem müssen wir natürlich noch verraten, in welchen MySQL-Tabellenfeldern die wichtigen Dinge stehen. Dafür beackern Sie /etc/courier/authmysqlrc wie folgt:

MYSQL_SERVER localhost
MYSQL_USERNAME provider_admin
MYSQL_PASSWORD ...
MYSQL_PORT 0
MYSQL_DATABASE provider
MYSQL_USER_TABLE users
#MYSQL_CRYPT_PWFIELD (comment this out)
MYSQL_CLEAR_PWFIELD password
MYSQL_UID_FIELD 5000
MYSQL_GID_FIELD 5000
MYSQL_LOGIN_FIELD email
MYSQL_HOME_FIELD "/home/vmail"
#MYSQL_NAME_FIELD (comment this out)
MYSQL_MAILDIR_FIELD CONCAT(SUBSTRING_INDEX(email,'@',-1),'/',SUBSTRING_INDEX(email,'@',1),'/')

Und seien Sie hierbei bitte sorgfältig - authmysqlrc ist ein bißchen empfindlich. Am Zeilenende auch bitte keine überflüssigen SPACEs (wenn sie mit vim arbeiten, wird ihnen :%s/\s\+$//g helfen). Dann starten wir den authdaemon noch neu: /etc/init.d/courier-authdaemon restart.

Nochmal kurz testen...

Versuchen Sie mal, an POP3 ranzukommen: führen Sie telnet localhost pop3 aus. Hier sollten Sie jetzt mit "+OK Hello there." belohnt werden. Voila - jetzt haben Sie glückliche Benutzer. :)

[Important]
eMails können Sie erst dann abholen, wenn mindestens eine eMail an diesen Benutzer gesendet wurde - sonst bekommt der Benutzer irgendwelche kryptischen Fehlermeldungen. Der Trick: schicken Sie neuen Benutzern einfach eine Willkommensnachricht.

Schritt 9: Ein wenig ausgiebiger testen...

Herzlichen Glückwunsch: die Konfiguration ist fertig! Kommen wir zum praktischen Teil: jetzt müssen wir Einträge in der Datenbank für Ihre erste Domäne anlegen, so dass Sie den Empfang von eMails für diese virtuelle Domäne testen können. Legen Sie also bitte folgende Zeilen in Ihren Tabellen an:

domains

SpalteEintrag
domainvirtual.test

users

SpalteEintrag
emailuser@virtual.test
passwordsecret

Um das ganze mit MySQL zu sagen:

INSERT INTO `domains` (`domain`) VALUES ('virtual.test');
INSERT INTO `users` (`email`,`password`) VALUES ('user@virtual.test','secret');

Etwas prosaischer betrachtet bedeutet das: Es gibt eine Domäne "virtual.test" und einen Benutzer, dessen eMail-Adresse und Benutzername "user@virtual.test" sind. Das Paßwort für diesen Benutzer lautet "secret". In Anbetracht der Tatsache, dass es für diese Domäne keinen MX-Eintrag im DNS gibt, müssen Sie die eMail von Hand zustellen. Starten Sie also eine SMTP-Verbindung zu Ihrem Mail-Server (telnet servername 25) und führen Sie die SMTP-Kommandos auf der rechten Seite aus:

Der ServerUnd Sie
220 myserver ESMTP Postfix (Debian/GNU)
	      
 
 
ehlo workaround.org
	      
250-mailtest
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN DIGEST-MD5 CRAM-MD5
250-AUTH=LOGIN PLAIN DIGEST-MD5 CRAM-MD5
250 8BITMIME
	      
 
 
mail from:<test@workaround.org>
	      
250 Ok
	      
 
 
rcpt to:<user@virtual.test>
	      
250 Ok
	      
 
 
data
	      
354 End data with <CR><LF>.<CR><LF></LF></CR></LF></CR>
					    
 
 
Dies ist eine Test eMail.
.
					    
250 Ok: queued as ABC1D1C123
					    
 
 
quit
					    
221 BYE
					    
 

Wenn der Server so wie oben beschrieben geantwortet hat, dann hat er zumindest Ihre eMail akzeptiert. In der Logdatei /var/log/mail.log sollten Sie einen etwa so aussehenden Abschnitt finden:

Jul 24 21:48:28 myserver postfix/smtpd[9119]: connect from myserver[127.0.0.1]
Jul 24 21:48:48 myserver postfix/smtpd[9119]: F2C1B47BD: client=myserver[127.0.0.1]
Jul 24 21:48:52 myserver postfix/cleanup[9144]: F2C1B47BD: message-id=<20040724194842.F2C1B47BD@myserver>
Jul 24 21:48:52 myserver postfix/qmgr[9117]: F2C1B47BD: from=<test@workaround.org>, size=313, nrcpt=1 (queue active)
Jul 24 21:48:52 myserver postfix/virtual[9148]: F2C1B47BD: to=<user@virtual.test>, relay=virtual, delay=10, status=sent (delivered to maildir)

Wenn Sie "status=sent (delivered to maildir)" finden, dann wurde diese eMail sogar erfolgreich ausgeliefert. Wenn Sie find /home/vmail ausführen, um alle Verzeichnisse und Dateien in "/home/vmail" zu finden - sollte etwa so aussehen:

/home/vmail/virtual.test
/home/vmail/virtual.test/user
/home/vmail/virtual.test/user/tmp
/home/vmail/virtual.test/user/cur
/home/vmail/virtual.test/user/new
/home/vmail/virtual.test/user/new/1090001045.2704_0.myserver.workaround.org

Soweit alles so passiert, wie beschrieben? Hervorragend! Als letzten Test können Sie jetzt versuchen, diese eMail mit einem Mailprogramm via POP3 oder IMAP vom Server zu holen - je nachdem, was Sie eben anbieten. Der Benutzername ist immer identisch mit der eMail-Adresse ("user@virtual.test") und das Passwort ist "secret" - zumindest für diesen Benutzer.

Schritt 10: Wir füttern unsere Datenbank

Nachdem die ersten Tests jetzt erfolgreich waren, müssen Sie die Datenbank für Ihre eigenen Domänen und deren Benutzer einrichten. Dazu brauchen Sie folgende Einträge in Ihrer Datenbank:

Für jede neue Domäne...

Fügen Sie die Domäne zur 'domains'-Tabelle hinzu.

>Für jeden neuen Benutzer...

Eine neue Zeile in 'users' - da stehen eMail-Adresse und Passwort drin (Klartext).

Für jede neue Weiterleitung...

Eine neue Zeile in 'forwardings'. Hier stehen die ursprüngliche Adresse (also die Adresse, an die die eMail gesendet wurde) und der neue Empfänger (die Adresse, an die diese eMail weitergeleitet werden soll) drin. Sollten Sie mehrere Weiterleitungen pro Adresse haben, können Sie die Adressen alle durch Kommas getrennt hier einfügen. Kleiner Tip: hier werden auch lokale Adressen nachgeschlagen, so dass es sogar möglich ist, lokale Adressen (also eMail-Adressen der lokalen Domänen) umzuleiten.

Beispiele:

Ursprüngliche Ziel-AdresseNeue ZieladressenEffekt
postmaster@my.domainphilip@my.domain Leitet eMails für postmaster an philip weiter.
@my.domainjohn@my.domain Leitet alle eMails an Adressen in der Domäne my.domain an john weiter. Das wird nicht auf die Benutzer in der Tabelle `email` angewendet - wie zum Beispiel tina@my.domain. Wenn also spezifische Benutzereinträge für eine Domäne existieren, werden diese den eben beschriebenen Auffangadressen für diese Domäne immer vorgezogen werden.
@my.domain@another.domain Hiermit leiten Sie ganze Domänen um - jede eMail-Adresse in der my.domain Domäne wird an die selbe eMail-Adresse in der Domäne another.domain umgeleitet. julie@my.domain wird also an julie@another.domain weitergeleitet.
jesper@my.domaindilbert@my.domain,dilbert@gmail.com Hiermit leiten wir eMails an jesper@my.domain an die zwei Adressen auf der rechten Seite weiter. Beide Benutzer bekommen ein Kopie der eMail.

Eingehende eMail auf Viren untersuchen(optional)

AMaViS-Einführung

Die zwei ärgerlichsten Dinge im Zusammenhang mit eMails sind SPAM und Viren. Beides kann man glücklicherweise mit AMaViS (A Mail Virus Scanner) bekämpfen. AMaViS ist eine Schnittstelle zwischen Postfix, Spamassassin (bekannt für seine bayes'schen Filterfähigkeiten) und beliebigen Virenscannern (zum Beispiel dem frei erhältlichen ClamAV). Nur um Verwirrungen vorzubeugen: AMaViS enthält den Filter, aber beinhaltet keinen Virenscanner. Ich schlage vor, dass Sie ClamAV auch installieren. Der wird häufig aktualisiert und ist kostenlos.

Sie sollten schon amavisd-new und andere Werkzeuge installiert haben. Siehe auch: Installation der benötigten Pakete.

Einrichtung von AMaViS

Werfen Sie mal bitte einen Blick auf: /etc/amavis/amavisd.conf file. Folgende Optionen müssen wir bearbeiten:

OptionBedeutung
$mydomain = 'yourdomain.org'; Tragen Sie hier bitte Ihre Domänen ein. Auf diese Option wird oft Bezug genommen. Hier steckt dieser Eintrag. Wenn Sie keine lokalen Domänen verwenden, sollten Sie hier "localhost" eintragen.
@bypass_virus_checks_acl = qw( . ); Wenn diese Zeile auskommentiert ist (also mit einer Raute beginnt), sind Virenüberprüfungen aktiviert.
@bypass_spam_checks_acl = qw( . ); Wenn diese Zeile auskommentiert ist (also mit einer Raute beginnt), sind SPAM-Tests aktiviert.
@lookup_sql_dsn = ( [ 'DBI:mysql:provider', 'provider_admin', '...' ] ); Anhand dieser Information findet AMaViS heraus, wie es auf die Datenbank zugreifen kann, um auf die Domänen-Tabelle zuzugreigen. Vergessen Sie nicht, die '...' durch Ihr Paßwort für die Datenbank zu ersetzen. Siehe auch den nächsten Eintrag:
$sql_select_policy = 'SELECT "Y" as local FROM domains WHERE CONCAT("@",domain) IN (%k)'; AMaViS muß herausfinden können, welche Domänen von Ihrem System verwaltet werden. Also verraten wir ihm, wie es das festellen kann, damit es beim Prüfen einer eMail zwischen eingehenden und ausgehenden eMails unterscheiden kann. Ausgehende eMails werden nicht von AMaViS untersucht.
$final_virus_destiny = D_DISCARD; Normalerweise werden infizierte eMails einfach gebounced (blödes Wort - ganz ehrlich, aber wie sagt mans besser). Das führt dazu, daß an den angegebenen Absender eine Fehlermeldung zurück geschickt wird. Jedoch ist das normalerweise ein ganz armer Kerl - denn der kann normalerweise nichts für die Mail und wird somit ganz unschuldig mit Fehlermeldungen belästigt. Lassen Sie das. Werden sie den Kram lieber weg.
$final_banned_destiny = D_REJECT; Hier wird festgelegt, wie eMails mit verbotenen Anhangstypen behandelt werden sollen. Viele Anhänge vom Typ PIF, EXE, COM oder DOC sind infiziert. Später können Sie einstellen, welche MIME-Typen Sie nicht zustellen worden.
$final_spam_destiny = D_PASS; Und natürlich noch das, was mit als SPAM erkannten eMails passieren soll. Sie fragen sich vielleicht, warum ich diese eMails durchlasse. Viele meiner Benutzer wären nicht sehr glücklich, wenn alle Emails unter SPAM-Verdacht einfach entsorgt würden. So füge ich also nur ein Feld "X-Spam-Status" in die eMail ein - in jedem Fall - so dass meine Benutzer ihre eMail-Programme konfigurieren können, anhand des Inhaltes dieses Feldes bestimmte Dinge mit den eMails zu tun.
$sa_tag_level_deflt = -1000; AMaViS bewertet jede eMail mit einem "spam score". Normaler SPAM hat ein Level von 5-10. Wenn dieser score größer als diese Option ist, wird der eMail ein Feld hinzugefügt, in dem der score-Wert steht - da ich möchte, dass alle eMails dieses Feld bekommen, setze ich diesen Wert auf quasi negatives unendlich.
$sa_tag2_level_deflt = 5.0; Wenn der SPAM-score größer ist als dieser Wert ist, dann wird ein weiteres Feld zu dieser eMail hinzugefügt, mit dem die eMail als SPAM gekennzeichnet wird: "X-Spam-Status: Yes".
$sa_kill_level_deflt = 10; Wenn der SPAM-score einer eMail größer als dieser Wert ist, führt AMaViS die von Ihnen in $final_spam_destiny definierten Aktionen aus.
$sa_spam_subject_tag = '***SPAM*** '; Wenn Sie möchten, dass der Betreff der eMail modifiziert wird, wird dieser Ausdruck zum Betreff hinzugefügt.
@av_scanners = ( ... Mit dieser Option können Sie die Virenscanner benennen. Viele Virenscanner sind schon vorkonfiguriert und Sie brauchen nur noch die Raute am Zeilenbeginn zu entfernen. Außerdem können Sie natürlich weitere Kommandozeilen-Virenscanner hinzufügen. Für den Anfang schlage ich vor, dass Sie nur ClamAV aktivieren und alle anderen Virenscanner auskommentieren ( eine Raute am Zeilenanfang eintragen). Und wenn Sie sich jetzt fragen, warum clamav doppelt vorkommt: @av_scanners ist für die Daemon-Version (clamd) und @av_scanners_backup führt die Kommandozeilen-Version aus (clamscan).
$sa_local_tests_only = 0; Wenn Ihr eMail-Gateway nicht schon total überlastet ist, möchte ich Ihnen das durchführen von remote tests (verdammt, gib mir doch einer ne sinnvolle Übersetzung) ans Herz legen. Postfix kann nur prüfen, ob die IP-Adresse, von der eine eMail eingeliefert wurde, auf einer schwarzen Liste steht. SpamAssassin kann das auch für jeden Mailserver, den diese eMail passiert hat. Das erhöht die Chancen, Spam sinnvoll zu filtern, ungemein. Außerdem prüft SpamAssassin alle in der eMail aufgeführten URLs darauf, ob sie auf einer schwarzen Liste stehen. Und das alles für umsonst - also automatisch. WENN Sie sich nicht darauf beschränken, lokale Prüfungen durchzuführen.

Wenn Sie den Teufel von ClamAV (also den Daemon) verwenden möchten, dann müssen Sie den Benutzer clamav zur Gruppe amavis hinzufügen: "adduser clamav amavis". Vergessen Sie auf jeden Fall bitte nicht, amavis neu zu starten, nachdem Sie die Konfigurationsdatei geändert haben (/etc/init.d/amavisd restart).

Postfix mit AMaViS bekannt machen

Nachdem amavis jetzt gemütlich im Hintergrund vor sich hin arbeitet, müssen Sie Postfix noch erklären, dass es das Ding auch verwenden soll, um eMails zu prüfen. Fügen Sie also die Option content_filter in Form der folgenden Zeile in Ihrer /etc/postfix/main.cf ein:

content_filter = amavis:[127.0.0.1]:10024
receive_override_options = no_address_mappings

Diese content_filter-Option sorgt dafür, daß jede eMail an einen Dienst namens amavis übergeben wird. Noch geht das aber nicht - postfix hat noch nicht alles zum Thema amavis gelernt. Den Rest müssen wir ihm durch diese zwei Zeilen in /etc/postfix/master.cf beibringen:

amavis unix - - - - 2 smtp
    -o smtp_data_done_timeout=1200
    -o smtp_send_xforward_command=yes

127.0.0.1:10025 inet n - - - - smtpd
    -o content_filter=
    -o local_recipient_maps=
    -o relay_recipient_maps=
    -o smtpd_restriction_classes=
    -o smtpd_client_restrictions=
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o mynetworks=127.0.0.0/8
    -o strict_rfc821_envelopes=yes
    -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks

In der Vergangenheit wurde ein pre-cleanup-Dienst eingerichtet - und auch wenn die Dokumentation von AMaViS dies immer noch empfiehlt rate ich davon ab.

Schlussendlich führen Sie noch einmal postfix reload und postfix check aus, um sicher zu stellen, dass in Ihrer Postfix-Konfiguration keine Fehler stecken. Alle eingehenden eMails werden jetzt auf Viren und SPAM-Wahrscheinlichkeit geprüft. Für Details können Sie mal einen Blick in Ihre /var/log/mail.log werfen. Außerdem können Sie Ihren AMaViS auf die Probe stellen: werfen Sie mal einen Blick auf webmail.us/testvirus. Von da können Ihnen harmlose eMails mit einer EICAR-Virus-Test-Signatur gesendet werden.

Wie funktioniert der content_filter eigentlich?

Noch ein paar kurze Worte zur Arbeitsweise von AMaViS. Nachdem Postfix eine eMail empfangen hat, wirft es sie direkt weiter zu AMaViS - getreu der Einstellung in content_filter. Da die no_address_mappings-Option gesetzt ist, werden an dieser Stelle alle Aliase ignoriert. AMaViS schaut dann mal schnell nach (natürlich wird es das nur beim Start tun - aber stellen Sie es sich ruhig so vor), welche Virenscanner aktiviert sind und wird mit diesen die Anhänge der eMail auf Viren untersuchen. Wenn die Anhänge gepackt sind, werden die entsprechenden Programme zum entpacken verwendet. Außerdem wird es die eMail an Spamassassin verfüttern, der anhand seines Wissens überprüft, wie wahrscheinlich es ist, daß diese eMail Spam ist. Nachdem das alles passiert ist, wird die eMail zurück an Postfix gegeben - dieses Mal auf dem lokalen Port 10025. Jetzt sind die content_filter- und no_address_mappings-Optionen leer. Es werden also Aliase angewendet und die eMail wird zugestellt. Wären die Aliase schon vor der Übergabe an content_filter aktiviert, würden eMails doppelt zugestellt werden. Daher verwenden wir Aliase erst nach den Filtern.

Diese zwei Schritte kann man natürlich auch in /var/log/mail.log beobachten. Zunächst ein "relay=amavis" und danach ein "relay=virtual". Wenn alles tut, wie es soll, kann man in /var/log/mail.log folgende Zeile sehen:

amavis[677]: (00677-02) Passed, <my@test.address> -> <user@virtual.test>, Message-ID: <20040716231708.8717C1C21E@myserver>, Hits: -

Wenn eine infizierte eMail eingeliefert wird (siehe auch eicar.org für einen harmlosen Test) finden Sie Folgendes in /var/log/mail.log:

amavis[11843]: (11843-01) INFECTED (Eicar-Test-Signature), <user@domain1> -> <user@domain2>...

Und jetzt noch ein bißchen Trainig für SpamAssassin

Um AMaViS ein bißchen effizienter als dieses langweilige Out-of-the-Box-Verhalten zu machen, müssen Sie den Teil, der für den Spam zuständig ist - also SpamAssassin - trainieren. Da jeder so seine eigenen Vorstellungen davon hat, was Spam ist und was nicht, und SpamAssassin bayes'sches Filtern betreibt, müssen Sie ihm also einige hundert eMails Spam und einige hundert eMails Ham (also nicht-Spam) zum Traning vorsetzen:

Nur eine kurze Randbemerkung: es ist wohl irgendwie auch möglich, Informationen bzgl. Spam/Ham für jeden virtuellen Benutzer individuell zu speichern. Allerdings hat mich die Dokumentation von AMaViS an dieser Stelle etwas verwirrt - wenn mich also jemand erleuchten will, ist er/sie herzlich Willkommen.

Die eigentlich einzige Herausforderung an dieser Stelle ist die Tatsache, dass man ausreichende Berechtigungen braucht, um sowohl die eMails der Benutzer zu lesen, als auch die hieraus gewonnenen Informationen für den Benutzer 'amavis' ablegen zu können. Daher führe ich das als einen cronjob des Benutzers root aus.

Lösung: schreiben Sie sich ein kleines Script, das bestimmte Ordner, die Spam-eMails beinhalten, ausliest und starten Sie es als cronjob von root (crontab -e als Benutzer root). Folgendes kleine Script habe ich mir dafür geschrieben und in /usr/local/bin/spamlearner abgelegt:

#!/bin/bash -e

SADIR=/var/lib/amavis/.spamassassin
DBPATH=/var/lib/amavis/.spamassassin/bayes
SPAMFOLDERS="\
/home/vmail/well-known-customer.com/fred/.spam/cur \
/home/vmail/spamtrap.org/jeanne/.spam/cur \
"
HAMFOLDERS="\
/home/vmail/spamtrap.org/jeanne/.trash/cur \
"

for spamfolder in $SPAMFOLDERS ; do \
echo Learning spam from $spamfolder ; \
nice sa-learn --spam --showdots --dbpath $DBPATH $spamfolder
done

for hamfolder in $HAMFOLDERS ; do \
echo Learning ham from $hamfolder ; \
nice sa-learn --ham --showdots --dbpath $DBPATH $hamfolder
done

chown -R amavis:amavis $SADIR

Um sich jetzt anzuschauen, was sich SpamAssassin von AMaViS jetzt so als Spam oder auch Ham gemerkt hat, können Sie einfach das Kommando sa-learn --dbpath /var/lib/amavis/.spamassassin/bayes --dump magic ausführen.

Vorsicht: auf diese Weise trainieren Sie die für AMaViS globale Datenbank für Spam und Ham - das heißt, dieses Wissen wird auf alle auf Ihrem System eingehenden eMails angewendet. Stellen Sie also sicher, dass die eMails, aus denen Sie lernen, auch tatsächlich entsprechend eines "common-sense" Spam sind, und nicht irgendein Benutzer aus Frust eMails seiner Ex-Freundin als Spam eingibt. Vielleicht ist der neue Freund dieser Dame ebenso Benutzer Ihres Systems und findet ganz und gar nicht, dass Mails von Ihr Spam sind.

Und nochmal: Weitergeleitete eMails als Grundlage für Spam-Training zu nehmen ist keine gute Idee - immerhin gehen beim Weiterleiten Informationen aus dem eMail-Header verloren. Und die findet SpamAssassin aber immanent wichtig.

Webmail einrichten und anbieten

Nachdem Sie jetzt schon wissen, wie Ihre Benutzer ihre eMails via POP3, IMAP und SMTP bearbeiten können, fragen Sie sich vielleicht, ob es auch noch eine Möglichkeit gibt, einen Webmail-Zugang zur Verfügung zu stellen. Das ist ziemlich einfach - Sie müssen nur das Paket "squirrelmail" installieren, ein Webmail-System für beliebige IMAP-Server, zum Beispiel den "Courier IMAP", den wir hier verwenden. Führen Sie also apt-get install squirrelmail aus. Damit das ganze dann auch von unserem Indianer - also dem Apache gefunden wird - müssen wir zunächst die Konfigurationsdatei an die entsprechende Stelle bringen:

ln -s /etc/squirrelmail/apache.conf /etc/apache2/conf.d/squirrelmail.conf

Führen Sie nun squirrelmail-configure aus, um die Grundeinstellungen von squirrelmail zu editieren. Allerdings sollten bis jetzt die Standards für Ihren Bedarf ausreichend sein, alles weitere können Sie jederzeit zu einem späteren Zeitpunkt noch editieren.

Wenn Sie jetzt auf Ihren Webserver mit http://hostname/squirrelmail (beispielsweise) zugreifen, sollten Sie eine Login-Seite sehen. Wie sonst auch: verwenden Sie die eMail-Adresse als Benutzernamen und das passende Passwort aus der `users`-Tabelle. Squirrelmail unterhält sich dann munter mit dem lokalen - also localhost - IMAP-Mailserver um Ihre E-Mails darzustellen.

Mailing listen mit Mailman

Eine Frage, die oft gestellt wird: "Und wie ist das mit Mailing Listen und virtuellen Domänen?" Eigentlich ist das ganz einfach - und davon gibts auch noch drei Geschmacksrichtungen.

Mailinglisten mit Pipes

Hierfür müssen Sie sich nur damit abfinden, dass virtuelle Benutzer keine Aliase mit Pipes haben können. (Pipen bedeutet soviel wie: die Ausgabe auf STDOUT von Programm 1 wird auf STDIN für Programm 2 gelegt. Sinnlosestes Beispiel: cat /etc/aliases|less gibt die Ausgabe von cat als Eingabe an less weiter.)

Pipes...wie? Wenn Sie mal eine Mailing-Liste mit 'newlist' angelegt haben, wissen Sie, dass Mailman will, dass Sie bestimmte Aliase zu /etc/aliases hinzufügen - sowas wie chitchat-admin, chitchat-bounces, chitchat-join usw. Deren Ziele sind dann sowas wie "|/var/lib/mailman/mail/mailman post powerdns-debian". Das bedeutet nichts anderes, als dass die eMail dann über eine Pipe an das Programm Mailman - also das Kommando mailman übergeben wird - mailman liest die eMail als Eingabe.

Das geht solange gut, solange die Domänen lokale Domänen sind - sobald sie jedoch eine Pipe für einen virtuellen Alias verwenden, wird es schief gehen. Das scheitert daran, dass Sie keine System-Benutzerkennung haben, die "Besitzer" dieser Pipe sein könnte. Der Umweg hierfür führt - wie sollte es anders sein - über eine Weiterleitung eines virtuellen Aliases auf einen lokalen Alias - also eine lokale eMail-Adresse und einen lokalen "Benutzer", wofür dann eine Pipe verwendet werden kann.

Ich möchte Ihnen empfehlen, dass Sie 'localhost' als lokale Domäne verwenden (mydestination = localhost) und jeden Maillman-Alias an den entsprechenden Alias @localhost weiterleiten. Im Beispiel: wenn Sie also chitchat-subscribe@virtual.domain haben, leiten Sie es weiter an chitchat-subscribe@localhost weiter. Hierfür verwenden Sie ja sowieso /etc/aliases und können daher das, was mailman von Ihnen erwartet, erfüllen. Aber vielleicht gibt es ja auch jemanden, der eine clevere Lösung dafür hat, /etc/aliases auch noch in MySQL unterzubringen. Dann aber immer her mit der Lösung.... :-)

Generischer Ansatz mit regulären Ausdrücken

Hierfür brauchen Sie für jede virtuelle Domäne, in der Sie Mailinglisten einsetzen wollen einen zusätzlichen Rechnernamen - belohnt werden Sie mit einem relativ einfachen Setup. Nehmen wir als Domänennamen einfach mal domain.com an. Der Rechnername, den Sie nehmen müßten, könnte zum Beispiel lists.domain.com sein. Das wäre dann Ihr Server für Mailinglisten. Für weitere Informationen: http://listes.rezo.net/how.php.

Ein Transportdienst (transport service) für Mailman...

Der dritte und vorläufig letzte Weg ist, einen sogenannten transport für Mailman einzurichten. Transport? Ja. Das sind diese komischen Dinger in /etc/postfix/master.cf. Genaueres hierzu finden Sie in: /etc/mailman/postfix-to-mailman.py im Abschnitt INSTALLATION.

Fehlersuche

Fehlermeldungen

LogdateiFehlermeldungBedeutung
/var/log/mail.log postfix/smtpd[11960]: NOQUEUE: reject: RCPT from myserver[10.20.30.40]: 550 <nonexisting@virtual.test>: Recipient address rejected: User unknown in virtual mailbox table; from=<user@domain> to=<nonexisting@virtual.test> ...to=<user2@my.testdomain>, relay=none, delay=0, status=bounced (unknown user: "user2@my.testdomain") Postfix weiß zwar, dass my.testdomain eine virtuelle Domäne ist, kann aber den Benutzer "user2@my.testdomain" nicht in der Tabelle 'users' finden.
/var/log/mail.log ...warning: connect to mysql server mailtest: Access denied for user: 'service@myserver' (Using password: YES) Postfix hat probiert, auf die MySQL-Datenbank mit dem Benutzer service@myserver zuzugreifen. MySQL hat aber diese Kombination aus Benutzername und Paßwort abgelehnt.
/var/log/mail.log Clam Antivirus-clamd FAILED - unknown status: var/lib/amavis/amavis-20050925T193330-15533/parts: Access denied. ERROR Der Benutzer clamav muß der Gruppe amavis hinzugefügt werden. Benutzen Sie hierzu folgendes Kommando: adduser clamav amavis
Ergebnis von postfix check postfix/postfix-script: warning: /var/spool/postfix/etc/hosts and /etc/hosts differ Eine Datei in ihrem chroot für Postfix /var/spool/postfix/etc unterscheidet sich von ihrem Pendant in /etc. Starten Sie Postfix einfach neu, die Dateien werden dann kopiert.
/var/log/mail.log ...warning: connect to mysql server mailtest: Access denied for user 'provider_admin'@'localhost.localdomain' (using password: YES) Das deutet darauf hin, daß sie einen Eintrag localhost.localdomain in Ihrer /etc/hosts-Datei haben. Löschen Sie ihn. (Anmerkung: Auf der Mailinglist debian-devel wurde dieses auch thematisiert und festgehalten, daß localhost.localdomain durchaus auch richtig ist. Sie können in MySQL also wahlweise Rechte für localhost als auch für localhost.localdomain vergeben. MySQL 5.0 wird es richtig interpretieren.

MySQL-Fehlersuche

In manchen Fällen kann es passieren, dass Postfix noch nicht einmal auf die Datenbank zugreifen kann. Wenn Sie vermuten, dass bei Ihnen ein solcher Fall aufgetreten ist, sollten Sie einen Blick auf /var/log/mysql/mysql.log werfen - diese Datei enthält alle Anfragen an Ihre Datenbanken.

Hilfe im IRC

Eine Menge cleverer Benutzer kann man im IRC in #postfix und (noch) einige wenige in #postfix-de(deutschsprachig) in freenode.net finden. Sie sind herzlich dazu eingeladen, sich dazu zu gesellen. Signum ist der Autor dieses Dokuments. Der deutsche Übersetzer ist sirio (Patrick Jäger). Bitte schicken Sie mir keine privaten Nachrichten - kommen Sie einfach in den channel und stellen Sie ihre Frage - so präzise wie möglich. Und: obwohl ich außerordentlich positiv überrascht bin, wieviele Menschen dieses Tutorial verwenden - ich kann keinerlei Reaktionszeiten garantieren, wenn Sie mir eine eMail schicken.

Wir kommen von einer alten Version dieses Tutorials...

Vielleicht haben Sie schon mit einer alten Version dieses Tutorials gearbeitet und möchten jetzt aktualisieren. Zur letzten Version geändert haben sich nur die Verzeichnisse. Tun Sie also folgendes:

  • Verschieben Sie Ihre Verzeichnisse für eMails, so dass aus /home/vmail/user@domain /home/vmail/domain/user wird. Skripte, die Ihnen diese Aufgabe abnehmen, finden Sie auf der Seite mit Ergänzungen .

E-Mails beim Zustellen mit Hilfe von Maildrop filtern

Eine Frage, die ich mittlerweile schon erahne, auch wenn sie sich nur anschleicht, bezieht sich auf die Filterung der E-Mails durch den Mailserver selbst. Viele E-Mail-Dienste bieten an, mögliche SPAM-E-Mails automatisch in einen anderen Ordner einsortieren zu lassen. Manch einer von Ihnen kennt wahrscheinlich sogar 'procmail' als außerordentlich praktischen und angenehmen Helfer, um E-Mails für lokale Benutzerkonten zu sortieren. Traurig aber wahr: das funktioniert leider nicht mit virtuellen E-Mail-Konten. Wie mir scheint, verwenden die meisten Administratoren für diesen Zweck 'maildrop' - Bestandteil von Courier und mittlerweile sogar tatsächlich auch in Debian verfügbar. Soviel zur Sonnenseite. Jetzt zum Schatten: das in Debian verfügbare Paket versteht sich leider nicht mit MySQL - was es aber müßte, um sich schlau zu machen, welche E-Mail wohin kommt. Denn 'maildrop' übernimmt die Aufgabe von 'virtual' - das ist das kleine Teufelchen, das in unserem Setup die E-Mails zustellt. Wenn Sie sich sicher sind, daß Sie das tatsächlich haben wollen, dann sollten Sie mal bei Jasper Slits' Seite vorbeischauen - er hat eine Anleitung geschrieben, wie man maildrop so kompiliert, daß es MySQL unterstützt. Außerdem unterstützt dieses dann auch E-Mail-Quotas.

Aber wenn Sie meine ganz persönliche Meinung dazu hören wollen: vergessen Sies! Außer daß es quasi nicht möglich ist, die Fehler zu beheben, ist es außerdem noch mehr ein schmutziger Hack als eine vernünftige Lösung. Denn die Warnungen, die in Ihren Log-Dateien auftauchen, sind eigentlich interne 'Segmentation Faults' von maildrop... Traurigerweise gibts es meines Wissens jedoch keine andere brauchbare Lösung.

Wenn Sie jetzt immer noch darauf aus sind, maildrop probieren zu wollen, mag es sie trösten, daß das nächste stabile Release von Debian(Etch) eine neue Version von 'maildrop' enthält, die Couriers authlib-Bibliothek verwendet, so daß Sie nichts weiter kompilieren müssen.

Danksagungen

Eine Menge Menschen haben mir Vorschläge gemailt. Ich möchte mich bei den folgenden Personen für ihre wertvollen Ergänzungen zu diesem Tutorial bedanken:

  • Alexander Stielau
  • Christian Garling
  • Christian Kurz
  • Christof Gruber
  • Daniel Hackenberg
  • Daniel Wladow
  • Eicke Kemm
  • Jesper Krogh
  • Jon Cox
  • Kay-Michael Voit
  • Lucas Baltes
  • Mario Duve
  • Mikael Tokarev
  • Patrick Blitz
  • Patrick Jäger
  • Pete Boyd
  • Thomas "Balu" Walter
  • Tim Weippert
  • Ricardo Arguello
  • Simon Kammerer

Herzliche Grüße an die kompetenten und freundlichen Personen in #postfix im freenode.net und natürlich an meine Frau. Sie hat eine Menge Geduld mit mir gehabt. Wenn Sie dieses Dokument übersetzen wollen, melden Sie sich bitte bei mir. Diese Dokument steht für Übersetzungen im Docbook-XML-Format zur Verfügung.

Worauf Sie gespannt sein dürfen... Etch!

  • MySQL-Zugriff über einen Socket - mit einem cleveren bind-mount über /etc/fstab - sind wir nicht geschickt?
  • Umstellung auf verschlüsselte Paßwörter - hatten wir schon mal, ich weiß - ist aber irgendwie sicherer. (courier-authdaemon mit der "-r imap"-Option)
  • Ein hübsches Webinterface zum verWALDen der Benutzer ;)
  • Ein sinnvolle(!) und durchdachte (wiederhole ich mich?) Lösung für Urlaubs- benachrichtigungen und automatische Antworten.

Ergänzungen von Lesern und Anwendern

Viele Benutzer haben kontinuierlich dabei geholfen, diese Anleitung zu verbessern, einige haben komplette Skripte oder Verweise zu weiterer Dokumentation oder Software eingeschickt. Da sich dabei aber so viel verändert, habe ich hierfür eine eigene Seite eingerichtet.

Herzlichen Dank auch an alle Leser und Benutzer, die soviel Rückmeldung geschickt haben - sowohl technischer als auch emotionaler Natur :-) Für die Neugierigen unter Ihnen: vielleicht möchten Sie wissen, was andere Personen hierüber denken.

Last change: Thursday, 12-Jul-2007 20:32:24 CEST / 66640 hits since 22.7.2005