Copyright © 1996 by O'Reilly/International Thomson Verlag

Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen.

Wünschen Sie mehr Informationen zu der gedruckten Version des Buches "Linux: Wegweiser durch das Netzwerk" dann klicken Sie hier.


Kapitel 15
Sendmail+IDA

Eine Einführung in Sendmail+IDA

Es wird behauptet, daß man kein echter UNIX-Systemadministrator sei, solange man noch keine sendmail.cf-Datei editiert hat. Es wird auch behauptet, daß man verrückt sei, wenn man es ein zweites Mal tut.

sendmail ist ein unglaublich mächtiges Programm. Für die meisten Leute ist es aber auch unglaublich schwer zu erlernen und zu verstehen. Jedes Programm, dessen definitive Referenz 792 Seiten lang ist, schreckt die meisten Leute zu Recht ab. Sendmail+IDA ist anders. Es befreit Sie davon, die ewig kryptische sendmail.cf-Datei bearbeiten zu müssen, und erlaubt es dem Administrator, die Site-spezifische Routing- und Adreß-Konfiguration über relativ einfache Support-Dateien, sogenannte »Tabellen« (tables), zu erledigen. Ein Wechsel zu Sendmail+IDA kann Ihnen viele Stunden Arbeit und Streß ersparen.

Verglichen mit den anderen großen Mail-Transport-Agents gibt es nichts, was mit Sendmail+IDA nicht schneller und einfacher erledigt werden könnte. Typische Aufgaben, die auf einer normalen UUCP- oder Internet-Site anfallen, sind einfach zu lösen. Normalerweise nur sehr schwer durchzuführende Konfigurationen sind einfach zu erzeugen und zu verwalten.

Während dieses Buch entsteht, ist die aktuelle Version, sendmail5.67b+ IDA1.5, über FTP bei vixen.cso.uiuc.edu zu beziehen. Unter Linux kann das Programm ohne jegliche Anpassungen kompiliert werden.

Alle Konfigurations-Dateien, die benötigt werden, um die Sendmail+IDA-Quellen zu kompilieren, zu installieren und unter Linux zum Laufen zu bringen, sind in newspak-2.2.tar.gz enthalten, das Sie über FTP von sunsite.unc.edu aus dem Verzeichnis /pub/Linux/system/Mail herunterladen können.

Übersicht der Konfigurations-Dateien

Das Setup von sendmail erfolgt traditionell durch eine System-Konfigurationsdatei (typischerweise /etc/sendmail.cf oder /usr/lib/sendmail.cf, die an keine Sprache erinnert, die Sie bisher kennengelernt haben. Das Editieren von sendmail.cf zur Anpassung des Verhaltens kann eine demütigende Erfahrung sein.

Dank Sendmail+IDA gehören diese Qualen aber der Vergangenheit an, weil alle Konfigurations-Optionen über Tabellen gesteuert werden, die eine ziemlich einfach zu verstehende Syntax verwenden. Diese Optionen werden konfiguriert, indem m4 (ein Makroprozessor) oder dbm (ein Datenbankprozessor) über Make-Files auf eine Reihe von Datendateien angewandt werden, die den Quellen beiliegen.

Die Datei sendmail.cf definiert nur das Standardverhalten des Systems. Nahezu jede spezielle Anpassung wird über eine Reihe optionaler Tabellen durchgeführt. sendmail.cf selbst muß dazu nicht editiert werden. Die nachfolgende Liste beschreibt die sendmail-Tabellen:

mailertable
Definiert spezielle Verhaltensweisen für andere Hosts oder Domains.

uucpxtable
Erzwingt die UUCP-Auslieferung von Nachrichten an Hosts, die das DNS-Format verwenden.

pathtable
Definiert UUCP-Bang-Pfade zu anderen Hosts und Domains.

uucprelays
Kürzt den pathalias-Pfad für wohlbekannte entfernte Hosts ab.

genericfrom
Wandelt interne in generische Adressen um, die für die Außenwelt sichtbar sind.

xaliases
Wandelt generische Adressen in/von gültige(n) interne(n) um.

decnetxtable
Wandelt RFC-822-Adressen in DECnet-Adressen um.

Die Datei sendmail.cf

sendmail.cf wird für Sendmail+IDA nicht direkt bearbeitet, sondern durch eine m4-Konfigurations-Datei erzeugt, die vom lokalen Systemadministrator bereitgestellt wird. Diese Datei bezeichnen wir nachfolgend als sendmail.m4.

Die Datei enthält einige Definitionen und zeigt ansonsten nur auf die Tabellen, wo die eigentliche Arbeit erledigt wird. Im allgemeinen müssen die folgenden Informationen spezifiziert werden:

Eine Reihe von Parametern kann definiert werden, mit denen das Verhalten des lokalen Servers bestimmt wird oder vorkompilierte Konfigurations-Optionen überschrieben werden können. Die Konfigurations-Optionen sind in der Datei ida/cf/OPTIONS im Source-Verzeichnis zu finden.

Eine sendmail.m4-Datei für eine Minimalkonfiguration (UUCP oder SMTP, wobei alle nichtlokalen Mails an einen direkt verbundenen Smart Host weitergeleitet werden) kann aus nur 10 bis 15 Befehlen (ohne Kommentarzeilen) bestehen.

Eine sendmail.m4-Beispieldatei

Eine sendmail.m4-Datei für vstout in der virtuellen Brauerei ist in Beispiel 15--1 zu sehen. vstout verwendet SMTP zur Kommunikation mit allen Hosts im Brauerei-LAN und sendet alle Mails für andere Zielorte über UCCP an moria, seinen Internet-Verteilerhost.

Tatsächlich nennen die meisten Leute ihre Konfigurations-Datei nicht sendmail.m4, sondern benennen sie nach dem Host, in unserem Beispiel also vstout.m4. Der Name spielt aber keine Rolle, solange die Ausgabedatei sendmail.cf genannt wird.

Beispiel 15-1. vstout.m4-Konfigurations-Datei (Beispiel)

dnl #------------------ SENDMAIL.M4-BEISPIELDATEI------------------
dnl # (der String 'dnl' ist das m4-Equivalent für das Auskommentieren einer Zeile)
dnl # im allgemeinen wird LIBDIR aus den vorkompilierten Pfaden nicht überschrieben
dnl #define(LIBDIR,/usr/local/lib/mail)dnl    # hier sind alle Support-Dateien zu finden
define(LOCAL_MAILER_DEF, mailers.linux)dnl    # Mailer für lokale Auslieferung
define(POSTMASTERBOUNCE)dnl                   # postmaster bekommt gebouncte Nachrichten
define(PSEUDODOMAINS, BITNET UUCP)dnl         # DNS nicht auf diese anwenden
dnl #-------------------------------------------------------------
dnl #
define(PSEUDONYMS, vstout.vbrew.com  vstout.UUCP vbrew.com)
dnl                                           # Namen, unter denen wir bekannt sind
define(DEFAULT_HOST, vstout.vbrew.com)dnl     # unser primärer 'Name' für Mail
define(UUCPNAME, vstout)dnl                   # unser UUCP-Name
dnl #
dnl #-------------------------------------------------------------
dnl #
define(UUCPNODES, |uuname|sort|uniq)dnl       # unsere UUCP-Nachbarn
define(BANGIMPLIESUUCP)dnl                    # sicherstellen, daß UUCP-Mail
define(BANGONLYUUCP)dnl                       #  korrekt gehandhabt wird
define(RELAY_HOST, moria)dnl                  # unser smarter Verteilerhost
define(RELAY_MAILER, UUCP-A)dnl               # moria wird über UUCP erreicht
dnl #
dnl #--------------------------------------------------------------------
dnl #
dnl # Verschiedene dbm-Suchtabellen
dnl #
define(ALIASES, LIBDIR/aliases)dnl            # System-Aliases
define(DOMAINTABLE, LIBDIR/domaintable)dnl    # Hosts Domains zuordnen
define(PATHTABLE, LIBDIR/pathtable)dnl        # Pfad-Datenbank
define(GENERICFROM, LIBDIR/generics)dnl       # Interne in generische Adressen
define(MAILERTABLE, LIBDIR/mailertable)dnl    # Mailer je Host oder Domain
define(UUCPXTABLE, LIBDIR/uucpxtable)dnl      # Pfade zu von uns versorgten Hosts
define(UUCPRELAYS, LIBDIR/uucprelays)dnl      # Kurze Pfade für bekannte Hosts
dnl #
dnl #--------------------------------------------------------------------
dnl #
dnl # füge hier den "echten" Kode ein, der alles zum Laufen bringt
dnl # (ist im Source-Kode enthalten)
dnl #
include(Sendmail.mc)dnl                         # BENÖTIGTER EINTRAG!!!
dnl #
dnl #------------ ENDE DER SENDMAIL.M4-BEISPIELDATEI -------

Anwendungsspezifische sendmail.m4-Parameter

Einige Punkte in der Datei sendmail.m4 werden die ganze Zeit über benötigt, während andere ignoriert werden können, wenn Ihnen die Standardeinstellungen genügen. Die folgenden Abschnitte behandeln detailliert jeden der Punkte aus der sendmail.m4-Datei aus Beispiel 15--1.

Punkte, die Pfade definieren

dnl #define(LIBDIR,/usr/local/lib/mail)dnl  # hier sind alle Support-Dateien 
                                            # zu finden
LIBDIR definiert das Verzeichnis, in dem Sendmail+IDA alle Konfigurations-Dateien, die verschiedenen dbm-Tabellen und spezielle lokale Definitionen erwartet. Bei einer typischen Binär-Distribution ist dieser Pfad bereits in die sendmail-Binary kompiliert und muß in sendmail.m4 nicht explizit gesetzt werden.

Die obige Zeile beginnt mit dnl, was bedeutet, daß es sich bei der Zeile um einen Kommentar handelt.

Sollen die Support-Dateien an einer anderen Stelle gespeichert werden, müssen Sie das führende dnl aus der obigen Zeile entfernen, den gewünschten Pfad eintragen und sendmail.cf neu erzeugen und installieren.

Definieren des lokalen Mailers

define(LOCAL_MAILER_DEF, mailers.linux)dnl  # Mailer für lokale Auslieferung
Die meisten Betriebssysteme bieten ein Programm an, das die Auslieferung lokaler Mails übernimmt. Typische Programme für viele der Hauptvarianten von UNIX sind bereits in das sendmail-Binary integriert.

Unter Linux muß der lokale Mailer explizit definiert werden, weil ein Programm zur lokalen Auslieferung nicht zwangsläufig in Ihrer Distribution vorhanden sein muß. Dies wird durch die Spezifizierung von LOCAL_MAILER_DEF in sendmail.m4 erreicht.

Um diesen Service beispielsweise durch das häufig verwendete Programm deliver ausführen zu lassen, würden Sie LOCAL_MAILER_DEF auf mailers.linux setzen.(1)

Die folgende Datei sollte dann als mailers.linux in dem unter LIBDIR angegebenen Verzeichnis installiert werden. Hier wird deliver explizit als lokaler Mailer in Mlocal definiert, wobei gleichzeitig die richtigen Parameter eingetragen werden, so daß sendmail alle Nachrichten korrekt ausliefern kann, die für das lokale System bestimmt sind. Solange Sie kein sendmail-Experte sind, sollten Sie das folgende Beispiel nicht verändern.

# -- /usr/local/lib/mail/mailers.linux --
#     (Lokale Mailer für Linux )
Mlocal, P=/usr/bin/deliver, F=SlsmFDMP, S=10, R=25/10, A=deliver $u
Mprog,  P=/bin/sh,       F=lsDFMeuP,   S=10, R=10, A=sh -c $u
Es gibt auch einen eingebauten Standardwert für deliver in der Datei Sendmail.mc, die in sendmail.cf eingefügt wird. Soll dieser verwendet werden, würden Sie nicht die Datei mailers.linux verwenden, sondern würden folgende Zeilen in Ihre sendmail.m4 eintragen:
dnl  --  (in sendmail.m4)  -
define(LOCAL_MAILER_DEF, DELIVER)dnl       # Mailer für lokale Auslieferung
Unglücklicherweise setzt Sendmail.mc voraus, daß deliver in /bin installiert ist. Das ist bei Slackware1.1.1 nicht der Fall (hier wird es in /usr/bin installiert). In diesem Fall müßten Sie entweder einen entsprechenden Link einrichten, oder deliver erneut aus den Quellen erzeugen, so daß es dann in /bin zu finden ist.

Mit gebouncter Mail umgehen

define(POSTMASTERBOUNCE)dnl        # postmaster bekommt gebouncte Nachrichten
Für viele Sites ist es wichtig, sicherzustellen, daß Nachrichten mit nahezu 100prozentiger Sicherheit verschickt und empfangen werden. Obwohl es hilfreich ist, die syslogd-Logs zu untersuchen, muß sich der Mail-Administrator auch die Header der nicht zugestellten Nachrichten ansehen, um erkennen zu können, ob es sich um einen Fehler des Benutzers oder um einen Konfigurations-Fehler bei einem der beteiligten Systeme handelt.

Durch Definition von POSTMASTERBOUNCE wird eine Kopie jeder nicht zustellbaren Nachricht an die Person geschickt, die für dieses System als Postmaster definiert wurde.

Leider wird durch Einstellen dieses Parameters auch der Inhalt der Nachricht mit an den Postmaster übertragen, was möglicherweise Fragen über die Privatsphäre Ihrer Benutzer aufwirft.

Postmaster sollten sich grundsätzlich dazu anhalten, die Post fremder Leute nicht zu lesen (oder die technischen Möglichkeiten wie Shell-Scripten ausschöpfen und den Text von nicht ausgelieferten Nachrichten abschneiden).

DNS-bezogene Punkte

define(PSEUDODOMAINS, BITNET UUCP)dnl       # DNS nicht auf diesen anwenden
Es gibt verschiedene wohlbekannte Netzwerke, die in Mail-Adressen aus historischen Gründen immer wieder adressiert werden, die aber für DNS nicht gültig sind. Durch die Definition von PSEUDODOMAINS verhindern Sie sinnlose DNS-Lookups, die immer fehlschlagen würden.

Definition lokaler Systemnamen

define(PSEUDONYMS, vstout.vbrew.com  vstout.UUCP vbrew.com)
dnl                                        # Namen, unter denen wir bekannt sind
define(DEFAULT_HOST, vstout.vbrew.com)dnl  # unser primärer 'Name' für Mail
Häufig möchten Systeme ihre wahre Identität verbergen, als Mail-Gateways dienen oder Nachrichten empfangen und verarbeiten, die an »alte« Namen adressiert sind.

PSEUDONYMS spezifiziert eine Liste von Hostnamen, für die das lokale System Nachrichten akzeptiert.

DEFAULT_HOST spezifiziert den Hostnamen, der in Nachrichten erscheint, die vom lokalen Host verschickt wurden. Es ist wichtig, daß dieser Parameter auf einen gültigen Wert eingestellt wird, weil sonst keine zurückkommende Mail ausgeliefert werden könnte.

UUCP-bezogene Punkte

define(UUCPNAME, vstout)dnl                   # unser UUCP-Name
define(UUCPNODES, |uuname|sort|uniq)dnl       # unsere UUCP-Nachbarn
define(BANGIMPLIESUUCP)dnl                    # sicherstellen, daß UUCP-Mail
define(BANGONLYUUCP)dnl                       #  korrekt gehandhabt wird
Häufig sind Systeme für DNS-Zwecke unter dem einen und für UUCP-Zwecke unter einem anderen Namen bekannt. Mit UUCPNAME können Sie einen anderen Hostnamen definieren, der in den Headern aller ausgehenden UUCP-Mails erscheint.

UUCPNODES definiert die Befehle, die eine Liste der Hostnamen aller Systeme zurückliefern, mit denen Sie direkt über UUCP verbunden sind.

BANGIMPLIESUUCP und BANGONLYUUCP stellen sicher, daß Nachrichten, die in UUCP-Bang-Syntax adressiert wurden, entsprechend den UUCP-Richtlinien behandelt werden und nicht entsprechend den heute im Internet verwendeten DNS-Richtlinien.

Verteilerstationen und Mailer

define(RELAY_HOST, moria)dnl                  # unser smarter Verteilerhost
define(RELAY_MAILER, UUCP-A)dnl               # moria wird über UUCP erreicht
Viele Systemadministratoren wollen mit der ganzen Arbeit nicht belästigt werden, die notwendig ist, um sicherzustellen, daß ihr System alle Netzwerke und Systeme in allen Netzwerken weltweit erreichen kann. Statt dessen leiten sie alle Nachrichten an ein anderes System weiter, das als »smart« bekannt ist.

RELAY_HOST definiert den UUCP-Hostnamen eines solchen benachbarten smarten Systems.

RELAY_MAILER definiert, welcher Mailer bei der Weiterleitung an dieses System zu verwenden ist.

Es ist wichtig zu bedenken, daß ein Einstellen dieses Parameters bewirkt, daß alle ausgehenden Mails an dieses andere System weitergeleitet werden, was diesen Rechner unter Umständen erheblich belastet. Holen Sie sich also zuerst das Einverständnis des Postmasters des entfernten Host ein, bevor Sie Ihr System so konfigurieren, daß dieser als allgemeiner Vermittlungshost benutzt wird.

Konfigurations-Tabellen

define(ALIASES, LIBDIR/aliases)dnl           # System-Aliases
define(DOMAINTABLE, LIBDIR/domaintable)dnl   # Hosts Domains zuordnen
define(PATHTABLE, LIBDIR/pathtable)dnl       # Pfad-Datenbank
define(GENERICFROM, LIBDIR/generics)dnl      # interne in generische Adressen
define(MAILERTABLE, LIBDIR/mailertable)dnl   # Mailer je Host oder Domain
define(UUCPXTABLE, LIBDIR/uucpxtable)dnl     # Pfade zu von uns versorgten Hosts
define(UUCPRELAYS, LIBDIR/uucprelays)dnl     # kurze Pfade für bekannte Hosts
Mit diesen Makros können Sie die Orte verändern, an denen Sendmail+IDA die verschiedenen dbm-Tabellen sucht, die das »wirkliche« Verhalten des Systems bestimmen. Es ist grundsätzlich eine weise Entscheidung, sie in LIBDIR zu belassen.

Die Hauptdatei Sendmail.mc

include(Sendmail.mc)dnl                         # BENÖTIGTER EINTRAG!!!
Die Autoren von Sendmail+IDA liefern die Datei Sendmail.mc mit, die die wirklich wichtigen Teile enthält, aus denen dann sendmail.cf erzeugt wird. Regelmäßig werden neue Versionen veröffentlicht, in denen Fehler behoben oder in die zusätzliche Funktionen aufgenommen wurden, ohne daß gleich eine völlig neue Release und eine Neukompilierung der sendmail-Quellen vonnöten wäre. Es ist wichtig, daß Sie die Datei nicht editieren.

Welche Einträge werden denn nun wirklich benötigt?

Wird keine der optionalen dbm-Tabellen verwendet, liefert Sendmail+IDA Mail über DEFAULT_MAILER (und eventuell über RELAY_HOST und RELAY_MAILER) aus, der in sendmail.m4 definiert ist, und aus dem die eigentliche sendmail.cf generiert wird. Sie können dieses Verhalten einfach verändern, indem Sie entsprechende Einträge in domaintable oder uucpxtable vornehmen.

Eine typische Internet-Site, die DNS versteht, oder eine reine UUCP-Site, die alle Nachrichten über UUCP an einen smarten RELAY_HOST weiterleitet, benötigt wahrscheinlich überhaupt keine spezifischen Tabelleneinträge.

Nahezu jedes System sollte aber die DEFAULT_HOST- und PSEUDONYMS-Makros setzen, die den kanonischen Sitenamen und eventuelle Aliases definieren, unter denen es bekannt ist. Auch DEFAULT_MAILER sollte definiert sein. Wenn Sie nur einen Verteilerhost und -mailer betreiben, brauchen Sie diese Standardwerte nicht einzustellen, weil dies automatisch geschieht.

Bei UUCP-Hosts muß wahrscheinlich UUCPNAME auf den offiziellen UUCP-Namen gesetzt werden. Möglicherweise müssen auch RELAY_MAILER und RELAY_HOST eingestellt werden, mit denen das Smart Host-Routing über einen Mail-Verteiler aktiviert wird. Die für Mails zu verwendende Transportart wird in RELAY_MAILER definiert und sollte bei UUCP-Sites normalerweise UUCP-A enthalten.

Wenn Ihre Site ausschließlich SMTP verwendet und DNS spricht, müssen Sie DEFAULT_MAILER auf TCP-A einstellen und wahrscheinlich die Zeilen RELAY_MAILER und RELAY_HOST entfernen.

Die Sendmail+IDA-Tabellen

Sendmail+IDA besitzt eine Reihe von Tabellen, mit denen Sie die Standardarbeitsweise von sendmail (wie in sendmail.m4 spezifiziert) überschreiben können. Gleichzeitig können Sie spezielle Verhaltensweisen für einzigartige Situationen, andere Systeme und Netzwerke festlegen. Diese Tabellen werden mit dbm über ein Makefile nachgearbeitet, das mit der Distribution geliefert wird.

Die meisten Sites benötigen, wenn überhaupt, nur wenige dieser Tabellen. Wenn Ihre Site diese Tabellen nicht braucht, besteht die einfachste Möglichkeit darin, die Länge der Dateien auf Null Byte zu bringen (mit dem Befehl touch), und in LIBDIR das Standard-Makefile zu verwenden, anstatt das Makefile selbst zu editieren.

mailertable

mailertable definiert die spezielle Behandlung von spezifischen Hosts oder Domains, basierend auf dem Namen des entfernten Host oder des Netzwerks. Sie wird häufig bei Internet-Sites verwendet, um einen Mail-Verteilerhost oder ein Gateway anzusprechen, über den/das ein entferntes Netzwerk erreicht werden soll. Außerdem wird bestimmt, welches Protokoll (UUCP oder SMTP) dabei verwendet werden soll. UUCP-Sites benötigen diese Datei nicht.

Die Reihenfolge ist wichtig. sendmail liest die Datei von oben nach unten und verarbeitet die Nachricht entsprechend dem ersten passenden Eintrag. Es ist daher sinnvoll, die exaktesten Einträge direkt am Anfang einzugeben und die allgemeineren Einträge gegen Ende.

Stellen Sie sich vor, daß Sie alle Nachrichten an das Institut für Informatik an der Groucho-Marx-Universität über UUCP an den Verteilerhost ada weiterleiten wollen. Dazu müssen Sie in mailertable einen Eintrag wie den folgenden aufnehmen:

# (in mailertable)
#
# alle Nachrichten für die Domain .cs.groucho.edu über UUCP an ada
UUCP-A,ada         .cs.groucho.edu
Stellen Sie sich nun vor, daß alle Nachrichten an die größere Domain groucho.edu an einen anderen Verteilerhost namens bighub gehen sollen, der die Auflösung der Adressen und die Auslieferung übernehmen soll. mailertable müßte dafür wie folgt erweitert werden:
# (in mailertable)
#
# alle Nachrichten für die Domain .cs.groucho.edu über UUCP an ada
UUCP-A,ada         .cs.groucho.edu
#
# alle Nachrichten für die Domain groucho.edu über UUCP an bighub
UUCP-A,bighub      .groucho.edu
Wie bereits erwähnt, ist die Reihenfolge wichtig. Würden Sie die Reihenfolge dieser beiden Regeln vertauschen, würden alle Nachrichten an .cs.groucho.edu über den allgemeineren bighub-Pfad laufen und nicht über den eigentlich gewünschten ada-Pfad.

In den obigen mailertable-Beispielen läßt der UUCP-A-Mailer sendmail über UUCP ausliefern, wobei im Mail-Header Domain-Namen/voll qualifizierte Host-Namen verwendet werden.

Das Komma zwischen dem Mailer und dem entfernten System teilt ihm mit, die Nachricht zur Adreßauflösung und Auslieferung an ada weiterzuleiten.

mailertable-Einträge haben das folgende Format:

Mailer Trennzeichen Vermittlungshost Host_oder_Domain
Es gibt eine ganze Reihe möglicher Mailer. Sie unterscheiden sich hauptsächlich in der Art, wie Adressen behandelt werden. Typische Mailer sind TCP-A (TCP/IP mit Internet-Adressen), TCP-U (TCP/IP mit UUCP-Adressen) und UUCP-A (UUCP mit Internet-Adressen).

Das Zeichen, das den Mailer vom Hostteil links in mailertable trennt, bestimmt, wie die Adresse von mailertable modifiziert wird:

!
Bei einem Ausrufezeichen wird der Hostname des Empfängers entfernt, bevor eine Weiterleitung an den Mailer erfolgt. Sie können dies verwenden, um die Auslieferung von Mail an eine fehlerhaft konfigurierte Site zu erzwingen.

,
Ein Komma verändert eine Adresse nicht. Die Nachricht wird einfach über den angegebenen Mailer an den angegebenen Verteilerhost weitergeleitet.

:
Bei einem Doppelpunkt wird der Hostname des Empfängers nur entfernt, wenn zwischen Ihnen und dem Zielhost noch weitere Hosts liegen. Das bedeutet also, daß foo aus foo!bar!joe entfernt wird, während xyzzy!janet unverändert bleibt.

Eine wichtige Sache ist, daß mailertable nur den Envelope neu schreibt (um die Nachricht auf das andere System zu bekommen). Andere Teile der Nachricht zu verändern, gilt als unfein, weil mit hoher Wahrscheinlichkeit die Mail-Konfiguration dabei zerbricht.

uucpxtable

Normalerweise werden Nachrichten an Hosts mit voll qualifiziertem Domainnamen über SMTP mittels DNS oder über den Verteilerhost ausgeliefert. uucpxtable erzwingt die Auslieferung über UUCP-Routing durch Umwandlung des mit der Domain versehenen Namens in den UUCP-typischen entfernten Hostnamen ohne Domain.

uucpxtable wird häufig beim Betrieb eines Mail-Forwarders für eine Site oder Domain eingesetzt, oder wenn ein direkter und zuverlässiger UUCP-Link anstelle des Standard-Mailers verwendet werden soll, um mehrere Sprünge (Hops) über dazwischenliegende Systeme und Netzwerke zu vermeiden.

UUCP-Sites, die mit UUCP-Nachbarn kommunizieren, bei denen Mailheader mit Domainnamen verwendet werden, würden diese Datei nutzen, um die Auslieferung der Nachrichten über die direkte UUCP-Punkt-zu-Punkt-Verbindung zwischen diesen beiden Systemen zu erzwingen, statt die weniger direkte Route über RELAY_MAILER und RELAY_HOST oder über DEFAULT_MAILER zu gehen.

Internet-Sites, die nicht über UUCP kommunizieren, werden uucpxtable wahrscheinlich nicht benutzen.

Stellen Sie sich vor, daß Sie das Mail-Forwarding für ein System bereitstellen, das unter DNS den Namen sesame.com besitzt und in den UUCP-Maps als sesame geführt wird. Sie müssen dann den folgenden Eintrag in Ihre uucpxtable aufnehmen, damit die Nachrichten für diesen Host über die direkte UUCP-Verbindung geleitet werden:

#============== /usr/local/lib/mail/uucpxtable ============
# Nachrichten an joe@sesame.com werden zu sesame!joe umgeschrieben
# und daher über UUCP ausgeliefert
#
sesame     sesame.com
#
#----------------------------------------------------------

pathtable

pathtable wird verwendet, um Routen zu entfernten Hosts oder Netzwerken explizit zu definieren. pathtable verwendet die gleiche Syntax wie pathalias und sollte alphabetisch sortiert sein. Die beiden in einer Zeile auftretenden Felder sollten durch einen echten Tabulator voneinander getrennt sein, da sich dbm ansonsten beschweren könnte.

Die meisten Systeme benötigen keine pathtable-Einträge.

#=============== /usr/local/lib/mail/pathtable ================
#
# dies ist eine Pfaddatei, die eine pathalias-Syntax verwendet und es
# Ihnen erlaubt, Nachrichten über den direkten UUCP-Pfad zu Ihren
# UUCP-Nachbarn zu transportieren, so daß diese Nachrichten nicht erst den
# langen Weg über Ihren Smart Host nehmen müssen.
#
# verwenden Sie echte Tabulatoren, sonst könnte sich m4 beschweren
#
# Mails werden über eine oder mehrere dazwischenliegende Sites an
# ein entferntes System geschickt; dabei wird UUCP-Adressierung verwendet
#
sesame!ernie!%s                          ernie
#  
# Weiterleitung zu einem System, das der UUCP-Nachbar einer erreichbaren
# Internet-Site ist
#
swim!%s                                    swim
#
# nachfolgend werden alle Nachrichten für zwei Netzwerke über zwei
# verschiedene Gateways verschickt (sehen Sie den führenden Punkt ?)
# in diesem Beispiel sind "uugate" und "byte" spezifische Systeme, die als
# Mail-Gateways für die Pseudo-Domains .UUCP bzw. .BITNET dienen
#
%@nngate.groucho.edu      .UUCP
byte!%s@mail.shift.com           .BITNET
#
#=================== ende von pathtable =======================

domaintable

Mit domaintable wird im allgemeinen ein bestimmtes Verhalten erzwungen, nachdem ein DNS-Lookup durchgeführt wurde. Diese Tabelle ermöglicht es dem Administrator, jeweils einen kurzen »Spitznamen« für häufig angesprochene Systeme oder Domains einzugeben, der automatisch in den eigentlichen Namen überführt wird. Sie können die Tabelle auch einsetzen, um falsche Host- oder Domainnamen durch die »richtigen« Informationen zu ersetzen.

Die meisten Sites benötigen keine domaintable-Einträge.

Das folgende Beispiel zeigt, wie eine inkorrekte Adresse, an die Leute Mail verschicken, durch die richtige Adresse ersetzt wird:

#============= /usr/local/lib/mail/domaintable =================
#
#
brokenhost.richtige.domain         brokenhost.falsche.domain
#
#
#=================== ende von domaintable ========================

aliases

Aliase bieten Ihnen eine ganze Reihe von Möglichkeiten:

Alle Systeme benötigen Aliase für Postmaster und MAILER-DAEMON, damit sie die Regeln der RFC erfüllen.

Achten Sie immer besonders dann auf die Sicherheit, wenn Sie ein Alias definieren, das ein Programm ausführt oder an ein Programm schreibt, weil sendmail immer mit Setuid root läuft.

Änderungen in aliases treten erst in Kraft, nachdem der Befehl

# /usr/lib/sendmail -bi
ausgeführt wurde, der die benötigten dbm-Tabellen erzeugt. Dies kann auch mit dem Befehl newaliases erledigt werden, üblicherweise aus cron heraus.

Details zu Mail-Aliases können Sie der aliases(5)-Manpage entnehmen. Eine beispielhafte aliases-Datei ist in Beispiel 15--2 zu sehen.

Beispiel 15-2. aliases-Beispieldatei

#--------------------- /usr/local/lib/mail/aliases ------------------
#
# demonstriert häufig verwendete Alias-Typen
#
usenet:         janet                     # Alias für eine Person
admin:          joe,janet                 # Alias für mehrere Personen
newspak-users:  :include:/usr/lib/lists/newspak
                                          # lese Empfänger aus einer Datei
changefeed:     | /usr/local/lib/gup      # Alias, das ein Programm ausführt
complaints:     /var/log/complaints       # Alias, das Nachricht in Datei 
schreibt
#
# die beiden folgenden Aliases müssen vorhanden sein, um RFC-konform zu sein
# es ist wichtig, daß bei der Auflösung eine Person herauskommt, die die Post
# regelmäßig liest
#
postmaster:     root                      # benötigter Eintrag
MAILER-DAEMON:  postmaster                # benötigter Eintrag
#
#-------------------------------------------------------------------

Selten benutzte Tabellen

Die folgenden Tabellen sind vorhanden, werden aber nur selten benutzt. Details können Sie der mit den Sendmail+IDA-Quellen ausgelieferten Dokumentation entnehmen.
uucprelays
Die Datei uucprelays wird verwendet, um den UUCP-Pfad zu besonders gut bekannten Sites abzukürzen. Auf diese Weise können Pfade mit mehreren Sprüngen bzw. unzuverlässige Pfade umgangen werden, die durch pathalias bei der Verarbeitung der UUCP-Maps erzeugt werden.

genericfrom und xaliases
Die Datei genericfrom versteckt lokale Benutzernamen und -Adressen vor der Außenwelt, indem lokale Benutzernamen automatisch in generische Absenderadressen umgewandelt werden, die keinem internen Benutzernamen entsprechen.

Das zugehörige xalparse-Utility automatisiert die Generierung der Dateien genericfrom und aliases, so daß die Übersetzung sowohl ein- als auch ausgehender Benutzernamen aus der Master-Datei xaliases erfolgt.

decnetxtable
Durch die Datei decnetxtable werden Adressen, die Domainnamen enthalten, in DECnet-Adressen umgewandelt. (Vergleichbar mit domaintable, die verwendet werden kann, um Adressen ohne Domainnamen in SMTP-Adressen umzuwandeln.)

sendmail installieren

In diesem Abschnitt werfen wir einen Blick auf die Installation einer typischen Binary-Distribution von Sendmail+IDA und gehen die Schritte durch, die zur Lokalisierung und ordnungsgemäßen Funktion notwendig sind.

Die aktuelle Binär-Distribution von Sendmail+IDA für Linux ist auf sunsite.unc.edu unter /pub/Linux/system/Mail zu finden. Selbst wenn Sie eine frühere Version von sendmail besitzen, möchte ich Ihnen wärmstens empfehlen, auf die Version sendmail5.67b+IDA1.5 zu wechseln, weil alle Linux-spezifischen Patches bereits in den Sourcen vorhanden sind. Außerdem wurden verschiedene Sicherheitslöcher gestopft, die noch in den Versionen bis zum 1. Dezember 1993 vorhanden waren.

Wenn Sie sendmail aus den Sourcen erzeugen, sollten Sie den Anweisungen in den READMEs folgen, die in der Quell-Distribution enthalten sind. Der aktuelle Quellkode zu Sendmail+IDA ist auf vixen.cso.uiuc.edu zu finden. Um Sendmail+IDA unter Linux zum Laufen zu bringen, benötigen Sie auch die Linux-spezifischen Konfigurations-Dateien aus newspak-2.2.tar.gz, die auf sunsite.unc.edu im Verzeichnis/pub/Linux/system/Mail zu finden sind.

Wenn Sie bereits smail oder ein anderes Mailsystem installiert haben, sollten Sie die entsprechenden Dateien löschen (oder umbenennen), um ganz sicher zu gehen.

Auspacken der binären Distribution

Zuerst müssen Sie die Archiv-Datei an einer sicheren Stelle entpacken:
$ gunzip -c sendmail5.65b+IDA1.5+mailx5.3b.tgz | tar xvf -
Wenn Sie eine »moderne« tar-Version (z. B. aus einer neuen Slackware-Distribution) besitzen, können Sie auch einfach tar -zxvf dateiname.tgz eingeben und erzielen dasselbe Ergebnis.

Durch Entpacken des Archivs wird das Verzeichnis sendmail5.65b+IDA1.5+ mailx5.3b erzeugt. In diesem Verzeichnis finden Sie eine komplette Installation von Sendmail+IDA sowie eine Binary des mailx-Agenten. Alle Dateipfade unter diesem Verzeichnis spiegeln die Orte wieder, an denen die Dateien installiert sein sollten. Sie gehen also auf Nummer Sicher, wenn Sie die Dateien mit einem tar-Befehl übertragen:

# cd sendmail5.65b+IDA1.5+mailx5.3b
# tar cf -- . | (cd /; tar xvvpoof -)

Erzeugen von sendmail.cf

Um eine für Ihr System angepaßte sendmail.cf-Datei zu erzeugen, müssen Sie eine entsprechende sendmail.m4-Datei schreiben und mit m4 verarbeiten. In /usr/local /lib/mail/CF finden Sie eine Beispieldatei namens sample.m4. Kopieren Sie diese Datei und geben Sie ihr einen anderen Namen -- per Konvention wird ihrhostname.m4 verwendet -- und editieren Sie sie so, daß die Situation auf Ihrer Site wiedergegeben wird.

Die Beispieldatei ist für eine reine UUCP-Site geschrieben, die Header mit Domainnamen verwendet und mit einem Smart Host kommuniziert. Bei solchen Sites müssen nur wenige Punkte bearbeitet werden.

In diesem Abschnitt möchte ich Ihnen eine kurze Übersicht der Makros geben, die Sie ändern müssen. Für eine komplette Beschreibung dessen, was sie tun, lesen Sie bitte die frühere Beschreibung von sendmail.m4.

LOCAL_MAILER_DEF
Definiert die Datei, die den Mailer für die lokale Nachrichtenauslieferung definiert. Was hier zu stehen hat, wird im Abschnitt »Definition des lokalen Mailers« beschrieben.

PSEUDONYMS
Definiert alle Namen, unter denen Ihr lokaler Host bekannt ist.

DEFAULT_HOST
An dieser Stelle muß Ihr voll qualifizierter Domainname stehen. Dieser Name erscheint als Ihr Hostname in allen ausgehenden Nachrichten.

UUCPNAME
An dieser Stelle steht Ihr unqualifizierter Hostname.

RELAY_HOST und RELAY_MAILER
Wenn Sie mit einem Smart Host über UUCP kommunizieren, muß RELAY_HOST auf den UUCP-Namen Ihres benachbarten »smarten Verteilerhost« gesetzt sein. Verwenden Sie den UUCP-A-Mailer, wenn Domainnamen im Header erscheinen sollen.

DEFAULT_MAILER
Wenn Sie im Internet hängen und über DNS kommunizieren, sollte dieser Wert auf TCP-A stehen. Dies weist sendmail an, den TCP-A-Mailer zu verwenden, der Nachrichten über SMTP ausliefert und die RFC-konforme Adressierung verwendet. Bei Internet-Sites muß RELAY_HOST oder RELAY_MAILER üblicherweise nicht definiert sein.

Um die Datei sendmail.cf zu erzeugen, müssen Sie den folgenden Befehl ausführen:

# make ihrhostname.cf
Das verarbeitet Ihre ihrhostname.m4-Datei und erzeugt daraus ihrhostname.cf.

Als nächstes sollten Sie überprüfen, ob die von Ihnen erzeugte Konfigurations-Datei auch das tut, was Sie von ihr erwarten. Dies wird in den folgenden beiden Abschnitten behandelt.

Sind Sie mit den Ergebnissen zufrieden, müssen Sie sie mit dem folgenden Befehl an die richtige Stelle kopieren:

# cp ihrhostname.cf /etc/sendmail.cf
An diesem Punkt ist das sendmail-System bereit, in Aktion zu treten. Nehmen Sie die folgende Zeile in die entsprechende Startup-Datei (üblicherweise /etc/rc.inet2) auf. Sie können sie auch von Hand ausführen, damit der Prozeß direkt gestartet wird:
# /usr/lib/sendmail -bd -q1h

Testen der Datei sendmail.cf

Um sendmail im Testmodus zu starten, müssen Sie es mit der Option -bt ausführen. Die Standard-Konfigurationsdatei ist die auf Ihrem System installierte Datei sendmail.cf. Eine andere Datei können Sie über die Option -Cdateiname angeben.

In den folgenden Beispielen testen wir vstout.cf, die Konfigurations-Datei, die aus der in Beispiel 15--1 abgebildeten sendmail.m4 erzeugt wurde. .

# /usr/lib/sendmail -bt -Cvstout.cf
ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
>
Mit den folgenden Tests stellen wir sicher, daß sendmail in der Lage ist, Nachrichten an die Benutzer Ihres Systems auszuliefern. In allen Fällen sollte das Ergebnis des Tests gleich sein und auf das lokale System mit dem LOCAL-Mailer zeigen.

Zuerst wird getestet, wie Mail an einen lokalen Benutzer ausgeliefert wird:

# /usr/lib/sendmail -bt -Cvstout.cf
ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
> 3,0 me
rewrite: ruleset  3   input: me
rewrite: ruleset  7   input: me
rewrite: ruleset  9   input: me
rewrite: ruleset  9 returns: < me >
rewrite: ruleset  7 returns: < > , me
rewrite: ruleset  3 returns: < > , me
rewrite: ruleset  0   input: < > , me
rewrite: ruleset  8   input: < > , me
rewrite: ruleset 20   input: < > , me
rewrite: ruleset 20 returns: < > , @ vstout . vbrew . com , me
rewrite: ruleset  8 returns: < > , @ vstout . vbrew . com , me
rewrite: ruleset 26   input: < > , @ vstout . vbrew . com , me
rewrite: ruleset 26 returns: $# LOCAL $@ vstout . vbrew . com $: me
rewrite: ruleset  0 returns: $# LOCAL $@ vstout . vbrew . com $: me
Die Ausgabe zeigt, wie sendmail die Adresse intern verarbeitet. Diese wird von verschiedenen Regeln analysiert, an andere Regeln übergeben und in ihre einzelnen Komponenten aufgebrochen.

In unserem Beispiel wird die Adresse me an die Regelsätze 3 und 0 übergeben (das ist die Bedeutung der Eingabe 3,0 vor der Adresse). Die letzte Zeile zeigt die übergebene Adresse, wie sie vom Regelsatz 0 zurückgeliefert wird. Enthalten ist der Mailer, an den die Nachricht ausgeliefert würde sowie der an den Mailer übergebene Host- und Benutzername.

Als nächstes kommt die Prüfung von Nachrichten an einen Benutzer Ihres Systems mit UUCP-Syntax.

# /usr/lib/sendmail -bt -Cvstout.cf
ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
> 3,0 vstout!me
rewrite: ruleset  3   input: vstout ! me
[...]
rewrite: ruleset  0 returns: $# LOCAL $@ vstout . vbrew . com  $: me
>
Als nächstes wird Mail an einen Benutzer Ihres Systems in Internet-Syntax mit Ihrem voll qualifizierten Host-Namen getestet:
# /usr/lib/sendmail -bt -Cvstout.cf
ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
> 3,0 me@vstout.vbrew.com
rewrite: ruleset  3   input: me @ vstout . vbrew . com
[...]
rewrite: ruleset  0 returns: $# LOCAL $@ vstout . vbrew . com $: me
>
Sie sollten die beiden vorherigen Tests mit jedem unter PSEUDONYMS und DEFAULT_NAME in ihrer sendmail.m4-Datei angegebenen Namen wiederholen:

Zum Schluß wird geprüft, ob Sie Nachrichten an Ihren Verteilerhost schicken können:

# /usr/lib/sendmail -bt -Cvstout.cf
ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
> 3,0 fred@moria.com
rewrite: ruleset  3   input: fred @ moria . com
rewrite: ruleset  7   input: fred @ moria . com
rewrite: ruleset  9   input: fred @ moria . com
rewrite: ruleset  9 returns: < fred > @ moria . com
rewrite: ruleset  7 returns: < @ moria . com > , fred
rewrite: ruleset  3 returns: < @ moria . com > , fred
rewrite: ruleset  0   input: < @ moria . com > , fred
rewrite: ruleset  8   input: < @ moria . com > , fred
rewrite: ruleset  8 returns: < @ moria . com > , fred
rewrite: ruleset 29   input: < @ moria . com > , fred
rewrite: ruleset 29 returns: < @ moria . com > , fred
rewrite: ruleset 26   input: < @ moria . com > , fred
rewrite: ruleset 25   input: < @ moria . com > , fred
rewrite: ruleset 25 returns: < @ moria . com > , fred
rewrite: ruleset  4   input: < @ moria . com > , fred
rewrite: ruleset  4 returns: fred @ moria . com
<?troff .Nd 6>
rewrite: ruleset 26 returns: < @ moria . com > , fred
rewrite: ruleset  0 returns: $# UUCP-A $@ moria $: < @ moria . com > , fred
>

Integrationstest zwischen sendmail.cf und den Tabellen

An diesem Punkt haben Sie sichergestellt, daß Nachrichten das gewünschte Standardverhalten zeigen, und daß Sie gültig adressierte Nachrichten senden und empfangen können. Um die Installation zu vollenden, könnte es notwendig sein, die entsprechenden dbm-Tabellen zu erzeugen, um die gewünschten Endergebnisse zu erzielen.

Nachdem Sie die für Ihre Site notwendige(n) Tabelle(n) angelegt haben, müssen Sie sie mit dbm durch Eingabe von make verarbeiten, wobei Sie sich in dem Verzeichnis befinden müssen, in dem die Tabellen gespeichert sind.

Wenn Sie nur mit UUCP arbeiten, müssen Sie keine der in README.linux angegebenen Tabellen erzeugen. Sie müssen die Dateien nur mit touch anstoßen, damit das Makefile funktioniert.

Wenn Sie nur mit UUCP arbeiten, aber neben dem Smart Host auch noch mit weiteren Sites kommunizieren, müssen Sie uucpxtable-Einträge für jede Site definieren (weil deren Mail sonst über den Smart Host ausgeliefert würde) und dann dbm über die aktualisierte uucpxtable laufen lassen.

Zuerst müssen Sie sicherstellen, daß Mail über Ihren RELAY_HOST über den RELAY_MAILER an diese Sites verschickt wird:

# /usr/lib/sendmail -bt -Cvstout.cf
ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
> 3,0 fred@sesame.com
rewrite: ruleset  3   input: fred @ sesame . com
rewrite: ruleset  7   input: fred @ sesame . com
rewrite: ruleset  9   input: fred @ sesame . com
rewrite: ruleset  9 returns: < fred > @ sesame . com
rewrite: ruleset  7 returns: < @ sesame . com > , fred
rewrite: ruleset  3 returns: < @ sesame . com > , fred
rewrite: ruleset  0   input: < @ sesame . com > , fred
rewrite: ruleset  8   input: < @ sesame . com > , fred
rewrite: ruleset  8 returns: < @ sesame . com > , fred
rewrite: ruleset 29   input: < @ sesame . com > , fred
rewrite: ruleset 29 returns: < @ sesame . com > , fred
rewrite: ruleset 26   input: < @ sesame . com > , fred
rewrite: ruleset 25   input: < @ sesame . com > , fred
rewrite: ruleset 25 returns: < @ sesame . com > , fred
rewrite: ruleset  4   input: < @ sesame . com > , fred
rewrite: ruleset  4 returns: fred @ sesame . com
rewrite: ruleset 26 returns: < @ sesame . com > , fred
rewrite: ruleset  0 returns: $# UUCP-A $@ moria $: < @ sesame . com > , fred
>
Wenn Sie neben RELAY_HOST weitere UUCP-Nachbarn haben, müssen Sie sicherstellen, daß Mail an diese sich auch entsprechend verhält. Mail-Adressen in UUCP-Syntax, die an einen Host gerichtet sind, mit dem Sie über UUCP kommunizieren, sollten direkt an diesen weitergeleitet werden (solange Sie das nicht durch einen expliziten domaintable-Eintrag verhindern). Nehmen wir an, daß der Host swim einer Ihrer direkten UUCP-Nachbarn ist. Die Angabe von swim!fred an sendmail sollte dann das folgende Ergebnis erzeugen:
# /usr/lib/sendmail -bt -Cvstout.cf
ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
> 3,0 swim!fred
rewrite: ruleset  3   input: swim ! fred
[...lines omitted...]
rewrite: ruleset  0 returns: $# UUCP $@ swim $: < > , fred
>
Wenn Sie uucpxtable-Einträge besitzen, mit denen die Auslieferung an bestimmte UUCP-Nachbarn erzwungen wird, die ihre Mail mit Internet-eigenen Headern versenden, in denen Domainnamen enthalten sind, sollten Sie dies auch prüfen:
# /usr/lib/sendmail -bt -Cvstout.cf
ADDRESS TEST MODE
Enter <ruleset> <address>
[Note: No initial ruleset 3 call]
> 3,0 dude@swim.2birds.com
rewrite: ruleset  3   input: dude @ swim . 2birds . com
[...lines omitted...]
rewrite: ruleset  0 returns: $# UUCP $@ swim . 2birds $: < > , dude
>

Administrivialitäten und dumme Mail-Tricks

Nachdem wir nun die Konfiguration, Installation und den Test eines Sendmail+IDA-Systems theoretisch besprochen haben, sollten wir auch einen Blick darauf werfen, was sich so im normalen Leben eines Mail-Administrators wirklich ereignet.

Systeme stürzen manchmal ab. Modems oder Telefonleitungen funktionieren manchmal nicht. DNS-Definitionen sind manchmal falsch eingestellt. Netzwerke hängen sich unerwartet auf. In solchen Fällen müssen Mail-Administratoren wissen, wie man schnell, effektiv und sicher reagiert, damit der Nachrichtenfluß über alternative Routen weiterläuft, bis das entfernte System oder der Service-Provider den normalen Betrieb wieder aufnimmt.

Der Rest dieses Kapitels soll Sie mit Lösungen versorgen, die häufig bei Mail-Notfällen angewendet werden.

Weiterleitung von Nachrichten an einen Verteilerhost

Um die Mail für einen bestimmten Host oder für eine bestimmte Domain an ein dafür vorgesehenes Verteilersystem weiterzuleiten, wird im allgemeinen die Datei mailertable verwendet. Um beispielsweise die Mail für backwood.org zu deren UUCP-Gateway backdoor weiterzuleiten, müssen Sie den folgenden Eintrag in mailertable aufnehmen:
 UUCP-A,backdoor   backwood.org

Auslieferung von Mail an fehlerhaft konfigurierte Sites erzwingen

Internet-Hosts haben häufig Probleme, Mail an fehlerhaft konfigurierte Sites zu übergeben. Es gibt verschiedene Varianten dieses Problems, aber das allgemeine Symptom ist, daß Mail vom anderen System zurückgeschickt (gebounced) wird oder aber überhaupt nicht dort ankommt.

Diese Probleme können den lokalen Systemadministrator in eine schlechte Position bringen, weil sich die Benutzer im allgemeinen nicht darum kümmern, daß er nicht jedes System auf der ganzen Welt verwaltet (oder weiß, wie man den Administrator des anderen Systems bittet, das Problem zu beheben). Er weiß nur, daß die Nachrichten den gewünschten Empfänger nicht erreichen und daß Sie die greifbarste Person sind, bei der er sich beschweren kann.

Die Konfiguration der anderen Site ist deren Problem, nicht Ihres. Auf keinen Fall sollten Sie Ihre Konfiguration demolieren, um mit der fehlerhaft konfigurierten Site kommunizieren zu können. Falls Sie den Postmaster des anderen Systems nicht dazu bewegen können, die Konfiguration in einer angemessenen Zeit zu korrigieren, bleiben Ihnen zwei Möglichkeiten:

Selbst wenn es Ihnen nun gelingt, die Nachrichten an deren System auszuliefern, wird man dort nicht unbedingt in der Lage sein, darauf zu antworten (schließlich ist das System ja fehlerhaft konfiguriert). Andererseits werden dann die Benutzer des anderen Systems ihre Administratoren anmachen, nicht Ihre Benutzer Sie.

Auslieferung von Mail über UUCP erzwingen

In einer (aus der Sicht des Internet) idealen Welt besitzen alle Hosts Einträge im Domain Name Service und senden Nachrichten mit voll qualifizierten Domainnamen.

Soll über UUCP mit einer solchen Site kommuniziert werden, können Sie dafür sorgen, daß Nachrichten über die direkte UUCP-Verbindung und nicht über den standardmäßigen Mailer ausgeliefert werden, indem Sie mit Hilfe der uucpxtable die Domainnamen aus der Nachricht entfernen.

Um die Auslieferung an sesame.com über UUCP zu erledigen, würden Sie die folgende Zeile in Ihre uucpxtable aufnehmen:

#Domain aus sesame.com entfernen, um Auslieferung über UUCP zu erzwingen
sesame    sesame.com
Das Ergebnis ist, daß sendmail dann erkennt (über UUCPNODES in der Datei sendmail.m4), daß Sie direkt mit dem anderen System verbunden sind, woraufhin die Nachrichten in die Queue geschoben werden, um mit UUCP ausgeliefert zu werden.

Auslieferung von Nachrichten über UUCP verhindern

Aber auch der entgegengesetzte Fall kommt vor. Häufig besitzen Systeme eine Reihe von direkten UUCP-Verbindungen, die nur selten benutzt werden, nicht so zuverlässig sind, oder nicht immer als standardmäßiger Mailer- oder Verteilerhost zur Verfügung stehen.

Beispielsweise gibt es im Raum Seattle eine ganze Reihe von Systemen, die die verschiedenen Linux-Distributionen über »anonymous UUCP« austauschen, sobald diese Distributionen erscheinen. Diese Systeme unterhalten sich über UUCP nur, wenn nötig. Daher ist es grundsätzlich schneller und sicherer, Nachrichten über mehrere, sehr sichere Sprünge und gängige (und immer verfügbare) Verteilerhosts zu senden.

Die Auslieferung von Nachrichten über UUCP an einen Host zu unterdrücken ist sehr einfach, wenn Sie über eine direkte Verbindung zu diesem Host verfügen. Besitzt das andere System einen voll qualifizierten Domainnamen, können Sie einen Eintrag wie den folgenden in die domaintable aufnehmen:

# Auslieferung von Mail über UUCP an einen Nachbarn unterdrücken
snorkel.com       snorkel
Das ersetzt jedes Auftreten des UUCP-Namens durch den voll qualifizierten Domainnamen und verhindert, daß die UUCPNODES-Zeile in der sendmail.m4-Datei greift. Das Ergebnis ist, daß Nachrichten nun über RELAY_MAILER und RELAY_HOST (oder DEFAULT_MAILER) ausgeliefert werden.

sendmail-Queue auf Anforderung ausführen

Um Nachrichten direkt zu verarbeiten, die sich in der Queue angesammelt haben, brauchen Sie nur /usr/lib/runq einzugeben. Auf diese Weise wird sendmail mit den entsprechenden Optionen gestartet, die benötigt werden, um die Queue mit den offenen Jobs direkt zu bearbeiten, anstatt den nächsten vorgesehenen Durchlauf abzuwarten.

Ausgabe von Statistiken

Viele Site-Administratoren (und die Personen, für die sie arbeiten) sind an dem Volumen von Mails interessiert, die von, zur und über die lokale Site fließen. Es gibt eine Anzahl von Möglichkeiten, Mail-Transfer zu quantifizieren:

Mischen und Abstimmen binärer Distributionen

Es gibt keine Standard-Konfiguration für den Transport elektronischer Post und der entsprechenden Programme, und es gibt keine »einzig wahre Verzeichnisstruktur«.

Dementsprechend ist es wichtig, sicherzustellen, daß die verschiedenen Teile des Systems (Usenet-News, Mail, TCP/IP) mit der Position des lokalen Mail-Auslieferungsprogramms (lmail, deliver etc.), mit dem entfernten Mail-Auslieferungsprogramm (rmail) und mit dem Mail-Transportprogramm (sendmail oder smail) zusammenpassen. Solche Annahmen sind grundsätzlich nicht dokumentiert, obwohl Ihnen der Befehl strings helfen kann, zu ermitteln, welche Dateien und Verzeichnisse erwartet werden. Nachfolgend einige Probleme, denen wir in der Vergangenheit bei einigen der gängigen Linux-Binärdistributionen und Sourcen begegnet sind.

Statt uns nun mit den Problemen herumzuschlagen, die die Kompilierung aller Mail-Clients mit sich bringen würde, umgehen wir dies durch Einrichten entsprechender Links.

Wo Sie weitere Informationen finden

Weitere Informationen zu sendmail finden Sie im »Linux Electronic Mail HOWTO«, das regelmäßig in comp.answers gepostet wird. Es steht auch über FTP auf rtfm.mit.edu zur Verfügung.

Der definitive Ort für Informationen sind aber die Sendmail+IDA-Quellen. Sehen Sie sich im Verzeichnis ida/cf, unter dem Quellverzeichnis, die Dateien DBM-GUIDE, OPTIONS und Sendmail.mc an. Lesen Sie mehr dazu im Kapitel 15.


Fußnoten

(1)
deliver wurde von Chip Salzenberg (chip%tct@ateng.com) geschrieben. Es ist Teil verschiedener Linux-Distributionen und kann über die üblichen FTP-Archive wie ftp.uu.net bezogen werden.

Inhaltsverzeichnis Kapitel 14 Kapitel 16