Home

Info

Artikel

Produkte

Stickers

UserGroups

Events

Bücher

	Linux-Magazin | LinuxUser | Linux-Events | Linux-Community | Perl Snapshots		Suchen:
			Jetzt bestellen! Die Software Rebellen Jahres-CD 2000

Postfix - der Sendmail-Ersatz? Modular und sicher Gregor Longariva

N

ahezu unüberschaubar ist die Flut von Diensten, die das Internet mittlerweile bietet. Einer der wichtigsten Dienste bleibt jedoch das Versenden und Empfangen von Mails. Ohne Open-Source-Tools wäre das undenkbar - gerade Sendmail gehört zu den am weitesten verbreiteten Mail Transfer Agents (MTA).

Leider ist der monolithische Sendmail alles andere als leicht zu pflegen. In solch ein "Multifunktions-Tool" schleichen sich zwangsläufig Fehler ein - eine neue Sicherheitslücke in Sendmail gehörte in der Vergangenheit zu den Treppenwitzen der Internet-Geschichte schlechthin.

Aber auch wenn die aktuelle Version - soweit bekannt - keine großen Sicherheitsmängel aufweist: alleine die Konfiguration von Sendmail schreit geradezu nach einer Alternativlösung. Das Standardwerk zu Sendmail, das so genannte "bat book" von Bryan Costales und Eric Allman [3] umfaßt 1021 Seiten.

Die beiden am häufigsten eingesetzten (freien) Alternativen zu Sendmail sind Dan Bernsteins Qmail und Postfix von Wietse Venema. Beide sind wie Sendmail im Quelltext frei verfügbar - Qmail unter der GPL, Postfix unter einer von der Mozilla Public License abgeleiteten Lizenz von IBM - und beide sind einfacher zu handhaben als das altehrwürdige Sendmail.

> We spent several months giving names to the program. 
>  
> The IBM name polizei killed every name we thought up, and so we 
> decided to change tactics. The program now has TWO names: 
> IBM Secure Mailer + Postfix.

Wieste's Ziel bei der Entwicklung von Postfix war, ein schnelles, einfach zu administrierendes und sicheres Programm(paket) zu entwickeln, das so weit wie möglich zu Sendmail kompatibel sein soll. Das Interessanteste an Postfix ist sein innerer Aufbau (siehe Grafik): es besteht aus mehreren kleinen Programmen, die über UNIX-Domain-Sockets kommunizieren. Auf diese Weise ist es viel einfacher, Probleme, Fehler oder Sicherheitsmängel in den Griff zu bekommen. Beispielsweise kommt Postfix ganz ohne setuid-M©chanismen aus. Deshalb ist es für einen potenziellen Angreifer unmöglich, Superuser-Rechte zu bekommen - selbst wenn er ein Sicherheitsloch von Postfix gefunden hätte. Sendmail hingegen muß unter UID 0 (root) laufen, zumindest in einer Standardinstallation und ohne größere Klimmzüge.

Ebenfalls aus Sicherheitsgründen arbeitet Postfix mit vier verschiedenen Queues: "maildrop", "incoming", "active" und "deferred". Lokal gesendete Mails landen in "maildrop" und werden von dort in die "incoming"-Queue kopiert, nachdem sie regelbasiert auf Größe, Inhalt und anderes überprüft wurden. In der "active" Queue landen die Mails, die der Queue-Manager gerade bearbeitet und ausliefert (lokal oder remote). Nachrichten, die Postfix nicht ausliefern kann (Dienst des Zielmailservers reagiert nicht, keine Route, keine Netzverbindung, ...), landen in der "deferred" Queue. Da Postfix immer nur eine Mail gleichzeitig bearbeitet und die "active" Queue klein hält, ist es unempfindlich gegen Ressourcenknappheit. Das Bearbeiten/Ausliefern von Mails kann also in keinem Fall, beispielsweise wegen eines vollen Dateisystems, blockiert werden.

Modularer Aufbau von Postfix

Die Grafik zeigt den modularen Aufbau von Postfix. Hierbei bedeuten: gelbe Ellipsen Programme gelbe Kästen Mail-Queues oder -Dateien blaue Kästen (Nachschlage-) Tabellen Programme in der umrandeten Box laufen unter der Kontrolle des Postfix master Daemons. Dateien in diesem Kasten gehören dem Postfix-Mail-System.

Postfix bietet zudem einige Mechanismen, empfangende, möglicherweise ressourcenschwache Mailsysteme zu schützen. Der Autor bezeichnet sein Mailsystem als "guten Nachbarn", der auch langsame Systeme nicht in Bedrängnis bringt.

Installation und Konfiguration

Postfix befindet sich derzeit immer noch in der Entwicklungsphase. So findet man auf den verschiedenen FTP-Servern verschiedene Versionen: die offiziellen und die experimentellen Releases (Snapshots). Operative Mailsysteme sollten nur eine offizielle Release verwenden, auch wenn die Snapshots nach Aussagen des Autors stabil laufen. Nach dem Auspacken sollte ein einfaches make genügen, um Postfix zu compilieren. Sollte Postfix bereits vorher für ein anderes Betriebssystem übersetzt worden sein, etwa in einem heterogenen Netz mit verschiedenen Unix-Systemen (siehe Kasten "Postfix-Plattformen"), löscht make tidy alle betriebssystemspezifischen Einstellungen.

ach dem Übersetzen folgt etwas Handarbeit. Bei Ersetzen eines bestehenden Mailsystems (etwa Sendmail), empfiehlt sich das Anlegen einer Sicherheitskopie der bestehenden Programme. Ein Beispiel:

mv /usr/sbin/sendmail /usr/sbin/sendmail.OFF
mv /usr/bin/newaliases /usr/bin/newaliases.OFF 
mv /usr/bin/mailq /usr/bin/mailq.OFF 
chmod 755 /usr/sbin/sendmail.OFF /usr/bin/newaliases.OFF 
/usr/bin/mailq.OFF 

Da Postfix nicht als "root" laufen sollte, ist es sinnvoll, einen neuen (virtuellen) Account einzurichten - etwa mit dem Namen "postfix" und ohne Login Shell:

Postfix verwaltet die Systemmailbox (etwa /var/ mail oder /var/spool/mail) auf zwei mögliche Arten: als systemweit schreibbares Verzeichnis, oder mittels SGID-Bit. Welche Methode sinnvoller ist, bleibt dem Systemadministrator überlassen. Ein SGID-Bit zu vergeben, ist immer mit Risiken verbunden. Wenn Postfix mit SETGID installiert wird, führt das Installationsskript folgendes aus:

chmod 1733 $QUEUE_DIRECTORY/maildrop
chmod g-s $COMMAND_DIRECTORY/postdrop

andernfalls (nicht setgid):

chgrp $setgid $COMMAND_DIRECTORY/postdrop
chmod g+s $COMMAND_DIRECTORY/postdrop  
chgrp $setgid $QUEUE_DIRECTORY/maildrop
chmod 1730 $QUEUE_DIRECTORY/maildrop

Das Installationsskript installiert die einzelnen Postfix-Dateien und ermöglicht gleichzeitig, einige Pfade interaktiv zu setzen. Diese werden gespeichert, um bei einer Neuinstallation nicht alles nochmal eingeben zu müssen.

Nun folgt die eigentliche (Laufzeit-) Konfiguration des Postfix-Mailsystems. Die Konfigurationsdateien liegen alle in einem einzigen Verzeichnis - in der Regel in /etc/postfix. Meistens braucht der System- oder Mailadministrator nicht viel einzustellen. Die Defaulteinstellungen sind entsprechend gewählt, um ein einfaches Mailsystem abzudecken. Sollte die Installation ein "send-only" Mailsystem sein (etwa auf einem Client, der über einen dedizierten Mailserver die Mails verschickt), kann Postfix einfach ohne weitere Konfigurierung gestartet werden. Allenfalls kann man in der Datei main.cf den Eintrag "smtp" auskommentieren. So verbietet man eine Verbindung von außen per inetd/smtp auf den Rechner.

Aber auch die Konfiguration eines "echten" Mailservers sollte keine Schwierigkeiten bereiten. Lediglich folgende Einträge in der Datei /etc/postfix/main.cf sind bei Bedarf anzupassen, darunter in jedem Fall die eigene Domain:

myhostname = mail.softbaer.de 
inet_interfaces = $myhostname 
mydestination = $myhostname 
mydomain = softbaer.de
myorigin = $mydomain 

Setzt man diese Werte nicht explizit, ermittelt Postfix die Werte durch Systemaufrufe - etwa den Hostnamen durch gethostname(2). Die Variable "myorigin" setzt den rechten Teil der Absenderadresse (longariva@MYORIGIN) der Mails. Setzt man "myorigin" nicht, setzt Postfix den Hostname als Absenderadresse, etwa longariva@mail.softbaer.de. Meistens ist die Form longariva@softbaer.deaerwünscht. Vorausgesetzt der MX-Eintrag im Nameserver ist richtig gesetzt, kann man dies durch

 
myorigin = $mydomain  

erreichen. Die Datei /etc/postfix/main.cf sowie die im gleichen Verzeichnis liegenden Beispieldateien für weitere Konfigurationen sind ziemlich gut kommentiert - damit sollten eventuell notwendige Feineinstellungen ohne weiteres möglich sein. Bleibt noch anzumerken, daß jede zugewiesene Variable an beliebiger anderer Stelle der Konfigurationsdatei wieder verwendet werden kann:

mydomain = domaene.de 
myorigin = $mydomain
relay_domains = $mydomain 

Falls doch das eine oder andere Feintuning notwendig sein sollte, kann man sich auf die beiden zentralen Dateien main.cf und master.cf (siehe Kasten "master.cf") beschränken. Erstere wurde bereits besprochen, letztere dient dem Steuern der Ressourcen, die Postfix verbraucht. Hier kann unter anderem angegeben werden, wieviele Prozesse maximal gleichzeitig laufen dürfen.

Gestartet wird Postfix auf zweierlei Art: einmal so, wie der gute alte sendmail mit

sendmail -bd -q5

oder durch

 
postfix start 

Dadurch daß der "alte" Aufruf funktioniert, brauchen eventuell vorhandene rc- (BSD) oder init.d- (SystemV) Skripte nicht angepaßt werden.

Beim ersten Aufruf legt das Postfix-Startup-Skript einige Dateien und Verzeichnisse an. Dies sollte keine Probleme bereiten, sollte aber wie bereits erwähnt nur beim ersten Start erfolgen. Sollten im laufenden Betrieb Änderungen in den Konfigurationsdateien gemacht werden, genügt das Kommando

 
postfix reload 

Um die Sicherheit von postfix noch etwas zu erhöhen ist es möglich, die einzelnen Postfix-Dämonen in einer "chroot"-Umgebung laufen zu lassen. Beispiele dazu liegen in examples/chroot-setup des Sourcebaumes.

# ====================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#                (yes)   (yes)   (yes)   (never) (50)
# ====================================================================
. . .
smtp      inet  n        -        -        -        5        smtpd
pickup    fifo  n        n        -        60       1        pickup
cleanup   unix  -        -        -        -        0        cleanup
qmgr      fifo  n        -        -        300      1        qmgr

Postfix im Einsatz

Auch im laufenden Betrieb ist Postfix pflegeleicht. Die wenigen für den Mailadministrator relevanten Kommandozeilen-Utilities sind folgende:

Das Kommando postfix dient zum Steuern des gesamten Systems. Damit kann der Administrator das Mailsystem starten oder herunterfahren, die Konfiguration neu laden, ohne das Mailsystem ganz runterfahren zu müssen. oder ähnliches. Dieses Kommando ist dem Superuser vorbehalten.

ähnlich Sendmails Kommando newaliases ist postalias für die Mail-Aliases zuständig

postcat zeigt in der aktuellen Postfix-Version den Inhalt der Queues an

postconf zeigt die in der Datei main.cf gesetzten Werte an.

postdrop wird auf solchen Systemen verwendet, die kein für alle schreibbares Verzeichnis für die "maildrop"-Queue haben. postdrop wird vom Kommando sendmail ausgeführt.

postkick dient als Schnittstelle zu internen -ommunikationskanälen, etwa für Shellskripts.

postlock stellt ein Postfix-kompatibles Mailbox-Locking zur Verfügung, etwa für Shellskripts.

postlog stellt für externe Programme oder Shellskripts eine Postfix-kompatible Logging-Funktion bereit.

postmap stellt in etwa dieselbe Funktion wie makemap zur Verfügung und generiert die Lookup-Tabellen, je nach System als hash (db) oder dbm.

postsuper ist das Tool, das die Mails in den verschiedenen Queues verschiebt. Das Postfix-Startskript führt dieses Kommando aus.

Wer den alten Sendmail gewöhnt ist, kann auch gewohnte Kommandos wie

 
sendmail -q    

zum Absenden der Mails in der Queue

 
sendmail -bp          

zum Anzeigen der Mail-Queue verwenden. Außer sendmail -v sollten alle gewohnten Befehle funktionieren. Dies erleichtert den Umstieg von Sendmail auf Postfix ungemein.

Virtuelle Domains

Postfix kann auch mit "virtual domains" umgehen. Das ist vor allem für Internet Service Provider interessant. Anstatt für jede Domäne einen eigenen Mailserver aufzubauen, kann Postfix das genauso wie Sendmail oder Qmail übernehmen. Wer das schon einmal unter Sendmail konfiguriert hat, wird erstaunt sein, wie einfach es ist. Am besten verwendet man dazu die leere Datei /etc/postfix/virtual aus den Beispielen. Die Einträge sollen in etwa folgendermaßen aussehen:

bereich.com EGAL WAS HIER STEHT
longariva@bereich.com grlongar
reimer@bereich.com reimer@softbaer.de
info@bereich.com grlongar, bnreimer, xwolf@xwolf.com
mein-zahnarzt.net Zahnarztportal
info@mein-zahnarzt.net info@softbaer.de 

In der ersten Zeile wird die Domäne ohne Mailadresse angegeben. Der rechte Teil spielt hier keine Rolle - als Tipp: eine kurze Erklärung zur Domäne kann ganz hilfreich sein. Darauf folgen die EMail-Adressen, die Postfix annehmen soll. Im rechten Teil stehen die (existierenden) Benutzeraccounts oder externe EMail-Adressen, an die Postfix die Mail weiterleiten soll. Postfix akzeptiert nur die hier eingetragenen Adressen. In /etc/postfix/main.cf muß man die Datei noch bekannt machen, je nach installiertem System mit db- oder dbm-Hashes:

#virtual_maps = dbm:/etc/postfix/virtual
virtual_maps = hash:/etc/postfix/virtual

Nach einer Änderung in der Datei sollte der Administrator nicht vergessen, postmap /etc/postfix/virtual aufzurufen, um die Hashtabelle für Postfix zu generieren. Sollten Hosts über eine Dialin-Verbindung die Mails an den Mailserver abschicken, kann es not- wendig sein, die Domäne des Providers, über den der Dialin erfolgt, zusätzlich als akzeptierte Relay-Domain einzutragen:

relay_domains = $mydestination, einwahl.provider.de, noch.einer.de 

Verschickt nämlich jemand von einem solchen Host aus eine Mail - zwar mit korrekter Absenderadresse - an jemanden außerhalb einer von Postfix verwalteten Domain, wird diese Mail nicht akzeptiert, weil Postfix die Domäne des Hosts überprüft.

Die meisten Provider bieten keine feste IP-Adresse für ihre Kunden; damit erscheinen die Dialin-Hosts unter der Domäne des Providers. Es sollten hier wirklich nur die allernotwendigsten Domänen oder Hosts eingetragen wer- den! Abhilfe könnte hier das weiter unten erläuterte "POP before SMTP" bieten.

Auf die Einträge in den DNS-Server soll hier nicht weiter eingegangen werden. Natürlich hat es keinen Sinn, virtuelle Domänen einzurichten, wenn der entspre- chende MX-Eintrag nicht auf den Postfix-Server zeigt.

Mail Relaying durch POP before SMTP

Generell ist es keine gute Idee, jedem Host zu erlauben, Mails auf dem Server abzulegen und weiterzuschicken. Genau dies benutzen nämlich die Mail-Spammer, um ihre Mails zu verteilen: auf einem schlecht administrierten Mailserver werden Mails abgelegt. Der sichtbare Absender einer solchen Mail ist in der Regel eine nichtexistierende Adresse (das SMTP Protokoll sieht hier keine Überprüfungsmechanismen vor), und der oder die Empfänger sind real existierende Adressen. Die Mails werden zugestellt, und der Empfänger hat in der Regel keine Chance festzustellen, woher die Mail tatsächlich kam. Der Absender ist gefälscht; als Absenderhost steht der angegriffene Mailhost im Header.

Lediglich der Rechner, der den Connect zum Mailhost aufgebaut hat, ist im Header ersichtlich. Meistens ist das ein Dialin-Account, der einmalig für solche Aktionen verwendet und danach nie wieder benutzt wird. Außerdem kann ein "normaler" Benutzer nichts mit den Informationen eines Mailheaders anfangen. Somit bleiben die Absender weitgehend anonym. Deshalb soll kein Rechner, der über das Internet erreichbar ist, Mails relayen!

VERBOSE=off
LOGABSTRACT=none
MAILHOME=$HOME/Mail
FRIENDS=$MAILHOME/friends
SPAM=$MAILHOME/spam
WORK=$MAILHOME/work
LISTS=$MAILHOME/lists

:0
* ^From.*bnreimer@(office\.|)softbaer\.de.*
  $FRIENDS

:0
* ^(To|Cc).*info@softbaer\.de.*
  $WORK

:0
* ^(From|To|Cc).*BUGTRAQ@SECURITYFOCUS.COM.*
  $LISTS

:0
* ^Subject: .*FREE .*
  $SPAM

Eine Möglichkeit um auftretende Probleme zu lösen - man will ja schließlich nicht wirklich jedem den Zugang verwehren - ist das so genannte POP before SMTP. SMTP bietet per se keine Authentifizierungsmöglichkeit. Es gibt zwar einige Erweiterungen des SMTP-Protokolls; diese muß aber auch der sendende Client unterstützen. Deshalb wird oft folgender einfacher Trick angewandt: Der Client (oder besser: der Benutzer) loggt sich in den POP-Server ein und holt seine Mails ab. Dazu muß er sich Login und Paßwort authentifizieren. Nun kann man den POP Server "aufbohren" und ihn anweisen, den gerade eben authentifizierten Host in eine Tabelle einzutragen. Beim Versenden von Mails schaut Postfix in dieser Tabelle nach und gestattet das Weitersenden von Mails von eben diesem Host. Nach einer gewissen Zeit löscht Postfix die Einträge wieder.

Das Paket DRAC (Dynamic Relay Authorization Control Daemon, [6]) wurde ursprünglich für Sendmail entwickelt. Es besteht aus einem Patch für den weit verbreiteten (freien) POP-Daemon qpopper [7] von Qualcomm und einem Dämon. Der Patch bewirkt, daß qpopper sich nach erfolgreicher Authentifizierung an den dracd verbindet und diesem die aktuelle Adresse des Rechners mitteilt. Der dracd schreibt diese dann in eine bestimmte Datei, die Postfix ausliest.

Der dazu nötige Eintrag in /etc/postfix/main.cf lautet:

smtpd_recipient_restrictions = permit_mynetworks \
check_client_access hash:/etc/postfix/client_access \
check_relay_domains

Auch hier ist zu beachten, ob man Hashes in db- oder dbm-Form verwendet. Den dracd muß man natürlich auch entsprechend konfigurieren.

Generell sollte man möglichst wenig Rechnern Zugriff gestatten; nicht nur um sich und seine Benutzer zu schützen, sondern auch um dem Phänomen SPAM entgegenzuwirken, das täglich Millionen von Dollar an Kosten verursacht - irgendjemand muß ja für das Datenaufkommen zahlen!

Postfix-Erweiterungen

Wegen des modularen Aufbaus von Postfix läßt sich das Paket sehr leicht erweitern. Es ist beispielsweise sehr leicht möglich, einen Virenscanner für einkommende Mails in Postfix einzubauen. Dazu kann es ein externes Programm an zwei Stellen aufrufen: entweder gleich beim Eintreffen der Mail, bevor die Mail in die Postfix-Queue übernommen wird, oder sobald die Mail in die Systemmailbox geschrieben wird - also wenn die Mail die Postfix-Queue wieder verläßt. In /etc/postfix/main.cf ist dazu ein lokales Mailverteilprogramm aufzurufen:

 
mailbox_command = /local/bin/viruscheck

Man sollte nicht vergessen, die Mail nach dem Check auch wirklich in die Mailbox zu schreiben, etwa mit Procmail [8]. Das Verwenden von Procmail hat übrigens den Vorteil, daß eventuell von den Benutzern definierte Filter automatisch verwendet werden. Das heißt, daß eine möglicherweise vorhandene .procmailrc im Home-Verzeichnis eines Benutzers automatisch verwendet wird, ohne daß der Benutzer die Mails mittels .forward an Procmail weiterleitet (siehe Kasten .procmailrc). Natürlich ist das nur ein sehr allgemeines Beispiel, das auf keinen Fall die Funktion von procmail erklären kann. Es zeigt aber, wie die Regeln auf einfachen regulären Ausdrücken basieren - damit sollte jeder, der etwas Perl, sed, awk oder grep>beherrscht, zurechtkommen. Lesen der Man-Pages von Procmail (procmail(1), procmailrc(5), procmailsc(5), procmailex(5)) hilft in jedem Fall weiter.

Die Möglichkeiten, externe Programme in Postfix einzubinden, sind sehr vielfältig. Beispielsweise könnte der Administrator eine automatische Ver/Entschlüsselung von Mails vom Firmensitz zu einer Außenstelle implementieren, damit sie "unterwegs" nicht lesûar sind. Außerdem kann ein SPAM-Filter an zentraler Stelle eingebaut werden. Ein solcher ist wesentlich einfacher zu verwalten als Procmail-Filter für jeden einzelnen Benutzer. Der Fantasie der Mailadministratoren sind (fast) keine Grenzen gesetzt. (hmi)