Postfix SMTP-Server
Postfix ist ein SMTP-Server. SMTP ist das Protokoll zum Mailaustausch im Internet. Wie genau arbeitet ein SMTP Server?
SMTP
Die Grafik zeigt den üblichen Weg einer Email die per SMTP verschickt wird:
Alice möchte an Bob eine Email senden. Alice ist Kundin bei T-Online und hat dort auch Ihre Emailadresse alice@t-online.de. Bob benutzt GMX als Mailprovider und hat dort die Adresse bob@gmx.net.
Alice schickt also eine Mail an die Adresse bob@gmx.net ab (1). Zum versenden benutzt sie den Mailserver von T-Online. Das Protokoll über welches die Mail von Alices PC zum T-Online Mailserver versendet wird ist SMTP. Der T-Online Mailserver ist jedoch nicht das Endziel der Mail, da dieser nicht für Mails die an @gmx.net Adressen gehen sollen zuständig ist. Eigentlich müßte der Mailserver solch eine Mail also abweisen, da er nicht der zuständige Mailserver für die Zieldomain ist. Alice ist jedoch T-Online Kundin. Daher darf sie Mails über den T-Online Server "relayen".
Als "Relay" bezeichnet man einen Mailserver über den Email zwecks endgültiger Zustellung nur durchgeleitet wird. Ein offenes Relay ist ein Mailserver über den jeder Mail an beliebige Ziele senden darf. Solche offenen Relays sind natürlich geradezu eine Einladung an Spammer. Daher werden Mailserver im allgemeinen heute so konfiguriert, das diese nur Emails ihrer eigenen Kunden, die sich als solche ausgewiesen haben hindurch relayen. Andere Emails werden abgewiesen wenn diese nicht an die Domain adressiert sind, für die der Mailserver zuständig ist.
Ursprünglich hat das SMTP-Protokoll keine Authentifizierung vorgesehen. Erst als die Notwendigkeit durch das vermehrte auftreten von Spam entstand, wurde eine Authentifizierung nachgerüstet. Daher weist sich Alices PC per SMTP-Auth beim T-Online Mailserver als Kundin aus. Dazu muß sie Benutzername und Passwort mitsenden. Im allgemeinen wird heutzutage für SMTP-Auth SASL verwendet. SASL steht für Simple Authentication and Security Layer.
Nachdem der T-Online Mailserver also die Mail zum relaying akzeptiert hat, wird er versuchen sie an sein eigentliches Ziel auszuliefern. Dazu muß er einen DNS-Server befragen, welcher Mailserver für die Zieldomain (also gmx.net) zuständig ist (2). Dies bezeichnet man als MX-Abfrage (MX ist der sogenannte Ressource Record im DNS Server in dem die zuständigen Mailserver enthalten sind). DNS Server haben allgemein die Aufgabe zu Hostnamen IP-Adressen zurück zu liefern, da Computer im Gegensatz zu Menschen nur mit IP-Adressen arbeiten. Warum fragt der Mailserver von T-Online nicht direkt nach der IP-Adresse für gmx.net? Dies liegt daran, das gmx.net eine Domäne und kein Hostname ist. Unter der Domäne gmx.net können viele Hostnamen stecken. Der T-Online Mailserver muß jedoch wissen welcher der gmx.net Hosts der für die gesamte Domäne zuständige Mailserver ist. MX Einträge weisen auf einen einzelnen Hostnamen in der Domäne hin, welcher für sämtliche Mail die an die Domäne geschickt wird zuständig ist. Theoretisch könnte natürlich jemand auch an einen Hostnamen eine Mail schicken. In diesem Fall würde der MX Eintrag nicht benötigt werden und die Mail könnte direkt an den adressierten Host zugestellt werden. Solch eine Mail hätte dann die Form: benutzer@host.example.com, statt benutzer@example.com. Es hat sich jedoch allgemein durchgesetzt und ist letzlich auch für alle Beteiligten (User genauso wie Mailadministratoren) einfacher, Domains zu verwenden.
Der DNS-Server antwortet also mit dem MX-Eintrag für gmx.net (3).
Daraufhin kann der T-Online Mailserver die Mail an sein eigentliches Ziel ausliefern. Diese Auslieferung geschieht wieder per SMTP, diesmal allerding natürlich ohne Authentifizierung, da der gmx.net Mailserver die Mail ohnehin akzeptieren muß, da er der zuständige Mailserver für die Domain ist (4).
Der GMX-Mailserver wird anhand des linken Teils der Emailadresse wissen, an welches Postfach er die Mail ausliefern muß. Er wird also daraufhin die Mail in seinen lokalen Nachrichtenspeicher ablegen (5). Die Aufgabe des SMTP-Servers ist damit erfüllt. Die Email ist in das jeweilige passende lokale Postfach des Mailservers zugestellt. Allerdings hat Bob deswegen die Mail noch nicht erhalten.
Bob muß dazu erst seine Mail abholen (6). Dies funktioniert jedoch nicht über SMTP sondern über andere Protokolle wie POP3 oder Imap. POP3 und Imap werden im allgemeinen durch andere Serverprogramme realisiert als SMTP. Postfix ist ein reiner SMTP-Server. Für POP3 genauso wie für Imap gibt es diverse andere Software, die zusammen mit einem SMTP Server eingesetzt wird. Beispiele für POP3 und Imap Software sind: popa3d (nur POP3), popper (nur POP3), Courier (POP3 und Imap), Dovecot (POP3 und Imap) und Cyrus (POP3 und Imap).
Postfix
Postfix ist ein SMTP-Server der als OpenSource Software, frei für Unix-artige Betriebssysteme (wie Linux, BSD oder Solaris) zur Verfügung steht. Er ist unter der IBM Public License veröffentlicht. Ursprünglich wurde Postfix von Wietse Venema bei IBM entwickelt. Jedoch hat IBM Postfix ausdrücklich der OpenSource Gemeinschaft zur freien Weiterentwicklung zur Verfügung gestellt und kontrolliert das Projekt nicht mehr.
Postfix ist vor allem als sicherer und leicht zu bedienender Ersatz für Sendmail entwickelt worden. Sendmail war bis dahin der fast einzigste Mailserver der im Internet verwendet wurde. Sendmail hatte jedoch vor allem 2 Probleme: Zum einen ist Sendmail in der Vergangenheit vor allem durch Sicherheitslücken aufgefallen, zum anderen ist Sendmail auch extrem kompliziert zu administrieren. Früher galt der Spruch das man kein richtiger Unixadmin ist, solange man noch nicht Sendmail konfiguriert hat, aber jeder der einmal Sendmail konfiguriert hat, tut es kein zweites mal.
Die Sicherheitslücken in Sendmail wurden zwar meist schnell geschlossen, aber Sendmail ist auch von seiner grundlegenden Architektur nicht auf Sicherheit ausgerichtet. Sendmail ist ein einzelnes großes Programm, welches mit root-Rechten laufen muß um Email in lokale Mailboxen verschiedener Benutzer zustellen zu können. Daher hat jeder der es schafft eine Sicherheitslücke in Sendmail auszunutzen auch automatisch root-Rechte in dem System in das er eingebrochen ist.
Postfix ist von Anfang an auf Sicherheit hin entwickelt worden. Sein Schöpfer Wietse Venema gilt als anerkannter Sicherheitexperte, der sich vor allem mit IT-Sicherheitsforschung beschäftigt hat. Postfix ist kein monolithischer Block wie Sendmail, sondern besteht aus verschiedenen einzelnen Programmteilen. Dies ermöglicht es jeden Teil von Postfix nur mit so viel Rechten, wie unbedingt nötig sind, laufen zu lassen. Kein Teil von Postfix, der mit dem Netzwerk kommuniziert, läuft mit root-Rechten.
Aufbau
Postfix besteht aus verschiedenen Teilen: Der Master-Prozess wird als erstes (mit root-Rechten) gestartet. Er hat nur die Aufgabe die anderen Teile von Postfix bei Bedarf zu starten und kontrolliert diese. Der Master-Prozess selbst wird über die Konfigurationsdatei master.cf konfiguriert. In der master.cf stehen die Parameter drin, mit denen alle anderen Prozesse gestartet werden, wie etwa ob diese als unprivilegierter User oder mit root-Rechten gestartet werden, oder ob diese in einem Chroot laufen. Die Datei master.cf muß daher in den meisten Fällen nicht abgeändert werden und sollte erst mal so bleiben wie sie ist.
Einige der wichtigen weiteren Teile von Postfix sind etwa der Queuemanager qmgr (ist für alle Warteschlangen in denen Mails zwischengespeichert werden zuständig), postdrop (nimmt lokale Mails auf), smtpd (lauscht auf Mails aus dem Netzwerk), smtp (versendet Mails ins Netzwerk), trivial-rewrite (erledigt einige einfache Headerumschreibungen) und local (legt Mails lokal in Postfächer). Es gibt noch mehr Teile von Postfix, aber die genannten sind einige der wichtigsten.
Konfiguration
Das Verzeichnis mit den Konfigurationsdateien von Postfix wird auf den meisten Systemen als /etc/postfix angelegt. In diesem Verzeichnis wird man die bereits genannte master.cf finden und auch die Hauptkonfigurationsdatei main.cf befindet sich hier. Das gesamte Verhalten aller Teile von Postfix wird über die Hauptkonfigurationsdatei main.cf bestimmt.
Was muß Postfix alles durch seine Konfigurationsdatei wissen um seine Arbeit erledigen zu können? Wie wir gesehen haben muß Postfix schon mal wissen für welche Maildomäne er eigentlich zuständig ist. Dies können übrigens durchaus auch mehrere Domänen auf einem Server sein. Zum zweiten muß er wissen wie er Mails behandeln soll, die nicht an seine Domäne gerichtet sind oder mit anderen Worten wer darf den Server als Relay benutzen. Zum dritten muß der Server auch noch wissen wohin er Mails für die er selber das Endziel ist abspeichern soll, mit anderen Worten also, wo befindet sich der lokale Nachrichtenspeicher. Natürlich gibt es darüber hinaus noch viele weitere Aspekte und Feinheiten die sich konfigurieren lassen, aber diese 3 Aspekte ergeben sich logischerweise aus dem oben gesagten und damit läßt sich eine einfache Grundkonfiguration von Postfix bewerkstelligen.
main.cf
Generell besteht die main.cf aus Name/Wert Paaren. Der erste Begriff auf einer Zeile, auf der linken Seite ist der Name eines Konfigurationsparameters. Danach folgt die Wertzuweisung. Leerzeichen und das =-Zeichen sind dabei optional. Kommentarzeilen beginnen mit einem #.
Manche Parameter können mehrere Werte haben. Mehrere Werte können sowohl durch Kommas, als auch durch Leerzeichen getrennt werden. Mehrere Werte können auch auf mehrere Zeilen verteilt werden, wenn die neue Zeile mit Leerzeichen oder Tabulatoren beginnt.
Die Werte von Parametern können wiederverwendet werden, wenn als Wert ein anderer Parameter mit einem davor gesetzten $-Zeichen verwendet wird. Beispielsweise heißt: mydestination = $mydomain. Das der Wert von mydestination auf den selben Wert gesetzt werden soll wie mydomain.
Der folgende Teil zeigt eine einfache Konfiguration für Postfix in der main.cf, die ich darunter erklären werde:
# Wer bin ich und fuer welche Domains bin ich zustaendig
myhostname = mail.example.com
mydomain = example.com
mydestination = $myhostname, $mydomain
localhost.$mydomain, localhost, example.net
# Wer darf Mails relayen
mynetworks_style = subnet
# Wo landen lokal abgelegte Mails
mail_spool_directory = /var/mail
Wer bin ich?
Über myhostname wird dem Server der eigene Hostname bekannt gegeben. Mit mydomain wird die Domäne explizit gesetzt. Ist mydomain nicht gesetzt, benutzt Postfix automatisch den Wert von myhostname ohne den ersten Teil des Namens. Wenn also myhostname mit host.example.net angegeben wird und mydomain nicht gesetzt wäre, dann ist mydomain automatisch example.net.
mydestination bestimmt für welche Domains sich der Server zuständig fühlt. Hier können mehrere Werte aufgeführt werden. Wird dieser Parameter nicht gesetzt ist der Defaultwert: $myhostname, localhost.$mydomain.
Relaykontrolle
mynetworks_style bestimmt welche Rechner den Mailserver auch als Relay benutzen können. Oder korrekter eigentlich: Welche Clients mehr Rechte auf dem Mailserver haben, wie auch immer dieses "mehr Rechte" aussehen mag. Im Normalfall heißt mehr Rechte einfach die Erlaubnis den Mailserver als Relay zu benutzen. Der Standardwert von mynetworks_style ist subnet (so wie angegeben, daher könnte dies im Beispiel auch weggelassen werden). Die Werte von mynetworks_style können host, subnet oder class sein, wobei host bedeutet das nur der Server selbst relayen darf (also lokal erzeugte Mails), subnet bedeutet, das alle Clients die sich im selben Subnetz wie der Mailserver befinden, relayen dürfen und class bedeutet, das alle Rechner die sich im gleichen Klasse A/B/C Netzwerk befinden relayen dürfen.
mynetworks_style = subnet ist praktisch wenn der Mailserver der zentrale Mailserver innerhalb eines internen Lans ist, aber im Internet könnte diese Einstellung gefährlich sein und sollte besser auf host gestellt werden. SASL Authentifizierung als Möglichkeit authentifizierten Clients das Relaying zu ermöglichen, erfordert eine ganze Reihe weiterer Schritte, die ich in dieser Grundkonfiguration hier nicht weiter erläutern werde.
Was aber wenn ich ein Lan betreibe mit mehreren Subnetzen? Neben mynetworks_style gibt es auch den Parameter mynetworks, mit dem ich mynetworks_style ersetzen kann. Ist mynetworks gesetzt, wird mynetworks_style nicht mehr weiter beachtet. In mynetworks, kann ich IP-Adressen oder Subnetze aufführen denen das Relaying erlaubt ist. Als Beispiel:
mynetworks = 127.0.0.1, 192.168.0.0/24, 192.168.3.250
Mailablage
Mit mail_spool_directory wird das Systemverzeichnis bestimmt unterhalb dem die lokalen Mailboxdateien liegen. Ein ebenfalls installierter POP3/Imap-Server muß auf das selbe Verzeichnis zugreifen um Mails ausliefern zu können. Für die lokale Auslieferung gibt es dabei 2 verschiedene Speicherformate und 4 verschiedene Möglichkeiten wie Postfix lokal ausliefert.
Die beiden Speicherformate sind Mbox und Maildir. Beide Speicherformate sind als Unix-Emailspeicherformate weit verbreitet und mindestens eines von beiden Formaten wird auch von jedem POP3- oder Imap-Server verstanden. Mbox ist ein Format bei dem alle Mails zusammen in einer einzelnen Datei liegen. Maildir ist ein Format bei dem jede Email eine eigene Datei ist. Die Mails liegen dabei in einem Verzeichnis, welches spezielle Unterordner haben muß, um neue Emails von den Restlichen zu trennen. Da nicht jeder POP3 Server oder Imap-Server jedes Format versteht, wird die Wahl des jeweiligen POP3 Servers im allgemeinen auch die Wahl des verwendeten Speicherformats für Postfix mitbestimmen. Sollten sie die Wahl zwischen beiden Formaten haben, empfehle ich Maildir, da Maildir weniger Probleme mit großen Postfächern verursacht, als Mbox.
Die vier Arten von lokaler Zustellung die Postfix beherrscht sind Systemmailboxen, zustellung ins Heimatverzeichnis, zustellung an Kommandos und LMTP.
Mit Systemmailboxen sind Verzeichnisse gemeint, die vom Betriebssystem extra dafür vorgesehen sind Mailboxen für die Benutzer des Systems bereit zu stellen. Häufig ist dies /var/mail oder /var/spool/mail. Systemmailboxen werden immer durch den Parameter mail_spool_directory definiert. Die Mailboxen selbst werden dort als Mboxdateien mit dem Namen des Benutzeraccounts angelegt.
Benutzt man in der main.cf den Parameter home_mailbox anstatt mail_spool_directory, werden die Mails in das Heimatverzeichnis des Users zugestellt. Mit dem Wert home_mailbox = mybox würde z. B. eine Mbox-Datei mybox im jeweiligen Heimatverzeichnis des Users angelegt werden in welches dann die Mails zugestellt werden. Ein Maildir-Verzeichnis statt einer Mbox-Datei läßt sich einfach durch einen abschließenden Schrägstrich definieren. Z. B.:
home_mailbox = Maildir/
Dies würde alle Mails in einem maildir-Verzeichnis namens Maildir im Heimatverzeichnis ablegen. Das Verzeichnis Maildir selbst, müßte dazu bereits existieren. Benötigte Unterverzeichnisse würden automatisch angelegt werden.
Daneben ist es noch möglich, Mails nicht direkt in die Mailboxen abzuliefern, sondern ein zusätzliches Programm zu verwenden, welches für die Mailboxablage zuständig ist. Das kann z. B. ein Filterprogramm oder ähnliches sein. Ein bekanntes Beispiel hierfür ist etwa das Programm procmail, welches Aktionen mit Mails anhand von Filterausdrücken ausführen kann. Mit dem Parameter mailbox_command kann ein externes Programm zur Auslieferung angegeben werden. Z. B.:
mailbox_command = /usr/bin/procmail
Als letztes gibt es noch die Möglichkeit Mails per LMTP auszuliefern. LMTP ist ein eigenes Protokoll welches ähnlich wie SMTP, aber einfacher als SMTP ist und speziell zur lokalen Auslieferung von Mails gedacht ist. LMTP wird vor allem dann benötigt, wenn man ein POP3 oder Imap Programm verwendet das ein eigenes spezielles Format für seinen Nachrichtenspeicher verwendet, oder wenn man sehr große komplexe Setups vornehmen muß bei denen Nachrichtenspeicher und SMTP-Server 2 unterschiedliche Maschinen sind. Dies ist z. B. beim Cyrus Imapserver der Fall, der ein eigenes Format zur Nachrichtenspeicherung verwendet. Auf die Konfiguration von LMTP gehe ich im Rahmen dieser Grundkonfiguration nicht weiter ein.
Überprüfen und neu laden
Nachdem man die main.cf verändert hat, muß Postfix die Konfiguration neu laden. Dies geschieht mit dem Befehl:
postfix reload
Dadurch liest Postfix seine Konfiguration neu ein. Verbindungen die zu diesem Zeitpunkt gerade bestehen werden aber nicht unterbrochen, da dies kein vollständiger Neustart aller Postfixprozesse ist. Ein vollständiger Stop von Postfix funktioniert mit postfix stop. Mit postfix start läßt sich Postfix dann wieder starten. Ein vollständiger Stop ist bei einfachen Veränderungen der main.cf jedoch nicht erforderlich.
Alle Einstellungen die für Postfix gelten kann man sich auch über den Befehl postconf ansehen. postconf -n zeigt alle Konfigurationsparameter die man in der main.cf gesetzt hat an. Ein einfaches postconf ohne Parameter zeigt alle Parameter an, egal ob diese in der main.cf gesetzt wurden, oder ob diese auf ihren Standardwerten stehen:
postconf -n
Benutzer, Gruppe und Pfade
Falls Postfix wieder erwarten mit dieser Konfigurationsdatei nicht starten sollte. Könnte dies daran liegen, das Postfix nicht weiß unter welchen unprivilegierten Benutzer es starten soll und unter welchen Pfad Queue-Verzeichnis und zu Postfix gehörende Binarys liegen. Dies könnte sich im Logfile z. B. so äußern:
fatal: file /etc/postfix/main.cf: parameter mail_owner: unknown user name value: postfix
Postfix verwendet für diese Parameter Standardwerte, die auf Ihrem System nicht unbedingt stimmen müssen. Falls dies der Fall ist müssen sie einige zusätzliche Werte in ihrer main.cf eintragen. Folgendes ist ein Beispiel für diese Werte, welches auf einem OpenBSD System korrekt ist:
mail_owner = _postfix
setgid_group = _postdrop
command_directory = /usr/local/sbin
daemon_directory = /usr/local/libexec/postfix
queue_directory = /var/spool/postfix
sendmail_path = /usr/local/sbin/sendmail
newaliases_path = /usr/local/sbin/newaliases
mailq_path = /usr/local/sbin/mailq
Eventuell beinhaltet das Postfix-Paket auf Ihrem System eine Beispiel main.cf von der Sie dann oft die auf ihrem System gültigen Werte übernehmen können
Lookup-Tabellen
Woher weiß eigentlich der Server welche Mailbenutzer es auf dem System gibt? Ganz einfach jeder auf dem System angelegte Benutzer ist automatisch auch ein Mailbenutzer. Dadurch ist auch festgelegt, welche Mailadressen vor dem Domainteil stehen können. Gibt es also einen Benutzer mit dem Benutzernamen "heinrich" und ist mydestination auf example.net, example.org gesetzt, dann gibt es automatisch die beiden Mailadressen heinrich@example.org und heinrich@example.net.
Manchmal möchte man jedoch für die Emailadresse einen anderen Namen haben als der Benutzername des Accounts oder es soll für einen Benutzer mehrere Emailadressen geben. Dieser Wunsch läßt sich durch Aliase erfüllen.
Aliase sind zusätzliche Mailnamen für Benutzeraccounts. Aliase werden in einer eigenen Datei aufgelistet. Diese Datei hat das Format aliasname: benutzername. Z. B.:
info: heinrich
heinrich.klein: heinrich
root: mirijam
postmaster: mirijam
mirijam.mueller: mirijam
In diesem Fall gibt es die Benutzer heinrich und mirijam. Die Adressen info@ und heinrich.klein@ werden auf den Benutzeraccount heinrich weitergeleitet. Die Adressen root@, postmaster@ und mirijam.mueller@ werden auf den Benutzeraccount mirijam weitergeleitet. Es können als Ziele auch externe Adressen, andere Aliase oder mehrere Adressen aufgeführt werden. Ein Beispiel:
postmaster: root
root: klaus
irene: irene@gmx.de
support: klaus, hans
In diesem Fall werden Mails an postmaster@ an root weitergeleitet, aber Mails an root@ werden an klaus weitergeleitet. Letztendlich landen also Mails an postmaster@ bei klaus. Mails an irene@ werden an eine externe Adresse weitergeleitet, Mails an support@ werden sowohl an klaus, als auch an hans weitergeleitet. Bei support@ handelt es sich also um eine Verteilerliste.
Derartige externe Listen, die von Postfix verarbeitet werden, werden Lookup Tabellen genannt. Postfix verwendet diese Textdateien jedoch nicht direkt, sondern die Textdateien müssen zunächst in eine Datenbankdatei umgewandelt werden, welche dann von Postfix genutzt wird. Der Befehl mit dem die Alias-Datei in eine Datenbank umgewandelt wird heißt postalias. Daneben gibt es noch den Sendmail-Befehl newaliases. Dieser wird ebenfalls von Postfix verstanden (Postfix versucht so kompatibel wie möglich zu Sendmail zu bleiben).
Damit die Alias Datenbank auch verwendet wird, müssen sie diese noch in der main.cf für Postfix bekannt geben:
alias_database = hash:/etc/postfix/aliases
alias_maps = $alias_database
Mit alias_database und/oder alias_maps setzen sie den Pfad auf die Alias Datei. Der Vorsatz hash: gibt dabei den Datenbanktyp an. Hash ist auf den meisten System der Standardtyp. Die auf dem System verfügbaren Datenbanktypen können sie sich mit postconf -m ansehen.
Warum gibt es 2 Parameter, sowohl alias_maps, als auch alias_database? Dies hängt mit der Sendmailkompatibilität von Postfix zusammen. Die Datei von alias_database wird mit dem Sendmailbefehl newaliases erzeugt. alias_maps wird mit dem Befehl postalias erzeugt und kann neben lokalen Dateien, auch andere nicht lokale Datenquellen einbinden. Dazu ist Sendmail, bzw. newaliases nicht in der Lage.
Nachdem die Datei erstellt und in die main.cf eingetragen wurde, muß die Datei als Datenbank auch erzeugt werden. Dem Befehl postalias ist dazu einfach der Dateiname zu übergeben. Also angenommen sie befinden mich momentan in dem Verzeichnis /etc/postfix, dann können sie einfach eingeben:
postalias aliases
Dies erzeugt dann die Datenbankdatei aliases.db. Bitte beachten Sie das die Datei zwar die Endung .db hat, aber diese Endung nicht so in die Konfiguration der main.cf mit übernommen wird. In der main.cf steht die Datei trotzdem als /etc/postfix/aliases. postalias erzeugt die Datei ohne weitere Angabe im Standarddatenbankformat des Systems (meist hash). Möchten sie ein spezielles Datenbankformat angeben kann folgende Syntax verwendet werden:
postalias btree:aliases
Dies wird die Datenbankdatei im btree statt im hash Format erstellen.
Falls sie Änderungen an der ursprünglichen Textdatei vornehmen, muß danach natürlich jedesmal die Datenbankdatei ebenfalls mit postalias neu erzeugt werden. Ein neuladen der Postfixkonfiguration durch postfix reload, ist jedoch nach einer Änderung der Aliase nicht nötig. Postfix erkennt automatisch das die Alias-Datenbank geändert wurde.
Hier nochmal eine neue main.cf als Beispiel für einige der zusätzlich kennengelernten Parameter:
# Wer bin ich und fuer welche Domains bin ich zustaendig
myhostname = mail.example.com
mydomain = example.com
mydestination = $myhostname, $mydomain
localhost.$mydomain, localhost, example.net
# Wer darf Mails relayen
mynetworks = 127.0.0.1, 192.168.1.0/24, 192.168.5.0/24
# Wo landen lokal abgelegte Mails
home_mailbox = maildir/
# Aliase
alias_database = hash:/etc/postfix/aliases
alias_maps = $alias_database
Email und DNS
Aus dem vorher erläuterten geht auch hervor, daß Email in hohem Maße von DNS, dem Domain Name System abhängig ist. Damit ein Mailserver Emails für eine Domäne empfangen kann, muß für diese Domäne ein MX Eintrag im DNS hinterlegt sein. Dabei ist es auch möglich für eine Domäne mehrere MX Einträge anzulegen. Dabei muß eine Priorität angegeben werden. Diese Priorität wird als Zahl vergeben, desto kleiner die Zahl ist, desto höher ist die Priorität.
Möchte ein anderer Mailserver Mails an eine Domäne ausliefern, fragt er die MX Einträge ab. Gibt es mehrere MX Einträge, soll der Mailserver zunächst versuchen die Mails an den Eintrag mit der höchsten Priorität auszuliefern. Nur wenn dies nicht funktionieren sollte, kontaktiert er stattdessen den Mailserver mit der nächst höheren Priorität. Dies soll die Zuverläßigkeit und Ausfallsicherheit erhöhen, falls mal der primäre Mailserver nicht erreichbar ist. Solche nachgeordneten Mailserver bezeichnet man daher auch als Backup MX.
Logging
Postfix sendet seine Logmeldungen an den Syslog-Dienst des Systems in die Facility "mail". Sehen sie in der Konfiguration ihres Syslog-Dienstes nach in welche Datei Meldungen der Facility "mail" geschrieben werden. Oft ist dies /var/log/mail.log. Die Logmeldungen sind oft bei Problemen hilfreich.
In Deutschland kann es aus Gründen des Datenschutzes gesetzliche oder je nach Betrieb auch betriebliche Regelungen, geben, die ein zu langes Speichern von Mailserverlogs verbieten oder gar generell das Speichern bestimmter Loginformationen, wie Empfängeradresse, Zieladresse und Zeitpunkt untersagen. Erkundigen sie sich in jedem Fall vorher, welche Regelungen für sie gelten.
Literatur
Kyle D. Dent: Postfix, Ein sicherer und leicht zu verwaltender MTA für Unix, O'Reilly Verlag 2004.
Tobias Wassermann: Postfix ge-packt, MITP Verlag, 2006.
René Maroufi
