Modular und sicher. Pfad: Erschienen im Linux-Magazin 06/2000

Transkript

1 Seite 1 von 9 Pfad: Erschienen im Linux-Magazin 06/2000 Postfix - der Sendmail-Ersatz? Modular und sicher Gregor Longariva Täglich senden weltweit über 100 Millionen Benutzer s. Erstaunlich ist, daß nach wie vor Eric Allman's betagter Sendmail der am weitesten verbreitete Mail Transfer Agent ist. Postfix hat das Zeug, Sendmail als Standard-Mailer abzulösen. 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. Ursprünglich hieß das Projekt "VMailer". IBMs Rechtsanwälte haben aber herausgefunden, daß der Name zu ähnlich dem eines eingetragenen Markenzeichens war. Wietse Venemas Antwort auf meine Frage nach dem Namen seines Mailerprojekts: > 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.

2 Seite 2 von 9 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

3 Seite 3 von 9 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. Postfix-Plattformen Postfix ist derzeit auf folgende Unix-Systemen erfolgreich getestet: AIX AIX 4.1.x AIX BSD/OS 2.x BSD/OS 3.x BSD/OS 4.x FreeBSD 2.x FreeBSD 3.x FreeBSD 4.x HP-UX 9.x HP-UX 10.x HP-UX 11.x IRIX 5.x IRIX 6.x Mac OS X server Linux Debian Linux Debian 2.x Linux RedHat 4.x Linux RedHat 5.x Linux RedHat 6.x Linux Slackware 3.5 Linux Slackware 4.0 Linux Slackware 7.0 Linux SuSE 5.x Linux SuSE 6.x NEXTSTEP 3.x NetBSD 1.x OPENSTEP 4.x Digital UNIX V3-5 OpenBSD 2.x Reliant UNIX 5.x Rhapsody 5.x SunOS 4.1.x Solaris Ultrix 4.x 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:

4 Seite 4 von 9 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. Datei master.cf # ==================================================================== # service type private unpriv chroot wakeup maxproc command + args

5 Seite 5 von 9 # (yes) (yes) (yes) (never) (50) # ====================================================================... smtp inet n smtpd pickup fifo n n pickup cleanup unix cleanup qmgr fifo n 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

6 Seite 6 von 9 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 -Adressen, die Postfix annehmen soll. Im rechten Teil stehen die (existierenden) Benutzeraccounts oder externe - 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

7 Seite 7 von 9 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.procmailrc :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!

8 Seite 8 von 9 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. Untersuchung Mailer im Internet Anfang April 2000 veröffentlichte Dan Bernstein, der Autor von Qmail, in den Newsgroups comp.mail.misc, comp.mail.sendmail,comp.security.unix eine Untersuchung über die Anteile der verschiedenen Mailer im Netz. Dazu schaute er sich 1/256 aller "second level".com-domains an, insgesamt IP-Adressen, und bekam in Fällen Kontakt auf dem SMTP-Port. Für die Verhältnisse in Europa mag diese Untersuchung wenig relevant sein, sie gestattet aber trotzdem einen gewissen Einblick. Einige Details der Untersuchung: Unix ist mit einem Anteil von 65% das meistgebräuchliche Betriebssystem; etwa 22% der Hosts sind Windows, und bei zirka 8% ist keine eindeutige Aussage möglich. Sendmail, Inc. spricht auf seiner Webseite von einem Marktanteil von "über 75 Prozent", diese Zahl ist aber schon ein paar Jahre alt. die meisten gefundenen Sendmail-Versionen sind bekanntermaßen fehlerhaft; in einigen Fällen kann man sich hierüber unautorisierten Zugriff verschaffen. Die wenigsten Server haben eine aktuelle Sendmail-Version. Offenbar nehmen die meisten Sendmail-Nutzer, was gerade auf einem System installiert ist. Die "Markt"-Anteile im einzelnen: Anteil % Anzahl Mailer UNIX Sendmail Windows Ipswitch IMail Windows Microsoft Exchange UNIX qmail UNIX/Windows Software.com Post.Office 294 unsicher 231 UNIX Exim 168 Windows Gordano NTMail

9 Seite 9 von UNIX/Windows Netscape Messaging Server 134 MacOS Eudora Internet Mail Server, früher AIMS 122 UNIX IBM Postfix, früher VMailer 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) Infos [1] Wietse Venema's postfix, [2] Eric Allman's sendmail, [3] Bryan Costales, Eric Allman sendmail, 2nd Edition O'Reilly, 1997 [4] Dan Bernstein's qmail, [5] postfix download sites, [6] Dynamic Relay Authorization Control Daemon, [7] Qpopper - POP3 Daemon, [8] procmail, Der Autor Gregor Longariva studierte Informatik an der Uni Erlangen. Während des Studiums gründete er die Firma SOFTbaer, die sich in erster Linie mit dem Thema Sicherheit und Netzwerkadministration auf Unix-Basis beschäftigt. Nebenbei ist er noch als Administrator des CIP-Pools der Informatik an der Uni Erlangen tätig und beschäftigt sich neben HPUX und Irix vor allem mit Solaris und Linux. Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links" nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedruckten Fassung entsprechen. webmaster@linux-magazin.de 2003 Linux New Media AG Last modified: :07