Suche im Katalog
Linux Netzwerker-Handbuch

Linux Netzwerker-Handbuch


Tony 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


TOC PREV NEXT INDEX

Kapitel 12

sendmail

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.

Die sendmail-Distribution installieren

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.

Herunterladen des sendmail-Quellcodes

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:

# ftp ftp.sendmail.org
Connected to ftp.sendmail.org (209.246.26.22).
220 services.sendmail.org FTP server (Version 6.00LS) ready.
Name (ftp.sendmail.org:craig): anonymous
331 Guest login ok, send your email address as password.
Password: win@vstout.com
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd /pub/sendmail
250 CWD command successful.
ftp> get sendmail.8.12.11.tar.gz
local: sendmail.8.12.11.tar.gz remote: sendmail.8.12.11.tar.gz
227 Entering Passive Mode (209,246,26,22,244,234)
150 Opening BINARY mode data connection for 'sendmail.8.12.11.tar.gz' (1899112 bytes).
226 Transfer complete.
1899112 bytes received in 5.7 secs (3.3e+02 Kbytes/sec)
ftp> get sendmail.8.12.11.tar.gz.sig
local: sendmail.8.12.11.tar.gz.sig remote: sendmail.8.12.11.tar.gz.sig
227 Entering Passive Mode (209,246,26,22,244,237)
150 Opening BINARY mode data connection for 'sendmail.8.12.11.tar.gz.sig' (152 bytes).
226 Transfer complete.
152 bytes received in 0.000949 secs (1.6e+02 Kbytes/sec)

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:

ftp> get PGPKEYS
local: PGPKEYS remote: PGPKEYS
227 Entering Passive Mode (209,246,26,22,244,238)
150 Opening BINARY mode data connection for 'PGPKEYS' (61916 bytes).
226 Transfer complete.
61916 bytes received in 0.338 secs (1.8e+02 Kbytes/sec)
ftp> quit
221 Goodbye.

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:

# gpg --import PGPKEYS
gpg: key 16F4CCE9: not changed
gpg: key 95F61771: public key imported
gpg: key 396F0789: not changed
gpg: key 678C0A03: not changed
gpg: key CC374F2D: not changed
gpg: key E35C5635: not changed
gpg: key A39BA655: not changed
gpg: key D432E19D: not changed
gpg: key 12D3461D: not changed
gpg: key BF7BA421: not changed
gpg: key A00E1563: non exportable signature (class 10) - skipped
gpg: key A00E1563: not changed
gpg: key 22327A01: not changed
gpg: Total number processed: 12
gpg: imported: 1 (RSA: 1)
gpg: unchanged: 11

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:

# gpg --fingerprint 95F61771
pub 1024R/95F61771 2003-12-10 Sendmail Signing Key/2004 <sendmail@Sendmail.ORG>
Key fingerprint = 46 FE 81 99 48 75 30 B1 3E A9 79 43 BB 78 C1 D4

Vergleichen Sie den angezeigten Fingerprint mit Tabelle 12-1, die die Fingerprints für die sendmail-Signaturschlüssel enthält.

Tabelle 12-1
Fingerprints für sendmail-Signaturschlüssel 
Jahr
Fingerprint
1997
CA AE F2 94 3B 1D 41 3C 94 7B 72 5F AE 0B 6A 11
1998
F9 32 40 A1 3B 3A B6 DE B2 98 6A 70 AF 54 9D 26
1999
25 73 4C 8E 94 B1 E8 EA EA 9B A4 D6 00 51 C3 71
2000
81 8C 58 EA 7A 9D 7C 1B 09 78 AC 5E EB 99 08 5D
2001
59 AF DC 3E A2 7D 29 56 89 FA 25 70 90 0D 7E C1
2002
7B 02 F4 AA FC C0 22 DA 47 3E 2A 9A 9B 35 22 45
2003
C4 73 DF 4A 97 9C 27 A9 EE 4F B2 BD 55 B5 E0 0F
2004
46 FE 81 99 48 75 30 B1 3E A9 79 43 BB 78 C1 D4

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:

# gpg --edit-key 95F61771
gpg (GnuPG) 1.0.7; Copyright (C) 2002 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

gpg: checking the trustdb
gpg: checking at depth 0 signed=1 ot(-/q/n/m/f/u)=0/0/0/0/0/1
gpg: checking at depth 1 signed=1 ot(-/q/n/m/f/u)=1/0/0/0/0/0
pub 1024R/95F61771 created: 2003-12-10 expires: never trust: -/q
(1). Sendmail Signing Key/2004 <sendmail@Sendmail.ORG>

Command> sign

pub 1024R/95F61771 created: 2003-12-10 expires: never trust: -/q
Fingerprint: 46 FE 81 99 48 75 30 B1 3E A9 79 43 BB 78 C1 D4

Sendmail Signing Key/2004 <sendmail@Sendmail.ORG>

How carefully have you verified the key you are about to sign actually belongs to the person named above? If you don't know what to answer, enter "0".

(0) I will not answer. (default)
(1) I have not checked at all.
(2) I have done casual checking.
(3) I have done very careful checking.

Your selection? 3
Are you really sure that you want to sign this key
with your key: "Winslow Henson <win.henson@vstout.vbrew.com>"

I have checked this key very carefully.

Really sign? y

You need a passphrase to unlock the secret key for
user: "Winslow Henson <win.henson@vstout.vbrew.com>"
1024-bit DSA key, ID 34C9B515, created 2003-07-23

Command> quit
Save changes? y

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:

# gpg --verify sendmail.8.12.11.tar.gz.sig sendmail.8.12.11.tar.gz
gpg: Signature made Sun 18 Jan 2004 01:08:52 PM EST using RSA key ID 95F61771
gpg: Good signature from "Sendmail Signing Key/2004 <sendmail@Sendmail.ORG>"
gpg: checking the trustdb
gpg: checking at depth 0 signed=2 ot(-/q/n/m/f/u)=0/0/0/0/0/1
gpg: checking at depth 1 signed=0 ot(-/q/n/m/f/u)=2/0/0/0/0/0

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.

sendmail kompilieren

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:

# cd sendmail-8.12.11
# ./Build

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:

$ ./Build -f ourconfig.m4

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.

define
Der define-Befehl modifiziert den aktuellen Wert, der in der Variable gespeichert ist.
APPENDDEF
Das Makro APPENDDEF hängt einen Wert an eine existierende Liste von Werten an, die in einer Variable gespeichert sind.
PREPENDDEF
Das Makro PREPENDDEF stellt einer existierenden Liste von Werten, die in einer Variable gespeichert sind, einen Wert voran.

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

define(`confMANROOT', `/usr/man/man')

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:

define(`confMANROOT', `/usr/share/man/man')

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:

# cd devtools/Site
# cat >> site.config.m4
APPENDDEF(`confMAPDEF', `-DLDAPMAP')
APPENDDEF(`confLIBS', `-lldap -llber')
Ctrl-D
# cd ../../
# ./Build -c

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.

Das sendmail-Binary installieren

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:

# grep smmsp /etc/passwd
smmsp:x:25:25:Mail Submission:/var/spool/clientmqueue:/sbin/nologin
# grep smmsp /etc/group
smmsp:x:25:

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:

# ./Build install

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:

drwxrwx--- 2 smmsp smmsp 4096 Jun 7 16:22 clientmqueue
-r-xr-sr-x 1 root smmsp 568701 Jun 7 16:51 /usr/sbin/sendmail

Nachdem sendmail installiert wurde, muss es konfiguriert werden. Dieses Thema nimmt den größten Teil dieses Kapitels ein.

sendmail-Konfigurationsdateien

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).

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.

Häufig benutzte sendmail.mc-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:

VERSIONID
OSTYPE
DOMAIN
FEATURE
define
MAILER
LOCAL_*

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.

VERSIONID

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:

VERSIONID(`sendmail.mc, 6/11/2004 18:31 by Win Henson')

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.

OSTYPE

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.

DOMAIN

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:

DOMAIN(`vbrew')

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.

FEATURE

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:

FEATURE(name)

Dabei ist name der Name der Funktion. Manche Funktionen beachten einen optionalen Parameter in einem solchen Format:

FEATURE(name, param)

Dabei ist param der anzugebende Parameter.

define

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:

define(`confDOMAIN_NAME', `vstout.vbrew.com')

Der oben gezeigte define-Befehl platziert Folgendes in die Datei sendmail.cf:

Djvstout.vbrew.com

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

undefine(`confDOMAIN_NAME')

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.

MAILER

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.

Tabelle 12-2
Argumente für das MAILER-Makro 
Argument
Zweck
local
Fügt die Mailer local und prog hinzu
smtp
Fügt alle SMTP-Mailer hinzu: smtp, esmtp, smtp8, dsmtp und relay
uucp
Fügt alle UUCP-Mailer hinzu: uucp-old (uucp) und uucp-new (suucp)
usenet
Erweitert sendmail um Unterstützung für Usenet-News
fax
Fügt Unterstützung für FAX mittels HylaFAX-Software hinzu
pop
Erweitert sendmail um Unterstützung für das Post Office Protocol (POP)
procmail
Fügt eine Schnittstelle für procmail hinzu
mail11
Fügt den DECnet-Mailer mail11 hinzu
phquery
Fügt das phquery-Programm für das CSO-Telefonbuch hinzu
qpage
Fügt den QuickPage-Mailer hinzu, der verwendet wird, um E-Mail an einen Pager zu senden
cyrus
Fügt die Mailer cyrus und cyrusbb hinzu

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:

smtp
Dieser Mailer verarbeitet nur traditionelle 7-Bit-ASCII-SMTP-Mail.
esmtp
Dieser Mailer unterstützt Extended SMTP (ESMTP), das die ESMTP-Protokollerweiterungen sowie die komplexen Nachrichtenrümpfe und erweiterten Datentypen von MIME-Mail versteht. Das ist der Standard-Mailer, der für SMTP-Mail benutzt wird.
smtp8
Dieser Mailer sendet 8-Bit-Daten an den entfernten Server, selbst wenn dieser kein ESMTP unterstützt.
dsmtp
Dieser Mailer unterstützt den ESMTP-ETRN-Befehl, der es dem Zielsystem ermöglicht, Mail zu empfangen, die sich auf dem Server in einer Warteschlange befindet.
relay
Dieser Mailer wird verwendet, um SMTP-Mail an einen anderen Mailserver weiterzugeben.

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.

LOCAL_*

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.

LOCAL_CONFIG
Markiert den Anfang eines Blocks mit sendmail.cf-Befehlen, die in den Abschnitt mit lokalen Informationen der sendmail.cf-Datei aufgenommen werden sollen.
LOCAL_NET_CONFIG
Markiert den Anfang eines Abschnitts mit Rewrite-Regeln, die an das Ende des Regelsatzes 0 angefügt werden sollen, der auch als Regelsatz parse bezeichnet wird.
LOCAL_RULE_n
Markiert den Anfang eines Abschnitts mit Rewrite-Regeln, die zu Regelsatz 0, 1, 2 oder 3 hinzugefügt werden sollen. Das n identifiziert den Regelsatz, zu dem die Rewrite-Regeln hinzugefügt werden sollen.
LOCAL_RULESET
Markiert den Anfang eines eigenen Regelsatzes, der zur Konfiguration hinzugefügt werden soll.

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.

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.

Tabelle 12-3
sendmail.cf-Konfigurationsbefehle 
Befehl
Syntax
Bedeutung
Version Level
[Vlevel/anbieter]
Gibt das Versions-Level an.
Define Macro
Dxwert
Setzt Makro x auf wert.
Define Class
Ccwort1[ wort2] ...
Setzt Klasse c auf wort1 wort2 ....
Define Class
Fcdatei
Lädt Klasse c aus datei.
Key File
Kname typ [argument]
Definiert Datenbank name.
Set Option
Ooption=wert
Setzt option auf wert.
Trusted Users
Tbenutzer1[ benutzer2 ...]
Vertrauenswürdige Benutzer sind benutzer1 benutzer2 ....
Set Precedence
Pname=zahl
Setzt name auf Präzedenz zahl.
Define Mailer
Mname, [feld=wert]
Definiert Mailer name.
Define Header
H[?mflag ?]name :format
Setzt das Header-Format.
Set Ruleset
Sn
Startet Regelsatz Nummer n.
Define Rule
Rlhs rhs Kommentar
Konvertiert lhs-Muster in das rhs-Format.

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.

sendmail.cf-R- und -S-Befehle

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:

Sn
Rlhs rhs
Rlhs2 rhs2

Die linke Seite

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:

$@
Entspricht genau null Token
$*
Entspricht null oder mehreren Token
$+
Entspricht einem oder mehreren Token
$-
Entspricht genau einem Token
$=x
Entspricht allen Werten in Klasse x
$~x
Entspricht allen Werten, die nicht in Klasse x sind

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:

O OperatorChars=.:%@!^/[  ]+

Betrachten Sie die folgende Adresse:

alana@ipa.vbrew.com

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.

Die rechte Seite

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:

$n
Dieses Metasymbol wird durch das n-te unbestimmte Token von der linken Seite ersetzt.
$[name$]
Dieser String wird durch die kanonische Form des angegebenen Hostnamens ersetzt.
$(map schlüssel $:vorgabe $)
Diese spezielle Syntax liefert das Ergebnis einer Suche nach schlüssel in der Datenbank map. Wenn die Suche nicht erfolgreich verläuft, wird der Wert zurückgeliefert, der für vorgabe definiert wurde. Ist keine Vorgabe angegeben und schlägt die Suche fehl, wird der schlüssel-Wert zurückgeliefert.
$>n
Dieses Metasymbol ruft Regelsatz n auf, um den Rest der Zeile zu verarbeiten.

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:

$@
Dieses Metasymbol beendet den Regelsatz.
$:
Dieses Metasymbol beendet diese einzelne Regel.

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:

$#mailer
Dieses Metasymbol veranlasst die Regelsatzauswertung zum Anhalten und legt den Mailer fest, der verwendet werden soll, um diese Nachricht im nächsten Schritt ihrer Auslieferung zu transportieren. Der spezielle Mailer error kann auf diese Weise aufgerufen werden, um eine Fehlermeldung zurückzuliefern.
$@host
Dieses Metasymbol legt den Host fest, an den diese Nachricht ausgeliefert wird. Wenn der lokale Host als Zielhost fungiert, kann diese Syntax im Mail-Auslieferungstriple weggelassen werden. Bei host kann es sich um eine durch Doppelpunkte getrennte Liste von Zielhosts handeln, die nacheinander ausprobiert werden, um die Nachricht auszuliefern.
$:benutzer
Dieses Metasymbol gibt den Empfänger für die Mail-Nachricht an.

Ein einfaches Beispiel für ein Regelmuster

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.

Ein vollständiges Beispiel für eine Rewrite-Regel

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.

Beispiel 12-1
Beispiel für eine Rewrite-Regel 
LOCAL_NET_CONFIG
R$*<@$*.$m.>$* $#esmtp $@$2.$m. $:$1<@$2.$m.>$3

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.

Anlegen einer sendmail-Konfiguration

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.

Beispiel 12-2
Die Datei generic-linux.mc 
divert(-1)
#
# Copyright (c) 1998, 1999 Sendmail, Inc. and its suppliers.
# All rights reserved.
# Copyright (c) 1983 Eric P. Allman. All rights reserved.
# Copyright (c) 1988, 1993
# The Regents of the University of California. All rights reserved.
#
# By using this file, you agree to the terms and conditions set
# forth in the LICENSE file which can be found at the top level of
# the sendmail distribution.
#
#
#
# This is a generic configuration file for Linux.
# It has support for local and SMTP mail only. If you want to
# customize it, copy it to a name appropriate for your environment
# and do the modifications there.
#
divert(0)dnl
VERSIONID(`$Id: ch12,v 1.6 2005/01/19 03:22:50 free2 Exp adam $')
OSTYPE(`linux')dnl
DOMAIN(`generic')dnl
MAILER(`local')dnl
MAILER(`smtp')dnl

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:

VERSIONID(`$Id: ch12,v 1.6 2005/01/19 03:22:50 free2 Exp adam $')

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 linux.m4 OSTYPE

Die Datei cf/ostype/linux.m4 wird in Beispiel 12-3 gezeigt.

Beispiel 12-3
Die Datei linux.m4 OSTYPE 
divert(-1)
#
# Copyright (c) 1998, 1999 Sendmail, Inc. and its suppliers.
# All rights reserved.
# Copyright (c) 1983 Eric P. Allman. All rights reserved.
# Copyright (c) 1988, 1993
# The Regents of the University of California. All rights reserved.
#
# By using this file, you agree to the terms and conditions set
# forth in the LICENSE file which can be found at the top level of
# the sendmail distribution.
#
#
divert(0)
VERSIONID(`$Id: ch12,v 1.6 2005/01/19 03:22:50 free2 Exp adam $')
define(`confEBINDIR', `/usr/sbin')
ifdef(`PROCMAIL_MAILER_PATH',,
define(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail'))
FEATURE(local_procmail)

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 generic.m4 DOMAIN

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.

Beispiel 12-4
Die Datei generic.m4 DOMAIN 
divert(-1)
#
# Copyright (c) 1998, 1999 Sendmail, Inc. and its suppliers.
# All rights reserved.
# Copyright (c) 1983 Eric P. Allman. All rights reserved.
# Copyright (c) 1988, 1993
# The Regents of the University of California. All rights reserved.
#
# By using this file, you agree to the terms and conditions set
# forth in the LICENSE file which can be found at the top level of
# the sendmail distribution.
#
#
#
# The following is a generic domain file. You should be able to
# use it anywhere. If you want to customize it, copy it to a file
# named with your domain and make the edits; then, copy the appropriate
# .mc files and change `DOMAIN(generic)' to reference your updated domain
# files.
#
divert(0)
VERSIONID(`$Id: ch12,v 1.6 2005/01/19 03:22:50 free2 Exp adam $')
define(`confFORWARD_PATH', `$z/.forward.$w+$h:$z/.forward+$h:$z/.forward.$w:$z/.forward')dnl
define(`confMAX_HEADERS_LENGTH', `32768')dnl
FEATURE(`redirect')dnl
FEATURE(`use_cw_file')dnl
EXPOSED_USER(`root')

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:

551 User not local; please try <neue-adresse>

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 setzt /usr/sbin als Pfad auf die ausführbaren Binärdateien.
Sie setzt den procmail-Pfad auf /usr/bin/procmail.
Sie benutzt procmail als local-Mailer.

Sie definiert den Suchpfad für .forward-Dateien.
Sie fügt der Konfiguration Unterstützung für die Pseudo-Domain .REDIRECT hinzu.
Sie lädt die Klasse $=w aus der Datei /etc/local-host-names.
Sie fügt root der Klasse $=E hinzu.
Sie fügt die Mailer local, prog, smtp, esmtp, smtp8, dsmtp und relay zur Konfiguration hinzu.

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.

Anlegen einer sendmail-Beispielkonfiguration für Linux

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.

$ cd sendmail-8.12.11/cf/cf
$ cp generic-linux.mc vstout.mc

Wir konfigurieren vstout als Mailserver für unsere Gruppe. Wir wollen, dass er Folgendes leistet:

Er akzeptierte eingehende Mail für verschiedene Clients, die vorhaben, Mail auf dem Server zu speichern. Es sind keine Modifikationen der m4-Konfiguration erforderlich, um das zu unterstützen, da die Datei domain/generic.m4, die in der Linux-Konfiguration verwendet wird, bereits den Befehl FEATURE(`use_cw_file') enthält.
Er gibt als Relay Mail für Clients in der Domain vbrew.com weiter. Das Implementieren dieser Funktion erfordert keine Änderungen an der m4-Konfiguration. sendmail-Konfigurationen unterstützen standardmäßig das Relaying für alle Domains, die in der Datei relay-domains definiert sind. Wir werden später in diesem Kapitel sehen, wie die Datei relay-domains konfiguriert wird, wenn wir sendmail-Datenbanken besprechen.
Er schreibt die Absenderadresse in ausgehenden Mails in ein generisches Format um, das von allen in vbrew.com benutzt wird. Dazu werden wir Unterstützung für die genericstable-Datenbank hinzufügen. Der Inhalt der genericstable-Datenbank wird im Abschnitt über die sendmail-Datenbanken später in diesem Kapitel behandelt.
Er bietet eine Anti-Spam-Unterstützung. Dazu werden wir die access-Datenbank verwenden.
Er ist mit zusätzlichen Sicherheitsmaßnahmen leicht zu konfigurieren. Die access-Datenbank, die wegen ihrer Anti-Spam-Fähigkeiten hinzugefügt wird, besitzt viele weitere leicht konfigurierbare Funktionen. Im Abschnitt über die sendmail-Datenbanken weiter hinten in diesem Kapitel werden wir noch mehr über die access-Datenbank erfahren.

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:

FEATURE(`genericstable')
GENERICS_DOMAIN(`vbrew.com')
FEATURE(`generics_entire_domain')
FEATURE(`access_db')

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:

Beispiel 12-5
Eigene Beispielkonfiguration 
VERSIONID(`Sample vstout configuration by Craig Hunt')
OSTYPE(`linux')dnl
DOMAIN(`generic')dnl
dnl Add support for the genericstable
FEATURE(`genericstable')
dnl Apply the genericstable to the vbrew.com domain
GENERICS_DOMAIN(`vbrew.com')
dnl Apply the genericstable to every host in the domain
FEATURE(`generics_entire_domain')
dnl Add support for the versatile access database
FEATURE(`access_db')
MAILER(`local')dnl
MAILER(`smtp')dnl

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.

Erstellen der Datei sendmail.cf

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:

$ ./Build vstout.cf
Using M4=/usr/bin/m4
rm -f vstout.cf
/usr/bin/m4 ../m4/cf.m4 vstout.mc > vstout.cf || ( rm -f vstout.cf && exit 1 )
chmod 444 vstout.cf

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:

$ m4 ../m4/cf.m4 vstout.mc > vstout.cf

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:

# cp vstout.cf /etc/mail/sendmail.cf

Sie können dazu aber auch den Build-Befehl verwenden:

# mv vstout.cf sendmail.cf
# ./Build install-cf
Using M4=/usr/bin/m4
../../devtools/bin/install.sh -c -o root -g bin -m 0444 sendmail.cf /etc/mail/sendmail.cf
../../devtools/bin/install.sh -c -o root -g bin -m 0444 submit.cf /etc/mail/submit.cf

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:

# kill -HUP `head -1 /var/run/sendmail.pid`

Manche Linux-Systeme bringen ihre eigenen Werkzeuge zum Verwalten von Dämonen mit. Beispielsweise können einige Systeme sendmail mit dem service-Befehl starten:

# service sendmail start
Starting sendmail: [ OK ]

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.

sendmail-Datenbanken

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:

aliases
Die aliases-Datenbank ist standardmäßig in der Konfiguration enthalten. Sie ist eine wichtige Komponente bei der Auslieferung lokaler Mail und der Mail-Weiterleitung. Der Konfiguration muss nichts hinzugefügt werden, um die aliases-Datenbank benutzen zu können.
local-host-names
Die Datei local-host-names wird einer Konfiguration durch die Funktion use_cw_file hinzugefügt. Mit dieser Datei definieren Sie, welche Mail für eine lokale Auslieferung akzeptiert wird.
relay-domains
Die Datei relay-domains ist standardmäßig in der Konfiguration enthalten. Deshalb sind keine Änderungen an der sendmail-Konfiguration erforderlich, um diese Datei zu benutzen. Die Datei relay-domains kann das Relaying autorisieren, das normalerweise deaktiviert ist.
genericstable
Die Funktion genericstable fügt Unterstützung für diese Datenbank hinzu. genericstable wird verwendet, um die E-Mail-Adressen, die von einer Einrichtung benutzt werden, in das Format umzuschreiben, das der Außenwelt präsentiert werden soll.
access
Die Funktion access_db fügt Unterstützung für diese Datenbank hinzu. Die access-Datenbank ist auf vielerlei Weise nützlich.

In den folgenden Abschnitten werden diese und weitere Datenbanken beschrieben, die nicht in der Beispielkonfiguration zum Einsatz kamen.

Die aliases-Datenbank

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:

Sie können eine Abkürzung oder einen bekannten Namen für Mail bereitstellen, die an eine oder mehrere Personen gehen soll. Beispielsweise erfordern alle Systeme Aliase für die bekannten Namen Postmaster und MAILER-DAEMON, damit sie RFC-konform sind.
Sie können ein Programm aufrufen, wobei die Mail-Nachricht die Eingabe des Programms darstellt. Achten Sie immer besonders auf die Sicherheit, wenn Sie Aliase definieren, die Programme starten oder in Programme schreiben, da sendmail manchmal mit root-Berechtigungen ausgeführt wird.
Sie können E-Mail an eine Datei ausliefern.

Einzelheiten bezüglich der Mail-Aliase finden Sie in der Manpage aliases(5). Eine aliases-Datei könnte aussehen wie in Beispiel 12-6.

Beispiel 12-6
Beispiel für eine aliases-Datei 
#
# Die beiden folgenden Aliase müssen vorhanden sein, um RFC-Konformität zu gewährleisten.
# Es ist wichtig, dass dahinter 'eine Person' steht, die regelmäßig ihre Mail liest.
#
postmaster: root # notwendiger Eintrag
MAILER-DAEMON: postmaster # notwendiger Eintrag
#
#
# das sind übliche Arten von Aliasen
#
usenet: janet # Alias für eine Person
admin: joe,janet # Alias für mehrere Personen
newspak-users: :include:/usr/lib/lists/newspak # liest Empfänger aus Datei
changefeed: |/usr/local/lib/gup # Alias, der ein Programm aufruft
complaints: /var/log/complaints # Alias schreibt Mail in Datei
#

Immer wenn Sie die Textdatei /etc/aliases aktualisieren, müssen Sie folgenden Befehl ausführen:

# /usr/bin/newaliases

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.

Die Datei local-host-names

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:

Fw/etc/mail/local-host-names

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:

vbrew.com
vporter.vbrew.com
vale.vbrew.com
vlager.vbrew.com
vpils.vbrew.com
vipa.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:

define(`confDONT_PROBE_INTERFACES', `true')

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:

LOCAL_DOMAIN(`vbrew.com')
LOCAL_DOMAIN(`vipa.vbrew.com')

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

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:

FEATURE(`bestmx_is_local', `vbrew.com')

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.

Die Datei relay-domains

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:

# cat >> /etc/mail/relay-domains
vbrew.com
Ctrl-D

Starten Sie sendmail erneut, um sicherzustellen, dass es die Datei relay-domains einliest:

# kill -HUP `head -1 /var/run/sendmail.pid`

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:

dnl RELAY_DOMAIN adds a domain name to class R
RELAY_DOMAIN(`vbrew.com')

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:

dnl A feature that relays mail for the local domain
FEATURE(`relay_entire_domain')

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:

promiscuous_relay
Diese Funktion schaltet das Relaying für alle Hosts ein. Natürlich schließt das auch die lokale Domain ein, diese Möglichkeit funktioniert also. Allerdings würde damit ein offenes Relay für Spammer entstehen. Vermeiden Sie die Funktion promiscuous_relay, selbst wenn Ihr Host durch eine Firewall geschützt ist.
relay_local_from
Diese Funktion aktiviert das Relaying für Mail, falls die E-Mail-Adresse in der Umschlagabsenderadresse der Mail den Namen eines Hosts in der lokalen Domain enthält. Da die Umschlagabsenderadresse gefälscht sein kann, könnten Spammer Ihren Server dazu bringen, Spam weiterzuvermitteln.

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.

Die genericstable-Datenbank

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:

FEATURE(`genericstable')
GENERICS_DOMAIN(`vbrew.com')
FEATURE(`generics_entire_domain')

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:

# cd /etc/mail
# cat > genericstable
kathy kathy.mccafferty@vbrew.com
win winslow.smiley@vbrew.com
sara sara.henson@vbrew.com
dave david.craig@vbrew.com
becky rebecca.fro@vbrew.com
jay jay.james@vbrew.com
alana@vpils.vbrew.com alana.darling@vbrew.com
alana@vale.vbrew.com alana.henson@vbrew.com
alana alana.sweet@vbrew.com
Ctrl-D
# makemap hash genericstable < genericstable

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:

# cd /etc/mail
# cat > aliases
kathy.mccafferty: kathy
win.strong: craig
sara.henson: sara
david.craig: dave
rebecca.fro: becky
alana.smiley: alana
alana.darling: alana@vpils.vbrew.com
alana.henson: alana@vale.vbrew.com
jay.james: jay
Ctrl-D
# newaliases

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

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:

FEATURE(`access_db')dnl

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:

eine Person, die entweder über die vollständige E-Mail-Adresse (benutzer@host.domain) oder einen Benutzernamen (benutzername@), definiert wird
einen Host, der über seinen Hostnamen oder seine IP-Adresse identifiziert wird
eine Domain, die über einen Domainnamen identifiziert wird
ein Netzwerk, das über den Netzwerkanteil einer IP-Adresse identifiziert wird

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:

To:
Die Aktion wird nur dann durchgeführt, wenn die Mail an die angegebene Adresse gesandt werden soll.
From:
Die Aktion wird nur dann durchgeführt, wenn die Mail von der angegebenen Adresse empfangen wurde.
Connect:
Die Aktion wird nur dann durchgeführt, wenn die angegebene Adresse die Adresse des Systems am anderen Ende der SMTP-Verbindung ist.

Es gibt fünf einfache Aktionen, die auf der rechten Seite einer Zugriffsregel definiert werden können:

OK
Akzeptiert die Mail-Nachricht.
RELAY
Akzeptiert die Mail-Nachrichten für das Relaying.
REJECT
Weist die Mail mit einer generischen Nachricht zurück.
DISCARD
Verwirft die Nachricht mit Hilfe des Mailers $#discard.
ERROR:dsn:code text
Liefert eine Fehlermeldung zurück, wobei der angegebene DSN-Code, der angegebene SMTP-Fehlercode und der festgelegte Text als Nachricht zum Einsatz kommen.

Eine beispielhafte /etc/mail/access könnte so aussehen:

friends@cybermail.com REJECT
aol.com REJECT
207.46.131.30 REJECT
postmaster@aol.com OK
linux.org.au RELAY
example.com ERROR:5.7.1:550 Relaying denied to spammers

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.

Weitere Datenbanken

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:

define(`confUSERDB_SPEC', `pfad')
Die Option confUSERDB_SPEC teilt sendmail mit, dass es die user-Datenbank auf die lokalen Adressen anwenden soll, und zwar nachdem die aliases-Datenbank, aber bevor die .forward-Datei angewendet wird. Das Pfad-Argument gibt sendmail bekannt, wo die Datenbank zu finden ist. Die user-Datenbank wird nicht oft verwendet, da die sendmail-Entwickler von ihrer Verwendung in den Antworten auf die Fragen 3.3 und 3.4 der FAQ abraten.
FEATURE(`use_ct_file', `pfad')
Die Funktion use_ct_file weist sendmail an, vertrauenswürdige Benutzernamen aus der angegebenen Datei in die Klasse $=t aufzunehmen. Da es Benutzern, die in $=t aufgeführt sind, erlaubt ist, Mail unter dem Benutzernamen eines anderen zu senden, stellen sie ein Sicherheitsrisiko dar. Sie müssen weniger Dateien vor Manipulationen schützen, wenn die vertrauenswürdigen Benutzer mit Hilfe von confTRUSTED_USERS in der Makrokonfigurationsdatei definiert werden. Und da nur wenigen Benutzern vertraut werden sollte, ist es nicht besonders aufwändig, sie in der Makrokonfigurationsdatei zu definieren.
FEATURE(`domaintable', `spezifikation')
Die Funktion domaintable weist sendmail an, dass es die Domain-Tabelle benutzen soll, um einen Domainnamen auf einen anderen abzubilden. Es kann eine optionale Datenbankspezifikation angegeben werden, um den Datenbanktyp und den Pfadnamen anzugeben. Standardmäßig ist die Datenbank vom Typ hash, und der Pfad lautet /etc/mail/domaintable. Die domaintable erleichtert den Übergang von einem alten zu einem neuen Domainnamen, indem der alte Name in allen Mails in den neuen Namen übersetzt wird. Da Sie sich vermutlich selten in einer solchen Situation befinden, wird diese Datenbank nicht oft eingesetzt.
FEATURE(`uucpdomain', `spezifikation')
Die Funktion uucpdomain teilt sendmail mit, dass es die uucpdomain-Datenbank verwenden soll, um UUCP-Site-Namen auf Internet-Domainnamen abzubilden. Die optionale Datenbankspezifikation überschreibt den vorgegebenen Datenbanktyp hash und den vorgegebenen Datenbankpfad /etc/mail/uucpdomain. Die uucpdomain-Datenbank konvertiert E-Mail-Adressen aus der .UUCP-Pseudo-Domain in altmodische UUCP-Bang-Adressen. Der Schlüssel zu dieser Datenbank ist der Hostname aus der .UUCP-Pseudo-Domain. Der Wert, der für diesen Schlüssel zurückgeliefert wird, ist die Bang-Adresse. Es ist sehr unwahrscheinlich, dass Sie diese Datenbank einsetzen werden, da sogar Sites, die immer noch UUCP verwenden, oft keine Bang-Adressen benutzen, weil aktuelle UUCP-Mailer E-Mail-Adressen verarbeiten, die genauso aussehen wie Internet-Adressen.
FEATURE('bitdomain', 'spezifikation')
Die Funktion bitdomain teilt sendmail mit, dass es die bitdomain-Datenbank verwenden soll, um BITNET-Hostnamen auf Internet-Domainnamen abzubilden. BITNET ist ein veraltetes IBM-Mainframe-Netzwerk, das Sie sicher nicht einsetzen, ebenso wenig wie diese Datenbank.

Es gibt zwei weitere Datenbanken namens mailertable und virtusertable, die zwar nicht in der Beispielkonfiguration enthalten, aber dennoch nützlich sind.

mailertable

Die Funktion mailertable fügt der sendmail-Konfiguration Unterstützung für die mailertable hinzu. Die Syntax für die Funktion mailertable lautet:

FEATURE(`mailertable', `spezifikation')

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:

.example.edu smtp8:oldserver.example.edu

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:

.example.edu smtp8:oldserver.example.edu
vlite.vbrew.com esmtp:postmaster@vstout.vbrew.com
vmead.vbrew.com error:nohost This host is unavailable

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.

virtusertable

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:

FEATURE(`virtusertable')

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:

samiam@bovine.net colin
sunny@bovine.net darkhorse@mystery.net
@dairy.org mail@jhm.org
@artist.org $1@red.firefly.com

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.

Testen Ihrer Konfiguration

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:

# /usr/sbin/sendmail -bt -Cvstout.cf
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
>

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.

Tabelle 12-4
Befehle für den sendmail-Testmodus 
Befehl
Benutzung
regelsatz [,regelsatz...] adresse
Verarbeitet die Adresse durch die Komma-separierte Liste mit Regelsätzen.
=Sregelsatz
Zeigt den Inhalt des Regelsatzes an.
=M
Zeigt alle Mailer-Definitionen an.
$v
Zeigt den Wert von Makro v an.
$=c
Zeigt die Werte in Klasse c an.
.Dvwert
Setzt das Makro v auf wert.
.Ccwert
Fügt wert zu Klasse c hinzu.
-dwert
Setzt den Debug-Level auf wert.
/tryflags flags
Setzt die Flags, die für die Adressverarbeitung durch /try benutzt werden.
/try mailer adresse
Verarbeitet die Adresse für den Mailer.
/parse adresse
Liefert das Mailer/Host/Benutzer-Auslieferungstriple für die Adresse zurück.
/canon hostname
Kanonisiert den hostnamen.
/mx hostname
Sucht die MX-Records für hostname.
/map mapname schlüssel
Sucht schlüssel in der Datenbank mapname.
/quit
Beendet den Adresstest-Modus.

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:

# /usr/sbin/sendmail -bt -Cvstout.cf
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> /parse issac
Cracked address = $g
Parsing envelope recipient address
canonify input: issac
Canonify2 input: issac
Canonify2 returns: issac
canonify returns: issac
parse input: issac
Parse0 input: issac
Parse0 returns: issac
ParseLocal input: issac
ParseLocal returns: issac
Parse1 input: issac
Parse1 returns: $# local $: issac
parse returns: $# local $: issac
2 input: issac
2 returns: issac
EnvToL input: issac
EnvToL returns: issac
final input: issac
final returns: issac
mailer local, user issac

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:

> /parse isaac@vstout.vbrew.com
Cracked address = $g
Parsing envelope recipient address
canonify input: isaac @ vstout . vbrew . com
Canonify2 input: isaac < @ vstout . vbrew . com >
Canonify2 returns: isaac < @ vstout . vbrew . com . >
canonify returns: isaac < @ vstout . vbrew . com . >
parse input: isaac < @ vstout . vbrew . com . >
Parse0 input: isaac < @ vstout . vbrew . com . >
Parse0 returns: isaac < @ vstout . vbrew . com . >
ParseLocal input: isaac < @ vstout . vbrew . com . >
ParseLocal returns: isaac < @ vstout . vbrew . com . >
Parse1 input: isaac < @ vstout . vbrew . com . >
Parse1 returns: $# local $: isaac
parse returns: $# local $: isaac
2 input: isaac
2 returns: isaac
EnvToL input: isaac
EnvToL returns: isaac
final input: isaac
final returns: isaac
mailer local, user isaac

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:

> /parse issac@vale.vbrew.com
Cracked address = $g
Parsing envelope recipient address
canonify input: issac @ vale . vbrew . com
Canonify2 input: issac < @ vale . vbrew . com >
Canonify2 returns: issac < @ vale . vbrew . com . >
canonify returns: issac < @ vale . vbrew . com . >
parse input: issac < @ vale . vbrew . com . >
Parse0 input: issac < @ vale . vbrew . com . >
Parse0 returns: issac < @ vale . vbrew . com . >
ParseLocal input: issac < @ vale . vbrew . com . >
ParseLocal returns: issac < @ vale . vbrew . com . >
Parse1 input: issac < @ vale . vbrew . com . >
MailerToTriple input: < > issac < @ vale . vbrew . com . >
MailerToTriple returns: issac < @ vale . vbrew . com . >
Parse1 returns: $# esmtp $@ vale . vbrew . com . $: issac < @ vale . vbrew . com . >
parse returns: $# esmtp $@ vale . vbrew . com . $: issac < @ vale . vbrew . com . >
2 input: issac < @ vale . vbrew . com . >
2 returns: issac < @ vale . vbrew . com . >
EnvToSMTP input: issac < @ vale . vbrew . com . >
PseudoToReal input: issac < @ vale . vbrew . com . >
PseudoToReal returns: issac < @ vale . vbrew . com . >
MasqSMTP input: issac < @ vale . vbrew . com . >
MasqSMTP returns: issac < @ vale . vbrew . com . >
EnvToSMTP returns: issac < @ vale . vbrew . com . >
final input: issac < @ vale . vbrew . com . >
final returns: issac @ vale . vbrew . com
mailer esmtp, host vale.vbrew.com., user issac@vale.vbrew.com

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:

# sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> /tryflags HS
> /try esmtp alana@vpils.vbrew.com
Trying header sender address alana@vpils.vbrew.com for mailer esmtp
canonify input: alana @ vpils . vbrew . com
Canonify2 input: alana < @ vpils . vbrew . com >
Canonify2 returns: alana < @ vpils . vbrew . com . >
canonify returns: alana < @ vpils . vbrew . com . >
1 input: alana < @ vpils . vbrew . com . >
1 returns: alana < @ vpils . vbrew . com . >
HdrFromSMTP input: alana < @ vpils . vbrew . com . >
PseudoToReal input: alana < @ vpils . vbrew . com . >
PseudoToReal returns: alana < @ vpils . vbrew . com . >
MasqSMTP input: alana < @ vpils . vbrew . com . >
MasqSMTP returns: alana < @ vpils . vbrew . com . >
MasqHdr input: alana < @ vpils . vbrew . com . >
canonify input: alana . darling @ vbrew . com
Canonify2 input: alana . darling < @ vbrew . com >
Canonify2 returns: alana . darling < @ vbrew . com . >
canonify returns: alana . darling < @ vbrew . com . >
MasqHdr returns: alana . darling < @ vbrew . com . >
HdrFromSMTP returns: alana . darling < @ vbrew . com . >
final input: alana . darling < @ vbrew . com . >
final returns: alana . darling @ vbrew . com
Rcode = 0, addr = alana.darling@vbrew.com
> /try esmtp alana@vale.vbrew.com
Trying header sender address alana@vale.vbrew.com for mailer esmtp
canonify input: alana @ vale . vbrew . com
Canonify2 input: alana < @ vale . vbrew . com >
Canonify2 returns: alana < @ vale . vbrew . com . >
canonify returns: alana < @ vale . vbrew . com . >
1 input: alana < @ vale . vbrew . com . >
1 returns: alana < @ vale . vbrew . com . >
HdrFromSMTP input: alana < @ vale . vbrew . com . >
PseudoToReal input: alana < @ vale . vbrew . com . >
PseudoToReal returns: alana < @ vale . vbrew . com . >
MasqSMTP input: alana < @ vale . vbrew . com . >
MasqSMTP returns: alana < @ vale . vbrew . com . >
MasqHdr input: alana < @ vale . vbrew . com . >
canonify input: alana . henson @ vbrew . com
Canonify2 input: alana . henson < @ vbrew . com >
Canonify2 returns: alana . henson < @ vbrew . com . >
canonify returns: alana . henson < @ vbrew . com . >
MasqHdr returns: alana . henson < @ vbrew . com . >
HdrFromSMTP returns: alana . henson < @ vbrew . com . >
final input: alana . henson < @ vbrew . com . >
final returns: alana . henson @ vbrew . com
Rcode = 0, addr = alana.henson@vbrew.com
> /try esmtp alana@foobar.vbrew.com
Trying header sender address alana@foobar.vbrew.com for mailer esmtp
canonify input: alana @ foobar . vbrew . com
Canonify2 input: alana < @ foobar . vbrew . com >
Canonify2 returns: alana < @ foobar . vbrew . com . >
canonify returns: alana < @ foobar . vbrew . com . >
1 input: alana < @ foobar . vbrew . com . >
1 returns: alana < @ foobar . vbrew . com . >
HdrFromSMTP input: alana < @ foobar . vbrew . com . >
PseudoToReal input: alana < @ foobar . vbrew . com . >
PseudoToReal returns: alana < @ foobar . vbrew . com . >
MasqSMTP input: alana < @ foobar . vbrew . com . >
MasqSMTP returns: alana < @ foobar . vbrew . com . >
MasqHdr input: alana < @ foobar . vbrew . com . >
canonify input: alana . smiley @ vbrew . com
Canonify2 input: alana . smiley < @ vbrew . com >
Canonify2 returns: alana . smiley < @ vbrew . com . >
canonify returns: alana . smiley < @ vbrew . com . >
MasqHdr returns: alana . smiley < @ vbrew . com . >
HdrFromSMTP returns: alana . smiley < @ vbrew . com . >
final input: alana . smiley < @ vbrew . com . >
final returns: alana . smiley @ vbrew . com
Rcode = 0, addr = alana.smiley@vbrew.com
> /quit

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.

sendmail ausführen

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:

/usr/sbin/sendmail -bd -q10m

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:

smtp stream tcp nowait nobody /usr/sbin/sendmail -bs

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:

# Verarbeitet alle fünfzehn Minuten den Mail-Spool
0,15,30,45 * * * * /usr/bin/runq

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:

# sendmail -q

Tipps und Tricks

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.

Verwalten des Mail-Spools

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:

# sendmail -bp

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:

$ mailq
Mail Queue (1 request)
--Q-ID-- --Size-- -----Q-Time----- ------------Sender/Recipient------------
RAA00275 124 Wed Dec 9 17:47 root
(host map: lookup (tao.linux.org.au): deferred)
terry@tao.linux.org.au

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.

Einen entfernten Host zwingen, seine Mail-Warteschlange zu verarbeiten

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:

# etrn vstout.vbrew.com

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.

Mail-Statistiken

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.

mailstats

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.

Tabelle 12-5
Die von mailstats angezeigten Felder 
Feld
Bedeutung
M
Die Mailer-(Transportprotokoll-)Nummer
msgsfr
Die Anzahl der Nachrichten, die von dem Mailer empfangen wurden
bytes_from
Mail von dem Mailer in Kbytes
msgsto
Anzahl der Nachrichten, die an den Mailer gesendet wurden
bytes_to
Mail in Kbytes, die an den Mailer gesendet wurden
msgsreg
Die Anzahl der abgewiesenen Nachrichten
msgsdis
Die Anzahl der verworfenen Nachrichten
Mailer
Der Name des Mailers

Die Ausgabe des Befehls mailstats könnte so aussehen wie in Beispiel 12-7.

Beispiel 12-7
Beispielausgabe des mailstats-Befehls 
# /usr/sbin/mailstats
Statistics from Sun Dec 20 22:47:02 1998
M msgsfr bytes_from msgsto bytes_to msgsrej msgsdis Mailer
0 0 0K 19 515K 0 0 prog
3 33 545K 0 0K 0 0 local
5 88 972K 139 1018K 0 0 esmtp
=  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
T 121 1517K 158 1533K 0 0

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:

$ grep StatusFile vstout.cf
O StatusFile=/etc/mail/statistics

Um die Sammlung der Statistikdaten erneut zu beginnen, setzen Sie die Länge der Statistikdatei auf null und starten sendmail neu.

hoststat

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:

sendmail -bh

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.

Beispiel 12-8
Beispielausgabe des Befehls hoststat 
# hoststat
-------------- Hostname ---------- How long ago ---------Results---------
mail.telstra.com.au 04:05:41 250 Message accepted for
scooter.eye-net.com.au 81+08:32:42 250 OK id=0zTGai-0008S9-0
yarrina.connect.com.a 53+10:46:03 250 LAA09163 Message acce
happy.optus.com.au 55+03:34:40 250 Mail accepted
mail.zip.com.au 04:05:33 250 RAA23904 Message acce
kwanon.research.canon.com.au 44+04:39:10 250 ok 911542267 qp 21186
linux.org.au 83+10:04:11 250 IAA31139 Message acce
albert.aapra.org.au 00:00:12 250 VAA21968 Message acce
field.medicine.adelaide.edu.au 53+10:46:03 250 ok 910742814 qp 721
copper.fuller.net 65+12:38:00 250 OAA14470 Message acce
amsat.org 5+06:49:21 250 UAA07526 Message acce
mail.acm.org 53+10:46:17 250 TAA25012 Message acce
extmail.bigpond.com 11+04:06:20 250 ok
earthlink.net 45+05:41:09 Deferred: Connection time

Der Befehl purgestat löscht die gesammelten Host-Daten und ist äquivalent zu einem Aufruf von sendmail als:

# sendmail -bH

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.

Weitere Informationen

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.

Die sendmail-Distribution wird mit einigen ausgezeichneten README-Dateien geliefert. Sie beginnen mit der README im obersten Verzeichnis, das bei der Installation der Distribution angelegt wird. Das Verzeichnis enthält eine Reihe weiterer informativer Dateien, wie etwa sendmail/README und cf/README. (Die Datei cf/README, in der die sendmail-Konfigurationsbefehle erläutert werden, steht auch im Web unter http://www.sendmail.org/m4/readme.html zur Verfügung.)
Der sendmail Installation and Operations Guide ist eine ausgezeichnete Informationsquelle. Er wird ebenfalls mit der sendmail-Quellcode-Distribution geliefert und kann in doc/op/op.me oder doc/op/op.ps gefunden werden, je nachdem, welches Format Sie bevorzugen.
Die sendmail-Website bietet einige sehr gute Artikel und Online-Dokumente. Die Dokumentation Compiling Sendmail, erhältlich unter http://www.sendmail.org/compiling.html, stellt ein hervorragendes Beispiel dar.
Auf der sendmail-Site finden Sie eine Liste der verfügbaren sendmail-Bücher unter http://www.sendmail.org/books.html.
Es gibt auch ein formales sendmail-Training. Schauen Sie unter http://www.sendmail.org/classes.html nach.

Mit Hilfe dieser Quellen sollten Sie in der Lage sein, mehr über sendmail zu erfahren, als Sie jemals wissen müssen. Auf geht's!

1Sie müssen die PGPKEYS-Datei nur etwa einmal im Jahr herunterladen und importieren.
2Beachten Sie, dass m4 asymmetrische einfache Anführungszeichen benutzt, d. h. `'.
3Die linke und die rechte Seite können nur durch Tabulatoren getrennt werden.
4Siehe die Datei cf/README für weitere Informationen über diese sendmail.cf-Makros. Im Sendmail Installation and Operations Guide, der in der Datei doc/op.ps zu finden ist, gibt es eine vollständige Liste aller sendmail.cf-Makros.
5Die aliases-Datenbank wird weiter hinten in diesem Kapitel behandelt.
6Das Format vorname.nachname@domain wird nicht überall unterstützt. In der sendmail-FAQ finden Sie einige Gründe, weshalb dieses Adressformat unter Umständen nicht eingesetzt werden sollte.

TOC PREV NEXT INDEX


O'Reilly Home | O'Reilly-Partnerbuchhandlungen | Bestellinformationen
Kontakt | Über O'Reilly | Datenschutz

© 2005, O'Reilly Verlag GmbH & Co. KG