Mit E-Mail-Diensten muss sich jeder Administrator früher oder später einmal beschäftigen. Das zur CeBIT erscheinende ADMIN 02/2012 gibt dazu Praxis-Tipps und ... (mehr)

Virtuelle Domains

Für unser Beispiel empfiehlt es sich, nur »localhost« und »$mydomain« einzutragen, weil weitere Zuständigkeiten im Verlauf der Konfiguration virtueller Domains verwendet werden (siehe dazu auch den Kasten "Virtuelle Domains und Mailboxen" ). Außerdem sollte man die Variable »$mydomain« auch im Parameter »myorigin« setzen:

myorigin = $mydomain

Virtuelle Domains und Mailboxen

Die im Artikel beschriebene Konfiguration erfordert das Anlegen einer Reihe weiterer Dateien, etwa zum Definieren der virtuellen Domains, der zugehörigen Mailboxen, sowie des Mappings zwischen Mailboxen und Mail-Usern. An erster Stelle muss der Admin die Datei »/etc/postfix/virtual_domains« anlegen, in der zeilenweise sämtliche Domains einzutragen sind, für die der Mailserver zuständig sein soll, selbstverständlich abgesehen von denen, die bereits als direkte Ziele in »mydestination« angegeben sind. Damit kann wahlweise der von Postfix selbst für virtuelle Mailboxen vorgesehene MDA ( »virtual« ) oder der im Beispiel genutzte Delivery Agent »dovecot« (in der Postfix-Konfiguration mit »virtual_transport« referenziert) sämtliche E-Mails, die im Empfänger einen der hier angegebenen Domainnamen tragen, an das zugehörige E-Mail-Postfach auf dem Mailserver zustellen.

Da im Beispiel bisher lediglich »localhost« und »$mydomain« als Primärziele in »/etc/postfix/main.cf« angegeben sind, kann der Admin jetzt beispielsweise die Domains »meinefirma.de« und »meinefirma.com« hinzufügen. Außerdem braucht er noch eine Konfigurationsdatei »/etc/postfix/vmailbox« , in der er zeilenweise Mappings zwischen den virtuellen E-Mail-Adressen und den physischen Mailboxen der zugehörigen Benutzer einträgt, etwa:

support@meinefirma.com               meinefirma.com/support/
info@m meinefirma.de                    meinefirma.de/info/
webmaster@meinefirma.d              meinefirma.de/webmaster/

und so weiter. Dabei steht das Verzeichnis, in dem der Delivery Agent die Mailbox ablegt in der zweiten Spalte und zwar relativ zu »$virtual_mailbox_base« . Die Schrägstriche am Ende der Mailbox-Definition sorgen automatisch dafür, dass Postfix Maildir als Mailbox-Format benutzt; beim Weglassen der Slashes wäre das Format Mbox. Ist das erledigt, erzeugt das »postmap« -Kommando aus der ASCII-Datei »/etc/postfix/vmailbox« die für Postfix lesbare Lookup-Tabelle »/etc/postfix/vmailbox.db« . Mithilfe einer weiteren Konfigurationsdatei »/etc/postfix/virtual_alias« kann der Admin außerdem eventuelle Weiterleitungen zwischen den einzelnen E-Mail-Empfängern wunschgemäß abbilden. Das Format dieser Mapping-Datei enthält erwartungsgemäß in beiden Spalten E-Mail-Adressen.

thomasdrilling@meinefirma.com              t.drilling@meinefirma.com
tdr@meinefirma.com                                t.drilling@meinefirma.com
thomas.drilling@meinefirma.com             t.drilling@meinefirma.com

Auch diese Datei ist anschließend in eine Postfix-Lookup-Tabelle zu übersetzen.

So kann Postfix »$myorigin« an unqualifizierte Adressen anhängen. Der Parameter »myorigin« ist wichtig, denn wenn etwa Cronjobs auf dem Mailserver Mails an »root« erzeugen, wird daraus »root@$myorigin« , was dann unbedingt in »$mydestination« stehen sollte. Möchte der Admin den Mailserver später in seine Domains »meinefirma.de« und »meinefirma.com« integrieren (Setzen der MX-Records), kann er einen der zahlreichen kostenlosen DNS-Dienste benutzen. Außerdem kann es nicht schaden, mit »inet_interfaces = all« dafür zu sorgen, dass der Mailserver SMTP-Anfragen auf allen verfügbaren Interfaces annimmt. Weiter ist es mithilfe von »mynetworks = 192.168.111.0/8« möglich, das hier angegebene Netzwerk als lokales und damit vertrauenswürdiges Netzwerk einzustufen. Somit können Clients aus lokalen Netz Mails direkt versenden, ohne sich dazu am MTA authentifizieren müssten.

Virtuelle Mailboxen

Da ein echter Mailserver üblicherweise für eine Vielzahl Benutzer beziehungsweise Mailboxen zuständig ist, kann der Admin schon aus Sicherheitsgründen nicht für jeden einen lokalen Shell-Account auf dem System zulassen, zumal eine lokale Auslieferung von E-Mails in das jeweilige Home-Verzeichnis ohnehin oft nicht gewünscht ist. Postfix bietet zu diesem Zweck virtuelle Mailboxen an, wobei sämtliche E-Mails vom Systembenutzer verwaltet werden.

Damit Postfix virtuelle Mailboxen nutzen kann, muss der Admin die Datei / »etc/postfix/main.cf« um einige Einträge erweitern. So legt etwa »virtual_mailbox_domains = /etc/postfix/virtual_domains« fest, dass die zu verwaltenden Domains in der Datei »virtual_domains« definiert sind. Die Zeile

virtual_mailbox_base = /var/mail/vhosts

teilt dem Postfix-Server mit, in welchem Verzeichnis die virtuellen Mailboxen im lokalen Dateisystem liegen. Mit dem Eintrag

virtual_mailbox_maps = hash:/etc/postfix/vmailbox

gibt der Administrator die Mapping-Datei an, in der er zeilenweise sämtliche Zuordnungen von E-Mail-Adressen zur physischen Mailbox-Datei definiert. Postfix hängt die in der Datei enthaltenen Dateinamen jeweils an das in »virtual_mailbox_base« angegebene Verzeichnis an und bildet daraus den absoluten Dateinamen der Mailboxen. Mit dem Parameter

virtual_alias_maps = hash:/etc/postfix/virtual_alias

dagegen gibt der Admin eine Mapping-Datei an, in der er Aliase für sämtliche Domains definieren kann. Das Anlegen der beschriebenen Mapping-Dateien, sowie das zugehörige Format ist im Kasten "Virtuelle Domains und Mailboxen" beschrieben. Der Administrator kann außerdem mit

virtual_minimum_uid = 100
virtual_uid_maps = static:4000
virtual_gid_maps = static:4000

die UID und GID festlegen, unter der Postfix den für das Zustellen einer E-Mail in ein Postfach zuständigen Delivery Agent »virtual« beziehungsweise »dovecot« ausführt. Postfix verwendet dann die hier angegebenen UID/GID für die Mailbox-Dateien, wobei alle Mailboxen von einem einzigen (System-)Benutzer mit der UID/GID 4000 verwaltet werden:

virtual_transport = dovecot
dovecot_destination_recipient_limit = 1
mailbox_size_limit = 0

Der Systembenutzer soll aus Sicherheitsgründen kein direktes Login auf dem Mailserver besitzen, weil er ausschließlich für das Verwalten des Mail-Storage gedacht ist. Der Benutzername und der Gruppen-Name sind frei wählbar, zum Beispiel »vmail« . Selbstverständlich müssen beide vor dem finalen Test der Postfix-Konfiguration mit der angegebenen UID/GID angelegt werden.

groupadd -g 4000 vmail
useradd -s /usr/sbin/nologin -u 4000 -g 4000 vmail

Außerdem muss der Admin im Verlauf der weiteren Konfiguration daran denken, die obigen Mapping-Dateien auch tatsächlich anzulegen und mit dem »postmap« -Kommando ins Postfix-eigene Datenbank-Format zu überführen. Anschließend kann er die benötigten Mailbox-Verzeichnisse anlegen. Danach erstellt er das Mailbox-Verzeichnis und ordnet dieses dem Benutzer und der Gruppe »vmail« zu:

mkdir -p /var/mail/vhosts/meinefirma.de
chown -R vmail:vmail /var/mail/vhosts

Im Übrigen muss der Admin auch den Nutzer »postfix« der Gruppe »vmail« hinzufügen. Wer ein Enterprise-Mailserver-Setup zum Verwalten von drei- oder vierstelligen Mailboxzahlen plant, sollte allerdings auf das Hantieren mit Benutzer-Dateien zugunsten einer Datenbank-Lösung (MySQL. Postgres) verzichten beziehungsweise auf einen Verzeichnisdienst ausweichen. An dieser Stelle bietet es sich außerdem an, mit »mailbox_size_limit = x« etwaige Quotas für die jeweiligen Mailboxgröße zu setzen, wobei der Wert 0 sämtliche Einschränkungen aufhebt. Die beiden Zeilen

virtual_transport = dovecot
dovecot_destination_recipient_limit = 1

weisen Postfix an, den Dovecot LDA als für das Ausliefern eingehender Mails zuständigen Mailbox-Transport zu nutzen.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023