Seit einiger Zeit betreibe ich auf meinem Server einen Mailserver. Einfach gesagt, im Hintergrund aber etwas komplizierter: ein Mailserver ist eine Kombination aus einem Mail-Transfer-Agent (MTA, bei mir Postfix), einem Mail-Delivery-Agent (MDA, bei mir Dovecot) und einem Mail-User-Agent (MUA, bei mir Roundcube). Die genaue Funktionsweise kann man bei bedarf googeln.

Standardmäßig hat ein Server eine Domain und User (Unix-User). Wenn alles richtig konfiguriert ist, können sich die „normalen“ Unix-User am MUA anmelden und sehen ihre Emails. In den seltensten Fällen ist das so einfach gewünscht. Denn als Serveradministrator hat man normalerweise ein oder mehrere Userkonten, möchte aber auch die Mails, die an root, postmaster, hostmaster und webmaster haben. Dafür eignen sich Aliase.

Aliase

Aliase sind im Prinzip Weiterleitungen, die den Postfix veranlassen entsprechende Mails nicht dem User zuzuordnen, an den sie gerichtet sind, sondern dem in der Alias-Datei definierten User. Die Aliasdatei ist /etc/aliases.

Aufgebaut ist die Datei sehr einfach:

root: marco
postmaster: marco
hostmaster: marco
webmaster: marco

Es werden also alle Mails an die User root, postmaster, hostmaster und webmaster an mich (marco) weitergeleitet. Hat man etwas an dieser Datei geändert muss noch folgenden Befehl ausführen, damit die Änderungen ihre Wirkung zeigen:

$ sudo newaliases

(als root entfällt selbstverfreilich das sudo)

Hat man mehrere Domains, die auf den Server zeigen, möchte man ziemlich sicher auch auf mehreren Domains Emails erhalten und schreiben können. Das ist – mit den normalen Unix-Usern – auch recht einfach möglich.

Mehrere gemeinsam genutzte Domains, Unix-User

In dieser Konstellation hält sich der Konfigurationsaufwand auch sehr in Grenzen. Es wird einfach in der Datei /etc/postfix/main.cf folgende Direktive geändert:

mydestination = $myhostname localhost.$mydomain example.com [weitere Domains]

Am besten einfach mit Leerzeichen getrennt die weiteren Domains hinten ranhängen.

Das funktioniert prima, solange man allein ist und es völlig Wurst ist, an welchen User welcher Domain jemand eine Email versendet, weil man sowieso alle selbst liest und beantwortet. Schwieriger ist es, wenn man mehrere User hat, die alle eine andere Domain zugeteilt bekommen sollen.

Mehrere getrennte Domains, Unix-User

Diese Konstellation wird im realen Umfeld nicht oft vorkommen; es ist aber dennoch eine Möglichkeit der Konfiguration. Hintergrund ist, nicht jeden User auf jeder Domain Mails empfangen zu lassen. Diese Lösung sieht so aus:

/etc/postfix/main.cf:
    virtual_alias_domains = example.org [weitere Domains]
    virtual_alias_maps = hash:/etc/postfix/virtual

um die weiteren virtuellen Alias-Domains festzulegen. Und dann werden noch die Mailadressen zugewiesen:

/etc/postfix/virtual:
    hansi@example.org    marco
    hubertus@example.org steve
    inge@example.org     steve
    [weitere Definitionen]

Möchte man, dass „alle anderen“ Mails auch abgefangen werden kann man noch folgende Zeile hinzufügen:

    @example.org         marco

Nachdem man die /etc/postfix/virtual geändert hat, muss man noch das Kommando postmap /etc/postfix/virtual  ausführen. Nach einer Änderung der Datei /etc/postfix/main.cf muss ein postfix reload  folgen.

Was nun, wenn man nicht nur die Domains, sondern auch die User völlig unabhängig von der Betriebssystem-Ebene konfigurieren will? Kein Problem. In der Theorie jedenfalls 😉

Mehrere getrennt genutzte Domains, keine Unix-User

Diese Konfiguration ist gleichzeitig die „komplizierteste“, aber auch die flexibelste Lösung. Wenn man professioneller Reseller ist, bietet sich durchaus auch eine kommerzielle Softwarelösung an, wie beispielsweise Plesk. Viele vServer- und Serveranbieter lizenzieren auch solche Verwaltungssoftware, mit welcher man derartige Umgebungen komfortabel verwalten und einrichten kann. Aber möchte man das nicht geht das natürlich auch „zu Fuß“.

Wir nehmen an, die virtuelle Domain soll „example.org“ sein. Wir möchten jetzt, dass Mails an diese Domain in eigene Postfächer gehen und von Nicht-Betriebssystem-Benutzern abgerufen werden sollen.

/etc/postfix/main.cf:
    virtual_mailbox_domains = example.org [evtl. weitere Domains]
    virtual_mailbox_base = /var/mail/vhosts
    virtual_mailbox_maps = hash:/etc/postfix/vmailboxes
    virtual_minimum_uid = 1000
    virtual_uid_maps = static:5000
    virtual_gid_maps = static:5000
    virtual_alias_maps = hash:/etc/postfix/virtual

/etc/postfix/vmailboxes:
    info@example.org    example.org/info
    mail@example.org    example.org/mail
    kontakt@example.org example.org/kontakt

/etc/postfix/virtual:
    postmaster@example.org  postmaster

Nach Änderungen an den Dateien /etc/postfix/virtual und /etc/postfix/vmailboxes müssen die Kommandos

$ postmap /etc/postfix/virtual
$ postmap /etc/postfix/vmailboxes

ausgeführt werden.

Außerdem muss man ein postfix reload ausführen, wenn die main.cf geändert wurde.

Anmerkungen zu der Konfiguration:

• Die Direktive virtual_mailbox_domains sagt Postfix, dass er Mails an diese Domain nicht abweisen soll. Ist sie nicht gesetzt werden alle anderen Einstellungen gar nicht erst wirksam. Der Sender einer Mail an diese Domain wird dann eine Meldung erhalten, dass sie nicht zugestellt werden konnte. WICHTIG: Man darf NIEMALS eine virtuelle Mailbox-Domain als mydestination oder virtual_alias_domain eingetragen haben. Überprüfen Sie das dreimal!
• Die Direktive virtual_mailbox_base definiert einen Präfix für die virtuellen Mailboxen. Das funktioniert ähnlich wie ein Home-Verzeichnis für Mailboxen. Es ist sinnvoll darunter noch Ordner für die einzelnen Domains zu machen, aber nicht zwingend nötig.
• virtual_mailbox_maps definiert eine Lookup-Tabelle mit Pfadangaben zu den Mailboxen. Wir verweisen hier auf die Datei vmailboxes, könnten aber auch beispielsweise eine MySQL-Tabelle verwenden. Hier gibt es eine Liste aller möglichen Lookup-Tabellen-Typen In der Datei steht dann welche Mailadresse welchen Pfad bekommt. Schlussendlich wird noch der Basispfad vorangestellt. In unserem Beispiel gehen also Mails an info@example.org in die Mailbox /var/mail/vhosts/example.org/info
• Die virtual_minimum_uid definiert die kleinste User-ID die gültig ist. Standard ist 100. Als Lookup dient die Direktive virtual_uid_maps. Ist die User-ID kleiner, wird die Mail nicht ausgeliefert.
• virtual_uid_maps und virtual_gid_maps definieren eine Loopup-Tabelle, welche die User-ID und Group-ID enthält, mit welcher postfix die Mails an die Mailbox liefert. Wen das tiefer interessiert ist mit der Postfix-Dokumentation und passablen Englischkenntnissen gut beraten. Wir haben hier eine statische User- bw. Group-ID gewählt.
• Man kann auch virtuelle Aliases mit virtuellen Mailboxen kombinieren. In der Datei /etc/postfix/virtual verwenden wir dies im Beispiel, um Mails an postmaster@example.org an den lokalen postmaster weiterzuleiten. Dies erfordert natürlich, dass $myorigin mit in der main.cf-Direktive mydestination gelistet ist.
• Es ist auch möglich in der Datei vmailboxes eine „Catch-All“-Klausel zu haben. Diese muss selbstredend als letzte Regel für eine Domain in der Datei stehen, da sie sonst bei der sequentiellen Abarbeitung natürlich eher greift. Die Syntax dafür ist ähnlich, wie die bei den virtuellen Alias-Definitionen: @example.org example.org/all

Noch ein Hinweis: Postfix ist eventuell in der Lage Mailbox-Verzeichnisse in /var/mail/vhosts anzulegen, abhängig von den Verzeichnisberechtigungen. Ungeachtet dessen ist es sicherer diese SELBST ANZULEGEN. Das ist auch die unmissverständliche Empfehlung der Postfix-Dokumentation.

Dovecot einrichten

Ist man so weit gekommen, ist es möglich Mails an diese virtuelle Mailbox-Domain zu senden. Allerdings kann man sie noch nicht aufrufen. Denn der MDA kennt diese viruellen Mailboxen ja noch nicht. Nutzt man Dovecot als Delivery-Agent kann die Einrichtung folgendermaßen aussehen:

/etc/dovecot/dovecot.conf:
   passdb {
     driver = passwd-file      
     args = scheme=CRYPT username_format=%u /etc/dovecot/users   
   }
   passdb {
     driver = pam
   }
   userdb {
     driver = passwd-file
     args = username_format=%u /etc/dovecot/users
   }
   userdb {
     driver = passwd
   }

Allerdings ist in einer modernen Standardkonfiguration von Dovecot vieles in verschiedene Dateien im Verzeichnis /etc/dovecot/conf.d ausgelagert. Möchte man also nichts verändern, weil man eh kaum Ahnung von Dovecot hat, kann man in die /etc/dovecot/conf.d/10-auth.conf gehen und am Ende der Datei eine der folgenden Zeilen auskommentieren:

#!include auth-deny.conf.ext
#!include auth-master.conf.ext
!include auth-system.conf.ext
#!include auth-sql.conf.ext
#!include auth-ldap.conf.ext
!include auth-passwdfile.conf.ext
#!include auth-checkpassword.conf.ext
#!include auth-vpopmail.conf.ext
#!include auth-static.conf.ext

Wie man sieht, habe ich mich hier beispielhaft für die Methode „auth-passwdfile.conf.ext“ entschieden. Die Datei auth-passwdfile.conf.ext enthält dann die relevanten Direktiven, die oben stehen. Nun brauchen wir nur noch die Definition. Unsere User-Datei heißt /etc/dovecot/users. Aufgebaut ist sie kompatibel zur bekannten /etc/passwd. Hier ein Beispiel:

info@example.org:{PLAIN}dasistdaspasswort:5000:5000::/var/mail/vhosts/example.org/info::userdb_mail=maildir:~/

Auf die Bedeutung der einzelnen Felder kann man sich hier belesen. Der Aufbau ist grob so:

username:passwort:uid:gid:(gecos):home:(shell):extra_fields

In den Extrafeldern steht bei uns, welches Mailbox-Format der User hat.

Wenn man das alles gemacht hat, und sich kein Fehler eingeschlichen hat, kann man mit den in der User-Datei definierten Usern die Mails abholen, die Postfix an die virtuellen Mailboxen geliefert hat.

Sollten Probleme auftreten gib es einerseits die Dovecot-Mailingliste (die mir sehr geholfen hat), andererseits die Postfix-Mailingliste. Außerdem ist es immer wichtig, die Log-Dateien aufmerksam zu lesen. Nicht zuletzt freue ich mich auch über Kommentare, sowohl positive als auch kritische. Wer einen Fehler findet darf mich auch gern kontaktieren.

Dieser Blog-Eintrag ist an folgende Seiten angelehnt:

• http://www.postfix.org/VIRTUAL_README.html
• http://wiki2.dovecot.org/Authentication/MultipleDatabases