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)