35.3Verwaltung der Postfix-Mail-Konten
Grundsätzlich gilt für Postfix: Jeder reguläre Benutzer in /etc/passwd ist auch ein Mail-User. Für diese Benutzer bedarf es keiner zusätzlichen Konfiguration. Jeder dieser Linux-Benutzer kann E-Mails senden und empfangen.
Externe Mail-Clients wie Thunderbird müssen sich bei Postfix bzw. Dovecot authentifizieren. Für diese Authentifizierung kommen ebenfalls die regulären Linux-Passwörter zum Einsatz. (Das ist ein großer Unterschied zu Samba: Dieser Datei-Server verwaltet für jeden Samba-User getrennte Passwörter.)
Sicherheitsrisiko Mail-Passwort
So bequem es ist, dass Linux- und Mail-User standardmäßig parallel laufen, so riskant kann dies auch sein. Nun wird vermutlich niemand so unvernünftig sein, root als regulären E-Mail-Account zu verwenden (also root@firma-abc.de) – das würde nämlich erfordern, bei der Konfiguration des Mail-Clients das root-Passwort anzugeben.
Viel eher wird das Risiko des folgenden Szenarios übersehen: Als Administrator des Servers firma-abc.de haben Sie dort einen Account mit sudo-Rechten – z.B. huber. Für Administrationsarbeiten loggen Sie sich mit ssh huber@firma-abc.de ein, führen dann sudo -s aus und erledigen, was eben gerade zu tun ist. So weit, so gut.
Nach der Konfiguration des Mail-Servers ist es natürlich naheliegend, den Mail-Account huber@firma-abc.de zu verwenden. Wie vorhin erläutert, sind dafür keine weiteren Konfigurationsarbeiten notwendig. Das Problem besteht darin, dass Sie nun Ihr huber-Passwort einmal bei der Konfiguration von Thunderbird auf Ihrem Linux-Notebook eingeben: einmal bei der Konfiguration Ihres Mail-Programms auf dem Smartphone, noch einmal für das Tablet etc. Geht eines dieser Geräte verloren, ist es mit etwas IT-Wissen nicht allzu schwer, das gespeicherte Passwort zu huber zu finden. Und dieses Passwort reicht nicht nur aus, um Ihre E-Mails zu lesen bzw. in Ihrem Namen zu versenden – der unehrliche Finder kann sich nun ebenfalls mit ssh auf firma.abc-de einloggen und hat dort dank sudo uneingeschränkte Rechte. Sicherheitstechnisch ist das das Schlimmste, was passieren kann.
Abhilfe: Verwenden Sie nie Mail-Accounts von Benutzern mit sudo-Rechten! Verwenden Sie getrennte Accounts für E-Mails und für Administratorarbeiten, auch wenn dies unbequem ist.
Die oben skizzierte Parallelschaltung von Linux- und Mail-Accounts entspricht der Defaultkonfiguration, aber dabei wird es selten bleiben. In den folgenden Abschnitten erläutere ich Ihnen einige Möglichkeiten für eine davon abweichende Konfiguration:
-
Mail-Aliase ermöglichen es, E-Mails auf vorhandene Accounts umzuleiten.
-
Mit der Konfiguration einer expliziten Empfängerliste können Sie die Liste der E-Mail-Accounts steuern und z.B. verhindern, dass System-Accounts wie adm oder lp E-Mails senden oder empfangen können.
-
Mit virtuellen Domänen können Sie mit einem Postfix-Server E-Mails verschiedener Hostnamen verarbeiten (nicht nur für firma-abc.de, sondern auch für firma-xy.info).
-
Mit virtuellen Postfächern können Sie Mail-Accounts und deren Passwörter vollkommen von den Linux-Accounts trennen. Die Login-Daten werden dann oft in einer Datenbank gespeichert.
Vorweg beschäftigt sich der folgenden Abschnitt aber mit der Frage, wo E-Mails eigentlich gespeichert werden.
mbox- oder Maildir-Format
Standardmäßig speichert Postfix eintreffende E-Mails im mbox-Format in der Datei /var/mail/name. Wenn E-Mails stattdessen in einer lokalen Datei im Benutzerverzeichnis gespeichert werden sollen (weiterhin im mbox-Format), geben Sie den gewünschten Dateinamen relativ zum Homeverzeichnis mit home_mailbox an:
Wenn Sie vorhaben, die Mails überwiegend via IMAP abzurufen, sollten Sie das Maildir-Format vorziehen. Die korrekte Einstellung von home_mailbox sieht nun so aus:
Der Verzeichnisname muss mit / enden, damit Postfix das Maildir-Format verwendet. Falls main.cf eine mailbox_command-Anweisung enthält, müssen Sie diese auskommentieren. Neu eintreffende E-Mails werden nun in eigenen Dateien im Verzeichnis /home/name/Maildir gespeichert.
Vergessen Sie nicht, auch Ihrem lokalen Mail-Client bzw. Dovecot den Ort und das Format Ihres Postfachs mitzuteilen (siehe Abschnitt 35.4, »Dovecot (POP- und IMAP-Server)«)! Wenn Sie mutt einsetzen, müssen Sie das Programm entsprechend konfigurieren, damit es die E-Mails aus dem Maildir-Verzeichnis liest (siehe Abschnitt 6.9, »Mutt«).
Mail-Aliase
Ein Mail-Alias ist ein zusätzlicher Mail-Name zum Empfang von E-Mail. Die E-Mail wird aber tatsächlich an einen bereits vorhandenen Account weitergeleitet. Aliase werden in der Datei /etc/aliases definiert. Diese Datei sieht üblicherweise so ähnlich wie das folgende Muster aus:
Die erste Spalte gibt den Alias-Namen ohne Domäne an. Der Name gilt für die in myhostname definierte Domäne, also beispielsweise postmaster@firma-abc.de. Die zweite Spalte enthält den lokalen Empfänger. Im obigen Beispiel werden an postmaster adressierte E-Mails an root weitergeleitet, E-Mails an webmaster und an Bernhard.Huber an huber. Es ist zulässig, in /etc/aliases für jeden Alias mehrere, durch Kommas getrennte Empfänger anzugeben.
Als Empfänger können Sie statt eines lokalen E-Mail-Account-Namens auch eine externe E-Mail-Adresse angeben oder eine Datei, an die die E-Mail angefügt wird, oder ein Programm in der Schreibweise |kommando, an das die E-Mail weitergegeben wird. Das Weiterleiten an externe E-Mail-Adressen funktioniert zwar problemlos, scheitert in der Praxis aber oft am Spam-Schutz des Ziel-MTAs. Wenn Sie also beispielsweise E-Mails an webmaster an name@gmx.de weiterleiten, erkennt der Spam-Filter von GMX, dass die E-Mail nicht direkt an gmx.de übertragen wurde, sondern indirekt über firma-abc.de. Das reicht für einen misstrauischen Spam-Filter, um die E-Mail als Spam zu klassifizieren.
Damit geänderte Aliase wirksam werden, müssen Sie das Kommando newaliases ausführen. Dieses Kommando synchronisiert die Textdatei /etc/aliases mit der BDB-Datei /etc/aliases.db.
In /etc/postfix/main.cf stoßen Sie in der Regel auf zwei alias-Optionen, was bisweilen Verwirrung stiftet:
alias_database gibt an, welche Datenbankdatei durch das Kommando newaliases aktualisiert werden soll. Die hier angegebene Datei (deren Name durch .db ergänzt wird) enthält die in /etc/aliases angegebenen Aliase in einem binären Format.
alias_maps gibt an, welche Alias-Datenbanken Postfix berücksichtigen soll. Normalerweise geben Sie hier dieselbe Datei an wie bei alias_database. Es ist aber zulässig, darüber hinaus weitere Quellen für Alias-Definitionen anzugeben. Der entscheidende Unterschied zwischen den beiden Parametern besteht darin, dass alias_database für newaliases gilt, alias_maps dagegen für Postfix!
Auch als lokaler Benutzer, der keinen Zugriff auf /etc/aliases hat, können Sie Ihre E-Mail an eine andere Adresse umleiten: Dazu erzeugen Sie die Datei .forward und speichern darin die neue Zieladresse. Fertig!
Wie ich oben bereits erwähnt habe, funktioniert diese simple Form der E-Mail-Umleitung zumeist nur bei lokalen Adressen wunschgemäß. Bei externen Zieladressen kann es dagegen passieren, dass sich die umgeleiteten E-Mails im Spam-Schutz des Ziel-MTAs verfangen.
Explizite Empfängerliste
Standardmäßig kann jeder Linux-Account E-Mails empfangen. Es ist aber selten wünschenswert, dass System-Accounts wie daemon, sys oder man E-Mails erhalten. Um diesen Missstand zu beheben, müssen Sie am Parameter local_recipient_maps drehen. Die Standardeinstellung lautet:
Das bedeutet, dass alle in der Unix-Datei /etc/passwd aufgezählten Benutzer sowie alle in den Alias-Datenbanken genannten Benutzer E-Mails empfangen können. Wenn Sie möchten, dass nur fischer, huber, schmidt sowie root (für System-Benachrichtigungen) E-Mails empfangen sollen, gehen Sie wie folgt vor: Zuerst erzeugen Sie eine Textdatei, die zeilenweise die Account-Namen enthält. Die Datei muss in einer zweiten Spalte einen beliebigen Wert enthalten, weil Postfix und das Kommando postmap generell Schlüssel/Wert-Paare (Key/Value Pairs) erwarten – auch bei Listen, bei denen eigentlich nur die Existenz eines Schlüssels relevant ist, der dazugehörige Wert aber gar nicht berücksichtigt wird.
Aus dieser Datei erstellen Sie nun mit postmap eine für Postfix lesbare Datenbankdatei local-recips.db:
Mit postmap -s können Sie überprüfen, dass die Datei korrekt erstellt wurde:
Anschließend fügen Sie in /etc/postfix/main.cf eine Zeile zur Einstellung von local_recipient_maps ein:
Mapping-Dateien ganz sicher aktualisieren
Nach jeder Änderung an local-recips müssen Sie postmap ausführen, um die für Postfix relevante Datenbankdatei local-recips.db zu aktualisieren. Diese Akualisierung ist allerdings ein kritischer Vorgang: postmap löscht dabei local-recips.db und schreibt die Datei anschließend neu. Wenn Postfix gerade während dieses Zeitpunkts auf local-recips.db zugreift, erhält es falsche bzw. unvollständige Daten.
Eine sichere Vorgehensweise sieht deswegen so aus: Sie geben der zugrunde liegenden Textdatei einen anderen Namen (z.B. local-recips1), wenden postmap auf diese Datei an und führen dann mv local-recips1.db local-recips.db aus. Somit enthält local-recips.db zu jedem Zeitpunkt konsistente Daten – entweder in der alten oder in der neuen Version. Diesen Vorgang können Sie durch eine Script- oder make-Datei automatisieren, wie es hier beschrieben ist:
http://www.postfix.org/DATABASE_README.html#safe_db
Dieser Hinweis gilt für alle in diesem Kapitel vorkommenden Mapping-Dateien.
Von nun an akzeptiert Postfix nur noch E-Mails an die in local-recips genannten Empfänger. Es gibt allerdings noch eine Einschränkung: Es werden nur dann E-Mails zugestellt (also lokal gespeichert), wenn der Benutzer einen Account auf dem Rechner hat. Ist das nicht der Fall, müssen Sie mit adduser einen neuen Account erstellen.
Im folgenden Beispiel bewirkt die Option --shell /bin/false, dass dem Account statt einer Shell das Programm /bin/false zugeordnet ist. Das macht ein interaktives Arbeiten unmöglich. --gecos ,,, unterdrückt die Fragen nach dem vollständigen Namen und weiteren überflüssigen Kontaktinformationen. Wichtig ist hingegen das Passwort, und das, obwohl sich der Benutzer gar nicht einloggen kann. Der Grund: Das Passwort gilt für die in Abschnitt 35.4, »Dovecot (POP- und IMAP-Server)«, beschriebene POP- und SMTP-Authentifizierung.
Tipp
Sichere Passwörter können Sie komfortabel mit pwgen, makepasswd (Debian, Ubuntu) oder mkpasswd (Fedora, RHEL, Paket expect) erzeugen.
Wenn Sie mit virtuellen Domänen arbeiten (siehe den übernächsten Abschnitt), können Sie darauf verzichten, für jeden Benutzer einen eigenen Linux-Account einzurichten. Postfix unterstützt dann sogenannte virtuelle Postfächer, die ganz real sind, aber keinem gültigen Benutzernamen entsprechen.
Vom Linux-Account abweichende E-Mail-Adressen
In vielen Firmen sind E-Mail-Adressen der Form Vorname.Nachname@firma.de üblich. Linux sieht jedoch derart lange Benutzernamen – noch dazu mit einem Punkt – nicht vor. Das hindert Sie aber nicht daran, dennoch lange E-Mail-Namen zu verwenden:
-
Legen Sie einen Linux-Account mit einem Linux-typischen, kurzen Benutzernamen an, z.B. huber.
-
Definieren Sie eine Alias-Regel, die E-Mails an Bernhard.Huber an huber weiterleitet.
-
Verwenden Sie bei der Konfiguration des E-Mail-Clients als Absenderadresse die Langform, also Bernhard.Huber@firma-abc.de. Beachten Sie aber, dass Sie zur POP-, IMAP- und SMTP-Authentifizierung den Linux-Account-Namen angeben müssen!
-
Damit auch lokal (z.B. durch mutt) versandte E-Mails die richtige Absenderadresse in der Langform enthalten, richten Sie eine neue Tabelle in der Textdatei /etc/postfix/canonical ein. Diese Tabelle gibt an, wie Postfix E-Mail-Adressen verändern soll:
# /etc/postfix/canonical huber Bernhard.Huber@firma-abc.de ...Diese Tabelle wandeln Sie mit postmap in eine für Postfix lesbare Tabelle um.
-
Anschließend stellen Sie in main.cf den Parameter canonical_maps ein und führen dann service postfix reload aus.
# in /etc/postfix/main.cf ... canonical_maps = hash:/etc/postfix/canonical
Neben den Canonical- und Alias-Tabellen bietet Postfix diverse weitere Möglichkeiten, um E-Mail-Adressen in verschiedenen Phasen des E-Mail-Verkehrs zu manipulieren, also beim Empfang, vor dem Versenden etc. Einen guten Überblick gibt die folgende Seite:
http://www.postfix.org/ADDRESS_REWRITING_README.html
Virtuelle Domänen mit gemeinsamen E-Mail-Benutzern
Im einfachsten Fall ist Postfix nur für E-Mails an den Hostnamen des Rechners zuständig, z.B. xxx@firma-abc.de. Oft ist es aber wünschenswert, dass ein MTA für mehrere E-Mail-Domänen zuständig ist, also xxx@noch-eine-firma.de. Alle Domänen, die nicht mit dem Hostnamen des Rechners übereinstimmen, werden in der Postfix-Nomenklatur »virtuell« genannt (auf Englisch oft auch Hosted Domains).
Postfix sieht mehrere Möglichkeiten zur Realisierung virtueller Domänen vor. Der einfachste Weg besteht darin, beim Parameter mydestination einfach mehrere Domänen einzustellen, etwa so:
Selbstverständlich müssen Sie auch die DNS-Konfiguration von noch-eine-firma.de entsprechend anpassen. Dem MX-Hostnamen muss also die IP-Adresse Ihres Servers zugeordnet sein (siehe auch Abschnitt 35.1, »Einführung und Grundlagen«).
Sie erreichen damit, dass Mails an noch-eine-firma.de genauso behandelt werden wie Mails an firma-abc.de. Es spielt also keine Rolle, ob eine E-Mail an huber@firma-abc.de oder an huber@noch-eine-firma.de adressiert wird: Postfix stellt die E-Mail auf jeden Fall dem lokalen Benutzer huber zu. Für manche Fälle ist das ausreichend – insbesondere dann, wenn eine Firma oder Organisation mehrere Webauftritte hat, aber in Wirklichkeit immer dieselben Personen dafür verantwortlich sind.
Virtuelle Domänen mit getrennten E-Mail-Benutzern
Wenn Sie zwischen gleichnamigen Benutzern je nach Domäne differenzieren möchten, geben Sie die betroffenen Domänen nicht in mydestination an, sondern mit dem Schlüsselwort virtual_alias_domains.
Außerdem brauchen Sie nun eine Tabelle, die die Zuordnung zwischen den E-Mail-Adressen der virtuellen Domänen und den realen Linux-Accounts herstellt. Weiterhin ist also für jede E-Mail-Adresse ein Linux-Account erforderlich. Um beim Beispiel der huber-Adressen zu bleiben: Der Account für huber@firma-abc.de ist weiterhin huber. Für huber@noch-eine-firma.de müssen Sie einen neuen Account anlegen, z.B. huberNEF. Der Aufbau der Tabelle für die virtuellen E-Mail-Benutzer sieht so aus:
Die Tabelle kann wie die Alias-Tabelle mehreren E-Mail-Adressen denselben Benutzer zuordnen, also etwa:
Mit postmap machen Sie aus dieser Datei eine für Postfix lesbare Datenbankdatei:
Jetzt müssen Sie noch main.cf anpassen. virtual_alias_domains zählt alle virtuellen Domänen auf (aber nicht die Hauptdomäne, die geben Sie weiterhin mit mydestination an!). virtual_alias_maps gibt den Dateinamen der virtuellen Alias-Tabelle an.
Virtuelle Domänen mit virtuellen Postfächern
Bis jetzt war es immer erforderlich, dass jeder E-Mail-Adresse ein Linux-Account gegenüberstand. Postfix weigert sich, E-Mails in einem Postfach zu speichern, wenn es nicht einen gleichnamigen Linux-Account gibt. Bei sehr vielen E-Mail-Adressen wird es aber zunehmend unpraktisch, jedes Mal auch einen neuen Account anzulegen. Postfix sieht zur Lösung dieses Problems virtuelle Postfächer vor. Das sind ganz gewöhnliche Postfachdateien; die Bezeichnung »virtuell« bezieht sich nur darauf, dass es keine dazugehörenden Linux-Accounts gibt.
Freilich müssen auch die virtuellen Postfächer jemandem gehören. Dazu erzeugen Sie eine neue Gruppe und einen neuen Benutzer mit jeweils noch unbenutzten GIDs und UIDs, im folgenden Beispiel jeweils 5000:
Nun ändern Sie main.cf wie im folgenden Beispiel-Listing. virtual_mailbox_domains gibt die virtuellen Domänen an, deren E-Mails in virtuellen Postfächern gespeichert werden sollen. virtual_mailbox_base gibt das Verzeichnis an, in dem die virtuellen Postfächer angelegt werden sollen. Die Tabelle virtual_mailbox_maps stellt die Zuordnung zwischen den E-Mail-Adressen und den Postfächern her. virtual_uid_maps und -_gid_maps gibt die UID und GID der Postfachdateien an. Theoretisch ist es hier möglich, eigene UIDs und GIDs für jedes Postfach anzugeben, aber das ist selten zweckmäßig.
Die Datei virtual-mboxes gibt für jede E-Mail-Adresse die dazugehörende Postfachdatei relativ zum Pfad virtual_mailbox_base an. Dieses Beispiel verwendet für jede Domain ein eigenes Verzeichnis und innerhalb dieses Verzeichnisses dann einfach den Benutzernamen. Grundsätzlich können Sie hier aber nach Belieben verfahren. Für die eigentliche Zustellung ist das Postfix-Kommando virtual zuständig. Es speichert die E-Mails standardmäßig im mbox-Format. Wenn Sie das Maildir-Format vorziehen, geben Sie in virtual-mboxes einfach im Anschluss an den Dateinamen einen Schrägstrich an, also beispielsweise noch-eine-firma.de/huber/:
postmap macht aus virtual-mboxes eine Datenbankdatei:
Ein letzter Schritt besteht nun darin, dass Sie für jede Domain das Postfachverzeichnis erzeugen müssen. Entscheidend sind dabei die Zugriffsrechte.
postfix reload aktiviert die Konfiguration. Nun senden Sie eine Testnachricht an huber@noch-eine-firma.de und werfen danach einen Blick in das Verzeichnis /var/mail/noch-eine-firma.de/. Dort sollte nun die Datei huber mit der neuen E-Mail auftauchen.
Wenn Sie alle Domänen virtuell verwalten möchten, also auch die Domäne des Hostnamens Ihres Rechners, entfernen Sie den Hostnamen aus der mydestination-Zeile und fügen ihn der virtual_mailbox_domains-Zeile hinzu:
Virtuelle Postfächer mit MySQL-Tabellen verwalten
Virtuelle Postfächer ersparen Ihnen es zwar, für jede E-Mail-Adresse einen Account einzurichten, machen dafür aber die Konfiguration von Dovecot zur Abholung der E-Mails (POP) sowie zur SMTP-Authentifizierung komplizierter: Sie müssen nun eine weitere Tabelle administrieren, die für jeden Benutzer einen Login-Namen und ein Passwort enthält.
Virtuelle Postfächer reduzieren den Verwaltungsaufwand nur dann, wenn Sie gleichzeitig sämtliche Daten der E-Mail-Accounts in einer Datenbank oder in einem LDAP-System speichern und Postfix und Dovecot gleichermaßen auf diese Datenbank zugreifen können. Eine ausführliche Anleitung, wie Sie dies mit MySQL bewerkstelligen, finden Sie auf den folgenden Seiten:
https://workaround.org/ispmail/wheezy
https://www.linode.com/docs/email/postfix/email-with-postfix-dovecot-and-mysql-on-centos-7