|
|
|
Linux Netzwerker-HandbuchTony Bautts, Terry Dawson & Gregor N. Purdy 3. Auflage Juli 2005 ISBN 3-89721-414-8 382 Seiten Weitere Informationen zur gedruckten Version des Buches finden Sie unter: www.oreilly.de/catalog/linag3ger/ Zur Übersicht aller OpenBooks |
 |
 |
 |
 |
Es wird behauptet, dass man kein echter Unix-Systemadministrator ist, wenn man noch keine sendmail.cf-Datei bearbeitet hat. Es wird auch behauptet, dass man verrückt sei, wenn man es ein zweites Mal tut.
Glücklicherweise müssen Sie die kryptische sendmail.cf-Datei inzwischen nicht mehr direkt bearbeiten. Die neuen Versionen von sendmail bieten ein Konfigurationswerkzeug, das die sendmail.cf-Datei auf der Grundlage viel einfacherer Makrodateien für Sie erzeugt. Sie müssen die komplexe Syntax der sendmail.cf-Datei nicht mehr verstehen. Stattdessen identifizieren Sie die Funktionen, die Sie in Ihre Konfiguration einfügen wollen, mit Hilfe der Makrosprache und geben die Parameter an, die bestimmen, wie diese Funktionen arbeiten. Ein traditionelles Unix-Hilfsprogramm namens m4 übernimmt dann Ihre Makro-Konfigurationsdaten und mischt sie mit den Daten, die es den Vorlagedateien entnimmt, in denen die eigentliche sendmail.cf-Syntax enthalten ist. Aus diesem Konglomerat entsteht schließlich Ihre sendmail.cf-Datei.
sendmail ist ein unglaublich leistungsfähiges Mail-Programm. Es ist aber auch unglaublich schwer zu lernen und zu verstehen. Jedes Programm, dessen endgültige Referenz (sendmail von Bryan Costales und Eric Allman, veröffentlicht von O'Reilly) 1200 Seiten lang ist, schreckt die meisten Leute ab. Und kein Programm, das so komplex ist wie sendmail, kann vollständig in einem einzigen Kapitel abgehandelt werden. Dieses Kapitel stellt sendmail vor und beschreibt, wie Sie es installieren, konfigurieren und testen. Als Beispiel dient eine einfache Konfiguration für die virtuelle Brauerei. Wenn die hier präsentierten Informationen Ihnen die Aufgabe der sendmail-Konfiguration weniger bedrohlich erscheinen lassen, wagen Sie sich hoffentlich auch bald an die Erstellung komplizierterer Konfigurationen.
sendmail ist in den meisten Linux-Distributionen in vorgefertigter Form enthalten. Ungeachtet dieser Tatsache gibt es einige gute Gründe dafür, sendmail aus den Quellen zu installieren. Das gilt vor allem, wenn Sie Wert auf ausreichende Sicherheit legen. sendmail wird häufig geändert, um Sicherheitsprobleme zu beheben und neue Funktionen einzuführen. Das Stopfen von Sicherheitslücken und die Einführung neuer Funktionen erfordern folglich eine Aktualisierung der sendmail-Version auf Ihrem System. Außerdem haben Sie eine größere Kontrolle über die sendmail-Umgebung, wenn Sie das Programm selbst aus den Quellen zusammenstellen. Melden Sie sich bei der Mailingliste sendmail-announce an, damit Sie benachrichtigt werden, wenn neue sendmail-Versionen herauskommen, und schauen Sie regelmäßig auf der Website http://www.sendmail.org/ vorbei, um über potenzielle Gefahren für die Sicherheit und die neuesten sendmail-Entwicklungen auf dem Laufenden zu bleiben.
Laden Sie die sendmail-Quellcode-Distribution und die Signaturdatei der Quellcode-Distribution von http://www.sendmail.org/current-release.html, von einer der gespiegelten Sites oder von ftp://ftp.sendmail.org/pub/sendmail/ herunter. Hier ist ein Beispiel mit ftp:
Falls Sie die aktuellen sendmail-PGP-Schlüssel nicht in Ihrem »Schlüsselbund« haben, dann laden Sie die PGP-Schlüssel herunter, die Sie benötigen, um die Signatur zu verifizieren. Führen Sie den folgenden Schritt in der ftp-Sitzung aus, um die Schlüssel für das aktuelle Jahr herunterzuladen:
Wenn Sie die neuen PGP-Schlüssel heruntergeladen haben, fügen Sie sie zu Ihrem Schlüsselbund hinzu. Im folgenden Beispiel wird gpg (Gnu Privacy Guard) verwendet:
Von den zwölf exportierbaren Schlüsseln in der PGPKEYS-Datei wird nur einer in Ihren Schlüsselbund exportiert. Der Kommentar not changed für die anderen elf Schlüssel zeigt, dass diese bereits in Ihrem Schlüsselbund installiert sind. Wenn Sie PGPKEYS das erste Mal importieren, werden alle zwölf Schlüssel zu Ihrem Schlüsselbund hinzugefügt.
Bevor Sie den neuen Schlüssel benutzen, müssen Sie seinen Fingerprint verifizieren, wie in diesem gpg-Beispiel gezeigt:
Vergleichen Sie den angezeigten Fingerprint mit Tabelle 12-1, die die Fingerprints für die sendmail-Signaturschlüssel enthält.
Wenn der Fingerprint korrekt ist, können Sie den Schlüssel signieren und damit validieren. In diesem gpg-Beispiel signieren wir den neu importierten sendmail-Schlüssel:
Nachdem die sendmail-Schlüssel zum Schlüsselbund hinzugefügt und signiert wurden,1 verifizieren Sie die sendmail-Distribution-tar-Datei. Wir benutzen hier die Signaturdatei sendmail.8.12.11.tar.gz.sig, um die komprimierte tar-Datei sendmail.8.12.11.tar.gz zu verifizieren:
Auf dieser Grundlage kann die tar-Datei mit der Distribution sicher wiederhergestellt werden. Die tar-Datei erzeugt ein Verzeichnis mit einem Namen, der sich aus der Nummer der sendmail-Version ableitet. Die in diesem Beispiel heruntergeladene tar-Datei würde also ein Verzeichnis namens sendmail-8.12.11 anlegen. Die Dateien und Unterverzeichnisse, die verwendet werden, um sendmail zu kompilieren und zu konfigurieren, sind in diesem Verzeichnis enthalten.
Kompilieren Sie sendmail mit Hilfe des Dienstprogramms Build, das von den sendmail-Entwicklern angeboten wird. Auf den meisten Systemen sind nur ein paar Befehle - vergleichbar den nachfolgend gezeigten - nötig, um sendmail zu kompilieren:
Ein einfacher Build-Befehl sollte funktionieren, solange Sie keine allzu speziellen Anforderungen haben. Sollte das allerdings der Fall sein, erzeugen Sie eine eigene Konfiguration, eine so genannte Site-Konfiguration, für die Benutzung durch den Build-Befehl. sendmail sucht im Verzeichnis devtools/Site nach Site-Konfigurationen. Auf einem Linux-System sucht Build nach Site-Konfigurationsdateien namens site.linux.m4, site.config.m4 und site.post.m4. Falls Sie einen anderen Dateinamen verwenden, dann identifizieren Sie die Datei auf der Build-Kommandozeile mit dem Argument -f. Zum Beispiel:
Wie die Dateierweiterung .m4 andeutet, wird die Build-Konfiguration mit m4-Befehlen erzeugt. Es werden drei Befehle verwendet, um die von Build benutzten Variablen zu setzen.
Nehmen Sie etwa an, dass die Datei devtools/OS/Linux, die die Build-Charakteristika für alle Linux-Systeme definiert, die Manpages im Verzeichnis /usr/man ablegt:2
Nehmen Sie weiterhin an, dass unsere Linux-Systeme Manpages in /usr/share/man speichern. Indem Sie die folgende Zeile zur Datei devtools/Site/site.config.m4 hinzufügen, weisen Sie Build an, den Manpage-Pfad auf /usr/share/man zu setzen:
Hier ist ein weiteres Beispiel. Stellen Sie sich vor, Sie müssen sendmail so konfigurieren, dass es Daten von einem LDAP-Server liest. Nehmen Sie außerdem an, dass Sie den Befehl sendmail -bt -d0.1 verwenden, um die sendmail-Compiler-Optionen zu überprüfen, und dass der String LDAPMAP nicht in der »Compiled with:«-Liste auftaucht. Sie müssen LDAP-Unterstützung hinzufügen, indem Sie die LDAP-Werte in der Datei site.config.m4 setzen und sendmail, wie unten gezeigt, neu kompilieren:
Beachten Sie den Build-Befehl. Wenn Sie Änderungen an der Datei siteconfig.m4 vornehmen und Build erneut ausführen, verwenden Sie das Kommandozeilenargument -c, um Build von den Änderungen in Kenntnis zu setzen.
Die meisten eigenen Build-Konfigurationen sind nicht viel komplizierter als diese Beispiele. Es gibt jedoch mehr als 100 Variablen, die für die Build-Konfiguration gesetzt werden können - zu viele, um sie in einem Kapitel zu behandeln. Eine vollständige Liste finden Sie in der Datei devtools/README.
Da das sendmail-Binary nicht mehr als set-user-ID root installiert wird, müssen Sie besondere Benutzer- und Gruppen-IDs erzeugen, bevor Sie sendmail installieren. Traditionell wurde das sendmail-Programm auf set-user-ID root gesetzt, so dass jeder Benutzer Mail über die Kommandozeile übermitteln und in das Warteschlangenverzeichnis schreiben lassen konnte. Allerdings ist dazu nicht wirklich ein Programm mit der Benutzer-ID root erforderlich. Wenn die richtigen Verzeichnisberechtigungen gesetzt sind, funktioniert ein Programm mit set-group-ID prima und ist darüber hinaus nicht so ein großes Sicherheitsrisiko.
Legen Sie den Benutzer und die Gruppe smmsp an. Diese benutzt sendmail, wenn es als Mail-Submission-Programm läuft. Dazu verwenden Sie einfach die auf Ihrem System üblichen Werkzeuge. Hier sind die /etc/passwd- und /etc/group-Einträge, die auf einem Beispielsystem unter Linux hinzugefügt wurden:
Bevor Sie ein neu kompiliertes sendmail installieren, sichern Sie das aktuelle sendmail-Programm, die sendmail-Dienstprogramme und Ihre aktuellen sendmail-Konfigurationsdateien. (Man kann nie wissen, möglicherweise müssen Sie zurück zur alten sendmail-Konfiguration wechseln, falls die neue nicht wie erwartet funktioniert.) Nachdem das System gesichert ist, installieren Sie das neue sendmail und die Dienstprogramme:
Wenn Sie Build install ausführen, werden sendmail und die Dienstprogramme installiert und mehr als 100 Ausgabezeilen erzeugt. Die Installation sollte fehlerfrei verlaufen. Beachten Sie, dass Build den Benutzer und die Gruppe smmsp verwendet, wenn es das Verzeichnis /var/spool/clientmqueue anlegt und das sendmail-Programm installiert. Ein kurzer Blick auf die Eigentümerschaft und die Berechtigungen für das Warteschlangenverzeichnis und das sendmail-Programm zeigt Folgendes:
Nachdem sendmail installiert wurde, muss es konfiguriert werden. Dieses Thema nimmt den größten Teil dieses Kapitels ein.
sendmail liest eine Konfigurationsdatei (normalerweise mit der Bezeichnung /etc/mail/sendmail.cf oder in älteren Distributionen /etc/sendmail.cf oder sogar /usr/lib/sendmail.cf), die für sendmail einfach zu analysieren, für einen Systemadministrator aber nicht einfach zu lesen oder zu bearbeiten ist. Glücklicherweise muss bei der sendmail-Konfiguration die Datei sendmail.cf kaum gelesen oder bearbeitet werden. Der Großteil der sendmail-Konfiguration erfolgt über Makros. Die Makromethode erzeugt Konfigurationen, mit denen sich die meisten Installationen abdecken lassen, Sie haben aber immer noch die Möglichkeit, die resultierende sendmail.cf von Hand anzupassen.
Der m4-Makroprozessor verarbeitet eine Makrokonfigurationsdatei und erzeugt daraus die Datei sendmail.cf. Aus Gründen der Bequemlichkeit bezeichnen wir in diesem Kapitel die Makrokonfigurationsdatei als sendmail.mc. Nennen Sie Ihre Konfigurationsdatei nicht sendmail.mc. Geben Sie ihr stattdessen einen aussagekräftigeren Namen. Sie könnten sie beispielsweise nach dem Host benennen, für den sie gedacht ist - in unserem Fall also vstout.m4. Wenn Sie der Konfigurationsdatei einen eindeutigen Namen geben, können Sie alle Konfigurationsdateien im gleichen Verzeichnis vorhalten und sich dadurch Ihr Administratordasein ein wenig erleichtern.
Der Konfigurationsvorgang besteht im Wesentlichen darin, eine sendmail.mc-Datei anzulegen, die Ihre gewünschte Konfiguration beschreibt, und diese sendmail.mc-Datei dann mit m4 verarbeiten zu lassen. Die Datei sendmail.mc kann einfache m4-Befehle wie define oder divert enthalten, allerdings sind die Zeilen in der Datei, die die größten Auswirkungen auf die Ausgabedatei haben, die sendmail-Makros. Die sendmail-Entwickler definieren die Makros, die in der sendmail.mc-Datei benutzt werden. Der m4-Makroprozessor erweitert die Makros zu Einheiten der sendmail.cf-Syntax. Die Makroausdrücke, die in die Datei sendmail.mc aufgenommen werden, beginnen mit dem Makronamen (in Großbuchstaben), gefolgt von den Parametern (eingeschlossen in Klammern), die in der Makroerweiterung verwendet werden. Die Parameter können als unveränderte Werte (Literal) in die sendmail.cf-Ausgabe übernommen werden. Sie können aber auch dazu benutzt werden, um die Art und Weise zu bestimmen, wie die Makroverarbeitung vonstatten geht.
Im Gegensatz zu einer sendmail.cf-Datei, die mehr als 1000 Zeilen lang sein kann, ist eine einfache sendmail.mc-Datei oft weniger als 10 Zeilen lang (ohne Kommentare).
Zeilen in der sendmail.mc-Datei, die mit dem #-Zeichen beginnen, werden von m4 nicht beachtet und landen als Ausgabe direkt in der Datei sendmail.cf. Das ist ganz nützlich, falls Sie sowohl in sendmail.mc als auch in sendmail.cf kommentieren wollen, was Ihre Konfiguration macht.
Um Kommentare in sendmail.mc zu setzen, die nicht in die Datei sendmail.cf gelangen, benutzen Sie die Befehle m4 divert oder dnl. divert(-1) unterbindet alle Ausgaben. divert(0) setzt die Ausgabe wieder auf den Vorgabewert zurück. Alle Zeilen dazwischen werden verworfen. Blöcke mit Kommentaren, die nur in der Datei sendmail.mc auftauchen sollen, werden normalerweise durch divert(-1)- und divert(0)-Befehle eingeschlossen. Um das gleiche Ergebnis für eine einzelne Zeile zu erreichen, verwenden Sie den dnl-Befehl am Anfang einer Zeile, die nur als Kommentar in sendmail.mc stehen soll. Der Befehl dnl bedeutet: »Lösche alle Zeichen bis einschließlich zum nächsten Zeilenwechsel (Newline).« Manchmal wird dnl an das Ende einer Makrobefehlszeile angehängt, damit alles, was dieser Zeile hinzugefügt wird, als Kommentar betrachtet wird.
Oft gibt es in einer sendmail.mc-Datei mehr Kommentare als Konfigurationsbefehle! Die folgenden Abschnitte erläutern die Struktur der sendmail.mc-Datei sowie die in der Datei verwendeten Befehle.
Einige Befehle werden verwendet, um die meisten sendmail.mc-Dateien zu erstellen. Im Folgenden finden Sie ein paar dieser normalerweise benutzten Befehle sowie die allgemeine Abfolge dieser Befehle in der sendmail.mc:
Bei den Befehlen in dieser Liste, die komplett großgeschrieben werden, handelt es sich um sendmail-Makros. Laut Konvention benutzen die sendmail-Entwickler Großbuchstaben für die Namen der von ihnen erzeugten Makros. Es gibt mehr als die gezeigten Makros. In der Datei cf/README finden Sie eine vollständige Liste der sendmail-Makros. In der obigen Liste sind alle bis auf den Befehl define sendmail-Makros. Der define-Befehl, der in Kleinbuchstaben geschrieben wurde, ist ein einfacher m4-Befehl. Alle einfachen m4-Befehle werden in Kleinbuchstaben geschrieben. Es gibt weitere m4-Befehle, die in sendmail.mc-Dateien eingesetzt werden. Um genau zu sein, können Sie jeden zulässigen m4-Befehl in einer sendmail.mc-Datei verwenden. Die oben aufgeführten Befehle bilden jedoch den wesentlichen Befehlssatz, mit dem die allgemeine Reihenfolge dargestellt werden soll, in der Befehle in einer sendmail.mc-Datei stehen. In den folgenden Abschnitten untersuchen wir jeden dieser Befehle näher.
Das Makro VERSIONID definiert Informationen zur Versionskontrolle. Dieses Makro ist zwar optional, Sie finden es aber in den meisten sendmail-m4-Dateien. Der Befehl besitzt kein vorgeschriebenes Format für das Argumente-Feld. Sie können alle gewünschten Versionsinformationen eintragen. Im Allgemeinen sollte es kompatibel mit dem von Ihnen verwendeten Revisionskontrollsystem sein. Falls Sie kein Revisionskontrollsystem einsetzen, dann schreiben Sie einen aussagekräftigen Kommentar in dieses Feld. Auf einem System ohne Versionskontrolle könnte das VERSIONID-Makro einer sendmail.mc-Datei etwa so aussehen:
Beachten Sie, dass das Argument in einfache Anführungszeichen eingeschlossen ist, wobei das öffnende Anführungszeichen ` ist und das schließende Anführungszeichen '. Wenn das Argument, das an das sendmail-Makro übergeben wird, Leerzeichen, Sonderzeichen oder Werte, die als m4-Befehle fehlinterpretiert werden könnten, enthält, muss das Argument von diesen besonderen Anführungszeichen umgeben sein. Das gilt für alle Makros, nicht nur für VERSIONID.
Das OSTYPE-Makro ist ein notwendiger Bestandteil der Makro-Konfigurationsdatei. Der OSTYPE-Makrobefehl lädt eine m4-Quelldatei, die betriebssystemspezifische Informationen definiert, wie etwa Datei- und Verzeichnispfade, Mailer-Pfadnamen und systemspezifische Mailer-Argumente. Das einzige Argument, das an den OSTYPE-Befehl übergeben wird, ist der Name der m4-Quelldatei, in der die betriebssystemspezifischen Informationen stehen. OSTYPE-Dateien werden im Verzeichnis cf/ostype gespeichert. Der Befehl OSTYPE(`linux') verarbeitet die Datei cf/ostype/linux.m4.
Die sendmail-Distribution bietet mehr als 40 vordefinierte Betriebssystem-Makrodateien im Verzeichnis cf/ostype. Falls Sie wollen, können Sie für eine spezielle Linux-Distribution auch Ihre eigenen erstellen. Einige Linux-Distributionen, namentlich die Debian-Distribution, bringen ihre eigene Definitionsdatei mit, die vollständig Linux-FHS-konform ist. Wenn das bei Ihrer Distribution der Fall ist, dann verwenden Sie diese Definition anstelle der Datei generic-linux.m4. Das OSTYPE-Makro muss einer der ersten Befehle sein, die in der Datei sendmail.mc stehen, da viele andere Definitionen davon abhängen.
Das DOMAIN-Makro verarbeitet die angegebene Datei aus dem Verzeichnis cf/domain. Eine DOMAIN-Datei ist nützlich, wenn Sie eine große Anzahl von Maschinen im gleichen Netzwerk auf eine standardisierte Weise konfigurieren. Mit dieser Datei werden nortmalerweise Elemente wie der Name von Mail-Relay-Hosts oder Hubs konfiguriert, die alle Hosts in Ihrem Netzwerk benutzen.
Um das Makro DOMAIN effektiv nutzen zu können, müssen Sie Ihre eigene Makrodatei anlegen, in der die Standarddefinitionen enthalten sind, die Sie für Ihre Site benötigen, und diese Datei im Unterverzeichnis domain ablegen. Falls Sie beispielsweise Ihre Domain-Makrodatei als cf/domain/vbrew.m4 gespeichert haben, würden Sie sie in Ihrer sendmail.mc folgendermaßen aufrufen:
Die sendmail-Distribution enthält mehrere Beispiele für Domain-Makrodateien, die Sie verwenden können, um Ihre eigenen zu erstellen. Eine ist die Datei domain/generic.m4, die in Beispiel 12-3 gezeigt wird.
Verwenden Sie das FEATURE-Makro, um vordefinierte sendmail-Funktionen in Ihre Konfiguration aufzunehmen. Es gibt eine große Anzahl von Funktionen - das cf/feature-Verzeichnis enthält mehr als 50 Feature-Dateien. In diesem Kapitel besprechen wir nur einige der gebräuchlicheren Funktionen. Ausführliche Informationen über alle Funktionen finden Sie in der Datei cf/README, die im Quellpaket enthalten ist.
Um eine Funktion zu benutzen, fügen Sie eine solche Zeile in die Datei sendmail.mc ein:
Dabei ist name der Name der Funktion. Manche Funktionen beachten einen optionalen Parameter in einem solchen Format:
Dabei ist param der anzugebende Parameter.
Mit dem m4-Befehl define setzen Sie Werte für die internen sendmail.cf-Makros, -Optionen oder -Klassen. Das erste Argument, das an define übergeben wird, ist der m4-Name der Variable, die gesetzt werden soll. Das zweite Feld enthält den Wert, auf den die Variable gesetzt wird. Hier ist ein Beispiel dafür, wie define benutzt wird, um ein sendmail.cf-Makro zu setzen:
Der oben gezeigte define-Befehl platziert Folgendes in die Datei sendmail.cf:
Das setzt das sendmail.cf-Makro $j, das den vollständigen Domainnamen des sendmail-Hosts enthält, auf vstout.vbrew.com. Im Allgemeinen ist es nicht notwendig, manuell einen Wert für $j einzustellen, da sendmail normalerweise den korrekten Namen für den lokalen Host vom System selbst bezieht.
Die meisten m4-Variablen enthalten einen vernünftigen Wert als Vorgabe und müssen daher in der m4-Quelldatei nicht ausdrücklich gesetzt werden. Der Befehl undefine setzt eine Variable wieder zurück auf ihren Vorgabewert. Zum Beispiel setzt
confDOMAIN_NAME zurück auf den Vorgabewert, selbst wenn die Konfiguration sie zuvor auf einen bestimmten Hostnamen gesetzt hatte.
Die Liste der m4-Variablen, die mittels define gesetzt werden können, ist ziemlich lang. In der Datei cf/README sind alle Variablen aufgeführt. Die Liste enthält den m4-Variablennamen, den Namen der entsprechenden sendmail.cf-Option, des Makros oder der Klasse, eine Beschreibung der Variable und den Vorgabewert, der verwendet wird, wenn Sie nicht ausdrücklich einen Wert für die Variable definieren.
Beachten Sie, dass der define-Befehl sich nicht darauf beschränkt, Werte für sendmail.cf-Makros, -Optionen und -Klassen zu setzen. Mit define können Sie auch Werte, die in den m4-Konfigurationen benutzt werden, sowie interne sendmail-Werte modifizieren.
Falls Sie wollen, dass sendmail Mail auf eine andere Weise transportiert als durch lokale Auslieferung, dann teilen Sie ihm mit Hilfe des Makros MAILER mit, welches Transportprotokoll verwendet werden soll. Einige sind unbedingt notwendig, einige werden selten verwendet und einige sind experimentell. Die Mailer-Argumente, die zusammen mit dem MAILER-Makro benutzt werden können, finden Sie in Tabelle 12-2.
Die meisten Hosts brauchen nur das SMTP-Transportprotokoll, um Mails zu anderen Hosts zu senden und von ihnen zu empfangen, sowie den local-Mailer, um Mails zwischen Benutzern auf dem System zu verschieben. Dazu fügen Sie sowohl MAILER(`local') als auch MAILER(`smtp') in die Makro-Konfigurationsdatei ein. (Das local-Mail-Transportprotokoll wird standardmäßig eingebunden, zum besseren Verständnis wird es normalerweise aber auch in der Makro-Konfigurationsdatei angegeben.)
Das MAILER(`local')-Makro fügt den local-Mailer hinzu, der lokale Mails zwischen den Benutzern des Systems ausliefert, und den prog-Mailer, der Mail-Dateien an Programme sendet, die auf dem System laufen. Das Makro MAILER(`smtp') fügt alle Mailer ein, die erforderlich sind, um SMTP-Mail über ein Netzwerk zu verschicken. Folgende Mailer werden durch das Makro MAILER(`smtp') in die Datei sendmail.cf eingefügt:
Jedes System, das mit dem Internet verbunden ist oder mit ihm kommuniziert, benötigt den MAILER(`smtp')-Mailer-Satz, und die meisten Systeme in isolierten Netzwerken verwenden diese Mailer, weil in ihrem Unternehmensnetzwerk TCP/IP zum Einsatz kommt. Ungeachtet der Tatsache, dass die große Mehrheit der sendmail-Systeme diese Mailer braucht, werden sie nicht standardmäßig installiert. Um SMTP-Mail zu unterstützen, müssen Sie das Makro MAILER(smtp) in Ihre Konfiguration aufnehmen.
Die Makros LOCAL_CONFIG, LOCAL_NET_CONFIG, LOCAL_RULESET und LOCAL_RULE_n ermöglichen es Ihnen, sendmail.cf-Konfigurationsbefehle direkt in die m4-Quelldatei zu schreiben. Diese Befehle werden genau so, wie sie geschrieben wurden, an die richtige Stelle der sendmail.cf-Datei kopiert. Die folgende Liste beschreibt, wo die Makros die von Ihnen bereitgestellten sendmail.cf-Konfigurationsbefehle platzieren.
Diese Makros bedeuten, dass alles, was in der Datei sendmail.cf erledigt werden kann, auch in der m4-Makro-Konfigurationsdatei erledigt werden kann, da Sie nicht nur Zugriff auf alle m4-Makros, sondern auch auf alle sendmail.cf-Befehle haben. Bevor Sie natürlich die sendmail.cf-Befehle benutzen können, müssen Sie eine Ahnung davon bekommen, wie sie funktionieren. Der nächste Abschnitt behandelt in aller Kürze die sendmail.cf-Konfigurationsbefehle.
Es ist selten nötig, die sendmail.cf-Befehle in Ihrer Konfiguration zu verwenden, da die von den sendmail-Entwicklern erzeugten sendmail-Makros die meisten möglichen Konfigurationen verarbeiten. Dennoch ist es sinnvoll, für jene seltenen Gelegenheiten, bei denen Ihnen eine Konfiguration über den Weg läuft, an die die sendmail-Entwickler nicht gedacht haben, etwas über die sendmail.cf-Befehle zu wissen. Tabelle 12-3 zeigt die sendmail.cf-Konfigurationsbefehle.
Alle Befehle in dieser Tabelle - bis auf die letzten beiden - können mit dem Makro LOCAL_CONFIG benutzt werden. Das Makro LOCAL_CONFIG ist dasjenige, das einem Abschnitt mit sendmail.cf-Befehlen voransteht, die dazu dienen, Werte für die Konfiguration zu definieren. Dabei kann es sich um sendmail.cf-Datenbankdeklarationen, -Makros oder -Klassenwerte handeln, also prinzipiell alles mit Ausnahme von Rewrite-Regeln. Trotzdem sind einige der sendmail.cf-Befehle, die in Tabelle 12-3 gezeigt werden, in der sendmail.mc-Datei einfach nicht erforderlich, selbst wenn Sie eine spezielle Konfiguration erzeugen.
Es gibt praktisch keinen Grund, die sendmail.cf-O-Befehle in die sendmail.mc-Konfiguration einzufügen, da alle sendmail.cf-Optionen mit Hilfe des define-Befehls und der m4-Variablen gesetzt werden können. Ebenso werden alle notwendigen M-Befehle durch m4-MAILER-Makros in die sendmail.cf-Datei eingefügt, weshalb es eher unwahrscheinlich ist, dass Sie LOCAL_CONFIG verwenden, um M-Befehle in Ihre Konfiguration einzufügen. Die T- und P-Befehle spielen eingeschränkte Rollen. Der T-Befehl fügt Benutzernamen zu der Liste mit Benutzern hinzu, denen es erlaubt ist, Mail unter dem Benutzernamen eines anderen Benutzers zu senden. Aus Sicherheitsgründen sollten Sie, was die Erweiterung dieser Liste angeht, sehr vorsichtig sein. Falls Sie es tun, können Sie die confTRUSTED_USERS-Definition in der m4-Datei oder das FEATURE(use_ct_file)-Makro verwenden und die Benutzernamen in der Datei /etc/mail/trusted-users definieren. Der P-Befehl definiert die Mail-Priorität, und ehrlich gesagt sind in der vorgegebenen sendmail.cf-Konfiguration bereits mehr Mail-Prioritäten definiert, als Sie jemals benötigen.
Die sendmail.cf-Befehle, die am häufigsten auf das LOCAL_CONFIG-Makro folgen, sind D, C, F und K. Sie alle können verwendet werden, um eigene Werte zu definieren, die später in einem selbst erstellten Regelsatz zum Einsatz kommen. Der D-Befehl setzt den Wert für ein sendmail.cf-Makro. Der C-Befehl fügt einer sendmail.cf-Klasse Werte von der Kommandozeile aus hinzu. Der F-Befehl fügt einer sendmail.cf-Klasse Werte aus einer Datei heraus zu. Der K-Befehl definiert eine Datenbank, aus der sendmail Werte beziehen kann. Alle Standard-sendmail.cf-Makros, -Klassen und -Datenbanken können über Standard-m4-Makros benutzt werden. D-, C-, F- oder K-Befehle werden der sendmail.mc-Konfiguration nur bei solchen seltenen Gelegenheiten hinzugefügt, wenn Sie Ihre eigenen privaten Makros, Klassen oder Datenbanken erzeugen.
Der H-Befehl definiert einen Mail-Header. Sämtliche Standard-Mail-Header sind bereits in der vorgegebenen Konfiguration definiert; es ist unwahrscheinlich, dass Sie jemals einen anderen Header-Typ definieren müssen. Der Aufruf einer speziellen Header-Verarbeitung ist der häufigste Grund für das Hinzufügen einer Header-Definition zur Konfiguration. (Siehe die Datei cf/cf/knecht.mc für ein Beispiel einer Header-Definition, die eine besondere Verarbeitung aufruft, sowie Rezept 6.9 im sendmail-Kochbuch [O'Reilly] von Craig Hunt für eine gute Beschreibung, wie die spezielle Header-Verarbeitung aufgerufen wird.) Falls Sie eine spezielle Header-Verarbeitung auslösen, müssen Sie natürlich auch den Regelsatz schreiben, der die Verarbeitung ausführt. Die S- und R-Befehle, die benutzt werden, um eigene Regelsätze anzulegen, sind unser nächstes Thema.
Die wohl leistungsfähigste Funktion von sendmail ist die Rewrite-Regel. Rewrite-Regeln legen fest, wie sendmail eine E-Mail-Nachricht verarbeitet. sendmail schickt die Adressen aus dem Header einer E-Mail-Nachricht durch Sammlungen von Rewrite-Regeln, so genannte Regelsätze. In der sendmail.cf-Datei wird jeder Regelsatz mit Hilfe eines S-Befehls benannt. Diese Befehle sind als Sn codiert, wobei n den Namen oder die Nummer angibt, der bzw. die dem aktuellen Regelsatz zugewiesen werden soll.
Die Regeln selbst werden mittels R-Befehlen definiert, die in Regelsätzen zusammengefasst sind. Jede Regel besitzt eine linke Seite und eine rechte Seite, die durch mindestens ein Tabulator-Zeichen voneinander getrennt werden.3 Wenn sendmail eine Mail-Adresse verarbeitet, durchsucht es die Rewrite-Regeln nach einer passenden linken Seite. Entspricht die Adresse der linken Seite einer Rewrite-Regel, wird die Adresse durch die rechte Seite ersetzt und erneut verarbeitet. Auf diese Weise wandeln die Rewrite-Regeln eine Mail-Adresse aus der einen Form in eine andere um. Stellen Sie sich das wie einen Editor-Befehl vor, bei dem ein bestimmtes Textmuster durch ein anderes ersetzt wird.
Ein sendmail-Regelsatz sieht deshalb so aus:
Die linke Seite einer Rewrite-Regel gibt das Muster an, dem eine Adresse entsprechen muss, damit sie umgewandelt werden kann. Das Muster kann Literale, sendmail.cf-Makros und -Klassen sowie folgende Metasymbole enthalten:
Ein Token ist entweder ein String, der durch einen Operator begrenzt wird, oder ein abgrenzender Operator. Die Operatoren werden durch die sendmail.cf-Option OperatorChars definiert, wie unten gezeigt:
Betrachten Sie die folgende Adresse:
Diese E-Mail-Adresse enthält sieben Token: alana, @, ipa, ., vbrew, . und com. Drei dieser Token, zwei Punkte (.) und ein @, sind Operatoren. Die anderen vier Token sind Strings. Diese Adresse würde dem Symbol $+ entsprechen, weil sie mehr als ein Token enthält, sie entspricht aber nicht dem Symbol $-, weil sie nicht genau ein Token enthält.
Wenn eine Regel eine Adresse herausfiltert, dann wird der Text, der von den Mustern in dem Ausdruck erfasst wird, besonderen Variablen zugewiesen, so genannten unbestimmten Token (indefinite tokens), die dann auf der rechten Seite verwendet werden können. Die einzige Ausnahme bildet das Symbol $@, das keine Token erfasst und deshalb niemals Text generiert, der auf der rechten Seite benutzt werden kann.
Wenn die linke Seite einer Rewrite-Regel eine Adresse filtert, wird der ursprüngliche Text gelöscht und durch die rechte Seite der Regel ersetzt. Literale Werte auf der rechten Seite werden wörtlich in die neue Adresse kopiert. sendmail.cf-Makros der rechten Seite werden erweitert und in die neue Adresse kopiert. So wie die linke Seite eine Reihe von Metasymbolen besitzt, die für die Mustererfassung verwendet werden, hat auch die rechte Seite eine besondere Syntax zum Transformieren einer Adresse. Diese Syntax wird in der folgenden Liste beschrieben:
Eine Rewrite-Regel, die zutrifft, wird normalerweise so lange wiederholt, bis sie nicht mehr zutrifft, dann wird mit der nächsten Regel weitergemacht. Dieses Verhalten kann verändert werden, indem der rechten Seite eins der beiden speziellen Metasymbole zur Schleifensteuerung vorangestellt wird:
Es gibt auch eine besondere Syntax für die rechte Seite, die verwendet wird, um das Mail-Auslieferungstriple aus Mailer, Host und Benutzer zu erzeugen. Diese Syntax findet man üblicherweise in Regelsatz 0, der die Mail-Auslieferungsadresse analysiert. Diese Symbole sind:
Um besser zu verstehen, wie die Muster zur Makrosubstitution funktionieren, betrachten Sie die folgende linke Seite:
Diese Regel filtert »null oder mehrere Token, gefolgt vom <-Zeichen, gefolgt von einem oder mehreren Token, gefolgt vom >-Zeichen«.
Würde diese Regel auf brewer@vbrew.com oder Head Brewer < > angewendet, dann würde sie nichts filtern. Der erste String würde nicht passen, weil er kein <-Zeichen enthält, und der zweite würde fehlschlagen, weil $+ einem oder mehreren Token entspricht und es zwischen den <>-Zeichen keine Token gibt. Immer wenn eine Regel nicht zutrifft, wird auch die rechte Seite der Regel nicht verwendet.
Würde die Regel dagegen auf Head Brewer < brewer@vbrew.com > angewendet, dann würde sie filtern, und auf der rechten Seite würde $1 durch Head Brewer und $2 durch brewer@vbrew.com ersetzt werden.
Würde die Regel auf < brewer@vbrew.com > angewendet, dann würde die Regel zutreffen, weil $* null oder mehreren Token entspricht. Auf der rechten Seite würde $1 durch den leeren String ersetzt werden.
Das folgende Beispiel verwendet das Makro LOCAL_NET_CONFIG, um eine lokale Regel zu deklarieren und die Regel vor dem Ende von Regelsatz 0 einzufügen. Regelsatz 0 löst eine Auslieferungsadresse zu einem Mail-Auslieferungstriple auf, das den Mailer, einen Benutzer und den Host festlegt. Beispiel 12-1 zeigt eine Rewrite-Regel.
Das Makro LOCAL_NET_CONFIG wird verwendet, um m4 anzuweisen, die Rewrite-Regel in Regelsatz 0 zu platzieren. Die Regel selbst ist die Zeile, die mit R beginnt. Betrachten wir zuerst die linke Seite der Regel und dann die rechte Seite.
Die linke Seite sieht so aus: $*<@$*.$m.>$*.
< und > sind Fokus-Zeichen, die von Regelsatz 3 frühzeitig bei der Adressverarbeitung eingefügt wurden und den Host-Anteil der Mail-Adresse umschließen. Alle Adressen werden mit diesen Fokus-Zeichen umgeschrieben. Beim @ handelt es sich tatsächlich um das @, das in einer Internet-Mail-Adresse verwendet wird, um den Benutzerteil vom Host-Anteil zu trennen. Die Punkte (.) sind tatsächlich die Punkte aus den Domainnamen. $m ist ein sendmail.cf-Makro, das den lokalen Domainnamen aufnimmt. Die drei verbleibenden Elemente sind $*-Metasymbole.
Diese Regel filtert alle Mail-Adressen, die so aussehen: ZielBenutzer<@irgendeinhost.unseredomain.>Irgendein Text. Das bedeutet, sie filtert Mail für alle Benutzer auf allen Hosts innerhalb unserer Domain.
Text, der von den Metasymbolen auf der linken Seite einer Rewrite-Regel erfasst wird, wird den unbestimmten Token zur Benutzung auf der rechten Seite zugewiesen. In diesem Beispiel erfasst das erste $* den gesamten Text vom Anfang der Adresse bis zu den <@-Zeichen. Dieser gesamte Text wird $1 zur Benutzung auf der rechten Seite zugewiesen. Gleichermaßen wird alles, was dem zweiten $* in dieser Rewrite-Regel entspricht, $2 zugewiesen, und alles, was dem letzten $* entspricht. wird $3 zugewiesen.
Wenn diese Regel eine Adresse von irgendeinem Benutzer auf irgendeinem Host innerhalb unserer Domain filtert, weist sie den Benutzernamen an $1, den Hostnamen an $2 und anhängenden Text an $3 zu. Die rechte Seite wird dann verwendet, um diese Werte zu verarbeiten.
Die rechte Seite unserer Rewrite-Regel sieht so aus: $#esmtp $@$2.$m. $:$1<@$2.$m.>$3.
Wenn die rechte Seite unseres Regelsatzes verarbeitet wird, werden die einzelnen Metasymbole verarbeitet und relevante Ersetzungen vorgenommen.
Das $#-Metasymbol veranlasst diese Regel, einen speziellen Mailer auszuwählen - in unserem Fall esmtp.
Das Metasymbol $@ legt den Zielhost fest. In unserem Beispiel wird der Zielhost als $2.$m. angegeben, wobei es sich um den voll qualifizierten Domainnamen (Fully Qualified Domain Name, FQDN) des Hosts in unserer Domain handelt. Der FQDN wird aus der Hostnamenkomponente konstruiert, die von unserer linken Seite an $2 zugewiesen und der unser Domainname (.$m.) angehängt wurde.
Das Metasymbol $: gibt die Adresse des Empfängers an. Dabei handelt es sich um die vollständige E-Mail-Adresse des Empfängers, in diesem Fall angegeben durch $1 < @ $2.$m. > $3 - Benutzer, spitze Klammer, at, Host, Punkt, Domain, Punkt, spitze Klammer, nachfolgender Text.
Da diese Regel zu einem Mailer aufgelöst wird, wird die Nachricht zur Auslieferung an einen Mailer weitergeleitet. In unserem Beispiel würde die Nachricht mit Hilfe des SMTP-Protokolls an den Zielhost weitergeleitet werden.
Mit den bisher in diesem Kapitel dargelegten Informationen über sendmail.mc und sendmail.cf sollten Sie in der Lage sein, eine einfache sendmail-Konfiguration zu lesen oder zu erzeugen. Sehen wir uns zunächst eine beispielhafte sendmail.mc-Datei an.
Die sendmail-Distribution enthält eine große Anzahl Beispieldateien für Makrokonfigurationen im Verzeichnis cf/cf. Viele von ihnen sind generische Konfigurationsdateien für unterschiedliche Betriebssysteme, einschließlich der Datei generic-linux.mc für Linux. Beispiel 12-2 zeigt den Inhalt dieser Datei.
Anhand dieser Konfigurationsdatei kann man einige Dinge erkennen, auch ohne dass man etwas über die Dateisyntax weiß. Erstens ist der Name sendmail.mc offenbar nicht unantastbar. generic-linux.mc funktioniert genauso gut und ist wesentlich aussagekräftiger. Zweitens ist die Konfigurationsdatei sehr kurz. Der Großteil der Zeilen in Beispiel 12-2 sind Kommentare; nur die letzten fünf Zeilen sind tatsächlich sendmail-Konfigurationsbefehle. Drittens sind die sendmail-Konfigurationsbefehle selbst kurz und haben eine relativ einfache Syntax.
Die fünf aktiven Zeilen in der Datei generic-linux.mc setzen sich aus vier unterschiedlichen Makros zusammen. Das VERSIONID-Makro aus der Datei generic-linux.mc lautet:
Daher wissen wir, dass die Datei generic-linux.mc zuletzt im September 1999 von Greg Shapiro, einem der Linux-Entwickler, aktualisiert wurde.
Der Befehl OSTYPE(`linux') in der Datei generic-linux.mc lädt die Datei cf/ostype/linux.m4, die wir uns gleich ansehen werden. Das Makro DOMAIN(`generic') verarbeitet die Datei cf/domain/generic.m4, die wir ebenfalls in Kürze besprechen.
Die Makros MAILER(`local') und MAILER(`smtp') schließlich werden verwendet, um die Mailer local, prog, smtp, esmtp, smtp8, dsmtp und relay in die sendmail.cf-Konfiguration einzufügen.
Diese fünf Makros erzeugen die gesamte generische Linux-sendmail-Konfiguration. In den Dateien linux.m4 und generic.m4 finden Sie jedoch noch weitere Details.
Die Datei cf/ostype/linux.m4 wird in Beispiel 12-3 gezeigt.
Die Datei beginnt mit einem Kommentarblock und einem VERSIONID-Makro. Sie definiert dann den Pfad zu dem Verzeichnis, in dem sich die ausführbaren Binärdateien befinden. Der Pfad wird in der m4-Variable confEBINDIR gespeichert. Die Datei linux.m4 setzt diesen Pfadwert auf /usr/sbin. Falls der Pfad auf procmail noch nicht definiert wurde, wird dieser als Nächstes auf /usr/bin/procmail gesetzt. Die letzte Zeile in der Datei ist ein FEATURE-Makro, das die Funktion local_procmail lädt, die sendmail dazu bringt, procmail als local-Mailer zu verwenden. m4 benutzt den Pfad, der für PROCMAIL_MAILER_PATH definiert ist, wenn es die Funktion local_procmail konstruiert. Das ist ein ausgezeichnetes Beispiel dafür, wie ein Wert zuerst definiert und dann beim Aufbau einer Konfiguration benutzt wird. Die Datei linux.m4 ist außerdem ein gutes Beispiel für die Art der Konfigurationsbefehle, die normalerweise in einer OSTYPE-Datei zu finden sind.
Die Datei cf/domain/generic.m4 ist eine beispielhafte DOMAIN-Datei, die von den sendmail-Entwicklern angeboten wird. Sie wird von der Datei generic-linux.mc benutzt, die in Beispiel 12-2 zu sehen ist. Die Datei generic.m4 wird in Beispiel 12-4 gezeigt.
Auch diese Datei beginnt mit einem großen Kommentarblock und einem VERSIONID-Makro. Darauf folgt ein define, das den Suchpfad setzt, den sendmail benutzt, wenn es nach einer .forward-Datei eines Benutzers sucht. Dieser Befehl setzt die Option ForwardPath in der Datei sendmail.cf. $z, $w und $h sind interne sendmail.cf-Makros.4
Das zweite define setzt die maximale Länge für alle Header in einer einzigen Mail auf 32.768 Bytes. Dazu setzt es die Option MaxHeadersLength in der Datei sendmail.cf.
Die nächsten beiden Zeilen fügen Funktionen zur sendmail-Konfiguration hinzu. Das Makro FEATURE(`redirect') fügt Unterstützung für die Pseudo-Domain .REDIRECT hinzu. Eine Pseudo-Domain ist eine Erweiterung im Domain-Stil, die einer E-Mail-Adresse intern von sendmail hinzugefügt wird, um eine besondere Behandlung der Adresse zu definieren. Die Pseudo-Domain .REDIRECT arbeitet mit der aliases-Datenbank zusammen, um Mail für Leute zu verarbeiten, die diese nicht mehr auf Ihrer Site lesen, aber immer noch Nachrichten an ihre alte Adresse geschickt bekommen.5 Nachdem Sie diese Funktion aktiviert haben, fügen Sie für jede veraltete Mail-Adresse einen Alias in dieser Form hinzu:
alte-adresse neue-adresse.REDIRECT
Dadurch wird eine Fehlermeldung an den Absender zurückgeschickt, die ihn auffordert, eine neue Adresse für den Empfänger zu versuchen:
Der Befehl FEATURE(`use_cw_file') liest /etc/mail/local-host-names ein und fügt die dort aufgelisteten Hostnamen zur sendmail.cf-Klasse $=w hinzu. Die Klasse $=w enthält die Namen der Hosts, für die der lokale Computer lokale Mail akzeptiert. Normalerweise ist es so: Wenn ein System, auf dem sendmail läuft, Mail aus dem Netzwerk empfängt, die an einen anderen Hostnamen adressiert ist, nimmt es an, dass die Mail zu diesem Host gehört, und leitet sie an diesen Host weiter, falls der lokale Host als Relay konfiguriert ist, oder verwirft die Mail, falls das nicht der Fall ist. Wenn das System Mail, die an einen anderen Host adressiert ist, als lokale Mail akzeptieren soll, muss der Name des anderen Hosts in die Klasse $=w aufgenommen werden. Jeder Hostname, der in der Datei local-host-names steht, wird zur Klasse $=w hinzugefügt, wenn die Funktion use_cw_file verwendet wird.
Die letzte Zeile in der Datei generic.m4 ist das Makro EXPOSED_USER. Das Makro EXPOSED_USER fügt Benutzernamen zur Klasse $=E hinzu. Die Benutzer, die in der Klasse $=E aufgeführt sind, werden nicht maskiert, selbst wenn Masquerading aktiviert ist. (Masquerading verbirgt in ausgehenden Mails den echten Hostnamen und ersetzt ihn durch den Hostnamen, den Sie der Außenwelt stattdessen anzuzeigen wollen.) Manche Benutzernamen wie root treten in vielen Systemen auf und sind deshalb in einer Domain nicht eindeutig. Wird bei solchen Benutzernamen der Hostanteil der Adresse konvertiert, dann wird es schwierig festzustellen, woher die Nachricht tatsächlich kam, und Antworten werden unmöglich. Der Befehl EXPOSED_USER in der Datei generic.m4 verhindert das, indem er sicherstellt, dass root nicht maskiert wird.
Auf Grund der Befehle, die in den Dateien generic-linux.mc, linux.m4 und generic.m4 enthalten sind, tut die generische Linux-Konfiguration Folgendes:
Sie können sendmail konfigurieren, indem Sie die Konfiguration modifizieren, die in Ihrer Linux-Distribution enthalten ist. Oder Sie legen eine eigene Konfiguration an, indem Sie die Datei generic-linux.mc verändern, die mit der sendmail-Distribution geliefert wurde. Im nächsten Abschnitt bauen wir eine sendmail-Konfiguration, die auf der Datei generic-linux.mc basiert.
Wir beginnen den Aufbau unserer eigenen Konfiguration, indem wir in das Konfigurationsverzeichnis wechseln und die Konfigurationsdatei generic-linux.mc in eine Arbeitsdatei kopieren. Da wir die Konfiguration für vstout.vbrew.com anlegen, nennen wir die Arbeitsdatei vstout.mc.
Wir konfigurieren vstout als Mailserver für unsere Gruppe. Wir wollen, dass er Folgendes leistet:
Um sendmail so zu konfigurieren, dass es die oben aufgeführten Aufgaben erfüllt, bearbeiten wir die Datei vstout.mc und fügen folgende Funktionen hinzu:
Die erste Zeile fügt Unterstützung für die genericstable Datenbank hinzu. Die zweite Zeile definiert vbrew.com als Domain, auf die die genericstable angewendet wird. Die dritte Zeile weist sendmail an, die genericstable auf jeden Host in der Domain vbrew.com anzuwenden. Die letzte Zeile fügt Unterstützung für die access-Datenbank hinzu.
Nach dem Entfernen unnötiger Kommentare, dem Aktualisieren der VERSIONID und dem Hinzufügen der neuen Zeilen sieht die vstout.mc-Konfigurationsdatei aus wie in Beispiel 12-5:
Wir müssen nun aus unserer Master-Konfigurationsdatei eine sendmail.cf-Datei erstellen, die neue sendmail.cf-Datei installieren und sicherstellen, dass sendmail die Datei auch einliest.
Die Datei sendmail.cf wird normalerweise im gleichen cf/cf-Verzeichnis erstellt wie die Master-Konfigurationsdatei. Falls Sie sich momentan nicht dort befinden, wechseln Sie in das Verzeichnis cf/cf, bevor Sie mit der Erstellung beginnen.
Führen Sie Build aus, um die Datei sendmail.cf aus der m4-Master-Konfigurationsdatei zu erzeugen. Das Build-Skript ist einfach zu benutzen. Geben Sie den Namen der Ausgabedatei, die Sie erzeugen wollen, als Argument auf der Build-Kommandozeile an. Das Skript ersetzt die Erweiterung .cf der Ausgabedatei durch die Erweiterung .mc und verwendet die Master-Konfigurationsdatei mit diesem Namen, um die Ausgabedatei anzulegen. Das bedeutet, wenn Sie vstout.cf auf die Build-Kommandozeile setzen, wird vstout.mc benutzt, um vstout.cf zu erzeugen. Hier ist ein Beispiel:
Trotz der Einfachheit des Build-Befehls benutzen viele Administratoren ihn nie, um eine sendmail-Konfiguration zu erstellen, weil die m4-Kommandozeile, die eingesetzt wird, um eine sendmail-Konfiguration zu erstellen, ebenfalls sehr einfach ist. Die m4-Kommandozeile, mit der man die Datei vstout.cf aus der Datei vstout.mc erzeugen könnte, lautet:
Für den durchschnittlichen sendmail-Administrator hat das Build-Skript keine wesentlichen Vorteile zu bieten. Die Entscheidung für das Build-Skript oder für den m4-Befehl ist für die meisten von uns vor allem eine Frage des persönlichen Geschmacks. Es ist sogar möglich, das Makefile direkt mit einem einfachen make-Befehl aufzurufen. Nehmen Sie die Methode, die Ihnen am besten gefällt.
Nach dem Erstellen der neuen .cf-Datei testen Sie sie gründlich, wie weiter hinten in diesem Kapitel beschrieben, bevor Sie diese Datei an diejenige Stelle kopieren, an der sendmail die sendmail.cf-Konfigurationsdatei erwartet, also normalerweise unter /etc/mail/sendmail.cf. In den meisten Fällen verwendet man dazu einfach einen cp-Befehl:
Sie können dazu aber auch den Build-Befehl verwenden:
Der oben verwendete Befehl Build install-cf installiert zwei Konfigurationsdateien: die Datei sendmail.cf und eine zweite Datei namens submit.cf. sendmail.cf existiert erst dann, wenn Sie sie anlegen. (In diesem Fall haben wir sie als vstout.cf erzeugt und dann in sendmail.cf umbenannt.) Eine vollständige submit.cf-Datei ist dagegen in der sendmail-Distribution enthalten und muss normalerweise nicht von Ihnen erzeugt oder modifiziert werden. Die Datei submit.cf ist die besondere Konfiguration, die von sendmail benutzt wird, wenn es als Mail-Submission-Programm arbeitet, während sendmail.cf die Konfigurationsdatei für den sendmail-Dämon ist. Der Befehl Build install-cf wird im Allgemeinen verwendet, wenn eine neue sendmail-Distribution das erste Mal installiert wird, um sicherzustellen, dass sowohl die Datei sendmail.cf als auch die Datei submit.cf installiert ist. Im Gegensatz zur anfänglichen Installation ist es im Allgemeinen nicht notwendig, beide Dateien gleichzeitig zu kopieren, weil es normalerweise nicht erforderlich ist, eine neue submit.cf-Datei zu erzeugen, wenn Sie eine neue sendmail.cf-Datei anlegen.
Sobald die Konfiguration installiert ist, starten Sie sendmail neu, indem Sie ihm ein HUP-Signal senden, um es zum Einlesen der neuen Konfiguration zu zwingen. Diese Methode des Neustarts von sendmail benutzt die normale sendmail-Signalverarbeitung, die auf jedem Linux-System zur Verfügung steht:
Manche Linux-Systeme bringen ihre eigenen Werkzeuge zum Verwalten von Dämonen mit. Beispielsweise können einige Systeme sendmail mit dem service-Befehl starten:
Unabhängig davon, wie sendmail neu gestartet wird, liest es beim Start des Dämons die Konfigurationsdatei /etc/mail/sendmail.cf ein, die nun die neue Konfiguration enthält.
Die gerade erzeugte Beispielkonfiguration verwendet mehrere sendmail-Datenbanken. (Wir verwenden den Begriff »Datenbank« hier sehr frei und meinen damit sowohl echte Datenbanken als auch einfache Dateien.) sendmail-Datenbanken bilden eine häufig übersehene Komponente der sendmail-Konfiguration, obwohl sie eine wichtige Rolle dabei spielen. In diesen Datenbanken, nicht in den m4-Dateien oder in der sendmail.cf-Datei, finden die täglichen Konfigurationsänderungen statt. In unserer Beispielkonfiguration werden folgende sendmail-Datenbanken verwendet:
In den folgenden Abschnitten werden diese und weitere Datenbanken beschrieben, die nicht in der Beispielkonfiguration zum Einsatz kamen.
Mail-Aliase sind ein leistungsfähiges Feature zum Routen von Mail an einen Ziel-Host. Beispielsweise ist es üblich, Anmerkungen oder Kommentare, die einen WWW-Server betreffen, an »webmaster« zu senden. Oft jedoch gibt es auf der Zielmaschine gar keinen Benutzer, der »webmaster« heißt, stattdessen handelt es sich dabei um einen Alias für einen anderen Benutzer. Eine andere gebräuchliche Anwendung für Mail-Aliase ist die Erzeugung von Mailinglisten. Dabei werden E-Mails über einen einzelnen Alias an viele Empfänger verteilt. Oder es wird ein Alias verwendet, um eingehende Nachrichten an das Listen-Serverprogramm zu richten. Aliase haben folgende Vorzüge:
Einzelheiten bezüglich der Mail-Aliase finden Sie in der Manpage aliases(5). Eine aliases-Datei könnte aussehen wie in Beispiel 12-6.
Immer wenn Sie die Textdatei /etc/aliases aktualisieren, müssen Sie folgenden Befehl ausführen:
Dieser Befehl baut die Datenbank neu auf, die sendmail intern benutzt. Der Befehl newaliases ist ein symbolischer Link auf das sendmail-Programm, der sich exakt so verhält, als wäre sendmail mit dem Kommandozeilenargument -bt aufgerufen worden.
sendmail schaut in die aliases-Datenbank, um festzustellen, wie eine ankommende Mail-Nachricht verarbeitet werden soll, die zur lokalen Auslieferung akzeptiert wurde. Wenn der Benutzeranteil der Auslieferungsadresse in der Mail-Nachricht einem Eintrag in der aliases-Datenbank entspricht, leitet sendmail die Nachricht so weiter, wie es durch den Eintrag beschrieben wird. Das geschieht aber nur, wenn sendmail die Mail zur lokalen Auslieferung annimmt. Die Datei local-host-names hilft sendmail bei der Entscheidung, welche Nachrichten zur lokalen Auslieferung akzeptiert werden sollen.
Eingehende Mail wird entweder direkt an den Adressaten ausgeliefert oder zur Auslieferung an einen anderen Mail-Host weitergereicht (»relayed«). sendmail akzeptiert nur solche Mail zur lokalen Auslieferung, die an den lokalen Host adressiert ist. Sämtliche andere Mail wird weitergereicht. Das System prüft die Klasse $=w, um zu entscheiden, ob es eingehende Mail zur lokalen Auslieferung akzeptieren muss. Klasse $=w ist ein Array, das alle Namen enthält, die sendmail für eine lokale Auslieferung von Mail als gültig akzeptiert.
Die Funktion use_cw_file weist sendmail an, die Datei /etc/mail/local-host-names in die Klasse $=w zu laden. Dazu wird der folgende F-Befehl in die Datei sendmail.cf platziert:
Sobald die Funktion use_cw_file in die Konfiguration aufgenommen wurde, erwartet sendmail, die Datei local-host-names vorzufinden, und zeigt eine Fehlermeldung an, wenn das nicht der Fall ist. Falls Sie noch keine Hostnamen in die Datei eingefügt haben, legen Sie einfach eine leere Datei an.
Um den sendmail-Server so zu konfigurieren, dass er eingehende Mail für andere Hosts akzeptiert, fügen Sie die Namen dieser Hosts einfach in die Datei local-host-names ein. Die Datei local-host-names ist lediglich eine Liste mit Hostnamen - ein Hostname pro Zeile. Hier ist eine Beispieldatei local-host-names für die Domain vbrew.com:
Die Werte, die in der Datei local-host-names gespeichert werden, werden den anderen Werten in der Klasse $=w hinzugefügt. Bei diesen Werten handelt es sich um alle diesem Host zugewiesenen Hostnamen, Hostnamen-Aliase und IP-Adressen, die sendmail durch Testen der verschiedenen Netzwerkschnittstellen ermitteln konnte. Es ist möglich, die Schnittstellentests, die sendmail durchführt, zu beschränken, indem Sie die folgende Definition in die sendmail-Konfiguration einfügen:
Die Definition confDONT_PROBE_INTERFACES wird im Allgemeinen nur dann eingesetzt, wenn das Testen der Schnittstellen sendmail fehlerhafte Informationen liefert oder wenn eine große Anzahl virtueller Schnittstellen benutzt wird.
Es ist auch möglich, mit Hilfe des Makros LOCAL_DOMAIN Hostnamen der Klasse $=w innerhalb der sendmail-Konfiguration hinzuzufügen:
Allerdings muss jedes Mal, wenn ein LOCAL_DOMAIN-Makro in die Konfiguration aufgenommen wird, die Datei sendmail.cf neu aufgebaut, getestet und in das Verzeichnis /etc/mail verschoben werden. Wird die Datei local-host-names verwendet, dann muss sendmail.cf nicht neu erstellt werden, nur weil local-host-names bearbeitet wurde.
Die Funktion bestmx_is_local stellt eine weitere Möglichkeit dar, Mail zur lokalen Auslieferung zu akzeptieren, die an einen anderen Hostnamen adressiert ist. Sie funktioniert gut, wenn der einzige Grund, Hostnamen in die Datei local-host-names aufzunehmen, darin besteht, dass der lokale Host der bevorzugte Mail-Exchanger für diese Hosts ist. Mail, die an ein System adressiert ist, das den lokalen Host als seinen bevorzugten Mail-Exchanger aufführt, wird als lokale Mail akzeptiert, wenn bestmx_is_local zum Einsatz kommt. Um diesen Ansatz zu verfolgen, schreiben Sie die folgende Zeile in die Konfiguration:
Der große Vorteil von bestmx_is_local besteht darin, dass es einfach ist - die Hostnamen der MX-Clients müssen nicht in die Datei local-host-names aufgenommen werden. Ein potenzielles Problem mit der bestmx_is_local-Lösung könnte es jedoch geben, da sich der Verarbeitungsaufwand für jede einzelne Mail erhöht. Für ein kleines System ist das nicht so schlimm, es könnte jedoch problematisch werden, wenn das System viele Mails verarbeiten muss. Eine weitere Einschränkung ist, dass bestmx_is_local vollständig von MX-Records abhängt, möglicherweise gibt es aber andere Gründe, um Mail als lokale Mail zu akzeptieren. Die Datei local-host-names kann alle von Ihnen gewünschten Hostnamen aufnehmen; sie ist nicht auf solche Hosts beschränkt, die Ihr System als ihren Mail-Exchanger definieren.
Mail, die nicht an den lokalen Host adressiert ist, wird weitervermittelt. Die Datei relay-domains stellt eine Methode dar, um das Relaying zu konfigurieren.
Standardmäßig erlaubt sendmail kein Relaying - nicht einmal Relaying von anderen Hosts innerhalb der lokalen Domain. Versuche, mit der Standardkonfiguration durch ein System zu vermitteln, bringen dem Absender einen »Relaying denied«-Fehler ein. sendmail agiert jedoch als Relay für alle Domains, die in der Klasse $=R aufgeführt sind. Alles, was in der Datei relay-domains steht, wird der Klasse $=R hinzugefügt. Beispielsweise erweitern die folgenden Befehle die Datei relay-domains so, dass das Relaying für die Domain vbrew.com aktiviert wird:
Starten Sie sendmail erneut, um sicherzustellen, dass es die Datei relay-domains einliest:
Nun können Hosts innerhalb der lokalen Domain durch vstout.vbrew.com vermitteln - ohne dass Änderungen an der m4-Konfiguration erforderlich sind oder die Datei sendmail.cf neu aufgebaut werden muss. Mail von oder zu Hosts in der Domain vbrew.com wird weitervermittelt. Mail, die weder von einem Host in der Domain vbrew.com stammt noch an einen gerichtet ist, ist weiterhin vom Relaying ausgeschlossen.
Es gibt andere Möglichkeiten, um das Relaying zu aktivieren. Keine ist jedoch so einfach wie das Hinzufügen der lokalen Domain zur Datei relay-domains. Einige stellen potenziell sogar ein Sicherheitsrisiko dar. Eine gute Alternative besteht darin, den lokalen Domainnamen mit Hilfe des Makros RELAY_DOMAIN der Klasse $=R hinzuzufügen. Wenn die folgenden Zeilen in die Makrokonfiguration aufgenommen werden, hätten sie die gleiche Wirkung wie die oben definierte Datei relay-domains:
Allerdings verlangt der Befehl RELAY_DOMAIN, dass die m4-Konfiguration verändert sowie die Datei sendmail.cf neu aufgebaut und neu installiert wird. Bei der Datei relay-domains ist das nicht der Fall, weshalb relay-domains einfacher anzuwenden ist.
Eine weitere gute Alternative ist die Funktion relay_entire_domain. Wenn der folgende Befehl in eine Makrokonfiguration aufgenommen wird, würde das Relaying für Hosts in der lokalen Domain aktiviert:
Die Funktion relay_entire_domain vermittelt Mail von jedem Host einer Domain, die in der Klasse $=m aufgeführt ist. Standardmäßig enthält die Klasse $=m den Domainnamen des Server-Systems, d.h. vbrew.com bei einem Server namens vstout.vbrew.com. Diese alternative Lösung funktioniert, ist aber etwas komplexer als die Benutzung der Datei relay-domains. Außerdem ist die Datei relay-domains sehr flexibel. Sie ist nicht auf die lokale Domain beschränkt. Jede Domain kann in der Datei relay-domains aufgeführt werden, und Mail von oder zu jedem Host in dieser Domain wird weitervermittelt.
Es gibt einige Techniken zum Aktivieren des Relaying, die man aus Sicherheitsgründen vermeiden sollte. Zwei dieser Alternativen sind:
Sobald die Datei relay-domains so konfiguriert ist, dass Mail von und zu der lokalen Domain weitervermittelt wird, können die Clients im lokalen Netzwerk damit beginnen, Mail durch den Server an die Außenwelt zu senden. Die Datenbank genericstable, die wir als Nächstes besprechen, erlaubt es Ihnen, die Absenderadresse der Mail umzuschreiben, wenn sie durch den Server geht.
Um Unterstützung für die genericstable-Datenbank zu bieten, haben wir die Funktion genericstable, das Makro GENERICS_DOMAIN und die Funktion generics_entire_domain zu unserer sendmail-Beispielkonfiguration hinzugefügt. Die folgenden Befehle wurden angegeben:
Die genericstable-Funktion fügt den Code hinzu, den sendmail benötigt, um die genericstable benutzen zu können. Das GENERICS_DOMAIN-Makro fügt den Wert, der auf der Makrokommandozeile angegeben wurde, in die sendmail-Klasse $=G ein. Normalerweise werden die Werte, die in der Klasse $=G stehen, als Hostnamen interpretiert, und nur genaue Treffer aktivieren die genericstable-Verarbeitung. Die Funktion generics_entire_domain veranlasst sendmail, die Werte in der Klasse $=G als Domainnamen zu interpretieren. Nun werden alle Hosts innerhalb dieser Domains durch die genericstable verarbeitet. Das heißt, in dieser Konfiguration wird der Hostname vipa.vbrew.com durch die genericstable verarbeitet, weil er den Domainnamen vbrew.com enthält.
Jeder Eintrag in der genericstable enthält zwei Felder: den Schlüssel und den Wert, der für diesen Schlüssel zurückgeliefert wird. Das Schlüsselfeld kann entweder eine vollständige E-Mail-Adresse oder ein Benutzername sein. Der zurückgelieferte Wert ist normalerweise eine vollständige E-Mail-Adresse, die sowohl einen Benutzernamen als auch einen Hostnamen enthält. Um die genericstable zu erzeugen, legen Sie zuerst eine Textdatei an, die die Datenbankeinträge enthält, und schicken diese dann durch den makemap-Befehl. Für den Server vstout.vbrew.com haben wir folgende genericstable erzeugt:
Mit dieser genericstable wird die Header-Absenderadresse win@vipa.vbrew.com zu winslow.smiley@vbrew.com umgeschrieben. Das ist der Wert, den die genericstable für den Schlüssel win zurückliefert. In diesem Beispiel gehört jeder Benutzerzugang namens win in der gesamten Domain vbrew.com zu Winslow Smiley. Unabhängig davon, von welchem Host in dieser Domain er seine Mail sendet, wird die Mail in winslow.smiley@vbrew.com umgeschrieben, sobald sie das System passiert. Damit Antworten an die umgeschriebene Adresse richtig funktionieren, muss der umgeschriebene Hostname zu einem Host aufgelöst werden, der die Mail akzeptiert. Dieser Host muss wiederum einen Alias für winslow.smiley besitzen, der die Mail an den echten Benutzerzugang namens win ausliefert.
Die Zuordnung durch die genericstable kann beliebig vorgenommen werden. In diesem Beispiel bilden wir Login-Namen auf den echten Namen des Benutzers und den lokalen Domainnamen ab, und zwar im Format vorname.nachname@domain.6 Falls natürlich Mail am Server eintrifft, die an vorname.nachname@domain adressiert ist, sind Aliase erforderlich, um die Mail an die tatsächliche Adresse des Benutzers auszuliefern. Aliase, die auf den oben gezeigten genericstable-Einträgen beruhen, könnten auf folgende Weise an die aliases-Datenbank angehängt werden:
Die Aliase, die auf einen Benutzernamen abgebildet werden, speichern Mail auf dem Server, wo sie vom Benutzer gelesen oder mit POP oder IMAP vom Client bezogen wird. Die Aliase, die auf die vollständige Adresse abgebildet werden, leiten die Mail an den Host weiter, der in der Adresse definiert ist.
Die meisten Einträge in der Beispieldatenbank genericstable (kathy, sara, dave, becky und jay) sind Viele-zu-eins-Abbildungen, die genauso funktionieren wie der oben beschriebene win-Eintrag. Ein interessanterer Fall ist die Zuordnung des Benutzernamens alana. Drei Personen in der Domain vbrew.com verwenden diesen Benutzernamen: Alana Henson, Alana Darling und Alana Sweet. Die vollständigen Adressen, die in den genericstable-Schlüsseln für Alana Darling und Alana Henson verwendet werden, ermöglichen es sendmail, Eins-zu-eins-Zuordnungen für diese Adressen vorzunehmen. Der für den Eintrag von Alana Sweet verwendete Schlüssel ist jedoch nur ein Benutzername. Dieser Schlüssel passt auf jede Eingangsadresse, die den Benutzernamen alana enthält, bis auf die Eingangsadressen alana@vpils.vbrew.com und alana@vale.vbrew.com. Wenn ein System Mail verarbeitet, die von mehreren Hosts stammt, kann es vorkommen, dass doppelte Login-Namen dabei sind. Dadurch dass der Schlüssel in der genericstable aber eine vollständige E-Mail-Adresse enthalten kann, haben Sie die Möglichkeit, diese einander überschneidenden Benutzernamen zuzuordnen.
Die letzte Datenbank, die in der beispielhaften Linux-sendmail-Konfiguration verwendet wird, ist die access-Datenbank. Diese Datenbank ist so vielseitig, dass sie am besten in die Konfiguration aller Mailserver aufgenommen wird.
Die access-Datenbank bietet große Flexibilität und Kontrolle, um zu konfigurieren, von welchen Hosts oder Benutzern Mail akzeptiert wird und für welche Hosts und Benutzer Mail weitervermittelt wird. Die access-Datenbank ist ein leistungsfähiges Konfigurationswerkzeug für Mail-Relay-Server, das einen gewissen Schutz vor Spam bietet und eine viel feinere Kontrolle über den Relay-Vorgang ermöglicht als die Datei relay_domains. Im Gegensatz zur Datei relay_domains ist die access-Datenbank nicht standardmäßig in der sendmail-Konfiguration enthalten. Um die access-Datenbank zu benutzen, haben wir die Funktion access_db zu unserer sendmail-Beispielkonfiguration unter Linux hinzugefügt:
Die allgemeine Idee hinter der access-Datenbank ist einfach. Wenn eine SMTP-Verbindung hergestellt wird, vergleicht sendmail die Informationen aus dem Umschlag-Header mit den Informationen in der access-Datenbank, um festzustellen, wie es die Nachricht verarbeiten soll.
Die access-Datenbank ist eine Sammlung aus Regeln, die beschreiben, welche Aktion für Nachrichten von oder zu bestimmten Benutzern oder Hosts ausgeführt werden soll. Die Datenbank weist ein einfaches Format auf. Jede Zeile in der Tabelle enthält eine Zugriffsregel. Die linke Seite jeder Regel ist ein Muster, das mit der Umschlag-Header-Information der Mail-Nachricht verglichen wird. Die rechte Seite enthält die Aktion, die ausgeführt werden soll, wenn die Umschlag-Information dem Muster entspricht.
Das linksseitige Muster kann Folgendes abgleichen:
Standardmäßig wird das Muster mit der Absenderadresse auf dem Umschlag verglichen. Die Aktion wird daher nur dann ausgeführt, wenn die Mail von der angegebenen Adresse stammt. Wenn die Funktion blacklist_recipient zur sendmail-Konfiguration hinzugefügt wird, dann wird der Mustervergleich sowohl mit der Quell-Umschlagadresse als auch mit der Ziel-Umschlagadresse durchgeführt. Der linken Seite kann jedoch ein optionales Tag-Feld vorangestellt werden, das eine feinere Kontrolle bietet, wenn der Mustervergleich durchgeführt wird. Beginnt das Muster mit einem optionalen Tag, wird sendmail mitgeteilt, dass der Mustervergleich auf bestimmte Bedingungen beschränkt werden soll. Die drei einfachen Tags sind:
Es gibt fünf einfache Aktionen, die auf der rechten Seite einer Zugriffsregel definiert werden können:
Eine beispielhafte /etc/mail/access könnte so aussehen:
Dieses Beispiel würde alle E-Mails zurückweisen, die von friends@cybermail.com, von allen Hosts in der Domain aol.com und vom Host 207.46.131.30 stammen. Die nächste Regel würde E-Mail von postmaster@aol.com akzeptieren, und zwar ungeachtet der Tatsache, dass die Domain selbst aufgrund der vorangegangenen Regel abgelehnt wird. Die fünfte Regel erlaubt das Relaying von Mail von allen Hosts in der Domain linux.org.au. Die letzte Regel weist Mail von example.com mit einer eigenen Fehlermeldung zurück. Die Fehlermeldung enthält den DSN-Code 5.7.1 (Delivery Status Notification), einen laut RFC 1893 gültigen Code, sowie den SMTP-Fehlercode 550, einen gültigen Code aus RFC 821.
Die access-Datenbank kann noch viel mehr, als hier gezeigt wurde. Beachten Sie, dass wir ausdrücklich »einfache« Tags und »einfache« Aktionen gesagt haben, da es noch viel mehr Werte gibt, die in aufwändigeren Konfigurationen eingesetzt werden können. Falls Sie eine kompliziertere Konfiguration einrichten wollen, lesen Sie den Abschnitt »Weitere Informationen« später in diesem Kapitel.
Die access-Datenbank ist die letzte Datenbank, die wir in unserer Beispielkonfiguration benutzt haben. Es gibt aber noch weitere Datenbanken. Diese werden im folgenden Abschnitt beschrieben.
Einige der verfügbaren sendmail-Datenbanken wurden in unserer Beispielkonfiguration nicht verwendet, entweder weil von ihrer Benutzung abgeraten wird oder weil sie sich auf veraltete Techniken beziehen. Diese Datenbanken sind:
Es gibt zwei weitere Datenbanken namens mailertable und virtusertable, die zwar nicht in der Beispielkonfiguration enthalten, aber dennoch nützlich sind.
Die Funktion mailertable fügt der sendmail-Konfiguration Unterstützung für die mailertable hinzu. Die Syntax für die Funktion mailertable lautet:
Die optionale Datenbankspezifikation wird benutzt, um den vorgegebenen Datenbanktyp hash und den vorgegebenen Datenbankpfad /etc/mail/mailertable zu überschreiben.
Die mailertable bildet Domainnamen auf den internen Mailer ab, der eingehende Mail für diese Domain verarbeiten soll. Einige Mailer werden nur verwendet, wenn sie in der mailertable referenziert werden. Beispielsweise fügt der Befehl MAILER(`smtp') die Mailer esmtp, relay, smtp, smtp8 und dsmtp zur Konfiguration hinzu. sendmail verwendet standardmäßig nur zwei dieser Mailer. Der Mailer esmtp wird verwendet, um normale SMTP-Mail zu verschicken, und der Mailer relay wird benutzt, wenn Mail durch einen externen Server weitervermittelt werden soll. Die anderen drei Mailer werden nur benutzt, wenn sie in einem mailertable-Eintrag oder in einer eigenen Rewrite-Regel referenziert werden. (Die Benutzung der mailertable ist viel einfacher als das Schreiben Ihrer eigenen Rewrite-Regeln!)
Lassen Sie uns den smtp8-Mailer als Beispiel verwenden. Der smtp8-Mailer ist dafür gedacht, 8-Bit-MIME-Daten an veraltete Mailserver zu senden, die zwar MIME unterstützen, aber Extended SMTP nicht verstehen. Wenn die Domain example.edu einen solchen Mailserver einsetzen würde, könnten Sie folgenden Eintrag in die mailertable setzen, um die Mail zu verarbeiten:
Ein mailertable-Eintrag enthält zwei Felder. Das erste Feld ist ein Schlüssel, in dem der Host-Anteil der Auslieferungsadresse steht. Dieser kann entweder ein voll qualifizierter Hostname - emma.example.edu - oder einfach ein Domainname sein. Um einen Domainnamen festzulegen, beginnen Sie den Namen mit einem Punkt, wie im Beispiel oben gezeigt. Wird ein Domainname verwendet, dann erfasst dieser alle Hosts in der Domain.
Das zweite Feld ist der Rückgabewert. Normalerweise enthält er den Namen des Mailers, der die Mail verarbeiten soll, und den Namen des Servers, an den die Mail geschickt werden soll. Optional kann ein Benutzername mit der Serveradresse angegeben werden, und zwar in der Form benutzer@server. Der gewählte Mailer kann auch ein interner Error-Mailer sein. Wird der Error-Mailer benutzt, dann ist der Wert, der auf den Mailer-Namen folgt, eine Fehlermeldung und kein Servername. Hier folgt jeweils ein Beispiel für diese alternativen Einträge:
Normalerweise wird Mail, die durch die mailertable verarbeitet wird, an den Benutzer gesandt, an den sie adressiert war. Beispielsweise wird Mail an jane@emma.example.edu durch den smtp8-Mailer an den Server oldserver.example.edu gesandt. Wenn jedoch dem zweiten Feld ein Benutzername hinzugefügt wird, wird dieses normale Verhalten geändert und die Mail an eine Person anstatt an einen Mailserver geroutet. So wird zum Beispiel Mail, die an einen beliebigen Benutzer auf vlite.vbrew.com gesandt wird, stattdessen an postmaster@vstout.vbrew.com geschickt. Dort wird die Mail wahrscheinlich manuell verarbeitet. Letztendlich muss Mail, die von der mailertable verarbeitet wird, überhaupt nicht ausgeliefert werden. Stattdessen kann eine Fehlermeldung an den Absender zurückgeschickt werden. Alle Mails, die an vmead.vbrew.com gesandt werden, liefern die Fehlermeldung »This host is unavailable« (Dieser Host steht nicht zur Verfügung) an den Absender zurück.
Die sendmail-Funktion virtusertable fügt Unterstützung für die Tabelle der virtuellen Benutzer hinzu, in der virtuelles E-Mail-Hosting konfiguriert wird. Virtuelles E-Mail-Hosting ermöglicht es dem Mailserver, Mail im Namen einer ganzen Reihe unterschiedlicher Domains zu akzeptieren und auszuliefern, so als würde es sich um eine Vielzahl separater Mail-Hosts handeln. Die virtusertable bildet eingehende Mails, die für irgendeinen benutzer@host gedacht sind, auf irgendeinen andererbenutzer@andererhost ab. Sie können sich das als eine erweiterte Mail-Alias-Funktion vorstellen - eine, die nicht nur den Zielbenutzer, sondern auch die Ziel-Domain beachtet.
Um die Funktion virtusertable zu konfigurieren, fügen Sie sie in Ihre m4-Makrokonfiguration ein:
Standardmäßig befindet sich die virtusertable-Quelldatei unter /etc/mail/virtusertable. Sie können das ändern, indem Sie der Makrodefinition ein Argument übergeben; schauen Sie in eine ausführliche sendmail-Referenz, um festzustellen, welche Optionen zur Verfügung stehen.
Das Format der virtusertable ist sehr einfach. Die linke Seite jeder Zeile enthält ein Muster, das die ursprüngliche Zieladresse repräsentiert; die rechte Seite enthält ein Muster, das die Mail-Adresse repräsentiert, auf die die virtuell vorgehaltene Adresse abgebildet wird. Das folgende Beispiel zeigt drei mögliche Typen von Einträgen:
In diesem Beispiel halten wir drei virtuelle Domains vor: bovine.net, dairy.org und artist.org.
Der erste Eintrag leitet Mail, die an einen Benutzer in der virtuellen Domain bovine.net geschickt wird, an einen lokalen Benutzer auf der Maschine um. Der zweite Eintrag leitet Mail an einen Benutzer in der gleichen virtuellen Domain an einen Benutzer in einer anderen Domain weiter. Das dritte Beispiel leitet alle Mails, die an einen beliebigen Benutzer in der virtuellen Domain dairy.org adressiert sind, an eine einzelne entfernte Mailadresse weiter. Der letzte Eintrag schließlich leitet alle Mails an einen Benutzer in der virtuellen Domain artist.org an denselben Benutzer in einer anderen Domain weiter. Zum Beispiel würde julie@artists.org an julie@red.firefly.com umgeleitet werden.
E-Mail ist ein ausgesprochen wichtiger Dienst. Es ist außerdem ein Dienst, der von Eindringlingen unterwandert werden kann, wenn er nicht richtig konfiguriert ist. Es ist sehr wichtig, dass Sie Ihre Konfiguration gründlich testen. Glücklicherweise bietet sendmail dafür eine relativ einfache Methode.
sendmail unterstützt einen Adresstest-Modus, der eine ganze Reihe von Tests ermöglicht. In den folgenden Beispielen geben wir eine Ziel-Mailadresse an sowie einen Test, der auf diese Adresse angewendet werden soll. sendmail verarbeitet dann diese Zieladresse, wobei die Ausgabe der einzelnen Regelsätze direkt nach der Verarbeitung angezeigt wird. Um sendmail in den Adresstest-Modus zu versetzen, rufen Sie es mit dem Argument -bt auf.
Die vorgegebene Konfigurationsdatei, die für den Adresstest-Modus benutzt wird, ist die Datei /etc/mail/sendmail.cf. Um eine alternative Konfigurationsdatei anzugeben, benutzen Sie das Argument -C. Das ist wichtig, weil Sie eine neue Konfiguration testen müssen, bevor Sie sie nach /etc/mail/sendmail.cf verschieben. Um die Linux-sendmail-Konfiguration zu testen, die wir weiter vorn in diesem Kapitel als Beispiel angelegt haben, benutzen Sie den folgenden sendmail-Befehl:
Der oben gezeigte >-Prompt signalisiert, dass sendmail bereit ist, einen Testbefehl zu empfangen. Während es sich im Adresstest-Modus befindet, akzeptiert sendmail eine Vielzahl von Befehlen, die die Konfiguration untersuchen, Einstellungen überprüfen und beobachten, wie E-Mail-Adressen durch sendmail verarbeitet werden. Tabelle 12-4 zeigt die Befehle, die im Testmodus zur Verfügung stehen.
Mehrere Befehle (=S, =M, $v und $=c) zeigen aktuelle sendmail-Konfigurationswerte an, die in der Datei sendmail.cf definiert sind. Der /map-Befehl zeigt Werte an, die in den sendmail-Datenbankdateien gesetzt wurden. Der Befehl -d kann verwendet werden, um die Menge der dargestellten Informationen zu ändern. Mit -d können sehr viele Debug-Level gesetzt werden, allerdings sind nur einige für den sendmail-Administrator von Nutzen. Lesen Sie in einer ausführlichen sendmail-Referenz nach, welche gültigen Debugging-Werte es gibt.
Zwei Befehle, .D und .C, werden benutzt, um Makro- und Klassenwerte in Echtzeit einzustellen. Verwenden Sie diese Befehle, um alternative Konfigurationseinstellungen auszuprobieren, bevor Sie die gesamte Konfiguration umbauen.
Zwei Befehle stellen die Interaktion zwischen sendmail und dem DNS dar. /canon zeigt den kanonischen Namen an, der für einen bestimmten Hostnamen vom DNS zurückgeliefert wurde. /mx zeigt die Liste der Mail-Exchanger, die für einen bestimmten Host vom DNS zurückgeliefert wurde.
Die meisten der verbleibenden Befehle verarbeiten eine E-Mail-Adresse durch die sendmail-Rewrite-Regeln. /parse zeigt die Verarbeitung einer Auslieferungsadresse an und stellt dar, welcher Mailer verwendet wird, um Mail auszuliefern, die an diese Adresse gesendet wurde. /try zeigt die Verarbeitung von Adressen für einen bestimmten Mailer. (Der Befehl /tryflags gibt an, ob die Absender- oder die Empfängeradresse vom /try-Befehl verarbeitet werden soll.) Benutzen Sie den Befehl regelsatz adresse, um die Verarbeitung einer Adresse durch eine beliebige Liste von Regelsätzen anzuzeigen, die Sie testen wollen.
Zuerst werden wir testen, ob sendmail in der Lage ist, Mail an lokale Benutzer im System auszuliefern. In diesen Tests erwarten wir, dass alle Adressen in den local-Mailer auf dieser Maschine umgeschrieben werden:
Diese Ausgabe zeigt uns, wie sendmail Mail verarbeitet, die an isaac auf diesem System adressiert ist. Auf jeder Zeile sehen Sie, welche Informationen einem Regelsatz übergeben wurden oder welches Ergebnis eine Verarbeitung durch einen Regelsatz lieferte. Wir teilten sendmail mit, dass wir die Adresse für eine Auslieferung analysieren lassen wollten. Die letzte Zeile zeigt uns, dass das System die Mail an isaac tatsächlich an den local-Mailer richtet.
Als Nächstes werden wir Mail testen, die an unsere SMTP-Adresse gerichtet ist: isa-ac@vstout.vbrew.com. Wir sollten in der Lage sein, das gleiche Ergebnis zu erzielen wie in unserem letzten Beispiel:
Nun testen wir, ob Mail, die an andere Hosts in der Domain vbrew.com adressiert ist, mittels SMTP-Mail direkt an diesen Host ausgeliefert wird:
Wir können sehen, dass dieser Test die Nachricht, die an den vorgegebenen SMTP-Mailer (esmtp) gerichtet ist, an den Host vale.vbrew.com und den Benutzer issac auf diesem Host gesendet hat.
Unser letzter Test überprüft die genericstable, die wir für die vstout.cf-Konfiguration erzeugt haben. Wir prüfen die Abbildung des Benutzernamens alana für alle drei Personen in der Domain vbrew.com, die diesen Benutzernamen verwenden. Der folgende Test zeigt uns, wie die genericstable alle Varianten dieses Namens zuordnet:
Dieser Test verwendet den Befehl /tryflags, mit dem wir festlegen können, ob wir die Header-Absenderadresse (HS), die Header-Empfängeradresse (HR), die Umschlag-Absenderadresse (ES) oder die Umschlag-Empfängeradresse (ER) verarbeiten wollen. In diesem Fall wollen wir feststellen, wie die Header-Absenderadresse umgeschrieben wird. Mit dem Befehl /try können wir angeben, welche Adresse für welchen Mailer umgeschrieben werden soll.
Dieser Test war ebenfalls erfolgreich. Die genericstable-Tests funktionieren für Alana Darling, Alana Henson und Alana Smiley.
Es gibt zwei Möglichkeiten, um den sendmail-Dämon auszuführen. Eine Möglichkeit besteht darin, ihn vom inetd-Dämon starten zu lassen. Die alternative und häufiger eingesetzte Methode sieht so aus, dass Sie sendmail als eigenständigen Dämon ausführen. Außerdem ist es üblich, dass Mailer-Programme sendmail als Benutzerbefehl starten, um lokal erzeugte Mail für die Auslieferung zu akzeptieren.
Wenn Sie sendmail als eigenständiges Programm ausführen, setzen Sie den sendmail-Befehl in eine Startdatei, damit er beim Booten aufgerufen wird. Die gebräuchliche Syntax lautet:
Das Argument -bd weist sendmail an, als Dämon zu laufen. Das Programm erzeugt einen Kindprozess und geht in den Hintergrund. Das Argument -q10m teilt sendmail mit, dass es alle zehn Minuten seine Warteschlange überprüfen soll. Sie können dafür auch ein anderes Intervall einstellen.
Um sendmail vom Netzwerkdämon inetd ausführen zu lassen, würden Sie einen solchen Eintrag wählen:
Das Argument -bs weist sendmail hier an, das SMTP-Protokoll an stdin/stdout zu verwenden, was für den Einsatz mit inetd erforderlich ist.
Wenn sendmail auf diese Weise aufgerufen wird, verarbeitet es alle Mails, die in der Warteschlange auf die Übertragung warten. Wird sendmail vom inetd ausgeführt, müssen Sie außerdem einen cron-Job erzeugen, der regelmäßig den Befehl runq aufruft, um den Mail-Spool zu verarbeiten. Ein entsprechender Eintrag in der cron-Tabelle könnte so aussehen:
In den meisten Installationen verarbeitet sendmail die Warteschlange alle 15 Minuten, wie in unserem crontab-Beispiel gezeigt. In diesem Beispiel wird der Befehl runq verwendet. Der runq-Befehl ist normalerweise ein symbolischer Link auf das sendmail-Programm und eine bequemere Form von:
Es gibt eine Vielzahl von Dingen, die Sie tun können, um die Verwaltung einer sendmail-Site effizient zu gestalten. Im sendmail-Paket sind einige Verwaltungsprogramme enthalten. Wir wollen uns die wichtigsten von ihnen einmal ansehen.
Mail wird vor der Übertragung im Verzeichnis /var/spool/mqueue in einer Warteschlange vorgehalten. Dieses Verzeichnis wird als Mail-Spool bezeichnet. Das sendmail-Programm stellt den Befehl mailq zur Verfügung, um eine formatierte Liste aller in der Warteschlange befindlichen Mail-Nachrichten mitsamt ihrem Status anzuzeigen. Der Befehl /usr/bin/mailq ist ein symbolischer Link auf das sendmail-Programm und verhält sich genauso wie:
Die Ausgabe des mailq-Befehls zeigt die Message-ID, die Größe der Nachricht, wann sie in die Warteschlange gestellt wurde, wer sie abgeschickt hat sowie eine Nachricht, die ihren aktuellen Status angibt. Im folgenden Beispiel sehen Sie eine Mail-Nachricht, die auf Grund eines Problems in der Warteschlange hängen geblieben ist:
Diese Nachricht befindet sich immer noch in der Warteschlange, weil die IP-Adresse des Ziel-Hosts nicht aufgelöst werden konnte.
Um sendmail zu zwingen, die Warteschlange sofort zu verarbeiten, rufen Sie den Befehl /usr/bin/runq auf. sendmail verarbeitet die Mail-Warteschlange dann im Hintergrund. Der runq-Befehl erzeugt keine Ausgabe, ein nachfolgender Befehl mailq teilt Ihnen jedoch mit, ob die Warteschlange leer ist.
Falls Sie eine temporäre Wählverbindung in das Internet mit einer festen IP-Adresse verwenden und darauf angewiesen sind, dass ein MX-Host Ihre Mail sammelt, wenn keine Verbindung besteht, werden Sie es nützlich finden, dass Sie den MX-Host zwingen können, seine Mail-Warteschlange zu verarbeiten, nachdem Sie Ihre Verbindung aufgebaut haben.
In der sendmail-Distribution ist ein kleines perl-Programm enthalten, das Mail-Hosts die Unterstützung einer solcher Funktionalität erleichtert. Das etrn-Skript hat auf einen entfernten Host fast die gleiche Wirkung wie die Ausführung von runq auf den lokalen Server. Falls wir den Befehl so aufrufen, wie in diesem Beispiel gezeigt:
zwingen wir den Host vstout.vbrew.com, alle Mails zu verarbeiten, die für Ihre lokale Maschine in der Warteschlange vorgehalten werden.
Normalerweise würden Sie diesen Befehl in Ihr PPP-Startskript einfügen, damit er ausgeführt wird, sobald Ihre Netzwerkverbindung aufgebaut wurde.
sendmail sammelt Daten über den Umfang des Mail-Verkehrs sowie Informationen über die Hosts, an die es Mail ausgeliefert hat. Es stehen zwei Befehle zur Verfügung, um diese Informationen anzuzeigen: mailstats und hoststat.
Der Befehl mailstats zeigt Statistiken über die Menge der Mail an, die von sendmail verarbeitet wird. Zuerst wird der Zeitpunkt ausgegeben, zu dem die Sammlung der Daten begonnen hat. Anschließend folgt eine Tabelle mit einer Zeile für jeden konfigurierten Mailer und einer Zeile, die eine Zusammenfassung für alle Mails bildet. Jede Zeile liefert acht Elemente mit verschiedenen Informationen, die in Tabelle 12-5 beschrieben werden.
Die Ausgabe des Befehls mailstats könnte so aussehen wie in Beispiel 12-7.
Diese Daten werden gesammelt, wenn die Option StatusFile in der Datei sendmail.cf aktiviert wurde und die Statusdatei existiert. Die Option StatusFile wird in der generischen Linux-Konfiguration definiert und ist deshalb in der Datei vstout.cf definiert worden, die wir aus der generischen Konfiguration erzeugt haben, wie gezeigt:
Um die Sammlung der Statistikdaten erneut zu beginnen, setzen Sie die Länge der Statistikdatei auf null und starten sendmail neu.
Der Befehl hoststat zeigt Informationen über den Status von Hosts an, zu denen sendmail versucht, Mail auszuliefern. Der Befehl hoststat ist äquivalent zu dem folgenden Aufruf von sendmail:
Die Ausgabe präsentiert jeden Host auf einer eigenen Zeile und außerdem den Zeitpunkt, ab wann die Auslieferung dorthin probiert wurde, sowie die Statusmeldung, die zu diesem Zeitpunkt empfangen wurde.
Ein persistenter Host-Status wird nur gepflegt, wenn ein Pfad für das Statusverzeichnis über die Option HostStatusDirectory definiert wird, die wiederum in der m4-Makro-Konfigurationsdatei durch confHOST_STATUS_DIRECTORY definiert wird. Standardmäßig ist für das Host-Statusverzeichnis kein Pfad definiert und es wird kein persistenter Host-Status gepflegt.
Beispiel 12-8 zeigt die Art der Ausgabe, die Sie vom hoststat-Befehl erwarten können. Beachten Sie, dass die meisten Ergebnisse eine erfolgreiche Auslieferung signalisieren. Das Ergebnis für earthlink.net zeigt allerdings, dass die Auslieferung nicht erfolgreich war. Die Statusmeldung kann Ihnen manchmal dabei helfen, die Ursache für einen Fehler festzustellen. In diesem Fall war die Zeit für die Verbindung abgelaufen, wahrscheinlich weil der Host zu dem Zeitpunkt, an dem der Auslieferungsversuch erfolgte, ausgeschaltet oder nicht erreichbar war.
Der Befehl purgestat löscht die gesammelten Host-Daten und ist äquivalent zu einem Aufruf von sendmail als:
Die Statistiken wachsen immer weiter an, bis Sie sie löschen. Sie sollten den Befehl purgestat regelmäßig ausführen, um die Suche in den aktuellen Einträgen zu erleichtern, vor allem wenn Ihre Site sehr ausgelastet ist. Sie könnten den Befehl in eine crontab-Datei einfügen, so dass er automatisch ausgeführt wird. Oder Sie rufen den Befehl gelegentlich von Hand auf.
sendmail ist ein komplexes Thema - viel zu komplex, um in einem einzigen Kapitel umfassend behandelt zu werden. Dieses Kapitel soll Ihnen einen Einstieg liefern und Ihnen helfen, einen einfachen Server zu konfigurieren. Falls Sie jedoch eine komplexere Konfiguration haben oder kompliziertere Funktionen benutzen wollen, benötigen Sie mehr Informationen. Hier sind einige Quellen, an denen Sie Ihre Suche nach Wissen beginnen können.
Mit Hilfe dieser Quellen sollten Sie in der Lage sein, mehr über sendmail zu erfahren, als Sie jemals wissen müssen. Auf geht's!
| |
|
|
|
© 2005, O'Reilly Verlag GmbH & Co. KG