Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Nützliche sendmail-Konfigurationen

sendmail-Konfigurationen gibt es wie Sand am Meer. In diesem Teil zeigen wir nur ein paar wichtige Konfigurationsarten, die in vielen sendmail-Installationen nützlich sind.

Benutzer, die das From:-Feld setzen dürfen

Manchmal ist es nützlich, das From:-Feld einer ausgehenden Mail-Nachricht überschreiben zu können. Nehmen wir zum Beispiel an, Sie hätten ein webbasiertes Programm, das E-Mails erzeugt. Normalerweise enthalten Mail-Nachrichten immer den Namen des Absenders, der den Webserver-Prozeß ausführt. Nun möchten wir aber eine andere Quelladresse angeben, so daß die Mail den Eindruck erweckt, als käme sie von einem anderen Benutzer oder einer anderen Adresse auf dieser Maschine. sendmail stellt nun ein Mittel zur Verfügung, mit dem festgelegt werden kann, welche Systemanwender für vertrauenswürdig erachtet werden, Mail-Nachrichten in der geschilderten Weise modifizieren zu dürfen.

Das Feature use_ct_file aktiviert die Spezifikation und Anwendung einer Datei, die eine Namensliste der vertrauenswürdigen Benutzer enthält. Standardmäßig wird nur eine kleine Anzahl von Systemanwendern von sendmail für vertrauenswürdig gehalten (z.B. root). Der übliche Dateiname dieses Features ist /etc/mail/trusted-users auf Systemen, die /etc/mail/ als Konfigurationsverzeichnis benutzen, bzw. /etc/sendmail.ct, wo das nicht der Fall ist. Sie können Name und Ort der Datei allerdings selbst angeben, indem Sie die Definition von confCT_FILE überschreiben.

Tragen Sie FEATURE(use_ct_file) in Ihre sendmail.mc-Datei ein, um dieses Feature zu aktivieren.

Mail-Aliasnamen

Mail-Aliase sind ein mächtiges Feature, mit dem Mails an Mailboxen geleitet werden können, bei denen es sich um alternative Namen für Benutzer oder Prozesse auf einem Zielhost handelt. Es ist zum Beispiel gängige Praxis, auf einem WWW-Server eingegebene Feedback-Daten oder Kommentare an den “Webmaster” zu leiten. Häufig gibt es aber gar keine Benutzer mit diesem Namen auf dem Zielrechner, sondern es handelt sich nur um einen Alias für einen anderen Anwender. Mail-Aliase werden häufig auch von Mailing-Listen-Serverprogrammen genutzt; sie leiten eingehende Nachrichten zur Verarbeitung an das Serverprogramm weiter.

Aliasnamen werden in der Datei /etc/aliases aufbewahrt. Diese Datei wird von sendmail konsultiert, wenn zu entscheiden ist, wie eine eingehende Mail behandelt werden soll. Falls sendmail in der Datei einen zum Empfänger der Mail passenden Eintrag findet, leitet es die Mail an die Adresse um, die im Eintrag beschrieben ist.

Es gibt im besonderen drei Dinge, die durch Aliase möglich gemacht werden:

• Sie gestatten es, für die Empfänger von Mails eine Kurzform oder einen gängigen Namen zu benutzen, mit dem eine bestimmte Person oder Personengruppe erreicht wird.

• Sie können ein Programm aufrufen, dem die Mail-Nachricht als Eingabe übergeben wird.

• Sie können Mail an eine Datei senden.

Jedes System, das der RFC-Norm entsprechen will, benötigt Aliasnamen für Postmaster und MAILER-DAEMON.

Achten Sie bei der Definition von Aliasen, die Programme aufrufen oder Programmeingaben erzeugen, peinlich genau auf die Systemsicherheit, da sendmail immer mit root-Rechten läuft.

Details zu Mail-Aliasen finden Sie in der Manpage aliases(5). Ein Beispiel für eine aliases-Datei zeigt Tabelle 18.4.

Beispiel 18.4: Beispiel für eine aliases-Datei

# # Die folgenden beiden Aliase müssen angegeben werden, # um RFC-konform zu sein. Wichtig ist, daß sie zu einer 'Person' # resolvieren, die die Mails routinemäßig liest. # postmaster:    root                             # notwendiger Eintrag MAILER-DAEMON: postmaster                   # notwendiger Eintrag # # # Demonstration der allgemeinen Alias-Typen # usenet:         janet                           # Alias für eine Person admin:         joe,janet                        # Alias für mehrere Personen remote-user:    user@otherhost.otherdomain      # Alias für einen nicht-lokalen                                                   Benutzer newspak-users: :include:/usr/lib/lists/newspak  # Empfänger aus Datei lesen changefeed:    |/usr/local/lib/gup              # Alias, der ein Programm aufruft complaints:     /var/log/complaints             # Alias, der Mail an eine Datei                                                  weitergibt #

Immer wenn Sie die Datei /etc/aliases geändert haben, müssen Sie unbedingt folgenden Befehl ausführen:

# /usr/bin/newaliases

# /usr/lib/sendmail -bi

Anwendung eines Smart Host

Manchmal stößt ein Host auf eine Mail, die er nicht direkt an den entsprechenden Remote-Host zustellen kann. Oft ist es zweckdienlich, wenn man in einem Netzwerk einen einzelnen Host dafür abstellt, solche schwer zustellbaren Mails zu verwalten, anstatt dieses den einzelnen Hosts zu überlassen.

Überhaupt gibt es einige gute Gründe, einen einzelnen Host für die Mail-Verwaltung einzusetzen. Sie können die Systemverwaltung vereinfachen, da Sie nur noch einen Host mit einer umfangreichen Mail-Konfiguration ausstatten müssen, der all die verschiedenen Mail-Transportarten wie UUCP, Usenet usw. zu verarbeiten weiß. Alle anderen Hosts brauchen dann nur noch ein einzelnes Transportprotokoll, um ihre Mails an diesen zentralen Host zu senden. Man bezeichnet solche Hosts, die das zentrale Mail-Routing und -Forwarding übernehmen, als Smart Hosts. Wenn Sie einen Smart Host haben, der Mails von Ihnen annimmt, können Sie ihm Mails beliebiger Art zukommen lassen; er wird Ihnen das Routing und die Übertragung dieser Mails abnehmen und sie an die gewünschten Zieladressen weiterleiten.

Eine weitere sinnvolle Anwendung für Smart-Host-Konfigurationen ist die Transportverwaltung von Mail über private Firewalls. Eine Firma könnte sich zum Beispiel dazu entschließen, ein privates IP-Netzwerk zu installieren und darin ihre eigenen unregistrierten IP-Adressen zu benutzen. Dieses private Netzwerk könnte über einen Firewall mit dem Internet verbunden sein. Wollte man nun Mails von den Hosts dieses privaten Netzwerks mittels SMTP an die Außenwelt senden (bzw. umgekehrt), wäre das mit einer konventionellen Konfiguration nicht zu machen, da die Hosts nicht in der Lage wären, direkte Netzwerkverbindungen zu Hosts im Internet herzustellen. Statt dessen könnte sich die Firma dafür entscheiden, ihren Firewall-Rechner auch als Smart Host für die Mail-Verwaltung agieren zu lassen. Der auf dem Firewall laufende Smart Host wäre durchaus in der Lage, direkte Verbindungen mit Hosts sowohl im privaten Netzwerk als auch im Internet herzustellen. Er würde Mails von beiden Seiten annehmen, im lokalen Speicher ablegen und dann für die erneute Übertragung der Mails an die gewünschten Hosts sorgen.

Üblicherweise werden Smart Hosts immer dann eingesetzt, wenn alle anderen Methoden der Mail-Zustellung fehlgeschlagen sind. Im Fall der Firma mit dem privaten Netzwerk wäre es absolut angemessen, die Hosts so einzurichten, daß sie versuchen, ihre Mails zunächst selbst zuzustellen, und im Falle eines Fehlschlags die betroffenen Mails an den Smart Host senden. Das würde den Smart Host von einer Menge Datenverkehr entlasten, denn schließlich könnten die Hosts im privaten Netzwerk sich ihre Mails ja gegenseitig direkt zusenden.

sendmail bietet eine einfache Methode, einen Smart Host zu konfigurieren, nämlich das Feature SMART_HOST. Genau diese Methode benutzen wir bei der Implementierung in unserer virtuellen Brauerei. Die für die Definition des Smart Host relevanten Abschnitte in unserer Konfiguration sind:

define(`SMART_HOST’, `uucp-new:moria’) LOCAL_NET_CONFIG # Diese Regel stellt sicher, daß die lokalen Mails mit Hilfe des smtp-Transports # zugestellt werden. Alles andere läuft über den Smart Host. R$* < @ $* .$m. > $*        $#smtp $@ $2.$m. $: $1 < @ $2.$m. > $3

Mit dem SMART_HOST-Makro können Sie den Host spezifizieren, der alle ausgehenden Mails verteilt, die Sie nicht direkt zustellen können, sowie das dafür zu verwendende Mail-Transportprotokoll.

In unserer Konfiguration benutzen wir den uucp-new-Transport zum UUCP-Host moria. Wollten wir sendmail so konfigurieren, daß es einen SMTP-basierten Smart Host verwendet, würden wir statt dessen etwa folgendes verwenden:

define(`SMART_HOST’, `mail.isp.net’)

Erinnern Sie sich noch, was es mit dem LOCAL_NET_CONFIG-Makro auf sich hatte und was die Rewrite-Regel damit anstellten?

Nun, mit dem LOCAL_NET_CONFIG-Makro können Sie “rohe” sendmail-Rewrite-Regeln in Ihre Konfiguration einfügen, die definieren, welche Mails nur im lokalen Mail-System umlaufen dürfen. In unserem Beispiel benutzen wir eine Regel, die zu allen E-Mail-Adressen paßt, deren Hosts zu unserer Domain (.$m.) gehören, und sie so übersetzt, daß sie direkt zum SMTP-Mailer gesendet werden. Damit wird sichergestellt, daß jede Mail an einen Host in unserer lokalen Domain direkt an den SMTP-Mailer gerichtet und von dort zu diesem Host geleitet wird, anstatt den Umweg über den Smart Host zu machen, wie es standardmäßig geschehen würde.

Verwaltung unerwünschter Mail (Spam)

Wenn Sie sich in eine Mailing-Liste eingetragen, Ihre E-Mail-Adresse auf einer Website veröffentlicht oder einen Artikel ins UseNet gepostet haben, werden Sie höchstwahrscheinlich unerwünschte Werbe-Mails bekommen. Leider hat sich mittlerweile die Unart verbreitet, das Netz nach E-Mail-Adressen zu durchforsten, mit der Absicht, sie in Verteiler-Listen aufzunehmen und diese an Firmen zu verkaufen, die damit für ihre Produkte werben können. Diese Art von E-Mail-Massensendungen bezeichnet man als Spamming.

Das Free On-line Dictionary of Computing bietet eine mailspezifische Definition von Spam an, die wie folgt lautet:¹

2. (Eine Einschränkung von Bedeutung 1, siehe oben.) Das wahllose Versenden nicht angeforderter E-Mails zum Bewerben von Produkten oder Diensten. Spam in diesem Sinne entspricht dem elektronischen Äquivalent von Junk-Mails, die an “Bewohner” gesendet werden.

In den 90er Jahren, als die kommerzielle Bedeutung des Netzes immer größer wurde, gab es wirklich rücksichtslose Individuen, die Firmen, die im Internet werben wollten, Spamming als “Dienst” anboten. Dabei wurden Werbe-Mails an bestimmte Mail-Adressen-Gruppen, Usenet-News oder Mailing-Listen gesendet. Das führte bei vielen Internet­anwendern zu heftigen Gegenreaktionen und aggressiven Wutausbrüchen gegen die Verursacher.

Zum Glück unterstützt sendmail Mechanismen, mit denen Sie unerwünschte Mails gesondert behandeln können.

Real-time Blackhole List

Die Real-time Blackhole List ist eine öffentliche Einrichtung, die Ihnen hilft, den Umfang unerwünschter Werbung, mit der Sie sich herumschlagen müssen, zu reduzieren. Die bekannten “schwarzen Schafe” unter den E-Mail-Adressen und Hosts sind in einer Datenbank im Internet gespeichert, die abgefragt werden kann. Sie werden von Leuten eingegeben, die unerwünschte Werbung von bestimmten E-Mail-Adressen erhalten haben. Größere Domains finden sich manchmal in dieser Liste wieder, wenn beim Einstellen des Spammings eine kleine Panne passiert ist. Obwohl sich manche Leute über einzelne Entscheidungen der RBL-Verwalter beschweren, ist diese Liste dennoch sehr populär, und Unstimmigkeiten werden für gewöhnlich schnell beiseite geräumt. Umfangreiche Informationen darüber, wie dieser Dienst funktioniert, findet man auf der Homepage des Mail Abuse Protection System unter http://maps.vix.com/rbl/.

Wenn Sie dieses sendmail-Feature aktivieren, testet es die Quelladresse jeder ankommenden Mail-Nachricht gegen die Real-time Blackhole List, um festzustellen, ob die Mail akzeptiert werden kann. Wenn Sie eine große Website mit vielen Benutzern betreiben, kann Ihnen dieses Feature beachtlich viel Plattenspeicher einsparen. Dieses Feature akzeptiert einen Parameter, der den Namen des zu benutzenden Servers angibt. Standardvorgabe ist der Hauptserver von rbl.maps.vix.com.

Um das Feature für die Real-time Blackhole List zu konfigurieren, fügen Sie folgende Makrodeklaration in Ihre sendmail.mc-Datei ein:

FEATURE(rbl)

Sollten Sie einen anderen RBL-Server angeben wollen, würden Sie etwa folgende Deklaration benutzen:

FEATURE(rbl,`rbl.host.net’)

Die Zugriffsdatei

Ein alternatives System, das mehr Flexibilität und Kontrolle auf Kosten manueller Konfiguration bietet, ist das sendmail-Feature access_db. In der Zugriffsdatenbank legen Sie fest, von welchen Hosts oder Benutzern Sie Mails akzeptieren und an welche Sie Mails zustellen wollen.

Es ist wichtig für Sie festzulegen, für wen Sie überhaupt Mails vermitteln, denn es gibt eine andere Technik, die häufig von Spamming-Hosts eingesetzt wird, um Systeme wie die gerade beschriebene Real-time Blackhole List zu umgehen. Anstatt Ihnen die Werbe-Mails direkt zuzusenden, leiten die Spammer die Mails über unverdächtige Hosts, die das dürfen. Die ankommende SMTP-Verbindung kommt dann nicht vom Spamming-Host, sondern vom sogenannten Relay-Host. Um sicherzustellen, daß Ihre Mail-Hosts nicht auf diese Weise mißbraucht werden, sollten Sie Mails nur für bekannte Hosts vermitteln. Seit sendmail, Version 8.9.0, ist diese Vermittlung standardmäßig abgeschaltet. Sie müssen daher die Zugriffsdatei heranziehen, um die Vermittlung für individuelle Hosts zu aktivieren.

Das Grundprinzip ist einfach. Wenn eine ankommende SMTP-Verbindung empfangen wird, liest sendmail die Information im Mail-Header, konsultiert dann die Zugriffsdatei und entscheidet, ob es auch den Rumpf der Nachricht akzeptieren soll.

Die Zugriffsdatei ist eine Ansammlung von Regeln, die beschreiben, welche Aktion für Nachrichten durchgeführt werden soll, die von benannten Hosts empfangen werden. Die Standard-Zugriffskontrolldatei ist /etc/mail/access. Die Tabelle hat ein einfaches Format. Jede Tabellenzeile enthält eine Zugriffsregel. Der linksseitige Teil jeder Regel ist ein Muster, mit dem der Absender einer eingehenden Mail-Nachricht überprüft wird. Dabei kann es sich um eine vollständige E-Mail-Adresse, um einen Hostnamen oder eine IP-Adresse handeln. Der rechtsseitige Teil beschreibt die durchzuführende Aktion. Sie können insgesamt fünf Arten von Aktionen konfigurieren:

OK

Mail-Nachricht akzeptieren.

RELAY

Nachrichten von diesem Host oder Benutzer akzeptieren, auch wenn sie nicht für unseren Host bestimmt sind, d.h., diese Aktion akzeptiert Nachrichten zur Vermittlung von diesem Host an andere Hosts.

REJECT

Mail mit einer allgemeinen Nachricht ablehnen.

DISCARD

Nachricht unter Verwendung des Mailers $#discard aussondern.

### any text

Eine Fehlermeldung zurückliefern und ### als Fehlercode (der RFC-821-konform sein sollte) und “any text” als Nachricht verwenden.

Eine Beispieldatei /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

Dieses Beispiel würde jede von friends@cybermail.com empfangene E-Mail ablehnen, ebenso jeden Host aus der Domain aol.com sowie den Host 207.46.131.30. Die nächste Regel würde E-Mails von postmaster@aol.com akzeptieren, obwohl die Domain selbst eine Reject-Regel hat. Die letzte Regel gestattet die Vermittlung von Mails von jedem Host in der linux.org.au-Domain.

Um das Zugriffsdatei-Feature zu aktivieren, benutzen Sie folgende Deklaration in Ihrer sendmail.mc-Datei:

FEATURE(access_db)

Die Standarddefinition bildet die Zugriffsdatei mittels hash -o /etc/mail/access, was aus der Textdatei eine simple Hashdatei erzeugt. Für die meisten Installationen reicht das völlig aus. Es gibt noch andere Optionen, die Sie in Betracht ziehen sollten, wenn Sie eine große Zugriffsdatei haben wollen. Weiterführende Informationen erhalten Sie im sendmail-Buch oder in anderen sendmail-Dokumentationen.

Benutzer vom Mail-Empfang ausschließen

Wenn Sie Benutzer oder automatisierte Prozesse haben, die nur Mails senden, aber nie empfangen, ist es manchmal sinnvoll, an sie gerichtete Mails grundsätzlich abzublocken. Das erspart das Abspeichern unnötiger E-Mails, die sowieso nie gelesen werden. Mit dem blacklist_recipients-Feature, kombiniert mit dem access_db-Feature, können Sie den Mail-Empfang für lokale Benutzer abstellen.

Um dieses Feature zu aktivieren, fügen Sie die folgenden Zeilen in Ihre sendmail.mc ein (wenn sie nicht bereits eingetragen sind):

FEATURE(access_db) FEATURE(blacklist_recipients)

Um den Mail-Empfang für einen lokalen Benutzer abzustellen, tragen Sie einfach nur die Details über ihn in die Zugriffsdatei ein. Für gewöhnlich benutzen Sie dafür den ###-Eintrags-Stil, der eine informative Fehlermeldung an den Absender zurückliefert, damit dieser erfährt, warum die Zustellung nicht geklappt hat. Dieses Feature eignet sich genausogut für Benutzer in virtuellen Mail-Domains; dann müssen Sie diese Domains in die Spezifikation der Zugriffsdatei eintragen. Beispieleinträge für /etc/mail/access könnten so aussehen:

daemon          550 Dämon akzeptiert oder liest keine Mail. flacco          550 Mail für diesen User wurde administrativ abgeschaltet. grump@dairy.org 550 Mail für diesen Empfänger abgeschaltet.

Virtuelles Mail-Hosting konfigurieren

Virtuelles Mail-Hosting versetzt einen Host in die Lage, Mails im Namen verschiedener Domains zu empfangen und zu senden, als ob er selbst eine Gruppe separater Mail-Hosts wäre. Zwar wird es in den meisten Fällen von Internet Application Providern in Kombination mit virtuellem Web-Hosting genutzt, es ist aber leicht zu konfigurieren, und Sie wissen nie, ob Sie sich nicht eines Tages in einer Situation befinden werden, in der Sie eine Mailing-Liste für Ihr eigenes Linux-Projekt virtuell hosten. Daher gehen wir hier näher darauf ein.

Mails für andere Domains akzeptieren

Wenn sendmail eine E-Mail empfängt, vergleicht es den Zielhost in den Mail-Headern mit dem lokalen Hostnamen. Stimmen sie überein, akzeptiert sendmail die Nachricht für lokale Zustellung. Falls nicht, kann sendmail sich dafür entscheiden, die Nachricht zu akzeptieren und zu versuchen, sie an die Zieladresse weiterzuleiten. Details, wie man sendmail konfiguriert, daß es Mails zur Weiterleitung akzeptiert, finden Sie in “Die Zugriffsdatei” in diesem Kapitel.

Wenn wir virtuelles Mail-Hosting konfigurieren wollen, müssen wir zuerst sendmail davon überzeugen, daß es auch Mails für die von uns gehosteten Domains akzeptiert. Zum Glück läßt sich das sehr leicht bewerkstelligen.

Das sendmail-Feature use_cw_file gestattet uns, den Namen einer Datei anzugeben, in der wir die Domainnamen eintragen, für die sendmail Mails akzeptiert. Zur Konfiguration dieses Features fügen Sie die folgende Deklaration in Ihre sendmail.mc-Datei ein:

FEATURE(use_cw_file)

Der Standardname dieser Datei lautet /etc/mail/local-host-names für Distributionen, die das Konfigurationsverzeichnis /etc/mail benutzen, ansonsten /etc/sendmail.cw. Alter­nativ dazu können Sie Name und Ort der Datei festlegen, indem Sie das Makro ­confCW_FILE überschreiben. Beispiel:

define(`confCW_FILE’,`/etc/virtualnames’)

Wenn wir bei den Standardnamen bleiben und virtuelles Hosting für die Domains ­bovine.net, dairy.org und artist.org anbieten wollten, würden wir eine Datei /etc/mail/local-host-names mit folgendem Inhalt erzeugen:

bovine.net dairy.org artist.org

Sobald das erledigt ist und davon ausgegangen werden kann, daß geeignete DNS-Records existieren, die diese Domainnamen auf unseren Host verweisen, wird sendmail Mail-Nachrichten für diese Domains so akzeptieren, als ob sie für unsere echten Domainnamen bestimmt wären.

Virtuell gehostete Mail an andere Zieladressen weiterleiten

Das sendmail-Feature virtusertable konfiguriert die Unterstützung für die virtuelle Benutzertabelle, wo wir virtuelles Mail-Hosting konfigurieren. Die virtuelle Benutzer­tabelle bildet ankommende Mails, die für einen user@host bestimmt sind, in einen ­otheruser@otherhost ab. Sie können sich das wie ein erweitertes Mail-Alias-Feature vorstellen, das nicht nur den Zielbenutzer betrifft, sondern auch die Zieldomain.

Um das virtusertable-Feature zu konfigurieren, fügen Sie es wie folgt in Ihre sendmail.mc-Konfiguration ein:

FEATURE(virtusertable)

Standardmäßig ist /etc/mail/virtusertable die Datei, die die Regeln für die Durchführung der Übersetzungen enthält. Das können Sie überschreiben, indem Sie der Makrodefinition ein Argument übergeben. Welche Optionen es gibt, können Sie in einer detaillierten sendmail-Referenz nachlesen.

Das Format der virtuellen Benutzertabelle ist sehr einfach gehalten. Der linksseitige Teil jeder Zeile enthält ein Muster, das die ursprüngliche Zieladresse der Mail enthält. Der rechtsseitige Teil enthält ein Muster, das die Mail-Adresse repräsentiert, auf die die virtuell gehostete Adresse abgebildet wird.

Das folgende Beispiel zeigt drei mögliche Arten von Einträgen:

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

Der erste Eintrag stellt Mails, die für einen Benutzer der virtuellen Domain bovine.net bestimmt sind, an einen lokalen Benutzer auf der Maschine zu. Der zweite Eintrag leitet Mails für einen Benutzer in derselben virtuellen Domain an einen Benutzer in einer anderen Domain um. Die dritte Zeile bewirkt, daß alle Mails, die an irgendwelche Benutzer in der virtuellen Domain dairy.org adressiert sind, an eine einzelne Remote-Mail-Adresse umgeleitet werden. Schließlich führt der letzte Eintrag dazu, daß die an die Benutzer der virtuellen Domain artist.org gerichteten Mails an die gleichnamigen Benutzer einer anderen Domain adressiert werden, zum Beispiel von julie@artists.org nach julie@red.firefly.com.

Weitere Informationen zum Linux - Wegweiser für Netzwerker

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center