Deutsche Ausgabe. sendmail. KochbuchTM. Craig Hunt. Deutsche Übersetzung von Kathrin Lichtenberg

Transkript

1 Deutsche Ausgabe sendmail KochbuchTM Craig Hunt Deutsche Übersetzung von Kathrin Lichtenberg

2

3 sendmail Kochbuch Craig Hunt Deutsche Übersetzung von Kathrin Lichtenberg Beijing Cambridge Farnham Köln Paris Sebastopol Taipei Tokyo

4 Die Informationen in diesem Buch wurden mit größter Sorgfalt erarbeitet. Dennoch können Fehler nicht vollständig ausgeschlossen werden. Verlag, Autoren und Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für eventuell verbliebene Fehler und deren Folgen. Alle Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt und sind möglicherweise eingetragene Warenzeichen. Der Verlag richtet sich im wesentlichen nach den Schreibweisen der Hersteller. 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. Kommentare und Fragen können Sie gerne an uns richten: O Reilly Verlag Balthasarstr Köln Tel.: 0221/ Fax: 0221/ kommentar@oreilly.de Copyright der deutschen Ausgabe: 2004 by O Reilly Verlag GmbH & Co. KG 1. Auflage 2004 Die Originalausgabe erschien 2004 unter dem Titel sendmail Cookbook bei O Reilly Media, Inc. Die Darstellung von Zwergfledermäusen im Zusammenhang mit dem Thema sendmail ist ein Warenzeichen von O Reilly Media, Inc. Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar. Übersetzung und deutsche Bearbeitung: Kathrin Lichtenberg, Ilmenau Lektorat: Kerstin Grebenstein & Ariane Hesse, Köln Fachliche Unterstützung: Sven Riedel, Hannover Korrektorat: Friederike Daenecke, Zülpich Satz: G&U e.publishing Services GmbH, Flensburg Umschlaggestaltung: Ellie Volckhausen, Emma Colby & Melanie Wang, Boston Produktion: Karin Driesen & Stephanie Buckstegge, Köln Belichtung, Druck und buchbinderische Verarbeitung: Druckerei Kösel, Krugzell; ISBN Dieses Buch ist auf 100% chlorfrei gebleichtem Papier gedruckt.

5 Für Amanda, Pat, Kathy, Sara und alle Mütter überall auf der Welt, durch die Leben und unsere Liebe zum Leben immer wieder neu entstehen.

6

7 First Inhalt Vorwort XI 1 Der Einstieg Die neueste Version herunterladen sendmail installieren sendmail für die Benutzung von LDAP kompilieren Den Datenbanktyp regex zu sendmail hinzufügen sendmail mit SASL-Unterstützung kompilieren sendmail mit STARTTLS-Unterstützung kompilieren STARTTLS-Dateipfade hineinkompilieren Eine sendmail-konfiguration erzeugen Eine neue Konfiguration testen sendmail-protokollierung Auslieferung und Weiterleitung Mail für andere Hosts akzeptieren Den Alias0 Missing Map-Fehler beheben und einfache Aliase anlegen Aliase über LDAP lesen Red Hat 7.3 so konfigurieren, dass es Aliase von einem NIS-Server ausliest Solaris 8 so konfigurieren, dass es Aliase von einem NIS-Server ausliest Weiterleitung an eine externe Adresse Mailinglisten anlegen Ehemalige Benutzer auf neue Adressen migrieren Mail an ein Programm ausliefern Programmnamen in Mailinglisten benutzen Nonlogin-Benutzern das Weiterleiten auf Programme erlauben Eine.forward-Schleife reparieren Die Benutzerdatenbank aktivieren Inhalt VII

8 3 Weitervermittlung (Relaying) Alle Mails an ein Relay übergeben Ausgehende Mails an ein Relay übergeben Lokale Mail an einen Mail-Hub übergeben Scheinbar lokale Mail an ein Relay übergeben UUCP-Mail an ein Relay übergeben Mail für alle Hosts in einer Domain vermitteln Mail für einzelne Hosts vermitteln Die Weitervermittlung auf einem Mail Exchanger konfigurieren Die Klasse $=R über LDAP laden Nur ausgehende Mail vermitteln Links 4 Masquerading Allen Absenderadressen Domains hinzufügen Den Hostnamen des Absenders maskieren Masquerading für den lokalen Mailer ausschalten Masquerading lokaler Mail erzwingen Empfängeradressen maskieren Masquerading am Relay Host Das Masquerading beschränken Alle Hosts in einer Domain maskieren Die meisten Hosts in einer Domain maskieren Die Umschlagadresse maskieren Die From-Adresse mit der genericstable umschreiben Absenderadressen für eine komplette Domain umschreiben Masquerading und LDAP Die genericstable über LDAP einlesen Mail-Routing Mail an Mailer für besondere Aufgaben routen Fehlermeldungen aus der mailertable senden Die MX-Verarbeitung deaktivieren, um Schleifen zu vermeiden Mail für die lokale Auslieferung routen Die mailertable über LDAP lesen Mail für einzelne virtuelle Hosts routen Mail für komplette virtuelle Domains routen Die virtusertable über LDAP lesen Mail mit LDAP routen LDAP-Routing mit Masquerading benutzen VIII Inhalt

9 Rechts 6 Spam unter Kontrolle halten Spam mit der access-datenbank blockieren Verhindern, dass lokale Benutzer auf Spammer antworten Die access-datenbank über LDAP lesen Einen DNS-Blackhole-List-Dienst benutzen Ihre eigene DNS-Blackhole-Liste anlegen Auf einer schwarzen Liste geführte Sites wieder freigeben Lokale Mail mit procmail filtern Ausgehende Mail mit procmail filtern Eine besondere Header-Verarbeitung auslösen Reguläre Ausdrücke in sendmail verwenden Lokale Benutzer identifizieren, die Ihnen Probleme bereiten MILTER benutzen Spam-Überprüfungen umgehen Spam-Überprüfungen pro Benutzer aktivieren Authentifizierung mit AUTH Eine AUTH-Authentifizierung anbieten Mit AUTH authentifizieren AUTH-Credentials in der Datei authinfo speichern Angekündigte Authentifizierungsmechanismen beschränken Mit AUTH die Weitervermittlung erlauben Den AUTH=-Parameter steuern Doppelte Verschlüsselung vermeiden Authentifizierung verlangen Selektiv eine Authentifizierung verlangen Den Mail-Transport sichern Eine private Certificate Authority aufbauen Eine Zertifizierungsanforderung erzeugen Eine Zertifizierungsanforderung signieren sendmail für STARTTLS konfigurieren Weitervermittlung auf der Grundlage der CA Weitervermittlung auf der Grundlage des Certificate-Subject Nach außen gerichtete Verschlüsselung anfordern Eine nach innen gerichtete Verschlüsselung anfordern Ein verifiziertes Zertifikat anfordern TLS für einen Empfänger anfordern Den STARTTLS-Dienst ablehnen STARTTLS selektiv bekannt machen Client-Zertifikate anfordern Inhalt IX

10 9 Die Warteschlange verwalten Mehrere Warteschlangen anlegen Die Unterverzeichnisse qf, df und xf benutzen Warteschlangengruppen definieren Empfänger bestimmten Warteschlangen zuweisen Persistente Queue-Runner benutzen Einen Warteschlangen-Server benutzen Protokoll-Timer setzen Links 10 sendmail sichern Die Anzahl der sendmail-server beschränken Die Anzahl der vom Netzwerk erreichbaren Server begrenzen Eine Aktualisierung durchführen, um Sicherheitslücken zu schließen Patches einspielen, um Sicherheitslücken zu schließen Die Auslieferung an Programme deaktivieren Die Auslieferung an Programme kontrollieren Die Auslieferung an Dateien deaktivieren Die.forward-Dateien eines Benutzers umgehen Die Auslieferung an Dateien kontrollieren sendmail nicht als root ausführen Eine sichere Standard-Benutzer-ID setzen Vertrauenswürdige Benutzer definieren Den sendmail-administrator identifizieren Die Menge der SMTP-Befehle einschränken Ein gültiges HELO verlangen Kommandozeilenoptionen einschränken DoS-Angriffe abwehren Index X Inhalt

11 First Vorwort Einführung sendmail ist heutzutage die leistungsfähigste und am weitesten verbreitete Unix- - Software weltweit. Millionen von Unix-Systemen laufen zurzeit mit sendmail. Allerdings finden viele Systemadministratoren dieses verbreitete Werkzeug äußerst verwirrend, und die meisten scheuen die sendmail-konfiguration. Diese Angst hat eine sehr rationale Grundlage: Komplexität und fehlende Vertrautheit. Die sendmail-konfigurationssprachen sind ebenso komplex wie andere Programmiersprachen und werden im Gegensatz zu vielen anderen Sprachen selten benutzt. sendmail wird konfiguriert, wenn es installiert oder aktualisiert wird; ansonsten hat der Administrator wenig mit der sendmail-konfiguration zu tun. Der durchschnittliche Systemadministrator hat einfach nicht genug Übung, um die sendmail-konfigurationssprachen wirklich zu meistern. Für mich und vermutlich auch für viele andere Technik-Freaks fällt das Kochen einer anständigen Mahlzeit ebenfalls in die Kategorie der Dinge, die ich nicht oft praktiziere. Was mich betrifft, sind eine Coke und ein Snickers schon ein Abendessen, während Bier und Bretzeln bereits ein Festessen darstellen. Wenn ich einmal an der Reihe bin, für andere zu kochen, vor allem ein aufwändiges Mahl, dann brauche ich Hilfe. Ich habe nicht die Zeit, selbst kochen zu lernen ich benötige jemanden, der mir sagt, was genau ich tun muss. Glücklicherweise wurden für diese Situationen Kochbücher erfunden. Ein Kochbuch bietet Rezepte für viele verschiedene Situationen. Die Rezepte stellen schrittweise Lösungen für bestimmte Probleme dar. In der Küche besteht das Problem darin, wie man bestimmte Gerichte richtig herstellt. Bei einem sendmail-server besteht das Problem darin, wie man mit bestimmten Situationen umgeht; zum Beispiel, wie man sendmail so konfiguriert, dass es Mail für Ihre Clients weitervermittelt, ohne ein offenes Relay zu schaffen, das von Spammern ausgenutzt wird. Wie der Name sendmail Kochbuch nahe legt, ist dies ein Kochbuch, randvoll mit Rezepten für die richtige sendmail-konfiguration. Ein sendmail-rezept umreißt ein Konfigurationsproblem, präsentiert den Konfigurationscode, der dieses Problem löst, und erläutert XI

12 den Code dann im Detail. Die Diskussionen des Code sind wichtig, da sie Ihnen einen Einblick verschaffen, wie Sie den Code so anpassen, dass er für Ihren Server geeignet ist. Die Haupteigenschaft dieses Buches ist es, dass Sie dadurch Zeit sparen. Zeit ist etwas, das bei den meisten Systemadministratoren immer knapp ist. Wenn Sie ein bestimmtes Problem bei der sendmail-konfiguration haben, dann geht es schneller, eine schrittweise Lösung nachzuschlagen, als das Problem zu erforschen und Ihre eigene Lösung zu entwickeln. Dieses Buch bietet schnelle Lösungen für viele häufig auftretende sendmail-konfigurationsprobleme. Das sendmail Kochbuch benutzt das gleiche Format aus Problem/Lösung/Diskussion, das in allen O Reilly-Kochbüchern zum Einsatz kommt. Als Beispiel für dieses Format ist der folgende Abschnitt, der erklärt, wie Sie dieses Buch benutzen können, im Rezeptformat gehalten. Links Dieses Kochbuch benutzen Problem Sie müssen dieses Kochbuch auf möglichst effektive Weise benutzen. Lösung Gehen Sie direkt zu dem Rezept, das sich mit Ihrem sendmail-problem befasst. Folgen Sie den Schritten in Ihrem ausgewählten Rezept. Kombinieren Sie die Elemente aus dem gewählten Rezept mit Ihrer tatsächlichen Konfiguration. Lesen Sie die Diskussion Ihres gewählten Rezepts, und führen Sie die dort gezeigten Tests durch, um sicherzustellen, dass das Rezept in Ihrer Arbeitsumgebung funktioniert. Diskussion Die meisten Bücher werden als eine Einheit geschrieben und sind dazu gedacht, als Ganzes gelesen zu werden. Ein Abschnitt führt zum nächsten über, ein Kapitel führt zum nächsten, und ein roter Faden soll Sie durch das Buch leiten. Ein Kochbuch funktioniert anders. Jedes Rezept steht für sich allein. Sie setzen sich nicht hin und lesen ein Kochbuch von vorn nach hinten durch. Sie würden das wahrscheinlich monoton und ziemlich langweilig finden (es sei denn, Sie sind sehr hungrig!). Das sendmail Kochbuch ist ein echtes Kochbuch. Versuchen Sie nicht, es von vorn nach hinten durchzulesen. Begeben Sie sich stattdessen direkt zu dem Rezept, das Sie für Ihr spezielles sendmail-problem benötigen. Die Rezepte in diesem Buch sind vollständig. Folgen Sie einem Rezept, und Sie haben eine voll funktionstüchtige Konfiguration, die getestet und überprüft werden kann. Da es sich um komplette, eigenständige Rezepte handelt, kommt es zu Wiederholungen. Jedes XII Vorwort

13 Rechts Rezept, das verlangt, die Datei sendmail.cf neu zu erstellen, sagt:»erstellen Sie die Datei sendmail.cf neu.«es geht nicht davon aus, dass Sie bereits andere Rezepte gelesen haben und deshalb wissen, wann Sie die Datei neu zu erstellen haben. Um jedoch die Menge der Wiederholungen zu reduzieren, werden Schritte, die in vielen Rezepten zum Einsatz kommen etwa das Kompilieren von sendmail oder das Erstellen der Datei sendmail.cf, einmal im Detail erläutert. Nachfolgende Rezepte verweisen dann lediglich auf diese früheren Rezepte, ohne die einzelnen Schritte noch einmal in allen Einzelheiten zu wiederholen. Eine effektive Technik für die Benutzung dieser Rezepte besteht darin, ein Rezept zuerst auf einem kleinen Testsystem umzusetzen. Auf diese Weise können Sie das Rezept nachvollziehen, ohne zu versuchen, die Funktionen dieses Rezeptes mit Ihrer aktuellen Konfiguration zu mischen, bevor Sie überhaupt die Wirksamkeit des Rezepts für Ihr spezielles Problem bewertet haben. Nachdem Sie festgestellt haben, dass die im Rezept verwendete Funktion für Ihr Problem geeignet ist, kann sie in Ihre eigentliche Konfiguration aufgenommen, erneut getestet und dann freigegeben werden. Viele Systemadministratoren, die das jetzt lesen, werden sagen:»woher nehme ich die Zeit, eine separate sendmail-konfiguration zu implementieren und zu testen?«keine Panik. Die schrittweisen Anleitungen aus diesem Buch können in wenigen Minuten umgesetzt und getestet werden. Und ein alter PC mit FreeBSD oder Linux kann als Testsystem dienen. Um genau zu sein, wurden die meisten Rezepte in diesem Buch auf einem System mit Red Hat Linux implementiert. Wie alle Kochbücher ist auch dieses Buch voll mit Rezepten für einzelne Gerichte. Es ist Ihre Aufgabe, die verschiedenen Rezepte auszuwählen, die Sie benötigen, um eine komplette Mahlzeit zusammenzustellen. Fügen Sie die neuen sendmail-konfigurationsfunktionen nacheinander ein, und testen Sie sie jedes Mal. Verschiedene Konfigurationsfunktionen können auf unerwartete Weise miteinander interagieren. Das Testen der kombinierten Konfiguration ist sehr wichtig. Siehe auch Der Siehe-auch-Abschnitt der einzelnen Rezepte verweist auf andere Rezepte, die zusätzlich hilfreich sein können. Außerdem verweist er auf diejenigen Abschnitte im O Reilly- Buch sendmail von Bryan Costales und Eric Allman, die technische Referenzen für das im jeweiligen Rezept behandelte Thema darstellen. Die Zielgruppe Das sendmail Kochbuch ist für all diejenigen gedacht, die sendmail-software konfigurieren müssen, die auf einem Unix-Computer läuft. Das schließt ganz offensichtlich den sendmail-administrator ein, der den Mailserver betreibt, und die Systemadministratoren, die für den Betrieb der Unix-Computer verantwortlich sind, aber auch alle Benutzer, die eine sendmail-konfiguration auf einem Desktop-Unix-System warten. Die Unix-Work- Vorwort XIII

14 station auf Ihrem Schreibtisch erfordert es wahrscheinlich, dass Sie Aufgaben bei der Systemadministration übernehmen. Falls zu diesen Aufgaben auch die sendmail- Konfiguration gehört, dann sollten Sie dieses Buch lesen. Wir gehen davon aus, dass Sie sich mit Computern und deren Betrieb gut auskennen und dass Sie im Allgemeinen mit der sendmail-konfiguration vertraut sind. Falls Ihnen Unix völlig neu ist, dann ist dieses Buch nicht für Sie geeignet. Auch wenn Sie bereits ein Experte bei der sendmail-administration sind, ist dieses Buch nicht sehr passend. Finden Sie sich jedoch irgendwo zwischen diesen beiden Extremfällen wieder, dann werden Sie feststellen, dass dieses Buch Ihnen eine Menge zu bieten hat. Ein Kochbuch hilft Ihnen, eine anständige Mahlzeit zu kochen, es verwandelt Sie jedoch nicht in einen Viersternekoch. Auch dieses Buch bietet Ihnen effektive Lösungen für häufig auftretende Probleme bei der sendmail-konfiguration, macht aus Ihnen aber keinen sendmail-guru. Das völlige Beherrschen eines Themas, das so komplex ist wie sendmail, erfordert mehr als nur empfohlene Lösungen für verbreitete Probleme. Um alle sendmail- Informationen zu haben, brauchen Sie eine Referenz und ein Tutorial zusätzlich zu einem Kochbuch. Die beste und vollständigste sendmail-referenz ist das Buch sendmail von Bryan Costales in Zusammenarbeit mit Eric Allman (O Reilly). Es wird Sie kaum überraschen, dass meine Lieblingsanleitung für sendmail das Buch Linux Sendmail Administration von Craig Hunt (Sybex) ist. Falls Ihr Job es mit sich bringt, dass Sie zu einem sendmail-guru werden müssen, brauchen Sie vermutlich alle drei Bücher. Aufbau des Buches Die sendmail-konfiguration ist nur das Mittel zum Zweck. sendmail wird konfiguriert, um bestimmte Funktionen effektiv auszuführen. Dieses Buch konzentriert sich auf die richtigen Konfigurationen für diese Funktionen. Elemente der sendmail-konfigurationssprache sind sekundär. Der Konfigurationscode wird ausführlich genug erklärt, so dass Sie ihn verstehen können, Sie können den Code also entsprechend an Ihr System anpassen. Das Ziel besteht jedoch darin, benutzbare Lösungen für allgemeine Probleme zu liefern. Dieses Ziel erfordert ein Buch, das um die Funktionen von sendmail herum aufgebaut ist. Das erste Kapitel definiert das grundlegende Gerüst, auf dem all die anderen Kapitel aufbauen. Es bietet Rezepte für das Herunterladen und Installieren der sendmail-distribution, für das Neukompilieren von sendmail, um eine Vielzahl von Funktionen zu unterstützen, für das Erstellen der sendmail-konfiguration und für das Testen einer neuen Konfiguration. Von Kapitel 2 bis zu Kapitel 10 werden Beispiellösungen für das richtige Konfigurieren wichtiger sendmail-funktionen geliefert. Einen Überblick über die Funktionen und Befehle, die in den einzelnen Kapiteln zum Einsatz kommen, finden Sie jeweils in der Einführung der Kapitel. Die Rezepte in den Kapiteln 2 bis 10 sind eigenständig. Ein Administrator kann sich direkt zu einer speziellen Lösung begeben und erhält ausreichend Informationen, um ein Links XIV Vorwort

15 Rechts bestimmtes Problem zu lösen. Die meisten dieser Lösungen befassen sich nur mit einem Problem. Ihre Konfiguration muss möglicherweise mehrere Probleme lösen. Sie können in diesem Buch hin- und herblättern und nur die Dinge suchen, die Sie benötigen. Beispielsweise muss Ihr Server ja vielleicht Mails für mehrere Clients akzeptieren und soll außerdem die Hostnamen dieser Clients in ausgehenden Mails verbergen. Eine solche Konfiguration braucht Rezepte aus Kapitel 2 und aus Kapitel 4. Nehmen Sie nur die Dinge, die Ihren Anforderungen entsprechen. Hier nun eine kurze Zusammenfassung der Kapitel in diesem Buch: Kapitel 1, Der Einstieg, beschreibt die Dateien und Verzeichnisse, die verwendet werden, um eine sendmail-konfiguration zu erstellen. Es bietet Anleitungen für das Herunterladen, Installieren und Kompilieren von sendmail und für das Erstellen und Testen einer sendmail-konfiguration. Kapitel 2, Auslieferung und Weiterleitung, konzentriert sich auf die Mail-Auslieferung. Die sendmail-konfiguration kontrolliert, welche Mail für die Auslieferung akzeptiert wird. Das Akzeptieren der richtigen Mail ist beim Einrichten eines Servers wichtig, vor allem eines Servers, der als Mail Exchanger arbeiten soll. Außerdem kann nur bei Mail, die für die Auslieferung akzeptiert wurde, eine Alias-Verarbeitung vorgenommen werden bzw. kann nur solche Mail weitergeleitet werden. Eine richtig konfigurierte Alias-Auflösung unterstützt Clients und erzeugt Mailinglisten. Kapitel 3, Weitervermittlung (Relaying), konzentriert sich auf die Mail-Weitervermittlung (Relaying). Wenn Mail vom lokalen Server nicht für die Auslieferung akzeptiert wird, muss sendmail entscheiden, ob sie zur Auslieferung an einen anderen Server weitervermittelt werden soll. Eine richtig konfigurierte Weitervermittlung ist wichtig, um einen voll funktionsfähigen Server zu erzeugen. Außerdem stellt sie eine Hauptzutat bei der Spam-Kontrolle dar. Ein Fehler bei der Relay-Konfiguration kann dazu führen, dass Ihr Server auf einer schwarzen Liste landet! Kapitel 4, Masquerading, beschreibt, weshalb und wie die wahre Identität des Endsystems bei einem Mail-Austausch verborgen wird. Die Maskierung verbirgt die Quelladresse ausgehender Mail. Das Kapitel behandelt sowohl die einfache Maskierung als auch die genericstable-datenbank. Es werden Konfigurationen vorgestellt, die sowohl den Host- als auch den Benutzeranteil der Quelladresse verbergen. Kapitel 5, Mail-Routing, beschreibt, wie der Administrator das Mail-Routing durch die Benutzung der sendmail-datenbanken kontrolliert. Die mailertable wird verwendet, um Mail zur speziellen Verarbeitung an einen bestimmten Mailer zu routen. Die mailertable bietet Zugriff auf eine Vielzahl von Mailern, die von sendmail bereitgestellt werden. Virtuelle Maildomains erlauben es einem einzigen Mailserver, Mail für viele unterschiedliche Domains zu verarbeiten. Die Benutzung der virtusertable-datenbank zum Verarbeiten virtueller Maildomains wird behandelt. Die Funktion ldap_routing, die Intranet-Mailrouting-Informationen von einem LDAP-Server liest, wird ebenfalls behandelt. Vorwort XV

16 Kapitel 6, Spam unter Kontrolle halten, beschreibt, wie Sie sendmail konfigurieren müssen, um das Problem der unerwünschten kommerziellen s zu reduzieren. In diesem Kapitel wird gezeigt, wie die access-datenbank zur Spam-Kontrolle eingesetzt wird, wie sendmail konfiguriert werden muss, um procmail für die Filterung persönlicher, lokaler und ausgehender Mail zu benutzen, und wie Sie Ihre eigene DNS-Blackhole-Liste erstellen. Außerdem werden die Header-Verarbeitung und reguläre Ausdrücke für die sendmail.cf behandelt. Kapitel 7, Authentifizierung mit AUTH, bietet Lösungen, um sendmail so zu konfigurieren, dass es als SMTP-AUTH-Server oder -Client fungiert. Es werden Beispielkonfigurationen für sendmail gezeigt, ebenso die notwendigen SASL-Konfigurationsdateien. Darüber hinaus wird darauf eingegangen, wie die access-datenbank mit der AUTH- Authentifizierung benutzt wird. Kapitel 8, Den Mail-Transport sichern, behandelt STARTTLS, die sendmail-funktion, die zum Verschlüsseln des Mail-Transports eingesetzt wird. Die sendmail-konfiguration von STARTTLS wird zusammen mit der erforderlichen Konfiguration der SSL-Werkzeuge geliefert, die von sendmail verwendet werden. Auch das Anlegen einer privaten sendmail-ca, von Client- und Server-Zertifikaten sowie das Signieren von Zertifikaten wird behandelt. Sie finden Rezepte, die steuern, wann eine Verschlüsselung eingesetzt wird, sowie Beispiele für die Benutzung von STARTTLS mit der access-datenbank. Kapitel 9, Die Warteschlange verwalten, behandelt sendmail-konfigurationen, die besonders für Systeme mit großen Mail-Warteschlangen nützlich sind. Es beschreibt das Erzeugen mehrerer Warteschlangen, das Definieren von Warteschlangengruppen und das Benutzen der Warteschlangengruppen mit der access-datenbank. Kapitel 10, sendmail sichern, liefert Rezepte, mit denen Sie die sendmail-sicherheit verbessern können. Standardmäßig verfügt sendmail über eng gesteckte Sicherheitseinstellungen. Manche Konfigurationen lockern die sendmail-sicherheit, um die Flexibilität zu erhöhen. Die Rezepte in diesem Kapitel verfolgen den entgegengesetzten Ansatz. Sie sind für alle gedacht, die willens sind, die Flexibilität der erhöhten Sicherheit zu opfern. Software-Versionen Die meisten der Beispiele sind unter Red Hat Linux 7.3 und 8.0 sowie Solaris 8 entstanden. Es ist jedoch relativ egal, welche Versionen von Unix verwendet wurden, um die Beispiele zu erzeugen. Es gibt kleine Unterschiede bei der Befehlsausgabe oder den Kommandozeilenoptionen; diese Unterschiede sollten jedoch kein Problem darstellen. sendmail-software funktioniert auf den verschiedenen Systemen auf die gleiche Weise. Viel wichtigere Unterschiede entstehen dagegen durch die jeweils verwendete sendmail- Version. sendmail wird ständig weiterentwickelt. Die Beispiele in diesem Buch basieren auf sendmail 8.12, speziell auf und Wir wissen nicht, ob die Rezepte bei anderen sendmail-versionen genauso funktionieren, wie hier gezeigt; sie sollten es jedoch mit minimalen Anpassungen tun. Links XVI Vorwort

17 Rechts Konventionen Dieses Buch verwendet die folgenden typographischen Konventionen: Kursivschrift Diese kennzeichnet die Namen von Dateien, Datenbanken, Verzeichnissen, Hosts, Domains, Benutzern, sendmail-funktionen sowie Unix-Dienstprogramme und Programme und wird verwendet, um neue Begriffe bei ihrer ersten Erwähnung hervorzuheben. Nichtproportionalschrift Kennzeichnet sendmail.cf-literale, -Befehle und -Variablen, m4-makros und integrierte Befehle sowie Unix-Kommandozeilenoptionen. Sie wird benutzt, um den Inhalt von Dateien und die Ausgabe von Befehlen zu zeigen. Schlüsselwörter sind ebenfalls in Nichtproportionalschrift gesetzt. Nichtproportionalschrift fett Wird benutzt, um Befehle oder Texte anzuzeigen, die Sie eingeben würden. Nichtproportionalschrift kursiv Wird in Beispielen und Text verwendet, um Variablen zu zeigen, für die eine kontextabhängige Ersetzung vorgenommen werden soll. (Die Variable dateiname würde zum Beispiel durch einen tatsächlichen Dateinamen ersetzt werden.) $, # Wenn wir Befehle demonstrieren, die Sie interaktiv ausführen würden, benutzen wir normalerweise den Standard-Prompt der Bourne-Shell ($). Muss der Befehl als root ausgeführt werden, verwenden wir den Standard-Prompt für den Superuser (#). [ option ] Beim Demonstrieren der Befehlssyntax setzen wir optionale Teile des Befehls in eckige Klammern. Zum Beispiel bedeutet ls [ -l ], dass die Option -l nicht erforderlich ist. Dieses Symbol kennzeichnet einen Hinweis, einen Vorschlag oder eine allgemeine Anmerkung. Dieses Symbol kennzeichnet eine Warnung. Vorwort XVII

18 Danksagungen Kein Buch ist das Produkt nur einer Person. Dieses hier ganz gewiss nicht! Ich muss vielen Leuten für ihre Hilfe beim Herstellen dieses Buches danken. Die Idee für dieses Buch stammt ursprünglich von Tim O Reilly. Mike Loukides erklärte mir das Konzept des Buches, und ich wusste, dass ich es schreiben wollte. Tim und Mike gebührt Dank dafür, dass sie den Stein ins Rollen brachten. Zwei Lektoren haben mich durch den langen und schwierigen Prozess der Produktion dieses Buches begleitet. Jim Sumser arbeitete mit mir während der ersten Phase des Schreibens zusammen. Simon St.Laurent brachte mich über die Ziellinie. Beide Jungs waren mir eine große Hilfe. Ganz besonders möchte ich meinen technischen Gutachtern, Greg Shapiro, Claus Assmann und Nick Christenson, danken. Sie können sich kein besseres technisches Team vorstellen. Schauen Sie sich die Liste der Autoren für den Sendmail Installation and Operations Guide an, und Sie werden Greg und Claus dort finden. Gregs Namen sehen Sie auch bei den meisten Beispielkonfigurationen, die mit der sendmail-distribution geliefert werden niemand weiß mehr über die sendmail-konfiguration als Greg. Was Nick betrifft, so ist er der Autor des Buches sendmail Performance Tuning (Addison Wesley), das Eric Allman einfach als»großartig«bezeichnet. Diese Jungs kennen sendmail und haben sich die Zeit genommen, jede Seite dieses Buches peinlich genau zu überprüfen. Ihre Hilfe und ihr Einblick waren von unschätzbarem Wert. Durch ihr Engagement ist es zu einem viel besseren Buch geworden. Ich möchte außerdem der Mannschaft bei O Reilly danken. Mein Dank geht an Marlowe Shaeffer, Production Editor und Korrektor, dafür, dass er dieses Buch fertig bekommen hat, an Derek Di Matteo für die Arbeit am Text, an Ellie Volckhausen für Ihre Arbeit am Cover und an Tom Dinse für die Indizierung. Schließlich möchte ich noch meiner Familie für die Geduld danken, die sie auch dann aufgebracht hat, wenn ich keine Geduld mehr hatte. Links XVIII Vorwort

19 First Kapitel 1 KAPITEL 1 Der Einstieg 1.0 Einführung Um ein Rezept richtig befolgen zu können, müssen Sie die Anweisungen genau verstehen, die es enthält. Sie müssen den Unterschied zwischen Unterheben und Rühren kennen und in der Lage sein, das Gewürz zu finden, wenn im Rezept eine Prise Kreuzkümmel gefordert wird. Genauso wie Sie sich in der Küche auskennen müssen, um Koch zu werden, müssen Sie mit der sendmail-distribution klarkommen, wenn Sie eine sendmail-konfiguration erstellen oder anpassen wollen. Die Verzeichnisstruktur erzeugt durch die tar-datei der sendmail-quellcodedistribution enthält die Werkzeuge und Zutaten, die benötigt werden, um sendmail zu kompilieren und zu konfigurieren. Dem obersten Verzeichnis, das vom tar-archiv angelegt wurde, wird ein Name zugewiesen, der die sendmail-versionsnummer identifiziert. Zum Zeitpunkt der Entstehung des Buches lautete die aktuelle Version von sendmail ; das oberste Verzeichnis heißt daher sendmail Wenn Sie dies hier lesen, wird es eine neuere Version von sendmail geben, was sich auch im Verzeichnisnamen widerspiegelt. Führen Sie den Befehl ls auf dem obersten Verzeichnis aus, erhalten Sie folgendes Ergebnis: 1 $ ls sendmail Build doc INSTALL libsmdb mailstats praliases sendmail cf editmap KNOWNBUGS libsmutil Makefile README smrsh contrib FAQ libmilter LICENSE makemap RELEASE_NOTES test devtools include libsm mail.local PGPKEYS rmail vacation Die meisten der Dateien und Verzeichnisse werden verwendet, um sendmail zu kompilieren. Das Skript Build benutzt das Makefile, um sendmail und seine Dienstprogramme zu kompilieren. Das Verzeichnis devtools dient zum Einstellen von Compiler-Optionen, wie in den Rezepten 1.2 bis 1.7 besprochen. Der Quellcode befindet sich in den entsprechend 1 Die meisten Ausgaben des Befehls ls in diesem Buch wurden auf einem Red Hat-Linux-System erzeugt. Andere Versionen von Unix und Linux sortieren die ls-ausgaben möglicherweise auf andere Weise. Abgesehen von der Reihenfolge sind die Dateien und Verzeichnisse jedoch identisch. 1

20 benannten Unterverzeichnissen. Beispielsweise befindet sich der sendmail-quellcode im Verzeichnis sendmail, die Bibliotheken liegen in Verzeichnissen wie libsm und libsmutil, und der Quellcode von Dienstprogrammen wie makemap und smrsh ist in den entsprechend benannten Verzeichnissen zu finden. In der Distribution gibt es außerdem mehrere wichtige Informationsquellen: Die Dateien INSTALL und README bieten die neuesten Informationen über das Kompilieren und Installieren von sendmail. Die Datei RELEASE_NOTES beschreibt die wichtigen Funktionen des neuen Release. Die Dateien KNOWNBUGS und FAQ erläutern Lösungen zu verbreiteten Problemen. Das Unterverzeichnis doc enthält den Sendmail Installation and Operations Guide, eine ausgezeichnete Informationsquelle für den sendmail-administrator. Das wichtigste all dieser wichtigen Verzeichnisse und Dateien ist (zumindest aus Sicht dieses Buches) das Verzeichnis cf, da sich in ihm die Konfigurationsdateien befinden (und dieses Buch handelt schließlich von der sendmail-konfiguration). Die Struktur des Verzeichnisses cf Die m4-quelldateien und -bibliotheken, die zum Erstellen der sendmail-konfiguration verwendet werden, befinden sich im Verzeichnis cf, das folgendermaßen aufgebaut ist: $ ls sendmail /cf cf feature m4 ostype sendmail.schema siteconfig domain hack mailer README sh Das Verzeichnis cf enthält zwei Dateien, README und sendmail.schema, sowie neun Unterverzeichnisse. Bei der Datei sendmail.schema handelt es sich um ein experimentelles LDAP-Schema, das Attributtypen und Objektklassen vordefiniert, die zusammen mit LDAP eingesetzt werden können. Das sendmail-schema wird in den meisten LDAP-Beispielen dieses Buches verwendet. Die Datei README ist eine umfassende Referenz zur Syntax und zur Verwendung all der m4-makros und Variablen, die benutzt werden, um sendmail zu konfigurieren. Die Datei README ist von unschätzbarem Wert, vor allem, wenn sie zusammen mit diesem Buch verwendet wird. Die Verzeichnisse hack, sh und siteconfig sind für die meisten Konfigurationen nicht so bedeutsam. hack Das Verzeichnis hack ist dafür gedacht, die m4-quelldateien aufzunehmen, die vom lokalen Systemadministrator erzeugt wurden, um vorübergehende Probleme mit der sendmail-konfiguration zu lösen. Es gibt im Verzeichnis hack nur eine einzige Datei, die als Beispiel für einen sendmail-hack dient, und diese ist schon einige Jahre alt. Das Verzeichnis hack und das Makro HACK gibt es immer noch, allerdings gibt es kei- Links 2 Kapitel 1: Der Einstieg

21 Rechts nen Grund, sie einzusetzen bei all den leistungsfähigen und flexiblen Mitteln, die zur Verfügung stehen, um sendmail zu konfigurieren. siteconfig Im Verzeichnis siteconfig sollen Dateien abgelegt werden, die sendmail-m4-site- Makros verwenden, um lokal angeschlossene UUCP-Sites aufzulisten. Das Verzeichnis siteconfig, das Makro SITECONFIG und das Makro SITE werden aus Gründen der Abwärtskompatibilität noch gepflegt. Allerdings sind das Verzeichnis und die Makros veraltet und sollten nicht mehr benutzt werden, um die UUCP-Konnektivität für einen UUCP-Mailserver zu definieren. sh Das Verzeichnis sh enthält nur die Datei makeinfo.sh. Die meisten der Dateien in den cf-unterverzeichnissen sind m4-makro-quelldateien, die mit der Erweiterung.m4 enden. Diese Datei endet jedoch mit der Erweiterung.sh, wodurch angezeigt wird, dass es sich um ein Shell-Skript handelt. Das Skript erzeugt drei Kommentarzeilen für die Datei sendmail.cf, die angeben, wer die Konfiguration zusammengestellt hat, wann dies geschehen ist und in welchem Verzeichnis sie erzeugt wurde. Die verbleibenden sechs Verzeichnisse bilden das eigentliche Kernstück der sendmail- Konfiguration. Vier dieser Verzeichnisse, domain, feature, ostype und mailer, tragen die gleichen Namen wie sendmail-m4-makros und stellen den Quellcode zur Verfügung, der von diesen Makros benutzt wird. Diese vier Verzeichnisse haben folgende Aufgaben: domain Das Verzeichnis domain enthält die m4-quelldateien, die die für Ihre Domain oder Ihr Netzwerk speziellen Konfigurationswerte definieren. Falls Sie solche Werte definieren müssen, legen Sie Ihre eigene Datei an; die sechs Dateien, die sich im Verzeichnis domain befinden, dienen lediglich als Beispiele. Die Konfigurationsdatei, die Sie für Ihre Umgebung erzeugen, wird dann über das Makro DOMAIN in der Hauptkonfigurationsdatei eingesetzt. ostype Die Dateien im Verzeichnis ostype definieren betriebssystemspezifische Eigenschaften für die sendmail-konfiguration. Jede Hauptkonfigurationsdatei muss ein Makro OSTYPE enthalten, um die richtige Makroquelldatei für das Betriebssystem des sendmail-servers verarbeiten zu können. 2 Im Verzeichnis sendmail /ostype befinden sich Konfigurationsdateien für mehr als 40 unterschiedliche Betriebssysteme, die jeweils leicht anhand ihrer Namen identifiziert werden können. Wählen Sie die Datei aus, die dem Betriebssystem Ihres Servers entspricht. mailer Zusätzlich zu einem Makro OSTYPE enthalten die meisten Hauptkonfigurationsdateien wenigstens ein Makro MAILER. MAILER-Makros verarbeiten Quelldateien aus 2 Rezept zeigt einen Trick, der verwendet wird, um eine Konfiguration anzulegen, ohne dass ein OSTYPE- Makro benutzt wird. Allerdings wird dieser Trick nicht für den allgemeinen Einsatz empfohlen. Einführung 3

22 dem Verzeichnis mailer. Jede Datei im Verzeichnis mailer enthält die Definition eines Satzes von Mailern. Im aktuellen mailer-verzeichnis befinden sich 12 unterschiedliche Dateien. Viele Konfigurationen verwenden nur die zwei grundlegendsten Mailer- Sätze: local.m4 für die lokale Mail-Auslieferung und smtp.m4 für SMTP-Mail-Auslieferung. feature Das Verzeichnis feature enthält die m4-quellcodedateien, die verschiedene sendmail-funktionen implementieren. Es stehen in diesem Verzeichnis mehr als 40 Feature-Dateien zur Verfügung. Die Funktionen werden verwendet, um bestimmten Konfigurationsproblemen zu begegnen. Die beiden verbleibenden Verzeichnisse, cf und m4, enthalten die Hauptkonfigurationsdateien und die Makro-Quellbibliotheken, die durch m4 benutzt werden. Die vier oben beschriebenen Verzeichnisse enthalten Dateien, die innerhalb der sendmail-konfiguration durch m4-makros aufgerufen werden. In den Verzeichnissen cf/cf und cf/m4 befinden sich m4-quelldateien, die normalerweise auf der m4-kommandozeile aufgerufen werden. Links Das Verzeichnis cf/m4 Das Verzeichnis cf/m4 enthält die m4-makrodefinitionen und das sendmail.cf-codegerüst, das benötigt wird, um eine sendmail.cf-konfigurationsdatei zu erstellen. Denken Sie daran, dass es sich bei m4 um eine allgemein einsetzbare Makrosprache handelt; es ist keine Sprache, die speziell dem Zweck dient, sendmail-konfigurationen zu erzeugen. sendmail-konfigurationen werden mit Hilfe von Makros erstellt, die durch die sendmail- Entwickler definiert werden. Das Verzeichnis cf/m4 enthält die vier Dateien, die diese Makrobefehle definieren: version.m4 Die Datei version.m4 definiert die Variable Z der sendmail.cf, der die sendmail-versionsnummer zugeordnet wird. Da sich dieser Wert mit jedem sendmail-release ändert, wird er aus Gründen der einfacheren Wartung in einer eigenen Datei definiert. 3 cf.m4 Die Datei cf.m4 wird auf der m4-kommandozeile angegeben, um die Bibliothek der sendmail-m4-makrobefehle in den m4-prozess einzubinden. Die Datei cf.m4 verweist auf die Datei cfhead.m4, die wiederum die Makrodefinitionen enthält. 3 Die sendmail-versionsnummer ist nicht identisch mit dem sendmail.cf-versionslevel. In unseren Beispielen ist die sendmail-versionsnummer , der sendmail.cf-versionslevel dagegen ist 10. Darüber hinaus hat keines von beiden mit dem m4-makro VERSIONID zu tun, das verwendet wird, um Informationen zur Versionskontrolle in der Hauptkonfigurationsdatei abzulegen. 4 Kapitel 1: Der Einstieg

23 Rechts cfhead.m4 Die Datei cfhead.m4 definiert die m4-makros, die verwendet werden, um sendmail zu konfigurieren. Diese Datei enthält eine Menge Zeug. Am wichtigsten ist dabei die Definition vieler der Befehle, mit denen man eine Konfiguration erstellt. proto.m4 Die Datei proto.m4 ist die Quelle der meisten Dinge, die in der Datei sendmail.cf zu finden sind. Das Unterverzeichnis cf Das Verzeichnis cf/cf ist das Arbeitsverzeichnis der sendmail-konfiguration. Es enthält alle Hauptkonfigurationsdateien. Hier legen Sie außerdem Ihre eigenen Hauptkonfigurationsdateien ab, wenn Sie selbst eine Konfiguration zusammenstellen. In dem Verzeichnis befinden sich mehr als 40 Dateien. $ ls sendmail /cf/cf Build generic-hpux10.cf generic-solaris.cf python.cs.mc chez.cs.mc generic-hpux10.mc generic-solaris.mc README clientproto.mc generic-hpux9.cf generic-sunos4.1.cf s2k-osf1.mc cs-hpux10.mc generic-hpux9.mc generic-sunos4.1.mc s2k-ultrix4.mc cs-hpux9.mc generic-linux.cf generic-ultrix4.cf submit.cf cs-osf1.mc generic-linux.mc generic-ultrix4.mc submit.mc cs-solaris2.mc generic-mpeix.cf huginn.cs.mc tcpproto.mc cs-sunos4.1.mc generic-mpeix.mc knecht.mc ucbarpa.mc cs-ultrix4.mc generic-nextstep3.3.cf mail.cs.mc ucbvax.mc cyrusproto.mc generic-nextstep3.3.mc mail.eecs.mc uucpproto.mc generic-bsd4.4.cf generic-osf1.cf mailspool.cs.mc vangogh.cs.mc generic-bsd4.4.mc generic-osf1.mc Makefile Die meisten dieser Dateien mehr als 30 von ihnen sind Beispiele für Hauptkonfigurationsdateien. Sie erkennen eine Hauptkonfigurationsdatei an der Erweiterung.mc. Manche sollen als Lehrwerkzeuge dienen, die meisten jedoch sind Prototypen oder generische Dateien, die als Grundlage Ihrer eigenen Konfiguration verwendet werden können. Die generischen Dateien, die für bestimmte Betriebssysteme etwa Solaris, HPUX, BSD, Linux und andere gedacht sind, sind besonders interessant. Wir benutzen die Datei generic-linux.mc in Rezept 1.8. Einige der Dateien weisen die Erweiterung.cf auf. Diese Dateien sind Ergebnisse der Verarbeitung der Hauptkonfigurationsdateien durch m4; sie liegen bereits im richtigen Format vor, um als Datei sendmail.cf eingesetzt zu werden. Es ist indes unwahrscheinlich, dass Sie eine dieser Dateien direkt benutzen. Die sendmail-konfigurationsdatei, die mit Hilfe dieser.mc-datei erzeugt wird, entspricht mit Sicherheit nicht dem, was Sie sich vorstellen, es sei denn, die generische Hauptkonfigurationsdatei entspricht genau Ihren Vorstellungen. Wir beginnen in Rezept 1.8 mit einer generischen Konfiguration, allerdings verändern die nachfolgenden Rezepte in diesem Buch diese generische Konfiguration, um die angepassten Konfigurationen zu erzeugen, die wir benötigen. Einführung 5

24 1.1 Die neueste Version herunterladen Links Problem Sie müssen Ihre sendmail-software auf dem neuesten Stand halten. Lösung Am einfachsten aktualisieren Sie sendmail, wenn Sie bei der auf Ihrem System eingesetzten Methode zur Softwareverwaltung bleiben. Benutzen Sie einen Paketmanager, dann begeben Sie sich zur Website Ihres Unix-Herstellers und laden von dort das entsprechend angebotene sendmail-update herunter. Kann der Hersteller nicht das entscheidende sendmail-update bereitstellen oder hat er nicht die Funktionen in das Paket integriert, die Sie benötigen, und Sie beschließen, die sendmail-quellcodedistribution zu verwenden, dann wechseln Sie vom Paketmanager zur Quellcodedistribution, indem Sie die Hinweise des Unix-Herstellers befolgen, wie Sie ein Paket entfernen können, das durch den Paketmanager installiert wurde. In der Diskussion sehen Sie an einem Beispiel, wie mit dem Red Hat Package Manager das sendmail-rpm gelöscht wird, bevor die sendmail-quellcodedistribution installiert wird. Müssen Sie die sendmail-quellcodedistribution verwenden, dann laden Sie die neueste Version von sendmail von ftp://ftp.sendmail.org/, von oder von einer der vielen gespiegelten Sites herunter. Einen Verweis auf die gespiegelten Sites finden Sie auf der sendmail-homepage In der Diskussion wird an einem Beispiel gezeigt, wie Sie die sendmail-quellcodedistribution per ftp herunterladen können. Holen Sie die Signatur-Datei, die mit der von Ihnen heruntergeladenen Version von sendmail verknüpft ist. Beispielsweise ist die Signatur-Datei für die tar-datei sendmail tar.gz, die in der Diskussion zum Einsatz kommt, sendmail tar.gz.sig. Laden Sie die PGP-Schlüssel herunter, die benötigt werden, um die Signatur zu verifizieren, und fügen Sie sie Ihrem Schlüsselbund hinzu (Sie müssen dies nur ungefähr einmal im Jahr erledigen). Nachdem die PGP-Schlüssel Ihrem Schlüsselbund hinzugefügt worden sind, können sie benutzt werden, um die Signatur-Datei aller weiteren Downloads zu verifizieren, die Sie während dieses Kalenderjahrs durchführen. Benutzen Sie die Programme pgp oder gpg, um die Signatur der heruntergeladenen Datei zu verifizieren (die Diskussion zeigt ein Beispiel mit gpg). Wenn Sie die Signatur akzeptieren, stellen Sie die tar-datei der sendmail-distribution wieder her. Diskussion sendmail ändert sich häufig. Als der erste Entwurf dieses Kapitels geschrieben wurde, war die neueste Version von sendmail ungefähr drei Wochen alt. Die vorhergehende Ver- 6 Kapitel 1: Der Einstieg

25 Rechts sion war nur 11 Wochen alt! Bedeutet das nun, dass Sie sendmail alle paar Monate aktualisieren müssen? Nicht unbedingt. Allerdings sollten Sie sich über neue sendmail- Versionen auf dem Laufenden halten, um festzustellen, wann eine Aktualisierung für Sie wichtig ist. Hier sind drei Gründe, die Systemadministratoren zu einer Aktualisierung bewegen könnten: Sicherheit sendmail stellt ein beliebtes Ziel für Eindringlinge in ein Netzwerk dar. Sie greifen sendmail an, weil es ein großes, komplexes Programm ist, das auf vielen Systemen läuft; sendmail wird sogar auf Desktop-Workstations ausgeführt, bei denen die Systemadministration alles andere als ausreichend ist. Die Schwächen, die bei solchen Angriffen zu Tage treten, werden in neuen sendmail-versionen schnell behoben. Informieren Sie sich, indem Sie die Mailingliste sendmail-announce abonnieren, um Hinweise auf neue sendmail-versionen zu empfangen, und schauen Sie regelmäßig auf der Website vorbei. Es ist wichtig, auf eine neue sendmail-version umzusteigen, wenn diese Version ein Sicherheitsproblem behebt. Spammer Angriffe auf die Sicherheit gehen normalerweise mit nichtautorisiertem Zugriff oder dem Lahmlegen eines Dienstes (Denial of Service) einher. Ein ähnliches Problem ist die nichtautorisierte Benutzung und der Diebstahl eines Dienstes, der auftritt, wenn ein Spammer Ihr -System missbraucht. Aktuelle sendmail-versionen verhindern den -Missbrauch viel besser als alte Versionen. Halten Sie Ausschau nach neuen Versionen, die Anti-Spam-Maßnahmen unterstützen. Wenn es Ihnen gelingt, Spam zu verringern, wird die Welt es Ihnen danken. Neue Funktionen und Eigenschaften Anti-Spam-Funktionen sind nicht die einzigen neuen Funktionen, die neue sendmail- Versionen ergänzen. Manchmal entdecken Sie eine neue Funktion, die wichtig genug ist, um eine Aktualisierung zu rechtfertigen. Beispielsweise bietet sendmail 8.11 nun Unterstützung für Transport Layer Security (TLS), was für Ihre Organisation von Bedeutung sein könnte. Von diesen drei Gründen für eine Aktualisierung ist die Sicherheit am wichtigsten. Wenn Ihnen ein Sicherheitsproblem bekannt ist, dann können Sie davon ausgehen, dass die bösen Buben es ebenfalls kennen und sich nach Kräften bemühen, es auszunutzen. Schließen Sie Sicherheitslücken so schnell wie möglich. Kapitel 10 zeigt Ihnen, wie Sie Sicherheitslücken in sendmail stopfen können. Sobald Sie beschlossen haben, die sendmail-software zu aktualisieren, müssen Sie festlegen, wie Sie vorgehen wollen. Am einfachsten ist es, das Werkzeug zur Software-Verwaltung zu benutzen, das in Ihrer Unix-Version zur Verfügung steht. Ein klassisches Beispiel für ein solches Werkzeug ist der RPM Package Manager (RPM), der von Red Hat entwickelt wurde und in vielen unterschiedlichen Linux-Distributionen eingesetzt wird. Werkzeuge wie RPM installieren Software-Pakete, die bereits für eine bestimmte Unix- Variante vorbereitet wurden, platzieren die Dateien in die richtigen Verzeichnisse und 1.1 Die neueste Version herunterladen 7

26 entbinden den Administrator von der Last, die Software kompilieren zu müssen. Diese Werkzeuge bieten außerdem Sicherheitsfunktionen, wie etwa die Option --verify des Befehls rpm, die während und nach der Installation prüft, ob an Software und Dateien herumgepfuscht wurde. Wenn Sie auf eine neue Version von sendmail umsteigen wollen, schauen Sie auf der Website Ihres Unix-Herstellers, ob diese Version in deren Paketformat vorliegt. 4 Trotz der Vorteile von Werkzeugen zur Software-Verwaltung müssen Sie manchmal Ihre eigene Software kompilieren, um besondere Funktionen zu aktivieren. Manchmal gibt es auch die neueste Version der Software nicht in einem Paketformat. Falls Sie auf einem System, auf dem die vorherige sendmail-installation durch einen Paketmanager erledigt wurde, auf die sendmail-tar-datei wechseln müssen, dann sichern Sie die aktuelle Konfiguration und deinstallieren anschließend die aktuelle Version von sendmail mit Hilfe des Paketmanagers, bevor Sie mit der Aktualisierung beginnen. Das Beispiel zeigt, wie Sie sendmail mittels RPM deinstallieren: # service sendmail stop Shutting down sendmail: [ OK ] # rpm -qa grep sendmail sendmail sendmail-cf sendmail-devel # rpm --erase sendmail-devel # rpm --erase sendmail-cf # rpm --erase --nodeps sendmail warning: /etc/mail/statistics saved as /etc/mail/statistics.rpmsave Dieses Beispiel stammt von einem Red Hat 7.3-System. Fahren Sie zuerst den aktuellen sendmail-daemon herunter. Benutzen Sie anschließend rpm -qa, um herauszufinden, welche sendmail-rpm-pakete installiert sind, sowie rpm --erase, um die einzelnen Pakete zu löschen. Beachten Sie, dass die Option --nodeps zusammen mit dem letzten rpm-befehl verwendet wird. Die Option --nodeps zwingt rpm, das Paket zu löschen, selbst wenn dadurch die Abhängigkeiten zu anderen Paketen verletzt werden. Das Entfernen des sendmail-daemons, was durch den letzten rpm-befehl geschieht, stört andere Pakete, die vom sendmail-daemon abhängen. Nach der Installation des neuen sendmail-daemons sollten diese Pakete wieder funktionieren. Der negative Einfluss auf die Abhängigkeiten, der durch den Wechsel von einer RPM-basierten Installation auf eine Installation aus einer tar-datei verursacht wird, ist einer der Gründe, weshalb Sie nach Möglichkeit immer versuchen sollten, eine RPM-Installation durch eine andere RPM-Installation zu ersetzen. Führen Sie diese Schritte aus, um das momentan installierte sendmail zu löschen, nachdem Sie die neue Version von sendmail erfolgreich kompiliert haben und bevor Sie die neu erzeugten sendmail-binaries installieren. Dieser Deinstallationsschritt ist erforder- 4 Falls Sie RPM verwenden, kann die Website rpmfind.net Ihnen bei der Suche nach RPM-kompatiblen Paketen helfen. Links 8 Kapitel 1: Der Einstieg

27 Rechts lich, um zu verhindern, dass der Paketmanager fälschlicherweise Fehler meldet, wenn er die Software auf mögliche Manipulationen prüft. Vorsicht ist ebenfalls geboten, wenn Sie das sendmail-paket eines Herstellers auf einem System installieren, auf dem es bereits eine eigene sendmail-konfiguration gibt. Wie die Rezepte 1.2 bis 1.7 zeigen, kann sendmail mit besonderen Optionen kompiliert werden. Vielleicht bietet jedoch der Hersteller nicht die Optionen, die Sie benötigen, und das Herstellerpaket überschreibt das speziell kompilierte sendmail-binary. Schlussfolgerung: Passen Sie auf, wenn Sie von einer Installationstechnik zu einer anderen wechseln. Falls Sie Ihre Installationstechnik nicht ändern und keinen Paketmanager verwenden, müssen Sie sich um die genannten Punkte vor der Installation der sendmail-quellcodedistribution keine Gedanken machen führen Sie einfach die Schritte aus, die im Folgenden besprochen werden. Beginnen Sie damit, dass Sie die sendmail-quellcodedistribution von sendmail.org/current-release.html, von einer der gespiegelten Sites oder von ftp://ftp. sendmail.org/pub/sendmail/ herunterladen. Hier ist ein Beispiel für ftp: $ ftp ftp.sendmail.org Connected to ftp.sendmail.org ( ). 220 services.sendmail.org FTP server (Version 6.00LS) ready. Name (ftp.sendmail.org:alana): anonymous 331 Guest login ok, send your address as password. Password: alana@rodent.wrotethebook.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 tar.gz local: sendmail tar.gz remote: sendmail tar.gz 227 Entering Passive Mode (209,246,26,22,207,236) 150 Opening BINARY mode data connection for 'sendmail tar.gz' ( bytes). 226 Transfer complete bytes received in 10.1 secs (1.8e+02 Kbytes/sec) Die neue Version wird als komprimierte tar-datei unter dem Namen sendmail.release. tar.gz für die Nutzer von gzip bzw. als sendmail.release.tar.z für die von compress im Verzeichnis pub/sendmail gespeichert. In jedem Fall ist release die aktuelle numerische Versionsnummer. Beispielsweise lautet die Versionsnummer zum Zeitpunkt der Entstehung des Buches , die gezippte tar-datei heißt daher sendmail tar.gz, und die komprimierte tar-datei heißt sendmail tar.z. Holen Sie als Nächstes die Signatur-Datei, die mit der von Ihnen heruntergeladenen sendmail-version verknüpft ist. Die Signatur-Datei für sendmail tar.gz ist beispielsweise sendmail tar.gz.sig. Hier laden wir sie während der gleichen ftp-sitzung herunter: ftp> get sendmail tar.gz.sig local: sendmail tar.gz.sig remote: sendmail tar.gz.sig 1.1 Die neueste Version herunterladen 9

28 227 Entering Passive Mode (209,246,26,22,207,238) 150 Opening BINARY mode data connection for 'sendmail tar.gz.sig' (152 bytes). 226 Transfer complete. 152 bytes received in secs (67 Kbytes/sec) Falls Sie die aktuellen sendmail-pgp-schlüssel nicht an Ihrem Schlüsselbund haben, laden Sie die PGP-Schlüssel herunter, die erforderlich sind, um die Signatur zu verifizieren. Wir führen hier in der ftp-sitzung den folgenden Schritt 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,207,239) 150 Opening BINARY mode data connection for 'PGPKEYS' (57704 bytes). 226 Transfer complete bytes received in secs (1.1e+02 Kbytes/sec) ftp> quit 221 Goodbye. Fügen Sie die PGP-Schlüssel in Ihr Schlüsselbund ein. Im folgenden Beispiel wird gpg (Gnu Privacy Guard) verwendet: $ gpg --import PGPKEYS gpg: key 16F4CCE9: not changed gpg: key 396F0789: public key imported 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: 11 gpg: imported: 1 (RSA: 1) gpg: unchanged: 10 gpg kommt in diesem Beispiel zum Einsatz, weil es Teil der Red Hat Linux-Distribution ist, die wir in unserem Beispiel-sendmail-System benutzen. Von den 11 exportierbaren Schlüsseln in der Datei PGPKEYS ist nur einer für unseren Schlüsselbund wichtig. Der Kommentar not changed für die anderen 10 Schlüssel zeigt, dass diese bereits in dem Schlüsselbund installiert waren. Wenn Sie PGPKEYS das erste Mal importieren, werden alle 11 Schlüssel dem Schlüsselbund hinzugefügt. Bevor Sie den neuen Schlüssel benutzen, verifizieren Sie seinen Fingerprint, wie hier gezeigt: $ gpg --fingerprint 396F0789 pub 1024R/396F Sendmail Signing Key/2003 <sendmail@sendmail.org> Key fingerprint = C4 73 DF 4A 97 9C 27 A9 EE 4F B2 BD 55 B5 E0 0F Links 10 Kapitel 1: Der Einstieg

29 Rechts Vergleichen Sie den dargestellten Fingerprint mit Tabelle 1-1, die die Fingerprints der signierenden Schlüssel von sendmail zeigt. Tabelle 1-1: Fingerprints der signierenden Schlüssel von sendmail Jahr Ist der Fingerprint korrekt, 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 396F0789 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=0 ot(-/q/n/m/f/u)=0/0/0/0/0/1 pub 1024R/396F0789 created: expires: never trust: -/- (1). Sendmail Signing Key/2003 <sendmail@sendmail.org> Command> sign Fingerprint 1997 CA AE F2 94 3B 1D 41 3C 94 7B 72 5F AE 0B 6A F A1 3B 3A B6 DE B2 98 6A 70 AF 54 9D C 8E 94 B1 E8 EA EA 9B A4 D C C 58 EA 7A 9D 7C 1B AC 5E EB D AF DC 3E A2 7D FA D 7E C B 02 F4 AA FC C0 22 DA 47 3E 2A 9A 9B C4 73 DF 4A 97 9C 27 A9 EE 4F B2 BD 55 B5 E0 0F FE B1 3E A BB 78 C1 D4 pub 1024R/396F0789 created: expires: never trust: -/- Fingerprint: C4 73 DF 4A 97 9C 27 A9 EE 4F B2 BD 55 B5 E0 0F Sendmail Signing Key/2003 <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: "Craig Hunt <craig.hunt@wrotethebook.com>" I have checked this key very carefully. Really sign? y 1.1 Die neueste Version herunterladen 11

30 You need a passphrase to unlock the secret key for user: "Craig Hunt <craig.hunt@wrotethebook.com>" 1024-bit DSA key, ID 34C9B515, created Links Command> quit Save changes? y Merken Sie sich, dass es nicht notwendig ist, die Datei PGPKEYS jedes Mal herunterzuladen und zu importieren, wenn Sie eine neue sendmail-version herunterladen. Neue Schlüssel werden nur ungefähr einmal pro Jahr der Datei PGPKEYS hinzugefügt. Nachdem die sendmail-schlüssel zum Schlüsselbund hinzugefügt und signiert worden sind, können Sie die tar-datei der sendmail-distribution prüfen. Wir verwenden hier die Signatur-Datei sendmail tar.gz.sig, um die komprimierte tar-datei sendmail tar.gz zu verifizieren: 5 $ gpg --verify sendmail tar.gz.sig sendmail tar.gz gpg: Signature made Sat 29 Mar :12:38 AM EST using RSA key ID 396F0789 gpg: Good signature from "Sendmail Signing Key/2003 <sendmail@sendmail.org>" 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=0 ot(-/q/n/m/f/u)=1/0/0/0/0/0 Auf dieser Grundlage kann die Distribution sicher wiederhergestellt, kompiliert und installiert werden. Verwenden Sie tar, um die tar-datei wiederherzustellen. Die tar-datei erzeugt ein Verzeichnis, dessen Name aus der sendmail-versionsnummer abgeleitet ist. Die folgenden Befehle legen daher ein Verzeichnis namens sendmail in /usr/local/src an: # cd /usr/local/src # tar -zxvf /home/craig/sendmail tar.gz Der Pfad /usr/local/src/sendmail wird durchgängig in diesem Buch verwendet. Passen Sie diesen Pfad entsprechend an Ihr System an, wenn Sie die Rezepte umsetzen. Siehe auch Rezept 10.4 zeigt ein ausführliches Beispiel für das Herunterladen und Installieren von sendmail-patches, die manchmal als Alternative zum Herunterladen einer kompletten Distribution dienen. sendmail, dritte Auflage, von Bryan Costales zusammen mit Eric Allman (O Reilly), behandelt in Abschnitt 2.2 das Herunterladen der sendmail-quelldistribution. PGP: Pretty Good Privacy, von Simson Garfinkel (O Reilly), ist ein ganzes Buch nur über PGP. Das GNU Privacy Handbook (GPH), das unter documentation/guides.html zur Verfügung steht, bietet ausführliche Informationen über GPG. 5 In diesem Beispiel wird die Signatur dazu eingesetzt, die mit gzip komprimierte tar-datei zu überprüfen. Mit Version wurde damit begonnen, komprimierte Dateien zu signieren. Bei früheren Versionen von sendmail wurde die unkomprimierte tar-datei signiert. In diesen Fällen wurde die tar-datei zuerst dekomprimiert und dann überprüft. 12 Kapitel 1: Der Einstieg

31 Rechts 1.2 sendmail installieren Problem Die sendmail-tar-datei ist eine Quellcodedistribution. Der enthaltene Quellcode muss kompiliert werden. Außerdem könnte es sich als notwendig erweisen, eine besondere Benutzer-ID und eine Gruppen-ID anzulegen, bevor die neue sendmail-software installiert und verwendet werden kann. Lösung Kompilieren Sie sendmail mit Hilfe des Dienstprogramms Build, das von den sendmail- Entwicklern bereitgestellt wird. Auf den meisten Systemen werden nur wenige Befehle benötigt, um sendmail zu kompilieren: # cd sendmail #./Build Der nächste Installationsschritt besteht darin, den Benutzer und die Gruppe smmsp für sendmail anzulegen, die zum Einsatz kommen, wenn es als Mail-Submissionsprogramm ausgeführt wird. Benutzen Sie dazu die auf Ihrem System üblichen Werkzeuge. Hier werden die Einträge in /etc/passwd und /etc/group dem Red-Hat-System hinzugefügt, das in diesem Buch als Beispiel verwendet wird: # grep smmsp /etc/passwd smmsp:x:25:25:mail Submission:/var/spool/clientmqueue:/sbin/nologin # grep smmsp /etc/group smmsp:x:25: Sichern Sie als Nächstes das aktuelle sendmail-binary, die sendmail-dienstprogramme und die aktuellen sendmail-konfigurationsdateien. Nach dem Sichern des Systems installieren Sie das neue sendmail und seine Dienstprogramme: #./Build install Diskussion Build ermittelt die Architektur des Systems und erstellt ein Makefile, das an dieses System angepasst ist. Es verwendet dann make, um sendmail zu kompilieren. Build ist ausgezeichnet darin, die Systemarchitektur korrekt zu erkennen. Ein einfacher Build-Befehl sollte in den meisten Situationen funktionieren. Ist das bei Ihnen nicht der Fall, entweder weil Sie besondere Hard- und Software einsetzen, oder weil Sie besondere Anforderungen stellen, dann legen Sie eine eigene Konfiguration an, die Build benutzen kann. sendmail bezeichnet diese eigenen Konfigurationen als Site- Konfigurationen und sucht im Verzeichnis devtools/site nach ihnen. Dort erwartet es auch 1.2 sendmail installieren 13

32 die lokale eigene Konfiguration unter dem Namen site.config.m4 vorzufinden. Standardmäßig sucht Build nach Dateien mit dem Namen site.os.m4, wobei OS der Name des Betriebssystems des Computers ist, sowie nach site.config.m4 und site.post.m4. Benutzen Sie einen anderen Dateinamen, dann setzen Sie das Argument -f auf der Build-Kommandozeile ein, um die Datei zu identifizieren. 6 Zum Beispiel: $./Build -f ourconfig.m4 Wie die Dateierweiterung.m4 vermuten lässt, wird die Build-Konfiguration mit m4- Befehlen erzeugt. Drei Befehle werden benutzt, um die von Build eingesetzten Variablen zu definieren. Diese Befehle sind: define Der Befehl define ist ein integrierter m4-befehl. Wenn er verwendet wird, dann wird der aktuelle Wert, der in der Variablen gespeichert ist, durch den neuen Wert ersetzt. APPENDDEF Das Makro APPENDDEF ist ein m4-makro, das benutzt wird, um einen Wert an eine existierende Liste von Werten anzuhängen, die in einer Variablen gespeichert sind. Es ersetzt nicht den aktuellen Wert in der Variablen; es fügt Werte an das Ende einer Liste von Werten an. PREPENDDEF Das Makro PREPENDDEF ist ein m4-makro, das benutzt wird, um einer existierenden Liste von Werten, die in einer Variablen gespeichert sind, einen Wert voranzustellen. Es ersetzt nicht den aktuellen Wert der Variablen; es fügt Werte am Anfang einer Liste von Werten hinzu. Hier ein Beispiel für einen Fall, in dem eine site.config.m4-datei benötigt werden könnte. Während die sendmail-software auf unserem Beispiel-Red-Hat-System fehlerlos kompiliert, bemerken wir ein Problem beim Installieren der Manpages. Die Datei devtools/os/ Linux in sendmail enthält den folgenden Befehl, der die Manpages in /usr/man ablegt: define(`confmanroot', `/usr/man/man') Unser Beispielsystem speichert die Manpages in /usr/share/man. Deshalb erzeugen wir die folgende devtools/site/site.config.m4-datei, um den Manpage-Pfad auf /usr/share/ man zu setzen: $ cat devtools/site/site.config.m4 define(`confmanroot', `/usr/share/man/man') m4-geschützte Strings werden in einfache ungleiche Anführungszeichen eingeschlossen. Diese einfachen ungleichen Anführungszeichen, die bei allen m4-befehlen zum Einsatz kommen, werden auch in der Datei site.config.m4 benutzt. 6 Falls Sie Änderungen an der Datei siteconfig.m4 vornehmen und Build erneut ausführen, müssen Sie das Kommandozeilenargument -c verwenden, um Build von den Änderungen in Kenntnis zu setzen. Links 14 Kapitel 1: Der Einstieg

33 Rechts Die meisten eigenen Build-Konfigurationen sind nicht komplizierter als dieses Beispiel. Die nächsten Rezepte zeigen weitere Beispiele für Build-Konfigurationen. Diese Beispiele wurden gewählt, weil die Optionen, die durch sie in sendmail kompiliert werden, in anderen Rezepten weiter hinten in diesem Buch erforderlich sind. Es gibt jedoch mehr als 100 Variablen, die für die Build-Konfiguration gesetzt werden können viel zu viele, um sie in einzelnen Rezepten abzuhandeln. In der Datei devtools/readme finden Sie eine vollständige Liste. Es war immer notwendig, sendmail vor der Installation zu kompilieren. Mit sendmail 8.12 tauchte in der Installationsprozedur ein neuer Schritt auf. sendmail 8.12 erwartet, eine Benutzer-ID und eine Gruppen-ID namens smmsp vorzufinden. Falls diese beiden IDs auf Ihrem System nicht existieren, legen Sie sie an, bevor Sie sendmail installieren, da das sendmail-binary nicht mehr als set-user-id root installiert wird. Traditionell war das sendmail-binary auf set-user-id root gesetzt, so dass jeder Benutzer Mail über die Kommandozeile absetzen und sie damit in das Warteschlangenverzeichnis schreiben konnte. Das erfordert allerdings nicht unbedingt ein Binary mit set-user-id root. Wenn die Verzeichnisrechte richtig gesetzt sind, funktioniert ein set-group-id-binary ganz hervorragend. Bevor Sie das frisch kompilierte sendmail installieren, legen Sie eine Sicherungskopie des aktuellen sendmail-programms, der sendmail-dienstprogramme und Ihrer aktuellen sendmail-konfigurationsdateien an. (Sie können nie wissen; möglicherweise müssen Sie wieder zurück zur alten sendmail-konfiguration wechseln, falls die neue nicht wie erwartet funktioniert.) Denken Sie daran: Wurde die vorherige Version von sendmail mit einem Paketmanager installiert, dann sollte sie mit Hilfe dieses Paketmanagers entfernt werden, bevor die neue sendmail-software installiert wird. Der Befehl Build install auf dem Beispiel-Red-Hat-System installiert sendmail und seine Dienstprogramme und erzeugt mehr als 100 Zeilen an Ausgaben. Er sollte ohne Fehler ausgeführt werden. Auf unserem Beispielsystem zeigen die install-befehle, die die Manpages platzieren, klar den Pfad, der zuvor in der Datei devtools/site/site.config.m4 definiert wurde. Beachten Sie außerdem, dass Build die Benutzer- und Gruppen-ID smmsp verwendet, wenn es das Verzeichnis clientmqueue anlegt und das sendmail-binary installiert. Eine schnelle Überprüfung der Eigentümerschaft und der Berechtigungen für das Warteschlangenverzeichnis und das sendmail-programm zeigt Folgendes: drwxrwx--- 2 smmsp smmsp 4096 Aug 7 16:22 clientmqueue -r-xr-sr-x 1 root smmsp Aug 7 16:51 /usr/sbin/sendmail Nach der Installation muss sendmail konfiguriert werden. Der größte Teil dieses Buches handelt davon, wie Sie sendmail so konfigurieren, dass es das tut, was Sie von ihm wollen. Siehe auch Das Buch sendmail behandelt in Kapitel 2 die Kompilierung und die Installation von sendmail. 1.2 sendmail installieren 15

34 1.3 sendmail für die Benutzung von LDAP kompilieren Links Problem sendmail muss mit den richtigen Optionen kompiliert werden, um Daten von einem LDAP-Server lesen zu können. Auch der LDAP-Server muss entsprechend konfiguriert sein, um die Anfragen von sendmail zu verstehen. Lösung Benutzen Sie den Befehl sendmail -bt -d0.1, um die sendmail-compiler-optionen zu prüfen. Taucht der String LDAPMAP in der Liste»Compiled with:«auf, dann ist es nicht notwendig, sendmail neu zu kompilieren. Steht LDAPMAP dagegen nicht in der Liste»Compiled with:«, dann kompilieren Sie sendmail neu, um LDAP-Unterstützung zu aktivieren. Um LDAP-Unterstützung hinzuzufügen, setzen Sie die LDAP-Werte in der Datei site. config.m4 und kompilieren sendmail dann erneut, wie unten gezeigt wird: # cd /usr/local/src/sendmail /devtools/site # cat >> site.config.m4 APPENDDEF(`confMAPDEF', `-DLDAPMAP') APPENDDEF(`confLIBS', `-lldap -llber') Ctrl-D # cd /usr/local/src/sendmail #./Build -c Nach dem Neukompilieren installieren Sie es noch einmal: #./Build install Der LDAP-Server muss ebenfalls so konfiguriert werden, dass er mit sendmail zusammenarbeitet. Geben Sie dem LDAP-Administrator eine Kopie der Datei sendmail.schema, die Sie im Verzeichnis cf der sendmail-distribution finden. Der LDAP-Administrator muss die Datei sendmail.schema im entsprechenden Verzeichnis auf dem LDAP-Server ablegen. Beispielsweise speichert ein LDAP-Server, der OpenLDAP ausführt, Schema- Dateien oft im Verzeichnis /etc/openldap/schema. Als Nächstes muss der LDAP-Administrator die Datei sendmail.schema der LDAP-Konfiguration hinzufügen. Auf einem System mit OpenLDAP schreiben Sie folgende include- Zeile in die Datei /etc/openldap/slapd.conf: include /etc/openldap/schema/sendmail.schema Starten Sie LDAP auf dem LDAP-Server neu, um sicherzustellen, dass das sendmail- Schema in die LDAP-Konfiguration aufgenommen wird. Hier ein Beispiel von einem LDAP-Server, der OpenLDAP ausführt: # ps -ax grep slapd 1426? S 0:00 /usr/sbin/slapd -u ldap # kill -TERM 1426 # /usr/sbin/slapd -u ldap 16 Kapitel 1: Der Einstieg

35 Rechts Diskussion In diesem Rezept werden zwei APPENDDEF-Befehle in die Datei site.config.m4 aufgenommen. Der erste APPENDDEF-Befehle fügt -DLDAPMAP der Liste der unterstützten Datenbanktypen hinzu, die in der confmapdef-definition gespeichert sind. Der zweite APPENDDEF- Befehl fügt -lldap und -llber der Liste der Bibliotheken hinzu, die in der conflibs-definition gespeichert sind. -llber ist erforderlich, weil dieses System OpenLDAP benutzt. Anschließend wird sendmail mit Build neu kompiliert. Die Option -c auf der Build-Kommandozeile ist erforderlich, um sicherzustellen, dass Build die Änderungen erkennt, die an der Datei site.config.m4 vorgenommen wurden. Nach dem erneuten Kompilieren wird sendmail neu installiert. Wenn Sie sendmail nun mit der Option -d0.1 ausführen, werden Sie sehen, dass LDAPMAP in der Liste»Compiled with:«auftaucht. sendmail kann jetzt für die Benutzung mit LDAP konfiguriert werden. Selbstverständlich bedeutet dies nicht, dass auch LDAP bereits mit sendmail arbeiten kann. Die sendmail-distribution wird mit einem Schema geliefert, das für den Einsatz mit LDAP vorgesehen ist. Der LDAP-Server muss nun so konfiguriert werden, dass er dieses Schema aufnimmt, um Anfragen von sendmail zu verstehen und korrekt zu verarbeiten. Für OpenLDAP geschieht dies, indem ein include-befehl in die Datei slapd.conf aufgenommen wird, der auf das sendmail-schema verweist, wie im Lösungsabschnitt demonstriert wurde. Sobald dies erledigt wurde, funktioniert LDAP mit dem Standard-Schema von sendmail. Siehe auch Die Rezepte 1.2 und 1.4 bis 1.7 zeigen weitere Beispiele für das Kompilieren von sendmail. In anderen Rezepten dieses Buches finden Sie besondere Beispiele für das Lesen von sendmail-daten von einem LDAP-Server. Informationen über LDAP finden Sie in den Büchern Understanding and Deploying LDAP Directory Services von Howes, Smith und Good (Macmillan) sowie LDAP System Administration von Gerald Carter (O Reilly). Die Datei cf/readme behandelt dieses Thema im Abschnitt Using LDAP for Aliases, Maps, and Classes. Das Buch sendmail behandelt die Kompilierung von sendmail in Abschnitt Den Datenbanktyp regex zu sendmail hinzufügen Problem Wird beim Ausführen von sendmail die Fehlermeldung»class regex not available«ausgegeben, dann muss sendmail mit Unterstützung für den Datenbanktyp regex kompiliert werden. 1.4 Den Datenbanktyp regex zu sendmail hinzufügen 17

36 Lösung Um Unterstützung für reguläre Ausdrücke in sendmail aufzunehmen, fügen Sie der Compiler-Variablen confmapdef in der Datei site.config.m4 den Wert MAP_REGEX hinzu und kompilieren sendmail dann erneut. Hier ist ein Beispiel: # cd /usr/local/src/sendmail /devtools/site # cat >> site.config.m4 APPENDDEF(`confMAPDEF', `-DMAP_REGEX') Ctrl-D # cd /usr/local/src/sendmail #./Build -c Nach der Kompilierung installieren Sie es neu: #./Build install Diskussion Wenn Sie versuchen, eine Konfiguration auszuführen, die einen regex-datenbanktyp auf einem sendmail-system angibt, ohne dass regex-unterstützung bei der Kompilierung aktiviert wurde, erhalten Sie eine Fehlermeldung, wie dieser Test zeigt: # sendmail -bt sendmail.cf: line 115: readcf: map dottedquad: class regex not available ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /quit Die erste Zeile nach dem Befehl sendmail -bt ist eine Fehlermeldung. Sie teilt uns mit, dass Zeile 115 in der Datei sendmail.cf einen Befehl K enthält, der eine Datenbank des Typs regex definiert. Dies führt zu einem Fehler, da regex auf diesem System nicht unterstützt wird. Um dieses Problem zu beheben, ist es erforderlich, eine lokale Compiler-Variable in der Datei site.config.m4 im Verzeichnis devtools/site zu definieren. Der Befehl APPENDDEF, der im Lösungsabschnitt zum Einsatz kam, hängt das Kommandozeilenargument -DMAP_REGEX an alle Werte an, die bereits in der Variablen confmapdef existieren. Der Befehl Build, mit dem sendmail erneut kompiliert wird, verwendet das Flag -c, um sicherzustellen, dass Build die neuen Daten aus der Datei site.config.m4 beachtet. Nach dem Kompilieren von sendmail führen Sie es mit den Kommandozeilenargumenten -bt und -d0.1 aus, um die Compiler-Optionen zu überprüfen: # sendmail -bt -d0.1 Version Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MIME7TO8 MIME8TO7 NEWDB NAMED_BIND NETINET NETUNIX PIPELINING SCANF USERDB XDEBUG ============ SYSTEM IDENTITY (after readcf) ============ (short domain name) $w = chef (canonical domain name) $j = chef.wrotethebook.com (subdomain name) $m = wrotethebook.com Links 18 Kapitel 1: Der Einstieg

37 Rechts (node name) $k = chef ======================================================== ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /quit Die Zeile»Compiled with:«, die durch das Argument -d0.1 ausgegeben wird, zeigt die Compiler-Optionen an. Diese Zeile sollte MAP_REGEX enthalten. Ist dies der Fall, dann müssten Konfigurationen, die den Datenbanktyp regex verwenden, nun erfolgreich ausgeführt werden. Siehe auch Die Rezepte 1.2, 1.3, 1.5, 1.6 und 1.7 zeigen weitere Beispiele für das Kompilieren von sendmail. Rezept 6.10 verwendet den Datenbanktyp regex. Das Buch sendmail behandelt das Kompilieren von sendmail in Abschnitt sendmail mit SASL-Unterstützung kompilieren Problem sendmail muss mit SASL-Unterstützung kompiliert werden, bevor es die Protokollerweiterung AUTH anbieten kann. Lösung Überprüfen Sie die sendmail-compiler-optionen. Wurde sendmail mit dem Flag SASL kompiliert, muss die Kompilierung nicht wiederholt werden. Wurde sendmail jedoch ohne SASL-Unterstützung kompiliert, dann fügen Sie SASL zu den -D-Flags hinzu, mit denen die Compiler-Umgebungsinformationen festgelegt werden. Fügen Sie sasl zu den -l-flags hinzu, mit denen die Bibliotheken für das Linken ausgewählt werden, und kompilieren Sie sendmail erneut. Nach der Kompilierung installieren Sie sendmail erneut und starten es neu. Diskussion Prüfen Sie mit dem Flag -d0.1 die Compiler-Optionen des sendmail-programms. Das Flag SASL sollte in der Liste»Complied with:«zu sehen sein, wie in diesem Beispiel gezeigt wird: # sendmail -bt -d0.1 Version Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETUNIX NEWDB PIPELINING SASL SCANF USERDB XDEBUG 1.5 sendmail mit SASL-Unterstützung kompilieren 19

38 ============ SYSTEM IDENTITY (after readcf) ============ (short domain name) $w = chef (canonical domain name) $j = chef.wrotethebook.com (subdomain name) $m = wrotethebook.com (node name) $k = chef ======================================================== Links ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /quit Falls das Flag nicht angezeigt wird, dann legen Sie eine Datei site.config.m4 im Verzeichnis devtools/site an, die die folgenden Befehle enthält: APPENDDEF(`conf_sendmail_ENVDEF', `-DSASL') APPENDDEF(`conf_sendmail_LIBS', `-lsasl') Kompilieren, installieren und starten Sie sendmail neu, wie in diesem Beispiel gezeigt: # cd /usr/local/src/sendmail #./Build -c...viele Ausgabezeilen gelöscht... # cd /usr/local/src/sendmail /sendmail #./Build install...viele Ausgabezeilen gelöscht... # kill -HUP `head -1 /var/run/sendmail.pid` Siehe auch Die Rezepte 1.2, 1.3, 1.4, 1.6 und 1.7 zeigen weitere Beispiele für das Kompilieren von sendmail. Kapitel 7 behandelt die SASL- und AUTH-Konfiguration. Das Buch sendmail behandelt in Abschnitt 10.9 die AUTH-Konfiguration und in Abschnitt 2.2 das Kompilieren von sendmail. In der Datei sysadmin.html der SASL-Dokumentation finden Sie weitere Informationen über die SASL-Konfiguration. 1.6 sendmail mit STARTTLS-Unterstützung kompilieren Problem sendmail muss mit besonderen Einstellungen kompiliert werden, um die Erweiterung STARTTLS zu unterstützen. Lösung Benutzen Sie den Befehl sendmail -bt -d0.1, um die sendmail-compiler-optionen zu überprüfen. Erscheint der String STARTTLS in der Liste»Compiled with:«, dann besteht nicht die Notwendigkeit, sendmail neu zu kompilieren. Wurde sendmail nicht mit 20 Kapitel 1: Der Einstieg

39 Rechts STARTTLS-Unterstützung kompiliert, dann bearbeiten Sie die Datei devtools/site/site. config.m4, um STARTTLS zu den -D-Flags des Compilers und ssl und crypto zu den -l-flags hinzuzufügen (die -l-flags werden verwendet, um die Bibliotheken zum Linken auszuwählen). Siehe das folgende Beispiel: # cd /usr/local/src/sendmail /devtools/site # cat >> site.config.m4 APPENDDEF(`conf_sendmail_ENVDEF', `-DSTARTTLS') APPENDDEF(`conf_sendmail_LIBS', `-lssl -lcrypto') Ctrl-D Kompilieren, installieren und starten Sie sendmail dann neu: # cd /usr/local/src/sendmail #./Build -c...viele Ausgabezeilen gelöscht... #./Build install...viele Ausgabezeilen gelöscht... # kill -HUP `head -1 /var/run/sendmail.pid` Diskussion In der Beispieldatei site.config.m4 fügt der erste APPENDDEF-Befehl -DSTARTTLS der Liste der Compiler-Optionen hinzu, die in der conf_sendmail_envdef-definition gespeichert sind. Der zweite APPENDDEF-Befehl fügt -lssl und -lcrypto der Liste der Bibliotheken hinzu, die in der conf_sendmail_libs-definition gespeichert sind. Der Befehl Build wird dann verwendet, um sendmail neu zu kompilieren. Die Option -c auf der Build-Kommandozeile stellt sicher, dass Build die Änderungen erkennt, die an der Datei site.config.m4 vorgenommen wurden. Build install wird ausgeführt, um das frisch kompilierte sendmail-programm auszuführen. Das HUP-Signal dient dazu, sendmail mit dem neuen Binary neu zu starten. Führen Sie sendmail nach dem Neukompilieren mit der Option -d0.1 aus, dann sehen Sie, dass STARTTLS nun in der Liste»Compiled with:«steht. sendmail kann nun so konfiguriert werden, dass es STARTTLS anbietet, wie in Kapitel 8 beschrieben. Siehe auch Die Rezepte 1.2 bis 1.5 bieten weitere Informationen über das Kompilieren von sendmail. Außerdem finden Sie in Rezept 1.7 Informationen über das Beheben eines Problems, das auftreten könnte, wenn Sie sendmail für die Unterstützung von STARTTLS kompilieren. Kapitel 8 behandelt die STARTTLS-Konfiguration. Das Buch sendmail behandelt in Abschnitt 2.2 das Kompilieren von sendmail und in Abschnitt STARTTLS. 1.6 sendmail mit STARTTLS-Unterstützung kompilieren 21

40 1.7 STARTTLS-Dateipfade hineinkompilieren Links Problem Wenn Sie sendmail so kompilieren, dass es die Erweiterung STARTTLS unterstützt, werden in Bezug auf OpenSSL-Dateien»No such file or directory«-fehler angezeigt. Lösung Setzen Sie die korrekten Pfadwerte in conf_sendmail_incdirs und conf_sendmail_libdirs, um sendmail mitzuteilen, wo sich die OpenSSL-Dateien befinden. Fügen Sie die Definitionen der Konfigurationsdatei site.config.m4 hinzu, wie in diesem Beispiel gezeigt: # cd /usr/local/src/sendmail /devtools/site # cat >> site.config.m4 APPENDDEF(`conf_sendmail_INCDIRS', `-I/usr/share/ssl/include') APPENDDEF(`conf_sendmail_LIBDIRS', `-L/usr/share/ssl/lib') Ctrl-D Kompilieren, installieren und starten Sie sendmail dann neu: # cd /usr/local/src/sendmail #./Build -c...viele Ausgabezeilen gelöscht... #./Build install...viele Ausgabezeilen gelöscht... # kill -HUP `head -1 /var/run/sendmail.pid` Diskussion Die sendmail-konfiguration geht davon aus, dass OpenSSL an der üblichen Stelle installiert ist. Sollte dies nicht der Fall sein, werden»no such file or directory«-fehler während der sendmail-erstellung angezeigt, sobald das System versucht, die OpenSSL-Dateien zu benutzen. Benutzen Sie APPENDDEF-Befehle, um der Variablen conf_sendmail_incdirs den korrekten Ablageort der OpenSSL-Include-Datei und der Variablen conf_sendmail_ LIBDIRS den korrekten Ablageort der OpenSSL-Bibliothek hinzuzufügen. Die APPENDDEF- Befehle werden in die Datei site.config.m4 eingefügt. Nach dem Definieren der richtigen Werte in site.config.m4 kompilieren Sie sendmail erneut mit dem Befehl Build -c. Wenn die Pfadwerte korrekt definiert sind, sollte das Erstellen von sendmail ohne Fehler vonstatten gehen. Siehe auch Die Rezepte 1.2 bis 1.6 bieten zusätzliche Informationen zum Kompilieren von sendmail. Speziell Rezept 1.6 zeigt ein Beispiel für das Kompilieren von sendmail mit STARTTLS- Unterstützung. Kapitel 8 behandelt die STARTTLS-Konfiguration. Das Buch sendmail 22 Kapitel 1: Der Einstieg

41 Rechts behandelt in Abschnitt 2.2 das Kompilieren von sendmail und in Abschnitt STARTTLS. 1.8 Eine sendmail-konfiguration erzeugen Problem sendmail-konfigurationen werden mit Hilfe von m4-makros geschrieben. Die Konfiguration muss durch m4 verarbeitet werden, um die sendmail.cf-konfigurationsdatei zu erzeugen, die von sendmail gelesen wird. Lösung Wechseln Sie in das Konfigurationsverzeichnis. Legen Sie die m4-hauptkonfigurationsdatei an. In diesem Beispiel nennen wir die Hauptkonfigurationsdatei sendmail.mc. Erzeugen Sie die Datei sendmail.cf, kopieren Sie sie in das Standardverzeichnis, und starten Sie den sendmail-daemon neu: #./Build sendmail.cf Using M4=/usr/bin/m4 rm -f sendmail.cf /usr/bin/m4../m4/cf.m4 sendmail.mc > sendmail.cf ( rm -f sendmail.cf && exit 1 ) chmod 444 sendmail.cf # cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.bak # cp sendmail.cf /etc/mail/sendmail.cf # kill -HUP `head -1 /var/run/sendmail.pid` Beachten Sie, dass sendmail in diesem Beispiel mit einem HUP-Signal neu gestartet wird. Dies setzt voraus, dass sendmail bereits mit einer aktuellen Konfiguration läuft, was für die Mehrzahl der Rezepte in diesem Buch eine gute Annahme ist. Falls sendmail jedoch bisher zwar installiert wurde, aber nicht läuft und auch nicht zuvor konfiguriert wurde, dann benutzen Sie Build install-cf, um sowohl die Datei sendmail.cf als auch die Datei submit.cf richtig zu installieren. Im Abschnitt»Die Datei sendmail.cf erzeugen und installieren«der folgenden Diskussion finden Sie ein Beispiel für den Befehl Build install-cf. Diskussion Neue sendmail-konfigurationen werden im Allgemeinen innerhalb des Verzeichnisses cf/cf angelegt. Natürlich handelt es sich bei cf/cf um einen relativen Pfad. Es ist also vom jeweiligen System abhängig, wo genau sich dieses Verzeichnis befindet. Beispielsweise platziert der Red-Hat-RPM die Konfigurationsdateien in /usr/share/sendmail-cf/cf. Falls Sie die sendmail-distribution verwenden, dann liegt das Verzeichnis cf/cf relativ zu der Stelle, an der Sie die Distribution installiert haben. Alle Beispiele in diesem Buch gehen 1.8 Eine sendmail-konfiguration erzeugen 23

42 davon aus, dass Sie die sendmail distribution benutzen und diese in /usr/local/src installiert haben. Unter dieser Voraussetzung würde der folgende cd-befehl Sie in das richtige Verzeichnis führen: # cd /usr/local/src/sendmail /cf/cf Legen Sie als Nächstes eine Hauptkonfigurationsdatei an, und führen Sie die notwendigen Arbeiten an dieser Datei aus. Sie können eine von Grund auf neue Konfigurationsdatei anlegen, mit einer generischen Konfiguration beginnen, die Ihnen von den sendmail- Entwicklern angeboten wird, oder mit einer Konfiguration beginnen, die Ihnen Ihr Unix- Hersteller liefert. Das Erstellen einer völlig neuen, eigenen Konfigurationsdatei ist recht einfach, da sendmail-hauptkonfigurationsdateien ziemlich kurz sind. Allerdings bieten Ihnen die sendmail-entwickler ein vollständiges Set generischer und prototypischer Dateien, die sich im Allgemeinen sehr gut als Ausgangspunkt eignen. Die Beispiele in diesem Buch sind Modifikationen der Konfigurationsdatei generic-linux. mc, die in der sendmail-distribution enthalten ist. Deshalb kopieren wir die Datei generic-linux.mc, die sich am besten für unser Beispiel-Linux-System eignet, nach sendmail.mc, unsere Arbeitsdatei. Die Datei generic-linux.mc enthält folgende Zeilen: 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. # # Links # # 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: ch01,v /12/03 15:32:48 jhawks Exp chodacki $') OSTYPE(linux)dnl DOMAIN(generic)dnl MAILER(local)dnl MAILER(smtp)dnl Der Befehl divert(-1) beginnt mit einem Abschnitt von Kommentaren, der mit dem Befehl divert(0) endet. Aus diesem Grund sind nur die letzten fünf Zeilen der generischen Datei aktive Zeilen der Rest der Datei besteht aus Kommentaren. 24 Kapitel 1: Der Einstieg

43 Rechts Das Makro VERSIONID legt Versionsinformationen fest, die in beliebiger Weise formatiert werden. Falls Sie ein Versionskontrollsystem benutzen, sollten Sie die Informationen vermutlich am besten so formatieren, dass sie mit diesem System kompatibel sind. Auf jeden Fall sollten Sie diese Informationen ändern, falls Sie die Datei bearbeiten, um anzugeben, wann und durch wen diese Änderungen vorgenommen wurden. Das Makro OSTYPE lädt die Konfiguration, die für das Betriebssystem erforderlich ist. In diesem Fall wird die Datei /ostype/linux.m4 geladen, wie Sie bei einer generischen Linux- Konfiguration erwarten würden. Wir werden gleich auf die Datei linux.m4 zurückkommen, um uns deren Inhalt anzuschauen. Das Makro DOMAIN lädt eine Konfigurationsdatei, die speziell für Ihre Domain gedacht ist. Die Datei generic-linux.mc ist eine Beispieldatei. Die Datei domain/generic.m4, die mit dem Makro DOMAIN geladen wird, ist ebenfalls eine Beispieldatei. Auch wenn sie nicht speziell für Ihre Domain vorgesehen ist, ist die Datei generic.m4 doch so gestaltet, dass sie keinen Schaden anrichten kann. Dem Inhalt der Datei domain/generic.m4 wenden wir uns später zu. Falls Sie eine eigene Domain-Datei anlegen, dann beachten Sie, dass es einen interessanten Nebeneffekt gibt, wenn alle Konfigurationsänderungen in der Domain-Datei vorgenommen werden und die Hauptkonfigurationsdatei unverändert bleibt. Das Neuerstellen der Datei sendmail.cf mit dem Build-Skript könnte folgenden Fehler erzeugen: #./Build sendmail.cf Using M4=/usr/bin/m4 make: `sendmail.cf' is up to date. Build prüft nicht, ob sich die Domain-Datei geändert hat. Das Skript sieht, dass sendmail. mc seit dem letzten Erstellen unverändert geblieben ist, und lehnt deshalb das Erzeugen einer neuen sendmail.cf-datei ab. Umgehen Sie dieses Problem, indem Sie die alte sendmail.cf-datei löschen, touch sendmail.mc ausführen, bevor Sie Build aufrufen, oder m4 anstelle von Build benutzen, um die Datei sendmail.cf neu zu erstellen. Die letzten beiden Makros in der Datei generic-linux.mc sind MAILER-Makros. Das erste MAILER-Makro lädt mailer/local.m4, wodurch die folgenden Mailer definiert werden: local Der Mailer local liefert Mail an Benutzerzugänge aus, die sich auf diesem System befinden. prog Der Mailer prog wird von sendmail verwendet, um Mail an andere Prozesse weiterzuleiten, die auf dem lokalen System laufen. Die Mailer local und prog werden beide in den meisten sendmail-konfigurationen verwendet. 1.8 Eine sendmail-konfiguration erzeugen 25

44 Das zweite MAILER-Makro lädt mailer/smtp.m4, wodurch folgende Mailer definiert werden: esmtp Der Mailer Extended SMTP (ESMTP) verarbeitet das Standard-TCP/IP-Mail-Protokoll, einschließlich komplexer Nachrichtenkörper und MIME-Typen. Dies ist der Standard-Mailer, der von sendmail für SMTP-Mail benutzt wird. relay Der Mailer relay wird verwendet, um SMTP-Mail an einen anderen Mail-Host zu vermitteln (Relaying). Weitervermittlung und Mail Relay Hosts werden in Kapitel 3 behandelt. smtp Der Mailer smtp verarbeitet nur altmodische 7-Bit-ASCII-SMTP-Mail. sendmail benutzt diesen Mailer nur, wenn es speziell dafür konfiguriert wurde; falls es beispielsweise durch einen Eintrag in der Datenbank mailertable dazu angewiesen wird. Die mailertable kommt in den Rezepten in Kapitel 5 zum Einsatz. smtp8 Der Mailer smtp8 ist dafür gedacht, mit entfernten Systemen zusammenzuarbeiten, die zwar 8-Bit-Mail verarbeiten können, das Standard-ESMTP-Protokoll jedoch nicht verstehen. sendmail benutzt diesen Mailer nur, wenn es speziell dafür konfiguriert wurde; falls es beispielsweise durch einen Eintrag in der Datenbank mailertable dazu angewiesen wird. dsmtp Der Mailer dsmtp erlaubt es dem Ziel-Host, Mails zu beziehen, die in einer Warteschlange auf dem Mailserver liegen. Normalerweise wird Mail von der Quelle zum Ziel»geschoben«(push); die Quelle initiiert die Verbindung. Dieser Mailer erlaubt es dem Ziel, Mail von der Quelle zu»ziehen«(pull), wenn es dazu bereit ist, Mails zu empfangen. Dazu verwendet es den optionalen SMTP-Befehl ETRN. sendmail benutzt diesen Mailer nur, wenn es speziell dafür konfiguriert wurde. Die beiden MAILER-Makros fügen der Konfiguration die wichtigsten Mailer hinzu. Die Makros DOMAIN (dieses lädt die Datei domain/generic.m4) und OSTYPE (dieses lädt die Datei ostype/linux.m4) erweitern die Konfiguration ebenfalls um Einstellungen. Schauen Sie sich die Dateien generic.m4 und linux.m4 an, um genau festzustellen, um welche Einstellungen es sich handelt. Die Datei linux.m4 Jede Hauptkonfigurationsdatei enthält ein OSTYPE-Makro. 7 Um eine Konfiguration vollständig zu verstehen, müssen Sie genau wissen, welche Parameter von dieser Datei gesetzt werden. Dieses Buch verwendet Linux als Beispielbetriebssystem und linux.m4 7 Rezept 10.1 zeigt einen Trick, mit dem Sie diese Anforderung umgehen können. Links 26 Kapitel 1: Der Einstieg

45 Rechts als Beispiel-ostype-Datei. Sie müssen jedoch die ostype-datei untersuchen, die speziell zu Ihren Betriebssystemen passt, bevor Sie die Rezepte ausprobieren, die in den späteren Kapiteln folgen. Hinter einem eröffnenden Kommentarblock enthält die Datei linux.m4 die folgenden aktiven Zeilen: VERSIONID(`$Id: ch01,v /12/03 15:32:48 jhawks Exp chodacki $') define(`confebindir', `/usr/sbin') ifdef(`procmail_mailer_path',, define(`procmail_mailer_path', `/usr/bin/procmail')) FEATURE(local_procmail) Wir haben VERSIONID bereits besprochen, müssen uns daher hier nicht noch einmal damit befassen. Der Befehl define definiert den Pfad zu dem Verzeichnis, in dem bestimmte ausführbare Dateien, vor allem die sendmail Restricted Shell (smrsh), gespeichert sind. Der Standardwert für confebindir ist /usr/libexec. Dieser define-befehl setzt den Wert auf /usr/sbin, einen für Linux-Systeme korrekten Wert. Beachten Sie, dass unterschiedliche einfache Anführungszeichen benutzt werden, um einen geschützten String in einem m4-befehl zu öffnen und zu schließen. Das öffnende Anführungszeichen ist ` (ein Backtick), und das schließende Anführungszeichen ist '. Diese Anführungszeichen sind nur erforderlich, wenn der String ein Leerzeichen, ein Sonderzeichen oder ein Schlüsselwort enthält. Allerdings werden die Anführungszeichen häufig eingesetzt und wenn dies der Fall ist, müssen sie genau so aussehen, wie oben dargestellt. Der Befehl ifdef ist ein integrierter m4-befehl. Er enthält drei durch Kommata getrennte Felder: Erstens den Namen der Variablen, die getestet werden soll, in diesem Beispiel also PROCMAIL_MAILER_PATH. Zweitens die Aktion, die ausgeführt werden soll, falls die Variable gesetzt ist. In diesem Fall wird keine Aktion ausgeführt, da das zweite Feld leer ist, wie die zwei hintereinander stehenden Kommata andeuten. Drittens die Aktion, die ausgeführt werden soll, falls die Variable nicht gesetzt ist. In der Datei linux.m4 wird der define-befehl, der PROCMAIL_MAILER_PATH auf /usr/bin/ procmail setzt, nur dann ausgeführt, wenn die Variable nicht bereits zuvor gesetzt wurde. PROCMAIL_MAILER_PATH wurde noch nirgendwo in dieser Konfiguration gesetzt; diese Definition wird also ausgeführt und setzt die Variable. Die letzte Zeile in der Datei linux.m4 ist ein FEATURE-Makro, das der Konfiguration die Funktion local_procmail hinzufügt. Die Funktion local_procmail veranlasst sendmail, procmail als lokalen Mailer zu benutzen. procmail ist ein Programm mit sehr leistungsfähigen Mail-Filtereigenschaften. procmail wird in Kapitel 6 besprochen. 1.8 Eine sendmail-konfiguration erzeugen 27

46 Die Datei generic.m4 Nachdem das Makro OSTYPE der Konfiguration die Datei linux.m4 hinzugefügt hat, fügt das Makro DOMAIN die Datei domain/generic.m4 hinzu. Sie enthält die folgenden aktiven Zeilen: VERSIONID(`$Id: ch01,v /12/03 15:32:48 jhawks Exp chodacki $') 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') Da wir wissen, was das Makro VERSIONID tut, müssen wir hier nicht noch einmal darauf eingehen. Der erste define-befehl setzt einen Wert für die Variable confforward_path, die sendmail mitteilt, wo es nach.forward-dateien suchen soll. Die Variable confforward_path wird in der Einführung zu Kapitel 2 und in Rezept 10.8 im Detail erläutert. Der zweite define-befehl setzt den Wert der Variablen confmax_headers_length. Diese m4-variable wiederum legt den Wert für die sendmail.cf-option MaxHeadersLength fest. Dieser Wert bezeichnet die maximale Anzahl an Header-Bytes, die sendmail für eine Nachricht zulässt. Der define-befehl setzt diesen Wert auf , den Standardwert, der zum Einsatz kommt, wenn kein Wert definiert ist. Das erste FEATURE-Makro aktiviert die Funktion redirect. Dies ist eine nützliche Funktion, die verwendet werden kann, um an den Absender eine Nachricht zurückzuschicken, die ihm die korrekte Adresse eines Empfängers mitteilt, dessen Adresse sich geändert hat. Die Funktion redirect wird in Rezept 2.8 benutzt, wo sie auch genauer erklärt wird. Das zweite FEATURE-Makro aktiviert die Funktion use_cw_file. Diese Funktion veranlasst sendmail, die Klasse $=w aus der Datei local-host-names zu laden. Wann und wie Sie diese Funktion einsetzen, erfahren Sie in Rezept 2.1 Schließlich wird das Makro EXPOSED_USER verwendet, um den Benutzernamen root zur Klasse $=E hinzuzufügen. Die Werte in Klasse $=E werden vom Masquerading ausgenommen, wenn die Technik des Masquerading (Maskierung) zum Einsatz kommt, um Hostnamen oder Benutzernamen zu verbergen. Das Makro EXPOSED_USER wird wiederholt in Kapitel 4 benutzt. Die Datei generic-linux.mc, die Datei linux.m4 und die Domain-Datei generic.m4 werden kombiniert, um eine Konfiguration zu erzeugen, die: den Verzeichnispfad confbindir auf /usr/sbin setzt, den Pfad von procmail auf /usr/bin/procmail setzt, procmail als local-mailer benutzt, einen Suchpfad für.forward-dateien definiert, Links 28 Kapitel 1: Der Einstieg

47 Rechts die maximale Länge der Header einer Nachricht auf Bytes setzt, die Funktion redirect aktiviert, die Klasse $=w aus der Datei local-host-names lädt, den Benutzer root vom Masquerading ausnimmt und das komplette Set der lokalen und SMTP-Mailer definiert. Da die Datei generic-linux.mc sowohl die Datei linux.m4 als auch die Datei generic.m4 umfasst, werden die gerade aufgezählten Konfigurationseinstellungen einfach dadurch Bestandteil der Datei sendmail.mc, dass die Datei generic-linux.mc kopiert wird. Die Datei sendmail.mc stellt die Grundkonfiguration dar, die in den nachfolgenden Rezepten verändert wird, um eigene Konfigurationen zu erzeugen. Die Datei sendmail.cf erzeugen und installieren Führen Sie Build aus, um die Datei sendmail.cf aus der Datei sendmail.mc zu erzeugen. Die Benutzung des Build-Skriptes ist ganz einfach. Geben Sie den Namen der Ausgabedatei, die Sie anlegen wollen, als Argument auf der Build-Kommandozeile an. Das Skript ersetzt die Erweiterung.cf der Ausgabedatei durch die Erweiterung.mc und benutzt die Makrokonfigurationsdatei mit diesem Namen, um die Ausgabedatei zu erzeugen. Wenn Sie daher sendmail.cf auf die Build-Kommandozeile setzen, bedeutet dies, dass sendmail.mc benutzt wird, um sendmail.cf zu erstellen. Ungeachtet der Einfachheit von Build verwenden viele Administratoren es nie, um eine sendmail-konfiguration anzulegen, da die m4-kommandozeile sich ebenso gut zum Aufbau einer sendmail-konfiguration eignet: $ m4../m4/cf.m4 sendmail.mc > sendmail.cf Für den durchschnittlichen sendmail-administrator bietet das Build-Skript keine entscheidenden Vorteile. Die meisten von uns entscheiden sich auf Grund einer persönlichen Vorliebe für Build oder m4. Es ist sogar möglich, das Makefile direkt mit einem einfachen make-befehl aufzurufen. In diesem Buch benutzen wir sowohl Build als auch m4, um die sendmail-konfigurationsdatei anzulegen. Nehmen Sie die Methode, die Ihnen am besten gefällt. Das Build-Skript macht es den Leuten, die die sendmail-distribution warten, einfach, eine.cf-datei für jede.mc-datei im Verzeichnis cf/cf anzulegen. Dazu genügt ein einziger Build all-befehl. Falls Sie mehrere Konfigurationen erstellen müssen, ist es möglich, das Makefile zu bearbeiten, wobei Sie die Variable $OTHER derart ändern, dass sie die Namen aller Konfigurationen enthält, die Sie anlegen wollen. Anschließend verwenden Sie den Befehl Build other, um all diese Konfigurationen auf einmal zu erzeugen. Die meisten Administratoren haben jedoch nicht genügend unterschiedliche Konfigurationen, um sich damit befassen zu müssen. Nach dem Erzeugen der neuen sendmail.cf-datei kopieren Sie diese Datei an die Stelle, an der sendmail seine Konfigurationsdatei zu finden erwartet. Auf unserem Beispiel-Red- 1.8 Eine sendmail-konfiguration erzeugen 29

48 Hat-System handelt es sich bei dieser Stelle um /etc/mail/sendmail.cf. In den meisten Fällen können Sie dies mit einem cp-befehl erledigen. Sie können dazu aber auch Build einsetzen: # cd cf/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 Befehl Build install-cf, der oben zum Einsatz kommt, installiert zwei Konfigurationsdateien: die Datei sendmail.cf, um die es sich in diesem Buch hauptsächlich dreht, und eine zweite Datei namens submit.cf. Diese Datei existiert nicht, es sei denn, Sie erzeugen sie, allerdings wird eine vollständige submit.cf mit der sendmail-distribution geliefert. Bei der Datei submit.cf handelt es sich um eine besondere Konfiguration, die verwendet wird, wenn sendmail durch einen Benutzer von der Kommandozeile aus aufgerufen wird, um eine Mail abzusetzen. sendmail.cf ist die Konfigurationsdatei, die der sendmail-daemon benutzt. Der Befehl Build install-cf wird im Allgemeinen verwendet, wenn eine neue sendmail-distribution zum ersten Mal installiert wird. Er soll sicherstellen, dass sowohl sendmail.cf als auch submit.cf installiert werden. Abgesehen von der ersten Installation, ist es jedoch meist nicht notwendig, beide Dateien zur gleichen Zeit zu kopieren, da es normalerweise nicht erforderlich ist, eine neue submit.cf-datei anzulegen, wenn Sie eine neue sendmail.cf-datei erzeugen. Sobald die Konfiguration installiert ist, starten Sie sendmail, um es zu veranlassen, die neue Konfiguration zu lesen. Im Lösungsabschnitt dieses Rezeptes wird sendmail neugestartet, indem ihm mit einem kill-befehl ein HUP-Signal gesendet wird. Diese Methode des Neustartens von sendmail greift auf die normale sendmail-signalverarbeitung zurück, die auf allen Systemen zur Verfügung steht. Der Befehl kill ist daher von der Technik des Herstellers unabhängig. Viele Leser werden damit vertraut sein, einen cat-befehl in einen kill-befehl einzubetten, um die Prozess-ID zu bekommen, die in einer PID-Datei gespeichert ist. Ein interessanter Aspekt der Benutzung von kill zum Neustarten von sendmail ist die Art und Weise, wie die sendmail-prozess-id aus der Datei sendmail.pid bezogen wird. Hier ist noch einmal ein Beispiel: # kill -HUP `head -1 /var/run/sendmail.pid` cat anstelle von head würde in diesem Befehl nicht funktionieren, weil sendmail eine mehrzeilige PID-Datei schreibt. Ein cat von /var/run/sendmail.pid auf unserem Beispielsystem zeigt Folgendes: # cat /var/run/sendmail.pid 1076 /usr/sbin/sendmail -bd -q15m Der Inhalt dieser Datei ist von mehr als nur vorübergehendem Interesse für jemanden, der vorhat, sendmail mit einem HUP-Signal neu zu starten. Die erste Zeile ist die Prozess- ID, die Sie in einer PID-Datei erwarten würden. Die zweite Zeile dieser Datei ist der Links 30 Kapitel 1: Der Einstieg

49 Rechts Befehl, mit dem sendmail gestartet wurde. Der Befehl muss den vollständigen Pfadnamen des sendmail-programms enthalten, damit das HUP-Signal sendmail erfolgreich neu starten kann. Zeigt die zweite Zeile dieser Datei einen teilweisen (oder relativen) Pfadnamen, beendet HUP das momentan laufende sendmail, startet aber keine neue Kopie von sendmail. Im Prinzip wird durch das Absenden eines HUP-Signals an sendmail, wenn die aktuelle Version von sendmail nicht mit dem vollständigen Pfadnamen ausgeführt wurde, sendmail beendet, was Sie vermutlich nicht so beabsichtigt hatten. Um sich auf der sicheren Seite zu bewegen, starten Sie sendmail immer mit dem vollständigen Pfadnamen. Natürlich wird das HUP-Signal nur verwendet, um sendmail neu zu starten, was voraussetzt, dass sendmail bereits läuft. Nach der ersten Installation auf Ihrem System wird sendmail von der Kommandozeile aus mit Hilfe des Befehls sendmail gestartet. Hier ist ein Beispiel: # /usr/sbin/sendmail -bd -q15m # /usr/sbin/sendmail -L sm-msp -Ac -q15m Die Option -bd auf der ersten Kommandozeile veranlasst sendmail, als Daemon zu starten und an den Ports 25 und 587 auf eingehende Mails zu warten. Dieser erste Befehl erzeugt den sendmail-daemon, der die sendmail.cf-konfigurationsdatei liest und in der traditionellen Rolle eines Mail-Transfer-Agenten (MTA) läuft. Der zweite Befehl startet sendmail als Mail-Submissionsprogramm. Die Option -Ac auf dieser Kommandozeile weist sendmail an, die Konfigurationsdatei submit.cf zu lesen. Die Option -L sagt dieser Kopie von sendmail, dass sie den Namen sm-msp benutzen soll, wenn sie Meldungen protokolliert. Ohne die Option -L würden beide Kopien von sendmail Meldungen unter dem Namen sendmail protokollieren, wodurch es schwierig wäre festzustellen, welche Kopie von sendmail die Meldung geschrieben hätte. Die Option -q15m auf beiden Kommandozeilen weist die einzelnen Kopien von sendmail an, ihre Mail-Warteschlange alle 15 Minuten zu verarbeiten. In Kapitel 9 finden Sie nähere Informationen über Mail-Warteschlangen. Manche Systeme stellen ihre eigenen Werkzeuge zum Starten von Daemons zur Verfügung. Beispielsweise kann ein Red-Hat-System, das eine RPM-Version von sendmail benutzt, sendmail mit dem Befehl service starten: # service sendmail start Starting sendmail: [ OK ] Unabhängig davon, wie sendmail gestartet oder neu gestartet wird, liest der Daemon beim Start die Konfigurationsdatei /etc/mail/sendmail.cf, die nun die neue Konfiguration enthält. Dieses Rezept bildet die Konfigurationsgrundlage, auf der die meisten Rezepte in diesem Buch aufbauen. Nachfolgende Kapitel beschreiben Lösungen für bestimmte Probleme. Diese Lösungen werden häufig im Kontext dieses Grundrezeptes präsentiert. Sie müssen diese Lösungen dann nehmen und sie in die Grundkonfiguration einordnen, die Sie für Ihren Server aufbauen. Wir verwenden aus zwei Gründen ein Grundrezept für die folgenden Lösungen: 1.8 Eine sendmail-konfiguration erzeugen 31

50 Erstens sind wir durch die Behandlung der Grundkonfiguration nicht mehr verpflichtet, diese lange Beschreibung bei allen Rezepten immer und immer wieder zu liefern. Dadurch können wir uns wiederum auf die individuellen Aspekte dieser Rezepte konzentrieren. Wir erläutern das Grundrezept einmal und gehen dann davon aus, dass Sie die Aussagen zur Grundkonfiguration verstehen. Rezepte enthalten naturgemäß viele Wiederholungen; unser Vorgehen verringert diese etwas. Zweitens liefert das Grundrezept einen konsistenten Referenzpunkt für nachfolgende Rezepte. Indem Sie eine Grundkonfiguration anlegen, die Sie als Ausgangspunkt für die meisten Rezepte in diesem Buch benutzen können, stellen wir sicher, dass Sie unsere Testergebnisse auf Ihrem System nachvollziehen können. Links Siehe auch Das Buch sendmail behandelt das Makro VERSIONID in Abschnitt , das Makro OSTYPE in Abschnitt , das Makro DOMAIN in Abschnitt und das Makro MAILER in Abschnitt Alle m4-makros und Konfigurationsbefehle werden in der Datei cf/readme besprochen, die mit der sendmail-distribution geliefert wird. 1.9 Eine neue Konfiguration testen Problem Sie müssen die sendmail-konfiguration testen, bevor sie freigegeben wird. Lösung Verwenden Sie die sendmail-kommandozeilenoptionen -bt, -bv und -v. Diskussion Am Ende von Rezept 1.8 wird die neu erzeugte Datei sendmail.cf über die alte Konfiguration kopiert. Kopieren Sie eine eigene Konfiguration erst dann in das Verzeichnis /etc/ mail, wenn sie ausreichend getestet wurde. sendmail stellt ausgezeichnete Testwerkzeuge zur Verfügung, von denen in diesem Buch auch ausreichend Gebrauch gemacht wird. Das wichtigste Werkzeug zum Testen von sendmail ist sendmail selbst. Wenn es mit der Kommandozeilenoption -bt gestartet wird, tritt sendmail in den Testmodus. Im Testmodus akzeptiert es eine Reihe von Befehlen, die die Konfiguration untersuchen, Einstellungen überprüfen und überwachen, wie -Adressen durch sendmail verarbeitet werden. Tabelle 1-2 zeigt die Befehle, die im Testmodus zur Verfügung stehen. 32 Kapitel 1: Der Einstieg

51 Rechts Tabelle 1-2: Befehle für den sendmail-testmodus Befehl Regelsätze Adresse =SRegelsatz Benutzung Verarbeitet die Adresse durch die mit Kommata getrennte Liste von Regelsätzen. Zeigt den Inhalt des Regelsatzes an. =M Zeigt alle Mailer-Definitionen an. $v Zeigt den Wert von Makro v an. $=c.dvwert.ccwert -dwert /tryflags Flag /try Mailer Adresse /parse Adresse /canon Hostname /mx Hostname /map Datenbankname Schlüssel /quit Zeigt den Wert in Klasse c an. Setzt das Makro v auf Wert. Fügt Wert zur Klasse c hinzu. Setzt die Debugausgabe auf Wert. Setzt die Flags, die für die Adressverarbeitung durch /try verwendet werden. Verarbeitet die Adresse für den Mailer. Liefert das Auslieferungstriple Mailer/Host/Benutzer für die Adresse zurück. Überführt den Hostnamen in seine kanonische Form. Sucht die MX-Records für Hostname. Sucht nach Schlüssel in der Datenbank, die durch Datenbankname identifiziert wird. Verlässt den Adresstestmodus. Einige Befehle (=S, =M, $v und $=c) geben aktuelle sendmail-konfigurationswerte aus, die in der Datei sendmail.cf definiert sind. Der Befehl /map gibt Werte aus, die in den sendmail-datenbankdateien gesetzt sind. Mit dem Befehl -d kann die Menge der angezeigten Informationen geändert werden. Mit -d lassen sich viele unterschiedliche Debugausgaben einstellen, von denen aber nur einige für den sendmail-administrator sinnvoll sind. Im Buch sendmail werden alle Debugwerte behandelt; auf die nützlichsten Werte gehen wir auch in diesem Buch ein. Zwei Befehle, nämlich.d und.c, werden verwendet, um in Echtzeit Makro- und Klassenwerte zu setzen. Setzen Sie diese Befehle ein, um alternative Konfigurationseinstellungen auszuprobieren, bevor Sie die gesamte Konfiguration neu erstellen. Zwei Befehle stellen die Interaktion zwischen sendmail und dem DNS dar. /canon zeigt den kanonischen Namen an, der vom DNS für einen bestimmten Hostnamen zurückgeliefert wird. /mx zeigt die Liste der MX-Einträge (Mail Exchanger) an, die vom DNS für einen bestimmten Host geliefert wird. Die meisten der verbleibenden Befehle verarbeiten eine -Adresse durch die Rewrite-Regeln von sendmail. /parse stellt die Verarbeitung einer Auslieferungsadresse dar und zeigt, welcher Mailer verwendet wird, um Mail auszuliefern, die an die Adresse gesandt wird. /try stellt die Verarbeitung von Adressen für einen bestimmten Mailer dar. (Der Befehl /tryflags legt fest, ob die Absender- oder die Empfängeradresse durch den Befehl /try verarbeitet werden soll.) Benutzen Sie den Befehl Regelsatz Adresse, um die 1.9 Eine neue Konfiguration testen 33

52 Verarbeitung einer Adresse durch eine beliebige Liste von Regelsätzen darzustellen, die Sie testen wollen. Das folgende Beispiel benutzt den sendmail-testmodus, um die Konfiguration zu prüfen, die in Rezept 1.8 angelegt wurde. Rufen Sie den Befehl sendmail mit der Option -bt auf, um in den Testmodus zu gelangen, und mit der Option -C, um die zu testende Konfigurationsdatei festzulegen. Falls die Option -C nicht verwendet wird, dann wird die aktuelle Konfigurationsdatei (/etc/mail/sendmail.cf) getestet. Der folgende Test zeigt die Mailer-Konfiguration in Form einer Liste von sendmail.cf-m- Befehlen: # sendmail -bt -C/usr/local/src/sendmail /cf/cf/sendmail.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > =M mailer 0 (prog): P=/bin/sh S=EnvFromL/HdrFromL R=EnvToL/HdrToL M=0 U=0:0 F=9DFMeloqsu L=0 E=\n T=X-Unix/X-Unix/X-Unix r=100 A=sh -c $u mailer 1 (*file*): P=[FILE] S=parse/parse R=parse/parse M=0 U=0:0 F=9DEFMPloqsu L=0 E=\n T=X-Unix/X-Unix/X-Unix r=100 A=FILE $u mailer 2 (*include*): P=/dev/null S=parse/parse R=parse/parse M=0 U=0:0 F=su L=0 E=\n T=<undefined>/<undefined>/<undefined> r=100 A=INCLUDE $u mailer 3 (local): P=/usr/bin/procmail S=EnvFromL/HdrFromL R=EnvToL/HdrToL M=0 U=0:0 F=/59:@ADFMPSfhlnqsw L=0 E=\n T=DNS/RFC822/X-Unix r=100 A=procmail -Y -a $h -d $u mailer 4 (smtp): P=[IPC] S=EnvFromSMTP/HdrFromSMTP R=EnvToSMTP/EnvToSMTP M=0 U=0:0 F=DFMXmu L=990 E=\r\n T=DNS/RFC822/SMTP r=100 A=TCP $h mailer 5 (esmtp): P=[IPC] S=EnvFromSMTP/HdrFromSMTP R=EnvToSMTP/EnvToSMTP M=0 U=0:0 F=DFMXamu L=990 E=\r\n T=DNS/RFC822/SMTP r=100 A=TCP $h mailer 6 (smtp8): P=[IPC] S=EnvFromSMTP/HdrFromSMTP R=EnvToSMTP/EnvToSMTP M=0 U=0:0 F=8DFMXmu L=990 E=\r\n T=DNS/RFC822/SMTP r=100 A=TCP $h mailer 7 (dsmtp): P=[IPC] S=EnvFromSMTP/HdrFromSMTP R=EnvToSMTP/EnvToSMTP M=0 U=0:0 F=%DFMXamu L=990 E=\r\n T=DNS/RFC822/SMTP r=100 A=TCP $h mailer 8 (relay): P=[IPC] S=EnvFromSMTP/HdrFromSMTP R=MasqSMTP/MasqSMTP M=0 U=0:0 F=8DFMXamu L=2040 E=\r\n T=DNS/RFC822/SMTP r=100 A=TCP $h > /quit Die Ausgabe zeigt, dass alle SMTP-Mailer konfiguriert sind, ebenso die Mailer prog und local. Eine Untersuchung des Parameters P in der Zeile Mlocal zeigt außerdem, dass procmail als local-mailer eingesetzt wird, was die Wirkung der Funktion local_procmail bestätigt. Außerdem zeigt der Parameter P, dass der Pfad zu diesem Programm demjenigen entspricht, der durch die PROCMAIL_MAILER_PATH-Definition festgelegt wurde. Links 34 Kapitel 1: Der Einstieg

53 Rechts sendmail kann auch mit Hilfe der Kommandozeilenoption -bv getestet werden. Die Option -bv verarbeitet eine Adresse durch sendmail und gibt das Mail-Auslieferungstriple für diese Adresse aus. Zum Beispiel: # sendmail -bv tyler@example.com tyler@example.com... deliverable: mailer esmtp, host example.com, user tyler@example.com Dieses Beispiel zeigt deutlich Mailer, Host und Benutzeradresse des Mail-Auslieferungstriple. In diesem Fall ist die Mail an tyler@example.com adressiert, wird zur Auslieferung an den Host example.com gesandt, und zwar mit dem Mailer esmtp. Wenn ein -bv-test mit einer Adresse ausgeführt wird, die direkt durch den lokalen Host ausgeliefert wird, dann hat das den zusätzlichen Vorteil, dass Aliase für diese Adresse aufgelöst werden können und außerdem überprüft wird, ob Mail an diese Adresse zugestellt werden kann. Hier sind einige Beispiele: # sendmail -bv craig craig... deliverable: mailer local, user craig # sendmail -bv fred fred... User unknown # sendmail -bv admin anna@crab.wrotethebook.com... deliverable: mailer esmtp, host crab.wrotethebook.com., user anna@crab.wrotethebook.com andy@rodent.wrotethebook.com... deliverable: mailer esmtp, host rodent.wrotethebook.com., user andy@rodent.wrotethebook.com jane@rodent.wrotethebook.com... deliverable: mailer esmtp, host rodent.wrotethebook.com., user jane@rodent.wrotethebook.com Der erste Test zeigt, dass craig ein lokaler Benutzername ist, an den Mail durch den Mailer local ausgeliefert werden kann. Der zweite Test zeigt, dass fred kein gültiger lokaler Benutzername ist. Der letzte Test zeigt, dass der Alias admin in drei Adressen aufgelöst wird, die über den Mailer esmtp zur Auslieferung an entfernte Systeme weitergeleitet werden. Es gibt weitere Befehle, wie etwa praliases, die es Ihnen erlauben, die aliases-datei zu untersuchen, aber sendmail -bv eignet sich am besten, um zu untersuchen, wie der Einsatz von Aliasen eine lokale Auslieferungsadresse beeinflusst. Die Argumente -bt und -bv zeigen beide, wie die lokale Kopie von sendmail Mail verarbeitet. Um die Interaktion mit einem entfernten System zu untersuchen, kann sendmail dazu veranlasst werden, Mail im ausführlichen Modus, das heißt mit der Option -v, auszuliefern. Zum Beispiel: $ sendmail -v craig@wrotethebook.com < test.msg craig@wrotethebook.com... Connecting to chef.wrotethebook.com. via esmtp chef.wrotethebook.com ESMTP Sendmail /8.12.4; Sat, 2 Aug :57: >>> EHLO rodent.wrotethebook.com 250-chef.wrotethebook.com Hello rodent.wrotethebook.com [ ], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 1.9 Eine neue Konfiguration testen 35

54 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-DELIVERBY 250 HELP >>> MAIL SIZE= Sender ok >>> RCPT Relaying denied >>> RSET Reset state /home/craig/dead.letter... Saved message in /home/craig/dead.letter Closing connection to chef.wrotethebook.com. >>> QUIT chef.wrotethebook.com closing connection Das Testen von sendmail mit dem Argument -v ist sinnvoll, wenn Sie die gesamte Protokollinteraktion verfolgen wollen. Beachten Sie jedoch, dass es in dem obigen Test auf der Zeile, die mit dem Code 550 beginnt, die Fehlermeldung»Relaying denied«gibt. Wenn die eigentliche Aufgabe dieses Tests darin bestand, die Empfängeradresse an dem entfernten Host zu testen, dann wollen Sie vermutlich nicht die gesamte Protokollinteraktion sehen. In diesem Fall ist es sicher besser, wenn Sie telnet benutzen, um eine Verbindung zum SMTP-Port des entfernten Systems herzustellen. Zum Beispiel: $ telnet chef.wrotethebook.com smtp Trying Connected to chef.wrotethebook.com. Escape character is '^]'. 220 chef.wrotethebook.com ESMTP Sendmail /8.12.9; Sat, 2 Aug :57: HELO rodent.wrotethebook.com 250-chef.wrotethebook.com Hello rodent.wrotethebook.com [ ], pleased to meet you MAIL From:<craig@rodent.wrotethebook.com> <craig@rodent.wrotethebook.com>... Sender ok RCPT To:<craig@wrotethebook.com> <craig@wrotethebook.com>... Relaying denied QUIT chef.wrotethebook.com closing connection Connection closed by foreign host. Mit Hilfe von telnet können Sie sich direkt zu der speziellen Protokollinteraktion begeben, die Sie testen wollen. Es ist wichtig, sendmail gründlich zu testen, bevor Sie eine neue Konfiguration freigeben. In diesem Buch nutzen wir alle hier beschriebenen Testmethoden. Siehe auch Das Buch sendmail behandelt die Option -bt in Kapitel 8, die Option -bv in Abschnitt und die Option -v in Abschnitt Links 36 Kapitel 1: Der Einstieg

55 Rechts 1.10 sendmail-protokollierung Problem Das Beheben eines Problems in der sendmail-konfiguration erfordert möglicherweise ausführlichere Informationen, als sendmail standardmäßig protokolliert. Lösung Benutzen Sie die Option LogLevel, entweder auf der sendmail-kommandozeile über das Flag -O oder in der sendmail-konfiguration mit Hilfe der Definition conflog_level, um LogLevel über den Standardwert von 9 hinaus zu erhöhen. Wird die conflog_level-definition verwendet, dann erstellen Sie die sendmail.cf neu, installieren sie erneut und starten dann sendmail neu, wie in Rezept 1.8 beschrieben. Diskussion sendmail protokolliert Nachrichten mit der Methode mail über syslog. Durch die Datei syslog.conf wird festgelegt, wo die Nachrichten abgelegt werden sollen. Ein grep von syslog.conf zeigt, wo die Nachrichten auf unserem Beispiel-Linux-System gespeichert werden: $ grep mail /etc/syslog.conf # Log anything (except mail) of level info or higher. *.info;mail.none;authpriv.none;cron.none /var/log/messages # Log all the mail messages in one place. mail.* /var/log/maillog Neben den Kommentaren gibt es zwei Zeilen in dieser speziellen syslog.conf-datei, die die Methode mail erwähnen. Die erste Zeile enthält ein Wildcard-Zeichen im Methodenfeld, was bedeutet, dass dies für jede syslog-methode gilt. Auf den ersten Blick könnten Sie annehmen, dass dies auch auf sendmail-nachrichten angewandt wird, bis Sie mail. none bemerken. Dieser Teil besagt, dass Nachrichten der Methode mail nicht in /var/log/ messages protokolliert werden. Auf diesem Beispiel-Linux-System müssen Sie in /var/log/ maillog nach sendmail-protokolleinträgen suchen. Der Eintrag mail.* bedeutet, dass unabhängig von der Protokollierungsstufe alle Nachrichten der Methode mail in /var/log/ maillog landen. Selbstverständlich ist die Datei syslog.conf für unser Beispielsystem angepasst worden. Ihre Datei könnte anders aussehen. Und selbst wenn sie genauso aussieht, können Sie sie beliebig ändern. Es unterliegt vollständig Ihrer Kontrolle, wo sendmail Protokollnachrichten ablegt. Die Datei syslog.conf kontrolliert, wo sendmail-nachrichten protokolliert werden. Die sendmail-option LogLevel legt fest, was protokolliert wird. Der Standardwert für LogLevel bei sendmail ist 9, das entspricht ungefähr der syslog-protokollierungsstufe info sendmail-protokollierung 37

56 Wenn Sie den Wert von LogLevel erhöhen, erhöht sich auch die Datenmenge, die sendmail protokolliert. Sinnvolle LogLevel-Werte sind: Protokolliert eine beschränkte Anzahl ernster Probleme, z.b. wenn der Hostname eines Systems oder der qualifizierte Domainname nicht gefunden wird. Protokolliert ernsthafte Systemfehler mit Hilfe der syslog-protokollierungsstufen crit und alert. Protokolliert Netzwerkfehler auf der Protokollierungsstufe crit. Protokolliert Verbindungsabrisse, fehlerhafte Adressen sowie Weiterleitungs- und Einbindungsfehler auf den syslog-protokollierungsstufen notice und error. Protokolliert die Ablehnung von Verbindungen, falsche qf-dateinamen und abgelaufene aliases-datenbanken auf den Protokollierungsstufen info und notice. Protokolliert das Klonen von Umschlägen und legt einen Eintrag für jede empfangene Nachricht an. Diese Protokolleinträge werden auf der syslog-protokollierungsstufe info erzeugt. Legt ein Record jeder Nachricht an, die an den ursprünglichen Absender zurückgesandt wurde, und protokolliert die eingehenden SMTP-Befehle VRFY, EXPN und ETRN auf der Protokollierungsstufe info. Protokolliert Auslieferungsfehler auf der Protokollierungsstufe info. Protokolliert erfolgreiche Auslieferungen und Neuerstellungen der Alias-Datenbank auf der syslog-protokollierungsstufe notice. Protokolliert Mail, die auf Grund mangelnder Systemressourcen zurückgestellt wurde, auf der Protokollierungsstufe info. Protokolliert eingehende SMTP-Verbindungen sowie MILTER-Connects und Antworten. Protokolliert jede Datenbankanfrage. Protokolliert AUTH- und STARTTLS- Fehler. All diese Meldungen werden auf der Protokollierungsstufe info aufgezeichnet. Protokolliert außerdem TLS-Fehler auf der syslog-protokollierungsstufe warning. Protokolliert das Ende der Verarbeitung sowie NIS-Fehler. Beide Arten von Meldungen werden auf der Protokollierungsstufe info aufgezeichnet. Links 38 Kapitel 1: Der Einstieg

57 Rechts Protokolliert ausgehende SMTP-Verbindungen auf der Protokollierungsstufe info. Protokolliert fragwürdige Dateisicherheitsmaßnahmen, wie etwa für alle schreibbare Dateien und fehlerhafte Benutzer-Shells. Protokolliert Verbindungsablehnungen. Protokolliert zusätzliche STARTTLS-Informationen. Beide Arten von Meldungen werden auf der Protokollierungsstufe info aufgezeichnet. Protokolliert alle eingehenden SMTP-Befehle auf der Protokollierungsstufe info Protokolliert Debugging-Informationen auf der Protokollierungsstufe debug. Diese Daten sind vor allem für Code-Entwickler interessant. Bei einer Einstellung von LogLevel werden alle Protokollierungsstufen unter der angegebenen Nummer ebenfalls protokolliert. Beim Standardwert für LogLevel von 9 werden also auch die beschriebenen Meldungen für die Protokollierungsstufen 1 bis 8 aufgezeichnet. Bei jedem LogLevel kommen weitere Einzelheiten hinzu; die Nachrichten der niedrigeren LogLevel-Einstellungen werden dabei weiterhin protokolliert. LogLevel kann in der sendmail-konfiguration mit Hilfe der Definition conflog_level gesetzt werden. Zum Beispiel: define(`conflog_level', `14') Oft ist es jedoch lediglich notwendig, LogLevel für eine kurze Zeit oder für einen einzigen Testdurchlauf zu erhöhen. Dazu definieren Sie LogLevel auf der sendmail-kommandozeile mit dem Argument -O. Hier ist ein Beispiel: # sendmail -O LogLevel=14 -bs -Am Dieses Beispiel führt sendmail von der Kommandozeile aus. Das Argument -Am, das für sendmail-versionen vor 8.12 keine Wirkung hat, stellt sicher, dass sendmail als MTA ausgeführt wird dieses Argument ist das Gegenteil der Option -Ac, die weiter vorn in diesem Kapitel besprochen wurde. Das Argument -bs erlaubt es Ihnen, die SMTP- Befehle manuell einzugeben, ähnlich wie bei den telnet-tests im vorangegangenen Rezept. Mit dem Argument -O können Sie den LogLevel von der Kommandozeile aus einstellen. Ein solcher Befehl könnte eingesetzt werden, um die Auswirkungen bestimmter SMTP-Interaktionen zu protokollieren. Beide Techniken zum Einstellen von LogLevel funktionieren gut. Welche Technik Sie verwenden, hängt von den Umständen und Ihren Vorlieben ab. Siehe auch Das Buch sendmail behandelt die Protokollierung in Abschnitt 14.3 und LogLevel in Abschnitt sendmail-protokollierung 39

58 FirstLeft. Kapitel 2 KAPITEL 2 Auslieferung und Weiterleitung 2.0 Einführung Eingehende Mail wird entweder direkt an den Adressaten ausgeliefert oder an einen anderen Mail-Host zur Auslieferung weitergeleitet. Mail wird nur dann direkt ausgeliefert, wenn sie für den lokalen Host gedacht ist; Mail, die für einen anderen Host gedacht ist, wird weitervermittelt (Relaying). In diesem Kapitel schauen wir uns an, wie Sie sendmail richtig konfigurieren, damit es Mail lokal ausliefert und an andere Systeme weiterleitet. Die Auslieferung ist ein mehrstufiger Vorgang. Zuerst muss sendmail den Host-Anteil der Auslieferungsadresse verarbeiten und erkennen, dass die Mail tatsächlich an den lokalen Host adressiert ist. Ist die Mail nicht an den lokalen Host gerichtet, dann wird sie so weitervermittelt, wie in Kapitel 3 beschrieben. Ist sie an den lokalen Host adressiert, dann wird der Benutzeranteil der Adresse mit der aliases-datei verglichen, um die richtige Auslieferungsadresse zu ermitteln. Liefert die aliases-datei eine externe Adresse zurück, dann wird die Mail an den externen Host zur Auslieferung weitergeleitet. Liefert sie die Adresse einer lokalen Mailbox, prüft sendmail, ob es eine.forward-datei gibt. Existiert die.forward-datei, dann wird die Mail so ausgeliefert, wie es diese Datei angibt. Ansonsten wird die Mail an die lokale Mailbox ausgeliefert. Abbildung 2-1 zeigt ein Flussdiagramm dieses Prozesses. 1 sendmail verarbeitet jede Auslieferungsadresse durch die Regelsätze canonify und parse Regelsätze 3 und 0. Die Auflösung der Aliase beginnt, wenn das Ergebnis dieses Vorgangs sendmail mitteilt, dass die Mail durch einen Mailer ausgeliefert werden soll, bei dem das Flag A gesetzt ist. 2 Gibt Regelsatz 0 den Namen eines Mailers zurück, bei dem das Flag A nicht gesetzt ist, werden die Aliase nicht aufgelöst. Das Flag A kann zwar für alle Mailer gesetzt werden, jedoch nur die Mailer cyrus und local haben ihn standardmä- 1 Dies ist eine vereinfachte Beschreibung, die auf der Standardkonfiguration beruht. sendmail-flags und -Optionen können die Art und Weise verändern, wie die Mail-Auslieferung vonstatten geht. 2 Die Flags werden durch den Parameter F in jeder sendmail.cf-mailer-definition gesetzt. 40 Kapitel 2: Auslieferung und Weiterleitung

59 Rechts Abbildung 2-1: Der mehrstufige Auslieferungsvorgang ßig gesetzt. Für unsere Besprechung der Alias-Auflösung werden wir den Mailer local als Beispiel benutzen. Bei der Auflösung von Aliasen wird zuerst die Auslieferungsadresse in der aliases-datenbank abgefragt. Liefert die Abfrage eine andere Mail-Adresse zurück, dann wird die neue Adresse verarbeitet. Wenn bei dem Mailer, der für die neue Adresse zum Einsatz kommt, das Flag A gesetzt ist, dann wird diese Adresse in der aliases-datenbank nachgesehen. Dieser Vorgang wird so lange fortgesetzt, bis bei einer Alias-Abfrage keine neue Adresse mehr zurückgegeben wird. Ist bei dem Mailer, der für die letzte durch die aliases-datenbank zurückgelieferte Adresse verwendet wird, das Flag w gesetzt, sucht sendmail in der.forward-datei des Benutzers nach einer Auslieferungsadresse. Standardmäßig ist nur beim Mailer local das Flag w gesetzt. Wurde eine.forward-datei gefunden, dann erfolgt die Auslieferung auf der Grundlage der Auslieferungsadresse, die in dieser Datei enthalten ist. Abbildung 2-1 zeigt zwar nur eine vereinfachte Version des eigentlichen Auslieferungsvorgangs, hebt aber dabei Bereiche der Konfiguration hervor, die mit der lokalen Auslieferung und Weiterleitung zu tun haben. Die Klasse $=w muss richtig konfiguriert sein. Die aliases-datei muss angelegt und in eine Datenbank überführt worden sein, und auch die.forward-dateien müssen richtig konfiguriert sein, falls sie zum Einsatz kommen. sendmail akzeptiert Mail für die lokale Auslieferung nur, wenn sie an den lokalen Host adressiert ist. Alle anderen Mails werden weitervermittelt. Die Klasse $=w enthält alle gültigen Hostnamen für den lokalen Host. Wenn der Hostname aus der Auslieferungsadresse in der Klasse $=w gefunden wird, dann wird die Mail für die lokale Auslieferung angenommen. Tatsächlich benutzt der Regelsatz 0 die Klasse $=w, wenn er den Mailer local auswählt. Einführung 41

60 Mail, die durch den Mailer local ausgeliefert wird, muss an einen Benutzerzugang adressiert sein, der auf dem lokalen Host existiert, oder an einen Alias, der zu einer gültigen Auslieferungsadresse aufgelöst werden kann. Die aliases-datenbank befreit den Mailer local von der Einschränkung, dass alle lokalen Mails an tatsächliche Benutzernamen adressiert sein müssen. sendmail wird dadurch flexibler, da Mail, die an einen einzigen Alias adressiert ist, an mehrere Empfänger ausgeliefert werden kann, oder andersherum Mail, die an mehrere unterschiedliche Namen gerichtet ist, an einen einzigen Empfänger geschickt werden kann. Die aliases-datenbank wird außerdem verwendet, um Mail an andere Computer, Programme und Dateien weiterzuleiten. Die aliases-datenbank ist für das Funktionieren eines sendmail-systems so wichtig, dass sendmail sich beschwert, wenn die Datenbank nicht existiert. Manche Benutzer und Programme, die -Benachrichtigungen verschicken, beschweren sich möglicherweise auch, weil sie davon ausgehen, dass es bestimmte Aliase gibt. Kann außerdem weder die aliases-datenbank noch die aliases-textdatei gefunden werden, verarbeitet sendmail auch die.forward-datei des Benutzers nicht. Wenn sendmail eine lokale Adresse in der aliases-datenbank abfragt und durch diese Abfrage keine neue Empfängeradresse zurückgegeben wird, dann überprüft sendmail, ob der Benutzer, der durch die lokale Adresse identifiziert wird, eine.forward-datei besitzt. Die möglichen Ablageorte der.forward-datei des Benutzers werden in der Datei sendmail.cf durch die Option ForwardPath definiert: $ grep ForwardPath sendmail.cf O ForwardPath=$z/.forward.$w+$h:$z/.forward+$h:$z/.forward.$w:$z/.forward Der oben gezeigte Pfad wurde durch die confforward_path-definition in der Datei domain/generic.m4 festgelegt, die in der Beispielkonfiguration aus Rezept 1.8 zum Einsatz kam. Die ForwardPath-Option in diesem Beispiel enthält drei sendmail.cf-makros. Das Makro $z beinhaltet den Pfad des Home-Verzeichnisses des Empfängers, wie in /etc/ passwd angegeben. Das Makro $w nimmt den primären Namen des lokalen Hosts auf. Im Makro $h steht normalerweise der Name des Empfänger-Hosts, wenn Regelsatz 0 das Auslieferungstriple Mailer/Host/Benutzer konstruiert. In diesem Fall jedoch ist Mailer der Mailer local, so dass der Host immer auf den lokalen Host gesetzt ist. Dadurch steht das Makro $h für andere Einsatzmöglichkeiten zur Verfügung. procmail bietet ein Beispiel dafür, wie das Makro $h auf andere Weise benutzt werden kann. Wenn beispielsweise die Adressierungssyntax Benutzer+Detail verwendet wird und procmail der local- Mailer ist, dann enthält das Makro $h den Wert Detail. 3 Wenn bei dieser speziellen ForwardPath-Option der Mailer local procmail heißt, der Hostname chef ist und die Mail an kathy+cookbook adressiert ist, dann werden die folgenden.forward-dateien gesucht: /home/kathy/.forward.chef+cookbook, /home/kathy/.forward+cookbook, /home/kathy/.forward.chef und /home/kathy/.forward. Alle Dateien 3 In der Konfiguration, die in Rezept 1.8 erzeugt wurde, wird procmail als local-mailer verwendet, weil die Datei linux.m4, die in dieser Konfiguration zum Einsatz kommt, die Funktion local_procmail enthält. Links 42 Kapitel 2: Auslieferung und Weiterleitung

61 Rechts werden in dieser Reihenfolge gesucht. Die Suche stoppt, sobald eine Datei mit dem angegebenen Namen gefunden wird. Sowohl die aliases-datenbank als auch die.forward-dateien sind in der Lage, Mail weiterzuleiten. Weiterleitung (»Forwarding«) und Vermittlung (»Relaying«) werden häufig verwechselt, vor allem, wenn Mail an einen externen Host weitergeleitet wird. In diesem Fall sind die Auswirkungen im Prinzip mit einer Vermittlung an diesen Host identisch Mail wird zur Auslieferung an ein externes System übergeben. Es gibt folgenden Unterschied: Mail wird nur dann weitergeleitet, wenn sie zuvor für eine lokale Auslieferung angenommen wurde; Mail wird vermittelt, wenn sie nicht zur lokalen Auslieferung angenommen wurde. Die Vermittlung wird in Kapitel 3 behandelt. 2.1 Mail für andere Hosts akzeptieren Problem Sie müssen sendmail so konfigurieren, dass es Mail, die an andere Hosts adressiert ist, für eine lokale Auslieferung akzeptiert. Das kommt üblicherweise dann vor, wenn Sie einen Mail Exchanger konfigurieren müssen, der Mail für eine Domain oder einzelne Hosts annehmen soll. Lösung Legen Sie eine Datei namens /etc/mail/local-host-names an. Setzen Sie in diese Datei die Hostnamen und Domainnamen, für die sendmail Mail zur lokalen Auslieferung akzeptieren soll. Geben Sie die Namen so ein, dass jeweils ein Host- oder Domainname auf einer Zeile steht. Fügen Sie der sendmail-konfiguration die Funktion use_cw_file hinzu, um die neu erzeugte local-host-names-datei nutzen zu können. Hier sind einige Beispielzeilen, die der Konfiguration hinzugefügt werden könnten, falls diese nicht bereits die Funktion use_cw_file enthält: dnl Load class $=w with other names for the local host FEATURE(`use_cw_file') Erstellen Sie schließlich die Datei sendmail.cf neu, kopieren Sie die neue sendmail.cf-datei nach /etc/mail, und starten Sie sendmail neu, wie in Rezept 1.8 gezeigt wird. Diskussion Mail, die an einen Host adressiert ist, kann aus verschiedenen Gründen an einen anderen Host weitergeschickt werden: Weiterleitung, Vermittlung, mailertable-einträge und so weiter. Häufig wird Mail auf diese Weise umgeleitet, weil das DNS dies so bestimmt. Ein System, das Mail versendet, leitet diese Mail auf der Grundlage der Informationen weiter, 2.1 Mail für andere Hosts akzeptieren 43

62 die vom DNS bezogen werden. Mail wird an einen Hostnamen adressiert. Das entfernte System nimmt diesen Hostnamen und fragt das DNS, ob dieses für den Host MX- Records (Mail Exchange) vorliegen hat. Wird für einen bestimmten Host kein MX- Record gefunden, dann wird das Adress-Record des Hosts vom DNS bezogen und die Mail wird direkt an den Host gesandt. Liefert das DNS MX-Records zurück, dann sendet das entfernte System die Mail an das System mit der niedrigsten Präferenznummer, das in dem MX-Record aufgeführt ist. Ungeachtet der Frage, weshalb die Mail an Ihren Mail-Host geleitet wird, muss das sendmail-system so konfiguriert werden, dass es die Mail akzeptiert, oder es erzeugt einen Relaying denied-fehler (Vermittlung verboten). Das ist ein interessanter Fehler, weil das entfernte System nicht unbedingt versucht, Mail weiterzuvermitteln; es könnte genauso gut versuchen, die Mail an den Mail Exchanger auszuliefern, wie es vom DNS angewiesen wird. Allerdings akzeptiert sendmail nur eingehende Mail zur Auslieferung, die an das lokale System adressiert ist. Alle anderen Mails werden weitervermittelt. sendmail akzeptiert Mail, die an einen anderen Host adressiert ist, nur dann zur lokalen Auslieferung, wenn es den Namen dieses Hosts in der Klasse $=w findet. Die Klasse $=w ist ein Array, das alle Namen enthält, die sendmail als gültig für die lokale Mail-Auslieferung erachtet. Es gibt drei Möglichkeiten, Namen in die Klasse $=w zu laden. Die empfohlene Methode zum Lösen dieses Problems besteht darin, die Funktion use_cw_file zu benutzen. Zwei Alternativen werden ebenfalls vorgestellt: das Platzieren lokaler Hostnamen direkt in sendmail.cf selbst oder die Benutzung der Funktion bestmx_is_local. Links Die Funktion use_cw_file benutzen Die Funktion use_cw_file weist sendmail an, die Datei /etc/mail/local-host-names in die Klasse $=w zu laden. Dazu setzt sie den folgenden F-Befehl in die Datei sendmail.cf: 4 Fw/etc/mail/local-host-names Sobald die Funktion use_cw_file zur Konfiguration hinzugefügt wurde, erwartet sendmail, die Datei local-host-names vorzufinden, und gibt einen Fehler aus, wenn das nicht der Fall ist. Es ist möglich, sendmail so zu konfigurieren, dass es local-host-names als optionale Datei betrachtet, indem die folgende Definition in die Konfiguration gesetzt wird, und zwar vor die Funktion use_cw_file: define(`confcw_file', `-o /etc/mail/local-host-names') Das Flag -o deklariert die Datei als optional, wodurch sendmail aufhört, sich darüber zu beschweren, dass es die Datei nicht finden kann. Mit der Definiton confcw_file können Sie auch einen anderen Pfadnamen für die Datei local-host-names angeben, falls Sie beschließen, die Datei in ein anderes Verzeichnis zu setzen oder ihr einen anderen Namen zu geben. Ändern Sie den Pfadnamen nur, wenn es unbedingt sein muss. Nutzen 4 Die generische Linux-Konfiguration, die in Rezept 1.8 erzeugt wurde, legt die Funktion use_cw_file in der Datei domain/generic.m4 fest. Ist die Funktion bereits definiert, muss sie nicht mehr extra hinzugefügt werden. 44 Kapitel 2: Auslieferung und Weiterleitung

63 Rechts Sie nach Möglichkeit immer Standardpfadnamen für Dateien; dadurch wird es denjenigen, die Ihr System pflegen, erleichtert, diese Dateien zu finden. Ehrlich, es gibt kaum einen Grund, die Datei local-host-names optional zu machen; tatsächlich kann es dadurch passieren, dass echte Fehler verschleiert werden, etwa Fehler beim Öffnen der Datei. Falls Sie noch nicht so weit sind, Hostnamen in die Datei aufzunehmen, dann legen Sie einfach eine leere Datei an. Wenn Sie jedoch Ihre Konfiguration um die Funktion use_cw_file erweitern, dann tun Sie dies sicher, weil Sie Hostnamen in die Datei local-host-names aufnehmen wollen. Lassen Sie uns als Beispiel eine Datei localhost-names für unser Beispielsystem anlegen, die folgende Zeilen enthält: wrotethebook.com horseshoe.wrotethebook.com Nach dem Anlegen der Datei local-host-names und dem Erzeugen der neuen sendmail.cf- Datei testen Sie die neue Konfiguration mit der Option -bt. Führen Sie zuerst sendmail -bt aus, um den Inhalt des Klassen-Array $=w zu untersuchen: # sendmail -bt -C./sendmail.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $=w chef localhost.localdomain localhost [ ] [ ] [chef.wrotethebook.com] horseshoe.wrotethebook.com wrotethebook.com chef.wrotethebook.com > /quit Dieser Test zeigt, dass die Werte horseshoe.wrotethebook.com und wrotethebook.com, die in der Datei local-host-names gespeichert sind, zur Klasse $=w hinzugefügt werden. Er zeigt außerdem, dass sich verschiedene andere Werte in diesem Array befinden. Bei diesen Werten handelt es sich um die Hostnamen, Hostnamen-Aliase und IP-Adressen, die diesem Host zugewiesen sind. sendmail hat diese Werte durch Tests der verschiedenen Netzwerkschnittstellen entdeckt. Die Hostnamen, die mit den Schnittstellenadressen verknüpft sind, werden sowohl aus der Datei /etc/hosts als auch vom DNS bezogen. 5 Schränken Sie die von sendmail durchgeführten Schnittstellentests ein, indem Sie der sendmail-konfiguration die folgende Definition hinzufügen: define(`confdont_probe_interfaces', `true') 5 Der Hostname localhost.localdomain ist ein Wert, den Red Hat für die Loopback-Adresse ( ) in die Datei /etc/hosts setzt. 2.1 Mail für andere Hosts akzeptieren 45

64 Wenn diese Definition verwendet wird, dann werden nur die Hostnamen, die dem System in der Datei /etc/hosts und im DNS zugewiesen sind, sowie die primäre IP-Adresse des Systems als Anfangswerte für die Klasse $=w benutzt. Diese Definition wird nicht verwendet, wenn Sie Mail als lokale Mail akzeptieren, die an eine der Schnittstellen Ihres Servers adressiert ist. Die Definition confdont_probe_interfaces ist jedoch sehr nützlich, wenn sendmail beim Testen der Schnittstellen fehlerhafte Informationen erhält oder wenn eine große Anzahl virtueller Schnittstellen benutzt wird. Mail, die an einen der Hostnamen adressiert ist, die in der Klasse $=w definiert sind, wird durch den Mailer local ausgeliefert. Die oben dargestellte $=w-ausgabe sagt uns, dass dieses System Mail, die an chef, localhost, horseshoe oder wrotethebook.com adressiert ist, mit Hilfe des Mailers local ausliefern wird. Ein zweiter Test, dieses Mal mit sendmail -bv, unterstreicht dies: # hostname chef # sendmail -bv alana@crab.wrotethebook.com alana@crab.wrotethebook.com... deliverable: mailer esmtp, host crab.wrotethebook.com., user alana@crab.wrotethebook.com # sendmail -bv payton@horseshoe.wrotethebook.com payton@horseshoe.wrotethebook.com... deliverable: mailer local, user payton Der Befehl hostname zeigt, dass der lokale Host chef ist, um zu verdeutlichen, dass keine dieser Mails tatsächlich an den lokalen Host adressiert ist. Der Befehl sendmail -bv überprüft eine Auslieferungsadresse und zeigt den Mailer, der verwendet wird, um die Mail auszuliefern. Der erste -bv-test zeigt, dass Mail, die an crab adressiert ist, über das Netzwerk mit dem Mailer esmtp ausgeliefert wird. Genau das würden Sie auch erwarten, da es sich bei crab um ein externes System handelt. Der zweite -bv-test jedoch zeigt, dass Mail, die an horseshoe ein anderes externes System adressiert ist, mit Hilfe des Mailers local ausgeliefert wird. Mail, die an horseshoe adressiert ist, wird behandelt, als wäre sie an chef adressiert. Dies liegt daran, dass horseshoe in der Datei local-host-names definiert ist und die Konfiguration die Funktion use_cw_file benutzt, um Hostnamen aus dieser Datei zur Klasse $=w hinzuzufügen. Dieser Test verdeutlicht, dass das System richtig programmiert ist, um Mail, die an horseshoe adressiert ist, wie lokale Mail zu verarbeiten. Die Datei sendmail.cf direkt benutzen Die Funktion use_cw_file funktioniert gut und ist die empfohlene Lösung für dieses Problem, es gibt aber auch alternative Lösungen. Setzen Sie zum Beispiel lokale Hostnamen in sendmail.cf selbst, oder nutzen Sie die Funktion bestmx_is_local. Die Beispieldatei local-host-names, die wir weiter vorn in diesem Abschnitt erzeugt hatten, enthielt nur zwei Zeilen. Solch eine geringe Anzahl von Namen könnte direkt in die sendmail.cf gesetzt werden. Dazu kämen anstelle der Funktion use_cw_file die folgenden beiden Zeilen zum Einsatz: LOCAL_DOMAIN('wrotethebook.com') LOCAL_DOMAIN('horseshoe.wrotethebook.com') Links 46 Kapitel 2: Auslieferung und Weiterleitung

65 Rechts Diese alternative Lösung ist jedoch schwieriger zu warten, wenn die Liste der Clients anwächst. Jedes Mal, wenn ein LOCAL_DOMAIN-Makro zur Konfiguration hinzugefügt wird, muss die Datei sendmail.cf neu erzeugt, getestet und in das Verzeichnis /etc/mail verschoben werden. Wenn die Datei local-host-names benutzt wird, besteht keine Notwendigkeit, die sendmail.cf neu zu erstellen, nur weil die Datei local-host-names bearbeitet worden ist. Die Funktion bestmx_is_local verwenden Die Funktion bestmx_is_local funktioniert gut, wenn der einzige Grund für das Hinzufügen von Hostnamen zur Datei local-host-names darin besteht, dass der lokale Host ein Mail Exchanger ist. Mail, die an ein System adressiert ist, das den lokalen Host als bevorzugten Mail Exchanger angibt, wird als lokale Mail akzeptiert, wenn die Funktion bestmx_is_local benutzt wird. Um diesen Ansatz zu verfolgen, setzen Sie diese Zeile in die Konfiguration: FEATURE(`bestmx_is_local', `wrotethebook.com') Der große Vorteil der Funktion bestmx_is_local besteht darin, dass sie einfach ist es muss keine Datei local-host-names gewartet werden. Diese Einfachheit erweist sich aber auch als Nachteil, da die Kontrolle darüber, welche Mail durch Ihr System als lokal akzeptiert wird, jemand anderem übergeben wird dem Domain-Administrator. Die potenziellen Probleme, die durch diese fehlende Kontrolle verursacht werden, werden durch die Benutzung einer optionalen Domain-Liste im Beispielbefehl begrenzt. Das Hinzufügen des Arguments `wrotethebook.com' zur Funktion bestmx_is_local bedeutet, dass nur MX- Records von dieser Domain als Beweis dafür akzeptiert werden, dass ein Host ein gültiger Client ist. Wurde die optionale Domain-Liste nicht für die Funktion bestmx_is_local festgelegt, kann jede Domain in der Welt die Mail kontrollieren, die Ihr System als lokal akzeptiert, einfach indem sie ein MX-Record anlegt, das auf Ihren Host verweist. Dadurch ist die Möglichkeit des Missbrauchs gegeben. Ein anderes potenzielles Problem mit der bestmx_is_local-lösung besteht darin, dass sie den Verarbeitungsaufwand für jede einzelne Mail vergrößert. Dies wäre für unser kleines Beispielsystem nicht weiter schlimm, könnte aber für alle Systeme problematisch werden, die mit großen Mengen an Mails umgehen müssen. Eine weitere Einschränkung der bestmx_is_local-lösung besteht in der Tatsache, dass sie völlig von MX-Records abhängt. bestmx_is_local funktioniert für einen Mail Exchanger, da alle Hostnamen, die dieser verarbeitet, MX-Records haben. Es gibt jedoch andere mögliche Gründe, Mail als lokale Mail zu akzeptieren. Die Datei local-host-names kann alle gewünschten Hostnamen speichern; sie ist nicht auf Hosts beschränkt, die Ihr System als ihren Mail Exchanger definieren. local-host-names ist schnell, flexibel und vollständig unter Ihrer Kontrolle. Aus diesen Gründen entscheiden wir uns für die Funktion use_cw_file als bevorzugte Lösung für dieses Problem. 2.1 Mail für andere Hosts akzeptieren 47

66 Siehe auch Das Buch sendmail behandelt use_cw_file, confcw_file und LOCAL_DOMAIN in Abschnitt , bestmx_is_local in Abschnitt und confdont_probe_interfaces in Abschnitt Links 2.2 Den Alias0 Missing Map-Fehler beheben und einfache Aliase anlegen Problem sendmail gibt die folgende Fehlermeldung aus: hash map "Alias0": missing map file /etc/mail/aliases.db: No such file or directory Lösung Legen Sie eine Textdatei namens /etc/mail/aliases an, und füllen Sie sie mit Einträgen der Form: alias: empfänger wobei alias ein Alias-Benutzername ist und empfänger die Adresse, an die Mail ausgeliefert wird, die an diesen Alias adressiert ist. Führen Sie newaliases aus, um die Textdatei zu verarbeiten, und erstellen Sie die aliases- Datenbankdatei, die sendmail verlangt: # newaliases Diskussion Es werden keine m4-konfigurationsbefehle benötigt, um auf die aliases-datenbank zuzugreifen. Jede grundlegende sendmail-konfiguration sollte funktionieren. Die meisten Systeme besitzen eine aliases-datenbank. Sie müssen lediglich die Aliase, die Sie haben wollen, in die existierende aliases-textdatei aufnehmen und den Befehl newaliases ausführen. Gibt Ihr System jedoch den»missing map file«-fehler aus, den wir Ihnen in der Problembeschreibung gezeigt haben, dann gibt es entweder keine aliases-datenbank oder diejenige, die Sie haben, befindet sich im falschen Verzeichnis. In jedem Fall müssen Sie eine gültige aliases-datenbank in den richtigen Pfad setzen. Enthält Ihr System keine aliases-datei, dann verwenden Sie eine von einem ähnlichen System oder greifen auf die Beispiel-aliases-Datei aus dem Verzeichnis sendmail der sendmail-distribution zurück. Befindet sich die Datei, die Sie haben, im falschen Pfad, dann verschieben Sie sie oder ändern die sendmail-konfiguration derart, dass sie auf die Stelle verweist, wo die aliases-datenbank liegt. 48 Kapitel 2: Auslieferung und Weiterleitung

67 Rechts Manche älteren Systeme speichern die aliases-datenbank im Verzeichnis /etc. Um sie in diesem Verzeichnis zu halten, fügen Sie die folgende ALIAS_FILE-Definition zur Datei sendmail.mc hinzu: define(`alias_file', `/etc/aliases') Die ALIAS_FILE-Definition akzeptiert verschiedene Flags. Mit dem Flag -o können Sie die aliases-datenbank optional machen. Sie setzen dieses Flag exakt so ein, wie in Rezept 2.1 mit der confcw_file-definition demonstriert wurde. Das ist jedoch keine gute Idee. Das Flag -o verhindert, dass sendmail den»missing map file«-fehler anzeigt, allerdings deaktiviert sendmail weiterhin die Auflösung von Aliasen, wenn es keine aliases-datei finden kann (d. h., er verbirgt den Fehler, löst aber das Problem nicht). Anstatt den Standardpfad zu ändern oder den Fehler mit einer ALIAS_FILE-Definition auszublenden, setzen Sie die aliases-textdatei in das Verzeichnis /etc/mail. Das ist vermutlich die beste Lösung für die meisten Unix-Versionen, da /etc/mail das Standardverzeichnis ist, in dem die meisten Administratoren diese Datei zu finden erwarten. Das folgende Beispiel verschiebt die aliases-textdatei und führt newaliases aus, um das»missing map file«-problem zu lösen: # sendmail -bv ftp hash map "Alias0": missing map file /etc/mail/aliases.db: No such file or directory ftp... deliverable: mailer local, user ftp # mv aliases /etc/mail/aliases # sendmail -bv ftp hash map "Alias0": missing map file /etc/mail/aliases.db: No such file or directory root... deliverable: mailer local, user root # newaliases /etc/mail/aliases: 40 aliases, longest 10 bytes, 395 bytes total # sendmail -bv ftp root... deliverable: mailer local, user root Die Befehle mv und newaliases lösen das Problem. Die drei Zeilen mit sendmail -bv ftp sollen die Auswirkungen der Befehle mv und newaliases demonstrieren. Der erste -bv-befehl zeigt die Fehlermeldung, die wir erwarten. Mail, die an ftp adressiert ist, wird über den Mailer local an den Benutzernamen ftp gesandt. Nachdem der Befehl mv ausgeführt wurde, zeigt der zweite -bv-befehl erneut die Fehlermeldung, da wir die aliases- Datenbank noch nicht aus der aliases-textdatei erzeugt haben. Dieses Mal jedoch zeigt der -bv-befehl, dass Mail, die an ftp adressiert ist, an den Benutzer root ausgeliefert wird, und zwar über den Mailer local. Es ist ganz deutlich etwas geschehen; irgendwie werden Aliase aufgelöst. sendmail benutzte die aliases-textdatei, um herauszufinden, dass die korrekte Auslieferungsadresse für den Alias ftp root ist. Schließlich wird newaliases ausgeführt, um die Datenbank zu erstellen, und dann wird der letzte -bv-test gestartet. Jetzt gibt es keinen Fehler. Uns wird wieder mitgeteilt, dass die Mail über den Mailer local an root ausgeliefert wird. Die Ausgabe des Befehls newaliases gibt an, dass newaliases 40 Aliase verarbeitet hat. Die drei sendmail -bv-tests zeigen genau, wie sendmail die aliases-dateien behandelt. Wenn sendmail die aliases-datenbank finden kann, verwendet es sie. Wird keine aliases- 2.2 Den Alias0 Missing Map-Fehler beheben und einfache Aliase anlegen 49

68 Datenbank gefunden, gibt sendmail einen Fehler aus und sucht nach der aliases-textdatei. Wenn es die Textdatei findet, benutzt sendmail diese. Kann es weder die Datenbank noch die Textdatei finden, deaktiviert sendmail die Auflösung von Aliasen. Hier sehen Sie Einträge aus der Beispiel-aliases-Datei von Red Hat: # Grundlegende System-Aliase -- diese MUESSEN vorhanden sein. mailer-daemon: postmaster postmaster: root Links # Allgemeine Umleitungen für Pseudozugaenge. bin: root daemon: root adm: root lp: root sync: root shutdown: root halt: root mail: root news: root ftp: root # decode abfangen, um Angriffe auf die Sicherheit abzuwehren decode: root # Person, die die Mail von root erhalten soll #root: marc Zeilen, die mit einem Hash-Zeichen (#) beginnen, sind Kommentare und können ignoriert werden. Die aktiven Einträge beginnen mit einem Alias und einem Doppelpunkt und werden von der Empfängeradresse gefolgt. Beachten Sie, dass es sich bei dem Empfänger ebenfalls um einen Alias handeln kann. Beispielsweise verweist mailer-daemon auf postmaster, was eigentlich ein Alias für root ist. Ein -bv-test zeigt die Auswirkungen dieses doppelten Alias: $ sendmail -bv mailer-daemon root... deliverable: mailer local, user root Die meisten Einträge in der Beispiel-aliases-Datei von Red Hat routen Mail, die an Systemzugänge gerichtet ist, an denen man sich nicht anmelden kann, an den Benutzer root. Tatsächlich meldet sich niemand als root an, jedoch werden alle Mails, die an Systemzugänge adressiert sind, an den root-zugang geschickt. Beachten Sie den letzten Kommentar in der Beispiel-aliases-Datei: Dies ist ein auskommentierter Alias für root. Löschen Sie das Hash-Zeichen am Anfang dieser Zeile, und ändern Sie das Empfängerfeld auf die Benutzer-ID des Administratorzugangs, um Mail, die an root adressiert ist, an eine Stelle zu schicken, wo sie auch gelesen wird. Hier ist ein Beispiel: # Person, die die Mail von root erhalten soll root: logan In diesem Beispiel meldet sich der Administrator an dem Zugang logan an, um die Mail von root zu lesen. Ein sendmail -bv-befehl zeigt die Wirkung dieses Alias: 50 Kapitel 2: Auslieferung und Weiterleitung

69 Rechts # sendmail -bv bin logan... deliverable: mailer local, user logan sendmail wertet zuerst bin aus und stellt fest, dass dies auf root verweist. Dann schaut es unter root nach und stellt fest, dass dies auf logan verweist. logan ist kein Alias, deshalb wird an den Zugang logan ausgeliefert. In diesem Fall wurden die Aliase zwei Stufen tief verschachtelt. Standardmäßig durchsucht sendmail bis zu 10 Stufen verschachtelter Aliase und gibt dann den folgenden Fehler aus, wenn der Alias nicht zu einer Auslieferungsadresse aufgelöst werden kann: aliasing/forwarding loop broken (11 aliases deep; 10 max) aliasing/forwarding loop broken Fügen Sie die confmax_alias_recursion-definition zur sendmail-konfiguration hinzu, um die Tiefe zu ändern, bis zu der sendmail nach verschachtelten Aliasen sucht; zum Beispiel: define(confmax_alias_recursion, 5) Die oben gezeigte Zeile verringert die Rekursion auf maximal fünf verschachtelte Aliase. Es gibt jedoch normalerweise keinen vernünftigen Grund, weshalb Sie den von sendmail vorgegebenen Wert ändern sollten. Bei einer Verringerung der Anzahl der Rekursionen verbessert sich die Leistung nicht unbedingt, da der Maximalwert eigentlich nur dann erreicht wird, wenn Sie eine Alias-Schleife erzeugt haben. Sie werden nie mehr Rekursionen haben wollen, denn wenn Sie mehr als 10 Verschachtelungsstufen brauchen, dann haben Sie Ihre Aliase nicht richtig angelegt. Dadurch wird dann auch die Leistung von sendmail beeinflusst. Wie bei den meisten sendmail-definitionen ist der Standardwert am besten. Sie können die Alias-Rekursion für einzelne Aliase steuern, ohne ein m4-makro benutzen oder die Datei sendmail.cf ändern zu müssen. Sie erzwingen die Beendigung der Alias- Auflösung, indem Sie einen Backslash vor die Empfängeradresse für diesen Alias setzen. Zum Beispiel: bin: \root Dies ist ein gestelltes Beispiel. Natürlich werden Sie nicht wirklich Mail an den root- Zugang ausliefern. Dieses gestellte Beispiel eignet sich jedoch gut, um die Auswirkungen des Backslashs zu illustrieren, da die spezielle Rekursion von bin zu root zu logan gerade vor wenigen Absätzen erst beschrieben wurde. Wenn Sie erneut den sendmail -bv-test ausführen, nachdem dieser Alias in die aliases-datenbank eingefügt wurde, erhalten Sie folgendes Ergebnis: # sendmail -bv bin \root... deliverable: mailer local, user \root Hier wird der Alias bin zu root aufgelöst. Dann stoppt die Auflösung der Aliase sendmail löst root nicht weiter zu logan auf. Üblicherweise wird diese Art der Empfängeradresse in Kombination damit verwendet, dass die Mail in eine Datei kopiert oder an ein Programm weitergeleitet wird. Am häufigsten ist sie in der Datei.forward zu finden und nicht in der Datei aliases. Sie wird in einer.forward-datei in Rezept 2.9 benutzt. 2.2 Den Alias0 Missing Map-Fehler beheben und einfache Aliase anlegen 51

70 Nach dem Anlegen der aliases-textdatei führen Sie newaliases aus, um die aliases-datenbank zu erzeugen. Die aliases-datenbank wird eigentlich durch sendmail angelegt; newaliases ist in Wirklichkeit ein symbolischer Link auf das sendmail-programm und entspricht dem Befehl sendmail mit dem Flag -bi. Links Siehe auch Rezept 2.3 ist ein ähnliches Rezept, das zeigt, wie Aliase von einem LDAP-Server gelesen werden können. Das Buch sendmail behandelt die aliases-datenbank in Kapitel Aliase über LDAP lesen Problem Wenn in Ihrer Einrichtung Aliase auf einem LDAP-Server gespeichert werden, müssen Sie sendmail so konfigurieren, dass es Aliase von dem LDAP-Server liest. Lösung Benutzen Sie sendmail -bt -d0.1, um die sendmail-compiler-optionen zu prüfen. Falls sendmail noch nicht mit Unterstützung für LDAP kompiliert wurde, dann kompilieren und installieren Sie es neu, wie in Rezept 1.3 beschrieben. Wurde der LDAP-Server noch nicht so konfiguriert, dass er sendmail-abfragen unterstützt, dann kopieren Sie die Datei sendmail.schema an die passende Stelle auf dem LDAP-Server und aktualisieren die Server-Konfiguration, so dass die Schema-Datei benutzt wird. Rezept 1.3 behandelt die notwendige LDAP-Server-Konfiguration. Sobald der LDAP-Server das sendmail-schema unterstützt, fügen Sie sendmail-aliase in die LDAP-Datenbank ein. Verwenden Sie dabei das Format, das durch dieses Schema definiert wird. Wenn OpenLDAP benutzt wird, wird zuerst eine LDIF-Datei erzeugt, die die LDAP-Records enthält. Anschließend werden diese Records mit ldapadd in die LDAP-Datenbank eingefügt. Der Diskussionsabschnitt zeigt an einem Beispiel, wie dies für Alias-Records erledigt wird. Fügen Sie auf dem sendmail-system der sendmail-konfiguration eine ALIAS_FILE-Definition hinzu, die den String ldap: enthält. Außerdem fügen Sie eine confldap_cluster-definition hinzu, die den gleichen Wert enthält wie das Attribut sendmailmtacluster, das in den Einträgen benutzt wird, die auf dem LDAP-Server angelegt werden. Hier ist ein Beispiel für diese Konfigurationsbefehle: # Setzt den Wert LDAP-Cluster define(`confldap_cluster', `wrotethebook.com') # Teilt sendmail mit, dass diese Aliase über LDAP zur Verfügung stehen define(`alias_file', `ldap:') 52 Kapitel 2: Auslieferung und Weiterleitung

71 Rechts Erzeugen Sie die sendmail-konfigurationsdatei, kopieren Sie sie nach /etc/mail/sendmail.cf, und starten Sie sendmail mit der neuen Konfiguration, wie in Rezept 1.8 beschrieben. Diskussion Dieses Rezept stellt Anweisungen sowohl für den sendmail-administrator als auch für den LDAP-Administrator bereit, da der LDAP-Server richtig installiert, konfiguriert und ausgeführt werden muss. Er muss das sendmail-schema enthalten, um Anfragen von sendmail verstehen und korrekt verarbeiten zu können. Kein Teil dieses Rezepts funktioniert ohne die enge Kooperation des LDAP-Administrators. Um genau zu sein, findet ein Großteil der Konfigurationsarbeit auf dem LDAP-Server statt. Sie sollten eine gewisse Erfahrung mit LDAP haben, bevor Sie versuchen, es zusammen mit sendmail einzusetzen. Um sendmail-aliase in die LDAP-Datenbank aufzunehmen, legen Sie zuerst eine LDIF- Datei an, die entsprechend dem sendmail-schema formatiert ist. Hier ist ein Beispiel, das die Aliase mailer-daemon, postmaster und root aus Rezept 2.2 in die LDAP-Datenbank einfügt: # cat > ldap-aliases dn: sendmailmtakey=mailer-daemon, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtaalias objectclass: sendmailmtaaliasobject sendmailmtaaliasgrouping: aliases sendmailmtacluster: wrotethebook.com sendmailmtakey: mailer-daemon sendmailmtaaliasvalue: postmaster dn: sendmailmtakey=postmaster, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtaalias objectclass: sendmailmtaaliasobject sendmailmtaaliasgrouping: aliases sendmailmtacluster: wrotethebook.com sendmailmtakey: postmaster sendmailmtaaliasvalue: root dn: sendmailmtakey=root, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtaalias objectclass: sendmailmtaaliasobject sendmailmtaaliasgrouping: aliases sendmailmtacluster: wrotethebook.com sendmailmtakey: root sendmailmtaaliasvalue: logan Ctrl-D # ldapadd -x -D "cn=manager,dc=wrotethebook,dc=com" \ > -W -f ldap-aliases Enter LDAP Password: SecretLDAPpassword adding new entry "sendmailmtakey=mailer-daemon, dc=wrotethebook, dc=com" adding new entry "sendmailmtakey=postmaster, dc=wrotethebook, dc=com" adding new entry "sendmailmtakey=root, dc=wrotethebook, dc=com" 2.3 Aliase über LDAP lesen 53

72 In diesem Beispiel wird die LDIF-Datei mit ldap-aliases bezeichnet. Mit Hilfe des Befehls ldapadd werden die Einträge in die LDAP-Datenbank eingefügt. Eine schnelle Überprüfung mit dem Befehl ldapsearch zeigt die neu aufgenommenen Records: # ldapsearch -x '(objectclass=sendmailmtaalias)' \ > sendmailmtakey sendmailmtaaliasvalue version: 2 # # filter: (objectclass=sendmailmtaalias) # requesting: sendmailmtakey sendmailmtaaliasvalue # # mailer-daemon, wrotethebook, com dn: sendmailmtakey=mailer-daemon, dc=wrotethebook, dc=com sendmailmtakey: mailer-daemon sendmailmtaaliasvalue: postmaster Links # postmaster, wrotethebook, com dn: sendmailmtakey=postmaster, dc=wrotethebook, dc=com sendmailmtakey: postmaster sendmailmtaaliasvalue: root # root, wrotethebook, com dn: sendmailmtakey=root, dc=wrotethebook, dc=com sendmailmtakey: root sendmailmtaaliasvalue: logan # search result search: 2 result: 0 Success # numresponses: 4 # numentries: 3 Beachten Sie, dass dieser ldapsearch-befehl mit den Argumenten -h oder -b funktioniert. (-h definiert den LDAP-Servernamen, und -b definiert den standardmäßig als Grundlage verwendeten Distinguished Name.) Dieser Test funktioniert ohne diese Argumente, da der korrekte LDAP-Servername und der Basis-Distinguished-Name in der Datei ldap.conf konfiguriert werden. Wenn diese ldap.conf-werte für die sendmail-abfrage nicht stimmen, dann geben Sie die richtigen -h- und -b-werte auf der ldapsearch-kommandozeile an. Falls Sie -h- und -b-werte vorgeben müssen, damit ldapsearch diesen Test erfolgreich ausführt, muss der sendmail-administrator sendmail die gleichen Werte übergeben. Benutzen Sie die confldap_default_spec-definition, um -h- und -b-werte für sendmail zu setzen. In Rezept 5.9 finden Sie ein Beispiel dafür, wie confldap_default_spec benutzt wird. Der ldapsearch-test zeigt, dass der LDAP-Server nun bereit ist, Anfragen von sendmail nach Aliasen zu beantworten. sendmail muss ebenfalls auf die Zusammenarbeit mit LDAP vorbereitet werden. Dazu muss sendmail mit LDAP-Unterstützung kompiliert werden, wie in Rezept 1.3 beschrieben, und es muss die richtige Konfiguration verwenden. In den meisten Fällen reicht es, der zugrunde liegenden sendmail-konfiguration 54 Kapitel 2: Auslieferung und Weiterleitung

73 Rechts zwei defines hinzuzufügen, um sendmail für das Lesen von Aliasen über LDAP zu konfigurieren. Die beiden Definitionen sind: define(`confldap_cluster', `wrotethebook.com') define(`alias_file', `ldap:') ALIAS_FILE definiert den Ablageort der aliases-datenbank. Anstatt einen Dateipfad als Argument für die ALIAS_FILE-Definition anzugeben, arbeitet das Beispiel mit dem String ldap:, der sendmail anweist, Aliase mit Hilfe des Standard-sendmail-Schemas vom LDAP-Server zu lesen. Die gerade gezeigte ALIAS_FILE-Definition ist äquivalent mit: define(`alias_file', `ldap: -k (&(objectclass=sendmailmtaaliasobject) (sendmailmtaaliasgrouping=aliases) ( (sendmailmtacluster=${sendmailmtacluster}) (sendmailmtahost=$j)) (sendmailmtakey=%0)) -v sendmailmtaaliasvalue') Der erweiterte Befehl zeigt den Suchschlüssel, der durch das Argument -k definiert wird, und den Rückgabewert, der durch das Argument -v definiert wird. Der Rückgabewert ist leicht zu verstehen. Es handelt sich um den Wert, der im Attribut sendmailmtaaliasvalue abgelegt wird. Der Suchschlüssel ist dagegen komplizierter; die Syntax der Suchkriterien ist jedoch identisch mit derjenigen des Befehls ldapsearch, mit der alle LDAP-Administratoren vertraut sein sollten. Der schwierige Teil ist die Tatsache, dass der Schlüssel einfache LDAP-Suchkriterien mit sendmail-makros kombiniert. ${sendmailmtacluster} enthält den Wert, der durch confldap_cluster in der Hauptkonfigurationsdatei definiert wird. $j liefert den voll qualifizierten Namen des lokalen Hosts zurück. In diesem Fall ist %0 der Alias, nach dem sendmail sucht. Alles in allem sucht dieser Schlüssel nach einem Record mit: Einer objectclass eines sendmailmtaaliasobject Einer sendmailmtaaliasgrouping von aliases Entweder einem sendmailmtacluster, das dem Wert entspricht, der durch confldap _CLUSTER definiert wird, oder einem sendmailmtahost-attribut, das den Namen des lokalen Hosts enthält Einem sendmailmtakey, der dem gewünschten Alias entspricht Die Wirkung des Suchschlüssels kann mit Hilfe des Befehls ldapsearch leicht simuliert werden: # ldapsearch -LLL -x '(&(objectclass=sendmailmtaaliasobject) \ > (sendmailmtaaliasgrouping=aliases) \ > ( (sendmailmtacluster=wrotethebook.com) \ > (sendmailmtahost=rodent.wrotethebook.com)) \ > (sendmailmtakey=postmaster))' \ > sendmailmtaaliasvalue dn: sendmailmtakey=postmaster, dc=wrotethebook, dc=com sendmailmtaaliasvalue: root Dieser ldapsearch-befehl zeigt den Schlüssel, den sendmail benutzen würde, um den Alias postmaster nachzusehen, wenn er auf einem Host namens rodent.wrotethebook.com ausgeführt werden würde, wobei confldap_cluster als wrotethebook.com definiert wäre. Der zurückgelieferte Wert ist root. 2.3 Aliase über LDAP lesen 55

74 Dieses Rezept verwendet die Definition confldap_cluster, um einen Wert für ${sendmailmtacluster} zu setzen, da alle Einträge, die in diesem Rezept in die LDAP- Datenbank eingefügt worden sind, ein sendmailmtacluster-attribut enthalten. Um diesen LDAP-Records zu entsprechen, müssen sendmail-abfragen den korrekten Wert für ${sendmailmtacluster} enthalten. Die Alternative zur Benutzung eines Cluster-Wertes besteht darin, LDAP-Datenbankeinträge für einzelne Hosts zu definieren. In diesem Fall verwendet der LDAP-Eintrag nicht das Attribut sendmailmtacluster. Stattdessen nimmt er das Attribut sendmailmtahost. Der Wert, der dem Attribut zugewiesen wird, ist der voll qualifizierte Hostname eines bestimmten Hosts. Falls Sie beschließen, LDAP-Einträge für einzelne Hosts anzulegen, muss das Attribut sendmailmtahost in jedem LDAP-Eintrag angegeben werden. Allerdings muss für sendmail kein spezieller Host-Wert konfiguriert werden, da sendmail den Wert in $j nutzt. Wenn das Attribut sendmailmtacluster in den LDAP-Records nicht genutzt wird, dann ist die confldap_cluster-definition für die sendmail-konfiguration nicht erforderlich. Wird jedoch die confldap_cluster-definition nicht verwendet, dann kann sendmail nur solche LDAP-Records beziehen, die ein sendmailmtahost-attribut enthalten, das dem durch $j zurückgelieferten Wert entspricht. Der Cluster-Wert bietet eine Möglichkeit für eine Gruppe von Hosts, gemeinsame LDAP-Daten miteinander zu teilen. Dies ähnelt einer NIS-Domain. Die Beispieldefinition confldap_cluster benutzt den DNS-Domainnamen als Cluster-Wert. Der Cluster-Wert ist ist jedoch beliebig und muss kein NIS- oder DNS-Domainname sein. Nach dem Konfigurieren des LDAP-Servers und des sendmail-systems zeigt ein Test, dass Aliase erfolgreich vom LDAP-Server bezogen werden. Die Wirkung der Aliase kann man sehen, wenn man den Befehl sendmail -bv ausführt: # sendmail -bv -Cgeneric-linux.cf mailer-daemon root... deliverable: mailer local, user root # sendmail -bv mailer-daemon logan... deliverable: mailer local, user logan Dieser Test zeigt den LDAP-Server in Aktion. Wenn der erste Test mit der generischen Konfiguration ausgeführt wird, wird der Alias mailer-daemon mit Hilfe der lokalen aliases- Datenbank aufgelöst, da die generische Konfiguration den vorgegebenen ALIAS_FILE-Pfad nicht überschreibt. Der zweite Test verwendet die sendmail-konfiguration, die in diesem Rezept erzeugt wurde. Diese verweist auf den LDAP-Server. Der Alias mailer-daemon wird mit Hilfe der drei Records aufgelöst, die weiter vorn in diesem Abschnitt der LDAP-Datenbank hinzugefügt worden waren. Siehe auch In den anderen Rezepten dieses Kapitels finden Sie Beschreibungen der verschiedenen Alias-Formate aller Formate, die von einem LDAP-Server gelesen werden können. Informationen über LDAP finden Sie in Understanding and Deploying LDAP Directory Services von Howes, Smith und Good (Macmillan) sowie in LDAP System Administra- Links 56 Kapitel 2: Auslieferung und Weiterleitung

75 Rechts tion von Gerald Carter (O Reilly). Die Datei cf/readme behandelt dieses Thema im Abschnitt Using LDAP for Aliases, Maps, and Classes. Das Buch sendmail geht auf die ALIAS_FILE-Definition in Abschnitt und auf die confldap_cluster-definition in Abschnitt ein. 2.4 Red Hat 7.3 so konfigurieren, dass es Aliase von einem NIS-Server ausliest Problem Sie wollen NIS verwenden, um auf die aliases-datenbank auf einem Red Hat 7.3-System zuzugreifen. Lösung Wechseln Sie in das Verzeichnis /etc/mail, und legen Sie die Datei service.switch an. Hier ist ein Beispiel: # cd /etc/mail # cat - > service.switch aliases nis files hosts dns files passwd files nis Diskussion Es werden keine m4-konfigurationsbefehle benötigt, um die Unterstützung für die Datei service.switch zu aktivieren sie steht standardmäßig zur Verfügung. Wahrscheinlich funktioniert die grundlegende sendmail-konfiguration, die bereits auf Ihrem System installiert ist, mit dieser Datei; auf jeden Fall tut dies die generische Konfiguration, die in Rezept 1.8 besprochen wird. Durch den von Sun Microsystems entwickelten Network Information Service (NIS) werden viele Systemadministrationsdatenbanken über das Netzwerk bereitgestellt. NIS erlaubt es einer Einrichtung, wichtige Konfigurationsdateien für alle Unix-Clients zentral zu steuern und zu warten. Die aliases-datenbank ist eine der Dateien, die durch das NIS zentral betreut und erreicht werden können. Eine Service-Switch-Datei definiert die Quellen verschiedener Systemadministrationsdateien sowie die Reihenfolge, in der diese abgefragt werden sollen. service.switch ist der Standarddateiname, den sendmail für eine Service-Switch-Datei verwendet, falls das System keine Service-Switch-Datei besitzt, die sendmail benutzen kann. 6 Auf einem Red-Hat- 6 Red Hat 7.3 besitzt eine Service-Switch-Datei namens /etc/nsswitch.conf. Wie die Manpage jedoch verdeutlicht, wird der aliases-eintrag in der Datei nsswitch.conf ignoriert. 2.4 Red Hat 7.3 so konfigurieren, dass es Aliase von einem NIS-Server ausliest 57

76 Linux-System suchen aktuelle Versionen im Verzeichnis /etc/mail nach service.switch; frühere Versionen haben im Verzeichnis /etc nach der Datei gesucht. Der Pfad auf die sendmail-service-switch-datei kann mit Hilfe der Definition confservice_switch_file geändert werden. Es ist jedoch im Allgemeinen einfacher, die Datei service.switch in das Verzeichnis /etc/mail zu setzen, wo sendmail und die meisten Administratoren sie auch vorzufinden erwarten. Die sendmail-datei service.switch ist viel kürzer als die Service-Switch-Datei des Systems, da sendmail nur an drei Arten von Systemadministrationsinformationen interessiert ist: Mail-Aliasen, Host-Informationen und Benutzerinformationen. Die Datei service.switch enthält einen Eintrag für alle Arten von Informationen. Diese Informationen werden durch den Namen der Datei identifiziert, die traditionell diese Informationen bereitgestellt hat: aliases, hosts oder passwd. Dem Namen folgt eine Liste von Quellen für diese Art von Informationen. Der Aliases-Eintrag im Beispiel lautet: aliases nis files NIS wird zuerst aufgeführt. Das bedeutet, dass sendmail als Erstes versucht, einen Alias über das NIS aufzulösen. Es sucht nur dann nach dem Alias in der lokalen aliases-datei, wenn NIS den Alias nicht auflösen kann. Daher werden Aliase, die nur in der lokalen Datei existieren, trotzdem aufgelöst; Aliase in der NIS-Map-Datei haben jedoch Vorrang. In der Datei service.switch können verschiedene Informationsquellen angegeben werden: files Die lokalen Dateien /etc/mail/aliases, /etc/hosts und /etc/passwd. nis NIS Version 2, das für aliases-, hosts- und passwd-informationen verwendet werden kann. nisplus NIS Version 3, das für aliases, hosts- und passwd-informationen verwendet werden kann. ldap LDAP kann für aliases-, hosts- und passwd-informationen verwendet werden. Rezept 2.3 zeigt die korrekte Methode zum Lesen von Aliasen von einem LDAP-Server. hesiod Der Dienst Hesiod kann für aliases-, hosts- und passwd-informationen verwendet werden, kommt aber vorrangig für passwd-informationen zum Einsatz. dns Das DNS kann für hosts-informationen verwendet werden. Um einen dieser Dienste zu benutzen, muss Ihr System als Client für diesen Dienst auftreten können und entsprechend konfiguriert sein. Die Konfiguration dieser Dienste würde allerdings den Rahmen dieses Buches sprengen. Links 58 Kapitel 2: Auslieferung und Weiterleitung

77 Rechts Einige Tests rund um unser Rezept herum zeigen die unmittelbare Wirkung unserer Lösung: # praliases bin bin:craig # ypmatch bin aliases root # sendmail -bv bin craig... deliverable: mailer local, user craig # cd /etc/mail # cat - > service.switch aliases nis files hosts dns files passwd files nis Ctrl-D # sendmail -bv bin root... deliverable: mailer local, user root # praliases kathy kathy:kathy@chef.wrotethebook.com # ypmatch kathy aliases Can't match key kathy in map mail.aliases. Reason: No such key in map # sendmail -bv kathy kathy@chef.wrotethebook.com... deliverable: mailer esmtp, host chef.wrotethebook.com., user kathy@chef.wrotethebook.com Der erste praliases-befehl zeigt den Wert, der für den Alias bin in der lokalen aliases- Datenbank gespeichert ist, und der erste ypmatch-befehl zeigt den Wert, der für diesen Alias in der NIS-Datenbank gespeichert ist. Die lokale Datei bildet bin auf craig ab, und die NIS-Datenbank bildet bin auf root einen vernünftigeren Wert ab. Der erste sendmail -bv-test zeigt, dass die Auslieferungsadresse aus der lokalen Datei verwendet wird. Dann bereiten wir unser einfaches Rezept vor. Sobald die Datei service.switch erzeugt wurde, wird der Test mit sendmail -bv erneut ausgeführt. Dieses Mal ist die Auslieferungsadresse, die für bin benutzt wird, diejenige, die auf dem NIS-Server definiert wurde. Unser einfaches Rezept veranlasst das lokale System ganz eindeutig, NIS zum Auflösen der Aliase zu verwenden. Die letzten drei Zeilen in dem Test unterstreichen die Tatsache, dass die lokale Datei weiterhin benutzt wird, wenn das NIS einen Alias nicht auflösen kann. In diesem Fall gibt es für kathy einen Alias in der lokalen Datei, nicht jedoch in der NIS-Map. Mail wird aber weiterhin an kathy ausgeliefert. Dazu kommt der Wert aus der lokalen Datei zum Einsatz. Alternativen Eine Alternative zum Anlegen einer service.switch-datei besteht darin, mit Hilfe der ALIAS_FILE-Definition in sendmail.cf die Informationsquellen sowie die Reihenfolge zu definieren, in der sie durchsucht werden. Die folgende Definition würde beispielsweise das Gleiche tun wie der Aliases-Eintrag aus der Datei service.switch in unserem Rezept: define(alias_file, `nis:mail.aliases,/etc/mail/aliases') 2.4 Red Hat 7.3 so konfigurieren, dass es Aliase von einem NIS-Server ausliest 59

78 Diese Definition teilt sendmail mit, dass die erste Quelle für Alias-Informationen die NIS- Map mail.aliases und die zweite Quelle die lokale Datei /etc/mail/aliases ist. Um diese alternative Lösung zu implementieren, fügen Sie diese Zeile in die Datei sendmail.mc ein, erstellen die Datei sendmail.cf neu, kopieren diese nach /etc/mail und starten sendmail neu. Diese alternative Lösung ist schwieriger zu implementieren und schwieriger zu warten als die Datei service.switch. Das Ändern der Suchreihenfolge erfordert das Anpassen der sendmail.mc, das Neuerstellen der sendmail.cf, das Kopieren der Datei sendmail.cf in das richtige Verzeichnis und das Neustarten von sendmail. Um die Suchreihenfolge mit Hilfe der Datei service.switch zu ändern, ändern Sie einfach die Aliases-Zeile in dieser Datei. Auch hier gilt wieder, dass die besten Lösungen für die sendmail-konfiguration es nicht unbedingt erfordern, Änderungen an der Datei sendmail.cf vorzunehmen. Ein letzter Hinweis zu dieser Alternative: Benutzen Sie nicht beide Lösungen gleichzeitig. Würden wir sowohl die Datei service.switch, die wir in unserem Rezept angelegt haben, als auch die gerade gezeigte ALIAS_FILE-Definition benutzen, würde sendmail zuerst die Anweisungen aus der Datei service.switch befolgen und den Alias über NIS und die lokale aliases-datei suchen. Anschließend würde sendmail alle optionalen Verarbeitungen durchführen, die durch die ALIAS_FILE-Definition gefordert werden würden. Das heißt, es würde den gleichen Alias wieder über das NIS nachsehen. Das ist zwar kein großes Problem, bringt aber einen unnötigen Verarbeitungsaufwand mit sich. Links Siehe auch Rezept 2.5 zeigt eine Lösung für ein ähnliches Konfigurationsproblem für Solaris. Das Buch sendmail behandelt die Datei service.switch in Abschnitt , die Definition confservice_switch_file in Abschnitt und die Definition ALIAS_FILE in Abschnitt Das Buch Managing NFS and NIS, 2. Auflage, von Stern, Eisler und Labiaga (O Reilly) behandelt NIS im Detail. 2.5 Solaris 8 so konfigurieren, dass es Aliase von einem NIS-Server ausliest Problem Sie müssen ein Solaris 8-System so konfigurieren, dass es Aliase von einem NIS-Server ausliest. Lösung Ändern Sie den Aliases-Eintrag in der Datei /etc/nsswitch.conf folgendermaßen: aliases: nis files 60 Kapitel 2: Auslieferung und Weiterleitung

79 Rechts Diskussion Es sind keine m4-konfigurationsbefehle erforderlich, um die Datei nsswitch.conf auf einem Solaris-System zu ändern. Die grundlegende sendmail-konfiguration, die bereits auf Ihrem System installiert ist, sollte funktionieren. Falls Ihr System noch nicht für die Ausführung von sendmail konfiguriert ist, verwenden Sie die Datei generic-solaris.mc als Ausgangspunkt, um Ihren Solaris-Server zum Laufen zu bringen. Sowohl das Linux- als auch das Solaris-System besitzt eine systemweite Service-Switch- Datei namens /etc/nsswitch.conf. Der Unterschied zwischen beiden besteht darin, dass das System mit Red Hat Linux 7.3 keinen Aliases-Eintrag in dieser Datei hat, Solaris dagegen schon. Wenn das System eine aktive System-Service-Switch-Datei aufweist, benutzt sendmail diese Datei und ignoriert die Datei, die durch die confservice_switch_file- Definition bezeichnet wird. Die korrekte Lösung für das Solaris-System besteht darin, die Quellen der Alias-Informationen in der nsswitch.conf-datei zu identifizieren. Jede Quelle, die mit der nsswitch.conf-syntax und mit sendmail kompatibel ist, kann angegeben werden. In der Manpage der nsswitch.conf finden Sie Informationen über die Syntax, die Ihr Computer unterstützt. Die Rezepte 2.3 und 2.4 zeigen ebenfalls Aliase, die von einem externen Server gelesen werden. Allerdings gehen Rezept 2.2 und die meisten Beispiele aus diesem Buch davon aus, dass es sich bei der aliases-datenbank um eine lokale Datei handelt, die sich direkt auf dem sendmail-system befindet. Das ist üblicherweise so und es gibt gute Gründe dafür. Aliase werden nur für solche Mailer gesucht, bei denen das Flag A gesetzt ist. Auf den meisten Systemen weist nur der local-mailer dieses Flag auf, was bedeutet, dass Aliase nur für eingehende Mails gelten, die für eine Auslieferung durch den Mailer local angenommen werden. Eine zentralisierte Datenbank, die Aliase für alle Benutzer in der Einrichtung enthält, wird nur von einem Server benötigt, der Mails für alle Benutzer dieser Einrichtung akzeptiert. Bei den meisten Unix-Workstations ist die Masse der Einträge in der zentralisierten Datenbank unbenutzt es werden nur solche Benutzer nachgesehen, die tatsächlich ihre Mails auf den jeweiligen Workstations erhalten. Durch das Platzieren der aliases-datei direkt auf dem System, das diese benötigt, wird die Leistung verbessert und der Netzwerk-Overhead verringert. Außerdem verbessert sich die Sicherheit Daten, die über das Netzwerk verschickt werden, können zerstört und gefälscht werden, und durch das Hinzufügen eines weiteren Protokolls, in diesem Fall NIS, wird das System für alle Bugs anfällig, die in diesem Protokoll auftauchen könnten. Sicherheit, Leistungsfähigkeit und Eignung schränken den Bedarf an einer zentralisierten aliases-datenbank ein, die über das Netzwerk zur Verfügung steht. Überlegen Sie genau, ob es wirklich nötig ist, die aliases-datenbank auf einen externen NIS- oder LDAP-Server auszulagern, bevor Sie weitermachen. Falls Sie jedoch beschließen, Aliase von einem externen Server zu lesen, kann sendmail dazu konfiguriert werden. 2.5 Solaris 8 so konfigurieren, dass es Aliase von einem NIS-Server ausliest 61

80 Siehe auch Rezept 2.4 beschreibt eine Lösung für das gleiche Problem auf anderen Betriebssystemen. Die Datei nsswitch.conf wird in den Büchern TCP/IP-Netzwerk-Administration, dritte Auflage, von Craig Hunt (O Reilly) und Managing NFS and NIS, zweite Auflage, von Stern, Eisler und Labiaga (O Reilly) beschrieben. Links 2.6 Weiterleitung an eine externe Adresse Problem Mail, die an den lokalen Host adressiert ist, muss für die endgültige Auslieferung an einen anderen Host weitergeleitet werden. Lösung Fügen Sie für jeden Benutzer, dessen Mail an ein anderes System weitergeleitet werden muss, einen Alias in die aliases-datei ein. Das Empfängerfeld des Alias-Eintrags muss eine vollständige -Adresse inklusive des Host-Anteils enthalten. Nach dem Hinzufügen des gewünschten Alias erstellen Sie die aliases-datenbankdatei mit dem Befehl newaliases neu. Diskussion Es gibt viele Gründe, weshalb Mail, die an Ihr System ausgeliefert wurde, anschließend an einen anderen Host weitergeleitet werden muss. Beispielsweise könnte ein Benutzer seine Adressen geändert haben, ein Benutzer könnte mehrere Adressen besitzen, aber nur eine davon lesen, oder Ihr Host könnte ein Mail-Hub sein, der Mail für mehrere unterschiedliche Systeme sammelt. Ein Mail Exchanger stellt ein gutes Beispiel für ein System dar, das Mail empfängt, die zur Auslieferung an einen anderen Host weitergeleitet werden muss. Ein Mail Exchanger empfängt Mail, die an andere Hosts adressiert ist, und akzeptiert diese Mail als lokale Mail. (In Rezept 2.1 wird dies näher erläutert.) Es ist jedoch möglich, dass nicht jeder Benutzer auf jedem Host, der Mail an den Mail Exchanger routet, einen lokalen Zugang auf dem Mail Exchanger besitzt. Zwei sendmail -bv-tests unterstreichen dies: # sendmail -bv pat@wrotethebook.com pat@wrotethebook.com... deliverable: mailer local, user pat # sendmail -bv andy@wrotethebook.com andy@wrotethebook.com... User unknown Im ersten Fall ist pat ein Benutzerzugang auf dem Mail Exchanger, so dass die Mail direkt an die lokale Mailbox von Pat ausgeliefert werden kann. Im zweiten Fall ist andy kein 62 Kapitel 2: Auslieferung und Weiterleitung

81 Rechts lokaler Benutzerzugang, so dass Mail mit dem Fehler»User unknown«abgewiesen wird. Nehmen Sie nun jedoch an, dass diese Mail nicht mit einem Fehler zurückkommen soll, weil Andy ein Angestellter ist, dem es erlaubt ist, Mail unter der Adresse in Empfang zu nehmen. Andy hat keinen Zugang auf dem Mail Exchanger, besitzt aber einen gültigen Zugang auf einem anderen System in der Domain wrotethebook.com. Auf diesem System liest Andy dann auch seine Mail. Der Fehler»User unknown«wird durch das Anlegen der korrekten Aliase aufgelöst. Beispielsweise könnten wir auf unserem Beispiel-Mail-Exchanger den folgenden Alias für andy anlegen: andy: Der Alias steht zur Verfügung, sobald newaliases ausgeführt wurde. Wenn Sie nun erneut den sendmail -bv-test durchführen, der zuvor den»user unknown«-fehler erbrachte, erhalten Sie dieses Ergebnis: # sendmail -bv andy@wrotethebook.com andy@rodent.wrotethebook.com... deliverable: mailer esmtp, host rodent.wrotethebook.com., user andy@rodent.wrotethebook.com Der Fehler ist verschwunden. Nun wird Mail, die an andy@wrotethebook.com adressiert ist, über den Mailer esmtp an andy@rodent.wrotethebook.com weitergeleitet. Entfernte Benutzer müssen nicht einmal wissen, dass es überhaupt einen Host namens rodent gibt. Sie senden Mail an benutzer@wrotethebook.com, und der Mail Exchanger leitet diese zur Auslieferung an den korrekten Host weiter. Siehe auch Rezept 2.2 liefert Anweisungen zum Erstellen einer einfachen aliases-datei. Das Buch sendmail behandelt die aliases-datenbank in Kapitel Mailinglisten anlegen Problem Sie wurden gebeten, Mailinglisten anzulegen. Lösung Legen Sie für jede Mailingliste einen Eintrag in der aliases-textdatei an. Das Alias-Feld enthält dabei den Namen der Mailingliste, und im Empfängerfeld steht eine durch Kommata getrennte Liste aller Empfänger der Mailingliste. Fügen Sie den besonderen Alias hinzu, den sendmail verwendet, um Fehlermeldungen auszuliefern, die die Mailingliste betreffen. Dieser besondere Alias muss einen Namen im Format owner-liste tragen, wobei owner- ein notwendiger String ist und liste der Name 2.7 Mailinglisten anlegen 63

82 der Liste, für die dieser Eigentümer-Alias deklariert wird. Falls die Liste beispielsweise den Namen admin trägt, muss dieser Alias owner-admin heißen. Das Empfängerfeld des besonderen Alias sollte die Adresse enthalten, an die die Fehler geschickt werden. Legen Sie außerdem einen Alias an, mit dessen Hilfe Benutzer die Person erreichen können, die die Mailingliste wartet. Das Format des Alias-Feldes sollte liste-request lauten, wobei liste der Name der Liste ist, für die dieser Request-Alias deklariert wird. -request ist ein notwendiger String. Heißt die Liste beispielsweise admin, dann sollte dieser Alias admin-request genannt werden. Führen Sie newaliases aus, um die aliases-datenbankdatei zu erstellen: # newaliases /etc/mail/aliases: 43 aliases, longest 30 bytes, 592 bytes total Links Diskussion Um zu zeigen, wie Mailinglisten erzeugt werden, lassen Sie uns annehmen, dass wir gebeten wurden, drei unterschiedliche Mailinglisten anzulegen: Mail, die an root adressiert ist, soll an die normalen Zugänge von drei Leuten gesandt werden, die den Mailserver administrieren. Der Chef möchte eine Mailingliste für den Verwaltungsrat haben, der aus den vier Abteilungsleitern und ihren wissenschaftlichen Beisitzern besteht. Außerdem soll ein Archiv aller Mails vorgehalten werden, die an diese Mailingliste geschickt werden. Der Chef möchte eine Mailingliste für alle Mail-Benutzer haben. Legen Sie dazu eine admin-mailingliste für die Systemadministratoren, eine chefs-liste für die Abteilungsleiter und eine angestellt ingliste für alle Mail-Benutzer an: # Mailinglisten admin: alana, logan, pat owner-admin: admin-request admin-request: alana chefs: reba, sara, tyler@example.com, jane@rodent.wrotethebook.com, kathy, /home/payton/chefs-archive owner-chefs: chefs-request chefs-request: alana angestellte: owner-angestellte: angestellte-request: :include:/etc/mail/allusers angestellte-request alana Bearbeiten Sie als Nächstes alle Aliase in der Datei, die die neu erzeugten Aliase referenzieren müssen. In diesem Beispiel wollen wir, dass Mail, die an root adressiert ist, an den neu erzeugten Alias admin geschickt wird. Wir führen also folgende Änderung durch: # Person, die die Mail von root erhalten soll root: admin 64 Kapitel 2: Auslieferung und Weiterleitung

83 Rechts Die erste Mailingliste ist am einfachsten. Sie definiert drei lokale Empfänger (alana, logan und pat), die Kopien der Mail erhalten, die an admin adressiert ist. Die Adresse admin kann direkt benutzt werden, um diese drei Benutzer zu erreichen, wie der folgende sendmail -bv-befehl zeigt: # sendmail -bv admin pat... deliverable: mailer local, user pat logan... deliverable: mailer local, user logan alana... deliverable: mailer local, user alana Wir wollen außerdem, dass Mail, die an root adressiert ist, an die drei Administratoren gesandt wird. Zu diesem Zweck haben wir die aliases-textdatei derart bearbeitet, dass der Alias root auf die Mailingliste admin verweist. Ein weiterer sendmail -bv-befehl zeigt die Wirkung dieser Aktion: # sendmail -bv bin pat... deliverable: mailer local, user pat logan... deliverable: mailer local, user logan alana... deliverable: mailer local, user alana In diesem Fall sieht sendmail den Alias bin nach und stellt fest, dass dieser auf root verweist. Anschließend sucht es den Alias root und sieht, dass dieser auf admin zeigt. Wenn es dann admin nachsieht, stellt es fest, dass dieser Alias auf alana, logan und pat verweist. Eine Suche nach diesen Namen erbringt das Ergebnis, dass es sich jeweils um Auslieferungsadressen handelt, die über den Mailer local erreichbar sind. Unmittelbar auf den Alias admin folgt ein Alias mit dem Namen owner-admin. Dabei handelt es sich um einen besonderen Alias, den sendmail vorzufinden erwartet. sendmail verwendet ihn, um Fehlermeldungen auszuliefern, wenn es Fehler beim Ausliefern der Mail an die Mailingliste admin entdeckt. Der nächste Alias, admin-request, wird nur benötigt, weil der Alias owner-admin auf ihn verweist; es ist allerdings üblich, Aliase in diesem Format zu verwenden, da diese zwei Vorteile mit sich bringen. Erstens erwarten viele Benutzer, dass sie unter einem Alias im Format liste-request die Person erreichen können, die die Liste betreut vorausgesetzt, dieser Alias entspricht den Vorstellungen der Benutzer. Einen zweiten Vorteil bringt das Empfängerfeld des Alias owner-liste mit sich, das verwendet wird, um die Unix-Zeile From und den Return-Path:-Header zu erzeugen. Denken Sie an unser Beispiel zurück: Würde der Alias owner-admin direkt auf alana verweisen, dann würden der Return-Path: und die Unix-Zeile From für Mail von der admin-mailingliste so aussehen, als kämen sie von alana. Benutzer, die sich die Header näher anschauen und die Unix-From-Information sehen, könnten annehmen, dass die Mail direkt durch alana an sie geschickt worden wäre statt von der Mailingliste. Indem der Alias owner-admin auf admin-request verweist, sehen diese Benutzer admin-request als Quelle der Mail, was für die meisten Leute weniger verwirrend sein dürfte. Da admin-request vor der endgültigen Auslieferung zu alana aufgelöst wird, gelangen Fehler zur Analyse an alana zurück. Die Benutzer sind glücklich, und der Zweck des Alias owner-admin ist erfüllt. 2.7 Mailinglisten anlegen 65

84 Wie die meisten formellen Mailinglisten besitzt auch die Mailingliste chefs die oben beschriebenen Aliase owner-liste und liste-request. Die Mailingliste chefs liefert Mails an die vier Abteilungsleiter und ihren Berater aus. Drei der Empfänger (reba, sara und kathy) sind lokale -Zugänge. Zwei (tyler und jane) sind Aliase, die auf Benutzerzugänge auf anderen Hosts verweisen. Der sechste Empfänger der Mailingliste chefs ist keine Person es handelt sich um eine Datei. Wenn der vollständige Pfadname einer Datei auf der rechten Seite eines Alias definiert wird, dann wird sendmail veranlasst, eine Kopie der Mail an diese Datei anzuhängen. 7 Auf diese einfache Weise können Sie ein Archiv für eine Mailingliste anlegen. Dies ist für eine solch kleine Mailingliste wie chefs völlig ausreichend. Der Aufwand, der damit verbunden ist, dass sendmail Mail in eine Datei kopiert, sorgt jedoch dafür, dass diese Lösung für große Mailinglisten mit einem hohen Aufkommen an Mails nicht besonders geeignet ist. Eine bessere Lösung für solche Listen besteht darin, die Mail durch sendmail an ein externes Programm schicken zu lassen, das das Archiv schreibt. Rezept 2.9 zeigt, wie sendmail Mail an ein Programm leitet. Beachten Sie, dass die sechs Empfänger der Mailingliste chefs auf drei unterschiedlichen Zeilen definiert werden. Wenn eine Zeile in der aliases-datei mit Whitespace beginnt (Leerzeichen oder Tabulatorzeichen), dann wird die Zeile als Fortsetzung der vorangegangenen Zeile behandelt. Das bedeutet, dass die Empfängerliste für einen Alias mehrere Zeilen lang sein kann. Die Mailingliste angestellte sendet Mail an alle Benutzer. Sie besitzt die gleichen unterstützenden owner-liste- und liste-request-aliase wie die anderen Mailinglisten. Am interessantesten an dieser Mailingliste ist die :include:-syntax auf der Empfängerseite des Alias. Die :include:-syntax veranlasst sendmail, eine Liste mit Empfängern aus einer externen Datei zu lesen. Im Beispiel liest sendmail eine Datei namens /etc/mail/allusers, in der die Auslieferungsadressen aller Personen enthalten sind, die von unserem Beispiel- Mailserver bedient werden. Auf unserem kleinen Beispielsystem enthält die Datei allusers zehn lokale und drei externe Benutzer. sendmail fügt die Datei in die aliases-datenbank als Empfänger der Mailingliste angestellte ein. Auch hier zeigt ein sendmail -bv-befehl dies: # sendmail -bv angestellte craig... deliverable: mailer local, user craig kathy... deliverable: mailer local, user kathy pat... deliverable: mailer local, user pat logan... deliverable: mailer local, user logan alana... deliverable: mailer local, user alana payton... deliverable: mailer local, user payton david... deliverable: mailer local, user david reba... deliverable: mailer local, user reba sara... deliverable: mailer local, user sara jay... deliverable: mailer local, user jay 7 Die Datei muss durch einen vollständigen Pfadnamen identifiziert werden, der mit der Wurzel (/) beginnt. Links 66 Kapitel 2: Auslieferung und Weiterleitung

85 Rechts deliverable: mailer esmtp, host crab.wrotethebook.com., user deliverable: mailer esmtp, host rodent.wrotethebook.com., user deliverable: mailer esmtp, host rodent.wrotethebook.com., user Zehn der Empfänger sind lokale Benutzer, deren Mail über den Mailer local ausgeliefert wird. Bei dreien handelt es sich um externe Benutzer, deren Mail durch den Mailer esmtp an andere Hosts in der lokalen Domain weitergeleitet wird. In keiner unserer Beispiel-Mailinglisten hatten wir doppelte Empfänger. Beispielsweise wurde die admin-liste zu alana, logan und pat aufgelöst drei eindeutigen Benutzeradressen. Wie wir jedoch zuvor sahen, können mehrere Aliase auf den gleichen Empfänger verweisen. Speziell alle Systembenutzerzugänge unseres Beispielsystems, an denen man sich nicht anmelden kann, verweisen auf root. Was würde passieren, wenn wir eine Mailingliste hätten, die mehrere dieser Zugänge enthielte? Zum Beispiel: sysusers: daemon, bin, ftp, root, alana owner-sysusers: sysusers-request sysusers-request: alana In dieser Beispiel-Mailingliste werden daemon, bin, ftp und root jeweils zu root aufgelöst. sendmail erkennt dieses Problem und löscht die doppelten Empfänger. Wenn Mail an diese Beispiel-Mailingliste adressiert ist, empfängt root nur eine Kopie dieser Mail. Würde sendmail die Duplikate nicht löschen, dann würde root vier Kopien exakt der gleichen Nachricht bekommen. Siehe auch Das Buch sendmail behandelt die aliases-datenbank in Kapitel 12 und liefert in Kapitel 13 Informationen über Mailinglisten. 2.8 Ehemalige Benutzer auf neue Adressen migrieren Problem Sie wurden gebeten, ehemaligen Benutzern beim Umzug auf ihre neuen Auslieferungsadressen zu helfen. Lösung Fügen Sie der sendmail-konfiguration die Funktion redirect hinzu. Dazu verwenden Sie den folgenden FEATURE-Befehl: dnl Notify senders about discontinued addresses FEATURE(`redirect') 2.8 Ehemalige Benutzer auf neue Adressen migrieren 67

86 Legen Sie die sendmail.cf-datei neu an, kopieren Sie die neue sendmail.cf-datei nach /etc/ mail, und starten Sie sendmail neu, wie in Rezept 1.8 beschrieben. Fügen Sie für jeden ehemaligen Benutzer einen Eintrag in die aliases-textdatei ein. Das Alias-Feld des Eintrags ist der lokale Benutzername, unter dem der ehemalige Benutzer früher seine Mail empfangen hat. Das Empfängerfeld ist die neue -Adresse des Benutzers, bei der der String.REDIRECT an das Ende der Adresse angehängt ist. Führen Sie wie immer, wenn die aliases-datei aktualisiert wurde, das newaliases-skript aus: # newaliases /etc/mail/aliases: 45 aliases, longest 30 bytes, 670 bytes total Diskussion Die ersten beiden Schritte im Lösungsabschnitt erzeugen eine sendmail-konfiguration, die die Funktion redirect enthält. Falls natürlich Ihre Konfiguration bereits diese Funktion enthält (wie z.b. die generische Linux-Konfiguration, die in Rezept 1.8 beschrieben wird), können Sie diese beiden ersten Schritte überspringen und direkt mit dem Anlegen der Aliase beginnen. Lassen Sie uns als Beispiel annehmen, dass wir noch sechs Monate lang Mails für einen ehemaligen Angestellten verarbeiten wollen. Michael hat kürzlich das Unternehmen verlassen. Richtige Kundenbeziehungen sind der erste und wichtigste Schritt beim Umstellen von Michaels Mail. Jay hat all seine Kunden übernommen. Wir wollen nun, dass diese Kunden ihre Geschäftskorrespondenz an Jay richten. Michael hat während seiner letzten Woche im Unternehmen Jay mit zu seinen lokalen Kunden genommen und ihn außerdem per Konferenzschaltung seinen externen Kunden vorgestellt. Die Kunden wurden benachrichtigt, und die Geschäftspost sollte nun in die richtige Richtung gehen. Wenn die Verwaltung die Kundenbeziehungen vernachlässigt, kann ein Systemadministrator daran kaum etwas ändern. Sie können jedoch sicherstellen, dass Michael seine persönlichen Mails bekommt, indem Sie einen Alias anlegen, um die Mail an seine neue Adresse weiterzuleiten: michael: michael@new.job.ora.com Michael wird jeden Monat eine Erinnerung gesandt, dass seine Mail-Weiterleitung in sechs Monaten geschlossen wird. Sechs Monate nach seinem Weggang aus seiner Abteilung wird der Alias michael folgendermaßen bearbeitet: michael: michael@new.job.ora.com.redirect Zuerst wird Michaels Mail an seine neue Adresse weitergeleitet, wie dieser -bv-test zeigt: # sendmail -bv michael@wrotethebook.com michael@new.job.ora.com... deliverable: mailer esmtp, host new.job.ora.com, user michael@new.job.ora.com Links 68 Kapitel 2: Auslieferung und Weiterleitung

87 Rechts Die Weiterleitung kann aber nicht unendlich lange bestehen bleiben. Solange die Mail durchkommt, wird es immer Absender geben, die ihre Adressbücher nicht aktualisieren. An irgendeiner Stelle müssen Sie einen Schnitt machen und damit aufhören, die Mail weiterzuleiten. Im Beispiel haben wir eine kleine Site und sind daher gewillt, die Mail sechs Monate lang weiterzuleiten. Bei einer größeren Site könnte es dagegen sein, dass man sich gar nicht auf eine Weiterleitung einlässt. Am Ende der sechs Monate wird die Pseudodomain.REDIRECT zu dem Alias hinzugefügt, um die Weiterleitung zu beenden. Die Wirkung der Pseudodomain.REDIRECT kann durch einen sendmail -bv-test belegt werden: # sendmail -bv michael@wrotethebook.com User has moved; please try <michael@new.job.ora.com> Mail, die an michael adressiert ist, wird nun mit einer Fehlermeldung an den ursprünglichen Absender zurückgesandt. In der Fehlermeldung wird dem Absender geraten, es unter Michaels neuer Adresse zu versuchen. Die Mail wird nicht weitergeleitet, aber der Absender erfährt, wie er die Mail direkt abliefern kann..redirect ist ganz eindeutig kein gültiger Domainname. In der Sprache von sendmail handelt es sich um eine Pseudodomain. Pseudodomains werden in der Klasse $=P aufgeführt; sendmail versucht nicht, für Domains in der Klasse $=P eine DNS-Anfrage durchzuführen. Pseudodomains werden verwendet, um eine besondere Verarbeitung zu signalisieren. Es reicht jedoch nicht, einfach REDIRECT zur Klasse $=P hinzuzufügen. Die Funktion redirect muss in die sendmail-konfiguration aufgenommen werden, damit die Pseudodomain.REDIRECT so behandelt werden kann, wie in diesem Rezept beschrieben. Alternativen Eine beliebte und praktikable Alternative, um einen ehemaligen Angestellten aus Ihrem Mailsystem herauszubekommen, besteht darin, seinen Zugang einfach zu löschen. Diese Alternative wurde für das Beispielproblem verworfen, da Michael im Verkauf tätig war. Das Überleben unseres Unternehmens hängt vom Verkauf ab, deshalb wollten wir unsere Kunden nicht mit einem»user unknown«-fehler befremden und verwirren, wenn sie etwa versuchen, ihren Verkaufsvertreter zu erreichen. Aus diesem Grund betont die Lösung die Kundenbeziehungen. Wäre Michael dagegen ein Programmierer gewesen, der an einem internen Projekt gearbeitet hatte, dann wäre das Löschen seines Zugangs ohne eine behutsame Migration durchaus akzeptabel. Eine andere verlockende Alternative ist es, folgenden Alias in die aliases-datenbank aufzunehmen: michael: jay Jay hat Michael ersetzt. Dieser Alias würde Michaels komplette Mail an Jay weiterleiten. Wir haben diese Alternative jedoch verworfen. Falls dieser Alias benutzt wird, bekommt Jay unerwünschte Mail von all den Mailinglisten, die Michael abonniert hatte, sowie Michaels persönliche Mail, wie etwa die Einladung zu seinem Matrikeltreffen. Wir legen 2.8 Ehemalige Benutzer auf neue Adressen migrieren 69

88 Wert auf freundschaftliche Beziehungen zu Michael, deshalb können wir seine Mail nicht einfach abweisen. Gleichzeitig soll Jay nicht gezwungen werden, Michaels Mail weiterzuleiten. Deshalb entschließen wir uns zum Einsatz der Funktion redirect. Diese Entscheidungen sind jedoch eine Frage der Firmenpolitik, die mit der Verwaltung abgesprochen werden muss. Links Siehe auch Das Buch sendmail behandelt die Funktion redirect in Abschnitt Mail an ein Programm ausliefern Problem Sie wollen, dass sendmail Mail-Nachrichten an ein anderes Programm übergibt. Lösung Adressieren Sie die Mail an das Programm, indem Sie den Pfadnamen des Programms benutzen, dem ein Pipe-Zeichen vorangestellt ist. Diskussion Eine Empfänger-Mail-Adresse kann ein Pipe-Zeichen und den Namen eines Programms enthalten. Zum Beispiel: /usr/local/bin/rtmproc sendmail verwendet den Mailer prog, um Mail an eine Empfängeradresse auszuliefern, die mit einem Pipe-Zeichen beginnt. Der Parameter P der prog-mailer-definition definiert den Pfad zum prog-mailer-programm, der Parameter A bestimmt den Befehl, mit dessen Hilfe der Mailer ausgeführt wird. Bei der generischen sendmail-konfiguration, die in Rezept 1.8 beschrieben wird, ist der Parameter P gleich P=/bin/sh und der Parameter A gleich A=sh -c $u. $u ist ein sendmail-makro, das die -Adresse des Benutzers enthält, an den die Mail ausgeliefert wird. Wenn wir die oben gezeigte Beispiel-Mail-Adresse verwenden, würde der Befehl, der für den prog-mailer ausgeführt wird, folgendermaßen lauten: /bin/sh -c "/usr/local/bin/rtmproc" Wenn die Option -c mit /bin/sh benutzt wird, werden Shell-Befehle aus dem String gelesen, der -c folgt. In diesem Fall veranlasst sendmail die Shell, ein Programm namens rtmproc auszuführen. sendmail hängt seine Ausgabe an die Standardeingabe der Shell an und gibt die Mail-Nachricht aus, die in dem Beispiel die Mail-Nachricht an das Programm rtmproc schickt. sendmail hängt außerdem die Standardausgabe und die Standardfehlerausgabe der Shell an seine Eingabe. 70 Kapitel 2: Auslieferung und Weiterleitung

89 Rechts Die Shell führt alle Befehle aus, die an sie übergeben werden. Die potenziellen Sicherheitsrisiken beim Ausführen beliebiger Befehle, die dem Pipe-Zeichen in einer Empfängeradresse folgen, sind offensichtlich, und die Tatsache, dass die Benutzer selbst solche Adressen in ihren.forward-dateien angeben können, erhöht das Risiko nur noch. Um diese Gefahren zu verringern, benutzen Sie anstelle von /bin/sh die Sendmail Restricted Shell (smrsh) für den prog-mailer. smrsh verbessert die Sicherheit, indem sie die Befehle einschränkt, die ausgeführt werden können. Wir gehen in Kapitel 10 näher darauf ein. -Adressen, die mit Pipe-Zeichen beginnen, können in der aliases-datenbank oder in.forward-dateien eingesetzt werden. Beispielsweise könnte der Systemadministrator den folgenden Alias anlegen, wenn rtmproc ein Programm ist, das Mail verarbeiten soll, die an root adressiert ist: root: " /usr/local/bin/rtmproc" In einem anderen Beispiel könnte Rebecca die folgende.forward-datei anlegen, um Mail durch das Programm slocal zu filtern: " /usr/lib/nmh/slocal -user reba" Aliase, die an ein Programm weiterleiten, werden in der.forward-datei häufiger eingesetzt als auf andere Weise. Systemadministratoren erzeugen die aliases-datenbank, ihre Benutzer dagegen legen ihre eigenen.forward-dateien an. Die Struktur der.forward- Datei ähnelt der einer :include:-datei. Jeder Eintrag in einer.forward-datei definiert eine oder mehrere Empfängeradressen, an die Mail ausgeliefert wird, die an den Benutzer adressiert ist. Alles, was im Empfängerfeld eines Eintrags in der aliases-datenbank stehen kann, darf auch in einem.forward-eintrag auftauchen. Beispielsweise kann Jill ihre Mail an einen externen Host weiterleiten: Julie kann Mail an ihre lokale Mailbox ausliefern lassen und außerdem eine Sicherheitskopie in einer Archivdatei speichern: \julie /mnt/nsf1/sara/mail.archive Kathy kann die folgende.forward-datei definieren, wenn sie in den Urlaub geht: \kathy, " /usr/local/bin/vacation kathy" Beachten Sie Kathys Eintrag. Kathy möchte eine Kopie der Mail in ihre Mailbox setzen, bevor sie das vacation-programm ausführt. Ihre.forward-Datei beginnt mit \kathy. Der \ veranlasst sendmail, Mail an den Zugang kathy auszuliefern, ohne irgendwelche Aliase aufzulösen. Der \ ist notwendig; ohne dieses Zeichen würde durch die Adresse kathy in Kathys.forward-Datei eine Schleife entstehen. Siehe auch Das Buch sendmail behandelt die aliases-datenbank in Kapitel Mail an ein Programm ausliefern 71

90 2.10 Programmnamen in Mailinglisten benutzen Links Problem sendmail entfernt Duplikate aus Mailinglisten; jedoch müssen Sie sicherstellen, dass alle Benutzer, die in einer Mailingliste aufgeführt sind, ihre Mail erhalten, selbst wenn mehrere Benutzer ihre Mail über eine Pipe auf das gleiche Programm bekommen. Lösung Wenn Empfängeradressen in der aliases-datei nicht eindeutig sind, weil sie das gleiche Programm kennzeichnen, machen Sie sie eindeutig, indem Sie einen harmlosen Shell- Kommentar nach dem Pfadnamen des Programms einfügen. Diskussion Doppelte Empfänger werden während der Verarbeitung von Mailinglisten entfernt, um die Auslieferung von mehreren Kopien der gleichen Mail an den gleichen Benutzer zu verhindern. Dies kann Probleme verursachen, wenn es sich bei den doppelten Empfängern eigentlich um separate Instanzen des gleichen Programms handelt. Die folgende aliases-datei verdeutlicht das: sales: owner-sales: sales-request: clark: jeff: jill: frank, clark, amanda, jill, jeff sales-request alana " /usr/bin/procmail" " /usr/bin/procmail" " /usr/bin/procmail" In diesem Fall scheint Mail an clark, jeff und jill an den gleichen Empfänger zu gehen nämlich an /usr/bin/procmail. Wenn die Duplikate entfernt werden, bekommt nur einer der drei Benutzer eine Kopie der Mail. Die meisten Programme, die dazu gedacht sind, mit sendmail zusammenzuarbeiten, erwarten einen Benutzernamen als Kommandozeilenargument. Es ist nicht so, dass das Programm diesen Wert unbedingt erfordert; dieser Mechanismus soll Duplikate vermeiden helfen, wenn das Programm als Empfänger in der aliases-datei benutzt wird. procmail jedoch verlangt keinen Benutzernamen als Kommandozeilenargument, es funktioniert im Gegenteil sehr schön ohne irgendwelche Kommandozeilenargumente. Machen Sie jeden Empfängerwert eindeutig, indem Sie den Benutzernamen als Shell- Kommentar hinter dem Befehl procmail einfügen. Der Kommentar wird ignoriert, hat also keinen Einfluss auf die Ausführung von procmail. Allerdings sind die einzelnen Empfängerzeilen dann eindeutig, so dass es keine Probleme mit doppelten Empfängern gibt. Hier ist die korrigierte Mailingliste für die aliases-datei: 72 Kapitel 2: Auslieferung und Weiterleitung

91 Rechts sales: owner-sales: sales-request: clark: jeff: jill: frank, clark, amanda, jill, jeff sales-request alana " /usr/bin/procmail #clark" " /usr/bin/procmail #jeff" " /usr/bin/procmail #jill" Wenn Benutzer aus ihren.forward-dateien heraus auf das procmail-programm weiterleiten, muss bei ihnen kein Benutzername hinzugefügt werden. Stammen mehrere Referenzen auf procmail aus einer einzigen Datei (z. B. der aliases-datei), müssen Sie sendmail helfen, die Dopplung aufzulösen. sendmail braucht keine Hilfe beim Auflösen der Dopplung, wenn die Einträge aus unterschiedlichen.forward-dateien bezogen werden. Siehe auch In Rezept 2.7 beschreibe ich außerdem das Entfernen von Duplikaten in Mailinglisten Nonlogin-Benutzern das Weiterleiten auf Programme erlauben Problem Sie wollen es Benutzern, die keine gültige Login-Shell erhalten haben, erlauben, Mail an Programme weiterzuleiten. Lösung Fügen Sie /SENDMAIL/ANY/SHELL/ zur Datei /etc/shell hinzu. Zum Beispiel: # echo /SENDMAIL/ANY/SHELL/ >> /etc/shells Diskussion Die Home-Verzeichnisse von Benutzern können sich auf einem NFS-Fileserver befinden, der so konfiguriert ist, dass er es dem Benutzer erlaubt, das Home-Verzeichnis zu mounten, nicht jedoch, sich anzumelden. Aus diesem Grund erhält der Benutzer keine gültige Login-Shell. Ein Benutzer benötigt aber eine solche gültige Login-Shell, um Mail an ein Programm weiterleiten zu können. Selbst wenn die smrsh zum Einsatz kommt, wie in Kapitel 10 beschrieben, reicht es nicht, Programme zum smrsh-programmverzeichnis hinzuzufügen, um diese Programme dem Benutzer zur Verfügung zu stellen, wenn der Benutzer keine gültige Login-Shell hat. sendmail betrachtet jede Shell, die in der Datei /etc/shells aufgeführt ist, als gültige Login-Shell. Besitzt das System keine /etc/shells-datei, dann wird eine vorgegebene Liste mit Shells benutzt, die durch die Variable DefaultUserShells im sendmail-quellcode 2.11 Nonlogin-Benutzern das Weiterleiten auf Programme erlauben 73

92 definiert wird. Wenn die Shell im /etc/passwd-eintrag des Benutzers keine gültige Shell ist, dann lehnt sendmail es ab, ein Programm aus der.forward-datei des Benutzers auszuführen. Manche NFS-Server sind so konfiguriert, dass sie es erlauben, Home-Verzeichnisse zu mounten, während sie den direkten Zugriff verweigern. Der /etc/passwd-eintrag eines Benutzers auf einem solchen Server enthält etwas wie /sbin/nologin oder /bin/false als Login-Shell. Diese»Nonlogin«-Shells dürfen nicht in /etc/shells aufgeführt werden. Deshalb findet sendmail die Shell des Benutzers nicht in /etc/shells und lehnt es ab, das Programm auszuführen, das der Benutzer in die.forward-datei gesetzt hat. Setzen Sie den String /SENDMAIL/ANY/SHELL/ in die Datei /etc/shells, um sendmail mitzuteilen, dass es das Programm aus der.forward-datei des Benutzers ausführen soll, selbst wenn der Benutzer keine gültige Login-Shell besitzt. Dieses Rezept fügt den Eintrag am Ende einer existierenden /etc/shells-datei an. Besitzt Ihr System keine /etc/shells-datei, dann erzeugt der Befehl echo, der im Lösungsabschnitt gezeigt wurde, eine, die den erforderlichen String enthält. Wenn die smrsh benutzt wird, dann ändert sich durch den String /SENDMAIL/ANY/SHELL/ in /etc/shells nicht die Tatsache, dass nur Programme, die im smrsh-programmverzeichnis stehen, ausgeführt werden. Das Erfordernis der gültigen Login-Shell kommt zur Erfordernis der smrsh hinzu. Der String /SENDMAIL/ANY/SHELL/ umgeht die Erfordernis der gültigen Login-Shell, nicht jedoch die Anforderungen der smrsh-konfiguration. Da /SENDMAIL/ANY/ SHELL/ eine Sicherheitsüberprüfung umgeht, sollte es nur dann benutzt werden, wenn es absolut notwendig ist. Links Siehe auch Die Datei cf/readme beschreibt die Benutzung von /SENDMAIL/ANY/SHELL/ in der Datei /etc/shells Eine.forward-Schleife reparieren Problem Mail, die an einen Benutzer adressiert ist, wird mit dem Fehler»too many hops«abgewiesen. Lösung Überprüfen Sie zuerst die aliases-datenbank, um sicherzustellen, dass sie nicht die Ursache des Problems darstellt. Wenn die aliases-datenbank nicht die Quelle der Schleife ist, dann legen Sie einen Alias für den Benutzernamen mit der Schleife an, um die.forward- Datei des Benutzers zu umgehen und eine lokale Auslieferung zu erzwingen. Das Alias- 74 Kapitel 2: Auslieferung und Weiterleitung

93 Rechts Feld des neuen Datenbankeintrags muss den Benutzernamen mit der Schleife enthalten und das Empfängerfeld den Benutzernamen mit der Schleife, dem ein \-Zeichen vorangestellt ist. Als Nächstes überprüfen Sie den Inhalt der.forward-datei des Benutzers. Wenn der Benutzer an ein entferntes System weiterleitet und Sie root-zugriff auf dieses System haben, dann geben Sie die.forward-datei auf diesem System aus. Haben Sie keinen root- Zugriff, dann führen Sie ein telnet an den SMTP-Port des entfernten Systems aus und benutzen den SMTP-Befehl EXPN, um festzustellen, wie dieses System Mail ausliefert, die an den Zugang mit der Mail-Schleife adressiert ist. Wenn diese Tests Ihnen die Schleife zeigen, dann sagen Sie dem Benutzer genau, was nicht stimmt und was repariert werden muss. Falls Sie die notwendigen Informationen nicht schnell vom entfernten System bekommen können, dann teilen Sie dem Benutzer mit, dass er wahrscheinlich eine Schleife in seinen.forward-dateien hat, die er beheben muss, und dass seine.forward-datei auf Ihrem System so lange ignoriert wird, bis dies geschehen ist. Diskussion Benutzer legen ihre eigenen.forward-dateien an und pflegen diese auch. Manchmal unterläuft einem Benutzer jedoch beim Konfigurieren der.forward-datei ein Fehler. Dann ist es an Ihnen, ihm bei der Korrektur dieses Fehlers zu helfen. Einer der am häufigsten auftretenden Konfigurationsfehler ist eine Schleife bei der Weiterleitung, bei der der Benutzer die.forward-datei so konfiguriert, dass Mail an ein anderes System weitergeleitet wird, und dann in der.forward-datei auf diesem anderen System einstellt, dass Mail wieder zurück an das Ausgangssystem geleitet wird. Manchmal sind sogar mehr als zwei Systeme beteiligt, da Benutzer oftmals Zugänge auf mehreren Systemen haben. Schauen wir uns ein Beispiel an. Nehmen wir an, der Benutzername, für den Mail zurückgekommen ist, lautet norman. Überprüfen Sie, wie Ihr System die -Adresse norman behandelt, indem Sie die Option -v (verbose; ausführlich) des Befehls sendmail -bv einsetzen: # sendmail -v -bv norman /home/norman/.forward: line 1: forwarding to norman@crab.wrotethebook.com norman@crab.wrotethebook.com... deliverable: mailer esmtp, host crab.wrotethebook.com., user norman@crab.wrotethebook.com Die Option -v des Befehls sendmail -bv liefert zusätzliche Informationen darüber, wie eine Adresse auf dem lokalen System wiedergegeben wird. In diesem Fall gibt es keinen Alias für norman, so dass die aliases-datenbank nicht an der Weiterleitungsschleife beteiligt sein kann. (Sie sollten immer zuerst überprüfen, ob Sie nicht vielleicht selbst die Ursache des Problems sind, bevor Sie an einen Benutzer herantreten.) Tatsächlich stellt der Befehl sendmail -v -bv klar, dass die Information, die benutzt wird, um die Adresse norman wiederzugeben, aus der Datei /home/norman/.forward stammt Eine.forward-Schleife reparieren 75

94 Fügen Sie der aliases-datenbank einen Alias hinzu, um die Schleife zu unterbrechen: norman: \norman Die \-Syntax beendet die Auflösung von Aliasen, bevor Normans.forward-Datei gelesen wird. An norman adressierte Mail, die auf diesem Host ankommt, wird nicht mehr von diesem Host aus weitergeleitet. Die Schleife wird dadurch unterbrochen. Wenn Sie weitersuchen wollen, können Sie die.forward-datei des Benutzers auf dem entfernten System überprüfen oder mit Hilfe des SMTP-Befehls EXPN feststellen, wie das entfernte System die Mail des Benutzers behandelt. Der Befehl sendmail -bv sagt uns lediglich, dass Norman seine Mail an crab.wrotethebook.com weiterleitet. Der folgende Test zeigt uns, wie crab mit Normans Mail umgeht: # telnet crab.wrotethebook.com smtp Trying Connected to crab.wrotethebook.com. Escape character is '^]'. 220 crab.wrotethebook.com ESMTP Sendmail /8.12.9; Mon, 11 Aug :31: HELO rodent.wrotethebook.com 250 crab.wrotethebook.com Hello rodent.wrotethebook.com [ ], pleased to meet you EXPN norman Norman Edwards <norman@wrotethebook.com> QUIT crab.wrotethebook.com closing connection Connection closed by foreign host. Das lokale System leitet Normans Mail an crab.wrotethebook.com weiter, und crab leitet die Mail an wrotethebook.com weiter. Wenn das lokale System der Mail-Exchanger für wrotethebook.com ist, dann ist die Ursache für die Schleife offensichtlich. Dieses Beispiel verwendet den SMTP-Befehl EXPN, um die Weiterleitung auf dem entfernten System zu untersuchen. Viele Mail-Hosts implementieren jedoch den Befehl EXPN nicht. In diesem Fall wird eine solche Fehlermeldung als Antwort auf den EXPN-Befehl ausgegeben: Sorry, we do not allow this operation Es ist nicht unbedingt notwendig, Informationen aus den lokalen und entfernten.forward- Dateien zu sammeln. Wenn sich dies einfach bewerkstelligen lässt, dann können Ihre Erkenntnisse über die Fehler in den Konfigurationen dieser Dateien das Auffinden einer dauerhaften Lösung beschleunigen. Die.forward-Datei unterliegt jedoch der Verantwortung des Benutzers. Wenn der Alias norman, den Sie in der aliases-datenbank angelegt haben, die Schleife unterbricht, und Informationen über die.forward-dateien nicht leicht zu bekommen sind, dann haben Sie sicher Besseres mit Ihrer Zeit zu tun, als Weiterleitungsinformationen zu sammeln. Norman kann seine.forward-dateien leicht ausdrucken und Ihnen die Informationen später zukommen lassen, falls er Hilfe braucht. Links 76 Kapitel 2: Auslieferung und Weiterleitung

95 Rechts Siehe auch Die SMTP-Befehle, einschließlich EXPN, werden im Abschnitt»Simple Mail Transfer Protocol«des Buches TCP/IP-Netzwerk-Administration, dritte Auflage, von Craig Hunt (O Reilly) behandelt. Das Buch sendmail behandelt EXPN in Abschnitt Die Benutzerdatenbank aktivieren Problem Obwohl die sendmail-entwickler davon abraten, haben Sie beschlossen, die Benutzerdatenbank zu konfigurieren. Lösung Benutzen Sie die sendmail-debug-option -d0.1, um zu überprüfen, ob sendmail mit dem Flag USERDB kompiliert wurde. Falls erforderlich, kompilieren Sie sendmail erneut, um Unterstützung für die Benutzerdatenbank hinzuzufügen. Legen Sie die Quelldatei für die Benutzerdatenbank an, und platzieren Sie für jeden Benutzernamen, der durch die Benutzerdatenbank abgebildet werden soll, Paare von maildropund mailname-einträgen in die Datei. Benutzen Sie das Skript makemap, um die vervollständigte Quelldatei in den erforderlichen Datenbanktyp btree umzuwandeln. Angenommen, die Datenbankdatei wurde im Verzeichnis /etc/mail angelegt und heißt userdb. Fügen Sie dann folgende Definition in die sendmail-konfiguration ein: define(`confuserdb_spec', `/etc/mail/userdb') Erstellen Sie die Datei sendmail.cf neu, kopieren Sie die neue Datei nach /etc/mail, und starten Sie sendmail neu, wie in Rezept 1.8 beschrieben. Diskussion Es sind drei Dinge erforderlich, bevor sendmail nach einer Benutzerdatenbank sucht: sendmail muss mit dem Compiler-Flag USERDB kompiliert worden sein, der Mailer muss das gesetzt haben, und mit Hilfe der confuserdb_spec-definition muss in der sendmail-konfiguration der Pfad zur Benutzerdatenbank festgelegt sein. Im Lösungsabschnitt wird angenommen, dass die Datei die Bezeichnung userdb trägt und sich im Verzeichnis /etc/mail befindet. Die sendmail-debug-option -d0.1 zeigt die Compiler-Flags an, die verwendet werden, um das sendmail-binary zu erzeugen. Untersuchen Sie die Compiler-Flags, die hinter»compiled with:«aufgeführt werden. Wenn USERDB fehlt, dann kompilieren Sie den 2.13 Die Benutzerdatenbank aktivieren 77

96 sendmail-quellcode entweder mit dem Compiler-Flag NEWDB oder dem Compiler-Flag HESIOD neu und installieren sendmail erneut. (Wird entweder NEWDB oder HESIOD benutzt, dann ist das Flag USERDB automatisch gesetzt.) Wählen Sie NEWDB oder HESIOD danach aus, ob die Informationen der Benutzerdatenbank auf einem Hesiod-Server oder lokal in einer Datenbankdatei gespeichert sein werden. Kapitel 1 zeigt Ihnen verschiedene Beispiele für das Neukompilieren von sendmail. Speziell in Rezept 1.4 erfahren Sie, wie Sie einen optionalen Datenbanktyp zu sendmail hinzufügen. Die Benutzerdatenbankdatei muss in eine echte Datenbank umgewandelt werden, bevor sendmail sie verwenden kann. Bauen Sie die Datenbank mit dem Befehl makemap auf. Um beispielsweise eine Datenbankdatei namens userdb aus einer Benutzerdatenbankquelldatei namens /etc/mail/userdb zu erzeugen, setzen Sie folgenden makemap-befehl ein: # cd /etc/mail # makemap btree userdb < userdb Das Programm makemap liest die Standardeingabe und schreibt die angegebene Datenbank des gewählten Typs aus. Der Befehl erwartet im Allgemeinen zwei Argumente: den Datenbanktyp und den Namen der Datenbank, die geschrieben werden soll. Die Benutzerdatenbank muss vom Typ btree sein, und der Name der Benutzerdatenbank muss in der sendmail-konfiguration definiert werden. Der Befehl makemap wird in diesem Buch mit einer Vielzahl von Kommandozeilenoptionen häufig eingesetzt. Die Benutzerdatenbank wird auf eingehende Mail nach der aliases-datenbank und vor der.forward-datei angewandt, wenn bei dem Mailer das gesetzt ist. Die Verwendung der Benutzerdatenbank wird nicht empfohlen. Die sendmail-entwickler sagten mir, dass sie wahrscheinlich irgendwann in der Zukunft aus der Distribution entfernt werden wird. Dieses Rezept wird nur gezeigt, weil Sie eine tolle Idee haben könnten, wie Sie sie benutzen wollen. Merken Sie sich einfach, dass die Benutzerdatenbank für ein einfaches Mapping ausgehender Absenderadressen nicht empfohlen wird. Falls Sie sie dennoch einsetzen wollen, sollten Sie einen besonderen Grund dafür haben. Die Einträge in der Benutzerdatenbank sehen ein bisschen so aus wie die Einträge in der aliases-datenbank. Allerdings haben sie zusätzlich ein Schlüsselwort, entweder maildrop oder mailname. Im Allgemeinen werden Einträge in der Benutzerdatenbank paarweise angegeben, bei denen jeder Benutzer sowohl einen maildrop- als auch einen mailname-eintrag besitzt. Ein Eintragspaar für den Benutzerzugang andy könnte so aussehen: andy.wright:maildrop andy andy:mailname andy.wright@wrotethebook.com Die Einträge, die das Schlüsselwort maildrop verwenden, entsprechen fast genau den Einträgen in der aliases-datenbank. Der Wert vor dem Doppelpunkt (:) ist der Benutzer- Alias, und der Wert nach dem Schlüsselwort maildrop ist die Empfängeradresse. Der Links 78 Kapitel 2: Auslieferung und Weiterleitung

97 Rechts oben gezeigte Beispiel-maildrop-Eintrag erfüllt exakt die gleiche Funktion wie die folgende Zeile, die in der aliases-datenbank platziert ist: andy.wright: andy Beide Einträge nehmen Mail, die an andy.wright adressiert ist, und liefern sie an den Benutzerzugang andy aus. Natürlich sind maildrop-zeilen nicht notwendig, wenn sie Zeilen aus der aliases-datei wiederholen. Die aliases-datei hat eingehende Adressen bereits zugeordnet, bevor die Benutzerdatenbank aufgerufen wird. Echte maildrop-einträge duplizieren keine Einträge, die bereits in der aliases-datenbank stehen. Die Ähnlichkeit zwischen Einträgen in der aliases-datenbank und maildrop-einträgen in der Benutzerdatenbank ist sehr stark. Abgesehen von dem Zusatz des Schlüsselwortes maildrop besteht der einzige Unterschied darin, dass maildrop-einträge nicht auf Aliase verweisen können. Die Empfängeradresse in einem maildrop-eintrag muss eine echte Adresse sein. Die Benutzerdatenbank weist die zusätzliche Eigenschaft auf, dass sie im Gegensatz zu den aliases- und.forward-dateien auch auf ausgehende Mail angewandt wird. mailname- Einträge in der Benutzerdatenbank wandeln die Absenderadresse in einen umgekehrten Alias (reverse alias) um. In einem mailname-eintrag ist der Wert vor dem Doppelpunkt (:) der lokale Benutzername, und der Wert, der dem Schlüsselwort mailname folgt, ist die Absenderadresse, die für Mail verwendet werden soll, die vom Benutzer stammt. Der oben gezeigte mailname-eintrag wandelt die Absenderadresse in allen Mails des Benutzers andy in um. Die Benutzerdatenbank ist jedoch nicht die einzige oder gar empfohlene Möglichkeit, um ausgehende Adressen umzuschreiben. Die sendmail-faq sagt in Frage 3.3, dass»die Benutzerdatenbank nicht länger die empfohlene Lösung«zum Umschreiben von Absenderadressen ist. Für diese Aufgabe ist die genericstable-datenbank das empfohlene Werkzeug. Kapitel 4 behandelt die genericstable. Die aliases-datenbank und die genericstable stellen aus folgenden Gründen die bevorzugten Alternativen zur Benutzerdatenbank dar: Die Benutzerdatenbank ist schwieriger zu benutzen als die Alternativen. Die aliases- Datenbank steht in allen sendmail-konfigurationen zur Verfügung, die Benutzerdatenbank dagegen erfordert m4-änderungen an der Konfiguration. Die genericstable verlangt ebenfalls m4-änderungen, neben den m4-änderungen muss der sendmail- Quellcode bei der Benutzerdatenbank auch noch mit einem besonderen Compiler- Flags kompiliert werden. Die Benutzerdatenbank wiederholt die aliases-datenbank, ersetzt sie jedoch nicht. Beispielsweise kann die Benutzerdatenbank nicht einen Alias auf einen Alias verweisen lassen. Selbst wenn Sie eine Benutzerdatenbank anlegen, brauchen Sie weiterhin eine aliases-datenbank, das heißt, Sie müssen dann zwei Dateien pflegen Die Benutzerdatenbank aktivieren 79

98 Die Benutzerdatenbank interagiert mit anderen Funktionen auf eine Weise, die Sie möglicherweise nicht absehen können, wie die sendmail-faq in den Fragen 3.3 und 3.4 verdeutlicht. Die sendmail-entwickler stellen in der Antwort auf die FAQ-Frage 3.4 klar, dass die Benutzerdatenbank für eine besondere Konfigurationsanforderung an der UC Berkeley entwickelt wurde und eigentlich nicht für viele Konfigurationen geeignet ist. Falls Sie darauf bestehen, sie dennoch einzusetzen, zeigt Ihnen dieses Rezept die Schritte, die notwendig sind, um die Benutzerdatenbank zu aktivieren. Links Siehe auch Kapitel 4 behandelt die genericstable, die bevorzugte Alternative zum Schreiben ausgehender Adressen. Die sendmail-faq liefert in den Fragen 3.3 und 3.4 Hinweise zur Benutzerdatenbank. Das Buch sendmail behandelt die Benutzerdatenbank in Abschnitt Kapitel 2: Auslieferung und Weiterleitung

99 First Kapitel 3 KAPITEL 3 Weitervermittlung (Relaying) 3.0 Einführung Ein Mail Relay ist ein System, das Mail, die es empfängt, weitersendet. Wenn Mail, die durch einen anderen Host ausgeliefert werden sollte, bei dem Mail Relay Host ankommt, entscheidet das System, ob es die Mail weitervermitteln sollte. Ist die Weitervermittlung erlaubt, sendet der Relay Host die Mail an die Zieladresse. Ist die Weitervermittlung hingegen nicht erlaubt, dann wird dem Absender eine»relaying denied«-fehlermeldung zurückgeschickt. Dieses Kapitel enthält Rezepte, mit denen Sie steuern können, wann die Weitervermittlung erlaubt oder verboten wird, sowie Rezepte, mit denen Sie ein System für die Benutzung eines Mail Relay konfigurieren können. Die Weitervermittlung (Relaying) unterscheidet sich von der Weiterleitung (Forwarding). Mail, die weitergeleitet wird, kommt auf dem System an, für das sie auch gedacht ist; sie ist an den lokalen Host adressiert. Sie wird nur weitergeleitet, wenn der Host durch die aliases-datenbank oder die.forward-datei entsprechend angewiesen wird. Mail, die weitervermittelt wird, kommt auf dem System an, ist aber eigentlich an einen anderen Host adressiert. Sie wird nur dann weitervermittelt, wenn sendmail auf Grund seiner Konfiguration das Relaying erlaubt. So wie sendmail konfiguriert sein muss, um als Mail Relay zu fungieren, muss auch ein System konfiguriert sein, um ein Mail Relay zu benutzen. Jedes System, das sendmail ausführt, kann seine eigene Mail direkt ausliefern; sendmail verlässt sich nicht standardmäßig auf Relays. Es gibt jedoch eine Vielzahl unterschiedlicher sendmail-konfigurationen, die Relay-Server benutzen: Alle Mails werden weitervermittelt Ein System kann so konfiguriert werden, dass es alle seine Mails an ein Relay sendet. Diese Art der Konfiguration wird als Null Client bezeichnet, nicht etwa, weil die Datei sendmail.cf leer ist, sondern weil das System für seinen gesamten -Dienst von einem externen Host abhängt. 81

100 Es wird nur lokale Mail weitervermittelt Ein System kann so konfiguriert werden, dass es ein Relay für Mail benutzt, die normalerweise durch den Mailer local ausgeliefert wird, während es alle anderen Mails selbst ausliefert. Das bedeutet, Mail von einem Benutzer an einen anderen Benutzer wird über einen Relay-Server geschickt, selbst wenn beide Benutzer am gleichen Client angemeldet sind. Mail an externe Hosts wird weitervermittelt sendmail kann so konfiguriert werden, dass es alle Mails, die an externe Hosts gerichtet sind, über ein Mail Relay schickt. Nur Mail, die durch den Mailer local ausgeliefert wird, wird nicht an das Relay gesandt. Mail für Pseudodomains wird weitervermittelt sendmail kann so konfiguriert werden, dass es»nicht-smtp«-mail zur Auslieferung an einen Mail Relay Host sendet. Pseudodomains sind interne Tags, die von sendmail dazu verwendet werden, Mail zu identifizieren, die keine normale SMTP-Mail ist. Es gibt besondere Konfigurationsbefehle zum Senden von UUCP-, BITNET-, DECnet- und FAX-Mail an einen Mail Relay Host, wenn diese Mail durch eine Pseudodomain gekennzeichnet ist. Mail wird über den SMTP-Mailer relay an den Mail Relay Host geschickt. Die Konfiguration des relay-mailers kann mit den m4-makros RELAY_MAILER_ARGS, RELAY_MAILER_ FLAGS, RELAY_MAILER_QGRP und RELAY_MAILER_MAXMSG geändert werden. sendmail kann sogar dazu konfiguriert werden, einen anderen Mailer für die Weitervermittlung zu verwenden, indem mit der Definition confrelay_mailer ein anderer Mailer-Name angegeben wird. Das Ändern des Mailer-Namens oder das Herumfummeln an der relay-mailer- Konfiguration ist im Allgemeinen keine gute Idee, da dadurch eine unnötig komplizierte Konfiguration entsteht, die gewartet werden muss. Es ist besser, einen Mail Relay Host zu konfigurieren, der in der Lage ist, mit Standard-SMTP-Mail umzugehen, als einen eigenen Mailer für jedes System anzulegen, das den Relay Host benutzt, da auf diese Weise einfach weniger Systeme zu betreuen sind. Standardmäßig vermittelt sendmail keine Mail weiter das heißt, ein normales sendmail- System betrachtet sich selbst nicht als Mail Relay. Es gibt dafür einen guten Grund: Durch die Weitervermittlung bietet ein System die Möglichkeit des Missbrauchs durch Spammer. Spammer bevorzugen Systeme, über die sie ihre Mails weitervermitteln lassen können, um die wahre Quelle der Spam-Mail zu verbergen. Alles, was Sie tun, um ein Relay anzulegen, schwächt Ihre Sicherheit. Deshalb müssen Sie sorgfältig darauf achten, nur solche Konfigurationswerkzeuge einzusetzen, die Sie wirklich brauchen, um diese Aufgabe zu erledigen. Es stehen verschiedene Funktionen zur Verfügung, um ein sendmail-system zu einem Mail Relay zu machen: promiscuous_relay Diese Funktion weist sendmail an, Mail von beliebigen Quellen zu beliebigen Zielen weiterzuvermitteln. Sie sollte nicht auf einem System benutzt werden, das vom Inter- Links 82 Kapitel 3: Weitervermittlung (Relaying)

101 Rechts net aus erreicht werden kann, da sie ein offenes Relay schafft, das schnell von Spammern gefunden und missbraucht werden wird. relay_local_from Diese Funktion veranlasst sendmail, alle Mails weiterzuvermitteln, bei denen die Umschlagabsenderadresse (envelope sender address) den Namen eines Hosts in der lokalen Domain enthält. Da die Umschlagabsenderadresse leicht gefälscht werden kann, können Spammer ein Relay missbrauchen, das diese Funktion verwendet. Aus diesem Grund sollte die Funktion relay_local_from vermieden werden. relay_mail_from Diese Funktion weist sendmail an, Mail weiterzuvermitteln, falls die Umschlagabsenderadresse dieser Mail den Namen eines Hosts in einer Domain enthält, die in der Datei relay-domains aufgeführt ist oder die als RELAY in der access-datenbank steht. Da die Umschlagabsenderadresse in Mails leicht gefälscht werden kann, können Spammer ein Relay missbrauchen, das diese Funktion verwendet, falls sie die Einträge in der Datei relay-domains oder der access-datenbank ermitteln können. Aus diesem Grund sollte die Funktion relay_mail_from vermieden werden. relay_based_on_mx Diese Funktion aktiviert die Weitervermittlung für alle Hosts oder Domains, die den lokalen Host als ihren MailExchanger aufführen. Der Nachteil dieser Funktion besteht darin, dass Sie die direkte Kontrolle darüber verlieren, welche Systeme Ihr System als Relay benutzen kann. Sie legen diese Kontrolle in die Hände anderer der Domain-Administratoren. Domain-Administratoren können einfach MX-Records in ihren Domains platzieren, um die Weitervermittlung durch Ihr System zu aktivieren. relay_entire_domain Wenn diese Funktion angegeben wird, vermittelt sendmail Mail für jeden Host in einer Domain weiter, die in der Klasse $=m identifiziert wird. Klasse $=m enthält den Namen der Domain des lokalen Hosts, wie durch sendmail während des Starts festgelegt. Das heißt, diese Funktion aktiviert die Weitervermittlung für Hosts in der lokalen Domain. relay_hosts_only Standardmäßig werden Werte in der Datei relay-domains oder der access-datenbank als Domainnamen interpretiert. Die Weitervermittlung wird allen Hosts in diesen Domains gewährt. Durch diese Funktion wird das geändert. Wenn relay_hosts_only angegeben wird, werden die Werte in der Datei relay-domains und der access-datenbank als Hostnamen interpretiert. Mails werden entsprechend nur an solche Hosts weitervermittelt, die in diesen Dateien auftauchen. Abgesehen von der Funktion relay_hosts_only, die mit der Datei relay-domains und der access-datenbank zusammenarbeitet, neigen die oben aufgeführten Funktionen dazu, die Kontrolle zu verringern, die der sendmail-administrator über die Weitervermittlung hat. Im Allgemeinen ist es besser, wenn Sie die Weitervermittlung mit Hilfe der Datei relaydomains aktivieren. Die Benutzung der Datei relay-domains erfordert keine besondere Einführung 83

102 m4-konfiguration, da sendmail standardmäßig diese Datei liest. Um sie zu verwenden, müssen Sie lediglich eine Textdatei namens relay-domains anlegen, die eine Liste der Domains enthält, für die eine Weitervermittlung erlaubt ist. Einträge in der Datei relay-domains aktivieren die Weitervermittlung zu oder von den Dateien, die in der Datei aufgeführt sind. Um mehr Kontrolle über die Bedingungen zu haben, unter denen die Weitervermittlung erlaubt wird, nutzen Sie die access-datenbank. Die access-datenbank ist nicht speziell für die Weitervermittlung gedacht sie dient breiter angelegten Sicherheitsanwendungen. Sie kann jedoch eingesetzt werden, um die Weitervermittlung zu kontrollieren, wie in Rezept 3.10 demonstriert wird. Für maximale Sicherheit verwenden Sie SMTP AUTH oder STARTTLS, um die Hosts zu authentifizieren, denen Relay-Rechte gewährt werden. In den Kapiteln 7 und 8 behandeln wir diese Sicherheitsprotokolle. Da Spammer ein Mail Relay missbrauchen könnten, sollten Sie besonders auf ausreichende Tests der Relay-Konfiguration achten. Falls Ihr Server bei einem der Tests versagt, ändern Sie die Konfiguration, um die Sicherheitslücke zu schließen. Es gibt keine Tests, die unfehlbar sind, aber zumindest liefern sie klare Anzeichen für mögliche Konfigurationsprobleme. Links 3.1 Alle Mails an ein Relay übergeben Problem Sie wurden gebeten, eine sendmail-konfiguration anzulegen, die alle Mails durch ein Relay sendet. Die Identität des lokalen Hosts soll verborgen bleiben, so dass alle Mails von dem Mail Relay Host zu kommen scheinen. Lösung Legen Sie eine minimale sendmail-konfiguration an, die nur eine OSTYPE-Anweisung enthält, um das richtige Betriebssystem anzugeben, sowie einen FEATURE-Befehl, um die Funktion nullclient auszuwählen: # cd /usr/local/src/sendmail /cf/cf # cat > sendmail.mc VERSIONID(`Recipe 3.1 nullclient master configuration file.') dnl Select the correct operating system OSTYPE(`linux') dnl Select the nullclient feature and specify the relay server FEATURE(`nullclient', `smtp.wrotethebook.com') Ctrl-D Erstellen Sie die neue sendmail.cf-datei, kopieren Sie sie in den richtigen Pfad, und starten Sie sendmail neu. Ein Beispiel für das Erstellen und Installieren einer sendmail.cf- Datei wird im letzten Schritt von Rezept 1.8 gezeigt. 84 Kapitel 3: Weitervermittlung (Relaying)

103 Rechts Diskussion Jedes Unix-System, das sendmail ausführt, ist vollständig in der Lage, seine eigene Mail zu verarbeiten, selbst wenn das System nur als Workstation für einen einzigen Benutzer eingesetzt wird. Auf manchen Workstations ist sendmail so konfiguriert, dass es sowohl eingehende als auch ausgehende Mails verarbeitet genau wie ein Mailserver. Viele Unix-Workstations, sogar solche, die von einem Mailserver abhängen, der die eingehende Mail für sie sammelt, verfügen über eine vollständige sendmail-konfiguration zum Verarbeiten ausgehender Mails. Es ist aber auch möglich, eine sehr einfache sendmail- Konfiguration auf einer Workstation zu schaffen, die den eingehenden und ausgehenden Mail-Verkehr komplett einem Mailserver übergibt. Wenn die Funktion nullclient verwendet wird, sendet ein System all seine Mails durch einen Mail Relay Host. Die meisten der Rezepte in diesem Buch zeigen Konfigurationszeilen, die zu einer bereits existierenden sendmail-konfiguration hinzugefügt werden. Bei diesem Rezept ist das nicht der Fall; der Lösungsabschnitt zeigt die komplette Konfigurationsdatei. Die nullclient-konfiguration enthält nur zwei wesentliche Zeilen: das OSTYPE-Makro, das das Betriebssystem des Clients identifiziert, und das FEATURE-Makro, das die nullclient-funktion konfiguriert. Die Funktion nullclient besitzt zwei Felder. Das erste zeigt den Namen der Funktion: nullclient. Das zweite enthält den Namen des Relay Hosts, an den ausgehende Mail gesandt wird. Das Format des zweiten Feldes ist mailer:host., wobei mailer der Name eines Mailers ist, der in der Konfiguration definiert wird, und host der Domainname des Relay Hosts. Die einfache nullclient-konfiguration enthält nur die Mailer local und prog sowie die fünf SMTP-Mailer smtp, esmtp, smtp8, dsmtp und relay. mailer ist standardmäßig relay, falls kein anderer Mailer-Name angegeben wird. Diese Vorgabe ist richtig und sollte nur geändert werden, falls Sie weitere Mailer in die Konfiguration einbinden und einen besonderen Grund für die Benutzung eines anderen Mailers haben. Wir lassen zu, dass mailer in der Beispielkonfiguration standardmäßig relay ist, und empfehlen Ihnen, das Gleiche zu tun. Der Server-Wert ist den Makros $S, $H und $M in der Konfigurationsdatei sendmail.cf zugewiesen. Bei diesen Makros handelt es sich um die Smart-Host-, Mail-Hub- bzw. Masquerade-Makros. sendmail sendet alle ausgehenden Mails an den Server, der durch das Makro $S identifiziert wird. sendet alle Mails, die normalerweise durch den Mailer local ausgeliefert werden würden, an den Server, der durch das Makro $H identifiziert wird. ändert den Hostnamen in der Absenderadresse ausgehender Mails auf den Hostnamen, der im Makro $M definiert ist. Einige sendmail -bv-tests zeigen die Wirkung der nullclient-konfiguration auf die Mail- Auslieferung: # sendmail -bv tyler@example.com tyler@example.com... deliverable: mailer relay, host smtp.wrotethebook.com, user tyler@example.com 3.1 Alle Mails an ein Relay übergeben 85

104 # sendmail bv deliverable: mailer relay, host smtp.wrotethebook.com, user # sendmail -bv craig craig... deliverable: mailer relay, host smtp.wrotethebook.com, user Der Host-Wert, der durch den ersten Test angezeigt wird, zeigt, dass Mail, die an einen Benutzer auf einem externen Host adressiert ist, durch den Mail Relay Host geschickt wird. In der generischen Konfiguration wird Mail, die an ein externes System adressiert ist, mit Hilfe des esmtp-mailers direkt an dieses System oder seinen MX-Server geschickt. Auf dem nullclient-system wird die Mail mit Hilfe des relay-mailers an den Relay Host gesandt. In diesem Beispiel greift der Client dann auf smtp.wrotethebook.com zurück, um die Mail an weiterzuvermitteln. Der zweite Test ähnelt dem ersten. Im zweiten Test wird Mail an einen anderen Host innerhalb der lokalen Domain wrotethebook.com adressiert. Auch hier wird die Mail an den Relay-Server und nicht direkt an den externen Host geschickt. Vermutlich am interessantesten ist der dritte Test, der zeigt, wie Mail an den lokalen Benutzernamen craig ausgeliefert wird. Normalerweise würde Mail, die auf diese Weise adressiert ist, durch den Mailer local verarbeitet und direkt an die Mailbox des lokalen Benutzers ausgeliefert werden. Bei der nullclient-konfiguration wird diese Mail zur Auslieferung an den Relay Host geschickt, obwohl sie an einen Benutzer adressiert ist, der direkt auf dem lokalen System einen Zugang hat. Beachten Sie, dass der -bv-test oft am besten ist, um Auslieferungsinformationen anzuschauen. In diesem speziellen Fall hätte ein Test mittels -bt möglicherweise ein verwirrendes Ergebnis geliefert. Nehmen Sie zum Beispiel an, dass Sie beschlossen haben, sendmail -bt auszuführen, und den Befehl /parse benutzen, um das Mail-Auslieferungstriple zu untersuchen. Sie würden etwa das Folgende sehen: # cat > special-test /parse tyler@science.foo.edu /parse sara@crab /parse craig CTRL-D # sendmail -bt < special-test grep '^mailer' mailer relay, host smtp.wrotethebook.com, user tyler@science.foo.edu mailer relay, host smtp.wrotethebook.com, user sara@crab.wrotethebook.com mailer local, user craig Die ersten beiden Ergebnisse, die von /parse geliefert werden, zeigen die korrekten Informationen. Das dritte Ergebnis ist jedoch potenziell irreführend. Sie könnten es sich anschauen und denken, dass selbst bei der vorhandenen nullclient-konfiguration Mail, die an lokale Benutzer adressiert ist, vom Mailer local verarbeitet wird, anstatt an den Relay-Server weitergeleitet zu werden. Das Problem wird durch die Annahme verursacht, dass das Parsen der Auslieferungsadresse schon alles ist. In diesem Fall ist es das nicht. Da es sich bei dem Mailer um local handelt, wird die Auslieferungsadresse durch die Links 86 Kapitel 3: Weitervermittlung (Relaying)

105 Rechts aliases-datenbank verarbeitet. Wenn sendmail die Auflösung der Aliase beendet, verarbeitet es den Regelsatz localaddr (Regelsatz 5), falls bei dem local-mailer das Flag F=5 gesetzt ist, was standardmäßig der Fall ist. Der Regelsatz localaddr entscheidet dann, dass diese Mail an das Mail Relay geschickt werden muss, wie der folgende -bt-test zeigt: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > localaddr craig localaddr input: craig MailerToTriple input: < server. wrotethebook. com > craig smtp. wrotethebook. com > MailerToTriple returns: $# relay $@ smtp. wrotethebook. com $: craig smtp. wrotethebook. com > localaddr returns: $# relay $@ smtp. wrotethebook. com $: craig smtp. wrotethebook. com > > /quit Es kann verwirrend sein, wenn man versucht, sich daran zu erinnern, wann jeder Regelsatz aufgerufen wird. Im Allgemeinen ist es einfacher, -bv zu benutzen, wenn Sie lediglich Informationen über die Mail-Auslieferung haben wollen. Zusätzlich zum Versenden aller Mails durch den Relay-Server ersetzt die nullclient-konfiguration den Hostnamen des Clients durch den Namen des Servers in der -Adresse des Absenders. Ein sendmail -bt-test demonstriert diese Funktion der nullclient-konfiguration: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /tryflags HS > /try relay kathy@giant.wrotethebook.com Trying header sender address kathy@giant.wrotethebook.com for mailer relay canonify input: giant. wrotethebook. com Canonify2 input: kathy giant. wrotethebook. com > Canonify2 returns: kathy giant. wrotethebook. com. > canonify returns: kathy giant. wrotethebook. com. > 1 input: kathy giant. wrotethebook. com. > 1 returns: kathy giant. wrotethebook. com. > HdrFromSMTP input: kathy giant. wrotethebook. com. > PseudoToReal input: kathy giant. wrotethebook. com. > PseudoToReal returns: kathy giant. wrotethebook. com. > MasqSMTP input: kathy giant. wrotethebook. com. > MasqSMTP returns: kathy giant. wrotethebook. com. > MasqHdr input: kathy giant. wrotethebook. com. > MasqHdr returns: kathy smtp. wrotethebook. com. > HdrFromSMTP returns: kathy smtp. wrotethebook. com. > final input: kathy smtp. wrotethebook. com. > final returns: smtp. wrotethebook. com Rcode = 0, addr = kathy@smtp.wrotethebook.com > /quit 3.1 Alle Mails an ein Relay übergeben 87

106 Der Befehl /tryflags gibt die spezielle Adresse an, die wir verarbeiten wollen. In diesem Fall wollen wir die Verarbeitung der Header/Sender-(HS-)Adresse sehen. 1 Der Befehl /try legt den Mailer fest, für den die Adresse verarbeitet werden soll (relay), sowie die - Adresse, die verarbeitet werden soll (kathy@giant.wrotethebook.com). Das Ergebnis zeigt, dass der Hostname des Absenders (giant.wrotethebook.com) durch den Namen des Mail Relay Hosts (smtp.wrotethebook.com) ersetzt wird. Dieses Beispiel verwendet den voll qualifizierten Domainnamen des Absenders, hätte aber auch jeden anderen Hostnamen-Alias nehmen können, der in der Klasse $=w zu finden ist. Jeder von ihnen würde in diesem Test durch smtp.wrotethebook.com ersetzt werden. Die zweizeilige Konfiguration, die in diesem Rezept gezeigt wird, sendet alle Mails, die von dem lokalen Host stammen, zur Verarbeitung an den Relay Host. Sie maskiert diese Mail außerdem, so dass es aussieht, als würde sie von dem Mail Relay Host kommen. Die nullclient-konfiguration ist für Systeme gedacht, die für alle Belange von s auf den Mailserver zurückgreifen. Klassische Beispiele für Systeme, die eine solche Konfiguration nutzen könnten, sind plattenlose Clients, die völlig von einem Server abhängen. Die Vorteile der nullclient-konfiguration haben jedoch noch viel größeren Nutzwert. Das Zentralisieren von Mail-Diensten kann die Warteschlangenverwaltung, die Kontrolle der Mail- Politik, die Sicherheit und die Protokollierung vereinfachen. Viele Sites setzen die nullclient-konfiguration auf Desktop-Workstations ein. Links Siehe auch Das Ersetzen des Hostnamens in der Absenderadresse wird als Maskierung (Masquerading) bezeichnet und ausführlich in Kapitel 4 behandelt. Die dritte Auflage von sendmail behandelt die nullclient-konfiguration in Abschnitt Die Rezepte 3.2, 3.3 und 3.4 liefern Konfigurationen, die einen Mail Relay Host verwenden; greifen Sie auf diese Rezepte zurück, falls die nullclient-funktion Ihren Ansprüchen nicht genügt. 3.2 Ausgehende Mails an ein Relay übergeben Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es alle Mails, die an externe Systeme gerichtet sind, durch einen Mail Relay Host schickt. Lösung Legen Sie eine sendmail-konfiguration an, die die SMART_HOST-Definition nutzt, um den Mail Relay Host zu identifizieren: 1 Setzen Sie /tryflags auf ES, und führen Sie diesen Test erneut durch, um sicherzugehen, dass die Umschlag/ Absender-Adresse (Envelope/Sender) ebenfalls umgeschrieben wird. 88 Kapitel 3: Weitervermittlung (Relaying)

107 Rechts dnl Define a relay for all outbound mail define(`smart_host', `smtp.wrotethebook.com') Erstellen Sie die neue sendmail.cf-datei, kopieren Sie sie in den richtigen Pfad, und starten Sie sendmail neu, wie in Rezept 1.8 beschrieben. Diskussion Die SMART_HOST-Definition setzt einen Wert für das sendmail.cf-makro $S. Das Makro $S identifiziert den Smart Host. sendmail benutzt den Smart Host, um Mail an externe Systeme weiterzuvermitteln. Einige -bv-tests zeigen die Wirkung der SMART_HOST-Definition: # sendmail -bv sara@crab sara@crab... deliverable: mailer relay, host smtp.wrotethebook.com, user sara@crab. wrotethebook.com # sendmail -bv tyler@example.com tyler@example.com... deliverable: mailer relay, host smtp.wrotethebook.com, user tyler@example.com # sendmail -bv craig craig... deliverable: mailer local, user craig Die ersten beiden Tests zeigen, dass alle Mails, die an einen externen Host adressiert sind unabhängig davon, ob der Host Teil der lokalen Domain wrotethebook.com oder einer anderen Domain ist, zur Auslieferung an den externen Host an den Smart Host gesandt werden. Der dritte Test zeigt, dass alle Mails, die durch den Mailer local ausgeliefert werden können, auf dem lokalen System verbleiben und durch local ausgeliefert werden. Diese Konfiguration unterscheidet sich auf zwei Arten von der nullclient-konfiguration: 1. Lokale Mail verbleibt auf dem lokalen Host. 2. Mail, die vom lokalen Host stammt, trägt den Hostnamen des lokalen Hosts in der Absenderadresse. Dies erzeugt eine sendmail-konfiguration, die ihre eigene lokale Mail verarbeiten kann, für den Zugriff auf externe Systeme jedoch auf einen Mail Relay Host angewiesen ist. Das Konzept eines Smart Host wurde ursprünglich entwickelt, weil viele Einrichtungen nur eine eingeschränkte Internet-Anbindung hatten. Damals wurde Mail durch den Smart Host weitervermittelt, weil dieser der einzige Host war, der die Mail ausliefern konnte. An manchen Orten ist es immer noch so, allerdings ist diese Konfiguration inzwischen eher deshalb so beliebt, weil Netzwerkverwalter alle ausgehenden Mails über einen einzigen Server leiten wollen, um die Sicherheit zu erhöhen, die Warteschlangenverwaltung zu vereinfachen und die Protokollierung zu zentralisieren. Siehe auch Im Abschnitt des Buchs sendmail wird die SMART_HOST-Definition beschrieben. 3.2 Ausgehende Mails an ein Relay übergeben 89

108 3.3 Lokale Mail an einen Mail-Hub übergeben Links Problem Sie wurden gebeten, eine sendmail-konfiguration anzulegen, die alle lokalen Mails an einen Mail-Hub sendet, während Mails, die an externe Systeme adressiert sind, direkt ausgeliefert werden sollen. Lösung Legen Sie eine sendmail-konfiguration an, die die MAIL_HUB-Definition enthält, um den Mail Relay Host für die lokale Mail zu identifizieren. Benutzen Sie den Befehl LOCAL_USER, um die Mail des root-benutzers von der Weitervermittlung auszunehmen. Hier sind Beispielbefehle: dnl Define a relay server for local mail define(`mail_hub', `smtp.wrotethebook.com') dnl Users whose mail is not passed to the mail hub LOCAL_USER(root) Erstellen Sie die Datei sendmail.cf neu, und installieren Sie sie, starten Sie dann sendmail neu. Beispiele für diese Schritte finden Sie in Rezept 1.8. Diskussion Die MAIL_HUB-Definition setzt einen Wert für das sendmail.cf-makro $H. Das Makro $H identifiziert einen Mail-Hub, den sendmail verwendet, um lokale Mail auszuliefern. Einige -bv-tests zeigen die Wirkung der MAIL_HUB-Definition: # sendmail -bv tyler@example.com tyler@example.com... deliverable: mailer esmtp, host example.com, user tyler@example.com # sendmail -bv sara@crab sara@crab... deliverable: mailer esmtp, host crab.wrotethebook.com., user sara@crab. wrotethebook.com # sendmail -bv craig craig... deliverable: mailer relay, host smtp.wrotethebook.com, user craig@smtp. wrotethebook.com Die Tests demonstrieren, dass sendmail den Mailer esmtp verwendet, um Mail, die an Systeme in externen Domains und an externe Systeme in der lokalen Domain gerichtet ist, direkt auszuliefern. Mail, die normalerweise durch den Mailer local ausgeliefert werden würde, wird dagegen über den Mailer relay an den Mail-Hub gesandt (smtp. wrotethebook.com). Beachten Sie das Benutzeradressfeld des Mail-Auslieferungstriples, das durch den dritten Test dargestellt wird. Die Adresse craig wurde in craig@smtp.wrotethebook.com umge- 90 Kapitel 3: Weitervermittlung (Relaying)

109 Rechts schrieben. Die Adresse wird auch umgeschrieben, wenn die Auslieferungsadresse den voll qualifizierten Domainnamen des lokalen Hosts enthält, zum Beispiel: # sendmail -bv craig@jamis.wrotethebook.com craig@jamis.wrotethebook.com... deliverable: mailer relay, host smtp.wrotethebook.com, user craig@smtp.wrotethebook.com Das heißt, alle Mails, die durch den Mailer local ausgeliefert werden würden, selbst Mail, die von einer externen Quelle ankommt, wird an den Mail-Hub weitergeleitet. Achten Sie beim Konfigurieren des Mail-Hubs darauf, dass Sie nicht Mail zurück an ein System leiten, das Mail an den Hub vermittelt, da dies eine Mail-Schleife verursacht. In diesem Beispiel muss der Mail-Hub entweder mit dem Zugang craig oder mit einem Alias für craig konfiguriert werden. Oft hält der Mail-Hub ein zentrales Spool-Verzeichnis für Mails vor und sammelt die Mail für alle seine Clients. Die Clients selbst besitzen keine lokalen Mail-Spool-Verzeichnisse. Sie mounten entweder das Spool-Verzeichnis des Servers über NFS, laden die Mail mittels POP oder IMAP in ein Mail-Programm herunter oder lesen die Mail direkt auf dem Server. Da der Mail-Hub einen Zugang oder einen Alias für jeden Benutzer auf jedem Client hat, ist es wichtig, dass die Benutzernamen auf den Clients eindeutig sind. Wenn Craig Hunt einen Zugang namens craig auf crab hat, Craig Rider einen Zugang namens craig auf jamis nutzt und beide Systeme smtp.wrotethebook.com als Mail-Hub verwenden, dann werden beide Systeme Mail mit der gleichen Auslieferungsadresse craig@smtp. wrotethebook.com an den Mail-Hub senden, auch wenn die Mail für zwei unterschiedliche Benutzer gedacht ist. Die Benutzung eines Mail-Hubs erfordert Koordination zwischen all den Clients. Ein Benutzername, der offensichtlich auf allen Clients vorkommt, ist root. Mit dem Makro LOCAL_USER können Sie sicherstellen, dass sendmail Mail, die an root adressiert ist, nicht an den Mail-Hub weitervermittelt. Das Makro LOCAL_USER fügt Benutzer zur sendmail.cf-klasse $=L hinzu. Die Klasse $=L ist eine Liste lokaler Benutzer, deren Mail nicht an den Mail-Hub vermittelt wird. Der folgende Test zeigt, dass ohne das Makro LOCAL_USER die Mail, die an den Benutzer root adressiert ist, an den Mail-Hub geschickt wird: # sendmail -bv root root... deliverable: mailer relay, host smtp.wrotethebook.com, user root@smtp. wrotethebook.com sendmail versucht ganz deutlich, Mail an den Mail-Hub weiterzuleiten, die an root adressiert ist. Um dies zu verhindern, wurde die folgende Zeile in die Konfiguration des Rezeptes aufgenommen: LOCAL_USER(root) Mit diesem Befehl in der Konfiguration zeigt der sendmail -bv-test die folgenden Ergebnisse: # sendmail -bv root root... deliverable: mailer local, user root 3.3 Lokale Mail an einen Mail-Hub übergeben 91

110 Der Test demonstriert die Wirkung des Makros LOCAL_USER. Die root-mail bleibt lokal, was wir ja auch so wollten. Bevor Sie jedoch das Makro LOCAL_USER einsetzen, sollten Sie sicher sein, dass es für Ihre Konfiguration richtig ist, die Mail für root lokal vorzuhalten. Oft wird Mail an den root-zugang über einen Alias an den eigentlichen Zugang des Administrators geschickt. Beispielsweise könnten Sie root an alana schicken, falls Alana Administrator dieses Systems ist und sich üblicherweise unter dem Zugang alana am System anmeldet. In diesem Fall würden Sie einen Alias benutzen und müssten nicht auf das Makro LOCAL_USER zurückgreifen obwohl das Hinzufügen des Makros keinen Schaden anrichtet. Links Alternativen Eine Alternative zu MAIL_HUB ist die Definition LOCAL_RELAY. LOCAL_RELAY bietet eine andere Möglichkeit, um einen Mail Relay Host für Mail zu definieren, die normalerweise durch den Mailer local ausgeliefert wird. Diese Alternative wurde verworfen, weil die LOCAL_RELAY-Definition bereits seit einigen Jahren von den sendmail-entwicklern abgelehnt wird. Wenn sowohl MAIL_HUB als auch LOCAL_RELAY in der gleichen Konfiguration auftauchen, dann interagieren sie auf verschiedene Weise. Wir empfehlen Ihnen, LOCAL_ RELAY zu vermeiden und in Ihren Konfigurationen nur MAIL_HUB einzusetzen. Siehe auch Kapitel 2 bietet ausführliche Beispiele für die Benutzung von Aliasen; speziell Rezept 2.2 zeigt ein Beispiel für das Weiterleiten der Mail von root an einen anderen Benutzernamen. Rezept 3.1 setzt ebenfalls einen Wert für den Mail-Hub im Makro $H. Das Buch sendmail behandelt MAIL_HUB in Abschnitt 4.5.7, LOCAL_USER in Abschnitt und LOCAL_RELAY in Abschnitt Scheinbar lokale Mail an ein Relay übergeben Problem Scheinbar lokale Mail ist Mail, die an lokale Benutzer adressiert zu sein scheint (d. h. die Auslieferungsadresse enthält keinen Hostnamen-Anteil, obwohl die Mail nicht wirklich an einen lokalen Benutzernamen adressiert ist). Konfigurieren Sie sendmail so, dass es diese Mail an einen Mail Relay Server sendet, der in der Lage ist, sie richtig zu verarbeiten. Lösung Legen Sie eine sendmail-konfiguration an, die eine LUSER_RELAY-Definition enthält, mit der der Host identifiziert wird, der scheinbar lokale Mail verarbeiten kann. Hier ist ein Beispiel-LUSER_RELAY-Befehl: dnl Define a relay server for apparently local mail define(`luser_relay', `smtp.wrotethebook.com') 92 Kapitel 3: Weitervermittlung (Relaying)

111 Rechts Erstellen Sie die Datei sendmail.cf neu, und installieren Sie sie. Starten Sie sendmail neu, um die neue Konfiguration einzulesen. Rezept 1.8 behandelt diese Schritte. Diskussion Eine Auslieferungsadresse ohne Hostnamen wird zur Auslieferung an einen lokalen Benutzer dem Mailer local übergeben. Wenn der Benutzeranteil der Adresse keinen gültigen lokalen Benutzernamen oder Alias bestimmt, wird der Fehler»User unknown«zurückgeliefert. Die folgenden Tests zeigen, wie dies bei einer generischen Konfiguration funktioniert: # sendmail -bv fred -Cgeneric-linux.cf fred... User unknown # sendmail -bv craig -Cgeneric-linux.cf craig... deliverable: mailer local, user craig craig ist ein gültiger Benutzername auf diesem Host, Mail wird daher durch den Mailer local ausgeliefert. fred ist kein gültiger lokaler Benutzername, deshalb wird ein Fehler zurückgegeben. Nach dem Hinzufügen der LUSER_RELAY-Definition zur Konfiguration wird Mail an craig wie gehabt ausgeliefert, Mail an fred dagegen wird zur Auslieferung an den Mail Relay Host gesandt: # sendmail -bv fred fred... deliverable: mailer relay, host smtp.wrotethebook.com, user fred@smtp. wrotethebook.com # sendmail -bv craig craig... deliverable: mailer local, user craig Die LUSER_RELAY-Definition setzt den Wert des sendmail.cf-makros $L und fügt dem Regelsatz localaddr (Regelsatz 5) zwei Regeln hinzu. Regelsatz 5 wird aufgerufen, nachdem die lokale Adresse durch die aliases-datenbank verarbeitet wurde. 2 Die beiden Rewrite-Regeln, die durch die LUSER_RELAY-Definition hinzugefügt wurden, werden nur dann ausgeführt, wenn die Empfängeradresse nicht bereits zu einer gültigen Auslieferungsadresse aufgelöst wurde. Die erste LUSER_RELAY-Rewrite-Regel prüft, ob der Benutzername aus der -Adresse ein Schlüssel in der Benutzerdatenbank ist. Falls der Benutzername in der Benutzerdatenbank gefunden werden kann, wird die Mail entsprechend den Anweisungen in dieser Datenbank ausgeliefert. Kann der Benutzername in der Datenbank nicht gefunden werden, wird die Mail an den Relay-Server gesandt, der durch das Makro $L identifiziert wird. Das bedeutet: Wenn eine lokale Auslieferungsadresse nicht in einen lokalen Benutzernamen aufgelöst werden kann oder nicht durch die aliases-datenbank oder die Benutzerdatenbank abgedeckt ist, dann wird die Mail zur Auslieferung an den LUSER_RELAY-Server gesandt. Im letzten oben gezeigten Test wird Mail, die an fred adressiert ist, an den LUSER_RELAY- Server geschickt. Die LUSER_RELAY-Konfiguration nimmt an, dass der Server weiß, wie die 2 Regelsatz 5 wird nur aufgerufen, wenn das Flag F=5 für den ausgewählten Mailer gesetzt ist. Standardmäßig ist dieses Flag für den Mailer local gesetzt, der auch in unseren Beispielen benutzt wurde. 3.4 Scheinbar lokale Mail an ein Relay übergeben 93

112 Mail an fred ausgeliefert werden muss. Oft heißt dies, dass der Server eine große aliases- Datei besitzt, die definiert, wie Mail an die Benutzer geleitet wird. Im Gegensatz zur MAIL_HUB-Konfiguration, die in Rezept 3.3 beschrieben wurde, geht die LUSER_RELAY-Konfiguration nicht davon aus, dass der Server ein zentrales Mail-Spool-Verzeichnis vorhält. Die LUSER_RELAY-Konfiguration erlaubt es dem Client, einige lokale Mails auszuliefern, und schickt andere zur Auslieferung an den Server. Eine Alternative zu LUSER_RELAY besteht darin, eine große aliases-datei auf dem Client zu haben. Dabei könnte es sich um eine lokale Datei oder auch um eine zentral verwaltete Datei handeln, die über NIS oder einen anderen Datenbankdienst erreichbar ist. Noch beliebter ist es, von den Benutzern zu verlangen, den Hostnamen zur -Adresse hinzuzufügen, wenn der Hostname für die Auslieferung erforderlich ist mit anderen Worten: ihnen so lange den Fehler»User unknown«vorzuhalten, bis sie verstanden haben, dass sie ihre s richtig adressieren müssen. All dies sind gangbare Alternativen. Links Siehe auch Kapitel 2 bietet Beispiele sowohl für die aliases-datenbank als auch für die Benutzerdatenbank. Das Buch sendmail behandelt LUSER_RELAY in Abschnitt UUCP-Mail an ein Relay übergeben Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es UUCP-Mail an einen Mail Relay Host sendet, der eine direkte UUCP-Verbindung besitzt. Lösung Legen Sie eine sendmail-konfiguration an, die eine UUCP_RELAY-Definition enthält, mit der das Mail Relay identifiziert wird, das in der Lage ist, UUCP-Mail zu verarbeiten. Hier ist ein Beispiel: dnl Define a relay server for UUCP mail define(`uucp_relay', `uucp.wrotethebook.com') Erstellen Sie die Datei sendmail.cf, installieren Sie sie, und starten Sie sendmail neu, wie in Rezept 1.8 beschrieben. Diskussion Die UUCP_RELAY-Definition setzt den Wert des sendmail.cf-makros $Y, fügt UUCP zur Klasse $=P hinzu und erweitert den Regelsatz Parse1 um eine Regel. Die neue Rewrite-Regel Parse1 sendet UUCP-Mail, die durch den lokalen Host nicht ausgeliefert werden kann, an das Mail Relay, das durch das Makro $Y gekennzeichnet ist. Wenn $Y nicht definiert 94 Kapitel 3: Weitervermittlung (Relaying)

113 Rechts ist, nimmt sendmail an, dass der lokale Host alle UUCP-Mails ausliefern kann. Die Klasse $=P enthält eine Liste mit Pseudodomains (Domainnamen, die intern von sendmail benutzt werden), die sendmail nicht im DNS nachzusehen versucht. Die Pseudodomain.UUCP wird von sendmail benutzt, um Mail zu markieren, die als UUCP-Mail behandelt werden soll. Wenn Mail, die an die Pseudodomain.UUCP adressiert ist, auf die neue Regel im Regelsatz Parse1 trifft, dann wird die Adresse als Mail-Auslieferungstriple umgeschrieben, das die Mail an den UUCP-Mail Relay Host schickt, der im Makro $Y definiert wurde. Ein sendmail -bt-test verdeutlicht dieses Vorgehen: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /parse crab!craig Cracked address = $g Parsing envelope recipient address canonify input: crab! craig Canonify2 input: craig crab. UUCP > Canonify2 returns: craig crab. UUCP. > canonify returns: craig crab. UUCP. > parse input: craig crab. UUCP. > Parse0 input: craig crab. UUCP. > Parse0 returns: craig crab. UUCP. > Parse1 input: craig crab. UUCP. > MailerToTriple input: < uucp. wrotethebook. com > craig crab. UUCP. > MailerToTriple returns: $# relay $@ uucp. wrotethebook. com $: craig crab. UUCP. > Parse1 returns: $# relay $@ uucp. wrotethebook. com $: craig crab. UUCP. > parse returns: $# relay $@ uucp. wrotethebook. com $: craig crab. UUCP. > 2 input: craig crab. UUCP. > 2 returns: craig crab. UUCP. > MasqSMTP input: craig crab. UUCP. > MasqSMTP returns: craig crab. UUCP. > final input: craig crab. UUCP. > final returns: crab! craig mailer relay, host uucp.wrotethebook.com, user crab!craig > /quit Dieser Test bittet sendmail, eine Auslieferungsadresse zu parsen, die im traditionellen UUCP-Bang-Format, host!benutzer, geschrieben ist. Der Regelsatz canonify schreibt die Adresse in das Standardadressformat für das Internet um und fügt die Pseudodomain.UUCP hinzu. Die Adresse wird bis zum Regelsatz Parse1 unverändert weitergeführt. Dieser schreibt die Adresse dann in ein Mail-Auslieferungstriple um. relay ist der Mailer, der in dem Triple verwendet wird. Der Wert, der vom Makro $Y bezogen wird, ist der Host aus dem Triple. Die Benutzeradresse verbleibt jedoch bis zum Regelsatz final im.uucp-pseudodomain-format, der die Benutzeradresse wieder in das UUCP-Bang-Format zurückwandelt. Durch diese ganzen Aktionen sendet man Auslieferungsadressen im Bang- Format an den UUCP-Relay Host und verlässt sich darauf, dass dieser Host die Mail ausliefert. 3.5 UUCP-Mail an ein Relay übergeben 95

114 UUCP_RELAY ist nicht das einzige Pseudodomain-Mail Relay, das in sendmail konfiguriert werden kann. Folgende Definitionen stehen ebenfalls zur Verfügung: BITNET_RELAY Kennzeichnet ein Mail Relay, das an das BITNET-Netzwerk angeschlossen ist (ein veraltetes Netzwerk, das Sie vermutlich nicht benutzen werden). DECNET_RELAY Kennzeichnet einen Mail Relay Host, der an ein DECnet-Netzwerk angeschlossen ist. DECnet ist eine veraltete Netzwerktechnik, die von der Digital Equipment Corporation stammt. Sie werden dieses Netzwerk wahrscheinlich nicht benutzen. FAX_RELAY Kennzeichnet eine an einen FAX-Server. All diese Relays werden auf die gleiche Weise definiert wie UUCP_RELAY in diesem Rezept. Ersetzen Sie einfach das Schlüsselwort und den Namen des Relay Hosts in dem Rezept durch die Werte, die Sie benötigen, und erstellen Sie die Datei sendmail.cf neu. Keine dieser Definitionen UUCP_RELAY, BITNET_RELAY, DECNET_RELAY oder FAX_RELAY jedoch ist besonders weit verbreitet. BITNET und DECnet stellen veraltete Techniken dar und sollten nicht benutzt werden. UUCP befördert nur einen Bruchteil der globalen s, und von diesem Bruchteil wird das meiste transparent durch Internet/UUCP-Gateways geleitet und verwendet das Standard-Internet-Adressformat. FAX_RELAY ist nicht flexibel genug, um die Vielfalt der s an FAX-Server einfach zu verarbeiten. Hersteller von FAX-Servern können ihren Markt nicht auf solche Sites beschränken, deren Administratoren genügend Ahnung haben, um sendmail anzupassen. Aus diesem Grund bieten die Hersteller normalerweise eine Technik an, die es einem Benutzer erlaubt, ein FAX ohne Änderungen an sendmail zu senden. Nur eine der vier Definitionen, nämlich UUCP_RELAY, hat einen wirklichen Nutzen und wird daher in diesem Buch behandelt. Links Siehe auch Das Buch sendmail behandelt das UUCP_RELAY in Abschnitt 4.5.8, das FAX_RELAY in Abschnitt 4.5.3, das BITNET_RELAY in Abschnitt und das DECNET_RELAY in Abschnitt Mail für alle Hosts in einer Domain vermitteln Problem Sie wurden gebeten, einen Mail Relay Host einzurichten, der Mail für alle Hosts innerhalb der lokalen Domain weitervermittelt. 96 Kapitel 3: Weitervermittlung (Relaying)

115 Rechts Lösung Legen Sie auf dem Mail Relay Host die Datei relay-domains an, die den Namen Ihrer lokalen Domain enthält. Zum Beispiel: # cat >> /etc/mail/relay-domains wrotethebook.com Ctrl-D Starten Sie sendmail neu, um sicherzustellen, dass es die Datei relay-domains liest: # kill -HUP `head -1 /var/run/sendmail.pid` Diskussion Es werden keine m4-konfigurationsbefehle benötigt, um diesen Mail Relay Host anzulegen. sendmail sucht nach einer Datei namens /etc/mail/relay-domains und fügt die Namen, die es dort findet, standardmäßig der Klasse $=R hinzu. Es gibt zwei Möglichkeiten, um den vorgegebenen Pfadnamen der Datei /etc/mail/relay-domains zu ändern: confcr_file Diese Definition setzt den Pfad der Datei, die in die Klasse $=R geladen wird. Die Definition confcr_file wird nur benutzt, wenn es erforderlich ist, den vorgegebenen Dateinamen zu ändern. Um beispielsweise die Klasse $=R aus einer Datei namens /etc/sendmail.cr zu laden, fügen Sie der Hauptkonfigurationsdatei folgende Zeile hinzu: define(`confcr_file', `/etc/sendmail.cr') RELAY_DOMAIN_FILE Dieses Makro legt den Pfad zu einer zusätzlichen Datei fest, die Daten für die Klasse $=R bereitstellt. Wenn die Standarddatei, die üblicherweise /etc/mail/relay-domains heißt, ebenfalls existiert, wird sie zur Klasse $=R hinzugefügt. Beispielsweise fügt der folgende Befehl Daten aus der Datei /etc/sendmail.cr zur Klasse $=R hinzu: RELAY_DOMAIN_FILE(`/etc/sendmail.cr') Keiner dieser Befehle taucht in diesem Rezept auf, weil es im Allgemeinen eine schlechte Idee ist, den vorgegebenen Dateinamen einer Datei zu ändern, die in der sendmail-konfiguration benutzt wird. Andere Administratoren müssen möglicherweise Informationen auf Ihrem System finden. Das ist für sie einfacher, wenn die Informationen an den Standardorten gespeichert sind. Bevor wir die Datei relay-domains angelegt haben, hat sendmail die gesamte Mail-Weitervermittlung blockiert selbst das Relaying von anderen Hosts innerhalb der lokalen Domain. sendmail erlaubt standardmäßig kein Relaying. Ein Test, der ausgeführt wurde, bevor wir die Datei relay-domains angelegt haben, belegt das. Unten wird telnet auf rodent.wrotethebook.com verwendet, um eine direkte Verbindung zum SMTP-Port auf dem sendmail-server smtp.wrotethebook.com herzustellen: 3.6 Mail für alle Hosts in einer Domain vermitteln 97

116 $ telnet smtp Trying Connected to Escape character is '^]'. 220 smtp.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 15 Aug :25: HELO rodent.wrotethebook.com 250 smtp.wrotethebook.com Hello rodent.wrotethebook.com [ ], pleased to meet you MAIL Sender ok RCPT Relaying denied QUIT smtp.wrotethebook.com closing connection Connection closed by foreign host. Dieser Test zeigt, dass der Absender den Fehler»Relaying denied«erhält, der anzeigt, dass die vorgegebene sendmail-konfiguration des Hosts in der lokalen Domain nicht erlaubt, Mail an einen dritten Host weiterzuvermitteln. Nachdem der Domainname wrotethebook.com in die Datei /etc/mail/relay-domains geschrieben und sendmail neu gestartet wurde, liefert ein erneuter Test ein anderes Ergebnis: $ telnet smtp Trying Connected to Escape character is '^]'. 220 smtp.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 15 Aug :12: HELO rodent.wrotethebook.com 250 smtp.wrotethebook.com Hello rodent.wrotethebook.com [ ], pleased to meet you MAIL From:<craig@rodent.wrotethebook.com> craig@rodent.wrotethebook.com... Sender ok RCPT To:<sara@crab.wrotethebook.com> sara@crab.wrotethebook.com... Recipient ok DATA 354 Enter mail, end with "." on a line by itself Subject: Test This is a test of wrotethebook.com entry in the relay-domains file g8rjclxf Message accepted for delivery QUIT smtp.wrotethebook.com closing connection Connection closed by foreign host. Nun ist es Hosts innerhalb der lokalen Domain erlaubt, über smtp.wrotethebook.com zu vermitteln ohne Änderungen an der m4-konfiguration oder die Notwendigkeit, die Datei sendmail.cf neu zu erstellen. Mail von oder zu Hosts in der Domain wrotethebook. com wird weitervermittelt. Mail, die weder von einem Host in der Domain wrotethebook. com stammt noch an ihn gerichtet ist, wird weiterhin vom Relaying ausgeschlossen. Links 98 Kapitel 3: Weitervermittlung (Relaying)

117 Rechts Alternativen Es gibt vier alternative Lösungen: das Makro RELAY_DOMAIN, die Funktion relay_entire_ domain, die Funktion promiscuous_relay und die Funktion relay_local_from. Das Beispiel im Lösungsabschnitt fügt nur einen Domainnamen in die Klasse $=R ein. Es ist möglich, aus der m4-konfiguration heraus einzelne Domains zur Klasse $=R hinzuzufügen, indem das Makro RELAY_DOMAIN verwendet wird. Die folgenden Zeilen hinzugefügt zur sendmail-konfiguration hätten die gleiche Wirkung wie die Datei relaydomains, die oben definiert wurde: dnl RELAY_DOMAIN adds a domain name to class R RELAY_DOMAIN(`wrotethebook.com') Der Befehl RELAY_DOMAIN verlangt jedoch Änderungen an der m4-konfiguration sowie ein Neuerstellen und Neuinstallieren der Datei sendmail.cf. Wenn Sie die Datei relaydomains verwenden, sind diese Dinge nicht erforderlich, weshalb diese Lösung einfacher zu benutzen ist. Es gibt einige weitere alternative Lösungen für dieses Problem. Wir hätten die Funktion relay_entire_domain benutzen können, um die Weitervermittlung für Hosts in der lokalen Domain zu aktivieren. Wenn der folgende Befehl zu einer Grundkonfiguration hinzugefügt wird, erhalten wir das gleiche Ergebnis wie bei diesem Rezept: dnl A feature that relays mail for the local domain FEATURE(`relay_entire_domain')dnl Die Funktion relay_entire_domain legt einige Rewrite-Regeln an, die Mail von einem beliebigen Host aus einer Domain, die in der Klasse $=m aufgeführt ist, weitervermittelt. Standardmäßig enthält die Klasse $=m den Domainnamen des Server-Systems. Das bedeutet: Klasse $=m enthält wrotethebook.com auf einem Server namens smtp.wrotethebook.com. Diese alternative Lösung funktioniert ganz gut, wurde aber aus verschiedenen Gründen verworfen. Erstens ist diese Lösung etwas komplizierter als diejenige, die in diesem Rezept zum Einsatz kam. Die Benutzung der Funktion relay_entire_domain erfordert Modifikationen an der m4-konfiguration, was bedeutet, dass die Datei sendmail.cf neu erstellt und neu installiert werden muss, bevor sendmail wieder gestartet werden kann. Wird nur die Datei relay-domains verwendet, muss lediglich sendmail neu gestartet werden. Zweitens wird der Wert in der Klasse $=m intern von sendmail ermittelt. Normalerweise stimmt er, das ist also nicht der Punkt, allerdings erhält der Administrator eine größere Kontrolle, wenn er den Wert in relay-domains einstellt. Drittens ist relay-domains selbstdokumentierend. Ein schneller Blick in die Datei verrät Ihnen, von welchen Domains der Server die Mail weitervermitteln darf. Viertens ist die Datei relay-domains sehr flexibel. In der Problemstellung wird angegeben, dass ein Mail Relay für andere Hosts in der lokalen Domain erzeugt werden soll. Es han- 3.6 Mail für alle Hosts in einer Domain vermitteln 99

118 delt sich hierbei um ein häufig auftretendes Beispiel für die Weitervermittlung. In der Datei relay-domains kann jedoch jede Domain aufgeführt werden. Mail, die von einem beliebigen Host in einer dieser Domains stammt, wird weitervermittelt. Stellen Sie sich zum Beispiel vor, wir wollten ein Mail Relay anlegen, das Mail für die Domains wrotethebook.com, ora.com, oreilly.com und sybex.com weitervermittelt. Dazu bräuchten wir nur die folgende relay-domains-datei: Links # cat /etc/mail/relay-domains wrotethebook.com ora.com oreilly.com sybex.com Dieses Rezept soll die Weitervermittlung von jedem Host in einer bestimmten Domain aus erlauben. Die genannten Gründe geben der Domain relay-domains für diesen speziellen Anwendungsfall einen leichten Vorteil gegenüber der Funktion relay_entire_domain, weshalb relay-domains für dieses Rezept gewählt wurde. Aus Sicherheitsgründen wurden zwei weitere alternative Lösungen verworfen: promiscuous_relay Diese Funktion aktiviert das Relaying für alle Hosts, einschließlich der lokalen Domain. Das würde unser Problem lösen. Allerdings wirft diese Funktion mehr Probleme auf, als sie löst, da Spammer das Relay schnell aufspüren und ausnutzen würden. Setzen Sie die Funktion promiscuous_relay niemals ein. Selbst wenn Ihr Host durch eine Firewall geschützt wäre, müssen Sie Ihr eigenes System vor einem Angriff schützen dies ist ein einfacher Grundsatz der»sicherheit durch mehrstufige Verteidigung«. Es ist nie gut, ein offenes Relay zu schaffen. relay_local_from Diese Funktion klingt, als wäre sie eine großartige Lösung für das Problem. Sie schaltet die Weitervermittlung für Mail ein, falls die -Adresse in der Umschlagabsenderadresse der Mail den Namen eines Hosts in der lokalen Domain enthält. Das Problem ist, dass diese Funktion völlig von der -Adresse in der Umschlagabsenderadresse abhängt. Leider können Spammer ganz einfach die Umschlagabsenderadresse auf der Spam-Mail umschreiben, so dass es aussieht, als würde sie aus Ihrer lokalen Domain stammen. Aus diesem Grund wurde diese Funktion als mögliche Lösung für unser Problem abgelehnt. Siehe auch Das Buch sendmail behandelt das Makro RELAY_DOMAIN_FILE in Abschnitt , die Funktion relay_entire_domain in Abschnitt 7.4.5, die Funktion relay_local_from in Abschnitt und die Funktion promiscuous_relay in Abschnitt Die cf/readme enthält aktuelle Informationen über all diese Relay-Funktionen. 100 Kapitel 3: Weitervermittlung (Relaying)

119 Rechts 3.7 Mail für einzelne Hosts vermitteln Problem Sie wurden gebeten, einen Mail Relay Host zu konfigurieren, um Mail für bestimmte, nicht jedoch für alle Hosts in einer Domain zu vermitteln. Lösung Legen Sie auf dem Mail Relay Host die Datei relay-domains an, die den Namen aller Hosts enthält, für die Mail vermittelt werden soll. Fügen Sie der sendmail-konfiguration auf dem Mail Relay Host die Funktion relay_hosts _only hinzu. Hier ist der erforderliche FEATURE-Befehl: dnl Configure the server to relay mail for specific hosts FEATURE(`relay_hosts_only') Erstellen Sie dann die sendmail.cf, kopieren Sie sie nach /etc/mail, und starten Sie sendmail neu, wie in Rezept 1.8 beschrieben. Diskussion Auf unserem Beispiel-Mail Relay Host erzeugen wir folgende relay-domains-datei: # cat > /etc/mail/relay-domains rodent.wrotethebook.com horseshoe.wrotethebook.com jamis.wrotethebook.com tcp.ora.com chill.sybex.com wrotethebook.com Ctrl-D Ein sendmail -bt-test zeigt die Werte, die in der Klasse $=R gespeichert sind: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $=R tcp.ora.com rodent.wrotethebook.com chill.sybex.com jamis.wrotethebook.com horseshoe.wrotethebook.com wrotethebook.com > /quit Normalerweise werden Werte in der Klasse $=R als Domainnamen interpretiert, und jeder Host innerhalb einer Domain, die in der Klasse $=R aufgeführt ist, darf Mail durch 3.7 Mail für einzelne Hosts vermitteln 101

120 den Server weitervermitteln. Rezept 3.6 nutzt diese Tatsache aus, um Mail für ganze Domains zu vermitteln. In diesem Fall jedoch wollen wir, dass wrotethebook.com als Hostname und nicht als Domainname interpretiert wird und dass Mail für diesen Host geroutet wird. Die Funktion relay_hosts_only ändert die Art und Weise, wie die Einträge in der Klasse $=R benutzt werden. In der Standardkonfiguration enthalten Mustervergleiche mit der Klasse $=R den String $*$=R, der keinem oder mehreren Token entspricht sowie jedem Wert, der in $=R gespeichert ist. Das heißt, wrotethebook.com, crab.wrotethebook.com und fun.rodent.wrotethebook.com würden alle auf den Wert wrotethebook.com passen, der in der oben gezeigten Klasse $=R gespeichert ist. Die Funktion relay_hosts_only ändert den String in dem Mustervergleich auf $=R, was bedeutet, dass nur exakte Treffer, die in der Klasse $=R gefunden werden, auch gültige Treffer sind. Wenn relay_hosts_only mit den Werten unserer Beispielklasse $=R benutzt wird, entspricht rodent.wrotethebook.com dem Muster, da rodent.wrotethebook.com in $=R enthalten ist; crab.wrotethebook.com passt nicht obwohl der Wert wrotethebook.com in dem Feld auftaucht. Nur ein Host namens wrotethebook.com würde diesem besonderen Wert entsprechen, wenn relay_hosts _only benutzt wird. Einige Tests demonstrieren den Einfluss der Funktion relay_hosts_only. Ein telnet-test von rodent aus zeigt, dass die Konfiguration von smtp die Weitervermittlung für rodent erlaubt: $ telnet smtp.wrotethebook.com smtp Trying Connected to Escape character is '^]'. 220 smtp.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 15 Aug :36: HELO rodent.wrotethebook.com 250 smtp.wrotethebook.com Hello rodent.wrotethebook.com [ ], pleased to meet you MAIL From:<craig@rodent.wrotethebook.com> craig@rodent.wrotethebook.com... Sender ok RCPT To:<tyler@example.com> tyler@example.com... Recipient ok QUIT smtp.wrotethebook.com closing connection Connection closed by foreign host. Wenn der gleiche Test von crab aus ausgeführt wird, sieht man, dass crab nicht durch smtp vermitteln darf: # telnet smtp.wrotethebook.com smtp Trying Connected to Escape character is '^]'. 220 smtp.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 15 Aug :43: HELO crab.wrotethebook.com 250 smtp.wrotethebook.com Hello crab.wrotethebook.com [ ], pleased to meet you Links 102 Kapitel 3: Weitervermittlung (Relaying)

121 Rechts MAIL Sender ok RCPT Relaying denied QUIT smtp.wrotethebook.com closing connection Connection closed by foreign host. Ein letzter Test von crab aus zeigt den vollen Einfluss der Klasse $=R auf die Weitervermittlung: $ telnet smtp.wrotethebook.com smtp Trying Connected to smtp. Escape character is '^]'. 220 smtp.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 15 Aug :20: HELO crab.wrotethebook.com 250 smtp.wrotethebook.com Hello crab.wrotethebook.com [ ], pleased to meet you MAIL From:<craig@crab.wrotethebook.com> craig@crab.wrotethebook.com... Sender ok RCPT To:<kathy@rodent.wrotethebook.com> kathy@rodent.wrotethebook.com... Recipient ok QUIT smtp.wrotethebook.com closing connection Connection closed by foreign host. In diesem Fall vermittelt crab die Mail erfolgreich durch smtp. Wenn entweder der sendende Host oder der Empfänger-Host in der Klasse $=R aufgeführt sind, wird Mail zur Vermittlung angenommen. Deshalb wird Mail, die von crab an rodent gesandt wird, zur Vermittlung akzeptiert, obwohl crab eigentlich nicht vermitteln darf, da rodent vermitteln darf und außerdem das Ziel dieser Mail ist. Siehe auch Abschnitt im Buch sendmail behandelt die Funktion relay_hosts_only. Die Rezepte 3.6 und 3.8 liefern Lösungen für ähnliche Probleme, die möglicherweise ebenfalls betrachtet werden müssen. 3.8 Die Weitervermittlung auf einem Mail Exchanger konfigurieren Problem Sie wurden gebeten, sendmail auf einem Mail Exchanger zu konfigurieren, um die Weitervermittlung für alle Systeme zu erlauben, die ihn rechtmäßig als ihren Mail Exchanger nutzen. 3.8 Die Weitervermittlung auf einem Mail Exchanger konfigurieren 103

122 Lösung Holen Sie vom Domain-Administrator eine Aufstellung der Hostnamen, deren MX- Records das lokale System als ihren Mail Exchanger aufführen. Fügen Sie die Liste der Hostnamen der Datei local-host-names hinzu, um eingehende Mail zu verarbeiten, die an eine Mailbox auf dem Mail Exchanger ausgeliefert oder wie durch die Dateien aliases oder.forward angewiesen weitergeleitet werden soll. Fügen Sie die Hostnamen aus der Liste der Datei relay-domains hinzu, um Mail zu verarbeiten, die weitervermittelt werden soll. Links Diskussion Falls Sie Zugriff auf ein System haben, das in der Lage ist, die gesamte Domain aufzulisten, dann können Sie mit diesen Unix-Befehlen ein bisschen zaubern, um alle Hosts in der Domain zu erhalten, die Ihr Mail-System als ihren MX-Server verwenden: 3 # cd /etc/mail # host -l wrotethebook.com \ > grep 'mail.*mail\.wrotethebook\.com' \ > awk '{ print $1 }' > temp-relay-domains Dieses Beispiel schreibt die Liste in eine Datei namens temp-relay-domains. Überprüfen Sie den Inhalt der Datei, bevor Sie die Daten entweder in der Datei relay-domains oder in der Datei local-host-names speichern. Außerdem verlangt dieses Beispiel, dass der sendmail-administrator direkten Zugriff auf ein System besitzt, das berechtigt ist, die gesamte Domain-Datei auszugeben. Sie müssen den Domain-Administrator nach der Liste der Hostnamen fragen, es sei denn, Ihnen ist die doppelte Pflicht als DNS- und als sendmail- Administrator übertragen worden. Die Datei local-host-names konfiguriert den Mail Exchanger so, dass er Mail zur lokalen Auslieferung oder Weiterleitung akzeptiert, wie in Kapitel 2 besprochen. Die Datei relaydomains konfiguriert den Mail Exchanger zur Weitervermittlung. Mail zu oder von Hosts in der Datei relay-domains wird vermittelt. Beachten Sie, dass die Namen in der Datei relay-domains dieses Beispiels als Hostnamen und nicht als Domainnamen betrachtet werden, da wir die Funktion relay_hosts_only einsetzen. Alternativen Die Funktion relay_based_on_mx ist eine alternative Lösung für das Problem, das zu Beginn beschrieben wird. Wenn die Funktion relay_based_on_mx verwendet wird, vermittelt sendmail Mail für alle Systeme weiter, die den lokalen Host in ihrem MX-Record 3 In dem Beispiel führen wir eine Domain namens wrotethebook.com auf und suchen mit grep nach mail.wrotethebook.com. Ersetzen Sie diese Werte durch die richtigen Werte für Ihre Domain und den Hostnamen Ihres Mail-Systems. 104 Kapitel 3: Weitervermittlung (Relaying)

123 Rechts aufführen. Die relay_based_on_mx-lösung ist einfacher als dieses Rezept und genauso effektiv, wurde aber aus zwei Gründen verworfen: Erstens haben Sie keine Kontrolle über das Anlegen von MX-Records. Jeder Domain-Administrator irgendwo auf der Welt könnte Ihren Mail Relay Host als Mail Exchanger für seine Domain festlegen. Danach könnte jeder Host in dieser entfernten Domain Ihren Host als Mail Relay nutzen. Das heißt, Sie können nicht sicher sagen, welche Hosts Ihr Relay nutzen. Zweitens sagen die sendmail-entwickler, dass»es normalerweise besser ist, eine Liste mit Hosts/Domains zu pflegen, für die der Server als Relay arbeitet«, als die Funktion relay_based_on_mx zu nutzen. Neben der oben erwähnten fehlenden Kontrolle erwähnen sie die Möglichkeit von Auslieferungsproblemen, wenn der entfernte DNS-Server langsam ist, und sie sagen, dass manche Adressformate (vor allem der %-Hack) nicht so behandelt werden, wie Sie es erwarten würden. Der Kontrollverlust und die Empfehlung der sendmail-entwickler waren für uns Grund genug, uns für die Lösung aus Rezept 3.8 zu entscheiden. Falls Einfachheit Ihnen wichtiger ist, dann tut es für Sie auch die Funktion relay_based_on_mx. Siehe auch Die Beschreibung der Funktion relay_based_on_mx in der Datei cf/readme erläutert die Empfehlungen der Entwickler. Das Buch sendmail behandelt relay_based_on_mx in Abschnitt Die Rezepte 2.1 und 3.7 liefern wichtiges Material für dieses Rezept. 3.9 Die Klasse $=R über LDAP laden Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es die Namen der Hosts und Domains, denen das Recht zur Weitervermittlung eingeräumt wird, von einem LDAP- Server einliest. Lösung Aktivieren Sie auf dem LDAP-Server die Unterstützung für das sendmail-schema, wie in Rezept 1.3 beschrieben. Beachten Sie, dass dies nur einmal geschehen muss. Fügen Sie auf dem LDAP-Server die Namen der Hosts und Domains hinzu, denen das Relaying gestattet ist. Benutzen Sie das Objektklassenformat sendmailmtaclass, das in der Datei sendmail.schema definiert ist. In der Diskussion wird an einem Beispiel demonstriert, wie dies auf einem Server mit OpenLDAP zu geschehen hat. 3.9 Die Klasse $=R über LDAP laden 105

124 Setzen Sie auf dem Mail Relay Host den Befehl sendmail -bt -d0.1 ein, um zu prüfen, ob sendmail mit LDAP-Unterstützung kompiliert wurde. Der String LDAPMAP muss in der»compiled with:«-liste auftauchen. Wenn sendmail nicht mit Unterstützung für LDAP kompiliert wurde, dann kompilieren und installieren Sie es noch einmal, wie in Rezept 1.3 gezeigt. Sobald sendmail LDAP unterstützt, fahren Sie mit den nächsten Schritten fort. Fügen Sie auf dem Mail Relay Host das Makro RELAY_DOMAIN_FILE zur sendmail-konfiguration hinzu. Es als Dateipfad der Relay-Domain fest, wodurch sendmail angewiesen wird, mit Hilfe des Standard-sendmail-Schemas die Werte der Klasse $=R vom LDAP-Server zu lesen. Verwenden Sie die Definition confldap_cluster, um das Makro ${sendmailmtacluster} auf den gleichen Wert zu setzen, der auch im Attribut sendmailmtacluster des LDAP-Eintrags benutzt wird. Hier sind die Beispielkonfigurationsbefehle: dnl Set the LDAP cluster value define(`confldap_cluster', `wrotethebook.com') dnl Tell sendmail to load $=R via LDAP Erstellen Sie die Konfigurationsdatei, kopieren Sie sie nach /etc/mail/sendmail.cf, und starten Sie sendmail mit der neuen Konfiguration neu, wie in Rezept 1.8 beschrieben. Diskussion Dieses Rezept geht davon aus, dass LDAP richtig installiert worden ist und läuft. Hier ist nicht die passende Stelle, um mit LDAP-Experimenten zu beginnen. Sowohl LDAP als auch sendmail sind große, komplexe Systeme. Sie sollten einige Erfahrung im Umgang mit LDAP besitzen, bevor Sie versuchen, es zusammen mit sendmail anzuwenden. Die Datei sendmail.schema, die in der sendmail-distribution enthalten ist, muss in die LDAP-Konfiguration aufgenommen werden, damit LDAP Anfragen von sendmail verstehen und richtig bearbeiten kann. 4 Der LDAP-Administrator muss sicherstellen, dass LDAP in der Lage ist, mit dem sendmail-standardschema zu arbeiten, bevor er der LDAP-Datenbank sendmail-daten hinzufügt. Der LDAP-Administrator erstellt mit Hilfe des sendmail-schemas eine LDIF-Datei, um die Liste der Hosts zu definieren, denen Relay-Berechtigungen gewährt werden. Anschließend führt er ldapadd aus, um den Inhalt der LDIF-Datei der LDAP-Datenbank hinzuzufügen. Hier ist ein Beispiel, das alle Hostnamen aus der Datei relay-domains hinzufügt, die in Rezept 3.7 benutzt wurde: # cat > ldap-relay-domains dn: sendmailmtaclassname=r, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtaclass sendmailmtacluster: wrotethebook.com 4 Sie können natürlich Ihr eigenes Schema entwerfen. Das ist aber kein Thema für ein sendmail-buch. Links 106 Kapitel 3: Weitervermittlung (Relaying)

125 Rechts sendmailmtaclassname: R sendmailmtaclassvalue: rodent.wrotethebook.com sendmailmtaclassvalue: horseshoe.wrotethebook.com sendmailmtaclassvalue: jamis.wrotethebook.com sendmailmtaclassvalue: tcp.ora.com sendmailmtaclassvalue: chill.sybex.com sendmailmtaclassvalue: wrotethebook.com Ctrl-D # ldapadd -x -D "cn=manager,dc=wrotethebook,dc=com" \ > -W -f ldap-relay-domains Enter LDAP Password: SecretLDAPpassword adding new entry "sendmailmtaclassname=r, dc=wrotethebook, dc=com" Ein ldapsearch-test zeigt die Daten in der LDAP-Datenbank: 5 # ldapsearch -LLL -x '(sendmailmtaclassname=r)' sendmailmtaclassvalue dn: sendmailmtaclassname=r, dc=wrotethebook, dc=com sendmailmtaclassvalue: rodent.wrotethebook.com sendmailmtaclassvalue: horseshoe.wrotethebook.com sendmailmtaclassvalue: jamis.wrotethebook.com sendmailmtaclassvalue: tcp.ora.com sendmailmtaclassvalue: chill.sybex.com sendmailmtaclassvalue: wrotethebook.com Sobald die Daten dem LDAP-Server hinzugefügt wurden, kann das sendmail-system dazu konfiguriert werden, sie zu lesen. Die Liste der Hosts, denen Relay-Berechtigungen gewährt werden, wird der LDAP-Datenbank als Werte in einem einzigen sendmailmtaclass-objektklassen-record hinzugefügt. Wie das Attribut sendmailmtaclassname verdeutlicht, werden diese Werte in der Klasse $=R gespeichert. Normalerweise wird die Klasse $=R aus der Datei /etc/mail/relay-domains geladen. Mit dem Makro RELAY_DOMAIN_FILE geben Sie eine weitere Datenquelle für die Klasse $=R an. Der im Pfadfeld des Makros weist sendmail an, die Klasse $=R mit Werten zu laden, die vom LDAP-Server bezogen werden. Die Wirkung des auf das Makro RELAY_DOMAINS_FILE kann leicht mit Hilfe des Befehls sendmail -bt untersucht werden: # rm f /etc/mail/relay-domains # sendmail bt Cgeneric-linux.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $=R > /quit # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $=R rodent.wrotethebook.com chill.sybex.com 5 Wenn ldapsearch die Argumente -h und -b verlangt, dann fordert sendmail ebenfalls die entsprechenden Werte. In Rezept 5.9 finden Sie ein Beispiel für das Setzen von -h und -b für sendmail. 3.9 Die Klasse $=R über LDAP laden 107

126 jamis.wrotethebook.com horseshoe.wrotethebook.com wrotethebook.com tcp.ora.com > /quit Der rm-befehl in diesem Test dient lediglich dazu, zu zeigen, dass aus der Datei relaydomains keine Werte in die Klasse $=R geladen werden. Auf einem echten System werden Sie möglicherweise sowohl die Datei relay-domains als auch LDAP nutzen. Der erste sendmail -bt-test lädt die generic-linux.cf-konfiguration, die mit der sendmail- Distribution bereitgestellt wird. Der Befehl $=R zeigt den Inhalt der Klasse $=R, die in diesem Fall leer ist. Der sendmail -bt-test wird mit der Konfigurationsdatei sendmail.cf, die in diesem Rezept angelegt wurde, erneut ausgeführt. Dieses Mal gibt der Befehl $=R die Werte aus, die vom LDAP-Server bezogen werden. Die Klasse $=R ist nicht die einzige Klasse, die über LDAP geladen werden kann. Jede Klasse, die aus einer Datei geladen wird, kann über LDAP geladen werden, indem der Dateipfadname im Befehl F durch den ersetzt wird. Dabei kommt folgende Syntax zum Einsatz: F{name}@LDAP Hier ist name der Name der Klasse. Der gleiche Name wird dann als Wert für das Attribut sendmailmtaclassname in dem LDAP-Record verwendet, das die Werte definiert, die in die Klasse geladen werden. Beachten Sie, dass dies der Klassenname ohne die geschweiften Klammern ist. Dieses Rezept verwendet die Definition confldap_cluster, da das LDAP-Record, das für dieses Rezept erzeugt wurde, das Attribut sendmailmtacluster enthält. sendmail-ldap- Records gelten entweder für einen einzelnen Host oder für eine Gruppe von Hosts, die sendmail als Cluster bezeichnet. Ein Record, das für einen einzelnen Host gilt, verwendet das Attribut sendmailmtahost; ein Record, das für eine Gruppe von Hosts gilt, verwendet das Attribut sendmailmtacluster. Wird confldap_cluster nicht angegeben, dann wird kein Cluster-Name verwendet und es werden nur Records mit einem sendmailmtahost- Attribut bezogen, das dem Hostnamen des sendmail-hosts entspricht. Das Record, das in dem obigen Beispiel in die LDAP-Datenbank aufgenommen wurde, verwendete das Attribut sendmailmtacluster und setzt dieses Attribut auf wrotethebook.com. Daher ist es notwendig, einen passenden Cluster-Wert in der sendmail-konfiguration zu definieren. Die Definition confldap_cluster, die im Lösungsabschnitt gezeigt wurde, setzt das sendmail.cf-makro ${sendmailmtacluster}, das den Cluster-Namen enthält, auf wrotethebook.com. Würde diese Definition nicht verwendet werden, dann würden Anfragen vom lokalen Host die Beispielwerte der Klasse $=R nicht erfolgreich vom LDAP-Server beziehen können. Links 108 Kapitel 3: Weitervermittlung (Relaying)

127 Rechts Siehe auch Die Rezepte 3.6 und 3.7 liefern Informationen über die Klasse $=R und darüber, wie diese für die Weitervermittlung genutzt wird. Informationen über LDAP gibt es in den Büchern Understanding and Deploying LDAP Directory Services von Howes, Smith und Good (Macmillan) sowie LDAP System Administration von Gerald Carter (O Reilly). Die Datei cf/readme behandelt dieses Thema im Abschnitt Using LDAP for Aliases, Maps, and Classes. Das Buch sendmail behandelt das Makro RELAY_DOMAIN_FILE in Abschnitt und die Definition confldap_cluster in Abschnitt Nur ausgehende Mail vermitteln Problem Sie wurden gebeten, einen Mail Relay Host zu konfigurieren, der nur ausgehende Mail verarbeitet. Der Host soll Mail weitervermitteln, die von bestimmten Hosts gesendet wurde, ohne dabei Mail zu vermitteln, die an diese Hosts adressiert ist. Lösung Fügen Sie der sendmail-konfiguration eine Unterstützung für die access-datenbank hinzu. Dazu verwenden Sie die Funktion access_db. Hier ist das erforderliche FEATURE- Makro: dnl Add support for the access database FEATURE(`access_db') Erstellen Sie eine access-datenbank, die alle Clients definiert, von denen der Server Mail zur Weitervermittlung akzeptieren soll. Die Einträge der access-datenbank müssen in der Form Connect:adresse RELAY vorliegen, wobei adresse die IP-Adresse oder der DNS- Name der Quelle ist, von der die Mail akzeptiert wird. Legen Sie die Datei sendmail.cf neu an, und installieren Sie sie, starten Sie dann sendmail neu. Diese Schritte werden in Rezept 1.8 behandelt. Diskussion Mail von einer Domain oder adressiert an eine Domain, die in der Datei relay-domains definiert ist, wird weitervermittelt. Das heißt, die Datei relay-domains erzeugt ein Relay, das sowohl eingehende als auch ausgehende Mail verarbeitet. Im Allgemeinen wird eine solche Konfiguration eingesetzt. Gelegentlich jedoch beschließen Netzwerkplaner, getrennte Systeme für eingehende und ausgehende Mail zu verwenden. Beispielsweise könnten ein Mail Exchanger für alle eingehenden Mails und ein Mail Relay Host für alle ausgehenden Mails auf zwei physisch getrennten Systemen platziert werden. Die access- Datenbank bietet die exakte Kontrolle, die erforderlich ist, um solche Entwurfsentschei Nur ausgehende Mail vermitteln 109

128 dungen umzusetzen. Die Funktion access_db erweitert die sendmail-konfiguration um Unterstützung für die access-datenbank. Einträge in der access-datei, aus der die access-datenbank erstellt wird, enthalten zwei grundlegende Felder: Den Bedingungstest, mit dem festgestellt wird, ob eine Aktion unternommen wird Die Aktion, die ausgeführt wird, wenn die Bedingung zutrifft Der Bedingungstest kann verschiedene Arten von Daten enthalten je nachdem, wofür der access-datenbankeintrag verwendet wird. Für die Weitervermittlung enthält der Bedingungstest normalerweise eine Adresse, bei der es sich um einen vollständigen oder teilweisen Domainnamen, Hostnamen oder eine IP-Adresse handeln kann. Es kann auch eine vollständige -Adresse oder der Benutzerteil einer -Adresse sein. Hier sehen Sie ein Beispiel für das Anlegen eines access-datenbankeintrags, der Mail weitervermittelt, die über eine Verbindung von einem beliebigen Host in der lokalen Domain wrotethebook.com empfangen wurde: # cd /etc/mail # cat > access Connect:wrotethebook.com Ctrl-D # makemap hash access < access RELAY Das Beispiel nutzt den Domainnamen wrotethebook.com als Datum in dem Bedingungstest, da wir Mail für alle Hosts in dieser Domain weitervermitteln wollen. Eine Alternative wäre es, die Netzwerkadresse zu verwenden, um Mail für alle Hosts im lokalen Netzwerk zu vermitteln; zum Beispiel: Connect: RELAY Das Schlüsselwort Connect:, das vor den Daten in dem Bedingungstest steht, wird als Tag bezeichnet. Ein Tag wird eingesetzt, um den Geltungsbereich des Tests zu begrenzen. Tags sind optional. Normalerweise werden die Daten in dem Bedingungstestfeld eines Eintrags in der access-datenbank anhand dreier unterschiedlicher Werte getestet der Absender- und Empfängeradresse des Nachrichtenumschlags sowie der IP-Adresse des entfernten Systems, das mit dem Server verbunden ist, um Mail zu übertragen. Entspricht eine der drei Adressen den Bedingungsdaten in der access-datenbank, dann ist die Bedingung erfüllt und die Aktion, die in der Datenbank definiert ist, wird ausgeführt. Mit einem Tag können Sie dieses vorgegebene Verhalten ändern und den Bedingungstest auf eine der drei möglichen Adressen beschränken. Die grundlegenden Tag-Werte sind: To: Nur die Empfängeradresse des Nachrichtenumschlags wird mit den Daten des Bedingungstests verglichen. From: Nur die Absenderadresse des Nachrichtenumschlags wird mit den Daten des Bedingungstests verglichen. Links 110 Kapitel 3: Weitervermittlung (Relaying)

129 Rechts Connect: Nur die IP-Adresse des entfernten Systems, das die Verbindung initiiert hat, über die die Mail empfangen wurde, wird mit den Daten des Bedingungstests verglichen. Das oben gezeigte Beispiel verwendet das Connect:-Tag, um die Weitervermittlung auf solche Hosts zu beschränken, die sich aus der Domain wrotethebook.com heraus mit dem Relay-Server verbinden. Mail von anderen Quellen wird nicht vermittelt. Das Aktionsfeld des Beispieleintrags der access-datei enthält das Schlüsselwort RELAY, was einfach bedeutet, dass der Server Mail weitervermitteln soll, die dem angegebenen Bedingungstest genügt. RELAY ist das einzige Schlüsselwort, das direkt mit der Weitervermittlung zu tun hat. Mehrere weitere Aktionsschlüsselwörter werden in Kapitel 7 behandelt. Die access-datei muss in eine Hash-Datenbank konvertiert werden, bevor sendmail sie nutzen kann. Das Programm makemap führt die erforderliche Konvertierung durch. Es liest ASCII-Text von stdin und schreibt eine Datenbank eines bestimmten Typs in die angegebene Datei. Beachten Sie in unserem Beispiel, dass die Eingabe- und Ausgabenamen gleich zu sein scheinen. Sie sind es nicht. Die Eingabedatei heißt access, und die Ausgabedatei wird als access.db bezeichnet. Sie müssen jedoch die Erweiterung.db nicht an den Namen der Ausgabedatei anhängen. makemap fügt auf der Grundlage der angegebenen Datenbank automatisch die richtige Erweiterung hinzu. makemap ist Bestandteil der sendmail-distribution. Nach dem Erstellen der access-datenbank, dem Erstellen der Datei sendmail.cf und dem Neustart von sendmail vermittelt das System Mail von Clients in der lokalen Domain weiter. Es vermittelt jedoch keine Mail an diese Clients, falls diese Mail aus einer anderen Domain stammt. 6 Zwei Tests belegen das. Im ersten Test wird Mail von einem Host in der lokalen Domain an einen entfernten Host gesandt: $ telnet smtp.wrotethebook.com smtp Trying Connected to smtp. Escape character is '^]'. 220 smtp.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 15 Aug :47: HELO rodent.wrotethebook.com 250 smtp.wrotethebook.com Hello rodent.wrotethebook.com [ ], pleased to meet you MAIL From:<craig@rodent.wrotethebook.com> craig@rodent.wrotethebook.com... Sender ok RCPT To:<tyler@example.com> tyler@example.com... Recipient ok QUIT smtp.wrotethebook.com closing connection Connection closed by foreign host. 6 sendmail muss nicht neu gestartet werden, wenn sich eine Datenbank ändert. Der einzige Grund, weshalb in diesem Rezept ein Neustart notwendig war, bestand darin, dass sich die Datei sendmail.cf geändert hatte Nur ausgehende Mail vermitteln 111

130 Im zweiten Test wird Mail von einem entfernten Host an einen Host in der lokalen Domain geschickt. Hätte die lokale Domain in der Datei relay-domain gestanden, wäre diese Mail akzeptiert worden. Dieser Test zeigt, dass die Mail mit der access-datenbank aus diesem Rezept abgewiesen wird: $ telnet smtp.wrotethebopok.com smtp Trying Connected to smtp. Escape character is '^]'. 220 smtp.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 15 Aug :52: HELO example.com 250 smtp.wrotethebook.com Hello example.com { ], pleased to meet you MAIL From:<tyler@example.com> tyler@example.com... Sender ok RCPT To:<craig@rodent.wrotethebook.com> craig@rodent.wrotethebook.com... Relaying denied QUIT smtp.wrotethebook.com closing connection Connection closed by foreign host. Links Siehe auch Kapitel 6 liefert Ihnen weitere Informationen über die access-datenbank. Der Abschnitt Finer control by using tags for the LHS of the access map der Datei cf/readme bietet zusätzliche Informationen über Tags. Das Buch sendmail behandelt die access-datenbank in Abschnitt Kapitel 3: Weitervermittlung (Relaying)

131 First Kapitel 4 KAPITEL 4 Masquerading 4.0 Einführung Masquerading (Maskierung) ist der sendmail-ausdruck für das Umschreiben des Hostnamens in der Adresse einer ausgehenden Mail. Die Gründe für das Masquerading lassen sich in zwei allgemeine Kategorien einteilen: Mail-Routing Viele Netzwerke sind so aufgebaut, dass sie alle eingehenden Mails durch einen zentralen Mail-Hub leiten. Wenn ein Host Mail mit seinem eigenen Hostnamen in der Absenderadresse verschickt, dann werden Antworten auf diese Mail auch wieder an den Host zurückgelangen. Wird der Hostname des sendenden Systems durch den Hostnamen des Hubs ersetzt, dann gelangen Antworten garantiert an den Hub zurück. Das Masquerading ist nicht die einzige Möglichkeit, dies zu erreichen. Ein MX-Record kann ebenfalls Mail an den Hub leiten. Allerdings unterliegt die Wartung der DNS-Zonendatei der Kontrolle des Domain-Administrators. Der sendmail- Administrator kümmert sich um das Masquerading, und die meisten sendmail- Administratoren ziehen es vor, ihre Angelegenheiten selbst zu erledigen. Außerdem ändern sich Hostnamen manchmal. Durch das Masquerading können konsistentere -Adressen zur Verfügung gestellt und die Wartung vereinfacht werden. Organisatorische Anforderungen Manche Einrichtungen verfolgen ganz einfach die Politik, Hostnamen zu verbergen. Das Management könnte denken, dass»belegte«hostnamen ein Bild der Desorganisation vermitteln. Das Marketing könnte denken, dass»unseriöse«hostnamen Kunden ein falsches Bild vermitteln. Naive Sicherheitsverantwortliche könnten sogar glauben, dass das Verbergen der Hostnamen die Sicherheit verbesserte. Aus welchen Gründen auch immer, das Management verlangt ein Masquerading, wodurch wiederum ein Bedarf an Systemen entsteht, die dafür konfiguriert sind, Antworten auf die maskierten Mails zu empfangen. Das Makro MASQUERADE_AS aktiviert das Masquerading. Dieses Makro speichert einen Wert im sendmail.cf-makro $M und fügt Code zum Regelsatz MasqHdr hinzu, um die Header- 113

132 Absenderadresse mit Hilfe des Werts, der von $M zurückgegeben wird, umzuschreiben. 1 Masquerading wird standardmäßig auf alle Mails angewendet, die vom lokalen Host stammen. Alle gültigen Hostnamen für den lokalen Host werden in der Klasse $=w gespeichert. Wenn MASQUERADE_AS verwendet wird, ersetzt sendmail den Hostnamen des Absenders durch den Wert von $M falls der ursprünglichen Adresse ein Hostname fehlt oder der Hostname einem Wert in der Klasse $=w entspricht. sendmail prüft beim Masquerading sowohl die Klasse $=w als auch die Klasse $=M. 2 Die Klasse $=M ist jedoch zu Anfang leer. Benutzen Sie das Makro MASQUERADE_DOMAIN, um einzelne Hostnamen zur Klasse $=M hinzuzufügen. Um mehrere Hosts hinzuzufügen, erzeugen Sie eine Datei, die eine Liste von Hosts enthält, und nutzen das Makro MASQUERADE_DOMAIN_FILE, um die Datei in die Klasse $=M zu laden. Normalerweise werden beim Masquerading die Werte in der Klasse $=M als Hostnamen interpretiert und nur genaue Treffer maskiert. Mit der Funktion masquerade_entire _domain interpretieren Sie die Werte in der Klasse $=M als Domainnamen. Wenn masquerade_entire_domain benutzt wird, dann werden alle Hosts einer Domain, die in der Klasse $=M aufgeführt ist, maskiert. masquerade_entire_domain kommt in Rezept 4.8 zum Einsatz. Masquerading wird standardmäßig auf die Header-Absenderadresse angewandt. Die Funktion masquerade_envelope veranlasst sendmail, Masquerading auch auf die Umschlagabsenderadresse anzuwenden. Rezept 4.10 zeigt an einem Beispiel, wie die Funktion masquerade_envelope benutzt wird. Die Funktion allmasquerade wendet Masquerading sowohl auf die Absender- als auch auf die Empfängeradresse an. Rezept 4.5 beschreibt die Funktion allmasquerade. Masquerading ist weit verbreitet und kann umfassend konfiguriert werden, bildet jedoch nicht die einzige oder gar die leistungsfähigste Methode, um die Absenderadresse im From:-Header umzuschreiben. Masquerading schreibt den Hostnamen in der Absenderadresse um; die genericstable schreibt die gesamte Adresse um sowohl den Benutzernamen als auch den Hostnamen. Die genericstable ist insofern mit dem Masquerading verwandt, als beide die Absenderadresse modifizieren, es gibt jedoch deutliche Unterschiede: Masquerading schreibt den Hostnamen auf der Grundlage des Eingabe-Hostnamens um. Die genericstable wird auf der Grundlage des Eingabe-Hostnamens auf Adressen angewandt, kann aber die gesamte Adresse auf der Grundlage der ganzen oder Teile der Eingabeadresse umschreiben. Links 1 Sogar Konfigurationen, die MASQUERADE_AS nicht benutzen, haben einen MasqHdr-Regelsatz, der den voll qualifizierten Hostnamen des lokalen Hosts, der von $j zurückgegeben wird, der Absenderadresse hinzufügt, wenn der Adresse ein Hostname fehlt. 2 Um sendmail zu zwingen, die Klasse $=w zu ignorieren und nur die Klasse $=M für das Masquerading zu verwenden, nutzen Sie die Funktion limited_masquerade. 114 Kapitel 4: Masquerading

133 Rechts Masquerading ersetzt jeden maskierten Hostnamen durch den gleichen Wert, während die genericstable jede Eingabeadresse durch einen anderen Wert ersetzen kann. Die Funktion genericstable definiert die generics-datenbank in der Datei sendmail.cf und fügt dem Regelsatz MasqHdr Code hinzu, um diese Datenbank zum Umschreiben der Absenderadresse im From:-Header zu nutzen. Der Schlüssel zur genericstable-datenbank ist ein Benutzername oder eine vollständige -Adresse, und der Wert, der für den Schlüssel zurückgegeben wird, ist eine vollständige -Adresse. Um die genericstable zu nutzen, legen Sie zuerst eine Textdatei an, in der jede Zeile ein Schlüssel/Wert-Paar des folgenden Formats enthält: Benutzername, Whitespace, -Adresse. Ein Beispieleintrag in der Textdatei sieht so aus: pat In diesem Beispiel ist pat der Schlüssel, mit dem der Eingabebenutzername verglichen wird. ist die -Adresse, die für diesen Schlüssel zurückgeliefert wird. Bevor die genericstable eingesetzt werden kann, muss die Textdatei, die die Schlüssel/Wert-Paare enthält, in eine Datenbank mit Hash-Werten umgewandelt werden. Dies erledigt der sendmail-befehl makemap. 3 Sowohl der Benutzername als auch der Hostname aus der Eingabeabsenderadresse werden durch den genericstable-prozess verwendet. Der Schlüssel zur Datenbank genericstable enthält immer einen Benutzernamen, entweder für sich allein stehend oder als Teil einer vollständigen -Adresse. sendmail sucht jedoch nur dann nach diesem Schlüssel, wenn der Hostname in der Eingabeabsenderadresse einem Wert in der Klasse $=G entspricht oder wenn die Eingabeabsenderadresse keinen Hostnamen enthält. Standardmäßig ist die Klasse $=G leer. Nutzen Sie das Makro GENERICS_DOMAIN, um einzelne Hostnamen zur Klasse $=G hinzuzufügen, oder das Makro GENERICS_DOMAIN_FILE, um die Klasse $=G aus einer Datei zu laden. Normalerweise werden die Werte in der Klasse $=G als Hostnamen interpretiert. Mit der Funktion generics_entire_domain veranlassen Sie sendmail, die Werte in der Klasse $=G als Domainnamen zu interpretieren. Wenn die Funktion generics_entire_domain verwendet wird, wird die genericstable auf Mail angewendet, die von allen Hosts in allen Domains gesendet wird, die in der Klasse $=G aufgeführt sind. Sowohl Masquerading als auch die genericstable werden in den Rezepten in diesem Kapitel verwendet. Zuerst beginnen wir jedoch mit einem Rezept, das die Funktion always_add_domain einsetzt. always_add_domain hat nichts mit der genericstable zu tun und ist genau genommen kein Masquerading-Befehl. Sie schreibt allerdings die Absenderadresse um, und das ist in diesem Kapitel der rote Faden. 3 Rezept 4.11 bietet ein Beispiel für das Erstellen einer genericstable-datenbank. Einführung 115

134 4.1 Allen Absenderadressen Domains hinzufügen Links Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es jeder Header-Absenderadresse einen Hostnamen hinzufügt, selbst wenn die Eingabeadresse keinen Hostnamenanteil aufweist und die Mail durch den Mailer local ausgeliefert wird. Lösung Fügen Sie der sendmail-konfiguration die Funktion always_add_domain hinzu. Der Befehl, den Sie angeben, lautet: dnl Add the domain to all sender addresses FEATURE(`always_add_domain') Erzeugen und installieren Sie entsprechend den Anweisungen aus Rezept 1.8 die sendmail-konfiguration, und starten Sie dann sendmail neu. Diskussion Die Funktion always_add_domain veranlasst sendmail sicherzustellen, dass jede Absenderadresse einen Hostnamenanteil enthält. Normalerweise fügt sendmail einer Absenderadresse keinen Hostnamenanteil hinzu, wenn die Adresse keinen Hostnamenanteil enthält und der Mailer local die Mail ausliefert. Das bedeutet, Mail von der Adresse alana durchläuft den Header-Absender-Vorgang des Mailers local unverändert, wenn die Standardkonfiguration verwendet wird, wie dieser Test zeigt: # sendmail bt Cgeneric-linux.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /tryflags HS > /try local alana Trying header sender address alana for mailer local canonify input: alana Canonify2 input: alana Canonify2 returns: alana canonify returns: alana 1 input: alana 1 returns: alana HdrFromL input: alana MasqHdr input: alana MasqHdr returns: alana HdrFromL returns: alana final input: alana final returns: alana Rcode = 0, addr = alana > /quit 116 Kapitel 4: Masquerading

135 Rechts Wenn Sie die Funktion always_add_domain zur Konfiguration hinzufügen und dann den Test erneut durchführen, erhalten Sie ein anderes Ergebnis: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /tryflags HS > /try local alana Trying header sender address alana for mailer local canonify input: alana Canonify2 input: alana Canonify2 returns: alana canonify returns: alana 1 input: alana 1 returns: alana HdrFromL input: alana AddDomain input: alana AddDomain returns: alana *LOCAL* > MasqHdr input: alana *LOCAL* > MasqHdr returns: alana chef. wrotethebook. com. > HdrFromL returns: alana chef. wrotethebook. com. > final input: alana chef. wrotethebook. com. > final returns: chef. wrotethebook. com Rcode = 0, addr = alana@chef.wrotethebook.com > /quit Hier geht die Adresse als alana hinein und kommt mit einem zusätzlichen Hostnamen als alana@chef.wrotethebook.com wieder heraus. Siehe auch Rezept 4.4 demonstriert, wie die Funktion always_add_domain beim Masquerading verwendet werden kann. Das Buch sendmail behandelt always_add_domain in Abschnitt Den Hostnamen des Absenders maskieren Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es den lokalen Hostnamen in der Header-Absenderadresse durch einen anderen Hostnamen ersetzt. Lösung Fügen Sie der sendmail-konfiguration das Makro MASQUERADE_AS hinzu, um den Hostnamen in der From:-Adresse auf den Hostnamen umzuschreiben, der durch das Makro MASQUERADE_AS festgelegt wird. Nehmen Sie das Makro EXPOSED_USER in die sendmail-konfiguration auf, um uneindeutige Benutzernamen vom Umschreiben der Adresse auszuschließen. Hier sind Beispiele für diese beiden Makros: 4.2 Den Hostnamen des Absenders maskieren 117

136 dnl Masquerade the From address as wrotethebook.com MASQUERADE_AS(`wrotethebook.com') dnl Users whose mail is not masqueraded EXPOSED_USER(root) Erstellen Sie die neue sendmail.cf-datei, kopieren Sie sie nach /etc/mail, und starten Sie sendmail neu, wie in Rezept 1.8 beschrieben. Diskussion Nutzen Sie das Makro MASQUERADE_AS, um sendmail so zu konfigurieren, dass es den Host-Anteil der Absenderadresse einer ausgehenden Mail umschreibt. Der Wert, der auf der MASQUERADE_AS-Kommandozeile angegeben wird, wird im sendmail.cf-makro $M gespeichert. sendmail nutzt den Wert aus dem Makro $M, um den Hostnamenanteil der Header-Absenderadresse umzuschreiben, wenn der Hostname einem Wert entspricht, der in den sendmail.cf-klassen $=w oder $=M zu finden ist. sendmail benutzt außerdem den Wert aus $M (anstelle des Wertes aus dem sendmail.cf-makro $j) als Hostnamenanteil der Header-Absenderadresse, wenn der Adresse der Hostnamenanteil fehlt. $j enthält den voll qualifizierten Namen des lokalen Hosts. Normalerweise wird $j dem Benutzernamen hinzugefügt, um eine vollständige -Adresse zu erzeugen. Ein Test mit der generischen Linux-Konfiguration, die das Makro MASQUERADE_AS nicht enthält, zeigt das: # sendmail -bt Cgeneric-linux.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $M Undefined > $j chef.wrotethebook.com > /tryflags HS > /try esmtp alana Trying header sender address alana for mailer esmtp canonify input: alana Canonify2 input: alana Canonify2 returns: alana canonify returns: alana 1 input: alana 1 returns: alana HdrFromSMTP input: alana PseudoToReal input: alana PseudoToReal returns: alana MasqSMTP input: alana MasqSMTP returns: alana *LOCAL* > MasqHdr input: alana *LOCAL* > MasqHdr returns: alana chef. wrotethebook. com. > HdrFromSMTP returns: alana chef. wrotethebook. com. > final input: alana chef. wrotethebook. com. > final returns: chef. wrotethebook. com Rcode = 0, addr = alana@chef.wrotethebook.com > /quit Links 118 Kapitel 4: Masquerading

137 Rechts Die Option -C auf der sendmail-kommandozeile lädt die generic-linux.cf-konfiguration, in der das Makro MASQUERADE_AS nicht enthalten ist. Der Befehl $M zeigt, dass das Makro $M nicht definiert wurde. Der Befehl $j gibt den voll qualifizierten Namen dieses Hosts aus. Im Beispiel lautet dieser Name chef.wrotethebook.com. Der Befehl /tryflags weist sendmail an, die Header-Absenderadresse (Header Sender Address; HS) zu verarbeiten. Der Befehl /try weist sendmail an, alana als Header-Absenderadresse für den Mailer esmtp zu verarbeiten. Beachten Sie, dass es sich bei alana um eine -Adresse ohne Host-Anteil handelt. sendmail fügt zu dem unqualifizierten Benutzernamen einen Hostnamen hinzu und verwendet dazu standardmäßig den Hostnamen, der in $j gefunden wird. Der Wert, der durch den Regelsatz MasqHdr zurückgeliefert wird, zeigt dies. Ein zweiter Test, dieses Mal mit der generischen Konfiguration, die durch die Beispielzeilen aus dem Lösungsabschnitt erweitert wurde, liefert ein anderes Ergebnis. Nun wird zusätzlich zu dem Wert, der für $j geliefert wird, ein Wert durch den Befehl $M zurückgegeben. Wenn alana als Header-Absenderadresse für den Mailer esmtp verarbeitet wird, schreibt der Regelsatz MasqHdr die Adresse mit dem Wert aus $M um und nicht mit dem Wert aus $j: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $M wrotethebook.com > $j chef.wrotethebook.com > /tryflags HS > /try esmtp alana Trying header sender address alana for mailer esmtp canonify input: alana Canonify2 input: alana Canonify2 returns: alana canonify returns: alana 1 input: alana 1 returns: alana HdrFromSMTP input: alana PseudoToReal input: alana PseudoToReal returns: alana MasqSMTP input: alana MasqSMTP returns: alana *LOCAL* > MasqHdr input: alana *LOCAL* > MasqHdr returns: alana wrotethebook. com. > HdrFromSMTP returns: alana wrotethebook. com. > final input: alana wrotethebook. com. > final returns: wrotethebook. com Rcode = 0, addr = alana@wrotethebook.com > /quit Die nullclient-konfiguration, die in Rezept 3.1 behandelt wird, maskiert Mail ebenfalls, so dass sie von einem Mail-Hub zu kommen scheint statt vom lokalen Host. Diese Konfiguration unterscheidet sich jedoch deutlich von der nullclient-konfiguration. Der 4.2 Den Hostnamen des Absenders maskieren 119

138 nullclient hat nicht seine eigene Mail ausgeliefert. Seine ganze Mail wurde über den Hub weitervermittelt. In diesem Sinne stammte die Mail des nullclients tatsächlich vom Mail- Hub. In diesem Rezept wird eine Konfiguration erzeugt, die ihre eigene Mail ausliefert und den Hostnamen in der Header-Absenderadresse ändert, auch wenn die Mail vom lokalen Host stammt. In diesem Beispiel maskiert der Host mit Hilfe des Domainnamens. Da alle Hosts in dieser Beispiel-Domain mit dem gleichen Wert maskieren, besteht die Möglichkeit, dass Konflikte auf Grund von uneindeutigen Benutzernamen auftreten. Das klassische Beispiel eines uneindeutigen Benutzernamens ist root jedes Unix-System verfügt über einen root-zugang. Würden Mails von und von als Mail von ausgesandt werden, wäre es schwierig festzustellen, woher die Mail wirklich kommt und wer Antworten auf diese Mail erhalten soll. Aus diesem Grund wird das Makro EXPOSED_USER verwendet, um sicherzustellen, dass Mail vom root-benutzer nicht maskiert wird. Ein Test zeigt dies: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /tryflags HS > /try esmtp root Trying header sender address root for mailer esmtp canonify input: root Canonify2 input: root Canonify2 returns: root canonify returns: root 1 input: root 1 returns: root HdrFromSMTP input: root PseudoToReal input: root PseudoToReal returns: root MasqSMTP input: root MasqSMTP returns: root *LOCAL* > MasqHdr input: root *LOCAL* > MasqHdr returns: root chef. wrotethebook. com. > HdrFromSMTP returns: root chef. wrotethebook. com. > final input: root chef. wrotethebook. com. > final returns: chef. wrotethebook. com Rcode = 0, addr = root@chef.wrotethebook.com > /quit Bei dem Beispiel in diesem Rezept wird in einem EXPOSED_USER-Makro nur ein Benutzername angegeben. Um mehrere Benutzernamen festzulegen, fügen Sie zusätzliche EXPOSED_USER-Makros hinzu jeweils eines für einen Benutzernamen. Bei einer größeren Anzahl von Benutzernamen, die Sie auf diese Weise bestimmen wollen, nutzen Sie das Makro EXPOSED_USER_FILE: EXPOSED_USER_FILE(`/etc/mail/exposed.users') Links 120 Kapitel 4: Masquerading

139 Rechts Die Datei in unserem Beispiel, /etc/mail/exposed.users, enthält eine Liste mit Benutzernamen, die jeweils auf einer eigenen Zeile stehen. Die Datei könnte folgendermaßen aussehen: $ cat /etc/mail/exposed.users root postmaster bin daemon adm mail news operator smmsp nobody Dies ist nur ein Beispiel. In diese Datei würden nur uneindeutige Benutzernamen platziert werden, von denen wirklich Mail gesandt wird. Siehe auch Die nullclient-konfiguration in Rezept 2.1 ist eine vergleichbare Konfiguration. Die Rezepte 4.3 bis 4.11 zeigen das Masquerading mit zusätzlichen Funktionen und Eigenschaften. Das Buch sendmail behandelt MASQUERADE_AS in Abschnitt 4.4.2; EXPOSED_USER und EXPOSED_USER_FILE werden in Abschnitt erläutert. Der Abschnitt»Address Masquerading«des Buches Linux Sendmail Administration von Craig Hunt (Sybex) ist eine Anleitung zum Masquerading. Die Datei cf/readme behandelt das Masquerading im Abschnitt Masquerading and Relaying. 4.3 Masquerading für den lokalen Mailer ausschalten Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es die Header-Absenderadressen aller Mails maskiert, die an externe Hosts gesandt werden. Bei Mails, die durch den lokalen Mailer ausgeliefert werden, soll der maskierende Hostname nicht hinzugefügt werden. Lösung Fügen Sie der sendmail-konfiguration die Funktion local_no_masquerade, das Makro MASQUERADE_AS und das Makro EXPOSED_USER hinzu. Hier sind Beispiele für diese Konfigurationsbefehle: dnl Masquerade the From address as wrotethebook.com MASQUERADE_AS(`wrotethebook.com') dnl Users whose mail is not masqueraded 4.3 Masquerading für den lokalen Mailer ausschalten 121

140 EXPOSED_USER(root) dnl Don't masquerade addresses for the local mailer FEATURE(`local_no_masquerade') Erstellen und installieren Sie die neue sendmail.cf-datei, und starten Sie anschließend sendmail neu. Diese Schritte werden in Rezept 1.8 erläutert. Diskussion Der Hostname, der auf der MASQUERADE_AS-Kommandozeile definiert wird, wird im sendmail.cf-makro $M gespeichert. sendmail schreibt den Hostnamen in der From:- Adresse auf den Wert um, den es im $M-gefunden hat, falls der Original-Hostname in den Klassen $=w oder $=M aufgeführt ist. Standardmäßig enthält die Klasse $=w alle Namen und Adressen des lokalen Hosts. Das heißt, Mail, die vom lokalen Host verschickt wird, wird mit Hilfe des Wertes aus $M maskiert. Genau das wollen Sie erreichen, wenn Mail an einen externen Host gesandt wird. Allerdings wollen Sie diesen Effekt vermutlich nicht erzielen, wenn der Mailer local die Mail lokal ausliefert. Einige Tests zeigen, wie lokale Mail vom Makro MASQUERADE_AS behandelt wird. Zuerst führen wir zwei Tests mit der Konfiguration aus, die in Rezept 4.2 definiert wurde (d. h. Masquerading ohne die Funktion local_no_masquerade): # sendmail bt Crecipe4.2.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /tryflags HS > /try local alana Trying header sender address alana for mailer local canonify input: alana Canonify2 input: alana Canonify2 returns: alana canonify returns: alana 1 input: alana 1 returns: alana HdrFromL input: alana MasqHdr input: alana MasqHdr returns: alana HdrFromL returns: alana final input: alana final returns: alana Rcode = 0, addr = alana > /try local alana@chef.wrotethebook.com Trying header sender address alana@chef.wrotethebook.com for mailer local canonify input: chef. wrotethebook. com Canonify2 input: alana chef. wrotethebook. com > Canonify2 returns: alana chef. wrotethebook. com. > canonify returns: alana chef. wrotethebook. com. > 1 input: alana chef. wrotethebook. com. > 1 returns: alana chef. wrotethebook. com. > HdrFromL input: alana chef. wrotethebook. com. > MasqHdr input: alana chef. wrotethebook. com. > Links 122 Kapitel 4: Masquerading

141 Rechts MasqHdr returns: alana wrotethebook. com. > HdrFromL returns: alana wrotethebook. com. > final input: alana wrotethebook. com. > final returns: wrotethebook. com Rcode = 0, addr = alana@wrotethebook.com > /quit Zwei gültige lokale Adressen werden als Header-Absenderadressen für den Mailer local verarbeitet. Die erste Adresse ist die lokale Adresse des Benutzernamens alana ohne Host-Anteil. In diesem Fall wird die Adresse als alana eingegeben, verarbeitet und kommt dann als alana wieder heraus. Das ist in Ordnung. Lokale Adressen benötigen für die Auslieferung keinen Hostnamenanteil. Jeder lokale Benutzer, der Mail von alana empfängt, kann auf diese Adresse antworten; die Mail wird erfolgreich durch den lokalen Mailer ausgeliefert. Die zweite Adresse, alana@chef.wrotethebook.com, ist ebenfalls eine lokale Adresse für alana, da es sich bei chef.wrotethebook.com um den Namen des lokalen Hosts handelt. Dieses Mal wird die Adresse jedoch durch die Header-Absender-Verarbeitung in alana@wrotethebook.com geändert. Wenn ein lokaler Benutzer auf alana@wrotethebook.com antwortet, liefert der lokale Mailer die Mail nicht lokal aus; stattdessen wird sie durch den esmtp-mailer an den Mail Exchanger für wrotethebook.com gesandt. Für die endgültige Auslieferung ist dann der Mail Exchanger verantwortlich. Nach dem Hinzufügen der Konfigurationszeilen, die im Lösungsabschnitt gezeigt wurden, sowie dem Erstellen und Installieren der Datei sendmail.cf fallen die Testergebnisse anders aus: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > =SHdrFromL > MAILER-DAEMON R@ $* > MAILER-DAEMON R$+ $: $> AddDomain $1 > /tryflags HS > /try local alana Trying header sender address alana for mailer local canonify input: alana Canonify2 input: alana Canonify2 returns: alana canonify returns: alana 1 input: alana 1 returns: alana HdrFromL input: alana HdrFromL returns: alana final input: alana final returns: alana Rcode = 0, addr = alana > /try local alana@chef.wrotethebook.com Trying header sender address alana@chef.wrotethebook.com for mailer local canonify input: chef. wrotethebook. com Canonify2 input: alana chef. wrotethebook. com > Canonify2 returns: alana chef. wrotethebook. com. > 4.3 Masquerading für den lokalen Mailer ausschalten 123

142 canonify returns: alana chef. wrotethebook. com. > 1 input: alana chef. wrotethebook. com. > 1 returns: alana chef. wrotethebook. com. > HdrFromL input: alana chef. wrotethebook. com. > HdrFromL returns: alana chef. wrotethebook. com. > final input: alana chef. wrotethebook. com. > final returns: chef. wrotethebook. com Rcode = 0, addr = alana@chef.wrotethebook.com > /quit Die Verarbeitung von alana als Header-Absenderadresse ergibt das gleiche Ergebnis wie zuvor. Die Adresse geht als alana in den Verarbeitungsprozess hinein und kommt als alana heraus. Dieses Mal verläuft der Vorgang jedoch anders der Regelsatz MasqHdr wird nicht vom Regelsatz HdrFromL aufgerufen. Der Unterschied ist bei der Verarbeitung der Adresse alana@chef.wrotethebook.com deutlicher zu sehen, die den Vorgang ebenfalls unverändert durchläuft. Eine Antwort auf die Header-Absenderadresse für alana oder alana@chef.wrotethebook.com wird als lokale Mail behandelt und durch den Mailer local ausgeliefert. Durch die Benutzung von local_no_masquerade wird der Overhead verringert, der entsteht, wenn lokale Mail lokal gehalten werden soll. Allerdings ist der Aufwand nicht zu groß, wenn einige lokale Mails an einen externen Host durchgereicht werden. Die Funktion local_no_masquerade stellt außerdem sicher, dass alle Mails von lokalen Benutzern, die an lokale Benutzer adressiert sind, auf die gleiche Weise behandelt werden. Konsistenz ist ein Vorteil dieser Funktion. Rezept 4.4 zeigt den entgegengesetzten Ansatz zum Erreichen von Konsistenz, der darin besteht, ein Masquerading aller Absenderadressen zu erzwingen. Links Siehe auch Die Rezepte 4.2 und 4.4 beschreiben ähnliche Probleme. Das Buch sendmail behandelt MASQUERADE_AS in Abschnitt 4.4.2, EXPOSED_USER in Abschnitt und local_no_masquerade in Abschnitt Der Abschnitt»Address Masquerading«des Buches Linux Sendmail Administration von Craig Hunt (Sybex) enthält eine Anleitung für das Masquerading. Die Datei cf/readme behandelt das Masquerading im Abschnitt Masquerading and Relaying. 4.4 Masquerading lokaler Mail erzwingen Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es alle Header-Absenderadressen maskiert, selbst solche, die durch den Mailer local verarbeitet werden und denen der Hostnamenanteil fehlt. 124 Kapitel 4: Masquerading

143 Rechts Lösung Legen Sie eine sendmail-konfiguration an, die die Funktion always_add_domain aus Rezept 4.1 mit den Makros MASQUERADE_AS und EXPOSED_USER aus Rezept 4.2 kombiniert. Beispiele für diese Befehle sind: dnl Masquerade the From address as wrotethebook.com MASQUERADE_AS(`wrotethebook.com') dnl Users whose mail is not masqueraded EXPOSED_USER(root) dnl Add the domain name to all addresses FEATURE(`always_add_domain') Erstellen und installieren Sie die neue sendmail.cf-datei, und starten Sie sendmail neu, wie in Rezept 1.8 beschrieben. Diskussion Die Funktion always_add_domain ist nicht Masquerading-spezifisch. Wenn always_add _domain ohne das Makro MASQUERADE_AS zum Einsatz kommt, nutzt sendmail den voll qualifizierten Namen des lokalen Hosts, der im Makro $j zu finden ist, um den Hostnamenanteil der Absenderadresse zu erzeugen. 4 Bei diesem Rezept wollen wir jedoch den Hostnamenanteil der Adresse maskieren; das Makro MASQUERADE_AS wird hier also zusammen mit der Funktion always_add_domain verwendet. Ist dieses Rezept komplett, liefert ein sendmail -bt-test das folgende Ergebnis: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /tryflags HS > /try local alana Trying header sender address alana for mailer local canonify input: alana Canonify2 input: alana Canonify2 returns: alana canonify returns: alana 1 input: alana 1 returns: alana HdrFromL input: alana AddDomain input: alana AddDomain returns: alana *LOCAL* > MasqHdr input: alana *LOCAL* > MasqHdr returns: alana wrotethebook. com. > HdrFromL returns: alana wrotethebook. com. > final input: alana wrotethebook. com. > final returns: wrotethebook. com Rcode = 0, addr = alana@wrotethebook.com > /try local alana@chef 4 Rezept 4.1 zeigt, welche Wirkung die Funktion always_add_domain hat, wenn sie ohne Masquerading eingesetzt wird. 4.4 Masquerading lokaler Mail erzwingen 125

144 Trying header sender address for mailer local canonify input: chef Canonify2 input: alana chef > Canonify2 returns: alana chef. wrotethebook. com. > canonify returns: alana chef. wrotethebook. com. > 1 input: alana chef. wrotethebook. com. > 1 returns: alana chef. wrotethebook. com. > HdrFromL input: alana chef. wrotethebook. com. > AddDomain input: alana chef. wrotethebook. com. > AddDomain returns: alana chef. wrotethebook. com. > MasqHdr input: alana chef. wrotethebook. com. > MasqHdr returns: alana wrotethebook. com. > HdrFromL returns: alana wrotethebook. com. > final input: alana wrotethebook. com. > final returns: wrotethebook. com Rcode = 0, addr = alana@wrotethebook.com > /try local alana@chef.wrotethebook.com Trying header sender address alana@chef.wrotethebook.com for mailer local canonify input: chef. wrotethebook. com Canonify2 input: alana chef. wrotethebook. com > Canonify2 returns: alana chef. wrotethebook. com. > canonify returns: alana chef. wrotethebook. com. > 1 input: alana chef. wrotethebook. com. > 1 returns: alana chef. wrotethebook. com. > HdrFromL input: alana chef. wrotethebook. com. > AddDomain input: alana chef. wrotethebook. com. > AddDomain returns: alana chef. wrotethebook. com. > MasqHdr input: alana chef. wrotethebook. com. > MasqHdr returns: alana wrotethebook. com. > HdrFromL returns: alana wrotethebook. com. > final input: alana wrotethebook. com. > final returns: wrotethebook. com Rcode = 0, addr = alana@wrotethebook.com > /quit Dieser Test zeigt, dass die lokalen Benutzeradressen aller möglichen Formate (benutzer, benutzer@host und benutzer@host.domain) in genau das gleiche Format umgeschrieben werden. Der maskierende Hostname, der im Makro $M gespeichert ist, wird Adressen hinzugefügt, die keinen Host-Anteil aufweisen, und kommt zum Einsatz, um den Hostnamen in Adressen zu ersetzen, die keinen Host-Anteil besitzen. Das heißt, die Adressen alana, alana@chef und alana@chef.wrotethebook.com werden durch die Verarbeitung der Header-Absenderadresse des Mailers local zu alana@wrotethebook.com umgeschrieben. Diese Konsistenz stellt sicher, dass eine Antwort auf Mail von Alana ungeachtet der Formatierung der ursprünglichen Absenderadresse immer auf die gleiche Weise behandelt wird. In diesem Fall gehen alle Antworten auf Mail von Alana zuerst an den Mail Exchanger. Das Ziel dieses Rezeptes ist es, sendmail zu zwingen, alle Absenderadressen zu maskieren. Auf den ersten Blick mag die Funktion allmasquerade als richtige Wahl für dieses Rezept erscheinen. Die Funktion allmasquerade beeinflusst jedoch Empfängeradressen. Links 126 Kapitel 4: Masquerading

145 Rechts Wir wollen hingegen in diesem Rezept nur Absenderadressen umschreiben. Rezept 4.5 behandelt das Masquerading der Empfängeradresse mittels der Funktion allmasquerade. Siehe auch Die Rezepte 4.1, 4.2, 4.3 und 4.5 bieten Informationen über verwandte Konfigurationen. Rezept 3.1 behandelt die nullclient-konfiguration. Rezept 3.3 geht auf das Makro MAIL_HUB ein. Das Buch sendmail behandelt die Funktion always_add_domain in Abschnitt und die Funktion allmasquerade in Abschnitt Empfängeradressen maskieren Problem Masquerading beeinflusst standardmäßig nur Absenderadressen. Sie wurden nun gebeten, sendmail so zu konfigurieren, dass es zusätzlich zur Maskierung der Absenderadressen auch die Empfängeradressen maskiert, wenn diese Adressen maskierte Hostnamen enthalten. Lösung Fügen Sie der sendmail-konfiguration die Makros MASQUERADE_AS und EXPOSED_USER sowie die Funktion allmasquerade hinzu. Hier ist ein Beispiel für die Zeilen, die angelegt werden könnten: dnl Masquerade as wrotethebook.com MASQUERADE_AS(`wrotethebook.com') dnl Users whose mail is not masqueraded EXPOSED_USER(root) dnl Masquerade recipient and sender addresses FEATURE(`allmasquerade') Erstellen und installieren Sie die neue sendmail.cf-datei, und starten Sie sendmail neu, wie in Rezept 1.8 beschrieben. Diskussion Kommt die einfache Masquerading-Konfiguration aus Rezept 4.2 zum Einsatz, dann wird die Header-Empfängeradresse nicht umgeschrieben, wie dieser Test zeigt: # sendmail -bt -Crecipe4.2.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /tryflags HR > /try esmtp david@chef Trying header recipient address david@chef for mailer esmtp 4.5 Empfängeradressen maskieren 127

146 canonify input: chef Canonify2 input: david chef > Canonify2 returns: david chef. wrotethebook. com. > canonify returns: david chef. wrotethebook. com. > 2 input: david chef. wrotethebook. com. > 2 returns: david chef. wrotethebook. com. > EnvToSMTP input: david chef. wrotethebook. com. > PseudoToReal input: david chef. wrotethebook. com. > PseudoToReal returns: david chef. wrotethebook. com. > MasqSMTP input: david chef. wrotethebook. com. > MasqSMTP returns: david chef. wrotethebook. com. > EnvToSMTP returns: david chef. wrotethebook. com. > final input: david chef. wrotethebook. com. > final returns: chef. wrotethebook. com Rcode = 0, addr = david@chef.wrotethebook.com > /quit Der Befehl /tryflags fordert einen Test der Adressverarbeitung der Header-Empfängeradresse (Header Recipient Address; HR). Der Befehl /try weist sendmail an, die Adresse david@chef als Header-Empfängeradresse für den Mailer esmtp zu verarbeiten. Der Hostname chef wird durch das DNS in den kanonischen Namen chef.wrotethebook.com umgewandelt. Der Hostname jedoch wird nicht maskiert. Eine Konfiguration, die zusätzlich zum Makro MASQUERADE_AS die Funktion allmasquerade enthält, schreibt die Empfängeradressen für den Mailer emstp um, wie dieser Test beweist: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /tryflags HR > /try esmtp david@chef Trying header recipient address david@chef for mailer esmtp canonify input: chef Canonify2 input: david chef > Canonify2 returns: david chef. wrotethebook. com. > canonify returns: david chef. wrotethebook. com. > 2 input: david chef. wrotethebook. com. > 2 returns: david chef. wrotethebook. com. > HdrFromSMTP input: david chef. wrotethebook. com. > PseudoToReal input: david chef. wrotethebook. com. > PseudoToReal returns: david chef. wrotethebook. com. > MasqSMTP input: david chef. wrotethebook. com. > MasqSMTP returns: david chef. wrotethebook. com. > MasqHdr input: david chef. wrotethebook. com. > MasqHdr returns: david wrotethebook. com. > HdrFromSMTP returns: david wrotethebook. com. > final input: david wrotethebook. com. > final returns: wrotethebook. com Rcode = 0, addr = david@wrotethebook.com > /quit Links 128 Kapitel 4: Masquerading

147 Rechts Wird die Funktion allmasquerade benutzt, dann werden maskierte Hostnamen verborgen, wenn sie in der Liste der Empfänger auftauchen. Der Vorteil dieses Vorgehens besteht darin, dass eine konsistente Sicht auf die maskierten Adressen gewährleistet wird. Ein entfernter Benutzer könnte bemerken, dass Leute innerhalb der Domain wrotethebook.com Mail an den Zugang david mit Hilfe der Adresse versenden. Dieser entfernte Benutzer könnte dies dann ebenfalls versuchen. Falls die Einrichtung die Nutzer jedoch wirklich dazu anhalten will, die Adresse zu verwenden, um den Zugang david zu erreichen, dann hilft das Masquerading von Empfängeradressen dabei, da auf diese Weise den Benutzern nur die bevorzugte Adresse gezeigt wird. Siehe auch Die Rezepte 4.1 bis 4.11 behandeln weitere Masquerading-Funktionen. Das Buch sendmail behandelt MASQUERADE_AS in Abschnitt und EXPOSED_USER in Abschnitt Masquerading am Relay Host Problem Sie wurden gebeten, den Mail Relay Host so zu konfigurieren, dass er die Header-Absenderadresse von Mail maskiert, die von bestimmten Hosts stammt, wenn diese Mail das Mail Relay passiert. Lösung Legen Sie eine Datei an, die alle Hostnamen aufführt, die sendmail maskieren soll. Sie können der Datei einen beliebigen Namen geben. In diesem Beispiel trägt die Datei den Namen /etc/mail/masquerade-domains. Fügen Sie der sendmail-konfiguration auf dem Mail Relay Host die Makros MASQUERADE_AS, EXPOSED_USER und MASQUERADE_DOMAIN_FILE hinzu. Das Makro MASQUERADE_DOMAIN_FILE muss die Datei masquerade-domains festlegen, die im ersten Schritt erzeugt wurde. Hier sind Beispiele für die Befehle, die der Konfiguration des Mail Relays hinzugefügt wurden: dnl Masquerade the From address as wrotethebook.com MASQUERADE_AS(`wrotethebook.com') dnl Users whose mail is not masqueraded EXPOSED_USER(root) dnl Load the list of hostnames that will be masqueraded MASQUERADE_DOMAIN_FILE(`/etc/mail/masquerade-domains') Erstellen Sie die neue sendmail.cf-datei, kopieren Sie sie nach /etc/mail, und starten Sie sendmail neu. Rezept 1.8 bietet Beispiele für diese Schritte. 4.6 Masquerading am Relay Host 129

148 Diskussion Das Makro MASQUERADE_DOMAIN_FILE legt eine Datei fest, die in die sendmail.cf-klasse $=M geladen wird. sendmail maskiert Hosts, die in der Klasse $=M aufgeführt werden, genauso wie solche, die in der Klasse $=w stehen. Die Hosts in der Klasse $=M sind jedoch nicht äquivalent zu denjenigen in der Klasse $=w. Wenn Sie einen Hostnamen in die Klasse $=M setzen, wird das Masquerading aktiviert. Im Gegensatz zu Mail, die an Hosts aus der Klasse $=w adressiert ist, wird Mail, die an Hosts in der Klasse $=M adressiert ist, nicht für eine lokale Auslieferung akzeptiert. Die Klasse $=M ermöglicht es, die Menge der Hosts zu erweitern, für die Masquerading durchgeführt wird, ohne die Liste der lokalen Hostnamen-Aliase zu ergänzen. Ein einfacher Test zeigt die Wirkung des Makros MASQUERADE _DOMAIN_FILE: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $=M horseshoe.wrotethebook.com rodent.wrotethebook.com jamis.wrotethebook.com > /tryflags HS > /try esmtp david@jamis.wrotethebook.com Trying header sender address david@jamis.wrotethebook.com for mailer esmtp canonify input: jamis. wrotethebook. com Canonify2 input: david jamis. wrotethebook. com > Canonify2 returns: david jamis. wrotethebook. com. > canonify returns: david jamis. wrotethebook. com. > 1 input: david jamis. wrotethebook. com. > 1 returns: david jamis. wrotethebook. com. > HdrFromSMTP input: david jamis. wrotethebook. com. > PseudoToReal input: david jamis. wrotethebook. com. > PseudoToReal returns: david jamis. wrotethebook. com. > MasqSMTP input: david jamis. wrotethebook. com. > MasqSMTP returns: david jamis. wrotethebook. com. > MasqHdr input: david jamis. wrotethebook. com. > MasqHdr returns: david wrotethebook. com. > HdrFromSMTP returns: david wrotethebook. com. > final input: david wrotethebook. com. > final returns: wrotethebook. com Rcode = 0, addr = david@wrotethebook.com > $=w chef localhost.localdomain localhost [ ] [localhost.localdomain] [ ] chef.wrotethebook.com > /quit Links 130 Kapitel 4: Masquerading

149 Rechts Der Befehl $=M gibt den Inhalt der Klasse $=M aus und zeigt, dass die Klasse $=M die Daten der Datei /etc/mail/masquerade-domains enthält, die wir angelegt haben. Die - Adresse wird als maskiert, wenn sie als Header-Absenderadresse für den Mailer esmtp verarbeitet wird, auch wenn jamis.wrotethebook.com nicht in der Klasse $=w enthalten ist, weil sie in der Klasse $=M steht. Alternativen Die Beispieldatei masquerade-domains enthält nur drei Einträge. Es ist möglich, diese Konfiguration zu wiederholen, ohne die Datei masquerade-domains anzulegen, indem drei MASQUERADE_DOMAIN-Makros in die sendmail-konfigurationsdatei aufgenommen werden: dnl Host names that will be masqueraded MASQUERADE_DOMAIN(`rodent.wrotethebook.com') MASQUERADE_DOMAIN(`horseshoe.wrotethebook.com') MASQUERADE_DOMAIN(`jamis.wrotethebook.com') Diese Alternative wurde abgelehnt, da sie nicht so flexibel ist wie das Anlegen einer eigenen masquerade-domains-datei. Dieses Rezept maskiert einzelne Hostnamen. Einzelne Hosts kommen und gehen. Hostnamen ändern sich. Jede Änderung würde eine Änderung an der m4-konfiguration mit dem dazugehörenden Neuerstellen, Neuinstallieren und Neustarten erforderlich machen, wenn die Lösung mit MASQUERADE_DOMAIN zum Einsatz käme. Änderungen an der Datei masquerade-domains erfordern hingegen nur einen Neustart. Falls Sie tatsächlich alle Hosts maskieren wollen, die Relay-Berechtigungen haben, werden Sie möglicherweise versucht sein, die Datei relay-domains als MASQUERADE_DOMAIN _FILE zu verwenden: MASQUERADE_DOMAIN_FILE(`/etc/mail/relay-domains') Das ist im Allgemeinen keine gute Idee. Eine Standarddatei sollte auch nur für ihre Standardaufgabe benutzt werden. Die Datei relay-domains darf nur verwendet werden, um Relay-Berechtigungen zu gewähren. Um maskierte Hostnamen zu definieren, muss eine eigene Datei angelegt werden selbst wenn diese Dateien identisch sind. Sie können nämlich nicht garantieren, dass diese Dateien auch künftig identisch sein werden. Auf lange Sicht wirft es weniger Probleme auf, wenn Sie getrennte Dateien für jeweils eine eigene Aufgabe einsetzen, als wenn Sie eine Standarddatei missbrauchen. Siehe auch Die Rezepte 3.8 und 4.2 bieten unterstützende Informationen für dieses Rezept. In den Rezepten 4.4 und 4.7 werden ähnliche Konfigurationen behandelt, die Sie sich zunächst einmal anschauen sollten, bevor Sie dieses Rezept umsetzen. Das Buch sendmail behandelt MASQUERADE_AS in Abschnitt 4.4.2, EXPOSED_USER in Abschnitt 4.4.1, MASQUERADE_DOMAIN 4.6 Masquerading am Relay Host 131

150 in Abschnitt und MASQUERADE_DOMAIN_FILE in Abschnitt Der Abschnitt»Address Masquerading«des Buches Linux Sendmail Administration von Craig Hunt (Sybex) enthält eine Anleitung zum Masquerading. Die Datei cf/readme behandelt Masquerading im Abschnitt Masquerading and Relaying. Links 4.7 Das Masquerading beschränken Problem Wenn das Masquerading aktiviert ist, wird standardmäßig jeder Hostname maskiert, der zur lokalen Auslieferung akzeptiert wird (d. h. jeder Hostname, der als Alias für den lokalen Host akzeptiert wird). Sie wurden gebeten, eine sendmail-konfiguration anzulegen, die nicht jeden lokalen Hostnamen-Alias maskiert. Stattdessen sollen Sie nur solche Hostnamen maskieren, die besonders für ein Masquerading gekennzeichnet wurden. Lösung Erstellen Sie eine Datei, die nur die Namen derjenigen Hosts enthält, die Sie maskieren wollen. In diesem Beispiel nennen wir die Datei /etc/mail/masquerade-domains. Legen Sie eine sendmail-konfiguration an, die die Makros MASQUERADE_AS, EXPOSED_USER und MASQUERADE_DOMAIN_FILE sowie die Funktion limited_masquerade enthält. Hier sind Beispielbefehle: dnl Masquerade the From address as wrotethebook.com MASQUERADE_AS(`wrotethebook.com') dnl Users whose mail is not masqueraded EXPOSED_USER(root) dnl Load the list of hostnames that will be masqueraded MASQUERADE_DOMAIN_FILE(`/etc/mail/masquerade-domains') dnl Only masquerade names listed in class $=M FEATURE(`limited_masquerade') Erstellen Sie die Datei sendmail.cf neu, und installieren Sie sie erneut. Starten Sie dann sendmail neu, wie in Rezept 1.8 beschrieben. Diskussion Standardmäßig ist es jedem Host, der in der Klasse $=w aufgeführt wird, erlaubt zu vermitteln, und Mail, die an einen Host in der Klasse $=w adressiert ist, wird zur lokalen Auslieferung angenommen. Wenn außerdem das Makro MASQUERADE_AS zum Einsatz kommt, wird Mail von allen Hosts, die in der Klasse $=w stehen, maskiert. Das ist normalerweise genau das, was Sie wollen. Eine Ausnahme tritt jedoch auf, wenn die Klasse $=w eine größere Menge an Hosts für die Weitervermittlung oder die lokale Auslieferung definiert als die Menge, die maskiert werden soll. Nehmen Sie zum Beispiel an, dass Sie einen Mail 132 Kapitel 4: Masquerading

151 Rechts Exchanger haben, der Mail für einige Domains verarbeitet, und dass Ihre local-hostnames-datei die folgenden Einträge enthält: horseshoe.wrotethebook.com wrotethebook.com ora.com example.com stateu.edu Zwei dieser Einträge (horseshoe.wrotethebook.com und wrotethebook.com) befinden sich in der lokalen Domain, die anderen nicht. Normalerweise werden sowohl die Hostnamen in der Klasse $=w als auch diejenigen in der Klasse $=M maskiert. Da dieses System der Mail Exchanger für ora.com, example.com und stateu.edu ist, darf es diese Domains nicht als wrotethebook.com maskieren. Die Funktion limited_masquerade beschränkt das Masquerading auf jene Hosts, die in der Klasse $=M aufgeführt werden. Weitervermittlung und lokale Auslieferung werden weiterhin durch die Klasse $=w beeinflusst, allerdings wird die Klasse $=w für das Masquerading ignoriert, wenn die Funktion limited_masquerade ins Spiel kommt. Einige Tests unterstreichen dies. Der erste Test ist ein sendmail -bt-test mit der gerade gezeigten Datei local-host-names und einer Masquerading-Konfiguration, die nicht die Funktion limited_masquerade verwendet. # sendmail -bt -Crecipe4.2.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $=w example.com chef ora.com localhost.localdomain localhost [ ] [localhost.localdomain] stateu.edu [ ] horseshoe.wrotethebook.com wrotethebook.com chef.wrotethebook.com > /tryflags HS > /try esmtp amanda@stateu.edu Trying header sender address amanda@stateu.edu for mailer esmtp canonify input: stateu. edu Canonify2 input: amanda stateu. edu > Canonify2 returns: amanda stateu. edu. > canonify returns: amanda stateu. edu. > 1 input: amanda stateu. edu. > 1 returns: amanda stateu. edu. > HdrFromSMTP input: amanda stateu. edu. > PseudoToReal input: amanda stateu. edu. > 4.7 Das Masquerading beschränken 133

152 PseudoToReal returns: amanda stateu. edu. > MasqSMTP input: amanda stateu. edu. > MasqSMTP returns: amanda stateu. edu. > MasqHdr input: amanda stateu. edu. > MasqHdr returns: amanda wrotethebook. com. > HdrFromSMTP returns: amanda wrotethebook. com. > final input: amanda wrotethebook. com. > final returns: wrotethebook. com Rcode = 0, addr = amanda@wrotethebook.com > /quit In diesem Fall wird die Header-Absenderadresse amanda@stateu.edu zu amanda@ wrotethebook.com umgeschrieben. Die Leute bei stateu.edu wollen nicht, dass ihre Adressen auf diese Weise umgeschrieben werden, obwohl sie die Dienste des Mail Exchangers in Anspruch nehmen. Um dies zu lösen, fügen Sie der Konfiguration ein MASQUERADE_ DOMAIN_FILE-Makro hinzu und legen eine masquerade-domains-datei an, die die Namen der Hosts enthält, die maskiert werden sollen. Die Datei könnte beispielsweise folgende Einträge enthalten: rodent.wrotethebook.com crab.wrotethebook.com jamis.wrotethebook.com giant.wrotethebook.com horseshoe.wrotethebook.com Das Makro MASQUERADE_DOMAIN_FILE lädt die Datei in die Klasse $=M. Durch das Hinzufügen der Funktion limited_masquerade zur Konfiguration wird sendmail veranlasst, die Klasse $=w zu ignorieren und $=M für das Masquerading zu nutzen, wie der folgende Test zeigt: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $=w example.com chef ora.com localhost.localdomain localhost [ ] [localhost.localdomain] stateu.edu [ ] horseshoe.wrotethebook.com wrotethebook.com chef.wrotethebook.com > $=M rodent.wrotethebook.com crab.wrotethebook.com jamis.wrotethebook.com giant.wrotethebook.com horseshoe.wrotethebook.com > /tryflags HS Links 134 Kapitel 4: Masquerading

153 Rechts > /try esmtp Trying header sender address for mailer esmtp canonify input: stateu. edu Canonify2 input: amanda stateu. edu > Canonify2 returns: amanda stateu. edu. > canonify returns: amanda stateu. edu. > 1 input: amanda stateu. edu. > 1 returns: amanda stateu. edu. > HdrFromSMTP input: amanda stateu. edu. > PseudoToReal input: amanda stateu. edu. > PseudoToReal returns: amanda stateu. edu. > MasqSMTP input: amanda stateu. edu. > MasqSMTP returns: amanda stateu. edu. > MasqHdr input: amanda stateu. edu. > MasqHdr returns: amanda stateu. edu. > HdrFromSMTP returns: amanda stateu. edu. > final input: amanda stateu. edu. > final returns: stateu. edu Rcode = 0, addr = amanda@stateu.edu > /quit Jetzt geht Mail von amanda@stateu.edu mit der vollständigen stateu.edu-adresse nach draußen, obwohl stateu.edu immer noch in der Klasse $=w steht. Nur die Hostnamen in der Klasse $=M werden maskiert. Das Beispiel, das für diese Tests verwendet wurde, zeigt einen einzelnen Mail Exchanger, der mehrere Mail-Domains verwaltet. Das kann auch mit virtuellen Mail-Domains erledigt werden, mit denen wir uns in Kapitel 5 befassen. Siehe auch Die Rezepte 2.1, 4.2, 4.4 und 4.6 bieten unterstützende Informationen für dieses Rezept. Die Rezepte 4.4 und 4.6 behandeln ähnliche Konfigurationen, die Sie sich ansehen sollten, bevor Sie dieses Rezept umsetzen. Das Buch sendmail behandelt MASQUERADE_AS in Abschnitt 4.4.2, EXPOSED_USER in Abschnitt 4.4.1, MASQUERADE_DOMAIN in Abschnitt 4.4.3, MASQUERADE_DOMAIN_FILE in Abschnitt und die Funktion limited_masquerade in Abschnitt Der Abschnitt»Address Masquerading«des Buches Linux Sendmail Administration von Craig Hunt (Sybex) enthält eine Anleitung zum Masquerading. Die Datei cf/readme behandelt das Masquerading im Abschnitt Masquerading and Relaying. 4.8 Alle Hosts in einer Domain maskieren Problem Sie wollen alle Hosts innerhalb einer Domain maskieren, ohne jeden einzelnen Hostnamen in den Klassen $=M oder $=w zu definieren. 4.8 Alle Hosts in einer Domain maskieren 135

154 Lösung Legen Sie eine sendmail-konfiguration an, die die Makros MASQUERADE_AS und EXPOSED_USER enthält. Fügen Sie das Makro MASQUERADE_DOMAIN hinzu, um die Domain zu definieren, zu der der maskierte Host gehört. Und benutzen Sie außerdem die Funktion masquerade _entire_domain um sicherzustellen, dass alle Hosts in der Domain maskiert sind. Hier ist ein Beispiel für diese Befehle: dnl Masquerade the From address as wrotethebook.com MASQUERADE_AS(`wrotethebook.com') dnl Users whose mail is not masqueraded EXPOSED_USER(root) dnl Store the domain name that will be masqueraded in class $=M MASQUERADE_DOMAIN(`wrotethebook.com') dnl Masquerade every host in the domain FEATURE(`masquerade_entire_domain') Erstellen Sie die neue sendmail.cf-datei, installieren Sie sie, und starten Sie sendmail neu. In Rezept 1.8 finden Sie ein Beispiel für diese Schritte. Diskussion Standardmäßig wird jeder Hostname, der in den Klassen $=w und $=M aufgeführt ist, maskiert, wenn das Makro MASQUERADE_AS in der Konfiguration enthalten ist. Auf den meisten Systemen funktioniert das perfekt, da das System nur Mail maskiert, die von diesem System stammt, und alle gültigen Hostnamen für den lokalen Host in der Klasse $=w definiert sind. Daher maskiert das System alle Mails, die mit einem seiner gültigen Hostnamen gesendet werden. Mail Exchanger, Hubs und Relays sind komplizierter, da sie mit Mail für eine Vielzahl von Hosts umgehen müssen. Bei einem Mail Exchanger ist es nicht ungewöhnlich, dass dieser Mail für alle Hosts innerhalb einer Domain verarbeitet und Mail von jedem Host in dieser Domain maskieren will. Das einfache Hinzufügen des Domainnamens zu den Klassen $=w oder $=M reicht nicht aus, da der Domainname als Hostname interpretiert wird, wie dieser Test zeigt: # sendmail -bt -Crecipe4.6.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $=m wrotethebook.com horseshoe.wrotethebook.com > /tryflags HS > /try esmtp michael@crab.wrotethebook.com Trying header sender address michael@crab.wrotethebook.com for mailer esmtp canonify input: crab. wrotethebook. com Canonify2 input: michael crab. wrotethebook. com > Canonify2 returns: michael crab. wrotethebook. com. > canonify returns: michael crab. wrotethebook. com. > 1 input: michael crab. wrotethebook. com. > 1 returns: michael crab. wrotethebook. com. > Links 136 Kapitel 4: Masquerading

155 Rechts HdrFromSMTP input: michael crab. wrotethebook. com. > PseudoToReal input: michael crab. wrotethebook. com. > PseudoToReal returns: michael crab. wrotethebook. com. > MasqSMTP input: michael crab. wrotethebook. com. > MasqSMTP returns: michael crab. wrotethebook. com. > MasqHdr input: michael crab. wrotethebook. com. > MasqHdr returns: michael crab. wrotethebook. com. > HdrFromSMTP returns: michael crab. wrotethebook. com. > final input: michael crab. wrotethebook. com. > final returns: crab. wrotethebook. com Rcode = 0, addr = michael@crab.wrotethebook.com > /quit Der obige Test zeigt, dass die Klasse $=M den Wert wrotethebook.com enthält. Mail von crab jedoch, einem Host in der Domain wrotethebook.com, wird nicht maskiert, weil die Werte in $=M als Hostnamen betrachtet und nur exakte Treffer maskiert werden. Das Hinzufügen der Funktion masquerade_entire_domain zur Konfiguration ändert dieses Verhalten. Wenn diese Funktion vorhanden ist, dann werden Werte in der Klasse $=w weiterhin als Hostnamen interpretiert, während Werte in der Klasse $=M als Domainnamen aufgefasst werden. Alle Hosts in einer Domain, die in der Klasse $=M aufgeführt sind, werden maskiert. Die Funktion masquerade_entire_domain wird immer mit entweder dem Makro MASQUERADE_DOMAIN oder dem Makro MASQUERADE_DOMAIN_FILE verknüpft, die beide Werte in die Klasse $=M laden, da masquerade_entire_domain nur die Werte in der Klasse $=M beeinflusst. Ein Test der Konfiguration, die durch dieses Rezept entstanden ist, zeigt die Wirkung dieser Funktion: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $=M wrotethebook.com > /tryflags HS > /try esmtp michael@crab.wrotethebook.com Trying header sender address michael@crab.wrotethebook.com for mailer esmtp canonify input: crab. wrotethebook. com Canonify2 input: michael crab. wrotethebook. com > Canonify2 returns: michael crab. wrotethebook. com. > canonify returns: michael crab. wrotethebook. com. > 1 input: michael crab. wrotethebook. com. > 1 returns: michael crab. wrotethebook. com. > HdrFromSMTP input: michael crab. wrotethebook. com. > PseudoToReal input: michael crab. wrotethebook. com. > PseudoToReal returns: michael crab. wrotethebook. com. > MasqSMTP input: michael crab. wrotethebook. com. > MasqSMTP returns: michael crab. wrotethebook. com. > MasqHdr input: michael crab. wrotethebook. com. > MasqHdr returns: michael wrotethebook. com. > HdrFromSMTP returns: michael wrotethebook. com. > final input: michael wrotethebook. com. > final returns: wrotethebook. com Rcode = 0, addr = michael@wrotethebook.com > /quit 4.8 Alle Hosts in einer Domain maskieren 137

156 Der Befehl $=M zeigt den Wert, der in der Klasse $=M durch das Makro MASQUERADE_DOMAIN gespeichert wird. In diesem Fall haben wir nur einen Wert in der Klasse $=M zu speichern, und da wir nicht vorhaben, ihn zu ändern, funktioniert MASQUERADE_DOMAIN ganz gut. Wenn Sie mehrere Werte haben, wollen Sie vermutlich MASQUERADE_DOMAIN_FILE benutzen, wie in Rezept 4.6 gezeigt wird. In diesem Test wird crab.wrotethebook.com maskiert, da es sich um einen Host in einer Domain handelt, die in der Klasse $=M aufgeführt ist die Wirkung der Funktion masquerade_entire_domain. Diese Funktion hat keinen Einfluss auf Werte in der Klasse $=w. Diese Werte werden weiterhin als Hosts interpretiert und damit weiterhin maskiert. Falls Sie das Masquerading auf die Domains beschränken wollen, die in der Klasse $=M definiert sind, dann fügen Sie der Konfiguration die Funktion limited_masquerade hinzu, wie in Rezept 4.7 beschrieben. Links Siehe auch Die Rezepte 4.4 und 4.7 behandeln ähnliche Konfigurationen, die Sie sich anschauen sollten, bevor Sie dieses Rezept umsetzen. Das Buch sendmail behandelt die Funktion masquerade_entire_domain in Abschnitt , MASQUERADE_AS in Abschnitt 4.4.2, EXPOSED_USER in Abschnitt 4.4.1, MASQUERADE_DOMAIN in Abschnitt und MASQUERADE _DOMAIN_FILE in Abschnitt Der Abschnitt»Address Masquerading«des Buches Linux Sendmail Administration von Craig Hunt (Sybex) enthält eine Anleitung zum Masquerading. Die Datei cf/readme behandelt das Masquerading im Abschnitt Masquerading and Relaying. 4.9 Die meisten Hosts in einer Domain maskieren Problem Sie wurden gebeten, eine sendmail-konfiguration anzulegen, die alle Hosts in einer Domain maskiert, mit Ausnahme einiger Hosts für besondere Aufgaben, die für die Außenwelt sichtbar sein sollen. Lösung Legen Sie eine Datei an, die alle Hosts der Domain aufführt, die vom Masquerading ausgenommen werden sollen. Der Name der Datei kann beliebig gewählt werden. Dieses Rezept verwendet den Namen /etc/mail/masquerade-exceptions. Fügen Sie der sendmail-konfiguration die Funktion masquerade_entire_domain sowie die Makros MASQUERADE_AS, EXPOSED_USER, MASQUERADE_DOMAIN und MASQUERADE_EXCEPTION_FILE hinzu. Beispiele der relevanten Befehle werden im Folgenden gezeigt: dnl Masquerade the From address as wrotethebook.com MASQUERADE_AS(`wrotethebook.com') dnl Users whose mail is not masqueraded 138 Kapitel 4: Masquerading

157 Rechts EXPOSED_USER(root) dnl Store the domain name that will be masqueraded in class $=M MASQUERADE_DOMAIN(`wrotethebook.com') dnl Masquerade all hosts in the domain FEATURE(`masquerade_entire_domain') dnl Load the list of hosts that should not be masqueraded MASQUERADE_EXCEPTION_FILE(`/etc/mail/masquerade-exceptions') Erstellen und installieren Sie entsprechend den Anweisungen aus Rezept 1.8 die Datei sendmail.cf neu, und starten Sie dann sendmail. Diskussion Die Funktion masquerade_entire_domain veranlasst sendmail, alle Namen in der Klasse $=M als Domain zu behandeln und bei einer Kombination mit dem Makro MASQUERADE_AS alle Hosts innerhalb dieser Domains zu maskieren. Rezept 4.8 zeigt die Wirkung der Funktion masquerade_entire_domain. Falls Sie die meisten Hosts in einer Domain maskieren wollen, ist es oft einfacher, die gesamte Domain zu maskieren und dann Ausnahmen festzulegen, als eine Liste der einzelnen Hosts anzugeben, die Sie maskieren wollen. Die Datei, die durch das Makro MASQUERADE_EXCEPTION_FILE identifiziert wird, wird in die sendmail.cf-klasse $=N geladen. Die Klasse $=N enthält eine Liste der Hosts, die nicht maskiert werden sollen, selbst wenn sie zu einer Domain gehören, die maskiert wird. Nehmen Sie zum Beispiel an, die Datei /etc/mail/masquerade-exceptions, die für dieses Rezept angelegt worden ist, enthielte die folgenden Einträge: # cat > /etc/mail/masquerade-exceptions info.wrotethebook.com sales.wrotethebook.com Ctrl-D Dieses Rezept maskiert alle Hosts in wrotethebook.com mit Ausnahme dieser drei Hosts, wie der folgende Test zeigt: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $=M wrotethebook.com > /tryflags HS > /try esmtp peyton@crab.wrotethebook.com Trying header sender address peyton@crab.wrotethebook.com for mailer esmtp canonify input: crab. wrotethebook. com Canonify2 input: peyton crab. wrotethebook. com > Canonify2 returns: peyton crab. wrotethebook. com. > canonify returns: peyton crab. wrotethebook. com. > 1 input: peyton crab. wrotethebook. com. > 1 returns: peyton crab. wrotethebook. com. > HdrFromSMTP input: peyton crab. wrotethebook. com. > PseudoToReal input: peyton crab. wrotethebook. com. > PseudoToReal returns: peyton crab. wrotethebook. com. > 4.9 Die meisten Hosts in einer Domain maskieren 139

158 MasqSMTP input: peyton crab. wrotethebook. com. > MasqSMTP returns: peyton crab. wrotethebook. com. > MasqHdr input: peyton crab. wrotethebook. com. > MasqHdr returns: peyton wrotethebook. com. > HdrFromSMTP returns: peyton wrotethebook. com. > final input: peyton wrotethebook. com. > final returns: wrotethebook. com Rcode = 0, addr = peyton@wrotethebook.com > $=N info.wrotethebook.com sales.wrotethebook.com > /try esmtp jill@sales.wrotethebook.com Trying header sender address jill@sales.wrotethebook.com for mailer esmtp canonify input: sales. wrotethebook. com Canonify2 input: jill sales. wrotethebook. com > Canonify2 returns: jill sales. wrotethebook. com. > canonify returns: jill sales. wrotethebook. com. > 1 input: jill sales. wrotethebook. com. > 1 returns: jill sales. wrotethebook. com. > HdrFromSMTP input: jill sales. wrotethebook. com. > PseudoToReal input: jill sales. wrotethebook. com. > PseudoToReal returns: jill sales. wrotethebook. com. > MasqSMTP input: jill sales. wrotethebook. com. > MasqSMTP returns: jill sales. wrotethebook. com. > MasqHdr input: jill sales. wrotethebook. com. > MasqHdr returns: jill sales. wrotethebook. com. > HdrFromSMTP returns: jill sales. wrotethebook. com. > final input: jill sales. wrotethebook. com. > final returns: sales. wrotethebook. com Rcode = 0, addr = jill@sales.wrotethebook.com > /quit Der Befehl $=M zeigt, dass die Klasse $=M den Domainnamen wrotethebook.com enthält. In dieser Konfiguration wird die Funktion masquerade_entire_domain verwendet; die Verarbeitung von peyton@crab.wrotethebook.com als Header-Absenderadresse für den Mailer esmtp ergibt also die Adresse peyton@wrotethebook.com, da crab ein Host in der Domain wrotethebook.com ist. Dagegen ergibt die Verarbeitung der Adresse jill@sales. wrotethebook.com als Header-Absenderadresse für den Mailer esmtp die Originaladresse ohne Masquerading, obwohl auch sales.wrotethebook.com ein Host in der Domain wrotethebook.com ist. Die Adresse sales.wrotethebook.com wird deshalb nicht maskiert, weil sie in der Klasse $=N aufgeführt ist, wie der Befehl $=N zeigt. Alternativen Auf Grund der geringen Anzahl an Hosts in der Datei masquerade-exceptions wäre die Benutzung des Makros MASQUERADE_EXCEPTION eine machbare Alternative zum Erstellen einer Datei für das Makro MASQUERADE_EXCEPTION_FILE. Dieses Rezept könnte dadurch geändert werden, dass das Makro MASQUERADE_EXCEPTION durch die folgenden Zeilen ersetzt werden würde: Links 140 Kapitel 4: Masquerading

159 Rechts dnl Define hosts that should not be masqueraded MASQUERADE_EXCEPTION(` MASQUERADE_EXCEPTION(`info.wrotethebook.com') MASQUERADE_EXCEPTION(`sales.wrotethebook.com') Die Systeme, für die kein Masquerading durchgeführt werden soll, sind im Allgemeinen Systeme für besondere Aufgaben. Es gibt normalerweise nur eine begrenzte Anzahl solcher Systeme, und die Menge dieser Systeme ändert sich üblicherweise kaum. Aus diesen Gründen bildet das Makro MASQUERADE_EXCEPTION eine praktikable Alternative zum Anlegen einer Datei für die Liste der Hostnamen. Wenn Sie jedoch eine große Anzahl von Hosts haben, die nicht maskiert werden sollen, oder wenn sich die Liste der ausgeschlossenen Hosts häufig ändert, dann ist MASQUERADE_EXCEPTION_FILE die beste Wahl. Nehmen Sie das Makro, das Ihnen am besten gefällt beide funktionieren gleichermaßen gut. Siehe auch Die Rezepte 4.7 und 4.8 behandeln ähnliche Konfigurationen, die Sie sich anschauen sollten, bevor Sie dieses Rezept umsetzen. Das Buch sendmail behandelt die Funktion masquerade_entire_domain in Abschnitt , MASQUERADE_AS in Abschnitt 4.4.2, EXPOSED_USER in Abschnitt 4.4.1, MASQUERADE_DOMAIN in Abschnitt 4.4.3, MASQUERADE_ DOMAIN_FILE in Abschnitt und MASQUERADE_EXCEPTION sowie MASQUERADE_EXCEPTION_ FILE in Abschnitt Der Abschnitt»Address Masquerading«des Buches Linux Sendmail Administration von Craig Hunt (Sybex) enthält eine Anleitung zum Masquerading. Die Datei cf/readme behandelt das Masquerading im Abschnitt Masquerading and Relaying Die Umschlagadresse maskieren Problem Sie wurden gebeten, eine Konfiguration anzulegen, die zusätzlich zum Masquerading der Header-Absenderadresse die Umschlagabsenderadresse maskiert, die vom SMTP-Protokoll verwendet wird. Lösung Fügen Sie der sendmail-konfiguration die Funktion masquerade_envelope, das Makro MASQUERADE_AS und das Makro EXPOSED_USER hinzu. Hier sind Beispiele: dnl Masquerade the From address as wrotethebook.com MASQUERADE_AS(`wrotethebook.com') dnl Users whose mail is not masqueraded EXPOSED_USER(root) dnl Masquerade the envelope address as wrotethebook.com FEATURE(`masquerade_envelope') 4.10 Die Umschlagadresse maskieren 141

160 Erstellen und installieren Sie die neue Konfiguration, und starten Sie dann sendmail neu. Rezept 1.8 zeigt dies an einem Beispiel. Diskussion Standardmäßig ersetzt das Makro MASQUERADE_AS den Hostnamen im From:-Nachrichten- Header durch den Maskierungswert. Die From:-Header-Adresse wird als Header-Absenderadresse (Header Sender Address) bezeichnet. Aus Sicht des SMTP-Protokolls sind die Nachrichten-Header einfach nur Teil der Nachricht Daten, die nach dem SMTP-Befehl DATA gesandt werden. Die Adressen, die durch das SMTP-Protokoll vor dem SMTP- Befehl DATA ausgetauscht werden, heißen Umschlagadressen (Envelope Addresses). Die Adresse der Quelle der Mail wird Umschlagabsenderadresse (Envelope Sender Address) genannt. Die Umschlagabsenderadresse erscheint im SMTP-Protokollaustausch als Wert im SMTP-Befehl MAIL From:. Das Makro MASQUERADE_AS führt standardmäßig kein Masquerading des Hostnamens in der Umschlagabsenderadresse aus. Ein Test der grundlegenden Masquerading-Konfiguration zeigt das: # sendmail bt Crecipe4.2.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /tryflags HS > /try esmtp clark@horseshoe.wrotethebook.com Trying header sender address clark@horseshoe.wrotethebook.com for mailer esmtp canonify input: horseshoe. wrotethebook. com Canonify2 input: clark horseshoe. wrotethebook. com > Canonify2 returns: clark horseshoe. wrotethebook. com. > canonify returns: clark horseshoe. wrotethebook. com. > 1 input: clark horseshoe. wrotethebook. com. > 1 returns: clark horseshoe. wrotethebook. com. > HdrFromSMTP input: clark horseshoe. wrotethebook. com. > PseudoToReal input: clark horseshoe. wrotethebook. com. > PseudoToReal returns: clark horseshoe. wrotethebook. com. > MasqSMTP input: clark horseshoe. wrotethebook. com. > MasqSMTP returns: clark horseshoe. wrotethebook. com. > MasqHdr input: clark horseshoe. wrotethebook. com. > MasqHdr returns: clark wrotethebook. com. > HdrFromSMTP returns: clark wrotethebook. com. > final input: clark wrotethebook. com. > final returns: wrotethebook. com Rcode = 0, addr = clark@wrotethebook.com > /tryflags ES > /try esmtp clark@horseshoe.wrotethebook.com Trying envelope sender address clark@horseshoe.wrotethebook.com for mailer esmtp canonify input: horseshoe. wrotethebook. com Canonify2 input: clark horseshoe. wrotethebook. com > Canonify2 returns: clark horseshoe. wrotethebook. com. > canonify returns: clark horseshoe. wrotethebook. com. > 1 input: clark horseshoe. wrotethebook. com. > 1 returns: clark horseshoe. wrotethebook. com. > EnvFromSMTP input: clark horseshoe. wrotethebook. com. > Links 142 Kapitel 4: Masquerading

161 Rechts PseudoToReal input: clark horseshoe. wrotethebook. com. > PseudoToReal returns: clark horseshoe. wrotethebook. com. > MasqSMTP input: clark horseshoe. wrotethebook. com. > MasqSMTP returns: clark horseshoe. wrotethebook. com. > MasqEnv input: clark horseshoe. wrotethebook. com. > MasqEnv returns: clark horseshoe. wrotethebook. com. > EnvFromSMTP returns: clark horseshoe. wrotethebook. com. > final input: clark horseshoe. wrotethebook. com. > final returns: horseshoe. wrotethebook. com Rcode = 0, addr = clark@horseshoe.wrotethebook.com > /quit Der erste /tryflags-befehl konfiguriert sendmail dahingehend, dass die Verarbeitung der Header-Absenderadresse (HS) getestet wird. Der erste /try-befehl verarbeitet clark@ horseshoe.wrotethebook.com als Header-Absenderadresse für den Mailer esmtp. Das Ergebnis zeigt, dass die Adresse als clark@wrotethebook.com maskiert wird. Der zweite /tryflags-befehl konfiguriert das System für die Verarbeitung der Umschlagabsenderadresse (ES). Dieses Mal wird die Adresse nicht maskiert. Das ist die grundlegende Masquerading-Konfiguration; sie maskiert die Header-Adressen, nicht jedoch die Umschlagadressen. Die Funktion masquerade_envelope ändert das, wie der folgende Test der Konfiguration dieses Rezepts zeigt: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /tryflags ES > /try esmtp clark@horseshoe.wrotethebook.com Trying envelope sender address clark@horseshoe.wrotethebook.com for mailer esmtp canonify input: horseshoe. wrotethebook. com Canonify2 input: clark horseshoe. wrotethebook. com > Canonify2 returns: clark horseshoe. wrotethebook. com. > canonify returns: clark horseshoe. wrotethebook. com. > 1 input: clark horseshoe. wrotethebook. com. > 1 returns: clark horseshoe. wrotethebook. com. > EnvFromSMTP input: clark horseshoe. wrotethebook. com. > PseudoToReal input: clark horseshoe. wrotethebook. com. > PseudoToReal returns: clark horseshoe. wrotethebook. com. > MasqSMTP input: clark horseshoe. wrotethebook. com. > MasqSMTP returns: clark horseshoe. wrotethebook. com. > MasqEnv input: clark horseshoe. wrotethebook. com. > MasqHdr input: clark horseshoe. wrotethebook. com. > MasqHdr returns: clark wrotethebook. com. > MasqEnv returns: clark wrotethebook. com. > EnvFromSMTP returns: clark wrotethebook. com. > final input: clark wrotethebook. com. > final returns: wrotethebook. com Rcode = 0, addr = clark@wrotethebook.com > /quit Dieser Test wiederholt den zweiten Teil des früheren Tests. Bei der grundlegenden Masquerading-Konfiguration wurde die Umschlagabsenderadresse nicht maskiert nun ist sie es Die Umschlagadresse maskieren 143

162 Benutzer und die Mail-Programme von Benutzern hantieren mit den Header-Absenderadressen. Eine Antwort in einem Benutzer-Mail-Programm erfolgt an die Adresse, die in einem Nachrichten-Header zu finden ist. Das Masquerading der Header-Absenderadressen stellt sicher, dass entfernte Benutzer die richtige Adresse erhalten, um lokalen Benutzern zu antworten. Auf diese Weise nützt das Masquerading den Benutzern. Hingegen haben die Benutzer normalerweise nichts mit den Umschlagadressen zu tun. Das Masquerading von Umschlagadressen vereinfacht die Interaktion der Maschinen. Dazu gibt es verschiedene gute Gründe: Das Aktivieren der Weitervermittlung. Das Bewerten der Umschlagadresse ist eine der Standardprüfungen, die durchgeführt werden, um ein Relaying zu autorisieren. Die Header-Absenderadresse wird normalerweise beim Relaying nicht benutzt. Das heißt: Falls Hosts Masquerading durchführen müssen, um Mail an ein Relay zu übergeben, wird die Umschlagabsenderadresse maskiert. Um die richtige Auslieferung der Fehlermeldungen sicherzustellen, die an die Umschlagadresse gesandt werden. Um zu verhindern, dass sendmail Mail von Hosts abweist, die private Hostnamen verwenden. sendmail prüft die Umschlagabsenderadresse, um festzustellen, ob diese per DNS aufgelöst werden kann. Wenn intern private Hostnamen benutzt werden können, muss Mail von diesen Hosts mit einem Hostnamen maskiert werden, der im öffentlichen DNS zu finden ist. Dieses Masquerading wird auf die Umschlagadresse angewandt. Anderenfalls könnte die Mail durch den sendmail-prozess, der auf dem entfernten System läuft, abgewiesen werden. Aus diesen und anderen Gründen wenden viele Sites, die Masquerading einsetzen, dies sowohl auf die Header- als auch auf die Umschlagadressen an. Links Siehe auch Rezept 4.2 liefert unterstützende Informationen für diese Konfiguration. Kapitel 3 behandelt die Konfiguration eines Mail Relays und beschreibt den Einsatz der Umschlagadresse beim Relaying. Das Buch sendmail behandelt das Makro MASQUERADE_AS in Abschnitt 4.4.2, das Makro EXPOSED_USER in Abschnitt und die Funktion masquerade_envelope in Abschnitt Der Abschnitt»Address Masquerading«des Buches Linux Sendmail Administration von Craig Hunt (Sybex) enthält eine Anleitung zum Masquerading. Die Datei cf/readme behandelt Masquerading im Abschnitt Masquerading and Relaying. 144 Kapitel 4: Masquerading

163 Rechts 4.11 Die From-Adresse mit der genericstable umschreiben Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es den Login-Namen, der als Absenderadresse für Mail verwendet wird, die vom lokalen Host stammt, durch eine Adresse ersetzt, die dem Adressformat entspricht, das Ihre Einrichtung oder Organisation bevorzugt. Lösung Erstellen Sie eine genericstable-datenbank, um die Eingangsabsenderadresse auf das Format abzubilden, das Sie für die Header-Absenderadresse haben wollen. Jeder Eintrag in der genericstable enthält zwei Felder: den Schlüssel und den Wert, der für diesen Schlüssel zurückgegeben wird. Das Schlüsselfeld eines genericstable-eintrags kann entweder eine vollständige -Adresse oder ein Benutzername sein. Der Wert, der zurückgegeben wird, wird als umgeschriebene Absenderadresse verwendet; normalerweise ist dies eine vollständige Adresse mit Benutzer- und Hostnamen. Um die genericstable zu erzeugen, legen Sie zuerst eine Textdatei an, die die Datenbankeinträge enthält. Danach lassen Sie die Textdatei durch das makemap-skript laufen, um die genericstable-datenbank zu erzeugen. Um die neu erzeugte genericstable-datenbank zu nutzen, legen Sie eine sendmail-konfiguration an, die die Funktion genericstable und das Makro GENERICS_DOMAIN enthält. Das Domainnamenargument des Makros GENERICS_DOMAIN teilt sendmail mit, wann es die genericstable benutzen soll. Hier sind Beispielzeilen, die in die sendmail-konfiguration eingefügt werden könnten: dnl Process login names through the genericstable FEATURE(`genericstable') dnl Identify the host that the genericstable applies to GENERICS_DOMAIN(`chef.wrotethebook.com') Erstellen Sie sendmail neu, installieren und starten Sie es, wie in Rezept 1.8 beschrieben. Diskussion Mail, die ihren Ursprung auf dem lokalen Host hat, verwendet standardmäßig den Login-Namen des Benutzers als Benutzernamenteil. In diesem Beispiel ist daher das Schlüsselfeld der genericstable ein Login-Name und der Wert, der zurückgegeben wird, eine vollständige -Adresse. Die Zuordnung können Sie nach Belieben festlegen; wir ordnen allerdings in diesem Beispiel die Login-Namen den echten Namen sowie der 4.11 Die From-Adresse mit der genericstable umschreiben 145

164 lokalen Domain der Benutzer zu, formatiert als formatiert. 5 Dazu wird eine Textdatei angelegt und dann durch makemap geschickt: # cd /etc/mail # cat > genericstable kathy kathy.mccafferty@wrotethebook.com craig craig.hunt@wrotethebook.com sara sara.henson@wrotethebook.com dave david.craig@wrotethebook.com becky rebecca.fro@wrotethebook.com alana alana.smiley@wrotethebook.com jay jay.james@wrotethebook.com Ctrl-D # makemap hash genericstable < genericstable Falls natürlich Mail am lokalen Host ankommt, die an vorname.nachname@domain adressiert ist, werden Aliase benötigt, um die Mail an die echten Adressen der Benutzer auszuliefern. Aliase auf der Grundlage der oben gezeigten genericstable-einträge könnten auf folgende Weise in die aliases-datenbank eingefügt werden: # cd /etc/mail # cat > aliases kathy.mccafferty: kathy craig.hunt: craig sara.henson: sara david.craig: dave rebecca.fro: becky alana.smiley: alana jay.james: jay Ctrl-D # newaliases Nach dem Erstellen der genericstable-datenbank und Hinzufügen der Funktion genericstable zur Konfiguration stehen die genericstable-daten sendmail zur Verfügung, wie dieser sendmail -bt-test zeigt: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /map generics sara map_lookup: generics (sara) returns sara.henson@wrotethebook.com (0) > /quit sendmail wird hier mit der Option -bt ausgeführt. Der Befehl /map dient dazu, den Eintrag für den Login-Namen sara zu suchen. Es wird der Wert sara.henson@wrotethebook. com zurückgegeben. Das heißt, man würde erwarten, dass die Absenderadresse aller Mails, die auf diesem Host von sara stammen, in sara.henson@wrotethebook.com umgeschrieben wird. Das wäre hier auch der Fall, aber nur, weil dieses Rezept das Makro GENERICS_DOMAIN enthält. Ohne das Makro GENERICS_DOMAIN handelt die Funktion 5 Das Format vorname.nachname@domain wird nicht allgemein geschätzt. In der FAQ finden Sie Gründe dafür, weshalb Sie dieses Adressformat vielleicht nicht einsetzen sollten. Links 146 Kapitel 4: Masquerading

165 Rechts genericstable nicht so, wie man es erwarten würde. Hier ist ein Beispiel für die Benutzung der Funktion genericstable ohne das Makro GENERICS_DOMAIN: # sendmail bt Cspecial4-11-test.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $j chef.wrotethebook.com > /tryflags HS > /try esmtp sara Trying header sender address sara for mailer esmtp canonify input: sara Canonify2 input: sara Canonify2 returns: sara canonify returns: sara 1 input: sara 1 returns: sara HdrFromSMTP input: sara PseudoToReal input: sara PseudoToReal returns: sara MasqSMTP input: sara MasqSMTP returns: sara *LOCAL* > MasqHdr input: sara *LOCAL* > canonify input: sara. wrotethebook. com Canonify2 input: sara. henson wrotethebook. com > Canonify2 returns: sara. henson wrotethebook. com. > canonify returns: sara. henson wrotethebook. com. > MasqHdr returns: sara. henson wrotethebook. com. > HdrFromSMTP returns: sara. henson wrotethebook. com. > final input: sara. henson wrotethebook. com. > final returns: sara. wrotethebook. com Rcode = 0, addr = sara.henson@wrotethebook.com > /try esmtp sara@chef Trying header sender address sara@chef for mailer esmtp canonify input: chef Canonify2 input: sara chef > Canonify2 returns: sara chef. wrotethebook. com. > canonify returns: sara chef. wrotethebook. com. > 1 input: sara chef. wrotethebook. com. > 1 returns: sara chef. wrotethebook. com. > HdrFromSMTP input: sara chef. wrotethebook. com. > PseudoToReal input: sara chef. wrotethebook. com. > PseudoToReal returns: sara chef. wrotethebook. com. > MasqSMTP input: sara chef. wrotethebook. com. > MasqSMTP returns: sara chef. wrotethebook. com. > MasqHdr input: sara chef. wrotethebook. com. > MasqHdr returns: sara chef. wrotethebook. com. > HdrFromSMTP returns: sara chef. wrotethebook. com. > final input: sara chef. wrotethebook. com. > final returns: chef. wrotethebook. com Rcode = 0, addr = sara@chef.wrotethebook.com > /quit 4.11 Die From-Adresse mit der genericstable umschreiben 147

166 Der gerade gezeigte Test wird auf einem Host namens chef.wrotethebook.com ausgeführt, wie der Befehl $j zeigt. Dieser Host setzt die Funktion genericstable ohne das Makro GENERICS_DOMAIN ein. Da Login-Namen unter Unix auf einem Host eindeutig sein müssen, wissen wir, dass es sich bei sara, und um jeweils die gleiche Person handelt. Der Test zeigt jedoch, dass sendmail diese Eingangsadressen in Hinsicht auf die genericstable nicht gleich behandelt. Wenn die Eingangsadresse keinen Host-Anteil enthält, wird sie umgeschrieben; anderenfalls wird sie nicht umgeschrieben. Der Grund dafür ist einfach: die genericstable, die wir erzeugt haben, bildet nur Login-Namen ab; keiner der Datenbankschlüssel enthält einen Hostnamenanteil. Wir wollen jedoch eine konsistente Header-Absenderadresse erzeugen keine Adresse, die von der Adresse abhängt, die der Benutzer eingibt. Um dies zu erreichen, nutzt dieses Rezept das Makro GENERICS_DOMAIN und setzt es auf den voll qualifizierten Namen, der im Makro $j verwendet wird. Dies veranlasst sendmail, die genericstable konsistent einzusetzen, um die Header-Absenderadresse der ganzen Mail umzuschreiben, die von diesem Host stammt. Hier ist ein Testdurchlauf mit der Konfiguration dieses Rezepts: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $=G chef.wrotethebook.com > /tryflags HS > /try esmtp sara@[ ] Trying header sender address sara@[ ] for mailer esmtp canonify input: [ ] Canonify2 input: sara [ ] > Canonify2 returns: sara chef. wrotethebook. com. > canonify returns: sara chef. wrotethebook. com. > 1 input: sara chef. wrotethebook. com. > 1 returns: sara chef. wrotethebook. com. > HdrFromSMTP input: sara chef. wrotethebook. com. > PseudoToReal input: sara chef. wrotethebook. com. > PseudoToReal returns: sara chef. wrotethebook. com. > MasqSMTP input: sara chef. wrotethebook. com. > MasqSMTP returns: sara chef. wrotethebook. com. > MasqHdr input: sara chef. wrotethebook. com. > canonify input: sara. wrotethebook. com Canonify2 input: sara. henson wrotethebook. com > Canonify2 returns: sara. henson wrotethebook. com. > canonify returns: sara. henson wrotethebook. com. > MasqHdr returns: sara. henson wrotethebook. com. > HdrFromSMTP returns: sara. henson wrotethebook. com. > final input: sara. henson wrotethebook. com. > final returns: sara. wrotethebook. com Rcode = 0, addr = sara.henson@wrotethebook.com > /quit Links 148 Kapitel 4: Masquerading

167 Rechts Das Makro GENERICS_DOMAIN lädt den Wert, der auf seiner Kommandozeile angegeben wurde, in die sendmail.cf-klasse $=G. sendmail wendet die genericstable auf jede Absenderadresse an, für die ein Name als ihr Hostnamenanteil in der Klasse $=G aufgeführt wird. In diesem Test zeigt der Befehl $=G, dass die Klasse $=G nur chef.wrotethebook.com enthält, den voll qualifizierten Namen dieses Hosts und der gleiche Wert, der in $j zu finden ist. Deshalb passt jeder Hostname, den sendmail zu $j umschreibt, auf den Wert in $=G und wird ebenfalls durch die genericstable verarbeitet. In diesem Test zeigen wir einen Extremfall, indem wir die Loopback-Adresse [ ] als Hostnamen nehmen, den sendmail auf den Wert umschreibt, der von $j zurückgeliefert wird, und anschließend durch den entsprechenden Eintrag der genericstable ersetzt. Wir hätten genauso gut chef, localhost, [ ] oder chef.wrotethebook.com als Hostnamen verwenden können alle gültigen Variationen des Namens des lokalen Hosts funktionieren. 6 In diesem Rezept stammen die s, die durch die genericstable verarbeitet werden, vom lokalen Host. Das bedeutet, dass die Eingangsabsenderadresse entweder keinen Hostnamenanteil besitzt oder es sich bei dem Hostnamen im Absender um einen Hostnamen des lokalen Hosts handelt. Viele Systeme (Mail Relay Hosts sind ein Beispiel) verarbeiten Mail von einer Vielzahl von Hosts. Die Absenderadresse kann in diesem Fall den Hostnamen eines beliebigen Hosts enthalten, dem eine Relaying-Berechtigung gewährt wurde. Da Mail nur dann durch die genericstable verarbeitet wird, wenn der Hostname des Absenders in der Klasse $=G zu finden ist, sollten die Hostnamen aller Hosts, denen es erlaubt ist, Mail durch das Relay zu senden, in die Klasse $=G geladen werden. Handelt es sich dabei um eine kleine Anzahl an Hostnamen, kann man dies erledigen, indem man mehrere GENERICS_DOMAIN-Makros in die Konfiguration aufnimmt. Bei vielen Hostnamen hingegen ist es einfacher, eine Datei anzulegen, die alle Hosts aufführt, und dann innerhalb der Konfiguration mit einem GENERICS_DOMAIN_FILE-Makro auf diese Datei zu verweisen. Beispielsweise würde das folgende Makro $=G mit allen Hostnamen, die in einer Datei namens /etc/mail/generics-domains aufgeführt sind, laden, wenn es in diesem Rezept anstelle des Makros GENERICS_DOMAIN eingesetzt werden würde: GENERICS_DOMAIN_FILE(`/etc/mail/generics-domains') Das Makro GENERICS_DOMAIN_FILE ermöglicht es, die Verarbeitung durch die genericstable mit anderen sendmail-funktionen zu koordinieren. Dazu werden einfach die Hostnamen den Dateien entnommen, die diese anderen Funktionen kontrollieren, und in der Datei gespeichert, die durch das Makro GENERICS_DOMAIN_FILE geladen wird. Werden zum Beispiel die Hostnamen aus /etc/mail/local-host-names in die Datei kopiert, die durch das Makro GENERICS_DOMAIN_FILE geladen wird, so wird die genericstable-verarbeitung für alle Systeme aktiviert, die einen Mail Exchanger verwenden. 6 Das bedeutet nicht unbedingt, dass alle Hostnamen-Aliase, die in der Klasse $=w gefunden werden, durch die genericstable verarbeitet werden. Dieses Rezept verarbeitet nur Hostnamen, die in den Wert aufgelöst werden, der durch $j zurückgegeben wird Die From-Adresse mit der genericstable umschreiben 149

168 Siehe auch Rezept 4.12 zeigt ein weiteres genericstable-beispiel. Rezept 4.14 demonstriert, wie die genericstable von einem LDAP-Server gelesen werden kann. Das Buch sendmail behandelt die genericstable in Abschnitt , das Makro GENERICS_DOMAIN in Abschnitt und das Makro GENERICS_DOMAIN_FILE in Abschnitt Kapitel 9 des Buches Linux Sendmail Administration von Craig Hunt (Sybex) enthält eine Anleitung im Abschnitt»Masquerading Usernames«, die zusätzliche Informationen bietet. Links 4.12 Absenderadressen für eine komplette Domain umschreiben Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es die Absenderadresse aller Mails, die aus der lokalen Domain stammen, in das Standardformat für Header-Absenderadressen umschreibt, das in Ihrer Einrichtung gebräuchlich ist. Lösung Erstellen Sie eine genericstable-datenbank, um die Eingangsadressen auf das Format abzubilden, das für die Header-Absenderadressen gewünscht wird. Jeder Eintrag in der genericstable enthält zwei Felder. Das erste Feld entspricht der Eingangsadresse, und das zweite Feld schreibt die Adresse um. Um die genericstable anzulegen, erzeugen Sie zuerst eine Textdatei, die die Datenbankeinträge enthält, anschließend schicken Sie die Textdatei durch den Befehl makemap, um die genericstable-datenbank zu erzeugen. Fügen Sie der sendmail-konfiguration die Funktion genericstable, das Makro GENERICS_ DOMAIN und die Funktion generics_entire_domain hinzu. Die hinzugefügten Befehle könnten etwa folgendermaßen aussehen: dnl Process login names through the genericstable FEATURE(`genericstable') dnl Load wrotethebook.com into G GENERICS_DOMAIN(`wrotethebook.com') dnl Interpret the value in G as a domain name FEATURE(`generics_entire_domain') Erstellen Sie die sendmail.cf, kopieren Sie sie nach /etc/mail, und starten Sie dann sendmail neu. Schauen Sie in Rezept 1.8, falls Sie ein Beispiel für diese Schritte benötigen. Diskussion Die Eingangsabsenderadresse wird so umgeschrieben, wie es die genericstable angibt. Die komplette Eingangsadresse oder Teile davon werden als Schlüssel verwendet, um die 150 Kapitel 4: Masquerading

169 Rechts genericstable zu durchsuchen. Wenn ein Wert durch die Suche zurückgegeben wird, dann wird dieser Wert verwendet, um die Adresse umzuschreiben. Für dieses Beispiel legen wir folgende genericstable an: # cd /etc/mail # cat > genericstable kathy kathy.mccafferty@wrotethebook.com craig craig.hunt@wrotethebook.com sara sara.henson@wrotethebook.com dave david.craig@wrotethebook.com becky rebecca.fro@wrotethebook.com jay jay.james@wrotethebook.com alana@blur.wrotethebook.com alana.darling@wrotethebook.com alana@giant.wrotethebook.com alana.henson@wrotethebook.com alana alana.smiley@wrotethebook.com Ctrl-D # makemap hash genericstable < genericstable Die Funktion genericstable fügt den Code hinzu, den sendmail benötigt, um die genericstable nutzen zu können. Das Makro GENERICS_DOMAIN fügt den Wert, der auf der Kommandozeile des Makros angegeben ist, zur sendmail-klasse $=G hinzu. Normalerweise werden die Werte, die in der Klasse $=G aufgeführt sind, als Hostnamen interpretiert. Nur exakte Treffer aktivieren die genericstable-verarbeitung. Die Funktion generics_entire_domain veranlasst sendmail, die Werte in der Klasse $=G als Domainnamen zu interpretieren. Jeder Host innerhalb einer dieser Domains wird durch die genericstable verarbeitet. Hier folgt ein Test eines Systems, das dieses Rezept einsetzt: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $=G wrotethebook.com > /tryflags HS > /try esmtp dave@tassajara.wrotethebook.com Trying header sender address dave@tassajara.wrotethebook.com for mailer esmtp canonify input: tassajara. wrotethebook. com Canonify2 input: dave tassajara. wrotethebook. com > Canonify2 returns: dave tassajara. wrotethebook. com. > canonify returns: dave tassajara. wrotethebook. com. > 1 input: dave tassajara. wrotethebook. com. > 1 returns: dave tassajara. wrotethebook. com. > HdrFromSMTP input: dave tassajara. wrotethebook. com. > PseudoToReal input: dave tassajara. wrotethebook. com. > PseudoToReal returns: dave tassajara. wrotethebook. com. > MasqSMTP input: dave tassajara. wrotethebook. com. > MasqSMTP returns: dave tassajara. wrotethebook. com. > MasqHdr input: dave tassajara. wrotethebook. com. > canonify input: david. wrotethebook. com Canonify2 input: david. craig wrotethebook. com > Canonify2 returns: david. craig wrotethebook. com. > canonify returns: david. craig wrotethebook. com. > MasqHdr returns: david. craig wrotethebook. com. > 4.12 Absenderadressen für eine komplette Domain umschreiben 151

170 HdrFromSMTP returns: david. craig wrotethebook. com. > final input: david. craig wrotethebook. com. > final returns: david. wrotethebook. com Rcode = 0, addr = david.craig@wrotethebook.com > /map generics dave map_lookup: generics (dave) returns david.craig@wrotethebook.com (0) > /quit Der Test zeigt, dass sich der Hostname tassajara.wrotethebook.com nicht in der Klasse $=G befindet; um genau zu sein, enthält die Klasse $=G nur den Domainnamen wrotethebook.com. Dennoch wird die Header-Absenderadresse dave@tassajara. wrotethebook.com zu david.craig@wrotethebook.com umgeschrieben, wobei es sich um den Wert handelt, den die genericstable für den Schlüssel dave zurückliefert. In diesem Beispiel gehört jeder Zugang namens dave in der gesamten Domain wrotethebook.com zu David Craig. Unabhängig davon, von welchem Host in dieser Domain er Mail absendet, wird diese Mail zu david.craig@wrotethebook.com umgeschrieben, sobald sie dieses System passiert. Damit Antworten an die umgeschriebene Adresse richtig funktionieren, muss der umgeschriebene Hostname zu einem Host aufgelöst werden, der die Mail akzeptiert. Außerdem muss dieser Host einen Alias für david. craig haben, der die Mail an den wirklichen Zugang dave ausliefert. Ein interessanterer Fall ist die Zuordnung des Benutzernamens alana. Drei Leute in der Domain wrotethebook.com verwenden diesen Benutzernamen: Alana Darling, Alana Henson und Alana Smiley. Der folgende Test zeigt, wie diese Namen jeweils zugeordnet werden: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /tryflags HS > /try esmtp alana@blur.wrotethebook.com Trying header sender address alana@blur.wrotethebook.com for mailer esmtp canonify input: blur. wrotethebook. com Canonify2 input: alana blur. wrotethebook. com > Canonify2 returns: alana blur. wrotethebook. com. > canonify returns: alana blur. wrotethebook. com. > 1 input: alana blur. wrotethebook. com. > 1 returns: alana blur. wrotethebook. com. > HdrFromSMTP input: alana blur. wrotethebook. com. > PseudoToReal input: alana blur. wrotethebook. com. > PseudoToReal returns: alana blur. wrotethebook. com. > MasqSMTP input: alana blur. wrotethebook. com. > MasqSMTP returns: alana blur. wrotethebook. com. > MasqHdr input: alana blur. wrotethebook. com. > canonify input: alana. wrotethebook. com Canonify2 input: alana. darling wrotethebook. com > Canonify2 returns: alana. darling wrotethebook. com. > canonify returns: alana. darling wrotethebook. com. > MasqHdr returns: alana. darling wrotethebook. com. > HdrFromSMTP returns: alana. darling wrotethebook. com. > Links 152 Kapitel 4: Masquerading

171 Rechts final input: alana. darling wrotethebook. com. > final returns: alana. wrotethebook. com Rcode = 0, addr = alana.darling@wrotethebook.com > /try esmtp alana@giant.wrotethebook.com Trying header sender address alana@giant.wrotethebook.com for mailer esmtp canonify input: giant. wrotethebook. com Canonify2 input: alana giant. wrotethebook. com > Canonify2 returns: alana giant. wrotethebook. com. > canonify returns: alana giant. wrotethebook. com. > 1 input: alana giant. wrotethebook. com. > 1 returns: alana giant. wrotethebook. com. > HdrFromSMTP input: alana giant. wrotethebook. com. > PseudoToReal input: alana giant. wrotethebook. com. > PseudoToReal returns: alana giant. wrotethebook. com. > MasqSMTP input: alana giant. wrotethebook. com. > MasqSMTP returns: alana giant. wrotethebook. com. > MasqHdr input: alana giant. wrotethebook. com. > canonify input: alana. wrotethebook. com Canonify2 input: alana. henson wrotethebook. com > Canonify2 returns: alana. henson wrotethebook. com. > canonify returns: alana. henson wrotethebook. com. > MasqHdr returns: alana. henson wrotethebook. com. > HdrFromSMTP returns: alana. henson wrotethebook. com. > final input: alana. henson wrotethebook. com. > final returns: alana. wrotethebook. com Rcode = 0, addr = alana.henson@wrotethebook.com > /try esmtp alana@anywhere.wrotethebook.com Trying header sender address alana@anywhere.wrotethebook.com for mailer esmtp canonify input: anywhere. wrotethebook. com Canonify2 input: alana anywhere. wrotethebook. com > Canonify2 returns: alana anywhere. wrotethebook. com. > canonify returns: alana anywhere. wrotethebook. com. > 1 input: alana anywhere. wrotethebook. com. > 1 returns: alana anywhere. wrotethebook. com. > HdrFromSMTP input: alana anywhere. wrotethebook. com. > PseudoToReal input: alana anywhere. wrotethebook. com. > PseudoToReal returns: alana anywhere. wrotethebook. com. > MasqSMTP input: alana anywhere. wrotethebook. com. > MasqSMTP returns: alana anywhere. wrotethebook. com. > MasqHdr input: alana anywhere. wrotethebook. com. > canonify input: alana. wrotethebook. com Canonify2 input: alana. smiley wrotethebook. com > Canonify2 returns: alana. smiley wrotethebook. com. > canonify returns: alana. smiley wrotethebook. com. > MasqHdr returns: alana. smiley wrotethebook. com. > HdrFromSMTP returns: alana. smiley wrotethebook. com. > final input: alana. smiley wrotethebook. com. > final returns: alana. wrotethebook. com Rcode = 0, addr = alana.smiley@wrotethebook.com > /quit 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 4.12 Absenderadressen für eine komplette Domain umschreiben 153

172 für diese Adressen vorzunehmen. Der Schlüssel, der für den Eintrag von Alana Smiley zum Einsatz kommt, ist jedoch nur ein Benutzername. Dieser Schlüssel entspricht jeder Eingangsadresse, die den Benutzernamen alana enthält, mit Ausnahme der Eingangsadressen und Wenn ein System Mail verarbeitet, die von mehreren Hosts stammt, besteht die Möglichkeit, dass doppelte Login-Namen auftreten. Die Tatsache, dass der Schlüssel in der genericstable eine vollständige -Adresse enthalten kann, erlaubt es Ihnen, diese sich überschneidenden Benutzernamen zuzuordnen. Links Siehe auch Rezept 4.11 liefert ein weiteres genericstable-beispiel. Rezept 4.14 zeigt, wie die genericstable von einem LDAP-Server gelesen werden kann. Das Buch sendmail behandelt die genericstable in Abschnitt , das Makro GENERICS_DOMAIN in Abschnitt und die Funktion generics_entire_domain in Abschnitt Kapitel 9 des Buches Linux Sendmail Administration von Craig Hunt (Sybex) enthält im Abschnitt»Masquerading Usernames«eine Anleitung, die zusätzliche Informationen liefert Masquerading und LDAP Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es die Daten, die das Masquerading steuern, von einem LDAP-Server liest. Lösung Fügen Sie auf dem LDAP-Server die Datei sendmail.schema zur LDAP-Konfiguration hinzu, wie in Rezept 1.3 beschrieben. Fügen Sie auf dem LDAP-Server die Masquerading-Konfigurationsdaten in die LDAP- Datenbank ein. Legen Sie dazu eine LDIF-Datei an, die die Liste der maskierten Domains enthält, sowie eine LDIF-Datei, die die Liste der offen gezeigten Benutzer enthält. Die Objektklasse der Daten in beiden Dateien muss sendmailmtaclass sein, die in der Datei sendmail.schema definiert ist. Verwenden Sie ldapadd, um diese Daten in die LDAP- Datenbank einzufügen. Prüfen Sie die sendmail-compiler-optionen auf dem sendmail-host. Falls sendmail LDAPMAP nicht unter den»compiled with:«-flags aufführt, kompilieren und installieren Sie sendmail neu, wie in Rezept 1.3 beschrieben. Erzeugen Sie auf dem sendmail-host eine Konfiguration, die die Dateien MASQUERADE_ DOMAIN_FILE und EXPOSED_USER vom LDAP-Server liest. Setzen Sie confldap_cluster so, dass es dem Attribut sendmailmtacluster entspricht, das in den Records benutzt wird, die 154 Kapitel 4: Masquerading

173 Rechts der LDAP-Datenbank hinzugefügt werden. Hier ist ein Beispiel für die Zeilen, die zur sendmail-konfiguration hinzugefügt werden: dnl Masquerade the From address as wrotethebook.com MASQUERADE_AS(`wrotethebook.com') dnl Define the LDAP cluster to which this host belongs define(`confldap_cluster', `wrotethebook.com')dnl dnl Use LDAP to read usernames that are not masqueraded dnl Get the list of masqueraded hostnames from LDAP Erstellen Sie die neue sendmail.cf-datei, und kopieren Sie diese nach /etc/mail. Starten Sie sendmail neu. In Rezept 1.8 finden Sie Beispiele. Diskussion Dieses Rezept geht davon aus, dass Sie einen voll funktionstüchtigen LDAP-Server haben, der um die sendmail-masquerading-informationen erweitert werden kann. Falls Sie Hilfe zum Thema LDAP benötigen, schauen Sie in die Bücher Understanding and Deploying LDAP Directory Services von Howes, Smith und Good (Macmillan) sowie LDAP System Administration von Gerald Carter (O Reilly). Bringen Sie den LDAP-Server an den Start, und kümmern Sie sich um eventuell auftretende Fehler, bevor Sie dieses Rezept ausprobieren. Nachdem Sie sichergestellt haben, dass der LDAP-Server sendmail unterstützt, fügen Sie die Masquerading-Daten zur LDAP-Datenbank hinzu. Dieses Beispiel legt ein Record für die Hostnamen an, die in die Klasse $=M geladen werden: # cat > ldap-masquerade-domains dn: sendmailmtaclassname=m, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtaclass sendmailmtacluster: wrotethebook.com sendmailmtaclassname: M sendmailmtaclassvalue: rodent.wrotethebook.com sendmailmtaclassvalue: horseshoe.wrotethebook.com sendmailmtaclassvalue: jamis.wrotethebook.com Ctrl-D # ldapadd -x -D "cn=manager,dc=wrotethebook,dc=com" \ > -W -f ldap-masquerade-domains Enter LDAP Password: SecretLDAPpassword adding new entry "sendmailmtaclassname=m, dc=wrotethebook, dc=com" Dieses Beispiel fügt eine Liste der offen gezeigten Benutzer in die LDAP-Datenbank ein: # cat > ldap-exposed-users dn: sendmailmtaclassname=e, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtaclass sendmailmtacluster: wrotethebook.com sendmailmtaclassname: E 4.13 Masquerading und LDAP 155

174 sendmailmtaclassvalue: root Ctrl-D # ldapadd -x -D "cn=manager,dc=wrotethebook,dc=com" \ > -W -f ldap-exposed-users Enter LDAP Password: SecretLDAPpassword adding new entry "sendmailmtaclassname=e, dc=wrotethebook, dc=com" Diese Beispiele zeigen das LDAP-Format, das für sendmail-klassendaten zum Einsatz kommt. Die Klasse, für die das LDAP-Record gilt, wird durch das Attribut sendmailmtaclassname festgelegt. Die Werte, die in die angegebene Klasse geladen werden sollen, werden mit Hilfe eines oder mehrerer sendmailmtaclassvalue-attribute in dem LDAP-Record definiert. In den Beispielen enthält das Record für Klasse $=M drei Werte und das Record für Klasse $=E einen Wert. Wandeln Sie die LDIF-Daten in das LDAP- Format um, und fügen Sie sie mit dem Befehl ldapadd in die LDAP-Datenbank ein. 7 Benutzen Sie den Befehl ldapsearch, um die neuen Daten zu untersuchen: 8 Links # ldapsearch -LLL -x '(sendmailmtaclassname=m)' sendmailmtaclassvalue dn: sendmailmtaclassname=m, dc=wrotethebook, dc=com sendmailmtaclassvalue: rodent.wrotethebook.com sendmailmtaclassvalue: horseshoe.wrotethebook.com sendmailmtaclassvalue: jamis.wrotethebook.com # ldapsearch -LLL -x '(sendmailmtaclassname=e)' sendmailmtaclassvalue dn: sendmailmtaclassname=e, dc=wrotethebook, dc=com sendmailmtaclassvalue: root LDAP ist fertig. Konfigurieren Sie nun sendmail so, dass es LDAP nach den Maskierungsdaten fragt. Dazu soll es den anstelle des Dateipfades in den Makros MASQUERADE_DOMAIN_FILE und EXPOSED_USER_FILE verwenden. angegeben ist, dann fragt sendmail LDAP mit Hilfe des Standard-sendmail-Schemas nach den erforderlichen Daten. Dieses Rezept definiert auch einen Wert für confldap_cluster. sendmail-ldap-records gelten entweder für einen einzelnen Host oder für eine Gruppe von Hosts, einen so genannten Cluster. Ein Cluster ist analog einer NIS-Domain es handelt sich um eine Gruppe von Hosts, die die gleichen LDAP-Daten verwenden. Der Name des Clusters wird in der sendmail-konfiguration mit der Variablen confldap_cluster und in den LDAP-Records mit dem Attribut sendmailmtacluster definiert. Gelten die LDAP-Records für einen einzelnen Host, dann wird der Host in den LDAP-Records durch das Attribut sendmailmtahost identifiziert, es ist aber keine besondere sendmail-konfiguration erforderlich, da der Hostnamenwert, der durch $j zurückgeliefert wird, für die LDAP-Abfrage zum Einsatz kommt. Beachten Sie Folgendes: Wird die Variable confldap_cluster für einen Host konfiguriert, der auch host-spezifische LDAP-Daten enthält, dann werden sowohl die Host- als auch die Cluster-Daten zurückgeliefert, wenn dieser Host eine 7 Alle LDAP-Beispiele in diesem Buch gehen davon aus, dass OpenLDAP benutzt wird. Passen Sie die Befehle entsprechend an Ihr eigenes System an. 8 Falls ldapsearch die Werte -h und -b verlangt, nutzen Sie confldap_default_spec, um die gleichen Werte für sendmail einzustellen, wie in Rezept 5.9 beschrieben. 156 Kapitel 4: Masquerading

175 Rechts LDAP-Anfrage auslöst. Dieses Rezept definiert einen Cluster-Namen in der sendmail- Konfiguration und benutzt nur Cluster-Daten in der LDAP-Datenbank. Ein einfacher Test zeigt die Wirkung dieses Rezepts: # sendmail -bt Cgeneric-linux.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $=M > $=E > /quit # sendmail -bt -Csendmail.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $=M rodent.wrotethebook.com jamis.wrotethebook.com horseshoe.wrotethebook.com > $=E root > /quit Ein sendmail -bt-test mit der generischen Konfiguration zeigt, dass die Klassen $=M und $=E standardmäßig leer sind. Wenn der Test erneut ausgeführt wird, dieses Mal jedoch mit der in diesem Rezept angelegten Datei sendmail.cf, dann enthalten die Klassen $=M und $=E die Daten, die in der LDAP-Datenbank definiert sind. MASQUERADE_DOMAIN_FILE und EXPOSE_USER_FILE sind nicht die einzigen Dateien, die vom LDAP gelesen werden können. Die Datei MASQUERADE_EXCEPTION_FILE, die in Rezept 4.9 benutzt wird, kann ebenfalls von einem LDAP-Server gelesen werden, indem der Pfadname in dem Makrobefehl durch den ersetzt wird. Tatsächlich kann jede Datei, die in eine Klasse geladen wird, vom LDAP gelesen werden. Außerdem können sendmail-datenbanken vom LDAP gelesen werden, wie das nächste Rezept mit der genericstable zeigt. Da Klassen während des Starts geladen werden, müssen Sie sendmail immer dann neu starten, wenn Sie LDAP-Records hinzufügen, ändern oder löschen, die sendmail-klassen beeinflussen. Die Änderungen werden erst nach einem Neustart von sendmail wirksam. Siehe auch Rezept 4.6 erläutert die Rolle, die die Klasse $=M beim Masquerading spielt. Rezept 4.2 erklärt, weshalb die Klasse $=E gebraucht wird. Rezept 3.9 ist ein weiteres Rezept, das LDAP verwendet, um eine Klasse zu laden, wodurch sich ein tieferer Einblick in den Gebrauch von LDAP ergibt. Das Buch sendmail behandelt das Makro MASQUERADE_ DOMAIN_FILE in Abschnitt 4.4.4, das Makro EXPOSE_USER_FILE in Abschnitt und die Definition confldap_cluster in Abschnitt Die Datei cf/readme behandelt LDAP im Abschnitt Using LDAP for Aliases, Maps, and Classes Masquerading und LDAP 157

176 4.14 Die genericstable über LDAP einlesen Links Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es die genericstable von einem LDAP-Server liest. Lösung Erweitern Sie die LDAP-Konfiguration auf dem LDAP-Server um eine Unterstützung für die Datei sendmail.schema, wie in Rezept 1.3 beschrieben. Fügen Sie auf dem LDAP-Server die genericstable-daten in die LDAP-Datenbank ein. Dazu legen Sie zuerst eine LDIF-Datei an und führen dann ldapadd aus. Nutzen Sie die Objektklasse sendmailmtamap, die in der Datei sendmail.schema definiert ist, um die genericstable-daten in der LDIF-Datei zu formatieren. Sie können auf dem LDAP-Server auch eine LDIF-Datei erzeugen, die die generischen Domaindaten für die Klasse $=G enthält. Die Daten sollten mit Hilfe der Objektklasse sendmailmtaclass formatiert werden, die in der Datei sendmail.schema definiert ist. Nutzen Sie ldapadd, um die Daten aus der LDIF-Datei in die LDAP-Datenbank einzufügen. Prüfen Sie auf dem sendmail-system, ob sendmail LDAP-Unterstützung bietet. Falls der Befehl sendmail -bt -d0.1 nicht den String LDAPMAP in der»compiled with:«-liste anzeigt, dann kompilieren und installieren Sie sendmail neu, wie in Rezept 1.3 beschrieben. Fügen Sie auf dem sendmail-system ein genericstable-feature-makro hinzu, das die genericstable vom LDAP-Server in die sendmail-konfiguration lädt. Verwenden Sie das Makro GENERICS_DOMAIN_FILE, um die Klasse $=G vom LDAP-Server zu laden. Stellen Sie die Definition confldap_cluster so ein, dass sie dem Attribut sendmailmtacluster entspricht, das in den genericstable-einträgen verwendet wird, die der LDAP-Datenbank hinzugefügt wurden. Hier sind die Beispielzeilen, die Sie einer sendmail-konfiguration hinzufügen könnten, um die genericstable von einem LDAP-Server zu lesen: dnl Define the sendmailmtacluster value define(`confldap_cluster', `wrotethebook.com') dnl Load the genericstable from the LDAP server FEATURE(`genericstable', `LDAP') dnl Load class $=G from the LDAP server Folgen Sie dem Beispiel in Rezept 1.8, um die Datei sendmail.cf zu erstellen und zu installieren und anschließend sendmail neu zu starten. 158 Kapitel 4: Masquerading

177 Rechts Diskussion Dieses Rezept nutzt einen LDAP-Server, um die Konfiguration zu duplizieren, die in Rezept 4.11 benutzt wird. Weshalb und wie die genericstable eingesetzt wird, wird in Rezept 4.11 behandelt. Dieses Rezept konzentriert sich darauf, wie die genericstable- Daten auf einem LDAP-Server gespeichert und von ihm bezogen werden. Die Daten werden zuerst in eine LDIF-Datei eingegeben. Jeder Dateneintrag wird auf eine Weise formatiert, die mit dem sendmail-schema kompatibel ist. Das LDAP-Record- Format, das für die genericstable zum Einsatz kommt, kann für jede sendmail-datenbank verwendet werden. Dazu kommen einfach der Datenbankname in das Attribut sendmailmtamapname, die richtigen Schlüsseldaten in das Attribut sendmailmtakey und der korrekte Rückgabewert in das Attribut sendmailmtamapvalue. Hier ist ein Beispiel mit den Einträgen dave, becky und alana aus der genericstable, die in Rezept 4.11 beschrieben wurde. # cat > ldap-generics dn: sendmailmtamapname=generics, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtamap sendmailmtacluster: wrotethebook.com sendmailmtamapname: generics dn: sendmailmtakey=dave, sendmailmtamapname=generics, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtamap objectclass: sendmailmtamapobject sendmailmtamapname: generics sendmailmtacluster: wrotethebook.com sendmailmtakey: dave sendmailmtamapvalue: david.craig@wrotethebook.com dn: sendmailmtakey=becky, sendmailmtamapname=generics, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtamap objectclass: sendmailmtamapobject sendmailmtamapname: generics sendmailmtacluster: wrotethebook.com sendmailmtakey: becky sendmailmtamapvalue: rebecca.fro@wrotethebook.com dn: sendmailmtakey=alana, sendmailmtamapname=generics, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtamap objectclass: sendmailmtamapobject sendmailmtamapname: generics sendmailmtacluster: wrotethebook.com sendmailmtakey: alana sendmailmtamapvalue: alana.smiley@wrotethebook.com Ctrl-D 4.14 Die genericstable über LDAP einlesen 159

178 # ldapadd -x -D "cn=manager,dc=wrotethebook,dc=com" \ > -W -f ldap-generics Enter LDAP Password: SecretLDAPpassword adding new entry "sendmailmtamapname=generics, dc=wrotethebook, dc=com" Links adding new entry "sendmailmtakey=dave, sendmailmtamapname=generics, dc=wrotethebook, dc=com" adding new entry "sendmailmtakey=becky, sendmailmtamapname=generics, dc=wrotethebook, dc=com" adding new entry "sendmailmtakey=alana, sendmailmtamapname=generics, dc=wrotethebook, dc=com" Beachten Sie, dass vier Einträge benutzt werden, um die ersten drei genericstable-werte in die LDAP-Datenbank einzugeben. Der erste Eintrag definiert den genericstable-datenbanknamen, der generics lautet. Sobald der Datenbankname LDAP bekannt ist, können Daten mit diesem Namen verknüpft werden. Die nächsten drei Einträge enthalten die eigentlichen genericstable-daten. Die sendmail-konfiguration in diesem Rezept verwendet ebenfalls LDAP, um die Klasse $=G zu laden. Das folgende Beispiel fügt einen Eintrag aus der Klasse $=G in die LDAP- Datenbank ein, der ein sendmailmtaclassvalue-attribut enthält, das dem Wert GENERICS_ DOMAIN entspricht, der in Rezept 4.11 benutzt wird: # cat > ldap-generics-domain dn: sendmailmtaclassname=g, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtaclass sendmailmtahost: chef.wrotethebook.com sendmailmtaclassname: G sendmailmtaclassvalue: chef.wrotethebook.com Ctrl-D # ldapadd -x -D "cn=manager,dc=wrotethebook,dc=com" \ > -W -f ldap-generics-domain Enter LDAP Password: SecretLDAPpassword adding new entry "sendmailmtaclassname=g, dc=wrotethebook, dc=com" Auch hier werden die Daten zuerst in eine LDIF-Datei eingegeben und dann mit Hilfe des Befehls ldapadd in der LDAP-Datenbank abgelegt. Das Attribut sendmailmtaclassname identifiziert die Klasse, zu der die Daten gehören. Die einzelnen Werte für die Klasse $=G werden durch die sendmailmtaclassvalue-attribute im LDAP-Record definiert. Im Beispiel wird nur ein sendmailmtaclassvalue verwendet, allerdings kann ein einzelnes sendmailmtaclassname-record mehrere Werte aufnehmen. Der Befehl ldapsearch kann verwendet werden, um die Ergebnisse zu untersuchen: # ldapsearch -LLL -x '(sendmailmtamapname=generics)' sendmailmtamapvalue dn: sendmailmtamapname=generics, dc=wrotethebook, dc=com dn: sendmailmtakey=dave, sendmailmtamapname=generics, dc=wrotethebook, dc=com sendmailmtamapvalue: david.craig@wrotethebook.com 160 Kapitel 4: Masquerading

179 Rechts dn: sendmailmtakey=becky, sendmailmtamapname=generics, dc=wrotethebook, dc=com sendmailmtamapvalue: dn: sendmailmtakey=alana, sendmailmtamapname=generics, dc=wrotethebook, dc=com sendmailmtamapvalue: # ldapsearch -LLL -x '(sendmailmtaclassname=g)' sendmailmtaclassvalue dn: sendmailmtaclassname=g, dc=wrotethebook, dc=com sendmailmtaclassvalue: chef.wrotethebook.com Drei Änderungen wurden an der sendmail-konfiguration aus Rezept 4.11 durchgeführt, um eine Konfiguration zu erzeugen, die die genericstable-daten aus LDAP liest: Die Definition confldap_cluster wurde der Konfiguration hinzugefügt, um das sendmail.cf-makro ${sendmailmtacluster} auf den gleichen Wert zu setzen wie das Attribut sendmailmtacluster, das in den genericstable-ldap-records verwendet wird. Dies stellt sicher, dass sendmail die richtigen Daten vom LDAP-Server bezieht. Falls die Definition confldap_cluster nicht benutzt wird, bezieht sendmail nur LDAP-Records, bei denen das sendmailmtahost-attribut auf den voll qualifizierten Hostnamen des sendmail-hosts gesetzt ist. In diesem Beispiel benutzt das LDAP- Record der Klasse $=G das Attribut sendmailmtahost. Es würde also von einem Host namens chef.wrotethebook.com geholt werden können, selbst wenn confldap_ CLUSTER nicht in der sendmail-konfiguration dieses Hosts definiert wäre. Das Makro GENERICS_DOMAIN, das in Rezept 4.11 verwendet wurde, wurde in diesem Rezept in ein GENERICS_DOMAIN_FILE-Makro geändert. Der im Makro GENERICS_DOMAIN_FILE weist sendmail an, die Klasse $=G mit Daten zu laden, die vom LDAP-Server bezogen wurden. (Traditionell handelt es sich bei dem Wert, der an das Makro GENERICS_DOMAIN_FILE übergeben wird, um den Pfadnamen einer lokalen Datei, die die Daten für die Klasse $=G enthält.) Der String LDAP wurde dem genericstable-befehl FEATURE hinzugefügt. Der LDAP-String weist sendmail an, die genericstable-daten unter Verwendung des Standard-sendmail-Schemas vom LDAP-Server zu lesen. Durch das Hinzufügen des LDAP-Strings zum genericstable-befehl FEATURE ändert sich das Format des sendmail.cf-befehls K, der die generics-datenbank definiert. Ein grep zeigt die Wirkung des LDAP-Strings: # grep 'Kgenerics' recipe4-10.cf Kgenerics hash /etc/mail/genericstable # grep '^Kgenerics' sendmail.cf Kgenerics ldap -1 -v sendmailmtamapvalue -k (&(objectclass=sendmailmtamapobject)( (sendmailmtacluster=${sendmailmtacluster}) (sendmailmtahost=$j))(sendmailmtamapname=generics)(sendmailmtakey=%0)) Das erste grep zeigt das vorgegebene Format des K-Befehls, der verwendet wird, um die generics-datenbank zu deklarieren, wenn mit dem genericstable-befehl FEATURE keine Argumente angegeben werden. Standardmäßig sucht sendmail nach einer Hash-Datenbank in der lokalen Datei /etc/mail/genericstable. Durch das Hinzufügen des LDAP-Argu Die genericstable über LDAP einlesen 161

180 ments zum genericstable-befehl FEATURE ändert sich der Datenbanktyp zu ldap, der K-Befehl erhält außerdem noch einige LDAP-spezifische Optionen. Die Option -v legt das LDAP-Attribut fest, das als Rückgabewert verwendet wird. Die Option -k definiert die LDAP-Suchkriterien, die als Datenbankschlüssel zum Einsatz kommen. Alle Attributnamen in dem oben gezeigten K-Befehl sind Attribute, die im sendmail- Schema definiert wurden. Falls Sie Ihr eigenes Schema definieren, können Sie nicht einfach den LDAP-String in dem genericstable-befehl FEATURE verwenden. Sie müssen stattdessen die Optionen -v und -k manuell definieren, die Ihr eigenes Schema angeben. Zum Beispiel: FEATURE(`genericstable', `ldap: -1 k (&(objectclass=localuserobject) (LocalUserKey=%0)) v LocalUser Address') Selbstverständlich handelt es sich bei den Attributnamen in diesen Beispielen um imaginäre Namen, die Sie durch die entsprechenden Attribute ersetzen müssten, wenn Sie Ihr eigenes Schema anlegen. Das Format des genericstable-befehls FEATURE ähnelt jedoch dem Befehl, den Sie in Ihrer sendmail-konfiguration benutzen würden. Beachten Sie, dass der K-Befehl, der durch Hinzufügen des Arguments LDAP zur Funktion genericstable erzeugt wurde, nicht den LDAP-Servernamen oder den vorgegebenen LDAP- Basis-Distinguished-Name enthält. Der Server und die Basis können dem Befehl K mit den gleichen -h- und -b-argumenten hinzugefügt werden, die Sie beim Befehl ldapsearch einsetzen würden. In der sendmail-konfiguration werden die Argumente -h und -b mit Hilfe von confldap_default_spec definiert; ein Beispiel finden Sie in Rezept 5.9. Es ist jedoch nicht nötig, confldap_default_spec zu verwenden, wenn die Werte HOST und BASE in der ldap.conf-datei für sendmail korrekt sind. Nachdem dieses Rezept installiert ist, können genericstable-daten genau so vom LDAP gelesen werden, als würden sie aus der lokalen Datenbank stammen, wie der folgende Test demonstriert: # rm f /etc/mail/genericstable* # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /map generics alana map_lookup: generics (alana) returns alana.smiley@wrotethebook.com (0) > /quit Der Befehl rm beweist, dass der Test keine genericstable-daten aus einer lokalen Datei liest. Der Befehl /map übergibt den Schlüssel alana an die generics-datenbank und erhält den Rückgabewert alana.smiley@wrotethebook.com. Der Befehl /map in diesem Beispiel ist genauso formatiert wie in Rezept 4.11, als die Daten aus einer lokalen Datenbank gelesen wurden. Der einzige Unterschied besteht darin, dass hier die Daten von einem LDAP-Server gelesen werden. Der Test, der in Rezept 4.11 verwendet wurde, um die Wirkung der Klasse $=G zu beurteilen, kann erneut ausgeführt werden, wenn dieses Rezept installiert ist. Auch hier funktioniert er genauso, nur dass die Daten von einem LDAP-Server kommen: Links 162 Kapitel 4: Masquerading

181 Rechts # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $=G chef.wrotethebook.com > /tryflags HS > /try esmtp alana@[ ] Trying header sender address alana@[ ] for mailer esmtp canonify input: [ ] Canonify2 input: alana [ ] > Canonify2 returns: alana rodent. wrotethebook. com. > canonify returns: alana rodent. wrotethebook. com. > 1 input: alana rodent. wrotethebook. com. > 1 returns: alana rodent. wrotethebook. com. > HdrFromSMTP input: alana rodent. wrotethebook. com. > PseudoToReal input: alana rodent. wrotethebook. com. > PseudoToReal returns: alana rodent. wrotethebook. com. > MasqSMTP input: alana rodent. wrotethebook. com. > MasqSMTP returns: alana rodent. wrotethebook. com. > MasqHdr input: alana rodent. wrotethebook. com. > canonify input: alana. wrotethebook. com Canonify2 input: alana. smiley wrotethebook. com > Canonify2 returns: alana. smiley wrotethebook. com. > canonify returns: alana. smiley wrotethebook. com. > MasqHdr returns: alana. smiley wrotethebook. com. > HdrFromSMTP returns: alana. smiley wrotethebook. com. > final input: alana. smiley wrotethebook. com. > final returns: alana. wrotethebook. com Rcode = 0, addr = alana.smiley@wrotethebook.com > /quit Die Daten für beliebige sendmail-datenbanken und sendmail-klassen können zentral über einen LDAP-Server definiert werden. sendmail behandelt die Daten gleich, ungeachtet der Quelle. Siehe auch Rezept 4.11 erklärt, wie die genericstable verwendet wird, und erläutert die Wichtigkeit der Klasse $=G. Kapitel 5 liefert zusätzliche Beispiele für den Einsatz von LDAP für sendmail- Datenbanken. Das Buch sendmail behandelt das Makro GENERICS_DOMAIN_FILE in Abschnitt , die genericstable in Abschnitt und die Definition confldap_cluster in Abschnitt Die Datei cf/readme behandelt LDAP im Abschnitt Using LDAP for Aliases, Maps, and Classes Die genericstable über LDAP einlesen 163

182 FirstLeft. Kapitel 5 KAPITEL 5 Mail-Routing 5.0 Einführung sendmail ist ein Mail-Router. Mail von externen Hosts wird an lokale Benutzer geleitet (»geroutet«). Mail von lokalen Benutzern wird in die Außenwelt geroutet. Mail vom Mail-Programm des Benutzers wird zur Auslieferung an den richtigen Mailer geroutet. Tatsächlich sind alle Funktionen, die bisher in diesem Buch behandelt wurden Auslieferung, Weiterleitung, Vermittlung und Masquerading, Teil der Arbeit, die sendmail als Mail-Router erledigt. Die Rollen, die die aliases-datenbank und die.forward-datei beim Routen von Mail von einem Benutzerzugang zu einem anderen spielen, und die die Vermittlung beim Routen von Mail von einem Host zu einem anderen spielt, sind ganz offensichtlich Komponenten des Mail-Routings. Selbst das Masquerading, das sicherstellt, dass Antworten auf Mail, die von Ihrem System stammt, an das richtige System geroutet werden, ist ein Aspekt des Routings. Doch wenn nun alle Rezepte, die wir bisher diskutiert haben, etwas mit Mail-Routing zu tun haben, dann stellt sich die Frage, weshalb es auch noch ein eigenes Kapitel mit dem Begriff Routing im Titel gibt? Der Grund ist, dass sich dieses Kapitel voll und ganz auf sendmail-funktionen konzentriert, die eine verstärkte Kontrolle des Mail-Routings bieten. sendmail routet Mail anhand ihrer Auslieferungsadresse an interne Mailer. Wenn sendmail eine Auslieferungsadresse verarbeitet, dann liefert es ein Mail-Auslieferungstriple zurück, das den zu verwendenden Mailer, den Host, an den die Mail gesandt werden soll, und die Empfängeradresse des Benutzers identifiziert, an den die Mail gerichtet ist. Das Ergebnis dieses Vorgangs sehen Sie bei einem sendmail -bv-test: # sendmail -bv james@big.wrotethebook.net james@big.wrotethebook.net... deliverable: mailer esmtp, host big.wrotethebook.net, user james@big.wrotethebook.net 164 Kapitel 5: Mail-Routing

183 Rechts Der Mailer, der zum Versenden der Mail verwendet wird, der Host, an den sie gesandt wird, und die Empfängeradresse, die in dieser Mail zum Einsatz kommt, sind in diesem einfachen Test gut zu erkennen. Die Verarbeitung einer Auslieferungsadresse zu einem Mail-Auslieferungstriple ist ein fundamentaler Bestandteil dessen, was sendmail tut, und legt fest, wie Mail für die Auslieferung geroutet wird. Die mailertable Die mailertable-datenbank gibt Ihnen die direkte Kontrolle über diesen Prozess, indem sie Ihnen festzulegen erlaubt, welcher Mailer benutzt wird und an welchen entfernten Host anhand des Hostnamenanteils der Auslieferungsadresse die Mail gesendet wird. Jeder mailertable-eintrag enthält zwei Felder: einen Schlüssel, der mit dem Hostnamenanteil der Auslieferungsadresse verglichen wird, und einen Rückgabewert, der die Mailerund Hostwerte für das Mail-Auslieferungstriple enthält. Der Schlüssel zu einem mailertable-datenbankeintrag ist ein vollständiger oder teilweiser Domainname. Ein teilweiser Domainnamenschlüssel beginnt mit einem Punkt (.). Beispielsweise ist jamis.wrotethebook.com ein vollständiger Domainnamenschlüssel, und.wrotethebook.com ist ein teilweiser Domainnamenschlüssel. Um einem vollständigen Domainnamenschlüssel zu entsprechen, muss der gesamte Hostnamenanteil der Auslieferungsadresse zu dem Schlüssel passen. Falls etwa der Schlüssel crab.wrotethebook.com ist, dann entspricht nur eine Auslieferungsadresse namens dem Schlüssel. Ein teilweiser Domainnamenschlüssel stimmt mit jeder Auslieferungsadresse überein, die mit dem Schlüsselwert endet. Lautet zum Beispiel der Schlüssel.wrotethebook.com, dann passt jede Auslieferungsadresse der Form zu dem Schlüssel. Ein besonderer Schlüssel, der aus einem einzelnen Punkt (.) besteht, entspricht jedem möglichen Hostnamen. Der Rückgabewert in einem mailertable-eintrag ist der interne Name des Mailers, durch den die Mail geroutet werden soll, sowie der Hostname des entfernten Mail-Hosts, an den die Mail gesandt werden soll. Er wird in der Form mailer:host geschrieben. Das mailer-feld muss immer einen gültigen internen sendmail-mailernamen enthalten (z. B. esmtp, local, error usw.). Das host-feld ist flexibler, weil sein Inhalt dadurch festgelegt wird, was der angegebene Mailer im Host-Anteil eines Mail-Auslieferungstriples erwartet. Das host-feld enthält oft den Hostnamen eines entfernten Hosts. Im Fall des Mailers error jedoch enthält das host-feld die Fehlermeldung; beim local-mailer steht in ihm ein Benutzername. Die Rezepte in diesem Kapitel liefern Beispiele für die verschiedenen host-feld-formate. Ein einfacher mailertable-eintrag sieht etwa folgendermaßen aus: big.wrotethebook.net smtp:mail.wrotethebook.com Die Wirkung dieses mailertable-eintrags ist leicht zu erkennen: # sendmail -bv james@big.wrotethebook.net james@big.wrotethebook.net... deliverable: mailer smtp, host mail.wrotethebook.com, user james@big.wrotethebook.net Einführung 165

184 sendmail verwendet hier nicht länger den vorgegebenen esmtp-mailer oder routet Mail durch diesen Mailer an das entfernte System big.wrotethebook.net. Stattdessen benutzt es das Routing, das in der mailertable angegeben wurde; in diesem Fall wird Mail, die an big.wrotethebook.net adressiert ist, durch den Mailer smtp an mail.wrotethebook.com geroutet. Im obigen Test wurden nur die Mailer- und Hostwerte geändert, wie in der mailertable festgelegt. Manchmal wird jedoch auch die Empfängeradresse im Benutzerfeld umgeschrieben. Das Festlegen des Mailers ist eine Methode, wie die mailertable die Art und Weise beeinflusst, in der die Empfängeradresse verarbeitet wird. Der Parameter R in jeder Mailer-Definition gibt die Regelsätze an, die auf die Empfängeradresse angewendet werden. Alle mailertable-einträge beeinflussen indirekt die Empfängeradresse durch den Parameter R des Mailers. Die mailertable kann die Empfängeradresse auch direkt im Benutzerwert des Mail-Auslieferungstriples kontrollieren, wie unten beschrieben wird. Das host-feld eines mailertable-eintrags kann einen Benutzernamen enthalten. Das ist üblich, wenn der Eintrag Mail durch den Mailer local routet: info.wrotethebook.com local:pat Mit diesem Eintrag wird Mail mit einer Empfängeradresse benutzer@info.wrotethebook. com an pat auf dem lokalen Host ausgeliefert. In diesem Fall kann benutzer ein beliebiger Benutzername sein er muss nicht wirklich auf einem System existieren. Eine andere Datenbank, die virtusertable, kann Mail für Hosts routen, die nicht als separate physische Computer existieren. Die Datei cf/readme nennt dies virtuelle Domains; die Unterstützung dafür wird in sendmail als virtuelles Hosting bezeichnet. Die virtusertable sendmail bietet über die Funktion virtusertable Unterstützung für virtuelles Hosting. Die virtusertable ermöglicht das Hosting mehrerer virtueller Mail-Domains auf einer Maschine, ähnlich den virtuellen Hosts, die auf Apache-Servern im Gebrauch sind. Auf die gleiche Weise, wie ein einzelner Webserver Webseiten für viele virtuelle Hosts vorhalten kann, kann sendmail den Mail-Dienst für viele virtuelle Mail-Domains bereitstellen. Einträge in der virtusertable haben zwei Felder: einen Schlüssel und eine -Adresse. Der Schlüssel enthält den Wert, der mit der Eingangsauslieferungsadresse verglichen wird. Bei dem Schlüssel kann es sich um eine vollständige Adresse der Form benutzer@domain oder um eine teilweise Adresse der handeln. Wenn das verwendet wird, dann wird Mail an einen beliebigen Benutzer in der angegebenen Domain an die Mail-Adresse geroutet, die im zweiten Feld enthalten ist. Im zweiten Feld steht die Adresse, an die die Mail wirklich ausgeliefert wird. Es gibt nur zwei Ausnahmen von der Benutzung einer einfachen -Adresse im zweiten Feld: Das zweite Feld könnte eine Fehlermeldung enthalten. Die Fehlermeldung beginnt mit dem Schlüsselwort error, das durch einen Doppelpunkt von einem Fehlercode- Links 166 Kapitel 5: Mail-Routing

185 Rechts Schlüsselwort getrennt ist. Darauf folgt der Text der Meldung. Tabelle 5-1 enthält eine Liste der Fehlercode-Schlüsselwörter von sendmail. Eine -Adresse im zweiten Feld kann Variablen enthalten. Diese Variablen werden durch Werte aus der Eingangsadresse ersetzt, die an die ausgehende Adresse übergeben werden. Der Benutzernamenanteil der Eingangsadresse wird an die Variable %1 übergeben, und der Wert detail in der +detail-syntax wird an die Variable %2 übergeben. Wenn die Variable %2 im zweiten Feld benutzt wird, dann setzen Sie +* vor im ersten Feld des virtusertable-eintrags, um anzuzeigen, dass die +detail-syntax zum Einsatz kommt. Ein Beispiel dafür, wie +* zusammen mit %2 benutzt wird, finden Sie in der letzten Zeile der Beispiel-virtusertable-Einträge, die im Folgenden zu sehen sind. Diese Beispiel-virtusertable-Einträge zeigen die möglichen Formate der beiden Felder: sales@example.com jill info@wrotethebook.org david@new-business.ora.com sales@chll.ora.com error:nouser User address is not %1@blur.wrotethebook.com +*@thatplace.ora.com %2@newplace.ora.com Die ersten drei Beispieleinträge zeigen einfache virtuelle Domains und Auslieferungsadressen. Mail, die an sales@example.com adressiert ist, wird an den Zugang jill auf dem lokalen Host ausgeliefert. Anfragen, die an info@wrotethebook.org geschickt werden, werden an sara@crab.wrotethebook.com weitergeleitet. Mail an einen beliebigen Benutzernamen in der Domain wrotethebook.net wird an david@new-business.ora.com geroutet. Mail wird mit der Adresse einer virtuellen Domain akzeptiert und an eine echte - Adresse geroutet. Der vierte Beispieleintrag illustriert die Formatierung von Fehlermeldungen. Mail, die an sales@chll.ora.com adressiert ist, wird nicht ausgeliefert. Stattdessen wird eine Fehlermeldung an den Absender zurückgeliefert, die besagt, dass die Benutzeradresse ungültig ist (»User address is not valid«). Der Fehlercode wird im oben gezeigten Beispiel durch das Schlüsselwort nouser gekennzeichnet. Bei dem Schlüsselwort muss es sich um eines der gültigen Schlüsselwörter aus Tabelle 5-1 handeln. Tabelle 5-1: Fehlercode-Schlüsselwörter Schlüsselwort config nohost nouser protocol tempfail unavailable usage Bedeutung Ein Konfigurationsfehler oder eine Routing-Schleife wurden entdeckt. Der Host-Anteil der Absender- oder Empfängeradresse ist ungültig. Der Benutzeranteil der Absender- oder Empfängeradresse ist ungültig. Die Auslieferung im Netzwerk ist fehlgeschlagen. Ein temporärer Fehler wurde entdeckt. Eine Ressource zur Auslieferung steht nicht zur Verfügung. Die Syntax der Auslieferungsadresse ist falsch. Einführung 167

186 Die letzten beiden Einträge sind Beispiele dafür, wie Werte aus der Eingangsadresse in der ausgehenden Adresse verwendet werden. Im wird der Benutzernamenanteil der Eingangsadresse an die Variable %1 übergeben und in der ausgehenden Adresse benutzt. Daher wird Mail, die an adressiert ist, an geroutet, und Mail, die an wrotethebook.org gerichtet ist, wird an gesandt. Der letzte Eintrag übergibt den Wert detail aus der +detail-syntax, der in der Eingangsadresse verwendet wird, als %2 an die ausgehende Adresse. Mit dem gerade gezeigten virtusertable-eintrag wird Mail, die an gesandt wird, an ausgeliefert. Mail an würde an ausgeliefert werden. sendmail muss so konfiguriert werden, dass es Mail akzeptiert, die an virtuelle Domains adressiert ist, die in der virtusertable-datenbank stehen. Bei der gerade gezeigten virtusertable muss sendmail entweder example.com, wrotethebook.org, wrotethebook.net, chll.ora.com, other.wrotethebook.org und thatplace.ora.com als Aliase für den lokalen Host akzeptieren oder sie als virtuelle Domains erkennen. Eine Lösung besteht darin, Hostnamen-Aliase für alle virtuellen Domains anzulegen. sendmail akzeptiert alle Namen, die in der Klasse $=w enthalten sind, als Alias für den lokalen Host. Rezept 2.1 zeigt, wie die Klasse $=w über die Datei local-host-names geladen wird. Wenn die Funktion use_cw_file in der Konfiguration enthalten ist, werden durch das Auflisten der virtuellen Domains in der Datei local-host-names diese in die Klasse $=w geladen und sendmail wird angewiesen, Mail für diese Domains zu akzeptieren. Es ist jedoch nicht erforderlich, eine virtuelle Domain in einen Hostnamen-Alias umzuwandeln, damit die virtusertable funktioniert. Eine Alternative wäre, den Namen der virtuellen Domain in der Klasse $={VirtHost} zu speichern. Fügen Sie die Namen der virtuellen Domains nacheinander der Klasse $={VirtHost} hinzu. Dazu verwenden Sie das Makro VIRTUSER_DOMAIN. Oder Sie laden die Klasse $={VirtHost} mit dem Makro VIRTUSER_DOMAIN_FILE aus einer Datei. Immer wenn Sie virtuelle Domains zu der Datei hinzufügen, müssen Sie sendmail mit einem SIGHUP-Signal neu starten, um sicherzustellen, dass es die neuen Werte in die Klasse $={VirtHost} lädt. Bevor sendmail die mailertable oder die virtusertable benutzen kann, muss die Textdatei, in der die Datenbankeinträge enthalten sind, mit Hilfe von makemap in eine Datenbank umgewandelt werden. Legen Sie den Datenbanktyp und den Namen der Datenbank auf der makemap-kommandozeile fest: # makemap hash /etc/mail/mailertable < /etc/mail/mailertable Standardmäßig definieren die sendmail.cf-k-befehle für diese Datenbanken sowohl mailertable als auch virtusertable als Hash-Datenbanken. Der vorgegebene Dateiname für die mailertable lautet /etc/mail/mailertable, der vorgegebene Dateiname für die virtusertable-datenbank ist /etc/mail/virtusertable. Die vorgegebenen Dateinamen und Datenbanktypen können in der sendmail-konfiguration mit Hilfe der optionalen Felder Links 168 Kapitel 5: Mail-Routing

187 Rechts im Makro FEATURE überschrieben werden. Beispielsweise könnte eine sendmail-konfiguration, die die Standardwerte für die mailertable verwendet und die vorgegebenen Werte für virtusertable überschrieben hat, folgende FEATURE-Makros enthalten: FEATURE(`mailertable') FEATURE(`virtusertable', `dbm /etc/virtual-mail-domains') Das Ändern des vorgegebenen Datenbankdateinamens ist nicht zu empfehlen. Die ganze Dokumentation, die mit der sendmail-distribution geliefert wird, verweist auf /etc/mail/ mailertable und /etc/mail/virtusertable als Orte, an denen sich diese Dateien befinden. Durch das Ändern des Dateinamens bieten sich Ihnen keine wirklichen Vorteile. Außerdem wird es für andere Systemadministratoren schwieriger, die Dateien zu finden, falls Wartungsarbeiten dies erforderlich machen. Falls Sie außerdem den vorgegebenen Datenbanktyp überschreiben, müssen Sie sicherstellen, dass Ihr sendmail-programm mit der passenden Unterstützung für die andere Datenbank kompiliert wurde. LDAP-Routing sendmail kann Mail-Routing-Informationen von einem LDAP-Server beziehen. Dazu kann es die mailertable und die virtusertable vom LDAP-Server lesen alle sendmail- Datenbanken können über LDAP gelesen werden. Rezept 5.5 zeigt, wie die mailertable von einem LDAP-Server gelesen wird, und in Rezept 5.8 sehen Sie, wie die virtusertable über LDAP gelesen wird. Darüber hinaus unterstützt sendmail das IETF Internet Draft LDAP Schema for Intranet Mail Routing. Das IETF-Draft-Schema definiert die Objektklasse inetlocalmailrecipient. Attribute dieser Objektklasse sind: maillocaladdress Dieses Attribut enthält eine -Adresse, die den Schlüssel zur LDAP-Datenbank darstellt. sendmail sucht nach Records, in denen das Attribut maillocaladdress der Empfängeradresse entspricht, die sendmail verarbeitet. Jedes inetlocalmailrecipient- Objektklassen-Record enthält ein maillocaladdress-attribut. mailhost Dieses Attribut enthält den Hostnamen des Mail-Hosts, der die Mail-Adresse an den Empfänger verarbeitet, der durch das Attribut maillocaladdress identifiziert wird. Mail, die an diesen Empfänger adressiert ist, sollte zur Auslieferung an diesen Host geroutet werden. Das Attribut mailhost stellt einen möglichen Rückgabewert da, der sendmail als Antwort auf eine Abfrage bereitgestellt wird. mailroutingaddress Dieses Attribut enthält eine -Adresse. Mail, die an den Empfänger adressiert ist, der durch das Attribut maillocaladdress identifiziert wird, wird an die Adresse ausgeliefert, die durch das Attribut mailroutingaddress angegeben wird. Das Attribut mailroutingaddress stellt einen möglichen Rückgabewert da, der sendmail als Antwort auf eine Abfrage bereitgestellt wird. Einführung 169

188 Durch das Hinzufügen der Funktion ldap_routing zur sendmail-konfiguration wird sendmail veranlasst, LDAP nach Routing-Informationen abzufragen, wenn es eine Mail verarbeitet, die an einen Host aus der Klasse $={LDAPRoute} adressiert ist. Liefert die Abfrage einen mailhost-wert zurück, dann benutzt sendmail diesen als den $h-hostwert im Mail- Auslieferungstriple. Liefert die Abfrage einen mailroutingaddress-wert, dann benutzt sendmail diesen als den $u-benutzeradresswert im Mail-Auslieferungstriple. Die Rezepte 5.9 und 5.10 zeigen, wie Sie ldap_routing benutzen können und welche Wirkung diese Funktion auf das Mail-Auslieferungstriple hat. Die Mail-Routing-Informationen, die durch das IETF-Draft-Schema definiert werden, liefern keine Informationen, die nicht auch durch die traditionellen sendmail-datenbanken erbracht werden können. Das ist keine Überraschung, bedenkt man das breite Spektrum, das die sendmail-konfiguration abdeckt. Sites benutzen die Funktion ldap_routing, weil sie bereits einen LDAP-Server betreiben und weil sie feststellen, dass das IETF-Schema besser zu ihrer Datenbankarchitektur passt. Es handelt sich jedoch um ein Draft-Schema, das sich künftig ändern kann. Alles, was unter Benutzung eines Draft-Schemas implementiert wird, kann durch zukünftige Änderungen beeinflusst werden. Wägen Sie Ihre Möglichkeiten sorgfältig ab, bevor Sie das LDAP-Mail-Routing einsetzen. Links 5.1 Mail an Mailer für besondere Aufgaben routen Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es mit besonderen entfernten Systemen klarkommt, die keine normale Extended SMTP-Mail verarbeiten. Lösung Erstellen Sie eine mailertable-datenbank, mit der Mail, die an bestimmte entfernte Systeme gerichtet ist, durch die entsprechenden speziellen Mailer geroutet wird. Dazu legen Sie zuerst eine Textdatei an und verarbeiten diese Datei dann mit dem Skript makemap, um eine Hash-Datenbank zu erzeugen. Der Schlüssel für diese mailertable-einträge ist ein vollständiger oder teilweiser Domainname, der dem Hostnamenanteil der Empfängeradresse bei Mail entsprechen muss, die von einem speziellen Mailer verarbeitet werden soll. Der Rückgabewert ist der interne Name des speziellen Mailers, der durch einen Doppelpunkt vom Namen des entfernten Systems getrennt ist, das die Mail akzeptiert. Fügen Sie die Funktion mailertable der sendmail-konfiguration hinzu. Hier ist das erforderliche mailertable-makro FEATURE: dnl Add support for the mailertable FEATURE(`mailertable') Erstellen Sie die Datei sendmail.cf. Kopieren Sie sie nach /etc/mail, und starten Sie sendmail neu. Ein Beispiel finden Sie in Rezept Kapitel 5: Mail-Routing

189 Rechts Diskussion Eine einfache sendmail-konfiguration enthält MAILER-Makros, die local.m4 und smtp.m4 laden. Das lokale MAILER-Makro fügt die Mailer prog und local zur sendmail.cf-konfiguration hinzu. Das SMTP-Makro MAILER definiert fünf Mailer. Zwei, nämlich esmtp und relay, sind für die grundlegende Auslieferung von SMTP-Mail wichtig. Die drei anderen Mailer, die durch das SMTP-Makro MAILER definiert werden (smtp8, dsmtp und smtp), werden nicht durch ein Mail-Auslieferungstriple in der Datei sendmail.cf referenziert. Die beste Möglichkeit, diese nicht benutzten Mailer zu verwenden, besteht durch die mailertable. Nehmen Sie für dieses Beispiel an, dass Sie Mail an ein entferntes System senden müssen, das nicht in der Lage ist, mit binärer Mail oder der normalen Extended SMTP-Syntax umzugehen, sowie an andere Systeme, die zwar binäre Mail verarbeiten können, nicht jedoch die normale Extended SMTP-Syntax. Hier ist eine Beispiel-mailertable mit Einträgen für diese Systeme: # cd /etc/mail # cat > mailertable fakeu.edu smtp8:mail.fakeu.edu.falseu.edu smtp8:ms.falseu.edu.stateu.edu smtp:mail.stateu.edu new.stateu.edu esmtp:new.stateu.edu Ctrl-D # makemap hash mailertable < mailertable Die ersten beiden Beispiel-mailertable-Einträge verwenden den Mailer smtp8 einen besonderen SMTP-Mailer für den Einsatz mit einem entfernten Server, der zwar binäre Mail, nicht aber das Extended SMTP-Protokoll verarbeiten kann, das normalerweise mit binärer Mail verknüpft ist. Ein einfacher Test zeigt die Wirkung dieser mailertable-einträge: # sendmail -bv -Cgeneric-linux.cf jeff@fakeu.edu jeff@fakeu.edu... deliverable: mailer esmtp, host fakeu.edu., user jeff@fakeu.edu # sendmail -bv Cgeneric-linux.cf reba@foo.falseu.edu reba@foo.falseu.edu... deliverable: mailer esmtp, host foo.falseu.edu, user reba@foo. falseu.edu # sendmail -bv jeff@fakeu.edu jeff@fakeu.edu... deliverable: mailer smtp8, host mail.fakeu.edu, user jeff@fakeu.edu # sendmail -bv reba@foo.falseu.edu reba@foo.falseu.edu... deliverable: mailer smtp8, host ms.falseu.edu, user reba@foo. falseu.edu # sendmail -bv becky@falseu.edu becky@falseu.edu... deliverable: mailer esmtp, host falseu.edu, user becky@falseu.edu Die ersten beiden sendmail -bv-tests zeigen, wie eine einfache sendmail-konfiguration Mail an fakeu.edu und foo.falseu.edu routet. Wenn Sie diese Tests erneut ausführen, nachdem dieses Rezept abgeschlossen ist, sehen Sie den Einfluss der mailertable. Beachten Sie die letzten beiden Tests. Adressen der Form benutzer@host.falseu.edu passen auf den mailertable-eintrag.falseu.edu und werden so verarbeitet, wie durch diesen mailertable-eintrag vorgegeben. Mail, die an benutzer@falseu.edu adressiert ist, passt 5.1 Mail an Mailer für besondere Aufgaben routen 171

190 dagegen nicht und wird daher auch nicht durch die mailertable in diesem Beispiel verarbeitet. Der mailertable-eintrag.falseu.edu definiert einen teilweisen Domainnamen. Um das Routing sowohl für foo.falseu.edu als auch für falseu.edu zu kontrollieren, setzen Sie zwei Einträge in die mailertable einen für den vollständigen Domainnamen falseu.edu und einen für den teilweisen Domainnamen.falseu.edu. Die letzten beiden Einträge in der Beispiel-mailertable benutzen die Mailer smtp und esmtp. esmtp ist der Standard-Mailer für die meisten Internet-Mails. Der Mailer smtp implementiert die alte Version des SMTP-Protokolls, die existierte, bevor Extended SMTP geschaffen wurde. Der Mailer smtp wird nur benötigt, falls die entfernte Site Extended SMTP nicht ausführen kann. Das Interessante an diesen beiden Einträgen ist, dass sie einander überschneidende Referenzen auf die Domain stateu.edu enthalten:.stateu.edu new.stateu.edu smtp:mail.stateu.edu esmtp:new.stateu.edu Der erste Eintrag definiert einen teilweisen Domainnamen, der auf jeden eingegebenen Hostnamen passt, der auf.stateu.edu endet. Dies scheint im Konflikt zum zweiten Eintrag zu stehen. Der zweite Eintrag entspricht genau dem Hostnamen new.stateu.edu. Allerdings trifft new.stateu.edu auch auf den ersten Eintrag zu, weil er auf.stateu.edu endet. Welchen Eintrag verwendet sendmail nun, um die Mail zu routen, die an new. stateu.edu adressiert ist? In diesem Fall benutzt es den zweiten Eintrag, weil dieser Eintrag die beste Übereinstimmung bietet und der längste Treffer Vorrang genießt. Dieser Vorrang ist unabhängig von der Reihenfolge, in der die Einträge in der mailertable auftauchen der längste Treffer hat immer Vorrang. Diese zwei Zeilen zusammengenommen veranlassen sendmail, mail.stateu.edu als Hostwert für das Mail-Auslieferungstriple für alle Mails zu verwenden, die an die Domain stateu.edu adressiert sind, mit Ausnahme von new.stateu.edu. Hier wird new.stateu.edu als Host-Wert verwendet. new.stateu.edu ist ein modernes System, das normale Extended SMTP-Mail verarbeitet. Leider handelt es sich bei mail.stateu.edu um ein überholtes System, das nur mit dem veralteten SMTP- Protokoll klarkommt. Links Alternativen Eine Aufrüstung der Hardware und Software der Zielsysteme, um eine vollständige Unterstützung von esmtp zu erreichen, ist eine bessere Alternative, als die Benutzung von mailertable zum Routen von Mail durch besondere Mailer. Falls Sie die Kontrolle über ein Zielsystem haben, das einen Mailer wie smtp oder smtp8 verwenden muss, um mit der Außenwelt zu kommunizieren, dann ersetzen Sie es. Es ist nie gut, veraltete Technik einzusetzen. Selbstverständlich können Sie nicht immer über entfernte Systeme bestimmen. Bei diesen Gelegenheiten ist die mailertable ein effektives Mittel. Siehe auch Die Rezepte 5.2 und 5.3 beschreiben weitere mailertable-eigenschaften, die Sie möglicherweise in Ihre mailertable aufnehmen wollen. Rezept 5.4 liefert zusätzliche Informa- 172 Kapitel 5: Mail-Routing

191 Rechts tionen über das Umschreiben der Benutzeradresse über die mailertable. Das Buch sendmail behandelt die mailertable in Abschnitt Die Datei cf/readme enthält einen Abschnitt namens Using Mailertables. 5.2 Fehlermeldungen aus der mailertable senden Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es Mail, die an bestimmte Hosts und Domains gerichtet ist, mit einer Fehlermeldung abweist. Lösung Erzeugen Sie mailertable-einträge, bei denen Sie die Domainnamen, an die keine Mail ausgeliefert werden soll, als Schlüssel und die Fehlermeldungen, die beim Abweisen der Mail zurückgeliefert werden sollen, als Rückgabewerte verwenden. Verarbeiten Sie diese Datei mit makemap, um eine Hash-Datenbank zu erzeugen. Legen Sie eine sendmail-konfiguration an, die die Funktion mailertable enthält. Die folgenden Zeilen fügen einer sendmail-konfiguration die mailertable hinzu: dnl Add support for the mailertable FEATURE(`mailertable') Erstellen und installieren Sie die sendmail.cf, und starten Sie anschließend sendmail neu, wie in Rezept 1.8 beschrieben. Diskussion Der Mailer error ist in das sendmail-programm integriert. error liefert eine Fehlermeldung an den Absender einer Mail-Nachricht zurück. Ebenso wie andere Mailer kann error im Mailer-Feld eines mailertable-eintrags angegeben werden. Ist dies der Fall, dann enthält das Host-Feld des Eintrags die Fehlermeldung, den SMTP-Antwortcode und den DSN-Code (Delivery Status Notification). Die Syntax eines mailertable-eintrags für den Mailer error lautet: schlüssel error:d.s.n:code meldung Dabei ist schlüssel ein vollständiger oder teilweiser Domainname, error der Name des Mailers, D.S.N ein erweiterter Statuscode, der entweder als drei durch Punkte getrennte numerische Felder oder in Form eines SMTP-Fehlercodewortes definiert ist, 1 code ein numerischer SMTP-Antwortcode und meldung die Textmeldung, die an den Absender zurückgeliefert wird. D.S.N-Werte müssen den Spezifikationen aus RFC 1893, Enhanced 1 In Tabelle 5-1 finden Sie eine Liste der SMTP-Fehlercode-Schlüsselwörter. 5.2 Fehlermeldungen aus der mailertable senden 173

192 Mail System Status Codes, entsprechen. D gibt Auskunft über den Erfolg oder das Fehlschlagen, S identifiziert die Fehlerkategorie, und N liefert zusätzliche Details. RFC 1893 bezeichnet diese drei Werte als class, subject und detail und definiert sie folgendermaßen: class Liefert eine breite Klassifikation des Status. Im RFC werden für die Klasse drei Werte definiert: 2 bedeutet Erfolg, 4 bedeutet temporäres Fehlschlagen, und 5 bedeutet dauerhaftes Fehlschlagen. subject Klassifiziert die Fehlermeldungen als zu einer von acht Kategorien gehörig: 0 (Undefiniert) Die bestimmte Kategorie kann nicht ermittelt werden. 1 (Adressierung) Es wurde ein Problem mit der Adresse entdeckt. 2 (Mailbox) Es wurde ein Problem mit der Auslieferungsmailbox entdeckt. 3 (Mail-System) Das Zielsystem zur Mail-Auslieferung hat ein Problem. 4 (Netzwerk) Die Netzwerkinfrastruktur hat ein Problem. 5 (Protokoll) Es ist ein Protokollproblem aufgetreten. 6 (Inhalt) Der Inhalt der Nachricht verursachte einen Übersetzungsfehler. 7 (Sicherheit) Es wurde ein Sicherheitsproblem gemeldet. detail Liefert Einzelheiten zu dem speziellen Fehler. Der detail-wert ist nur im Kontext des subject-code von Bedeutung. Beispielsweise bezeichnet x.1.1 eine falsche Zielbenutzeradresse und x.1.2 eine falsche Zielhostadresse, während x.2.1 bedeutet, dass die Mailbox deaktiviert ist, und x.2.2, dass die Mailbox voll ist. In RFC 1893 finden Sie die Liste der detail-codes. Wir wollen einmal ein Beispiel eines mailertable-eintrags untersuchen: oldname.ora.com error:5.7.1:550 oldname.ora.com is out of service Der Test dieses Eintrags mit sendmail -bv zeigt, dass die mailertable in Betrieb ist und der Eintrag funktioniert. Die Rolle des SMTP-Codes oder des DSN-Codes wird jedoch nicht klar: # sendmail -bv richard@oldname.ora.com richard@oldname.ora.com... oldname.ora.com is out of service Links 174 Kapitel 5: Mail-Routing

193 Rechts Tatsächlich zeigt der -bv-test in diesem Fall nicht alle Werte im Mail-Auslieferungstriple. Stattdessen sehen Sie die gleichen Meldungen, die jeder sehen würde, der Mail an oldname.ora.com schickt. Um das vollständige Mail-Auslieferungstriple für den Mailer error zu erhalten, führen Sie sendmail mit der Option -bt aus und verwenden den Befehl /parse: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /parse richard@oldname.ora.com Cracked address = $g Parsing envelope recipient address canonify input: oldname. ora. com Canonify2 input: richard oldname. ora. com > Canonify2 returns: richard oldname. ora. com > canonify returns: richard oldname. ora. com > parse input: richard oldname. ora. com > Parse0 input: richard oldname. ora. com > Parse0 returns: richard oldname. ora. com > Parse1 input: richard oldname. ora. com > MailerToTriple input: < error : : 550 oldname. ora. com is out of service > richard oldname. ora. com > MailerToTriple returns: $# error $@ $: 550 oldname. ora. com is out of service Parse1 returns: $# error $@ $: 550 oldname. ora. com is out of service parse returns: $# error $@ $: 550 oldname. ora. com is out of service richard@oldname.ora.com... oldname.ora.com is out of service mailer *error*, host 5.7.1, user 550 oldname.ora.com is out of service > /quit Der Befehl /parse zeigt, dass der SMTP-Code oder der DSN-Code als Host-Wert im Mail-Auslieferungstriple verwendet wird und dass die Fehlermeldung als Benutzerwert erscheint. Wenn der DSN-Code als Host-Wert benutzt wird, dann erscheint der SMTP- Code als erster String des Benutzerwertes. Die Wirkung des Ganzen ist am besten in den Interaktionen des SMTP-Protokolls zu sehen. Ein einfacher telnet-test zeigt den wirklichen Einfluss dieses mailertable-eintrags: # telnet localhost smtp Trying Connected to localhost. Escape character is '^]'. 220 chef ESMTP Sendmail ; Mon, 4 Nov :32: HELO chef.wrotethebook.com 250 chef.wrotethebook.com Hello localhost.localdomain [ ], pleased to meet you MAIL From:<craig@chef.wrotethebook.com> craig@chef.wrotethebook.com... Sender ok RCPT To:<richard@oldname.ora.com> richard@oldname.ora.com... oldname.ora.com is out of service QUIT chef.wrotethebook.com closing connection Connection closed by foreign host. 5.2 Fehlermeldungen aus der mailertable senden 175

194 Der Befehl RCPT To: enthält eine Empfängeradresse, die dem Schlüssel im mailertable-eintrag oldname.ora.com entspricht. Beachten Sie die SMTP-Antwort auf diese Empfängeradresse. Wie alle SMTP-Antworten beginnt sie mit einem Antwortcode. Der Code lautet 550, das ist der Wert, den wir im mailertable-eintrag definiert haben. Das nächste Feld in der SMTP-Antwort ist der DSN-Code auch hierbei handelt es sich um den von uns in der mailertable definierten Wert. Darauf folgen die Empfängeradresse und die Fehlermeldung, die wir in der mailertable definiert haben. Es wird deutlich, dass der mailertable- Eintrag für oldname.ora.com alle Aspekte dieser Antwort bestimmt hat. Ich empfehle Ihnen, den DSN-Wert bei allen mailertable-einträgen für den Mailer error zu benutzen, da Sie auf diese Weise alle Aspekte der Fehlerantwort kontrollieren können. Links Siehe auch Die Rezepte 5.1, 5.3 und 5.4 beschreiben weitere mailertable-funktionen. Das Buch sendmail behandelt die mailertable in Abschnitt und den Mailer error in Abschnitt Die MX-Verarbeitung deaktivieren, um Schleifen zu vermeiden Problem Wenn die mailertable eines Hosts Mail zu einem Ziel routet, dessen MX-Records zurück auf den Host verweisen, dann kann eine Mail-Schleife auftreten. Lösung Durch das Deaktivieren der MX-Verarbeitung für den mailertable-eintrag kann diese Art der Mail-Schleife vermieden werden. Schließen Sie das Host-Feld des mailertable-eintrags in eckige Klammern ein, wenn das System, das im Host-Feld identifiziert wird, das sendmail-system als seinen Mail Exchanger benutzt. Die mailertable-[host]-syntax umgeht die Verarbeitung von MX-Records. Nach dem Anlegen der mailertable verarbeiten Sie die mailertable-textdatei mit dem Skript makemap, um eine Hash-Datenbank zu erzeugen. Nehmen Sie die Funktion mailertable mit folgenden Zeilen in die sendmail-konfiguration auf: dnl Add support for the mailertable FEATURE(`mailertable') Erstellen Sie die Datei sendmail.cf, kopieren Sie sie nach /etc/mail, und starten Sie sendmail neu, wie in Rezept 1.8 an einem Beispiel beschrieben wird. 176 Kapitel 5: Mail-Routing

195 Rechts Diskussion Normalerweise verarbeitet ein Mail Exchanger Mail, die durch MX-Records an ihn geroutet wird, mit Hilfe der grundlegenden Vermittlungs- und Weiterleitungsfunktionen von sendmail, wie in Kapitel 2 und Kapitel 3 besprochen wird. Bei solchen Gelegenheiten ist besondere Sorgfalt vonnöten, wenn ein Mail Exchanger seine Mail durch die mailertable verarbeitet, um Mail-Schleifen zu verhindern. Um dies zu verstehen, wollen wir uns einige Beispiel-mailertable-Einträge anschauen:.wrotethebook.net wrotethebook.net smtp:[mail.wrotethebook.net] smtp:[mail.wrotethebook.net] Die Domain wrotethebook.net wird durch die mailertable verarbeitet. Diese Domain kann nicht durch normale Weiterleitung oder Vermittlung bedient werden, weil diese Methoden den Mailer esmtp benutzen, der Host mail.wrotethebook.net Extended SMTP jedoch nicht versteht. Aus dem gleichen Grund verweisen MX-Records für die Domain wrotethebook.net nicht direkt auf mail.wrotethebook.net. Würden die MX-Records direkt auf mail.wrotethebook.net verweisen, dann würden entfernte Systeme versuchen, Mail mit dem Internet-Standardprotokoll Extended SMTP direkt dorthin zu senden, das jedoch von diesem System nicht unterstützt wird. Unser lokales System ist ein Mail-Gateway, das auf Grund seiner Konfiguration mit diesem Problem umgehen kann. Mail wird durch MX-Records an unseren lokalen Host gerichtet. Die mailertable auf dem lokalen Host wird so konfiguriert, dass sie Mail mit dem Mailer an mail.wrotethebook.net routet, den mail.wrotethebook.net unterstützt. Die beiden Beispiel-mailertable-Einträge für wrotethebook.net sehen fast genauso aus wie die mailertable-einträge, die in anderen Rezepten dieses Kapitels zum Einsatz kommen. Der Hauptunterschied besteht in der Benutzung der [host]-syntax. Diese Syntax verhindert, dass sendmail beim Ausliefern von Mail nach MX-Records sucht, wie durch die mailertable angewiesen. Ohne diese Syntax prüft sendmail das MX-Record und folgt dessen Anweisungen, wenn es die endgültige Auslieferung ausführt. In diesem Fall würde das Befolgen des MX-Records eine Schleife verursachen, weil das MX-Record direkt zurück auf den lokalen Host verweist. Durch die [host]-syntax wird das MX-Record umgangen und die Schleife vermieden. Die Beispiel-mailertable-Einträge verweisen auf die gleiche Domain: Ein Eintrag ist ein teilweiser Domainname, und der andere Eintrag ist ein vollständiger Domainname. Der Eintrag für den vollständigen Domainnamen wird verwendet, um Mail abzufangen, die an benutzer@domain adressiert ist, falls es ein MX-Record für die gesamte Domain gibt. Der Eintrag für den teilweisen Domainnamen erfasst für Hosts, die eigene MX-Records haben, Mail, die an benutzer@host.domain adressiert ist. Die Empfängeradresse pat@wrotethebook.net entspricht diesem mailertable-eintrag: wrotethebook.net smtp:[mail.wrotethebook.net] Und die Adresse pat@sales.wrotethebook.net entspricht diesem Eintrag:.wrotethebook.net smtp:[mail.wrotethebook.net] 5.3 Die MX-Verarbeitung deaktivieren, um Schleifen zu vermeiden 177

196 Keiner der Einträge ist für sich selbst ausreichend, um beide Adressformate zu erfassen. Beide mailertable-einträge werden benötigt, falls beide Arten von MX-Records existieren. Da der sendmail-administrator unter Umständen nicht die Kontrolle über das genaue Format der MX-Records besitzt, die in der DNS-Zonendatei abgelegt werden, ist es am sichersten, beide Einträge in die mailertable aufzunehmen. Links Siehe auch Die Rezepte 5.1, 5.2 und 5.4 beschreiben zusätzliche mailertable-funktionen. Das Buch sendmail behandelt die mailertable in Abschnitt Mail für die lokale Auslieferung routen Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es Mail, die an ausgewählte Hostnamen adressiert ist, an bestimmte lokale Benutzerzugänge routet. Lösung Erzeugen Sie mailertable-einträge, die Mail durch den Mailer local an lokale Benutzerzugänge routen. Verarbeiten Sie die mailertable-textdatei mit makemap, um eine Hash- Datenbank zu erhalten. Legen Sie eine sendmail-konfiguration an, die die Funktion mailertable enthält. Hier ist ein Beispiel-FEATURE-Makro: dnl Add support for the mailertable FEATURE(`mailertable') Erstellen Sie die Datei sendmail.cf neu, und installieren Sie sie. Starten Sie anschließend sendmail neu, wie in Rezept 1.8 beschrieben. Diskussion Der Mailer local liefert Mail an Benutzer auf dem lokalen Host aus. Aus diesem Grund benötigt er nicht den Namen eines entfernten Hosts für den Host-Wert des Mail-Auslieferungstriples. Auch das Host-Feld eines mailertable-eintrags für den local-mailer enthält keinen Namen eines entfernten Hosts. Stattdessen ist dieses Feld entweder leer oder enthält einen lokalen Benutzernamen. Wenn das Host-Feld leer ist, dann wird der Benutzername aus der Eingangsadresse verwendet. Mail wird an den lokalen Benutzerzugang dieses Namens ausgeliefert. Enthält das Host-Feld dagegen einen Benutzernamen, wird die Mail an diesen lokalen Benutzer ausgeliefert. Hier sind drei mailertable-einträge für den Mailer local zwei mit einem Benutzernamen und einer ohne: 178 Kapitel 5: Mail-Routing

197 Rechts support.wrotethebook.com sales.wrotethebook.com info.wrotethebook.com local:admin local: local:pat Es besteht kein Bedarf an physischen Computern namens sales, support oder info, und wahrscheinlich gibt es auch gar keine Computer dieses Namens. Stattdessen sind diese Namen mit MX-Records in der DNS-Zonendatei verknüpft, die auf den Mail Exchanger verweisen, und die mailertable-einträge auf dem Mail Exchanger liefern die Mail an lokale Benutzerzugänge aus. Einige Tests zeigen, wie diese Einträge das Mail-Routing beeinflussen. Zuerst ein Test des Eintrags info.wrotethebook.com: # sendmail -bv logan@info.wrotethebook.com logan@info.wrotethebook.com... deliverable: mailer local, host logan@info.wrotethebook. com, user pat Dieser Test zeigt, wie Mail verarbeitet wird, die an logan@info.wrotethebook.com adressiert ist. Der Hostnamenanteil dieser Eingangsadresse entspricht dem Schlüssel eines der mailertable-einträge. Der Einfluss der mailertable-verarbeitung ist in den Mailer- und Benutzerwerten zu sehen, die durch den sendmail -bv-test angezeigt werden. 2 Die Mail wird über den Mailer local an den lokalen Benutzerzugang pat ausgeliefert, weil pat im Host-Feld des mailertable-eintrags info.wrotethebook.com angegeben ist. Mail an einen anderen Benutzer in info.wrotethebook.com wird an den lokalen Zugang pat ausgeliefert. Ein zweiter Test zeigt, wie weit der local-mailer-prozess Sie bringen kann: # sendmail -bv alana@support.wrotethebook.com anna@crab.wrotethebook.com... deliverable: mailer esmtp, host crab.wrotethebook.com., user anna@crab.wrotethebook.com andy@rodent.wrotethebook.com... deliverable: mailer esmtp, host rodent.wrotethebook.com., user andy@rodent.wrotethebook.com jane@rodent.wrotethebook.com... deliverable: mailer esmtp, host rodent.wrotethebook.com., user jane@rodent.wrotethebook.com In diesem Test ist die Mail an alana@support.wrotethebook.com adressiert. Wenn Sie sich den mailertable-eintrag für support.wrotethebook.com anschauen, könnten Sie vermuten, dass der -bv-test local als Mailer-Wert und admin als Benutzerwert anzeigt. Stattdessen wird Mail, die an alana@support.wrotethebook.com adressiert ist, über den Mailer esmtp an drei unterschiedliche Benutzer ausgeliefert, die sich auf externen Systemen befinden. Der Grund dafür ist, dass es sich bei admin um eine Mailingliste handelt, die in der aliases-datenbank definiert ist. (Mailinglisten und die aliases-datenbank werden in Kapitel 2 besprochen.) Die mailertable bildet nicht unbedingt das Ende des Auslieferungsvorgangs. Die Auflösung von Aliasen betrifft die meisten mailertable-einträge, die auf den Mailer local verweisen, da dieser üblicherweise mit dem Mailer-Schalter F=A konfiguriert ist. 2 sendmail übergibt dem Mailer local die ursprüngliche Auslieferungsadresse als Host-Wert für das Mail-Auslieferungstriple. 5.4 Mail für die lokale Auslieferung routen 179

198 Schließlich testen wir den Eintrag sales.wrotethebook.com, der im Rückgabefeld keinen lokalen Benutzernamen bereitstellt: # sendmail -bv logan@sales.wrotethebook.com logan@sales.wrotethebook.com... deliverable: mailer local, host logan@sales.wrotethebook. com, user logan In diesem Test ist Mail an logan@sales.wrotethebook.com adressiert. Der mailertable-eintrag weist sendmail an, den Mailer local zu verwenden, um die Mail auszuliefern, stellt aber keinen lokalen Benutzernamen für diese Auslieferung bereit. sendmail verwendet den Benutzernamen aus der Eingangsadresse, der in diesem Fall logan lautet. Mail, die an einen Benutzer in sales.wrotethebook.com adressiert ist, wird demzufolge an einen gleichnamigen Benutzerzugang auf dem lokalen Host ausgeliefert. Links Alternativen Benutzen Sie die virtusertable als Alternative zu mailertable-einträgen für den local-mailer, die einen Benutzernamen enthalten. Wenn im mailertable-eintrag kein Benutzername angegeben ist, dann verwenden Sie die Datei local-host-names als Alternative zur mailertable, um Mail an den Mailer local zu routen. Das Setzen des Hostnamens sales. wrotethebook.com in die Datei local-host-names liefert Ihnen das gleiche Ergebnis wie der oben gezeigte mailertable-eintrag. Dieser Test mit der Konfiguration aus Rezept 2.1 verdeutlicht, dass die Datei local-host-names eine gute alternative Lösung darstellt: # cat >> /etc/mail/local-host-names sales.wrotethebook.com # sendmail -bv -Crecipe2-1.cf logan@sales.wrotethebook.com logan@sales.wrotethebook.com... deliverable: mailer local, user logan Siehe auch Die Rezepte 5.1 bis 5.3 beschreiben zusätzliche mailertable-eigenschaften. Die Rezepte 5.6 und 5.7 beschreiben die virtusertable. Sie sollten sich diese Rezepte als Alternative anschauen, bevor Sie dieses Rezept umsetzen. Rezept 2.7 behandelt die aliases-datenbank und Mailinglisten. Das Buch sendmail behandelt die mailertable in Abschnitt Die Datei cf/readme beschreibt die Syntax der mailertable-einträge für den local- Mailer. 5.5 Die mailertable über LDAP lesen Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es die mailertable von einem LDAP-Server liest. 180 Kapitel 5: Mail-Routing

199 Rechts Lösung Fügen Sie der LDAP-Konfiguration auf dem LDAP-Server Unterstützung für die Datei sendmail.schema hinzu. Rezept 1.3 zeigt an einem Beispiel, wie Sie dies auf einem Server mit OpenLDAP erledigen. Legen Sie auf dem LDAP-Server eine LDIF-Datei an, die die mailertable-daten enthält, die entsprechend der sendmail-schema-objektklasse sendmailmtamap formatiert sind. Fügen Sie die mailertable-daten mit Hilfe von ldapadd der LDAP-Datenbank hinzu. Führen Sie auf dem sendmail-host den Befehl sendmail -bt -d0.1 aus, um zu prüfen, ob der String LDAPMAP in der»compiled with:«-liste vorkommt. Ist er vorhanden, dann enthält sendmail LDAP-Unterstützung und ist bereit. Fehlt der String in der Liste, dann kompilieren und installieren Sie sendmail neu, wie in Rezept 1.3 beschrieben. Erzeugen Sie eine sendmail-konfiguration, die die Funktion mailertable enthält. Fügen Sie dem mailertable-befehl FEATURE den String LDAP hinzu, um sendmail anzuweisen, die mailertable von einem LDAP-Server zu lesen. Setzen Sie die Definition confldap_cluster auf den gleichen Wert, der auch für das Attribut sendmailmtacluster in den mailertable- Records verwendet wird. Hier sind Beispielkonfigurationszeilen: dnl Set the LDAP cluster value define(`confldap_cluster', `wrotethebook.com') dnl Read the mailertable via LDAP FEATURE(`mailertable', `LDAP') Erstellen Sie die Datei sendmail.cf, kopieren Sie sie nach /etc/mail, und starten Sie sendmail neu. Rezept 1.8 zeigt dies an einem Beispiel. Diskussion Die mailertable-daten werden zuerst in eine LDIF-Datei eingegeben. Dieses Beispiel fügt ein mailertable-record aus jeder der Datenbanken aus den Rezepten 5.1 und 5.2 hinzu, so dass wir ingesamt zwei Daten-Records erhalten: # cat > ldap-mailer dn: sendmailmtamapname=mailer, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtamap sendmailmtacluster: wrotethebook.com sendmailmtamapname: mailer dn: sendmailmtakey=fakeu.edu, sendmailmtamapname=mailer, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtamap objectclass: sendmailmtamapobject sendmailmtamapname: mailer sendmailmtacluster: wrotethebook.com sendmailmtakey: fakeu.edu sendmailmtamapvalue: smtp8:mail.fakeu.edu 5.5 Die mailertable über LDAP lesen 181

200 dn: sendmailmtakey=oldname.ora.com, sendmailmtamapname=mailer, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtamap objectclass: sendmailmtamapobject sendmailmtamapname: mailer sendmailmtacluster: wrotethebook.com sendmailmtakey: oldname.ora.com sendmailmtamapvalue: error:5.7.1:550 oldname.ora.com is out of service Ctrl-D # ldapadd -x -D "cn=manager,dc=wrotethebook,dc=com" \ > -W -f ldap-mailer Enter LDAP Password: SecretLDAPpassword adding new entry "sendmailmtamapname=mailer, dc=wrotethebook, dc=com" Links adding new entry "sendmailmtakey=fakeu.edu, sendmailmtamapname=mailer, dc=wrotethebook, dc=com" adding new entry "sendmailmtakey=oldname.ora.com, sendmailmtamapname=mailer, dc=wrotethebook, dc=com" Jedes LDAP-mailertable-Record ist entsprechend dem sendmail-schema formatiert. Der interne sendmail.cf-datenbankname für die mailertable, der mailer lautet, wird durch das erste LDAP-Record dem Attribut sendmailmtamapname zugewiesen. Nachdem der Datenbankname definiert wurde, können mit diesem Datenbanknamen Daten verknüpft werden. Die nächsten beiden LDAP-Records enthalten die eigentlichen mailertable-daten. Beide Records definieren mit Hilfe des Attributs sendmailmtakey einen mailertable- Schlüssel und mit Hilfe des Attributs sendmailmtamapvalue den Rückgabewert, der mit diesem Schlüssel assoziiert ist. Das bedeutet, der mailertable-eintrag fakeu.edu smtp8:mail.fakeu.edu aus Rezept 5.1 wird zu folgendem LDAP-Record: dn: sendmailmtakey=fakeu.edu, sendmailmtamapname=mailer, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtamap objectclass: sendmailmtamapobject sendmailmtamapname: mailer sendmailmtacluster: wrotethebook.com sendmailmtakey: fakeu.edu sendmailmtamapvalue: smtp8:mail.fakeu.edu Nach dem Ausführen des Befehls ldapadd, mit dem Sie die LDIF-Daten in die LDAP- Datenbank einfügen, können Sie mit ldapsearch die Ergebnisse untersuchen: 3 # ldapsearch -LLL -x '(sendmailmtamapname=mailer)' sendmailmtamapvalue dn: sendmailmtamapname=mailer, dc=wrotethebook, dc=com dn: sendmailmtakey=fakeu.edu, sendmailmtamapname=mailer, dc=wrotethebook, dc=com sendmailmtamapvalue: smtp8:mail.fakeu.edu dn: sendmailmtakey=oldname.ora.com, sendmailmtamapname=mailer, dc=wrotethebook, dc=com 3 Falls ldapsearch die Werte -h und -b verlangt, müssen die gleichen Werte für sendmail definiert sein. Dazu verwenden Sie confldap_default_spec, wie in Rezept 5.9 gezeigt. 182 Kapitel 5: Mail-Routing

201 Rechts sendmailmtamapvalue: error:5.7.1:550 oldname.ora.com is out of service Die LDAP-Datenbank ist bereit. Jetzt muss sendmail dazu konfiguriert werden, sie zu benutzen. Das sendmail-schema definiert zwei Attribute, die den Geltungsbereich eines LDAP- Records festlegen. Der Geltungsbereich eines Records kann entweder ein einzelner Host sein, wie durch das Vorhandensein des Attributs sendmailmtahost angezeigt wird, oder eine Gruppe von Hosts, ein so genannter Cluster, wie durch das Attribut sendmailmtacluster verdeutlicht wird. Die Records in diesem Rezept benutzen alle das Attribut sendmailmtacluster. Verwenden Sie die Definition confldap_cluster, um sendmail den Cluster-Namen mitzuteilen. Wird die Definition confldap_cluster nicht benutzt, dann bezieht sendmail nur LDAP-Records, bei denen das Attribut sendmailmtahost auf den voll qualifizierten Hostnamen des sendmail-hosts gesetzt ist, was in diesem Fall keinem der LDAP-Records entsprechen und daher keine mailertable-werte zurückliefern würde. Falls das Attribut sendmailmtacluster in den LDAP-Records, die Sie benötigen, gesetzt ist, müssen Sie die Definition confldap_cluster einsetzen. Sollten Sie nicht vorhaben, die Definition confldap_cluster zu verwenden, dann müssen die LDAP-Records das Attribut sendmailmtahost benutzen. Der String LDAP im mailertable-befehl FEATURE weist sendmail an, die mailertable-daten unter Benutzung des Standard-sendmail-Schemas vom LDAP-Server zu lesen. Wenn die Tests aus früheren Rezepten erneut ausgeführt werden, sehen Sie, dass die mailertable genauso funktioniert unabhängig davon, ob sie aus einer lokalen Datenbank oder von einem LDAP-Server gelesen wird. Wird nach Fertigstellung dieses Rezepts der Test aus Rezept 5.1 noch einmal durchgeführt, dann zeigt sich das gleiche Ergebnis wie beim ursprünglichen Test: # sendmail -bv -Cgeneric-linux.cf jeff@fakeu.edu jeff@fakeu.edu... deliverable: mailer esmtp, host fakeu.edu., user jeff@fakeu.edu # sendmail -bv jeff@fakeu.edu jeff@fakeu.edu... deliverable: mailer smtp8, host mail.fakeu.edu, user jeff@fakeu.edu Auch der erneute Test aus Rezept 5.2 erbringt das richtige Ergebnis: # sendmail -bv richard@oldname.ora.com richard@oldname.ora.com... oldname.ora.com is out of service Tatsächlich kann jedes Record, das in eine lokale mailertable-datenbank eingegeben wird, auch ins LDAP eingegeben und vom LDAP-Server bezogen werden und funktioniert genau wie erwartet. Siehe auch Die Rezepte 5.1 und 5.2 erläutern die mailertable-records, die in diesem Rezept verwendet werden. Die Rezepte 4.14 und 5.8 liefern weitere Beispiele für den Einsatz von LDAP für sendmail-datenbanken. Die Datei cf/readme behandelt dieses Thema im Abschnitt Using LDAP for Aliases, Maps, and Classes. Das Buch sendmail behandelt die mailertable in Abschnitt und die Definition confldap_cluster in Abschnitt Die mailertable über LDAP lesen 183

202 5.6 Mail für einzelne virtuelle Hosts routen Links Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es Mail für virtuelle Hosts routet. Lösung Auf dem DNS-Server legt der Domain-Administrator MX-Records an, die Mail für jede virtuelle Domain an das sendmail-system routen, das als Mail Exchanger fungiert. Diese Records müssen für alle Domains, die virtuelle Hostnamen enthalten, der Zonendatei hinzugefügt werden. Legen Sie auf dem Mail Exchanger eine Datei /etc/mail/virtuser-domains an, die jeweils auf einer eigenen Zeile alle virtuellen Hostnamen aufführt. Erzeugen Sie als Nächstes die Textdatei /etc/mail/virtusertable, die das Routing für die virtuellen Hosts definiert. Die Struktur eines virtusertable-eintrags wird in der Einführung zu diesem Kapitel beschrieben. Benutzen Sie makemap, um aus der Textdatei eine Hash-Datenbank zu erzeugen. Erstellen Sie eine sendmail-konfiguration, die ein VIRTUSER_DOMAIN_FILE-Makro enthält, mit dem Sie die Datei virtuser-domains in die Klasse $={VirtHost} laden, sowie ein FEATURE-Makro, das die Funktion virtusertable aktiviert. Folgende Beispielzeilen könnten der sendmail-konfiguration hinzugefügt werden: dnl Load $={VirtHost} from a file VIRTUSER_DOMAIN_FILE(`/etc/mail/virtuser-domains') dnl Use the virtusertable for mail routing FEATURE(`virtusertable') Legen Sie schließlich die Datei sendmail.cf neu an, kopieren Sie sie nach /etc/mail, und starten Sie sendmail neu, wie in Rezept 1.8 gezeigt. Diskussion Die virtusertable routet Mail für virtuelle Hosts; allerdings ist das sendmail-system, das die virtusertable enthält, an diesem Mail-Routing nicht beteiligt, es sei denn, die Mail wird zuerst an dieses sendmail-system geroutet. Das anfängliche Routing wird über die MX-Records des DNS erreicht. Nehmen Sie beispielsweise an, der DNS-Administrator fügt in die Zonendatei von wrotethebook.com die folgenden MX-Records ein: support.wrotethebook.com. MX 5 mail.wrotethebook.com. sales.wrotethebook.com. MX 5 mail.wrotethebook.com. Der DNS-Administrator von techbooksrus.ora.com fügt Folgendes hinzu: techbooksrus.ora.com. MX 5 mail.wrotethebook.com. 184 Kapitel 5: Mail-Routing

203 Rechts Und der Administrator der wrotethebook.org-zonendatei fügt diese Zeile hinzu: phd.wrotethebook.org. MX 5 mail.wrotethebook.com. Nimmt man diese MX-Records als Grundlage, dann müssen die Datei virtuser-domains, die Datenbank virtusertable und die sendmail-konfiguration, die im Lösungsabschnitt beschrieben werden, alle auf mail.wrotethebook.com erzeugt werden. Hier ist ein Beispiel für die Datei virtuser-domain, die auf mail.wrotethebook.com angelegt werden könnte: # cat > /etc/mail/virtuser-domains support.wrotethebook.com sales.wrotethebook.com techbooksrus.ora.com phd.wrotethebook.org Ctrl-D Die folgende virtusertable wurde auf mail.wrotethebook.com erstellt, um Mail für die virtuellen Hosts zu routen, die in der Datei virtuser-domains aufgeführt werden: # cd /etc/mail # cat > %1@orders.example.com sales@techbooksrus.ora.com error:nohost:553 Invalid address Ctrl-D # makemap hash virtusertable < virtusertable Die Datei virtuser-domains ist unbedingt notwendig. Ohne diese Datei wird Mail, die an die vier oben aufgeführten Hosts adressiert ist, mit dem Fehler»Relaying denied«abgewiesen. Ist die Datei vorhanden, dann wird Mail, die an diese Hosts adressiert ist, durch mail.wrotethebook.com angenommen, wo sie dann mit Hilfe der virtusertable verarbeitet werden kann. Mail muss vier Hürden überwinden, bevor sie durch die virtusertable modifiziert wird: 1. Mail muss zur Verarbeitung an den lokalen Host geroutet werden. Die DNS-MX-Records erledigen diese Aufgabe. Es ist aber auch möglich, Mail mit Hilfe eines DNS-Address-(A-)Records zu routen. Allerdings genießen MX-Records beim Mail-Routing Vorrang gegenüber anderen DNS-Records. 2. Mail muss vom lokalen Host zur Verarbeitung angenommen werden. Um diese Bedingung zu erfüllen, muss die Mail an einen Host adressiert sein, der in den Klassen $=w oder $=R aufgeführt ist. Wenn die Klasse $=w genutzt wird, um virtuelle Hosts zu identifizieren, dann wird die Mail akzeptiert, weil die Werte in der Klasse $=w die Hostnamen-Aliase des lokalen Hosts sind Mail, die an einen Host in der Klasse $=w adressiert ist, wird als Mail akzeptiert, die an den lokalen Host adressiert ist. Wird die Klasse $={VirtHost} verwendet, um die virtuellen Hosts zu identifizieren, dann wird die Mail akzeptiert, weil die Werte in $={VirtHost} durch den sendmail.cf-befehl CR{VirtHost} in der Klasse $=R wiederholt werden. Die Weitervermittlung ist für alle Domains erlaubt, die in der Klasse $=R aufgeführt werden. Des- 5.6 Mail für einzelne virtuelle Hosts routen 185

204 halb wird Mail zu oder von einem Host aus einer Domain, die in der Klasse $={VirtHost} steht, durch den lokalen Host als Mail für einen gültigen Relay-Client angenommen. 3. Der Hostname in der Empfängeradresse muss für die Verarbeitung durch die virtusertable akzeptiert werden. Eine Empfängeradresse wird nur anhand der virtusertable verarbeitet, falls der Hostname in dieser Adresse einem Wert in den Klassen $=w oder $={VirtHost} entspricht. Diese Prüfung ist mit Schritt 2 vergleichbar, nur dass Hostnamen, die in der Klasse $=R aufgeführt werden, Schritt 2 durchlaufen, nicht jedoch Schritt Die Empfängeradresse muss einem Schlüssel in der virtusertable-datenbank entsprechen. Einem Wert in den Klassen $=w oder $={VirtHost} zu entsprechen, bietet keine Garantie dafür, dass es einen Schlüssel für diesen Wert in der virtusertable gibt. Nur Mail mit einer Empfängeradresse, die einem Schlüssel entspricht, wird durch die virtusertable geroutet. Links Die sendmail-konfiguration in diesem Rezept verwendet das Makro VIRTUSER_DOMAIN _FILE, um die Klasse $={VirtHost} aus einer externen Datei zu laden. Alternativ können mit dem Makro VIRTUSER_DOMAIN einzelne Werte zu $={VirtHost} hinzugefügt werden. Die folgenden Makros würden die gleichen Werte zu $={VirtHost} hinzufügen, wie die Beispieldatei virtuser-domains, die oben zu sehen ist: VIRTUSER_DOMAIN_FILE(`support.wrotethebook.com') VIRTUSER_DOMAIN_FILE(`sales.wrotethebook.com') VIRTUSER_DOMAIN_FILE(`techbooksRus.ora.com') VIRTUSER_DOMAIN_FILE(`phd.wrotethebook.org') Diese Alternative funktioniert, ist aber schwieriger zu warten, wenn die Liste der virtuellen Domains lang ist oder sich ändert. Sobald die sendmail-konfiguration aus diesem Rezept installiert wurde, zeigen vier sendmail -bv-tests die Wirkung der virtusertable: # sendmail -bv sara@support.wrotethebook.com anna@crab.wrotethebook.com... deliverable: mailer esmtp, host crab.wrotethebook.com., user anna@crab.wrotethebook.com andy@rodent.wrotethebook.com... deliverable: mailer esmtp, host rodent.wrotethebook.com., user andy@rodent.wrotethebook.com jane@rodent.wrotethebook.com... deliverable: mailer esmtp, host rodent.wrotethebook.com., user jane@rodent.wrotethebook.com # sendmail -bv sara@sales.wrotethebook.com sara@sales.wrotethebook.com... deliverable: mailer esmtp, host orders.example.com, user sara@orders.example.com # sendmail -bv sales@techbooksrus.ora.com sales@techbooksrus.ora.com... deliverable: mailer esmtp, host orders.example.com, user jay@orders.example.com # sendmail -bv sales@phd.wrotethebook.org sales@phd.wrotethebook.org... Invalid address 186 Kapitel 5: Mail-Routing

205 Rechts Der erste Test zeigt, dass Mail, die an einen Benutzer auf dem virtuellen Host support. wrotethebook.com adressiert ist, an den lokalen Benutzer admin ausgeliefert wird. In diesem Fall handelt es sich bei admin um eine Mailingliste, die in der aliases-datei definiert wurde. Wenn ein virtusertable-eintrag Mail an einen lokalen Benutzer routet, dann werden auch die Aliase aufgelöst. Der zweite Test zeigt, dass Mail, die an einen Benutzernamen auf dem virtuellen Host sales.wrotethebook.com adressiert ist, an diesen Benutzernamen auf orders.example.com ausgeliefert wird. Dieser Test zeigt, wie die Variable %1 benutzt wird, um den Benutzernamen von der Eingangs- zur Ausgangsadresse zu verschieben. Andererseits bewahrt der dritte Test nichts von der Eingangsadresse. In diesem Fall wird Mail, die an adressiert ist, an ausgeliefert. Der letzte sendmail -bv-befehl testet den Eintrag mit der Fehlermeldung in der Beispielvirtusertable. In diesem Fall liefert Mail an einen Benutzer auf phd.wrotethebook.org die Fehlermeldung»Invalid address«(ungültige Adresse). Dieser -bv-test liefert nur die Fehlermeldung; es wird nicht das ganze Mail-Auslieferungstriple gezeigt. Um weitere Einzelheiten zu erhalten, müssen Sie zusätzliche Tests ausführen. Wenn Sie per telnet eine Verbindung zum SMTP-Port aufnehmen, können Sie die Interaktionen des SMTP-Protokolls sehen: # telnet localhost smtp Trying Connected to localhost. Escape character is '^]'. 220 chef.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 8 Nov :53: HELO chef.wrotethebook.com 250 chef.wrotethebook.com Hello localhost.localdomain [ ], pleased to meet you MAIL From:<craig@chef.wrotethebook.com> craig@chef.wrotethebook.com... Sender ok RCPT To:<sales@phd.wrotethebook.org> sales@phd.wrotethebook.org... Invalid address QUIT chef.wrotethebook.com closing connection Connection closed by foreign host. Die Antwort des Servers auf die Empfängeradresse sales@phd.wrotethebook.org zeigt die Fehlercodes sowie den Text der Fehlermeldung. Der SMTP-Antwortcode 553 kennzeichnet eine ungültige Mailbox, und der DSN-Code gibt an, dass es sich um einen permanenten Fehler am Ziel-Mailsystem handelt. Beides sind zutreffende Codes für das Fehlerschlüsselwort nohost, das wir für phd.wrotethebook.org in den virtusertable-eintrag gesetzt haben. Alternativen Die aliases-datei bildet eine Alternative zur Benutzung der virtusertable für Zuordnungen von Benutzernamen zu Benutzernamen. In der Beispiel-virtusertable, die weiter vorn in 5.6 Mail für einzelne virtuelle Hosts routen 187

206 diesem Abschnitt zu sehen war, bildet die folgende Adresse eine bestimmte eingehende Adresse auf eine bestimmte ausgehende Adresse ab: Der Benutzer sales auf techbooksrus.ora.com wird auf den Benutzer jay auf orders. example.com abgebildet. Das gleiche Ergebnis würden Sie erhalten, wenn Sie den folgenden Eintrag in die aliases-datenbank setzen würden: Diese Alternative funktioniert nur, wenn bei dem Mailer, der Mail für techbooksrus.ora. com verarbeitet, der Mailer-Schalter F=A gesetzt ist. Üblicherweise ist dies nur beim Mailer local der Fall. Der oben gezeigte Alias würde eine Neukonfiguration von sendmail erfordern, um den Schalter F=A für den esmtp-mailer zu setzen. Das Setzen des Schalters F=A bei einem Mailer, der entfernte Mail ausliefert, würde bedeuten, dass jede entfernte Adresse in der aliases-datenbank nachgesehen werden würde, was einen bedeutend höheren Verarbeitungsaufwand erfordert. Die mailertable ist in manchen Fällen ebenfalls eine Alternative zur virtusertable. Drei der Einträge in der virtusertable könnten mit den folgenden Einträgen auch von der mailertable abgedeckt werden: support.wrotethebook.com sales.wrotethebook.com.wrotethebook.org local:admin esmtp:orders.example.com error:nohost Invalid address Der wichtigste Nachteil der mailertable für diese Anwendung besteht darin, dass sie die Zuordnung von auf nicht erledigen kann. Die mailertable vergleicht nur Hostnamen; der Benutzername wird nicht in den Vergleich einbezogen. Für diese besondere Anwendung stellt die virtusertable die beste Wahl dar. Links Siehe auch Rezept 5.7 beschreibt zusätzliche virtusertable-eigenschaften und sollte für entsprechende Informationen ebenfalls beachtet werden. Das Buch sendmail behandelt die virtusertable in Abschnitt Linux Sendmail Administration von Craig Hunt (Sybex) erläutert die numerischen SMTP-Antwortcodes, die Fehlercode-Schlüsselwörter und die DSN-Codes. 5.7 Mail für komplette virtuelle Domains routen Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es Mail für komplette virtuelle Domains und nicht nur für einzelne Hosts routet. 188 Kapitel 5: Mail-Routing

207 Rechts Lösung Der Domain-Administrator muss jede virtuelle Mail-Domain bei einer offiziellen DNS- Registrierungsstelle registrieren. Der DNS-Administrator muss außerdem für jede virtuelle Mail-Domain eine minimale Zonendatei anlegen. Zusätzlich zu den grundlegenden Records, die erforderlich sind, um eine Zonendatei zu erzeugen, muss die Datei MX- Records enthalten, die auf den Mail Exchanger verweisen, den Sie konfigurieren. Im Buch DNS und BIND von Paul Albitz und Cricket Liu (O Reilly) finden Sie weitere Informationen über die DNS-Konfiguration. Legen Sie auf dem Mailserver eine /etc/mail/virtuser-domains-datei an, die alle virtuellen Mail-Domains aufführt, für die der Dienst angeboten wird. Erzeugen Sie eine /etc/mail/virtusertable-textdatei, die das Routing für alle virtuellen Mail-Domains definiert. Mit Hilfe von makemap wandeln Sie die Textdatei in eine Hash- Datenbank um. Erstellen Sie als Nächstes eine sendmail-konfiguration, die die Funktion virtusertable aktiviert, die Klasse $={VirtHost} aus der Datei /etc/mail/virtuser-domains lädt und die Funktion virtuser_entire_domain aktiviert. Hier sind Beispiele für die Zeilen, die in die sendmail-konfiguration eingefügt werden müssen: dnl Use the virtusertable for mail routing FEATURE(`virtusertable') dnl Load $={VirtHost} from a file VIRTUSER_DOMAIN_FILE(`/etc/mail/virtuser-domains') dnl Interpret the values in $={VirtHost} as domain names FEATURE(`virtuser_entire_domain') Erzeugen und installieren Sie die Datei sendmail.cf, und starten Sie sendmail neu, wie in Rezept 1.8 gezeigt. Diskussion Nehmen Sie an, dass die Zonendatei, die für die Domains shop.wrotethebook.org, school. ora.com und hotel.example.com angelegt wurde, MX-Records enthält, die an mail. wrotethebook.com routen. Der Host mail.wrotethebook.com weist diese Mail ab, es sei denn, der Ziel-Hostname wird in den Klassen $=w oder $={VirtHost} aufgeführt. Die Konfiguration, die im Lösungsabschnitt beschrieben wurde, lädt die Klasse $={VirtHost} aus der Datei /etc/mail/virtuser-domains, die durch das Makro VIRTUSER_DOMAIN_FILE festgelegt wird. Hier ist ein Beispiel für die Datei virtuser-domains, die die Namen dreier virtueller Mail-Domains enthält: # cat /etc/mail/virtuser-domains shop.wrotethebook.org school.ora.com hotel.example.com 5.7 Mail für komplette virtuelle Domains routen 189

208 Werte, die in der Klasse $={VirtHost} gespeichert sind, werden in der Klasse $=R wiederholt, wie dieser einfache Test zeigt: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $={VirtHost} shop.wrotethebook.org school.ora.com hotel.example.com > $=R shop.wrotethebook.org school.ora.com hotel.example.com > /quit Standardmäßig werden die Werte in den Klassen $=w und $={VirtHost} als Hostnamen interpretiert. Werte in der Klasse $=R werden andererseits als Domainnamen interpretiert. Mit der Funktion virtuser_entire_domain können Sie dafür sorgen, dass die Werte in der Klasse $={VirtHost} ebenfalls als Domainnamen interpretiert werden. Die Funktion virtuser_entire_domain weist sendmail an, die Klassen $=R und $={VirtHost} auf äquivalente Weise zu bewerten alle Hosts in allen Domains, die in der Klasse $=R aufgeführt sind, werden für die Verarbeitung durch den lokalen Host akzeptiert, und alle Hosts in allen Domains, die in der Klasse $={VirtHost} stehen, werden mit den Werten in der virtusertable verglichen. Hier ist eine virtusertable, mit der wir dies verdeutlichen: # cat > reservations@b1088.isp.wrotethebook.net Ctrl-D # makemap hash /etc/mail/virtusertable < /etc/mail/virtusertable Die ersten drei Einträge routen Mail, die an irgendjemanden auf den drei Hosts in der Domain shop.wrotethebook.org adressiert ist, an die lokalen Benutzerzugänge, wo die Mail gelesen wird, die an diese virtuellen Hosts gerichtet ist. school.ora.com und hotel.example.com betreiben beide ihre eigenen Server, allerdings sind diese Server tatsächlich Teil der Domain isp.wrotethebook.net. school.ora.com besitzt nur einen Server. hotel.example.com hat drei Server einen im Motel, einen in der Lodge und einen im Hotel. Beachten Sie, dass school.ora.com die +detail-syntax verwendet, um die spezielle Mailbox beim Zugang jeff zu identifizieren, in der die Mail gespeichert werden soll. Damit das funktioniert, muss der Zugang jeff auf b2341.isp.wrotethebook.net einen Mail-Filter haben, der die +detail-syntax verarbeitet. Links 190 Kapitel 5: Mail-Routing

209 Rechts Einige Tests der Konfiguration dieses Rezepts zeigen die Wirkung der Funktion virtuser_ entire_domain sowie der virtusertable-einträge: # sendmail -bv info@mall.shop.wrotethebook.org info@mall.shop.wrotethebook.org... deliverable: mailer local, user pat # sendmail -bv cranks@sales.school.ora.com cranks@sales.school.ora.com... deliverable: mailer esmtp, host b2341.isp.wrotethebook. net., user jeff+sales@b2341.isp.wrotethebook.net # sendmail -bv reservations@lodge.hotel.example.com reservations@lodge.hotel.example.com... deliverable: mailer esmtp, host b0531.isp. wrotethebook.net., user reservations@b0531.isp.wrotethebook.net Keiner der Hostnamen in den drei Testadressen, die oben gezeigt werden, wird in den Klassen $=w oder $={VirtHost} aufgeführt. Dennoch werden alle drei Adressen offensichtlich durch die virtusertable umgeschrieben. Das ist die Wirkung der Funktion virtuser_ entire_domain: Diese Hostnamen werden durch die virtusertable verarbeitet, weil sie zu Domains gehören, die in der Klasse $={VirtHost} aufgeführt sind. Potenzielle Konflikte und Lösungen Die Funktion virtuser_entire_domain ändert jedoch nicht die Art und Weise, wie die Schlüssel in der virtusertable interpretiert werden. Es gibt keinen Domain-Platzhalter für die virtusertable. Jeder Hostname im oben gezeigten Test wird umgeschrieben, weil er genau auf einen Schlüssel in der Datenbank passt. Ein häufig gemachter Fehler besteht darin zu denken, dass ein Eintrag auf alle Hosts in der Domain school.ora.com angewandt wird, weil die Funktion virtuser_entire_domain zum Einsatz kommt. Ein Test zeigt, dass dies nicht der Fall ist: # sendmail -bv dave@school.ora.com dave@school.ora.com... deliverable: mailer esmtp, host b2341.isp.wrotethebook.net., user dave@b2341.isp.wrotethebook.net # sendmail -bv dave@hs.school.ora.com dave@hs.school.ora.com... deliverable: mailer esmtp, host hs.school.ora.com., user dave@hs.school.ora.com Beide oben gezeigten Empfängeradressen stammen aus einer Domain, die in $={VirtHost} aufgeführt ist, außerdem ist die Funktion virtuser_entire_domain aktiviert. Aus diesen Gründen werden beide Adressen mit der virtusertable abgeglichen. Aber nur die erste Adresse entspricht einem Schlüssel, der in der Datenbank zu finden ist, und wird umgeroutet. Die andere Adresse durchläuft den normalen Auslieferungsvorgang. Darin liegt ein möglicher Konflikt mit dem Domain-Administrator. Manche Domain-Administratoren verwenden Wildcard-MX-Records, die auf jeden Hostnamen innerhalb einer bestimmten Domain passen. Das Wildcard-MX-Record erleichtert die Dinge für den Domain-Administrator, schafft aber möglicherweise neue Probleme für den sendmail-administrator. Der sendmail -bv-test von dave@hs.school. ora.com zeigt das Problem. Mail, die an hs.school.ora.com adressiert ist, wird zur Verarbeitung durch den lokalen Host akzeptiert, weil die Domain school.ora.com in der Klasse $=R aufgeführt ist, was 5.7 Mail für komplette virtuelle Domains routen 191

210 bedeutet, dass der lokale Host Mail für diese Domain weitervermittelt. Die Adresse hs.school.ora.com wird nicht durch den virtusertable-prozess verändert, so dass der lokale Host versucht, die Mail über den esmtp-mailer direkt an einen Host namens hs.school. ora.com auszuliefern. Wenn der lokale Host eine DNS-Anfrage nach hs.school.ora.com ausführt, verläuft diese Anfrage erfolgreich, da dieser Host durch das MX-Wildcard abgedeckt wird. Das MX-Record, das durch die Anfrage zurückgeliefert wird, verweist den lokalen Host direkt zurück an den lokalen Host. Schon haben wir ein Problem! Es gibt verschiedene Möglichkeiten, dieses Problem zu vermeiden. Alle drei Lösungen funktionieren, und alle drei haben verschiedene Vor- und Nachteile. Die erste Lösung wird bevorzugt; für welche Lösung Sie sich jedoch schließlich entscheiden, hängt von Ihrer persönlichen Situation ab. Es gibt folgende Lösungen: Verwenden Sie einzelne MX-Records Das MX-Wildcard ist die Ursache des Problems: Es routet Mail für einen Host, der nicht existiert weder real noch virtuell. Legen Sie eine an die einzelnen virtuellen Mail-Domains angepasste Zonendatei an, die explizit ein MX-Record für jeden Host definiert, der von der virtusertable abgedeckt wird. Wenn der Domain-Administrator gleichzeitig auch der sendmail-administrator ist, dann funktioniert dieser Ansatz ganz hervorragend und hat den klaren Vorteil, dass Fehler bei Domainnamen dort behoben werden, wo sie auftreten im DNS. Der Nachteil bei diesem Ansatz besteht darin, dass er die Arbeit für den Domain-Administrator erhöht und die Fähigkeit des sendmail-administrators verringert, seine eigenen Probleme zu lösen. Verwenden Sie local-host-names, und führen Sie nur einzelne Hostnamen auf Mail, die an hs.school.ora.com adressiert ist, wird zur Weitervermittlung durch das lokale System akzeptiert, weil die Domain, zu der es gehört, in der Klasse $=R aufgeführt ist. Jeder Eintrag in $={VirtHost} wird in der Klasse $=R wiederholt. Jeder Eintrag in der Klasse $=R wiederum wird als Domainname interpretiert. Das heißt, selbst wenn die Funktion virtuser_entire_domain nicht benutzt wird, verursacht das Aufführen von school.ora.com in $={VirtHost} das Mail-Auslieferungsproblem, das wir gerade beschrieben haben. Vermeiden Sie dies, indem Sie school.ora.com in die Datei local-host-names aufnehmen und die Funktion use_cw_file verwenden, um diese Datei in die Klasse $=w zu laden. Werte in der Klasse $=w werden als Hostnamen interpretiert; das heißt, Mail, die an hs.school.ora.com adressiert ist, wird nicht durch das lokale System akzeptiert, und das Auslieferungsproblem wird nicht ausgelöst. Natürlich wird die Mail dann als unzustellbar an den Absender zurückgeschickt. Das ist in Ordnung, falls der Absender beim Eingeben der Adresse einen Fehler gemacht hat; falls jedoch die Leute bei school.ora.com diese Adresse bekannt gemacht haben, ist es keine gute Idee, eine Fehlermeldung an den Absender zurückzuschicken. Ein anderer Nachteil dieser Lösung besteht darin, dass das Aufführen der Hostnamen in local-host-names diese Hostnamen praktisch zu Aliasen für den lokalen Host macht, wodurch Konflikte bei den Benutzernamen auftreten können. Links 192 Kapitel 5: Mail-Routing

211 Rechts Einen Catchall-Eintrag in der mailertable anlegen Ein Catchall-Eintrag ist ein Eintrag in einer Datenbank, der alle Abfragen abfängt, für die es keinen speziellen Schlüssel gibt. Im Allgemeinen beantwortet ein Catchall- Eintrag diese Abfragen mit einer Fehlermeldung. Catchall-Einträge in der virtusertable verarbeiten Benutzernamen, die nicht besonders durch Tabelleneinträge abgedeckt werden. Um einen Catchall-Eintrag für einen Hostnamen zu erzeugen, benutzen Sie die mailertable. Die Vorteile von Catchall-Einträgen bestehen darin, dass sie proaktiv auf Fehlersituationen reagieren und außerdem unter direkter Kontrolle des sendmail-administrators stehen. Der Nachteil von Catchall-Einträgen ist, dass sie alles abfangen auch Dinge, die sie nicht abfangen sollen. Sie müssen vollständig getestet und sorgfältig eingesetzt werden. Die Catchall-Lösung Unten definieren wir Catchall-Einträge in der mailertable, um mögliche Auslieferungsprobleme zu vermeiden, die ausgelöst werden würden, wenn der Domain-Administrator in unseren virtuellen Beispiel-Mail-Domains Wildcard-MX-Records benutzen würde. Erweitern Sie zuerst die einfache Konfiguration aus Rezept 5.7 um Unterstützung für die mailertable: dnl Use the virtusertable for mail routing FEATURE(`virtusertable') dnl Load $={VirtHost} from a file VIRTUSER_DOMAIN_FILE(`/etc/mail/virtuser-domains') dnl Interpret the values in $={VirtHost} as domain names FEATURE(`virtuser_entire_domain') dnl Use the mailertable to invoke special mailers FEATURE(`mailertable') Erzeugen Sie die virtusertable-datenbank und die Datei virtuser-domains, wie oben beschrieben. Legen Sie eine mailertable mit einem Catchall-Eintrag für alle virtuellen Mail-Domains an: # cat > /etc/mail/mailertable.school.ora.com error:5.3.0:553 Invalid hostname shop.wrotethebook.org error:5.3.0:553 Invalid hostname.shop.wrotethebook.org error:5.3.0:553 Invalid hostname hotel.example.com error:5.3.0:553 Invalid hostname.hotel.example.com error:5.3.0:553 Invalid hostname Ctrl-D # makemap hash /etc/mail/mailertable < /etc/mail/mailertable Der erste Eintrag behandelt das spezielle Problem, das im obigen Beispiel beschrieben wurde. Die nächsten beiden Einträge liefern eine ähnliche Fehlerkontrolle für die virtuelle Mail-Domain shop.wrotethebook.org, und die letzten beiden Einträge bieten den Schutz für die virtuelle Mail-Domain hotel.example.com. Die zusätzlichen Einträge für die Domains shop.wrotethebook.org und hotel.example.com sind erforderlich, weil im Gegensatz zur Domain school.ora.com keine dieser beiden Domains über einen virtusertable- 5.7 Mail für komplette virtuelle Domains routen 193

212 Eintrag verfügt, der Mail routet, die an adressiert ist, wie dieser Test der Grundkonfiguration dieses Rezeptes zeigt: # sendmail -bv jane@shop.wrotethebook.org jane@shop.wrotethebook.org... deliverable: mailer esmtp, host shop.wrotethebook.org., user jane@shop.wrotethebook.org # sendmail -bv kathy@hotel.example.com kathy@hotel.example.com... deliverable: mailer esmtp, host hotel.example.com., user kathy@hotel.example.com # sendmail -bv sara@school.ora.com sara@school.ora.com... deliverable: mailer esmtp, host b2341.isp.wrotethebook.net., user sara@b2341.isp.wrotethebook.net mailertable-einträge, die mit einem Punkt beginnen, sind teilweise Domainnamen, die alle Adressen erfassen, die auf diesen besonderen Domainnamen enden. Beispielsweise würde ein mailertable-eintrag, der mit.wrotethebook.com beginnt, Adressen der Form benutzer@host.wrotethebook.com abfangen. Vollständige Domainnamen (die also nicht mit einem Punkt beginnen) entsprechen Adressen der Form benutzer@domain. Ein mailertable-eintrag, der mit ora.com beginnt, würde daher craig@ora.com, nicht jedoch craig@tcp.ora.com entsprechen. Diese Catchall-mailertable-Einträge können nur bei virtuellen Mail-Domains eingesetzt werden und sind nur sinnvoll, wenn die Zonendateien dieser Domains Wildcard-MX- Records benutzen. Würde es sich um echte Domains handeln, könnte der virtusertable- Eintrag Mail von einem Host in der Domain zu einem anderen in der gleichen Domain routen. Die umgeschriebene Adresse würde dann von dem mailertable-catchall-eintrag abgefangen werden und der Fehler»invalid hostname«(ungültiger Hostname) würde zurückgegeben werden. Da es sich um virtuelle Mail-Domains ohne physische Existenz handelt, routet virtusertable niemals Mail an einen Host in nicht existierenden Domains. Das heißt, Adressen, die durch die virtusertable umgeschrieben werden, entsprechen nicht den Catchall-Einträgen und können weiterhin ihren Weg nehmen, wie durch die virtusertable angewiesen. Diese Catchall-Einträge sind nützlich, allerdings nur für das hier beschriebene spezielle Problem. Führen Sie einige Tests mit der neuen Konfiguration aus, um die Wirkung dieser mailertable-einträge zu sehen: # sendmail -bv -C recipe5-7a.cf dave@hs.school.ora.com dave@hs.school.ora.com... Invalid hostname # sendmail -bv C recipe5-7a.cf dave@school.ora.com dave@school.ora.com... deliverable: mailer esmtp, host b2341.isp.wrotethebook.net., user dave@ b2341.isp.wrotethebook.net # sendmail -bv C recipe5-7a.cf jane@mall.shop.wrotethebook.org jane@mall.shop.wrotethebook.org... deliverable: mailer local, user pat # sendmail -bv C recipe5-7a.cf jane@shop.wrotethebook.org jane@shop.wrotethebook.org... Invalid hostname Diese Tests zeigen, dass Adressen, die Schlüsseln in der virtusertable entsprechen, richtig umgeschrieben werden, während Adressen in der virtuellen Mail-Domain, die keine Einträge in der virtusertable besitzen, nun korrekt als Adressierungsfehler identifiziert wer- Links 194 Kapitel 5: Mail-Routing

213 Rechts den. Catchall-Einträge sind nützlich, müssen aber mit Bedacht eingesetzt und ausreichend getestet werden, um sicherzustellen, dass sie keine Dinge abfangen, die sie nicht abfangen sollen. Diese ganze Arbeit könnte natürlich vermieden werden, wenn der Domain-Administrator keine Wildcard-MX-Records benutzen würde. Die beste Lösung für dieses potenzielle Problem besteht darin, Wildcards zu vermeiden und individuelle MX-Records einzusetzen. Siehe auch Rezept 5.6 definiert einzelne virtuelle Hosts im Gegensatz zu den virtuellen Mail- Domains und sollte als Alternative betrachtet werden, bevor Sie dieses Rezept umsetzen. Die Rezepte 5.1 bis 5.4 und die Einführung in dieses Kapitel bieten zusätzliche Informationen über die mailertable. Das Buch sendmail behandelt die virtusertable in Abschnitt MX-Records und das DNS werden in DNS und BIND von Paul Albitz und Cricket Liu (O Reilly) sowie in TCP/IP-Netzwerk-Administration von Craig Hunt (O Reilly) behandelt. 5.8 Die virtusertable über LDAP lesen Problem Sie müssen sendmail so konfigurieren, dass es die virtusertable von einem LDAP-Server liest. Lösung Fügen Sie auf dem LDAP-Server die Datei sendmail.schema in die LDAP-Konfiguration ein, und starten Sie LDAP neu. Rezept 1.3 bietet ein ausführliches Beispiel für die entsprechende Vorgehensweise auf einem System mit OpenLDAP. Legen Sie auf dem LDAP-Server eine LDIF-Datei an, die die virtusertable-daten enthält, und fügen Sie diese Daten mit dem Befehl ldapadd in die LDAP-Datenbank ein. Die virtusertable-daten sollten als Daten vom Typ sendmailmtamap-objektklasse eingegeben werden. Die Klasse $={VirtHost} kann ebenfalls von einem LDAP-Server geladen werden. Auch hier werden die Daten zuerst in eine LDIF-Datei eingefügt und dann mittels ldapadd in die LDAP-Datenbank eingebracht. Die $={VirtHost}-Daten werden mit Hilfe des sendmailmtaclass-objektklassenformats eingegeben. Erzeugen Sie auf dem sendmail-system eine Konfiguration, die einen virtusertable-befehl FEATURE enthält, der sendmail anweist, die virtusertable über LDAP zu lesen, sowie ein VIRTUSER_DOMAIN_FILE-Makro, das die Klasse $={VirtHost} vom LDAP-Server liest. Setzen Sie die Definition confldap_cluster auf den Namen des LDAP-Clusters, der im 5.8 Die virtusertable über LDAP lesen 195

214 sendmailmtacluster-attribut der virtusertable-ldap-records verwendet wird. Folgende Zeilen würden Sie unserer Beispiel-sendmail-Konfiguration hinzufügen: dnl Define the LDAP cluster to which this host belongs define(`confldap_cluster', `wrotethebook.com') dnl Read the virtusertable via LDAP FEATURE(`virtusertable', `LDAP') dnl Load $={VirtHost} from the LDAP server Anschließend erstellen Sie die Datei sendmail.cf neu, installieren sie und starten dann sendmail neu, wie in Rezept 1.8 beschrieben. Links Diskussion Dieses Rezept verdeutlicht, wie die virtusertable-daten auf einem LDAP-Server gespeichert und von ihm bezogen werden. Die Einzelheiten Ihrer Konfiguration werden natürlich unterschiedlich sein, die dahinter stehenden Konzepte hingegen sind identisch. Die Beispiele in diesem Rezept nutzen Informationen von einem LDAP-Server, um die Konfiguration zu duplizieren, die in Rezept 5.6 zum Einsatz kommt. Weshalb und wie die virtusertable benutzt wird und welche Rolle die Klasse $={VirtHost} spielt, wird in jenem Rezept behandelt. Der LDAP-Administrator gibt die Daten zuerst in eine LDIF-Datei ein, die auf eine mit dem sendmail-schema kompatible Weise strukturiert ist. Dieses Beispiel nutzt drei der virtusertable-einträge aus Rezept 5.6 und fügt sie in die LDAP-Datenbank ein: # cat > ldap-virtuser dn: sendmailmtamapname=virtuser, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtamap sendmailmtacluster: wrotethebook.com sendmailmtamapname: virtuser dn: sendmailmtakey=@mall.shop.wrotethebook.org, sendmailmtamapname=virtuser, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtamap objectclass: sendmailmtamapobject sendmailmtamapname: virtuser sendmailmtacluster: wrotethebook.com sendmailmtamapvalue: pat dn: sendmailmtakey=@sales.school.ora.com, sendmailmtamapname=virtuser, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtamap objectclass: sendmailmtamapobject sendmailmtamapname: virtuser sendmailmtacluster: wrotethebook.com 196 Kapitel 5: Mail-Routing

215 Rechts sendmailmtamapvalue: dn: sendmailmtamapname=virtuser, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtamap objectclass: sendmailmtamapobject sendmailmtamapname: virtuser sendmailmtacluster: wrotethebook.com sendmailmtamapvalue: Ctrl-D # ldapadd -x -D "cn=manager,dc=wrotethebook,dc=com" \ > -W -f ldap-virtuser Enter LDAP Password: SecretLDAPpassword adding new entry "sendmailmtamapname=virtuser, dc=wrotethebook, dc=com" adding new entry "sendmailmtakey=@mall.shop.wrotethebook.org, sendmailmtamapname=virtuser, dc=wrotethebook, dc=com" adding new entry "sendmailmtakey=@sales.school.ora.com, sendmailmtamapname=virtuser, dc=wrotethebook, dc=com" adding new entry "sendmailmtakey=@lodge.hotel.example.com, sendmailmtamapname=virtuser, dc=wrotethebook, dc=com" Der virtusertable-datenbankname, der virtuser lautet, wird in dem ersten Eintrag definiert. Nachfolgende Dateneinträge für diese Datenbank verknüpfen sich selbst mit der Datenbank, indem mit dem Attribut sendmailmtamapname auf den Datenbanknamen verwiesen wird. virtusertable-daten sind Schlüssel/Wert-Paare. Der Schlüssel wird durch das Attribut sendmailmtakey definiert, der Rückgabewert wird durch das Attribut sendmailmtamapvalue definiert. Das bedeutet, der folgende virtusertable-eintrag aus Rezept pat wird durch das Eingeben in die LDAP-Datenbank zu folgendem Record: dn: sendmailmtakey=@mall.shop.wrotethebook.org, sendmailmtamapname=virtuser, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtamap objectclass: sendmailmtamapobject sendmailmtamapname: virtuser sendmailmtacluster: wrotethebook.com sendmailmtamapvalue: pat Dieses Rezept verwendet LDAP ebenfalls, um die Klasse $={VirtHost} zu laden. Das folgende Beispiel speichert die Daten für die Klasse $={VirtHost} auf dem LDAP-Server: # cat > ldap-virtuser-domains dn: sendmailmtaclassname=virthost, dc=wrotethebook, dc=com 5.8 Die virtusertable über LDAP lesen 197

216 objectclass: sendmailmta objectclass: sendmailmtaclass sendmailmtacluster: wrotethebook.com sendmailmtaclassname: VirtHost sendmailmtaclassvalue: shop.wrotethebook.org sendmailmtaclassvalue: school.ora.com sendmailmtaclassvalue: hotel.example.com Ctrl-D # ldapadd -x -D "cn=manager,dc=wrotethebook,dc=com" \ > -W -f ldap-virtuser-domains Enter LDAP Password: SecretLDAPpassword adding new entry "sendmailmtaclassname=virthost, dc=wrotethebook, dc=com" Das Attribut sendmailmtaclassname kennzeichnet die Klasse als VirtHost. 4 Die einzelnen Klassenwerte werden durch die sendmailmtaclassvalue-attribute in dem LDAP-Record definiert. Dieses LDAP-Record definiert die gleichen Werte wie die Datei virtuserdomains in Rezept 5.6. ldapadd lädt die Daten in die LDAP-Datenbank. Verwenden Sie ldapsearch, um die Daten zu überprüfen: # ldapsearch -LLL -x '(sendmailmtamapname=virtuser)' sendmailmtamapvalue dn: sendmailmtamapname=virtuser, dc=wrotethebook, dc=com Links dn: sendmailmtakey=@mall.shop.wrotethebook.org, sendmailmtamapname=virtuser, dc=wrotethebook, dc=com sendmailmtamapvalue: pat dn: sendmailmtakey=@sales.school.ora.com, sendmailmtamapname=virtuser, dc=wrotethebook, dc=com sendmailmtamapvalue: jeff+sales@b2341.isp.wrotethebook.net dn: sendmailmtakey=@lodge.hotel.example.com, sendmailmtamapname=virtuser, dc=wrotethebook, dc=com sendmailmtamapvalue: reservations@b0531.isp.wrotethebook.net # ldapsearch -LLL -x '(sendmailmtaclassname=virthost)' sendmailmtaclassvalue dn: sendmailmtaclassname=virthost, dc=wrotethebook, dc=com sendmailmtaclassvalue: shop.wrotethebook.org sendmailmtaclassvalue: school.ora.com sendmailmtaclassvalue: hotel.example.com Der ldapsearch-test zeigt, dass der LDAP-Server für sendmail bereit ist. Wenn der Befehl ldapsearch auf Ihrem sendmail-system die Argumente -h und -b verlangt, dann müssen diese Werte auch für sendmail konfiguriert sein. Dazu verwenden Sie die Definition confldap_default_spec, die in Rezept 5.9 beschrieben wird. Nun muss die sendmail-konfiguration verändert werden, um sendmail für LDAP vorzubereiten. Dieses Rezept setzt Rezept 5.6 in einer LDAP-Umgebung um. Dazu wird der String LDAP (der sendmail anweist, Daten vom LDAP zu lesen) dem virtusertable-befehl FEATURE hinzugefügt. Diese Änderung ist ausgesprochen wichtig, um unser Ziel, das 4 Beachten Sie, dass der Klassenname ohne die umschließenden geschweiften Klammern ({}) geschrieben wird. 198 Kapitel 5: Mail-Routing

217 Rechts Lesen der virtusertable von einem LDAP-Server, zu erreichen, es ist aber nicht die einzige wichtige Modifikation. In Anbetracht der Eigenschaften der Daten, die in den Server geladen werden, ist auch die confldap_cluster-definition wichtig. Der von sendmail verwendete Cluster-Name muss dem Attribut sendmailmtacluster entsprechen, das in den LDAP-Records benutzt wird. Wenn kein Cluster-Name definiert ist, dann versucht sendmail, die LDAP-Records mit Hilfe des voll qualifizierten Hostnamens des sendmail-hosts zu beziehen, was nur funktioniert, wenn bei den LDAP-Records dieser Wert mit einem sendmailmtahost-attribut gesetzt wurde. Dieses Rezept setzt außerdem den im Makro VIRTUSER_DOMAIN_FILE ein, um die Klasse $={VirtHost} vom LDAP-Server zu laden. Das ist für unser Ziel, die virtusertable-daten von einem LDAP-Server zu lesen, nicht unbedingt erforderlich, ist aber notwendig, um die Konfiguration aus Rezept 5.6 zu duplizieren. Außerdem zeigt es, dass Klassen von einem LDAP-Server geladen werden können. Das Wesentliche ist hier nicht, die Konfiguration aus Rezept 5.6 zu duplizieren das Wesentliche ist zu demonstrieren, dass jede virtusertable-konfiguration mit Hilfe eines LDAP-Servers dupliziert werden kann. Nachdem dieses Rezept auf dem System installiert wurde, zeigen einige schnelle Tests, dass die LDAP-Daten nun sendmail zur Verfügung stehen. Hier wird sendmail -bt benutzt, um die LDAP-Daten zu untersuchen: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $={VirtHost} school.ora.com shop.wrotethebook.org hotel.example.com > /map map_lookup: virtuser (@mall.shop.wrotethebook.org) returns pat (0) > /quit Der Befehl $={VirtHost} gibt den Inhalt der Klasse $={VirtHost} aus. Er zeigt, dass die Daten, die für $={VirtHost} in der LDAP-Datenbank definiert wurden, geladen worden sind. Der Befehl /map wird verwendet, um die virtuser-datenbank wrotethebook.org als Schlüssel zu durchsuchen. Die Suche liefert den Wert pat zurück. Das haben wir genau erwartet, wenn wir die Records zu Grunde legen, die wir der LDAP- Datenbank in diesem Rezept hinzugefügt haben. Es wurden ganz klar LDAP-Daten für die Klasse $={VirtHost} und für die virtusertable verwendet. Tatsächlich können die Daten für alle sendmail-datenbanken und für alle sendmail-klassen zentral durch einen LDAP-Server definiert werden. sendmail behandelt alle Daten ungeachtet der Quelle gleich. 5.8 Die virtusertable über LDAP lesen 199

218 Siehe auch Rezept 5.6 behandelt die virtusertable sowie die Klasse $={VirtHost}. Das Buch sendmail behandelt das Makro VIRTUSER_DOMAIN_FILE in Abschnitt , die virtusertable in Abschnitt und die Definition confldap_cluster in Abschnitt LDAP wird im Abschnitt Using LDAP for Aliases, Maps, and Classes der Datei cf/readme beschrieben. Links 5.9 Mail mit LDAP routen Problem Ihr Unternehmen möchte das IETF Internet Draft LDAP Schema for Intranet Mail Routing verwenden. Sie wurden gebeten, sendmail so zu konfigurieren, dass es das IETF-Draft- Schema einsetzt und interne Informationen zum Mail-Routing vom LDAP-Server liest. Lösung Diese Lösung erfordert die Zusammenarbeit von LDAP-Administrator und sendmail- Administrator. Anweisungen für den LDAP-Administrator Beschaffen Sie sich eine Kopie des IETF-Draft-Schemas für das Intranet-Mail-Routing. Das Schema ist in der Datei draft-lachman-laser-ldap-mail-routing-02 dokumentiert, die unter zur Verfügung steht. Es ist als Teil der Datei misc.schema definiert, die in der OpenLDAP-Distribution enthalten ist. Binden Sie die Schema-Datei in die LDAP-Konfiguration ein, indem Sie der Datei slapd.conf den folgenden include-befehl hinzufügen: include /etc/openldap/schema/misc.schema In der Diskussion finden Sie Informationen über einen möglichen Konflikt zwischen der Datei misc.schema und einem anderen Schema. Zusätzlich muss die Datei sendmail.schema in den richtigen Pfad kopiert und in die LDAP-Konfiguration eingefügt werden, wie in Rezept 1.3 beschrieben. Starten Sie LDAP neu, um sicherzustellen, dass das IETF-Draft-Schema und das sendmail-schema für die Benutzung zur Verfügung stehen. Hier ist ein Beispiel: # ps -ax grep slapd 1426? S 0:00 /usr/sbin/slapd -u ldap # kill -TERM 1426 # /usr/sbin/slapd -u ldap Legen Sie eine LDIF-Datei an, die die Mail-Routing-Informationen enthält. Nutzen Sie die Objektklasse inetlocalmailrecipient aus dem IETF-Draft-Schema, um die Mail- 200 Kapitel 5: Mail-Routing

219 Rechts Routing-Daten in der LDIF-Datei zu formatieren. Führen Sie ldapadd aus, um die Daten in die LDAP-Datenbank einzufügen. Die Diskussion zeigt ein Beispiel für diesen Schritt. sendmail wendet das LDAP-Routing auf eine Empfängeradresse an, wenn der Host- Anteil dieser Adresse in der Klasse $={LDAPRoute} aufgeführt ist. Um die $={LDAPRoute}- Klassenwerte auf dem LDAP-Server zu speichern, erzeugen Sie eine LDIF-Datei, die ein sendmailmtaclass-record enthält. Dabei handelt es sich um eine Objektklasse, die in der Datei sendmail.schema definiert ist. Setzen Sie das Attribut sendmailmtaclassname auf LDAPRoute, und definieren Sie die Werte für diese Klasse mit den sendmailmtaclassvalue- Attributen. Verwenden Sie ldapadd, um die LDIF-Datei umzuwandeln und die Daten in die LDAP-Datenbank einzubinden. Anweisungen für den sendmail-administrator Weisen Sie sendmail an, das LDAP-Intranet-Mail-Routing zu verwenden, indem Sie die Funktion ldap_routing der Konfiguration hinzufügen. Fügen Sie das Makro LDAPROUTE _DOMAIN_FILE hinzu, um die Klasse $={LDAPRoute} zu laden, die vom LDAP-Server bezogen werden kann. Folgende Zeilen sollten Sie in die sendmail-konfiguration aufnehmen: dnl Stop Build from complaining define(`confldap_default_spec', ` -h ldserver -b dc=wrotethebook,dc=com') dnl Identify the recipient hosts that require LDAP mail routing LDAPROUTE_DOMAIN_FILE(`@LDAP') dnl Enable the ldap_routing feature FEATURE(`ldap_routing') Erstellen Sie die Datei sendmail.cf neu, und installieren Sie sie. Starten Sie anschließend sendmail neu, wie in Rezept 1.8 beschrieben. Diskussion Diese Diskussion behandelt sowohl die LDAP- als auch die sendmail-konfiguration. Die LDAP-Konfiguration Damit eine Abfrage erfolgreich verläuft, müssen sendmail und LDAP das gleiche Schema verwenden und verstehen. Die Funktion ldap_routing hängt von einem Mail-Routing- Schema ab, das in einem Draft-IETF-Dokument definiert ist. Dieses Schema, das in der Datei misc.schema der OpenLDAP-Distribution zur Verfügung steht, muss in die LDAP- Konfiguration aufgenommen werden, damit LDAP die Mail-Routing-Anfragen versteht, die von sendmail kommen. Ein Problem könnte auftreten, wenn Sie versuchen, LDAP neu zu starten, nachdem Sie die Datei misc.schema in die Konfiguration eingefügt haben. Der Fehler könnte folgendermaßen aussehen: /etc/openldap/schema/redhat/rfc822-mailmember.schema: line 7: Duplicate attributetype: " " 5.9 Mail mit LDAP routen 201

220 In diesem Fall wurde der include-befehl für die Datei misc.schema in die Datei slapd.conf vor einem rfc822-mailmember.schema-include-befehl eingefügt. Als LDAP versuchte, die Datei rfc822-mailmember.schema zu verarbeiten, stellte es fest, dass der Attributtyp bereits deklariert worden war in diesem Fall durch die Datei misc.schema. Falls Sie ein solches Problem haben, müssen Sie den Konflikt lösen. Die Auflösung ist hier ganz einfach entfernen Sie den rfc822-mailmember.schema-include-befehl ganz einfach aus der Datei slapd.conf. Der include-befehl kann gefahrlos gelöscht werden, da die Datei rfc822-mailmember.schema die letzten beiden Einträge in der Datei misc.schema exakt dupliziert. Dieses spezielle Problem trat auf Red Hat-Linux-Systemen auf, weil es sich um einen Konflikt mit einer Schema-Datei handelt, die von Red Hat bereitgestellt wurde. Konflikte sind jedoch jederzeit möglich, sobald mehrere Schema-Dateien in die LDAP-Konfiguration aufgenommen werden. Links Fügen Sie die Datei sendmail.schema in die LDAP-Konfiguration ein, um Unterstützung für die anderen LDAP-Records zu gewähren, die von sendmail benutzt werden. Beispielsweise liest die sendmail-konfiguration in diesem Rezept LDAP-Records, um die Klasse $={LDAPRoute} zu laden, die das sendmail-schema verlangt. Nachdem die Schema- Dateien zur Datei slapd.conf hinzugekommen sind, starten Sie slapd neu, um sicherzustellen, dass die Schema-Dateien gelesen wurden und benutzt werden können. Fügen Sie die Records, die von der Funktion ldap_routing verlangt werden, mit Hilfe des Draft-IETF-Schemas zur LDAP-Datenbank hinzu. Dieses Beispiel zeigt drei mögliche Varianten des LDAP-Routing-Records: # cat > ldap-routing dn: uid=kathy, dc=wrotethebook, dc=com objectclass: inetlocalmailrecipient maillocaladdress: kathy@rodent.wrotethebook.com mailroutingaddress: kathy@chef.wrotethebook.com dn: uid=alana, dc=wrotethebook, dc=com objectclass: inetlocalmailrecipient maillocaladdress: alana@wrotethebook.com mailhost: chef.wrotethebook.com dn: uid=craig, dc=wrotethebook, dc=com objectclass: inetlocalmailrecipient maillocaladdress: craig@horseshoe.wrotethebook.com mailhost: chef.wrotethebook.com mailroutingaddress: craig@crab.wrotethebook.com Ctrl-D # ldapadd -x -D "cn=manager,dc=wrotethebook,dc=com" \ > -W -f ldap-routing Enter LDAP Password: SecretLDAPpassword adding new entry "uid=kathy, dc=wrotethebook, dc=com" adding new entry "uid=alana, dc=wrotethebook, dc=com" adding new entry "uid=craig, dc=wrotethebook, dc=com" 202 Kapitel 5: Mail-Routing

221 Rechts Die Objektklasse der Records ist inetlocalmailrecipient. Jedes Record enthält ein maillocaladdress-attribut, das von sendmail als Datenbankschlüssel verwendet wird. Records können eines oder mehrere der Attribute mailhost und mailroutingaddress enthalten, wobei es sich um die Werte handelt, die durch die LDAP-Datenbank an sendmail zurückgeliefert werden. Das Beispiel zeigt, wie diese Werte zuerst benutzt werden, um eine LDIF-Datei anzulegen, die dann durch ldapadd verarbeitet wird, um die Records in die LDAP-Datenbank einzufügen. Sobald sich die Records in der Datenbank befinden, können sie mit ldapsearch betrachtet werden: # ldapsearch -LLL -x '(objectclass=inetlocalmailrecipient)' \ > maillocaladdress mailhost mailroutingaddress dn: uid=kathy, dc=wrotethebook, dc=com maillocaladdress: kathy@rodent.wrotethebook.com mailroutingaddress: kathy@chef.wrotethebook.com dn: uid=alana, dc=wrotethebook, dc=com maillocaladdress: alana@wrotethebook.com mailhost: chef.wrotethebook.com dn: uid=craig, dc=wrotethebook, dc=com maillocaladdress: craig@horseshoe.wrotethebook.com mailhost: chef.wrotethebook.com mailroutingaddress: craig@crab.wrotethebook.com sendmail fragt den LDAP-Server nur nach Routing-Informationen, wenn der Host-Anteil der Empfängeradresse in der Klasse $={LDAPRoute} aufgeführt wird. Werte in dieser Klasse können einzeln mit Hilfe von LDAPROUTE_DOMAIN-Makros definiert werden. Sie können aber auch mit dem Makro LDAPROUTE_DOMAIN_FILE aus einer Datei gelesen werden. Die sendmail-konfiguration in diesem Rezept verwendet das Makro LDAPROUTE_DOMAIN_ FILE und liest die Liste der Werte für die Klasse $={LDAPRoute} vom LDAP-Server. Das folgende Beispiel zeigt, wie der LDAP-Administrator die $={LDAPRoute}-Daten auf dem LDAP-Server speichern könnte, so dass sendmail später an diese herankommen kann: # cat > ldap-route-domains dn: sendmailmtaclassname=ldaproute, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtaclass sendmailmtahost: rodent.wrotethebook.com sendmailmtaclassname: LDAPRoute sendmailmtaclassvalue: rodent.wrotethebook.com sendmailmtaclassvalue: wrotethebook.com sendmailmtaclassvalue: horseshoe.wrotethebook.com Ctrl-D # ldapadd -x -D "cn=manager,dc=wrotethebook,dc=com" \ > -W -f ldap-route-domains Enter LDAP Password: SecretLDAPpassword adding new entry "sendmailmtaclassname=ldaproute, dc=wrotethebook, dc=com" Die Beispiel-LDIF-Datei enthält ein sendmailmtaclass-record, bei dem es sich um eine Objektklasse handelt, die in der Datei sendmail.schema gespeichert ist. Das Record setzt das Attribut sendmailmtaclassname auf LDAPRoute und definiert die Werte für diese Klasse 5.9 Mail mit LDAP routen 203

222 mit Hilfe der sendmailmtaclassvalue-attribute. Nachdem die LDIF-Datei umgewandelt und mit dem ldapadd-befehl in die LDAP-Datenbank eingefügt wurde, zeigt ein ldapsearch-befehl den Inhalt des LDAP-Records: # ldapsearch -LLL -x '(sendmailmtaclassname=ldaproute)' sendmailmtaclassvalue dn: sendmailmtaclassname=ldaproute, dc=wrotethebook, dc=com sendmailmtaclassvalue: rodent.wrotethebook.com sendmailmtaclassvalue: wrotethebook.com sendmailmtaclassvalue: horseshoe.wrotethebook.com LDAP ist bereit; nun muss noch sendmail konfiguriert werden. Die sendmail-konfiguration Drei Befehle in der sendmail-konfiguration dieses Rezepts sorgen dafür, dass sendmail die LDAP-Records benutzen kann, die wir gerade erzeugt haben: die Definition confldap_ DEFAULT_SPEC, das Makro LDAPROUTE_DOMAIN_FILE und die Funktion ldap_routing. Die Definition confldap_default_spec legt Standardwerte fest, die sendmail verwendet, um auf die LDAP-Datenbank zuzugreifen. Bei vielen sendmail-konfigurationen, die LDAP benutzen, ist die confldap_default_spec-definition nicht erforderlich, weil die vorgegebenen Werte korrekt sind. Die Definition confldap_default_spec wird in diesem Rezept eingesetzt, um zu verhindern, dass sendmail eine Warnmeldung ausgibt. Wenn sendmail mit der Funktion ldap_routing konfiguriert wird, beschwert es sich jedes Mal, wenn die Konfiguration beim Ausführen nicht auch noch die Definition confldap_ DEFAULT_SPEC enthält. Zum Beispiel: WARNING: Using default FEATURE(ldap_routing) map definition(s) without setting confldap_default_spec option. Indem Sie die Definition confldap_default_spec zur Konfiguration dieses Rezepts hinzufügen, wird diese Warnung unterdrückt, allerdings müssen Sie Sorgfalt walten lassen, um die richtigen Werte für diese Definition einzustellen. Wenn die Werte in der Definition confldap_default_spec falsch sind, ist sendmail nicht in der Lage, den LDAP-Server erfolgreich abzufragen. Die Beispieldefinition confldap_default_spec im Lösungsabschnitt enthält zwei Werte: -h -b Das Argument -h definiert den Hostnamen des LDAP-Servers. Falls Sie mehrere Server haben, dann benutzen Sie den Hostnamen des Servers, auf dem die sendmail- Daten gespeichert sind. Haben Sie nur einen einzigen Server, dann hat der HOST- Wert, den Sie in der Datei ldap.conf konfiguriert haben, wahrscheinlich bereits den Hostnamen, den Sie hier benutzen müssen. Das Argument -b definiert den vorgegebenen LDAP-Basis-Distinguished-Name, der für sendmail-abfragen benutzt wird. Der Wert sollte dem Suffix der Datenbank entsprechen, die Sie abfragen wollen, wie in der slapd.conf durch den Eintrag suffix für diese Datenbank definiert. Das in diesem Rezept verwendete Suffix ist die System- Links 204 Kapitel 5: Mail-Routing

223 Rechts vorgabe, die durch den Befehl BASE in der Datei ldap.conf für alle LDAP-Clients definiert ist. Da dieses Rezept auf die Systemvorgaben zurückgreift, ist es nicht unbedingt erforderlich, es mit dem Befehl confldap_default_spec festzulegen. Die Werte, die durch die Definition confldap_default_spec bestimmt werden, erscheinen in der Datei sendmail.cf auf der LDAPDefaultSpec-Optionszeile, wie dieses grep zeigt: # grep LDAPDefaultSpec sendmail.cf O LDAPDefaultSpec= -h ldserver -b dc=wrotethebook,dc=com Testen Sie mit ldapsearch die -h- und -b-werte, wie in diesem Beispiel gezeigt: # ldapsearch -LLL -x -h ldserver \ > b 'dc=wrotethebook,dc=com' \ > '(objectclass=inetlocalmailrecipient)' maillocaladdress dn: uid=kathy, dc=wrotethebook, dc=com maillocaladdress: kathy@rodent.wrotethebook.com dn: uid=alana, dc=wrotethebook, dc=com maillocaladdress: alana@wrotethebook.com dn: uid=craig, dc=wrotethebook, dc=com maillocaladdress: craig@horseshoe.wrotethebook.com Wenn die Argumente -h und -b mit ldapsearch funktionieren, dann sollten sie es auch für sendmail tun. Der der anstelle des Dateipfades für das Makro LDAPROUTE_DOMAIN_FILE benutzt wird, weist sendmail an, die Klasse $={LDAPRoute} vom LDAP-Server zu laden. In der Konfigurationsdatei müssen entweder ein LDAPROUTE_DOMAIN_FILE-Makro oder einige LDAPROUTE_DOMAIN-Makros stehen, wenn die Funktion ldap_routing verwendet wird, weil sendmail LDAP-Routing nur für Hosts einsetzt, die in der Klasse $={LDAPRoute} aufgeführt sind. Schließlich wird das ldap_routing-makro FEATURE zur Konfiguration hinzugefügt. Die sendmail-konfiguration im Lösungsabschnitt verwendet die einfachste Form dieses Befehls, die keine optionalen Argumente enthält; in dieser Form hingegen definiert die Funktion ldap_routing mit Hilfe von zwei sendmail.cf-k-befehlen zwei Datenbanken: ldapmh akzeptiert eine Empfängeradresse als Schlüssel und liefert den Namen des Mail-Hosts zurück, der benutzt werden soll, um diese Adresse zu erreichen. Der Mail-Host, den die Datenbank ldapmh zurückgibt, wird als $h-wert für das Mail- Auslieferungstriple verwendet. ldapmra akzeptiert eine Empfängeradresse als Schlüssel und liefert die Mail-Routing- Adresse zurück, die anstelle der Empfängeradresse eingesetzt werden soll, um die Mail auszuliefern. Der Wert, der von ldapmra zurückgegeben wird, wird zum $u- Wert für das Mail-Auslieferungstriple. 5.9 Mail mit LDAP routen 205

224 Die Ergebnisse testen Einige einfache Tests zeigen die Wirkung dieses Rezepts. Zuerst demonstriert ein sendmail -bt-befehl, dass sendmail erfolgreich die LDAP-Daten liest: Links # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $={LDAPRoute} rodent.wrotethebook.com horseshoe.wrotethebook.com wrotethebook.com > /map ldapmh alana@wrotethebook.com map_lookup: ldapmh (alana@wrotethebook.com) returns chef.wrotethebook.com (0) > /map ldapmra kathy@rodent.wrotethebook.com map_lookup: ldapmra (kathy@rodent.wrotethebook.com) returns kathy@chef.wrotethebook.com (0) > /quit Der Befehl $={LDAPRoute} zeigt, dass sendmail diese Klasse erfolgreich vom LDAP-Server geladen hat. Der Befehl /map zeigt, dass sendmail LDAP-Routing-Daten sowohl aus der Datenbank ldapmh als auch aus der Datenbank ldapmra lesen kann. Als Nächstes wird sendmail -bv verwendet, um zu zeigen, wie die Mail-Auslieferungstriples für Empfängeradressen umgeschrieben werden, in denen Hostnamen enthalten sind, die in $={LDAPRoute} aufgeführt werden: # sendmail -bv kathy@rodent.wrotethebook.com kathy@rodent.wrotethebook.com... deliverable: mailer esmtp, host chef.wrotethebook.com., user kathy@chef.wrotethebook.com # sendmail -bv alana@wrotethebook.com alana@wrotethebook.com... deliverable: mailer relay, host chef.wrotethebook.com, user alana@wrotethebook.com # sendmail -bv craig@horseshoe.wrotethebook.com craig@horseshoe.wrotethebook.com... deliverable: mailer relay, host chef.wrotethebook. com, user craig@crab.wrotethebook.com Schauen Sie noch einmal nach ldapsearch in einem früheren Beispiel. Sie werden feststellen, dass das Record für kathy@rodent.wrotethebook.com nur eine Mail-Routing-Adresse zurückliefert. das Record für alana@wrotethebook.com nur einen Mail-Host zurückgibt. das Record für craig@horseshoe.wrotethebook.com sowohl einen Mail-Host als auch eine Mail-Routing-Adresse zurückliefert. Die sendmail -bv-tests zeigen, wie diese verschiedenen Rückgabewerte das Mail-Auslieferungstriple beeinflussen: Im ersten Test wird die Mail-Routing-Adresse zum Benutzerwert des Triples. Die Mailer- und Host-Werte sind erforderlich, um an diese Benutzeradresse auszuliefern. 206 Kapitel 5: Mail-Routing

225 Rechts Im zweiten Test wird aus dem Mail-Host, der durch die LDAP-Abfrage zurückgeliefert wird, der Host-Wert im Auslieferungstriple. Bei dem verwendeten Mailer handelt es sich um relay, da die Mail an diesen Host zur Auslieferung weitervermittelt wird. Weil durch das LDAP keine Mail-Routing-Adresse zurückgegeben wurde, wird der Relay Host an die ursprüngliche Adresse geschickt. Nun ist der entfernte Host dafür verantwortlich, Mail an diese Adresse auszuliefern. Der dritte Test liefert sowohl einen Mail-Host-Wert als auch eine Mail-Routing- Adresse. In diesem Fall wird wiederum der Mailer relay eingesetzt, um Mail an den entfernten Host zu vermitteln, der durch den Mail-Host-Wert festgelegt wurde. Bei der Auslieferungsadresse, die an diesen Host übergeben wird, handelt es sich um die Mail-Routing-Adresse. Nun ist dieser entfernte Host dafür verantwortlich, die Mail an die Mail-Routing-Adresse auszuliefern. Das LDAP-Routing stellt nur einen Schritt im Auslieferungsprozess dar. virtusertable und mailertable werden beide nach dem LDAP-Routing angewandt. Und wenn bei dem Mailer, der zur Auslieferung an den vom LDAP zurückgegebenen Host verwendet wird, der Schalter F=A gesetzt ist, dann werden auch noch Aliase aufgelöst. 5 Falls die Mail an einen entfernten Host weitergeleitet wird, verarbeitet dieser Host auch die Adresse. Die Ergebnisse des sendmail -bv-tests zeigen deutlich die Wirkung des LDAP-Routings allerdings nur teilweise, da dieses Rezept an diesen Adressen keine weiteren Verarbeitungsschritte ausführt. Auf einem Produktionssystem mit einer komplexeren Konfiguration liefert sendmail -bv möglicherweise nicht so deutliche Ergebnisse. Es ist jedoch möglich, die Wirkung des LDAP-Regelsatzes direkter zu testen. Die Funktion ldap_routing fügt den Regelsatz LDAPExpand hinzu, um LDAP abzufragen und den Rückgabewert zu verarbeiten, und fügt zwei Regeln zum Regelsatz Parse1 hinzu, um den neuen Regelsatz aufzurufen. Nutzen Sie sendmail -bt, um zu prüfen, ob das LDAP-Routing auf eine bestimmte Adresse angewandt wird oder nicht, und um das Mail-Auslieferungstriple anzuschauen, das für diese Adresse zurückgegeben wird. Hier ist ein Beispiel: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > Parse1 craig<@horseshoe.wrotethebook.com.> Parse1 input: craig horseshoe. wrotethebook. com. > LDAPExpand input: < craig horseshoe. wrotethebook. com. > > < horseshoe. wrotethebook. com > < > canonify input: crab. wrotethebook. com Canonify2 input: craig crab. wrotethebook. com > Canonify2 returns: craig crab. wrotethebook. com. > canonify returns: craig crab. wrotethebook. com. > LDAPExpand returns: $# relay $@ chef. wrotethebook. com $: craig crab. wrotethebook. com. > 5 Der Schalter F=A ist für den Mailer local standardmäßig gesetzt. 5.9 Mail mit LDAP routen 207

226 Parse1 returns: $# relay chef. wrotethebook. com $: craig crab. wrotethebook. com. > > /quit Rezept 5.10 zeigt ein weiteres Beispiel dafür, wie Sie die Funktion ldap_routing dadurch testen, dass Sie eine Adresse an Parse1 übergeben. 6 In Rezept 5.10 finden Sie weitere Einzelheiten über diesen Regelsatz. Links Die Funktion ldap_routing Der ldap_routing-befehl FEATURE, der in diesem Rezept zum Einsatz kommt, stellt die einfachste Form dieses Befehls dar. Der Befehl akzeptiert bis zu vier optionale Argumente. Die vollständige Syntax sieht so aus: FEATURE(ldap_routing, mhmap, mramap, bounce, detail) Die vier optionalen Argumente sind: mhmap Dies ist eine eigene Definition für eine Mail-Host-Datenbank. Sie ersetzt die vorgegebene ldapmh-datenbank, die durch die Funktion ldap_routing erzeugt wurde. Die Datenbankdefinition muss mindestens die Argumente -k und -v enthalten. mramap Dies ist eine eigene Definition für eine Mail-Routing-Adressdatenbank. Sie ersetzt die vorgegebene ldapmra-datenbank, die durch die Funktion ldap_routing erzeugt wurde. Die Datenbankdefinition muss mindestens die Argumente -k und -v enthalten. bounce Dieses Argument teilt sendmail mit, was zu tun ist, wenn eine Empfängeradresse nicht in der LDAP-Datenbank gefunden werden kann. Normalerweise wird die Auslieferung fortgesetzt und sendmail liefert die Mail an die Empfängeradresse aus, wie es durch die restliche Konfiguration angewiesen wird. Für dieses Argument können zwei Schlüsselwörter verwendet werden: passthru Dieses Schlüsselwort weist sendmail an, mit der Auslieferung fortzufahren. Hierbei handelt es sich um die Standardaktion. bounce Dieses Schlüsselwort weist sendmail an, die Mail als nicht auslieferbar zurückgehen zu lassen. Tatsächlich veranlasst jeder andere Wert als passthru sendmail, die Mail abzuweisen; der Klarheit wegen schlagen jedoch die sendmail- Entwickler vor, dass Sie das Schlüsselwort bounce verwenden, um die Mail abzuweisen. 6 Die spitzen Klammern (<>) werden in der Adresse verwendet, weil Parse1, das normalerweise aufgerufen wird, nachdem canonify diese eingefügt hat, spitze Klammern erwartet. 208 Kapitel 5: Mail-Routing

227 Rechts detail Dies teilt sendmail mit, wie Empfängeradressen zu behandeln sind, die die +detail- Syntax verwenden. Standardmäßig wird eine Adresse, die +detail-informationen enthält, so nachgesehen, wie sie ist, mit intakten +detail-informationen. Es können zwei Schlüsselwörter verwendet werden, um dieses Verhalten zu ändern: strip Dieses Schlüsselwort weist sendmail an, zuerst die Adresse mit den +detail- Informationen nachzusehen, und anschließend die Adresse ohne die +detail- Informationen zu suchen, falls keine Übereinstimmung gefunden wurde. preserve Dieses Schlüsselwort weist sendmail ebenso wie strip an, zuerst die Adresse mit den +detail-informationen nachzusehen und anschließend die Adresse ohne die +detail-informationen zu suchen, falls keine Übereinstimmung gefunden wurde. Neben der Änderung des Suchvorgangs modifiziert dieses Schlüsselwort den Wert, der von der LDAP-Datenbank zurückgeliefert wird. Wenn LDAP eine Mail-Routing-Adresse zurückgibt, dann hängt sendmail die +detail- Informationen aus der Empfängeradresse an die Mail-Routing-Adresse an, wenn das Schlüsselwort preserve angegeben wurde. Siehe auch Das Buch sendmail behandelt das Makro LDAPROUTE_DOMAIN_FILE in Abschnitt , die Funktion ldap_routing in Abschnitt und die Argumente, die für die Definition confldap_default_spec zur Verfügung stehen, in Abschnitt Der Abschnitt Using LDAP for Aliases, Maps, and Classes der Datei cf/readme hält ebenfalls wichtige Informationen bereit LDAP-Routing mit Masquerading benutzen Problem Wenn der Hostnamenanteil der -Adresse, die dem Attribut maillocaladdress eines LDAP-Routing-Records zugewiesen ist, ein Masquerading-Wert ist, dann muss sendmail den Hostnamen aus der Empfängeradresse in den Masquerading-Namen umwandeln, bevor es eine LDAP-Suche vornimmt. Sie wurden gebeten, sendmail entsprechend zu konfigurieren. Lösung Rezept 5.9 liefert dem LDAP-Administrator Informationen über das Aktivieren der Unterstützung für das IETF-Draft-Schema für das Intranet-Mail-Routing und über die Datei sendmail.schema in der LDAP-Konfigurationsdatei. Dieses Rezept erläutert außer LDAP-Routing mit Masquerading benutzen 209

228 dem, wie Mail-Routing-Daten in die LDAP-Datenbank eingefügt werden können. Lesen Sie Rezept 5.9, bevor Sie weitermachen. Legen Sie auf dem sendmail-host eine Datei namens ldaproute-equivalents an, um die Klasse $={LDAPRouteEquiv} zu laden. Listen Sie Hostnamen in der Datei auf, die in den MASQUERADE_AS-Hostnamen umgewandelt werden sollten, bevor der LDAP-Server nach Routing-Informationen abgefragt wird. Hier ist ein Beispiel: # cd /etc/mail # cat > ldaproute-equivalents jamis.wrotethebook.com giant.wrotethebook.com horseshoe.wrotethebook.com Ctrl-D Erzeugen Sie eine sendmail-konfiguration, die das Makro MASQUERADE_AS, die Definition confldap_default_spec, die Funktion ldap_routing und das Makro LDAPROUTE_ EQUIVALENT_FILE enthält, das die Klasse $={LDAPRouteEquiv} lädt. Hier sehen Sie ein Beispiel für die Zeilen, die in die sendmail-konfiguration aufgenommen werden könnten: dnl Define the masquerade value MASQUERADE_AS(`wrotethebook.com') dnl Stop Build from complaining define(`confldap_default_spec', ` -h ldserver -b dc=wrotethebook,dc=com') dnl Load $={LDAPRouteEquiv} from ldaproute-equivalents LDAPROUTE_EQUIVALENT_FILE(`/etc/mail/ldaproute-equivalents') dnl Enable the ldap_routing feature FEATURE(`ldap_routing') Erstellen Sie entsprechend den Anweisungen in Rezept 1.8 die Datei sendmail.cf neu, installieren Sie sie, und starten Sie anschließend sendmail neu. Diskussion Wenn ein Empfänger-Host Mitglied der Klasse $={LDAPRouteEquiv} ist, dann wandelt sendmail den Namen des Hosts in den MASQUERADE_AS-Hostnamen um, bevor es den LDAP-Server nach Routing-Informationen abfragt. Hostnamen können mit Hilfe von LDAPROUTE_EQUIVALENT-Makros einzeln in $={LDAPRouteEquiv} eingefügt werden. Oder Sie laden die Hostnamen mit dem Makro LDAPROUTE_EQUIVALENT_FILE aus einer Datei (oder vom LDAP-Server) in die Klasse. Dieses Rezept verwendet eine lokale ldaprouteequivalents-datei. Das Makro MASQUERADE_AS muss in dieser sendmail-konfiguration enthalten sein, weil die Hostnamen, die in der Klasse $={LDAPRouteEquiv} aufgeführt sind, in den Masquerading- Namen konvertiert werden. Die Beispielkonfiguration im Lösungsabschnitt gibt wrotethebook.com als MASQUERADE_AS-Wert an. Falls daher der Host-Anteil einer Empfängeradresse einem Wert in $={LDAPRouteEquiv} entspricht, wird er vor der Abfrage des LDAP-Servers in wrotethebook.com umgewandelt. Links 210 Kapitel 5: Mail-Routing

229 Rechts Die Definition confldap_default_spec legt den Hostnamen des LDAP-Servers sowie den Basis-Distinguished-Name fest, den sendmail verwendet, um den LDAP-Server abzufragen. Weshalb das in dieser Konfiguration erforderlich ist, wird in der Diskussion von Rezept 5.9 ebenso erläutert wie der ldap_routing-befehl FEATURE und seine Syntax. Nachdem dieses Rezept installiert worden ist, nutzen Sie sendmail -bt, um die Wirkung der Konfiguration auf sendmail-variablen und auf das Routing von Mail an bestimmte Adressen zu überprüfen. Hier ist ein Beispiel: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $M wrotethebook.com > $={LDAPRouteEquiv} giant.wrotethebook.com jamis.wrotethebook.com horseshoe.wrotethebook.com > Parse1 alana<@jamis.wrotethebook.com.> Parse1 input: alana jamis. wrotethebook. com. > LDAPExpand input: < alana jamis. wrotethebook. com. > > < wrotethebook. com > < > LDAPExpand returns: $# relay $@ chef. wrotethebook. com $: alana jamis. wrotethebook. com. > Parse1 returns: $# relay $@ chef. wrotethebook. com $: alana jamis. wrotethebook. com. > > /quit Der Befehl $M zeigt den Masquerading-Wert, der in diesem Fall wrotethebook.com lautet. Der Befehl $={LDAPRouteEquiv} zeigt die Liste der Empfängerhosts, die in den Masquerading-Wert konvertiert werden, bevor sie an den LDAP-Server übergeben werden. Die nächste Befehlszeile ruft den Regelsatz Parse1 auf und übergibt ihm die Empfängeradresse alana@jamis.wrotethebook.com mit den korrekt eingefügten spitzen Klammern. Die Funktion ldap_routing fügt dem Regelsatz Parse1 zwei Regeln hinzu, die den Regelsatz LDAPExpand aufrufen. Eine Regel ruft LDAPExpand auf, um Hosts zu verarbeiten, die in $={LDAPRoute} aufgeführt werden, und die andere ruft sie auf, um Hosts zu verarbeiten, die in $={LDAPRouteEquiv} stehen. Wenn Parse1 LDAPExpand aufruft, übergibt es drei Werte: die ursprüngliche Adresse, die als durchzureichender Wert verwendet wird, die Adresse für die Suche und alle +detail-informationen. Der Parse1 alana<@jamis.wrotethebook.com.>-test zeigt Folgendes: Wenn Parse1 eine Adresse übergeben wird, die einen Hostnamen enthält, der in $={LDAPRouteEquiv} gefunden wird, dann ruft Parse1 wiederum den Regelsatz LDAPExpand auf und übergibt ihm die ursprüngliche Adresse als ersten Parameter und eine umgeschriebene Adresse als zweiten Parameter. Die umgeschriebene Adresse enthält den Masquerading-Wert als Host- Anteil. Der Regelsatz LDAPExpand fragt den LDAP-Server ab und verarbeitet die Antwort des LDAP-Servers. Wie der Test zeigt, liefert LDAPExpand ein Mail-Auslieferungstriple zurück. Beachten Sie, dass der Mailer in dem Triple relay ist. Der Host in dem Triple ist 5.10 LDAP-Routing mit Masquerading benutzen 211

230 chef.wrotethebook.com. Der Relay-Hostname stammt vom LDAP-Server und kam als Antwort auf eine Abfrage mit der Masquerading-Adresse, wie diese ldapsearch-tests zeigen: # ldapsearch -LLL x \ > '(&(objectclass=inetlocalmailrecipient) \ > (maillocaladdress=alana@wrotethebook.com))' mailhost dn: uid=alana, dc=wrotethebook, dc=com mailhost: chef.wrotethebook.com # ldapsearch -LLL -x \ > '(&(objectclass=inetlocalmailrecipient) \ > (maillocaladdress=alana@jamis.wrotethebook.com))' mailhost Der erste ldapsearch-test zeigt, dass ein Record für alana@wrotethebook.com in der LDAP-Datenbank gefunden wurde. Der zweite Test zeigt, dass alana@jamis.wrotethebook.com nicht in der LDAP-Datenbank steht. jamis.wrotethebook.com muss ganz offensichtlich in wrotethebook.com umgeschrieben werden, damit die Suche erfolgreich ist. Links Siehe auch Rezept 5.9 behandelt ganz ausführlich den ldap_routing-befehl FEATURE und die confldap_default_spec. Außerdem enthält es ein Beispiel für das Laden einer sendmail- Klasse von einem LDAP-Server. Die Datei cf/readme behandelt dieses Thema im Abschnitt Using LDAP for Aliases, Maps, and Classes. Das Buch sendmail behandelt das Makro LDAPROUTE_EQUIVALENT_FILE in Abschnitt , die Funktion ldap_routing in Abschnitt und die Argumente, die für die Funktion confldap_default_spec zur Verfügung stehen, in Abschnitt Kapitel 5: Mail-Routing

231 First Kapitel 6 KAPITEL 6 Spam unter Kontrolle halten 6.0 Einführung Spam-Mail: Sie erkennen sie, wenn Sie sie sehen, und jeder hat vermutlich bereits einmal mit den lächerlichen Werbeanzeigen für Investmentpläne, Pornografie, Kräuterkuren und andere unmögliche Dinge zu tun gehabt. Viele Experten bezeichnen alle unverlangt zugesandten kommerziellen s (Unsolicited Commercial ; UCE) als Spam, und sicherlich verstopft UCE elektronische Postfächer auf der ganzen Welt. Allerdings sind rechtmäßige Reklametreibende, die echte»ausstiegsprogramme«(opt-out schemes) bieten, nicht das größte Problem. 1 Die wirklichen Probleme stammen von Spammern. Spammer unterscheiden sich von rechtmäßigen Werbern dadurch, dass sie ihre Identität verbergen und die Systeme anderer Leute missbrauchen. Diese Eigenschaften zeigen sich folgendermaßen: Spammer verbergen den Ursprung der , so dass niemand weiß, wer sie gesandt hat. Seriöse Werbetreibende präsentieren in der Absenderadresse stolz den Namen ihres Unternehmens. Jeder Werber, der dies nicht tut, hat vermutlich einen Grund zu verbergen, wer er ist und was er tut, und sollte als Spammer betrachtet werden. Spammer missbrauchen die Dienste der Systeme anderer Leute, indem sie diese Systeme als nicht autorisierte Relays verwenden. Spammer senden Informationen, die Sie niemals angefordert haben. Sie treten nicht der Mailingliste eines Spammers bei. Und wenn Spammer ein Ausstiegsprogramm anbieten, dann sorgt es nicht dafür, dass ein Benutzer irgendwo wieder aussteigen kann. Stattdessen wird dieses Programm dazu eingesetzt, -Adressen zu sammeln, die dann an andere Spammer verkauft werden. Sie müssen Ihren Beitrag leisten, um Spam für andere zu reduzieren, indem Sie sicherstellen, dass Ihr System einerseits nicht von externen Spammern missbraucht wird und dass andererseits Ihre lokalen Benutzer nichts zu Spam beitragen. 1 Puristen wettern gegen Ausstiegsprogramme, dabei können sie funktionieren, wenn sie wirklich implementiert wurden. 213

232 Spammer benutzen offene Mail Relays, um ihre Identität zu verbergen. In den Rezepten in Kapitel 3 finden Sie Beispiele dafür, wie ein Mail Relay Host konfiguriert wird. Testen Sie Ihr Relay so, wie es in Kapitel 3 gezeigt wird, wenn Sie die Konfiguration geändert haben, damit Sie sicher sein können, dass es nicht missbraucht werden kann. Der erste Schritt, mit dem Sie lokalen Spammern begegnen können, besteht darin, akzeptable Benutzungsregeln zu schaffen, die das Versenden von Spam verbieten, und Aktionen festzulegen, die Sie unternehmen, um es zu unterbinden. Stellen Sie in der Regelung klar, dass s keine Privatangelegenheiten sind, sondern protokolliert, gescannt und gefiltert werden können. Dieses Regelwerk muss vom Management bestätigt und erlassen sowie von der Rechtsabteilung überprüft und genehmigt werden. Regeln sind immer schwierig, da es sich nicht um technische Lösungen handelt und sie außerdem das Management einbeziehen. Allerdings ist dieser Schritt erforderlich, um Ihnen die nötige Autorität zum Analysieren der Mail zu geben. Sobald die Regeln in Kraft getreten sind, müssen alle Benutzer ihnen zustimmen, um einen Benutzerzugang erhalten zu können. Zusätzlich zu den Maßnahmen, die sicherstellen, dass Ihr System nicht zum Spam-Problem beiträgt, gibt es technische Hilfsmittel, die Sie einsetzen können, um Spam aktiv zu bekämpfen. sendmail bietet eine Reihe von Werkzeugen, mit denen Sie eingehender Junk-Mail entgegentreten können: Die access-datenbank blockiert Mail von und zu bestimmten Systemen. DNS-basierte schwarze Listen (DNS Blackhole Lists) blockieren Mail von mutmaßlichen Spammern und von offenen Mail Relays. Sie können von sendmail aus auf Mail-Filterprogramme wie procmail zugreifen. Diese eignen sich dazu, Mail auf der Grundlage ihres Inhalts zu filtern. Die Header-Verarbeitung von sendmail kann verstümmelte oder inkonsistente Header entdecken. sendmail führt automatisch Sanity-Prüfungen durch, wie etwa die Prüfung, ob die Domain eines Absenders durch das DNS aufgelöst werden kann. Links Die access-datenbank Die access-datenbank bietet eine ausgefeilte Kontrolle über das Mail Relaying und die Mail-Auslieferung. Verwenden Sie die Funktion access_db, um der sendmail-konfiguration die access-datenbank hinzuzufügen: FEATURE(`access_db') Standardmäßig handelt es sich bei der access-datenbank um eine Hash-Datenbank. Ihr vorgegebener Pfadname lautet /etc/mail/access.db. Nutzen Sie das optionale Argumentfeld der Funktion access_db, um die Standardwerte zu ändern, wie in diesem Beispiel gezeigt wird: FEATURE(`access_db', `btree T<TMPF> /var/mail/access') 214 Kapitel 6: Spam unter Kontrolle halten

233 Rechts Dieses Beispiel ändert den Datenbanktyp, legt die Option -T<TMPF> für den Umgang mit temporären Lookup-Fehlern fest und ändert den Datenbankpfadnamen. Ändern Sie die Standardwerte nur dann, wenn es unbedingt erforderlich ist. Jede Zeile in der access-datenbank enthält zwei Felder: das Schlüsselfeld und den Rückgabewert. Wenn die access-datenbank benutzt wird, um Junk-Mail zu kontrollieren, dann ist der Schlüssel zur Datenbank eine Adresse, und der Rückgabewert legt die Aktion fest, die sendmail in Hinblick auf die Mail zu oder von der angegebenen Adresse ausführen soll. Als die access-datenbank in Kapitel 3 benutzt wurde, war der Rückgabewert logischerweise das Schlüsselwort RELAY. Um Spam zu kontrollieren, setzen die Rezepte in diesem Kapitel die access-datenbank ein, mit der sie festlegen, ob Mail von bestimmten Adressen angenommen bzw. an diese Adressen ausgeliefert werden darf. Dafür benötigen wir eine andere Menge von Rückgabewerten. Die Schlüsselwörter, die dazu dienen, Junk-Mail unter Kontrolle zu halten, werden in Tabelle 6-1 aufgeführt. Tabelle 6-1: Zur Spam-Kontrolle eingesetzte Schlüsselwörter der access-datenbank Schlüsselwort OK DISCARD REJECT ERROR:dsn:code text HATER FRIEND Aktion Akzeptiert Nachrichten von oder zu der angegebenen Adresse. Weist alle Nachrichten von oder zu der angegebenen Adresse ab. Gibt eine Fehlermeldung aus und weist alle Mails von oder zu der angegebenen Adresse ab. Weist die Mail mit dem angegebenen Antwortcode und der Fehlermeldung ab. Fügt die Regelsätze check_mail und check_relay für Mail an den angegebenen Empfänger hinzu. Überspringt die Regelsätze check_mail und check_relay für Mail an den angegebenen Empfänger. Der Befehl OK weist sendmail an, ungeachtet anderer Bedingungen Mail von der Quelle zu akzeptieren, die durch die Adresse im Schlüsselfeld angegeben wird. Falls beispielsweise der Hostname, der im Adressfeld festgelegt wurde, nicht durch das DNS aufgelöst werden kann, akzeptiert sendmail Mail von diesem Host sogar dann, wenn die Funktion accept_unresolvable_domains nicht aktiviert ist. OK akzeptiert Mail für die lokale Auslieferung; OK gewährt keine Relaying-Berechtigungen. Dafür ist das Schlüsselwort RELAY erforderlich, das in Kapitel 3 beschrieben wird. Das Schlüsselwort REJECT liefert eine Standardfehlermeldung an die Quelle zurück und weist die Mail ab. Die Aktion DISCARD weist die Mail ab, ohne eine Fehlermeldung zurück an die Quelle zu senden. Viele Anti-Spam-Autoritäten missbilligen die Praxis des stillschweigenden Abweisens der Mail, da sie das Gefühl haben, dass Spammer dadurch nicht entmutigt werden. So weit der Spammer weiß, haben Sie die Mail empfangen, weshalb er weiterhin Junk sendet. Andere Anti-Spam-Autoritäten ziehen es vor, Mail stillschweigend abzuweisen, da sie glauben, dass durch das Beantworten der Mail in welcher Form auch immer die Adresse für den Spammer bestätigt wird. Der Spammer wird dadurch ermutigt, mit seinen Belästigungen fortzufahren. Beide Ansätze schützen Ihre Einführung 215

234 Benutzer vor dem Spammer. Der Einsatz der Aktion REJECT jedoch, bei der eine Fehlermeldung zurückgegeben wird, ist nützlich, wenn rechtmäßige Mail fälschlicherweise als Spam eingeordnet wird, da die Quelle der Mail davon in Kenntnis gesetzt wird, dass die Mail abgewiesen wurde. Die Aktion REJECT sendet eine vorgegebene Fehlermeldung. Benutzen Sie das Schlüsselwort ERROR, um eine Nachricht mit Ihrer eigenen Fehlermeldung abzuweisen. Zum Beispiel: Links example.com ERROR:5.7.1:550 Relaying denied to spammers In diesem Fall lautet die Fehlermeldung, die an den Absender zurückgeliefert wird:»relaying denied to spammers«. Diese Fehlermeldung enthält den DSN-Code (Delivery Status Notification) sowie den SMTP-Fehlercode 550. Benutzen Sie einen gültigen DSN-Code aus RFC 1893, der kompatibel mit dem RFC-821-Fehlercode und der Nachricht ist. 2 Das Format für die Fehlermeldung, die in Tabelle 6-1 gezeigt wird, ist ERROR: dsn:code text. Dieses Format wird empfohlen, ist aber nicht notwendig. Es könnte auch ohne das Schlüsselwort ERROR oder den DSN-Code angegeben werden. Das alte Fehlerformat jedoch wird inzwischen abgelehnt. Benutzen Sie das Schlüsselwort ERROR und den DSN-Code, um die Kompatibilität mit künftigen sendmail-versionen sicherzustellen. Die Schlüsselwörter FRIEND und HATER gelten nur, wenn die Funktion delay_checks benutzt wird, um die Anwendung der Regelsätze check_mail und check_relay zu steuern. Das Schlüsselwort FRIEND im Rückgabewert erlaubt es, dass Mail, die normalerweise durch check_mail und check_relay abgewiesen werden würde, an das System des Empfängers weitergereicht werden kann, der im Schlüsselfeld angegeben wurde. Wenn HATER benutzt wird, dann werden check_mail und check_relay nur auf Mail an Empfänger angewendet, bei denen das Schlüsselwort HATER in ihren Einträgen in der access-datenbank steht. FRIEND und HATER können nicht in der gleichen access-datenbank auftauchen, da die Funktion delay_checks so konfiguriert werden muss, dass sie entweder FRIEND oder HATER akzeptiert sie kann nicht beide gleichzeitig akzeptieren. Rezept 6.13 zeigt an einem Beispiel, wie diese Schlüsselwörter benutzt werden. Die meisten der Aktionen aus Tabelle 6-1 werden so beschrieben, dass sie Mail»von oder zu«einer Adresse beeinflussen. Dies stimmt aber nur dann, wenn Tags oder die Funktion blacklist_recipients verwendet werden. Wird diese Funktion nicht eingesetzt, dann beeinflussen die Aktionen nur Mail, die von einer Quelladresse kommt, es sei denn, das Adressfeld wurde durch ein optionales To:-, From:- oder Connect:-Tag modifiziert. Diese Tags beschränken den Adresstest auf die Umschlagempfänger-, die Umschlagabsenderbzw. die Verbindungsadresse. 3 Beispielsweise könnte ein access-datenbankeintrag zum Abweisen von Verbindungen von Folgendes enthalten: Connect: ERROR:5.7.1:550 UCE not accepted 2 Kapitel 5 bietet zusätzliche Einzelheiten über DSN-Codes und listet die SMTP-Codeschlüsselwörter auf. Beachten Sie außerdem RFC Die optionalen Tags der access-datenbank werden in Kapitel 3 näher behandelt. 216 Kapitel 6: Spam unter Kontrolle halten

235 Rechts Das Connect:-Tag beschränkt den Vergleich auf die Adresse des entfernten Systems, das mit dem Server verbunden ist, um die Mail auszuliefern. Wenn diese Adresse lautet, dann wird die Mail abgewiesen und die Meldung»UCE not accepted«an den Absender zurückgeliefert. Die Adresse im Schlüsselfeld eines access-datenbankeintrags kann einen Benutzer, eine einzelne -Adresse, eine Quell-IP-Adresse, eine Netzwerkadresse oder den Namen einer Domain definieren: Eine Einzelperson wird entweder über eine vollständige -Adresse in der Form oder einen Benutzernamen in der Form identifiziert. Ein Host wird durch seinen Hostnamen oder seine IP-Adresse identifiziert. Eine Domain wird durch einen Domainnamen identifiziert. Ein Netzwerk wird durch den Netzwerkanteil einer IP-Adresse identifiziert. Neben dem Connect:-Beispiel, das in der access-datenbank gezeigt wurde, können weitere Adressformate benutzt werden, um Mail von zu identifizieren. Hier sind einige: REJECT [ ] DISCARD example.com ERROR:5.7.1:550 Mail not accepted. Die ersten beiden Zeilen in dieser access-datenbank entsprechen IP-Adressen. Der erste Eintrag weist Mail von jedem Computer ab, dessen IP-Adresse mit der Netzwerknummer beginnt, dem Netzwerk, von dem die UCE empfangen wurde. Die zweite Zeile definiert einen bestimmten Computer mit der Adresse Die eckigen Klammern, die diese Einzeladresse umgeben, zeigen an, dass diese IP-Adresse nicht zu einem Hostnamen aufgelöst wird. Der letzte Eintrag definiert eine ganze Domain. Er weist Mail von allen Hosts in der Domain example.com ab. Selbstverständlich würden Sie das nicht tun, wenn Sie nur eine einzige UCE von dieser Domain erhalten hätten. Bekommen Sie jedoch ständig Junk-Mail aus dieser Domain, dann könnten Sie beschließen, alle Mails zu blockieren, die aus dieser Domain stammen, bis dort die Sicherheit verbessert worden ist. Die Funktion dnsbl bietet eine weitere Methode zum Blockieren von Mail von bestimmten Hosts und Domains. Blackhole Lists mit dnsbl und enhdnsbl Fügen Sie der sendmail-konfiguration die Funktion dnsbl hinzu, um eine schwarze Liste (Blackhole List) zum Blockieren von Spam zu definieren. Eine Blackhole List ist eine DNS-Datenbank, die Spam-Verteiler identifiziert. Bei den Verteilern kann es sich um die ursprüngliche Quelle des Spam oder auch um offene Mail Relays handeln, die es Spammern erlauben, Mail weiterzuvermitteln. Blackhole-List-Dienste werden durch das DNS implementiert. Jedes Unix-System kann DNS-Anfragen auslösen, dies ist daher eine sehr effektive Möglichkeit, um Informationen zu verteilen. Selbstverständlich kann ein Pro- Einführung 217

236 gramm diese Informationen nur dann verwenden, wenn es sie versteht, was bei sendmail der Fall ist. Die Funktion dnsbl akzeptiert zwei optionale Argumente. Das erste Argument ist der Name der Domain, die die schwarze Liste enthält. Standardmäßig ist dies die Realtime Blackhole List (RBL), die durch das Mail Abuse Prevention System (MAPS) gewartet wird. Es gibt verschiedene andere Gruppen, die Listen pflegen und sie der Öffentlichkeit zugänglich machen. Tabelle 6-2 zeigt einige von ihnen. Links Tabelle 6-2: Blackhole-List-Dienste Dienstname Website Domainname Spamhaus Block List sbl.spamhaus.org Relay Stop List relays.visi.com relays.visi.com Distributed Server Boycott List dsbl.org list.dsbl.org MAPS RBL mail-abuse.org Nicht erforderlich. Dies ist der dnsbl-standardwert. Um eine der schwarzen Listen zu verwenden, die in Tabelle 6-2 angegeben sind, muss das erste Argument der Funktion dnsbl auf die Domain verweisen, die in der Tabelle steht. Beispielsweise würde der folgende Befehl sendmail so konfigurieren, dass es die Spamhaus Block List benutzt: FEATURE(`dnsbl', `sbl.spamhaus.org') Durch die verschiedenen Blackhole-List-Dienste werden unterschiedliche Regeln definiert. Die meisten dieser Dienste konzentrieren sich darauf, offene Relays zu blockieren, anstatt auf die Quellen von Spam zu schauen. Das liegt daran, dass die Spam-Quellen sich laufend ändern und ihre wahren Identitäten verschleiern. Sie werden dabei obschon unabsichtlich durch offene Mail Relays unterstützt. Das offene Relay möchte eigentlich dem Spammer nicht helfen. Durch das Blockieren der Mail des offenen Relays wird die Aufmerksamkeit des Administrators dieses Relays schnell geweckt. Er wird das System dann reparieren und dem Spammer so den Zugriff auf die Ressourcen verweigern. Diese indirekte Verteidigung gegen Spam beeinträchtigt viele unschuldige, wenn auch naive Netzwerkbenutzer. Aus diesem Grund betrachten viele Leute schwarze Listen als eine Kur, die so schlecht ist wie die Krankheit, und raten von ihrer Benutzung ab. Es gibt viele Systeme, die in öffentlichen schwarzen Listen aufgeführt werden. Jede Site, die Spam weitervermittelt das könnte auch Ihre Site sein, falls Sie sendmail nicht richtig konfigurieren, könnte auf einer schwarzen Liste auftauchen. Dies ist einer der Gründe dafür, dass es unerlässlich ist, sendmail korrekt zu konfigurieren. Ein Fehler beim Konfigurieren des Relaying könnte dazu führen, dass Ihre Site auf einer schwarzen Liste auftaucht. Wenn eine Site kein Spam mehr weitervermittelt, sollte sie nach ungefähr einem Monat von der Liste entfernt werden. Natürlich wird diese Regel bei den verschiedenen Listen unterschiedlich gehandhabt, und es gibt auch Unterschiede bei der Effizienz, mit der Sites den Listen hinzugefügt oder von ihnen entfernt werden. Wenn Ihre Site auf eine schwarze Liste gesetzt wird, dann beheben Sie das Problem, und bitten Sie darum, dass die Site wieder von 218 Kapitel 6: Spam unter Kontrolle halten

237 Rechts der Liste entfernt wird, indem Sie die Anweisungen befolgen, die auf der Website der Liste zu finden sind. Besuchen Sie die Websites der einzelnen Listendienste, um mehr über die jeweilige Liste herauszufinden, bevor Sie damit beginnen, sie zu benutzen. Die einfachste Möglichkeit, Spam zu blockieren, besteht darin, dies jemand anderen erledigen zu lassen. Allerdings ist es zwar einfach, eine öffentliche schwarze Liste zu benutzen, jedoch nicht perfekt. Sie können nicht entscheiden, welche Sites der Liste hinzugefügt werden, was bedeutet, dass die Liste s von einer befreundeten Liste blockiert, nur weil der Administrator dieser Site vergessen hat, das Relaying zu deaktivieren. Sie können jedoch Einträge in einer schwarzen Liste außer Kraft setzen, indem Sie die access-datenbank verwenden, wie in Rezept 6.4 beschrieben. Um noch mehr Kontrolle zu erhalten, beschließen manche Einrichtungen sogar, ihre eigenen DNS-basierten schwarzen Listen zu erstellen. Rezept 6.5 zeigt Ihnen, wie Sie Ihre eigene schwarze Liste erstellen und aktivieren. Das zweite Argument, das für die Funktion dnsbl zur Verfügung steht, ist die Fehlermeldung, die angezeigt wird, wenn die Mail wegen des Servers mit der schwarzen Liste abgewiesen wird. Das Format der Standardmeldung sieht folgendermaßen aus: 550 Rejected $&{client_addr} listed at dnsbl-domain Dabei bezeichnet $&{client_addr} die IP-Adresse, die abgewiesen wurde, und dnsbldomain ist die DNS-basierte schwarze Liste, die die Adresse abgewiesen hat (d. h., dnsbldomain ist der Wert aus dem ersten Argument, das der Funktion dnsbl übergeben wurde). Verwenden Sie das zweite dnsbl-argument nur, wenn Sie die Standardfehlermeldung ändern wollen. Die meisten Administratoren bleiben bei der Standardmeldung. Mit dem dritten Argument, das für die Funktion dnsbl zur Verfügung steht, können Sie festlegen, wie mit temporären DNS-Lookup-Fehlern umgegangen werden soll. Standardmäßig stellt sendmail die Meldung nicht zurück, nur weil der Blackhole-List-Dienst nicht in der Lage ist, auf einen DNS-Lookup zu antworten. Wird ein t in das dritte Argumentfeld gesetzt, dann wird sendmail veranlasst, eine temporäre Fehlermeldung auszugeben und die Nachricht zurückzustellen. Hier ist ein Beispiel: FEATURE(`dnsbl', `sbl.spamhaus.org',,`t') Eine Alternative zur Funktion dnsbl bildet die Funktion enhdnsbl. Die Syntax der Funktion enhdnsbl zeigt die gleichen drei Ausgangsargumente wie die Funktion dnsbl, setzt aber noch ein viertes Argument hinzu. Bei diesem vierten Argument handelt es sich um den Rückgabewert, den sendmail von der DNS-Anfrage erwartet. Standardmäßig signalisiert jeder DNS-Lookup-Wert, der von einem Blackhole-List-Dienst zurückgegeben wird, dass die Adresse, die nachgesehen wurde, von dem Dienst aufgeführt wird und daher abgewiesen werden sollte. Das vierte Argument erlaubt es Ihnen, dies zu ändern, so dass nur ein Wert, der dem vierten Argument entspricht, ein Abweisen auslöst. Das vierte Argument muss kein einzelner Wert sein: Es kann sich um eine Liste von Werten handeln, oder es kann die gleichen Operatoren als LHS (Lefthand Side; linke Seite) einer Rewrite-Regel verwenden, um mehrere Werte zu erfassen. Hier ist ein Beispiel für die Funktion enhdnsbl: FEATURE(`enhdnsbl', `sbl.spamhaus.org',,,` ', ` ') Einführung 219

238 Dieser Makroeintrag aktiviert die Funktion enhdnsbl und nutzt den Blackhole-List-Dienst sbl.spamhaus.org. Er weist sendmail an, die eingehende Nachricht abzuweisen, wenn der Blackhole-List-Dienst entweder den Wert oder den Wert als Antwort auf den Lookup der Verbindungsadresse zurückliefert. Die access-datenbank und die schwarzen Listen blockieren Mail von bekannten Spam- Quellen und von offenen Relays. Allerdings stammt nicht jeder Spam aus einer bekannten Spam-Quelle. Manchmal wissen Sie erst nach dem Lesen einer Mail, dass es sich um Junk-Mail handelt. Mail-Filterwerkzeuge können den Inhalt der Mail untersuchen und anhand der Informationen, die in der Mail selbst gefunden wurden, entscheiden, wie sie behandelt werden soll. MILTER sendmail bietet über die Sockets-Schnittstelle direkten Zugriff auf externe Mail-Filterprogramme, so genannte MILTER, die entsprechend der Sendmail Mail Filter API geschrieben wurden. Externe Mail-Filter werden in der sendmail-konfiguration entweder mit Hilfe des Makros INPUT_MAIL_FILTER oder des Makros MAIL_FILTER definiert. Anders als der Name ist die Syntax beider Makros identisch. Hier ist beispielsweise die Syntax des Makros INPUT_MAIL_FILTER: INPUT_MAIL_FILTER(name, equates) Der name ist ein beliebiger Name, der von sendmail benutzt wird etwa wie ein interner Mailer-Name oder ein interner Datenbankname. Es gibt bis zu drei equates, die in der Form schlüsselbuchstabe=wert geschrieben werden, wobei schlüsselbuchstabe einen der folgenden Werte annehmen kann: S Das Equate S ist erforderlich, weil es den Socket definiert, der für die Kommunikation mit dem externen Filter eingesetzt wird. Die Socket-Definition wird in der Form S=typ: spezifikation geschrieben, wobei typ den Socket-Typ bezeichnet und spezifikation den Socket in einer Weise definiert, die vom angegebenen Socket-Typ verlangt wird. Es werden drei Socket-Typen unterstützt: S=unix:pfad Unix-Sockets werden unterstützt. pfad ist der vollständige Pfadname des Unix- Sockets. Das Schlüsselwort unix kann durch das Synonym local ersetzt werden (z. B. S=local:/var/run/filter1.sock). S=inet:port@host Das Schlüsselwort inet verlangt einen IP-Socket. port ist die Netzwerk-Portnummer, die von dem Filter benutzt wird. host ist der Hostname oder die IP- Adresse des Systems, auf dem der Filter läuft. S=inet6:port@host IPv6-Sockets werden ebenfalls unterstützt. Das Schlüsselwort inet6 verlangt einen IPv6-Socket, port identifiziert den IPv6-Port, der durch den Filter benutzt wird, und host identifiziert das System, auf dem der Filter läuft. host kann ent- Links 220 Kapitel 6: Spam unter Kontrolle halten

239 Rechts weder eine IPv6-Adresse oder ein Hostname sein, der auf eine IPv6-Adresse abgebildet wird. F=buchstabe Benutzen Sie dieses optionale Equate, um zu definieren, wie ein Socket-Fehler behandelt werden soll. Standardmäßig fährt sendmail mit der normalen Mail-Verarbeitung fort, falls der Socket fehlschlägt oder der Filter auf unerwartete Weise antwortet. Benutzen Sie F=R, um die Verbindung mit einem permanenten Fehler zurückzuweisen, oder F=T, um die Nachricht mit einem temporären Fehler zurückzustellen, wenn ein Socket- oder Filterproblem auftritt. T=buchstabe:wert;buchstabe:wert;... Verwenden Sie dieses optionale Equate, um die vorgegebenen Timeout-Werte zu ändern. Es stehen vier Buchstabenwerte zur Verfügung: C E R S Definiert den Verbindungstimeout. Standardmäßig wird die Verbindung abgebrochen (erhält einen Timeout), wenn innerhalb von fünf Minuten keine erfolgreiche Verbindung hergestellt wurde (5m). Definiert den Gesamttimeout. Dieser liegt standardmäßig bei fünf Minuten (5m). Definiert den Timeout zum Lesen einer Antwort vom Filter. Dieser liegt standardmäßig bei 10 Sekunden (10s). Definiert den Timeout zum Senden der Daten an den Filter. Der Standardwert liegt bei 10 Sekunden (10s). Bei dieser Syntax könnte ein INPUT_MAIL_FILTER-Makro, das Unterstützung für das externe Programm MIMEDefang hinzufügt, folgendermaßen aussehen: INPUT_MAIL_FILTER(`mimedefang',`S=unix:/var/run/mimedefang.sock, T=S:5m;R:5m') Dieses Makro definiert mimedefang als internen Namen für diesen Filter. sendmail erzeugt den Socket /var/run/mimedefang.sock und kommuniziert mit dem Filter über diesen Unix- Socket. Da sendmail diesen Socket erzeugt, darf er vorher noch nicht existieren. Das Equate F wird im Beispiel nicht benutzt, deshalb fährt sendmail fort, die Nachricht auf normale Weise zu verarbeiten, selbst wenn der Socket fehlschlägt oder der Filter falsch antwortet. Das Equate T erhöht die Sende- und Empfangstimer auf fünf Minuten. Das Makro INPUT_MAIL_FILTER definiert nur einen Filter. Um mehrere Filter zu benutzen, fügen Sie in die sendmail-konfiguration mehrere INPUT_MAIL_FILTER- oder MAIL_FILTER- Makros ein. Wenn mehrere Filter benutzt werden, dann wird der Unterschied zwischen MAIL_FILTER und INPUT_MAIL_FILTER deutlich. Hier ist ein Beispiel. Nehmen Sie an, die sendmail-konfiguration enthielte die folgenden Makros: INPUT_MAIL_FILTER(`filter1', `S=unix:/var/run/filter1.soc') INPUT_MAIL_FILTER(`filter2', `S=unix:/var/run/filter2.soc') INPUT_MAIL_FILTER(`filter3', `S=unix:/var/run/filter3.soc') Einführung 221

240 Das Makro INPUT_MAIL_FILTER legt die Reihenfolge fest, in der die Filter benutzt werden. Angesichts dieser drei Makros und der Reihenfolge, in der sie aufgeführt sind, würde sendmail Daten durch filter1, filter2 und filter3 in dieser Reihenfolge senden. Um eine äquivalente Konfiguration mit dem Makro MAIL_FILTER zu erzeugen, wären vier sendmail-konfigurationszeilen erforderlich: Links MAIL_FILTER(`filter1', `S=unix:/var/run/filter1.soc') MAIL_FILTER(`filter2', `S=unix:/var/run/filter2.soc') MAIL_FILTER(`filter3', `S=unix:/var/run/filter3.soc') define(`confinput_mail_filters', `filter1, filter2, filter3') MAIL_FILTER-Makros legen nicht die Reihenfolge fest, in der die Filter benutzt werden; aus diesem Grund müssen sie von einer confinput_mail_filters-definition begleitet werden, die die Ausführungsreihenfolge angibt. Falls die Definition confinput_mail_filters nicht verwendet wird, wenn MAIL_FILTER-Makros zum Einsatz kommen, werden die Filter ignoriert, die durch das Makro definiert werden. Werden dagegen natürlich MAIL _FILTER-Makros und die confinput_mail_filters-definition benutzt, dann müssen die Mail-Filter nicht in der Reihenfolge ausgeführt werden, in der sie deklariert wurden. Durch das Ändern der confinput_mail_filters-definition in die hier gezeigte Definition würden beispielsweise die Filter in umgekehrter Reihenfolge ausgeführt werden: define(`confinput_mail_filters', `filter3, filter2, filter1') Bei den von sendmail benutzten Filtern handelt es sich um externe Programme. Jeder einigermaßen fähige Programmierer kann ein einfaches Filterprogramm schreiben; allerdings ist das Schreiben eines Filters, der wirklich effektiv den Missbrauch von Mail bekämpft, eine Herausforderung. Glücklicherweise haben bereits viele fähige Leute nützliche Filter geschaffen. Bevor Sie das Rad noch einmal erfinden, suchen Sie im Web nach Filtern, die Ihre -Probleme lösen können. Hier sind vier Stellen, an denen Sie Ihre Suche beginnen könnten: Eine Website mit Informationen über MILTER im Allgemeinen. http// Ein leistungsfähiger, erweiterbarer MILTER, der Virus-Scans, das Löschen von Anhängen auf der Grundlage des Namens und des Inhalts und SpamAssassin-Verarbeitung unterstützt. 4 Ein MILTER, der zu überprüfen versucht, ob es sich bei der sendenden Adresse um eine gültige -Adresse handelt. Viele Spammer verwenden keine gültigen Absenderadressen. Ein virenscannender MILTER. 4 Unter finden Sie Informationen über das SpamAssassin-Programm. 222 Kapitel 6: Spam unter Kontrolle halten

241 Rechts Eine Vielzahl kommerziell unterstützter MILTER, die von Sendmail, Inc. zur Verfügung gestellt werden. Es gibt noch viel mehr Websites, die sich mit MILTERn befassen, sowie noch viele weitere MILTER. Allerdings sind MILTER nicht die einzigen Werkzeuge, die zum Filtern von Mails zur Verfügung stehen; procmail wird ebenfalls weithin eingesetzt. Filtern mit procmail Die meisten sendmail-texte, und dieser hier bildet keine Ausnahme, konzentrieren sich beim Mail-Filtern auf procmail. Dafür gibt es einige Gründe: procmail ist eng in sendmail integriert. procmail ist ein leistungsfähiges Werkzeug, das für bedeutend mehr als Spam-Filterung eingesetzt werden kann. procmail ist das standardmäßig verwendete lokale Mail-Auslieferungsprogramm für Linux-Systeme und kann auf jedem Unix-System als lokaler Mailer benutzt werden, indem die sendmail-konfiguration um die Funktion local_procmail erweitert wird. Der Befehl MAILER(procmail) fügt procmail zu sendmails Liste der Mailer hinzu. Die Vielfalt der Möglichkeiten, procmail aufzurufen, mehrt die Flexibilität dieses Werkzeugs. Wie oben angemerkt, kann sendmail so konfiguriert werden, dass es procmail als local-mailer benutzt. procmail kann auch von der Kommandozeile der Shell gestartet werden. Es kann von der mailertable aufgerufen werden, wie in Rezept 6.8 beschrieben, und es kann auf folgende Weise aus der.forward-datei des Benutzers heraus aufgerufen werden: $ cat >.forward " /usr/bin/procmail" Ctrl-D Häufig wird fälschlicherweise angenommen, dass die wichtigste Mail-Filterung auf der Systemebene stattfindet, nur weil systemweite Mail-Filter eine große Anzahl von Benutzern beeinflussen. Die Mail-Filterung auf Benutzerebene ist genauso wichtig wie Filter auf Systemebene. Filter auf Benutzerebene bieten eine letzte Verteidigungslinie gegen Spam, der es durch die Systemfilter geschafft hat. erlauben es Benutzern, ihre eigenen persönlichen -Regeln durchzusetzen. erlauben eine Inhaltsfilterung ohne die Gefahr, die Privatsphäre zu verletzen. gehen mit einem viel kleineren Mail-Aufkommen um. Aus diesen und weiteren Gründen ist es günstig, die Benutzer zu ermuntern, die ihnen zur Verfügung stehenden Mail-Filter kennen zu lernen und einzusetzen. Viele Mail-Programme für Endbenutzer enthalten Funktionen zur Mail-Filterung. Diese sind nicht in sendmail integriert und werden deshalb hier nicht erläutert. Einführung 223

242 procmail ist ein leistungsfähiges, wenn auch komplexes Mail-Filtersystem. Persönliche procmail-filter werden durch den Benutzer in seinem Home-Verzeichnis definiert, und zwar in einer Datei namens.procmailrc. Der Systemadministrator definiert systemweite Mail-Filter in der Datei /etc/procmailrc und benutzt die Datei /etc/procmailrc für eine allgemeine Spam- Filterung. Der Endbenutzer verwendet.procmailrc, um eine Filterung nach seinen persönlichen Vorstellungen durchzuführen. Das Format beider Dateien ist identisch. Die Datei.procmailrc enthält zwei Arten von Einträgen: Zuweisungen von Umgebungsvariablen und Mail-Filterregeln, die in der Sprache von procmail als Recipes (Rezepte) bezeichnet werden. Zuweisungen von Umgebungsvariablen sind einfach und sehen genauso aus wie solche Zuweisungen in Shell-Skripten. Beispielsweise ist HOME=/home/craig eine gültige Umgebungsvariablenzuweisung. Die.procmailrc-Manpage führt mehr als 30 Umgebungsvariablen auf. Das Wesentliche einer.procmailrc-datei sind die Rezepte. Die Syntax eines Rezeptes lautet: :0 [flag] [:[sperrdatei]] [* bedingung] aktion Jedes Rezept beginnt mit :0, wodurch es sich von einer Zuweisungsanweisung unterscheidet. Der :0 folgen optional Flags, die festlegen, wie der Filter verarbeitet wird. Tabelle 6-3 zeigt die Flags und ihre Anwendungsgebiete. Links Tabelle 6-3: Flags für procmail-rezepte Flags A a b B c D e E f H h I r w W Bedeutung Führt dieses Rezept aus, wenn das vorangegangene Rezept mit true (wahr) bewertet wurde. Dieses Flag hat die gleiche Bedeutung wie das Flag A, allerdings muss das vorangegangene Rezept auch noch erfolgreich ausgeführt worden sein. Übergibt den Body der Nachricht an das Ziel. Dies ist die Voreinstellung. Filtert den Nachrichten-Body. Erzeugt eine Kopie (Cc) dieser Mail. Tests werden unter Berücksichtigung der Groß-/Kleinschreibung ausgeführt. Normalerweise wird die Schreibweise ignoriert. Führt dieses Rezept aus, wenn bei der Ausführung des vorangegangenen Rezepts ein Fehler zurückgegeben wurde. Führt dieses Rezept aus, wenn das vorangegangene Rezept nicht ausgeführt wurde. Übergibt die Daten an ein externes Filterprogramm. Filtert die Nachrichten-Header. Dies ist die Voreinstellung. Übergibt den Nachrichten-Header an das Ziel. Dies ist die Voreinstellung. Ignoriert Schreibfehler für dieses Rezept. Schreibt die Mail ohne zusätzliche Formatprüfungen aus. Prüft den Exit-Code des externen Filter-Programms. Dieses Flag hat die gleiche Bedeutung wie das Flag w, allerdings wird keine Fehlermeldung ausgegeben. 224 Kapitel 6: Spam unter Kontrolle halten

243 Rechts Nutzen Sie die optionale Variable sperrdatei, um den Namen der lokalen Sperrdatei (Lockfile) festzulegen, die für dieses Rezept eingesetzt werden soll. Die Sperrdatei verhindert, dass mehrere Kopien von procmail gleichzeitig in die gleiche Mailbox schreiben, was auf einem ausgelasteten System passieren kann. Dem Namen der sperrdatei wird ein Doppelpunkt vorangestellt. Wenn der Doppelpunkt vorhanden ist, der Name jedoch fehlt, dann wird ein Standardname für die sperrdatei aus dem Mailboxnamen erzeugt, der die Erweiterung.lock erhält. Wird keine lokale Sperrdatei festgelegt, dann wird eine vorgegebene Sperrdatei benutzt. Die procmail-dokumentation ermuntert jedoch dazu, lokale Sperrdateien zu verwenden. Der Bedingungstest ist optional. Wenn keine bedingung angegeben wird, handelt das Rezept so, als wäre die Bedingung erfüllt (wahr), das heißt, die Aktion wird durchgeführt. Wird eine bedingung angegeben, dann muss sie mit einem Asterisk (*) beginnen. Die bedingung wird als regulärer Ausdruck geschrieben. Falls der Wert, der durch den regulären Ausdruck definiert wird, in der Mail gefunden wird, dann wird die Bedingung als wahr bewertet und die Aktion ausgeführt. Um eine Aktion auszuführen, wenn die Mail nicht den angegebenen Wert enthält, setzen Sie ein Ausrufezeichen vor den regulären Ausdruck. Hier sind einige Beispiele für gültige Bedingungstests: * ^From.*simon@oreilly\.com *!^Subject: Chapter Der erste Bedingungstest prüft, ob die Mail eine Zeile enthält, die mit dem String From anfängt (das Zeichen ^ signalisiert hierbei den Zeilenanfang), gefolgt von einer beliebigen Anzahl Zeichen (.*) und dem String simon@oreilly.com beginnt. Die zweite Bedingung erfasst alle Mails, die keine (!) Zeile enthalten, die mit dem String Subject: Chapter beginnt. Werden in einem Rezept mehrere Bedingungen definiert, dann erscheint jede Bedingung auf einer eigenen Zeile. Es darf zwar mehrere Bedingungen in einem procmail-rezept geben, allerdings nur eine aktion. Die aktion kann die Mail in eine Datei leiten, sie an eine andere -Adresse weiterleiten oder sie an ein Programm senden. Die aktion kann aber auch zusätzliche Rezepte zum Verarbeiten der Nachricht definieren. Handelt es sich bei der aktion um ein zusätzliches Rezept, beginnt sie mit :0. Falls die aktion die Mail an eine -Adresse richtet, beginnt sie mit einem Ausrufezeichen (!), und falls sie die Mail an ein Programm schickt, beginnt sie mit einem senkrechten Strich ( ). Richtet die aktion die Mail an eine Datei, wird nur der Name der Datei angegeben. Das folgende Beispiel zeigt, wie Mail zur Verarbeitung an ein externes Programm übergeben wird: :0 B *.*pheromones awk -f spamscript > spam-suspects Das Flag B wendet den Bedingungstest auf den Inhalt des Nachrichten-Body an. Alle Nachrichten, die irgendwo im Nachrichten-Body das Wort»pheromones«enthalten, werden zur Verarbeitung an awk übergeben. In diesem Beispiel ruft awk eine Programmdatei namens spamscript auf, die Informationen aus der Mail extrahiert und in einer Datei namens spam-suspects speichert. Sie können sich vorstellen, dass der Administrator Einführung 225

244 dieses Systems spamscript angelegt hat, um die -Adressen aus mutmaßlichem Spam zu extrahieren. Das Beispiel zeigt, wie procmail den Nachrichten-Body filtert. Standardmäßig schaut sich procmail die Nachrichten-Header an. Den Nachrichten-Headern kann innerhalb der sendmail-konfiguration durch die Benutzung maßgeschneiderter Regelsätze ebenfalls besondere Aufmerksamkeit gewidmet werden. Maßgeschneiderte Regelsätze Mit sendmail können Sie eine angepasste Verarbeitung für die Adressen und Header eingehender Mail definieren. sendmail bietet zu diesem Zweck einige Einstiegspunkte. Dabei handelt es sich um: Local_check_relay Dies ist der Einstiegspunkt in den Regelsatz check_relay. Dem Regelsatz Local_check _relay werden der Hostname und die IP-Adresse des Hosts übergeben, der die - Verbindung initiiert hat. Local_check_mail Dies ist der Einstiegspunkt in den Regelsatz check_mail, der die Umschlagabsenderadresse aus dem SMTP-Befehl MAIL From: verarbeitet. Rezept 6.10 enthält einen Beispiel-Local_check_mail-Regelsatz. Local_check_rcpt Dies ist der Einstiegspunkt in den Regelsatz check_rcpt, der die Umschlagempfängeradresse prüft, die durch den SMTP-Befehl RCPT To: definiert wird. Diese Regelsätze sind nicht speziell dafür gedacht, Junk-Mail aufzuspüren und zu löschen; sie haben ein breiteres Anwendungsfeld. Allerdings sind diese Einstiegspunkte in die Regelsätze ganz nützlich zum Bekämpfen von Spam. Zusätzlich zu diesen Einstiegspunkten, die aus den Standardregelsätzen heraus aufgerufen werden, kann ein Regelsatz von einer Header-Definition aufgerufen werden, um eine maßgeschneiderte Header-Verarbeitung durchzuführen. Die grundlegende Syntax des sendmail. cf-befehls H definiert das Format der Mail-Header. In der Grundsyntax beginnt die Header- Definition mit dem Befehl H, gefolgt vom Namen des Headers und dem Format dieses Headers. Die Syntax zum Aufrufen eines Regelsatzes aus einem H-Befehl heraus lautet: Hname: $>regelsatz Dabei ist name der Header-Name und regelsatz der Regelsatz, der aufgerufen wird, um eingehende Header dieses Namens zu verarbeiten. Nutzen Sie diese Fähigkeit, eingehende Header zu prüfen, um Spam-Mail anhand der Header-Informationen zu erkennen. Rezept 6.9 zeigt an einem Beispiel, wie diese Fähigkeit eingesetzt werden kann. Links 226 Kapitel 6: Spam unter Kontrolle halten

245 Rechts 6.1 Spam mit der access-datenbank blockieren Problem Da es sich beim Hauptteil der Mails, die von bestimmten Sites eintreffen, um Junk-Mail handelt, wurden Sie gebeten, sendmail so zu konfigurieren, dass es alle Mails von diesen Sites blockiert. Lösung Fügen Sie die Adressen, die blockiert werden sollen, in die Textdatei /etc/mail/access ein. Der Schlüssel zu den einzelnen Einträgen ist die Adresse des Spammers. Der Rückgabewert ist entweder DISCARD, um die Mail stillschweigend abzuweisen, REJECT, um die Mail mit einem Standardfehler abzuweisen, oder ERROR, um die Mail mit einer eigenen Fehlermeldung abzuweisen. Erstellen Sie mit dem Skript makemap eine Hash-Datenbank aus der Textdatei. Erzeugen Sie dann eine sendmail-konfiguration, die die Funktion access_db enthält. Hier ist das erforderliche FEATURE-Makro: dnl Use the access database FEATURE(`access_db') Entsprechend dem Beispiel in Rezept 1.8 erstellen Sie dann die Datei sendmail.cf neu, kopieren die neue sendmail.cf nach /etc/mail und starten sendmail neu. Diskussion Verwenden Sie REJECT, ERROR oder DISCARD in der access-datenbank, um Junk-Mail zu blockieren. Die folgende Beispiel-access-Datenbank blockiert Mail von drei Sites: example.com wrotethebook.net fake.ora.com REJECT ERROR:5.7.1:550 Invalid mail source DISCARD Ein telnet-test zeigt, was die entfernten Sites in Abhängigkeit von der Aktion sehen, die in der Datenbank definiert wurde: # telnet localhost smtp Trying Connected to localhost. Escape character is '^]'. 220 chef.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 22 Aug :01: HELO localhost 250 chef.wrotethebook.com Hello IDENT:UWSRv+Jij66J8vALUBVBECbGPVoU8OQe@localhost [ ], pleased to meet you MAIL From:<crooks@example.com> <crooks@example.com>... Access denied 6.1 Spam mit der access-datenbank blockieren 227

246 MAIL Invalid mail source MAIL Sender ok QUIT chef.wrotethebook.com closing connection Connection closed by foreign host. Mail von example.com wird mit dem Fehler»Access denied«abgewiesen, da der example. com-eintrag in der Beispiel-access-Datenbank REJECT als Aktion definiert, die für Mails ausgeführt wird, die von dieser Domain stammen. Mail von wrotethebook.net wird mit der Fehlermeldung»Invalid mail source«abgewiesen, die in der access-datenbank mit dem Befehl ERROR definiert wurde. Andererseits scheint aus Sicht des entfernten Systems Mail von fake.ora.com vom Server akzeptiert zu werden. Es ist ein sendmail -bt-test erforderlich, um die Wirkung der Aktion DISCARD zu sehen, die in der access-datenbank für Mail von fake.ora.com festgelegt wurde: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > check_mail junk@fake.ora.com check_mail input: fake. ora. com Basic_check_mail input: fake. ora. com tls_client input: $ MAIL D input: < > <? > <! "TLS_Clt" > < > D returns: <? > < > <? > <! "TLS_Clt" > < > A input: < > <? > <! "TLS_Clt" > < > A returns: < > <? > <! "TLS_Clt" > < > TLS_connection input: $ < > <? > <! "TLS_Clt" > < > TLS_connection returns: OK tls_client returns: OK CanonAddr input: < fake. ora. com > canonify input: < fake. ora. com > Canonify2 input: junk fake. ora. com > Canonify2 returns: junk fake. ora. com > canonify returns: junk fake. ora. com > Parse0 input: junk fake. ora. com > Parse0 returns: junk fake. ora. com > CanonAddr returns: junk fake. ora. com > SearchList input: < + From > $ < F : fake. ora. com > < U : > < D : fake. ora. com > < > F input: < fake. ora. com > <? > < + From > < > F returns: <? > < > SearchList input: < + From > $ < U : > < D : fake. ora. com > < > U input: < > <? > < + From > < > U returns: <? > < > SearchList input: < + From > $ < D : fake. ora. com > < > D input: < fake. ora. com > <? > < + From > < > D returns: < DISCARD > < > SearchList returns: < DISCARD > SearchList returns: < DISCARD > SearchList returns: < DISCARD > Links 228 Kapitel 6: Spam unter Kontrolle halten

247 Rechts Basic_check_mail returns: $# discard $: discard check_mail returns: $# discard $: discard > /quit In diesem Test wird die Adresse durch den Regelsatz check_mail verarbeitet, der die MAIL From:-Adresse prüft. Der Regelsatz check_mail verarbeitet die Adresse und gibt»discard«zurück, was bedeutet, dass Mail von fake.ora.com stillschweigend abgewiesen wird. Siehe auch Die Datei cf/readme, Kapitel 3 und die Einführung in diesem Kapitel bieten weitere Informationen über die access-datenbank. Das Buch sendmail behandelt die access-datenbank in Abschnitt Verhindern, dass lokale Benutzer auf Spammer antworten Problem Manche der lokalen Benutzer ermutigen Spammer, indem sie auf Spam-Mails antworten. Sie wurden gebeten, sendmail so zu konfigurieren, dass es sowohl die Spammer als auch diejenigen stoppt, die Spam durch eine Reaktion ermutigen. Lösung Schaffen Sie, bevor Sie Benutzerzugänge anlegen, akzeptable Benutzungsregeln, die Ihnen unter anderem die Berechtigung geben, die Spam-Kommunikation sowohl eingehende als auch ausgehende zu blockieren. Sorgen Sie dafür, dass alle Benutzer diesen Regeln zustimmen, bevor Sie ihnen Benutzerzugänge zuweisen. Fügen Sie die Spam-Adressen, die blockiert werden sollen, in die Textdatei /etc/mail/ access ein. Verwenden Sie die Tags To: und From:, um zu verhindern, dass Mail an Spammer gesandt wird oder Mail von Spammern akzeptiert wird. Erstellen Sie mit makemap eine Hash-Datenbank aus der Textdatei. Erzeugen Sie eine sendmail-konfiguration, die die access-datenbank mit der Funktion access_db aktiviert. Der erforderliche sendmail-feature-befehl lautet: dnl Use the access database FEATURE(`access_db') Erstellen Sie die sendmail.cf-datei, kopieren Sie die neue sendmail.cf nach /etc/mail, und starten Sie sendmail neu, wie in Rezept 1.8 beschrieben. 6.2 Verhindern, dass lokale Benutzer auf Spammer antworten 229

248 Diskussion Standardmäßig gilt die access-datenbank für Quelladressen. Je nach der Quelle der wird die Aktion ausgeführt, die in dem Datenbankeintrag definiert ist. Die access-datenbank, die für Rezept 6.1 angelegt wurde, sorgt dafür, dass Mail von example.com, wrotethebook.net und fake.ora.com abgewiesen wird, wie die Tests in diesem Rezept demonstrieren. Beispielsweise wird Mail von jemandem aus example.com mit dem Fehler»Access denied«abgewiesen. Allerdings verhindert die access-datenbank aus Rezept 6.1 nicht, dass Mail vom lokalen Host aus an jemanden in example.com geschickt wird. Durch das Hinzufügen des To:-Tags zu einem Eintrag in der access-datenbank wird die Aktion, die in dem Eintrag definiert wurde, auf Empfängeradressen angewandt, die dem Schlüssel entsprechen, während das From:-Tag speziell anfordert, dass die Aktion auf passende Quelladressen angewandt wird. Hier sehen Sie die access-datenbank aus Rezept 6.1, umgeschrieben mit To:- und From:-Tags: From:example.com To:example.com From:wrotethebook.net To:wrotethebook.net From:fake.ora.com To:fake.ora.com REJECT ERROR:5.7.1:550 Mail to this site is not allowed ERROR:5.7.1:550 Invalid mail source ERROR:5.7.1:550 Mail to this site is not allowed DISCARD ERROR:5.7.1:550 Mail to this site is not allowed Da die Aktion für den From:-example.com-Eintrag REJECT ist, wird Mail von dieser Site abgewiesen, wie in Rezept 6.1 gezeigt. Durch den Zusatz des To:-Eintrags wird Mail, die an example.com adressiert ist, ebenfalls abgewiesen, wie dieser Test beweist: # telnet localhost smtp Trying Connected to localhost. Escape character is '^]'. 220 chef.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 22 Aug :01: HELO localhost 250 chef.wrotethebook.com Hello IDENT:UWSRv+Jij66J8vALUBVBECbGPVoU8OQe@localhost [ ], pleased to meet you MAIL From:<craig@chef.wrotethebook.com> <craig@chef.wrotethebook.com>... Sender ok RCPT To:<crook@example.com> <crook@example.com>... Mail to this site is not allowed QUIT chef.wrotethebook.com closing connection Connection closed by foreign host. Sie müssen Sorgfalt walten lassen, wenn Sie ausgehende Mails blockieren. Lokale Benutzer erwarten, dass sie mit jedem kommunizieren können, und wollen nicht, dass Sie entscheiden, mit wem sie reden dürfen und mit wem nicht. Eine Benutzungsregelung, die Ihnen diese Autorität gibt, ist ausgesprochen wichtig, bevor Sie in Aktion treten. Stellen Sie sich auf Beschwerden ein, egal, was die von allen zu akzeptierende Benutzungsregelung besagt. Links 230 Kapitel 6: Spam unter Kontrolle halten

249 Rechts Alternativen Die Funktion blacklist_recipients ist eine alternative Möglichkeit, um ausgehende Mails an bekannte Spammer zu blockieren. Die Funktion blacklist_recipients wendet jeden unmarkierten Eintrag in der access-datenbank auf Empfängeradressen an. Die folgenden Zeilen, die in die sendmail-konfiguration eingefügt wurden, aktivieren die access-datenbank und wenden die Datenbank auf Empfängeradressen an: dnl Use the access database FEATURE(`access_db') dnl Also apply the access database to recipient addresses FEATURE(`blacklist_recipients') Die Funktion blacklist_recipients funktioniert gut und ist sehr einfach zu benutzen. Da sie jedoch auf jeden unmarkierten Eintrag in der access-datenbank angewandt wird, bietet sie nicht die gleiche Konfigurationskontrolle wie das Tag To:. Außerdem sind Tags selbstdokumentierend. Jeder, der in die gerade gezeigte Beispiel-access-Datenbank schaut, versteht, dass Mail an example.com nicht erlaubt ist, wenn er das Tag To: und die Fehlermeldung im Aktionsfeld sieht. Siehe auch Kapitel 3 und die Einführung in dieses Kapitel bieten weitere Informationen über die access-datenbank. Das Buch sendmail behandelt die access-datenbank in Abschnitt 7.5 und die Funktion blacklist_recipients in Abschnitt Der Abschnitt Anti-Spam Configuration Control der Datei cf/readme behandelt dieses Thema ebenfalls. 6.3 Die access-datenbank über LDAP lesen Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es die access-datenbank von einem LDAP-Server liest. Lösung Falls es notwendig sein sollte, kompilieren und installieren Sie sendmail erneut, um den sendmail-host um LDAP-Unterstützung zu erweitern, und fügen das sendmail-schema in die LDAP-Konfiguration auf dem LDAP-Server ein. Beide Schritte werden in Rezept 1.3 gezeigt. Geben Sie die access-datenbank-records auf dem LDAP-Server in eine LDIF-Datei ein. Benutzen Sie dazu das sendmailmtamap-objektklassenformat, das durch das sendmail- Schema definiert ist. Verwenden Sie das Skript ldapadd, um die access-records in der LDAP-Datenbank zu speichern. 6.3 Die access-datenbank über LDAP lesen 231

250 Fügen Sie auf dem sendmail-host die Definition confldap_cluster und die Funktion access_db in die sendmail-konfiguration ein. Setzen Sie confldap_cluster auf den gleichen Wert, der für das Attribut sendmailmtacluster in den access-ldap-records verwendet wird. Fügen Sie den String LDAP zum access_db-befehl FEATURE hinzu, um sendmail anzuweisen, die access-daten über LDAP zu lesen. Hier sind Beispielzeilen, die in die sendmail-konfiguration eingefügt werden könnten: dnl Define the LDAP cluster name define(`confldap_cluster', `wrotethebook.com') dnl Read the access database via LDAP FEATURE(`access_db', `LDAP') Erstellen und installieren Sie die Datei sendmail.cf neu, starten Sie dann sendmail erneut. Ein Beispiel finden Sie in Rezept 1.8. Links Diskussion Die sendmail-distribution liefert eine LDAP-Schema-Datei, in der die grundlegenden Attribute definiert werden, die für sendmail-datenbanken und -Klassen benötigt werden. Sie können natürlich Ihr eigenes Schema definieren. Wenn Sie jedoch das sendmail- Schema einsetzen, vereinfacht sich sowohl die LDAP- als auch die sendmail-konfiguration. Im folgenden Beispiel werden die access-einträge, die in Rezept 6.1 zum Einsatz kamen, in LDAP-Records konvertiert. Dazu verwenden wir das sendmail-schema zur Definition der access-einträge für die LDAP-Datenbank: # cat > ldap-access dn: sendmailmtamapname=access, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtamap sendmailmtacluster: wrotethebook.com sendmailmtamapname: access dn: sendmailmtakey=example.com, sendmailmtamapname=access, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtamap objectclass: sendmailmtamapobject sendmailmtamapname: access sendmailmtacluster: wrotethebook.com sendmailmtakey: example.com sendmailmtamapvalue: REJECT dn: sendmailmtakey=wrotethebook.net, sendmailmtamapname=access, dc=wrotethebook, dc=com objectclass: sendmailmta objectclass: sendmailmtamap objectclass: sendmailmtamapobject sendmailmtamapname: access sendmailmtacluster: wrotethebook.com sendmailmtakey: wrotethebook.net sendmailmtamapvalue: ERROR:5.7.1:550 Invalid mail source dn: sendmailmtakey=fake.ora.com, sendmailmtamapname=access, dc=wrotethebook, dc=com 232 Kapitel 6: Spam unter Kontrolle halten

251 Rechts objectclass: sendmailmta objectclass: sendmailmtamap objectclass: sendmailmtamapobject sendmailmtamapname: access sendmailmtacluster: wrotethebook.com sendmailmtakey: fake.ora.com sendmailmtamapvalue: DISCARD Ctrl-D # ldapadd -x -D "cn=manager,dc=wrotethebook,dc=com" \ > -W -f ldap-access Enter LDAP Password: SecretLDAPpassword adding new entry "sendmailmtamapname=access, dc=wrotethebook, dc=com" adding new entry "sendmailmtakey=example.com, sendmailmtamapname=access, dc=wrotethebook, dc=com" adding new entry "sendmailmtakey=wrotethebook.net, sendmailmtamapname=access, dc=wrotethebook, dc=com" adding new entry "sendmailmtakey=fake.ora.com, sendmailmtamapname=access, dc=wrotethebook, dc=com" Vier LDAP-Records werden verwendet, um die drei access-einträge aus Rezept 6.1 hinzuzufügen. Das erste Record teilt LDAP den access-datenbanknamen mit. Nachfolgende LDAP-Records referenzieren diesen Datenbanknamen, um access-records in die LDAP- Datenbank einzufügen. Die nächsten drei LDAP-Records definieren die drei access-einträge, die in Rezept 6.1 beschrieben wurden. Beachten Sie, dass die Attribute sendmailmtakey und sendmailmtamap Value jedes Records den Schlüssel/Wert-Paaren aus den ursprünglichen access-einträgen entsprechen. Durch das Variieren der Werte, die in den Attributen sendmailmtamapname, sendmailmtakey und sendmailmtamapvalue gespeichert sind, kann das zugrunde liegende LDAP-Record-Format, das für die access-datenbank zum Einsatz kommt, für jede sendmail-datenbank verwendet werden. Nachdem die Records aus der LDIF-Datei konvertiert und zur LDAP-Datenbank hinzugefügt worden sind, können sie mittels ldapsearch untersucht werden: # ldapsearch -LLL -x '(sendmailmtamapname=access)' sendmailmtamapvalue dn: sendmailmtamapname=access, dc=wrotethebook, dc=com dn: sendmailmtakey=example.com, sendmailmtamapname=access, dc=wrotethebook, dc=com sendmailmtamapvalue: REJECT dn: sendmailmtakey=wrotethebook.net, sendmailmtamapname=access, dc=wrotethebook, dc=com sendmailmtamapvalue: ERROR:5.7.1:550 Invalid mail source dn: sendmailmtakey=fake.ora.com, sendmailmtamapname=access, dc=wrotethebook, dc=com sendmailmtamapvalue: DISCARD Dieser Test zeigt, dass die access-datenbank-records vom LDAP-Server verfügbar sind. Falls Ihr sendmail-system die Werte -h und -b für den ldapsearch-test verlangt, dann 6.3 Die access-datenbank über LDAP lesen 233

252 sind diese Werte auch für die sendmail-konfiguration erforderlich. Setzen Sie -h und -b mit Hilfe der Definition confldap_default_spec, wie in Rezept 5.9 gezeigt. Jetzt muss sendmail noch so konfiguriert werden, dass es den LDAP-Server benutzt. Zuerst wird der Befehl confldap_cluster zur sendmail-konfiguration hinzugefügt, um sendmail den LDAP-Cluster-Namen mitzuteilen. Das sendmail-schema lässt Records zu, die auf einen einzelnen Host oder auf eine Gruppe von Hosts, einen so genannten Cluster, angewandt werden. Falls LDAP-Records für einen einzelnen Host gelten, benutzen sie das Attribut sendmailmtahost. sendmail bezieht nur Records, die das Attribut sendmailmtahost benutzen, falls es sich bei dem Wert, der diesem Attribut zugewiesen ist, um den voll qualifizierten Namen des sendmail-hosts handelt. Records, die für eine Gruppe von Hosts gelten, verwenden das Attribut sendmailmtacluster. Um Records zu beziehen, die dieses Attribut einsetzen, muss sendmail mit dem Cluster-Namen konfiguriert sein. Das ist genau das, was dieses Rezept tut. Es definiert die LDAP-access-Records mit Hilfe des Attributs sendmailmtacluster und informiert sendmail mit der Definition confldap_cluster über den Cluster-Namen. Durch das Hinzufügen des Arguments LDAP zum access_db-befehl FEATURE wird sendmail angewiesen, die access-datenbank vom LDAP-Server zu lesen. Dabei soll es das Standardsendmail-Schema benutzen. Falls Sie sich ein eigenes Schema definieren, müssen Sie sendmail anweisen, dieses zu benutzen, um access-records zu beziehen. Zum Beispiel: FEATURE(`access_db', `ldap: -1 k (&(objectclass=ouraccessdb)(ouraccesdbkey=%0)) v OurAccessDBValue') Die Beispielattributnamen sollten ignoriert werden. Allerdings ähnelt das Format des Befehls FEATURE demjenigen, das Sie definieren würden, um access-daten mittels eines eigenen LDAP-Schemas zu beziehen. Die Option -k definiert die LDAP-Suchkriterien, die als Datenbankschlüssel benutzt werden. Die Attribute, die in diesen Suchkriterien benutzt werden, müssen den Attributen entsprechen, die in Ihrem Schema definiert wurden. Die Option -v legt das LDAP-Attribut fest, das den Rückgabewert enthält. Auch dieses muss dem Attribut aus Ihrem eigenen Schema entsprechen. Die Benutzung des vorgegebenen sendmail-schemas vereinfacht die sendmail-konfiguration. Verwenden Sie einfach den String LDAP im access_db-befehl FEATURE, wie in der Lösung gezeigt. Einige Tests, die durchgeführt werden, nachdem dieses Rezept installiert ist, zeigen, dass sendmail die LDAP-Daten liest. Führen Sie zuerst einen sendmail -bt-test durch, und benutzen Sie den Befehl /map, um ein access-record vom LDAP-Server zu beziehen: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /map access fake.ora.com map_lookup: access (fake.ora.com) returns DISCARD (0) > /quit Dieser Test zeigt, dass die access-datenbank auf die gleiche Weise funktioniert ob sie nun aus einer lokalen Datenbank oder von einem LDAP-Server gelesen wird. Eine erneute Ausführung des Tests, der in Rezept 6.1 zum Einsatz kam, zeigt, dass sendmail Links 234 Kapitel 6: Spam unter Kontrolle halten

253 Rechts Mail mit Hilfe von LDAP blockiert, genau wie es unter Benutzung einer lokalen access- Datenbank der Fall war: # sendmail -bs 220 rodent.wrotethebook.com ESMTP Sendmail /8.12.9; Thu, 27 Mar :42: MAIL From:<crooks@example.com> <crooks@example.com>... Access denied MAIL From:<thieves@wrotethebook.net> <thieves@wrotethebook.net>... Invalid mail source QUIT rodent.wrotethebook.com closing connection LDAP ändert die Art und Weise nicht, wie sendmail funktioniert. Die Entscheidung für die Verwendung von LDAP liegt nicht bei sendmail, sondern bei LDAP. Falls Sie bereits LDAP einsetzen, um die Verwaltung von Informationen zu zentralisieren, könnten Sie beschließen, sendmail-konfigurationsdaten auf Ihren LDAP-Server auszulagern. Siehe auch Die Rezepte 6.1 und 6.2 erklären, wie die access-datenbank benutzt wird, um Spam unter Kontrolle zu halten; vor allem Rezept 6.1 erläutert die besonderen access-datenbankeinträge, die für dieses Rezept zum Einsatz kommen. Die Datei cf/readme behandelt dieses Thema im Abschnitt Using LDAP for Aliases, Maps, and Classes. Das Buch sendmail behandelt die Funktion access_db in Abschnitt 7.5 und die Definition confldap_ CLUSTER in Abschnitt Einen DNS-Blackhole-List-Dienst benutzen Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es einen Blackhole-List-Dienst benutzt, um mit minimalem Aufwand große Mengen an unerwünschten Werbe- s (UCE) aus einer Vielzahl von Quellen zu stoppen. Lösung Fügen Sie der sendmail-konfiguration die Funktion dnsbl hinzu. Identifizieren Sie auf der dnsbl-kommandozeile den speziellen Blackhole-List-Dienst, den Sie benutzen wollen. Hier ist ein Beispiel: dnl Use the DSBL blacklist service FEATURE(`dnsbl', `list.dsbl.org') Erstellen Sie entsprechend Rezept 1.8 die Datei sendmail.cf neu, kopieren Sie die neue sendmail.cf nach /etc/mail, und starten Sie sendmail neu. 6.4 Einen DNS-Blackhole-List-Dienst benutzen 235

254 Diskussion Die Funktion dnsbl legt den sendmail.cf-code an, der erforderlich ist, um einen DNS- Blacklist-Dienst zu aktivieren. Die Funktion dnsbl benutzt einen K-Befehl, um die dnsbl- Datenbank als Datenbank vom Typ host zu definieren. Das bedeutet, dass Anfragen an dnsbl in Wirklichkeit zur Auflösung an das DNS übergeben werden. 5 Die Funktion dnsbl fügt außerdem noch einige Regeln in den Regelsatz Basic_check_relay ein, der vom Regelsatz check_relay aufgerufen wird. Die hinzugefügten Regeln schauen die Verbindungsadresse in der dnsbl-datenbank nach. Wenn die Verbindungsadresse in der Datenbank gefunden wird, dann wird Mail von dieser Adresse mit einer Fehlermeldung abgewiesen. Wird die Verbindungsadresse nicht in der dnsbl-datenbank gefunden, dann wird die Mail zur weiteren Verarbeitung weitergegeben. Ein sendmail -bt-test zeigt die Wirkung der hinzugefügten Rewrite-Regeln: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> >.D{client_addr} > Basic_check_relay <> Basic_check_rela input: < > Basic_check_rela returns: $# error $@ $: "550 Rejected: " " listed at list.dsbl.org" > /quit Da es keine aktive Verbindung gibt es handelt sich ja hier nur um einen Test, besteht der erste Schritt darin, eine Verbindungsadresse für den Test statisch zu definieren. Als Nächstes wird der Regelsatz Basic_check_relay aufgerufen und an einen leeren Workspace übergeben. Der Workspace, der in diesem Test an den Regelsatz übergeben wird, ist unwichtig, da die erste Regel, die dem Regelsatz durch die Funktion dnsbl hinzugefügt wurde, bedingungslos den Workspace durch den Wert ersetzt, der in ${client_addr} steht. Deshalb ist der Wert, der in der dnsbl-datenbank nachgesehen wird, die Verbindungsadresse, die im Makro ${client_addr} gespeichert ist. In diesem Test wird die Adresse in der Blackhole-Liste gefunden, die bei list.dsbl.org gepflegt wird, Mail von dieser Adresse wird daher abgewiesen. Die Mail wird mit folgender Fehlermeldung zurückgewiesen: 550 Rejected: listed at list.dsbl.org Die Fehlermeldung zeigt die Adresse an, die abgewiesen wird, und den Dienst, der die Zurückweisung empfohlen hat. Diese Information ist wichtig. Die Administratoren bei könnten den Blackhole-Dienst kontaktieren, um herauszufinden, weshalb ihr System auf der schwarzen Liste steht und was sie tun können, um von der schwarzen Liste entfernt zu werden. Oft wird ein System wegen einer Fehlkonfiguration, durch die ein offenes Relay entsteht, auf eine schwarze Liste gesetzt. Sobald der Fehler behoben wurde, möchte der Administrator, dass sein System wieder von der schwarzen Liste ver- 5 Dies geht davon aus, dass die Service-Switch-Datei Host-Anfragen auf das DNS abbildet. In Kapitel 5 finden Sie Informationen über die Service-Switch-Datei. Links 236 Kapitel 6: Spam unter Kontrolle halten

255 Rechts schwindet. Dadurch, dass der Administrator erfährt, welche Dienste das System auf die schwarze Liste gesetzt haben, weiß er, welche Dienste er entsprechend ansprechen muss. Diese Konfiguration verwendet den Blackhole-Server bei list.dsbl.org, weil dieser Dienst mit Hilfe des Befehls dnsbl in diesem Rezept so festgelegt wurde es ist aber nur ein Beispiel und keine ausdrückliche Empfehlung für den Dienst list.dsbl.org. Es stehen eine Menge Blackhole-Dienste zur Verfügung, von denen einige in Tabelle 6-2 aufgeführt sind. Begeben Sie sich zu den Websites der einzelnen Dienste, und beurteilen Sie selbst deren Regelungen für die Aufnahme von Hosts in die Datenbank. Wählen Sie den Dienst aus, dessen Regelungen der von Ihnen auf Ihrem Server angestrebten Politik am nächsten kommen. Wenn auf der Kommandozeile der dnsbl-funktion kein Dienst angegeben ist, greift sendmail standardmäßig auf blackholes.mail-abuse.org zurück. Dabei handelt es sich um den gleichen Dienst, der auch von der inzwischen nicht mehr empfohlenen sendmail-funktion rbl benutzt wird. Die Funktion enhdnsbl könnte als Alternative zu dnsbl für dieses Rezept eingesetzt werden. Allerdings bietet sie in diesem speziellen Fall keinen wirklichen Vorteil. Siehe auch Bevor Sie einen Blackhole-Dienst benutzen, schauen Sie sich dessen Website an. Bei der Benutzung eines Blackhole-Dienstes übergeben Sie einen Teil der Verantwortung für Mail, die Ihr System erreicht, an eine externe Organisation. Überprüfen Sie die Regeln und den Zweck des Blackhole-List-Dienstes, um sicherzustellen, dass seine Ziele mit Ihren Zielen kompatibel sind. In den Rezepten 6.5 und 6.6 finden Sie weitere Informationen über Blackhole-Dienste, die Sie anschauen sollten, bevor Sie dieses Rezept umsetzen. Das Buch sendmail behandelt die Funktion dnsbl in Abschnitt und die Funktion enhdnsbl in Ihre eigene DNS-Blackhole-Liste anlegen Problem Sie müssen Ihre eigene DNS-Blackhole-Liste anlegen, weil kein externer Blackhole-Dienst genau die Aufnahmeregeln und den Inhalt bietet, die Sie benötigen. Lösung Der Domain-Administrator muss eine DNS-Zonendatei im richtigen Format anlegen, die alle Verbindungsadressen aufführt, die auf die schwarze Liste verbannt werden sollen. Die besonderen DNS-Address-Records in der Zonendatei werden geschaffen, indem die IP-Adresse des auf der schwarzen Liste aufgeführten Systems umgedreht wird, um das DNS-Namensfeld des Records zu erzeugen, und indem eine Adresse wie etwa Ihre eigene DNS-Blackhole-Liste anlegen 237

256 im Datenfeld des Address-Records benutzt wird. Dieses Format bedeutet, dass Hosts mit ihrer IP-Adresse auf der schwarzen Liste erscheinen und nicht mit ihrem Namen. Das ist sinnvoll, da die dnsbl-anfrage mit Hilfe der Verbindungs-IP-Adresse erledigt wird. Der DNS-Server muss die Autorität für die Domain besitzen, in der die Blackhole-Liste angesiedelt werden soll. Dies wird normalerweise erledigt, indem eine besondere Subdomain für die Blackhole-Liste innerhalb des Autoritätsbereichs des DNS-Servers angelegt wird. Erzeugen Sie auf dem sendmail-system eine Konfiguration, die die Funktion dnsbl enthält. 6 Identifizieren Sie die lokale DNS-Blackhole-Liste auf der dnsbl-kommandozeile. Hier ist ein Beispiel: dnl Point dnsbl to our local DNS blackhole list FEATURE(`dnsbl', `dnsbl.wrotethebook.com') Erstellen Sie entsprechend den Anweisungen aus Rezept 1.8 die Datei sendmail.cf neu, kopieren Sie sie nach /etc/mail, und starten Sie sendmail neu. Diskussion Die Benutzung eines Blackhole-List-Dienstes ist einfach, aber nicht besonders flexibel, da Sie nicht entscheiden können, welche Sites aufgeführt werden. Das bedeutet, dass Mail von einer freundlich gesinnten Site blockiert werden könnte, nur weil der Administrator dieser Site die Weitervermittlung falsch konfiguriert hat. Aus diesem Grund beschließen manche Einrichtungen, ihre eigene DNS-basierte schwarze Liste anzulegen. Wenn Sie Ihren eigenen Blackhole-Server konfigurieren, können Sie sicher sein, dass die Verbindungen zu allen Sites, die Sie erreichen wollen, Ihrer direkten Kontrolle unterliegen. Allerdings erfordert ein solches Vorgehen sowohl Kenntnisse in sendmail als auch in DNS. Der DNS-Administrator nutzt eine zone-anweisung in der named.conf-datei des DNS- Servers, um die Blackhole-Datenbank zu laden. Nehmen Sie einmal an, die auf der schwarzen Liste stehenden Hosts würden in einer Zonendatei namens blacklisted.hosts definiert werden, die die Daten für eine Domain namens dnsbl.wrotethebook.com bereitstellt. Dann würde folgende zone-anweisung zum Einsatz kommen: zone "dnsbl.wrotethebook.com" IN { type master; file "blacklisted.hosts"; allow-update { none; }; }; Blackhole-Einträge für die Adressen und , definiert in der Datei blacklisted.hosts, sehen so aus: IN A IN A Alternativ kann die Funktion enhdnsbl benutzt werden. Links 238 Kapitel 6: Spam unter Kontrolle halten

257 Rechts Die neu angelegte DNS-Domain wird auf der dnsbl-kommandozeile in der Lösung als Quelle für die Blackhole-Listendaten angegeben. Mail von jeder Site, die in der Domain dnsbl.wrotethebook.com aufgeführt wird, wird abgewiesen, wie dieser Versuch, Mail von zu senden, zeigt: # telnet chef smtp Trying Connected to Escape character is '^]'. 220 chef.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 22 Aug :01: helo rodent.wrotethebook.com 250 chef.wrotethebook.com Hello rodent.wrotethebook.com [ ], pleased to meet you MAIL From:<craig@rodent.wrotethebook.com> Rejected: listed at dnsbl.wrotethebook.com QUIT chef.wrotethebook.com closing connection Connection closed by foreign host. Die Verbindungsadresse wird in der Domain dnsbl.wrotethebook.com gefunden. Unser Server weist daher die Mail ab und gibt die Fehlermeldung» Rejected: listed at dnsbl.wrotethebook.com«zurück. Diese Standardfehlermeldung kann mit einem zusätzlichen Argument auf der dnsbl-kommandozeile geändert werden. Beispielsweise ändert der Befehl FEATURE(`dnsbl', `dnsbl.wrotethebook.com', `"Mail rejected. "$&{client_addr}" is a suspected spam relay."') die Fehlermeldung in»mail rejected is a suspected spam relay«. Die Standardmeldung ist jedoch ganz in Ordnung und liefert der entfernten Site mehr Informationen. Die geringe Anzahl an Systemen, die in der schwarzen Liste dieses Rezeptes standen, hätte viel einfacher durch die access-datenbank verarbeitet werden können. In den meisten Fällen ist es viel einfacher, die access-datenbank einzusetzen, um unerwünschte Mail-Verbindungen zu blockieren, als Ihre eigene schwarze Liste anzulegen. Das Erzeugen und Warten einer eigenen schwarzen Liste ist arbeitsaufwändig. Ständig müssen Systeme neu auf die Liste gesetzt oder von ihr entfernt werden. Außerdem sind viele Informationen erforderlich, um eine solche Liste zunächst einmal zu erzeugen. Es ist möglich, ein Mail-Filterwerkzeug zu benutzen, etwa procmail, um automatisch verdächtige Adressen direkt aus den Mails herauszusammeln. Allerdings ist es schwierig, ein System zu erzeugen, das die richtigen Informationen sammelt und auf dem neuesten Stand hält. Die meisten Administratoren ziehen es vor, auf der Grundlage der Blackhole-Liste, die ein entsprechender Dienst zur Verfügung stellt, ihre eigenen schwarzen Listen anzulegen. Die Dienste haben bereits große Listen und pflegen sie dauernd. Die meisten Blackhole-List-Dienste bieten irgendeine Möglichkeit, die gesamte Liste herunterzuladen. Beispielsweise kann die DSBL-Liste mit Hilfe von rsync heruntergeladen werden: # rsync rsync.dsbl.org::dsbl/bind-list.dsbl.org. 6.5 Ihre eigene DNS-Blackhole-Liste anlegen 239

258 Das regelmäßige Herunterladen und Anpassen dieser Liste ist eine Möglichkeit, Ihre eigene schwarze Liste zu erzeugen. Aber selbst wenn Sie mit einer bereits existierenden Liste beginnen, ist das Anlegen Ihrer eigenen schwarzen Liste eine Aufgabe, die Sie nicht leichtfertig auf sich nehmen sollten. Es handelt sich im Gegenteil sogar um eine der schwierigsten Techniken zum Kontrollieren unerwünschter Junk- . Wie üblich ist die Entscheidung zwischen der Benutzung eines Blackhole-List-Dienstes und dem Erstellen einer eigenen schwarzen Liste eine Entscheidung zwischen Einfachheit und Flexibilität. Die Betreiber der meisten Sites entscheiden sich für die Einfachheit. Falls Sie nicht über das notwendige Personal verfügen, das erforderlich ist, um Ihre eigene schwarze Liste aufzubauen und zu pflegen, dann sollten Sie bei dem üblichen Blackhole- List-Dienst, wie in Rezept 6.4 beschrieben, bleiben und die in Rezept 6.6 beschriebene Technik nutzen, um den Dienst an Ihre Anforderungen anzupassen. Links Siehe auch Rezept 6.4 beschreibt eine einfache Methode für die Benutzung einer schwarzen Liste. Rezept 6.6 legt dar, wie wesentliche Schwächen eines Blackhole-List-Dienstes mit Hilfe der access-datenbank ausgeglichen werden können. Lesen Sie beide Rezepte, bevor Sie dieses Rezept umsetzen. Das Buch sendmail behandelt die Funktion dnsbl in Abschnitt und die Funktion enhdnsbl in Abschnitt Informationen über die DNS-Konfiguration finden Sie in DNS und BIND von Paul Albitz und Cricket Liu (O Reilly) sowie in Linux DNS Server Administration von Craig Hunt (Sybex). 6.6 Auf einer schwarzen Liste geführte Sites wieder freigeben Problem Sie verwenden einen Blackhole-List-Dienst, der einige Sites, mit denen Sie kommunizieren müssen, auf seine schwarze Liste gesetzt hat. Sie müssen sendmail so konfigurieren, dass es die schwarze Liste für bestimmte Adressen außer Kraft setzt. Lösung Um den Blackhole-List-Dienst für eine bestimmte Adresse außer Kraft zu setzen, fügen Sie die Adresse in die Datei /etc/mail/access ein und weisen dann das Schlüsselwort OK als Rückgabewert für die Adresse zu. Verwenden Sie makemap, um eine Hash-Datenbank aus der Textdatei zu erzeugen. Legen Sie eine sendmail-konfiguration an, die entweder die Funktion dnsbl oder die Funktion enhdnsbl nutzt, um einen Blackhole-List-Dienst auszuwählen, sowie die Funktion access_db, um die schwarze Liste für ausgewählte Sites außer Kraft zu setzen. Fol- 240 Kapitel 6: Spam unter Kontrolle halten

259 Rechts gende Beispielzeilen könnten zur sendmail-konfiguration hinzugefügt werden, um diese Funktionen zu aktivieren: dnl Use dnsbl and select a blacklist service FEATURE(`dnsbl', `list.dsbl.org') dnl Use the access database FEATURE(`access_db') Erstellen Sie die Datei sendmail.cf neu, kopieren Sie sie nach /etc/mail, und starten Sie sendmail neu. In Rezept 1.8 finden Sie ein Beispiel. Diskussion Die Funktion dnsbl erweitert die sendmail.cf-konfiguration um Unterstützung für einen DNS-basierten Blackhole-List-Dienst und legt den Dienst fest, der verwendet werden soll. Tabelle 6-2 zeigt eine Liste einiger der verfügbaren Dienste. Falls kein Dienst angegeben wird, wird standardmäßig die MAPS-RBL benutzt. Wählen Sie einen Dienst sorgfältig aus. Die Beispielliste ist so konfiguriert worden, dass sie von blockiert, wie dieser Test zeigt, der von aus ausgeführt wird: # telnet chef smtp Trying Connected to Escape character is '^]'. 220 chef.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 22 Aug :01: helo rodent.wrotethebook.com 250 chef.wrotethebook.com Hello rodent.wrotethebook.com [ ], pleased to meet you MAIL From:<craig@rodent.wrotethebook.com> Rejected: listed at list.dsbl.org QUIT chef.wrotethebook.com closing connection Connection closed by foreign host. Verwenden Sie die access-datenbank, um einige der Einträge in der Blackhole-Datenbank außer Kraft zu setzen. In diesem Beispiel erledigen wir dies für die folgenden Sites: # cd /etc/mail # cat > access OK OK Ctrl-D # makemap hash access < access Nach dem Erstellen der access-datenbank ergibt ein erneuter telnet-test von folgendes Ergebnis: # telnet chef smtp Trying Connected to Escape character is '^]'. 220 chef.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 22 Aug :01: Auf einer schwarzen Liste geführte Sites wieder freigeben 241

260 helo rodent.wrotethebook.com 250 chef.wrotethebook.com Hello rodent.wrotethebook.com [ ], pleased to meet you MAIL Sender ok QUIT chef.wrotethebook.com closing connection Connection closed by foreign host. Jetzt wird Mail von akzeptiert, obwohl immer noch in der schwarzen Liste aufgeführt wird, weil die Aktion, die für die Adresse in der access- Datenbank steht, OK lautet. Wenn Sie die access-datenbank einsetzen, um einen Blackhole-List-Dienst außer Kraft zu setzen, müssen Sie normalerweise nicht mehr eine eigene DNS-basierte schwarze Liste anlegen. Im Allgemeinen scheuen sich Einrichtungen davor, auf einen Blackhole-List- Dienst zurückzugreifen, weil dieser Mail von einer freundlich gesinnten Site blockieren könnte. Indem Sie die access-datenbank mit dem Blackhole-Dienst kombinieren, erhalten Sie die Einfachheit des Blackhole-Dienstes und die Flexibilität der direkten Kontrolle darüber, mit welchen Sites Sie kommunizieren. Falls der Blackhole-Dienst außerdem eine Site nicht aufführt, von der Sie der Meinung sind, dass sie auf eine schwarze Liste gehört, können Sie die Liste selbst ergänzen. Dazu benutzen Sie einfach die access-datenbank, wie in Rezept 6.1 beschrieben. Links Siehe auch Die Rezepte 6.4 und 6.5 enthalten weitere Beispiele für den Einsatz einer schwarzen Liste. Die Rezepte 6.1 und 6.2 bieten zusätzliche Informationen über die Benutzung der access- Datenbank zur Kontrolle von Spam. Mehr über die access-datenbank im Allgemeinen finden Sie in Kapitel 3. Das Buch sendmail behandelt die Funktionen dnsbl in Abschnitt 7.2.1, enhdnsbl in Abschnitt und access_db in Abschnitt 7.5. Der Abschnitt Anti-Spam Configuration Control der Datei cf/readme behandelt ebenfalls diese Themen. 6.7 Lokale Mail mit procmail filtern Problem Sie wollen Mail vor der Auslieferung an lokale Benutzer mit procmail filtern. Lösung Fügen Sie die Funktion local_procmail in die sendmail-konfiguration ein. Dabei setzen Sie das Makro FEATURE hinter das Makro OSTYPE und vor die Zeile MAILER(`local') in der Hauptkonfigurationsdatei. Die Werte für den Mailer local werden normalerweise in der Datei OSTYPE festgelegt. Prüfen Sie die Datei sorgfältig im Hinblick auf Ihr Betriebssystem. 242 Kapitel 6: Spam unter Kontrolle halten

261 Rechts Fügen Sie die Funktion local_procmail nur dann in Ihre Hauptkonfigurationsdatei ein, wenn local_procmail nicht bereits in der Datei OSTYPE steht. Legen Sie eine Datei /etc/procmailrc an, die die Filter enthält, die Sie auf die lokale Mail anwenden wollen. Erstellen und installieren Sie die neue Konfiguration, wie in Rezept 1.8 beschrieben. Diskussion Die OSTYPE-Datei linux.m4 enthält die Funktion local_procmail, da procmail der local- Mailer ist, der standardmäßig auf den meisten Linux-Systemen verwendet wird. Auf einem Linux-System ist es für dieses Rezept ausreichend, einfach eine Konfiguration auszuführen, die die OSTYPE-Datei linux.m4 benutzt. Andere Systeme sind nicht so einfach. Nehmen Sie beispielsweise an, Sie haben ein Solaris-8-System. Die OSTYPE-Datei solaris8. m4 benutzt die Funktion local_lmtp, um mail.local als local-mailer festzulegen. Um den Mailer local auf procmail zu ändern, überschreiben Sie die Funktion local_lmtp, indem Sie die Funktion local_procmail in die Hauptkonfigurationsdatei setzen. Hier ist ein Beispiel mit der Datei generic-solaris.mc: VERSIONID(`Solaris with local_procmail added') OSTYPE(solaris2) DOMAIN(generic) dnl Add the local_procmail feature FEATURE(`local_procmail') MAILER(local) MAILER(smtp) Da die Funktion local_procmail nach dem Makro OSTYPE auftritt, setzt sie die Funktion local_lmtp außer Kraft, die in der Datei OSTYPE definiert ist. Die Funktion local_procmail wird aktiviert, sobald die Datei sendmail.cf erzeugt und nach /etc/mail kopiert worden ist und sendmail neu gestartet wurde. Wenn die Funktion local_procmail benutzt wird, übergibt sendmail lokale Mail zur Auslieferung an procmail. procmail verarbeitet die Mail, wobei es zuerst die Befehle verwendet, die in der Datei /etc/procmailrc definiert sind, und dann auf die Befehle zurückgreift, die in der Datei.procmailrc im Home-Verzeichnis des Empfängers definiert sind. Falls keine rc-datei definiert wurde, schreibt procmail die Mail unverändert in die Mailbox des Benutzers. Beachten Sie, dass die.procmailrc-datei des Benutzers auf Mail angewandt wird, die durch die Funktion local_procmail ausgeliefert wird. Wenn local_procmail benutzt wird, ist es für den Benutzer nicht erforderlich, das Programm procmail aus der Datei.forward heraus aufzurufen, wie in der Einführung zu diesem Kapitel gezeigt wurde. Der Benutzer muss lediglich eine.procmailrc-datei anlegen; diese wird auf die Mail angewandt. Wird procmail als lokaler Mailer eingesetzt, können sowohl der Systemadministrator als auch der Benutzer eingehende Mail mit procmail filtern. Wenn procmail als local-mailer eingesetzt wird, führt sendmail es mit drei Argumenten aus: -Y, -a und -d. Das Argument -Y weist procmail an, das Standard-Berkeley-Unix-Mail- 6.7 Lokale Mail mit procmail filtern 243

262 box-format zu verwenden. Das Argument -d liefert procmail den Benutzernamen des lokalen Empfängers, der die Mail empfangen soll (im Mail-Auslieferungstriple ist dies der Wert user). Das Argument -a übergibt einen optionalen Wert an procmail, der innerhalb des procmail-rezepts als Variable $1 erreichbar ist; im Mail-Auslieferungstriple handelt es sich hierbei um den Wert host. sendmail übergibt einen Wert nur dann durch -a, wenn entweder die +detail-syntax benutzt wird oder Mail über die mailertable an den local- Mailer geroutet wird. Im Fall der +detail-syntax wird der Wert detail übergeben. Im Fall der mailertable handelt es sich bei dem übergebenen Wert um die Eingangsadresse, die den Schlüssel zum mailertable-eintrag gebildet hat. In allen anderen Fällen wird kein Wert durch das Argument -a übergeben und die Variable $1 bleibt unbelegt. Links Siehe auch Die Funktion local_procmail hat Folgen für die Sicherheit, und zwar für smrsh sowie für Versuche, die Mail-Weiterleitung durch Benutzer zu beschränken. In den Rezepten 10.6 und 10.8 finden Sie Näheres. Rezept 6.8 liefert zusätzliche Informationen über procmail. Das Buch sendmail behandelt.forward in Kapitel 13 und die Funktion local_procmail in Abschnitt Auf den Manpages procmail, procmailrc, procmailex und procmailsc finden Sie weitere Informationen über das Filtern von Mail mit procmail. 6.8 Ausgehende Mail mit procmail filtern Problem Sie wollen sendmail so konfigurieren, dass es Mail, die an bestimmte Domains adressiert ist, mit Hilfe von procmail als Mail-Filtersoftware filtert. Lösung Erstellen Sie eine mailertable, die Mail, die an bestimmte Domains gerichtet ist, durch den Mailer procmail routet. Legen Sie eine Datei im Verzeichnis /etc/procmailrcs an, die die speziell benötigte Filterung definiert. Es können mehrere Filter benutzt werden. Erzeugen Sie eine sendmail-konfiguration, die die Funktion mailertable aktiviert und procmail zur Liste der verfügbaren Mailer hinzufügt. Hier sind die Zeilen, die zur sendmail-konfiguration hinzugefügt werden müssen: dnl Enable support for the mailertable FEATURE(`mailertable') dnl Add procmail to the list of available mailers MAILER(procmail) 244 Kapitel 6: Spam unter Kontrolle halten

263 Rechts Erstellen Sie die Datei sendmail.cf, kopieren Sie sie nach /etc/mail/sendmail.cf, und starten Sie sendmail neu, wie in Rezept 1.8 beschrieben. Diskussion Das Makro MAILER(procmail) fügt die procmail-mailer-definition in die Datei sendmail.cf ein. Der Mailer procmail hat nichts mit der Funktion local_procmail zu tun. Ein System kann den Mailer procmail benutzen, ohne procmail als local-mailer einzusetzen, und procmail kann als local-mailer verwendet werden, ohne dass das Makro MAILER(procmail) in der Konfiguration auftauchen muss. Das Makro MAILER(procmail) fügt keinen Code in die Konfiguration ein, um den Mailer procmail zu benutzen. Sie müssen entweder eigene sendmail.cf-regeln anlegen, um den Mailer zu referenzieren, oder Sie müssen die Mail mit Hilfe der mailertable durch den Mailer procmail routen. Die Benutzung der mailertable ist die einfachste und auch empfohlene Methode, um auf den Mailer zuzugreifen. Hier legen wir mailertable-einträge an, die procmail aufrufen: # cd /etc/mail # cat >> mailertable example.com procmail:/etc/procmailrcs/spam-filter wrotethebook.net procmail:/etc/procmailrcs/spam-filter fake.ora.com procmail:/etc/procmailrcs/uce-filter Ctrl-D # makemap hash mailertable < mailertable Das Beispiel fügt drei Einträge in die mailertable ein, die Mail durch den Mailer procmail routen. Das erste Feld in einem mailertable-eintrag ist der Schlüssel, mit dem die Empfängeradresse verglichen wird. Das zweite Feld sind der mailer-wert und der host-wert, die sendmail benutzt, um das Mail-Auslieferungstriple zu erstellen. In diesem Beispiel wird Mail mit einer passenden Empfängeradresse durch den Mailer procmail geroutet. Einige Tests eines Systems, das dieses Rezept einsetzt, zeigen das: # sendmail -bv crooks@example.com crooks@example.com... deliverable: mailer procmail, host /etc/procmailrcs/ spam-filter, user crooks@example.com # sendmail -bv spammers@wrotethebook.net spammers@wrotethebook.net... deliverable: mailer procmail, host /etc/procmailrcs/spamfilter, user spammers@wrotethebook.net # sendmail -bv thieves@fake.ora.com thieves@fake.ora.com... deliverable: mailer procmail, host /etc/procmailrcs/ uce-filter, user thieves@fake.ora.com Wenn Mail an den Mailer procmail geroutet wird, muss der Host-Wert ($h) den Pfadnamen der rc-datei enthalten, die procmail einsetzen soll, um die Mail zu filtern. Im obigen Beispiel werden in Abhängigkeit vom Ziel der zwei unterschiedliche Filter spam-filter und uce-filter an procmail übergeben. sendmail ruft procmail vom procmail-mailer aus mit dem folgenden Befehl auf: procmail -Y -m $h $f $u 6.8 Ausgehende Mail mit procmail filtern 245

264 Das Flag -Y weist procmail an, das Berkeley-Unix-Mailbox-Format zu benutzen. Das Flag -m führt procmail als allgemeinen Mail-Filter aus. Das erste Argument, das dem Flag -m folgt, muss der Pfad der rc-datei sein, die die procmail-filterrezepte enthält. sendmail weist den Host-Wert, der durch die mailertable-anfrage zurückgeliefert wird, dem Makro $h zu, das diesen dann als erstes Argument nach dem Flag -m an procmail übergibt. Deshalb muss das host-feld eines mailertable-eintrags, den der Mailer procmail benutzt, den vollständigen Pfadnamen einer rc-datei enthalten. Die nächsten beiden Argumente, die an procmail übergeben werden, sind die Umschlagabsenderadresse ($f) und die Umschlagempfängeradresse ($u). Diese Werte stehen innerhalb der procmail rc-datei als Variablen $1 bzw. $2 zur Verfügung. Links Durch das Filtern ausgehender Mail mit procmail können unter Umständen Routing-Schleifen entstehen. Rezepte, die die Mail löschen, sie an den Absender zurückschicken oder sie an eine dritte Partei weiterleiten, stellen kein Problem dar. Falls die Mail jedoch untersucht und dann an den ursprünglichen Empfänger gesandt wird, kehrt sie zu sendmail zurück, das sie an procmail routet, das sie an sendmail zurückgibt, das sie... Sie verstehen. Falls einige der ausgehenden Mails, die von procmail gefiltert werden, wieder an den ursprünglichen Empfänger geschickt werden, müssen Sie eventuell eigenen sendmail.cf-code hinzufügen, um die Schleife zu vermeiden. Eine gebräuchliche Technik zum Vermeiden von Schleifen besteht darin, die Pseudodomain.PROCMAIL zur Empfängeradresse hinzuzufügen, wenn die Mail an den ursprünglichen Empfänger weitergeschickt wird. Die Pseudodomain stellt sicher, dass die Empfängeradresse nun keinem Wert in der mailertable mehr entspricht, wodurch die Schleife unterbrochen wird. Die Pseudodomain wird durch procmail-befehle in der rc- Datei angelegt. Allerdings ist eine richtig konfigurierte rc-datei nicht die ganze Lösung..PROCMAIL ist keine echte Domain, daher muss Code in die Datei sendmail.cf eingefügt werden, der sicherstellt, dass die Pseudodomain korrekt verarbeitet wird. Die folgenden m4-makros und der sendmail.cf-code, angehängt an das Ende der Hauptkonfigurationsdatei dieses Rezepts, verarbeiten die Pseudodomain.PROCMAIL, falls eine durch die rc-datei hinzugefügt wurde: LOCAL_CONFIG # Add.PROCMAIL to the pseudo-domain list CP.PROCMAIL LOCAL_RULE_0 # Strip.PROCMAIL and send via esmtp R$+ $+.PROCMAIL. > $#esmtp $@ $2 $: $1<@$2> Das Makro LOCAL_CONFIG kennzeichnet den Beginn des Codes, der dem Abschnitt mit den lokalen Informationen der Datei sendmail.cf hinzugefügt werden soll. In diesem Beispiel fügen wir einen Kommentar und einen C-Befehl hinzu. Der C-Befehl fügt.procmail in die Klasse P ein. Die Klasse P führt Pseudodomains auf, bei denen sendmail nicht versuchen soll, sie im DNS nachzusehen. Durch das Hinzufügen von.procmail zu Klasse P 246 Kapitel 6: Spam unter Kontrolle halten

265 Rechts vermeiden Sie die Verzögerungen und verschwendete Ressourcen, die auftreten, wenn sendmail einen Domainnamen nachsieht, der nicht existiert. Das Makro LOCAL_RULE_0 kennzeichnet den Beginn des sendmail.cf-codes, der zum Regelsatz 0 hinzugefügt wird üblicherweise als parse-regelsatz bezeichnet. Der Code, der auf das Makro LOCAL_RULE_0 folgt, wurde zum Regelsatz ParseLocal hinzugefügt, der einen Einstieg in den Regelsatz parse bietet, in dem lokal definierte Regeln hinzugefügt werden. 7 Der Regelsatz parse schreibt die Auslieferungsadresse in ein Mail-Auslieferungstriple um. Der Code, der auf das Makro LOCAL_RULE_0 in dem Beispiel folgt, ist ein Kommentar und eine Rewrite-Regel. Der R-Befehl vergleicht Eingangsadressen der Form benutzer@domain. PROCMAIL und schreibt diese Adressen in ein Mail-Auslieferungstriple um, wobei der Mailer esmtp, der Host-Wert domain und der Benutzerwert benutzer@domain ist. Nach dem Neuerstellen der Konfiguration mit der neuen Hauptkonfigurationsdatei zeigt ein sendmail -bv- Test die Wirkung dieser Rewrite-Regel: # sendmail -bv crooks@example.com.procmail crooks@example.com.procmail... deliverable: mailer esmtp, host example.com, user crooks@example.com Siehe auch Rezept 6.7 bietet zusätzliche Informationen über procmail. Das Buch sendmail behandelt LOCAL_CONFIG in Abschnitt und LOCAL_RULE_0 in Abschnitt Weitere Informationen über die Filterung von Mail mit procmail finden Sie auf den Manpages procmail, procmailrc, procmailex und procmailsc. Rezept 5.1 erklärt die mailertable und zeigt, wie sie dazu verwendet wird, Mail an einen beliebigen speziellen Mailer zu routen. 6.9 Eine besondere Header-Verarbeitung auslösen Problem Sie müssen die sendmail-konfiguration um angepasste Header-Prüfungen erweitern. Lösung Hängen Sie Ihre eigene Header-Verarbeitung mit einem LOCAL_CONFIG-Makro und einem LOCAL_RULESETS-Makro an das Ende der Hauptkonfigurationsdatei an. Das Makro LOCAL _CONFIG fügt in der Datei sendmail.cf Zeilen zum Abschnitt mit den lokalen Informationen hinzu und wird deshalb verwendet, um alle Makros, Klassen oder Datenbanken zu definieren, die von Ihrer eigenen Header-Verarbeitung verwendet werden. Benutzen Sie 7 Der Regelsatz ParseLocal ist auch als Regelsatz 98 bekannt. 6.9 Eine besondere Header-Verarbeitung auslösen 247

266 das Makro LOCAL_RULESET, um Ihren angepassten Regelsatz zur Datei sendmail.cf hinzuzufügen. In der Diskussion werden Sie Beispiele für beide Makros finden. Erstellen Sie die Datei sendmail.cf, kopieren Sie sie nach /etc/mail/sendmail.cf, und starten Sie sendmail neu, wie in Rezept 1.8 beschrieben. Links Diskussion Die Datei knecht.mc, die mit der sendmail-distribution geliefert wird, enthält eine Vielzahl von Beispielen, die unterschiedliche Aspekte der sendmail-konfiguration illustrieren. Das folgende Beispiel für eine eigene Header-Prüfung stammt aus der Datei knecht.mc: LOCAL_CONFIG # # Names that won't be allowed in a To: line (local-part and domains) # C{RejectToLocalparts} friend you C{RejectToDomains} public.com LOCAL_RULESETS HTo: $>CheckTo SCheckTo R$={RejectToLocalparts}@$* R$*@$={RejectToDomains} $#error $: "553 Header error" $#error $: "553 Header error" Eine eigene Header-Verarbeitung erfordert neben der normalen m4-konfiguration zusätzlichen sendmail.cf-code. Das Makro LOCAL_CONFIG kennzeichnet den Anfang der Zeilen, die direkt zu dem Abschnitt mit den lokalen Informationen in der Datei sendmail.cf hinzugefügt werden. Im Beispiel definieren die beiden C-Zeilen, die dem Makro LOCAL_CONFIG folgen, zwei Klassen und laden diese Klassen mit einigen Werten. Das Makro LOCAL_RULESET zeigt an, dass ein lokal definierter Regelsatz folgt. Die erste Zeile in dem Beispiel, die LOCAL_RULESET folgt, ist der Header-Befehl, der den eigenen Regelsatz aufruft: HTo: $>CheckTo Dieser H-Befehl ruft den Regelsatz CheckTo auf, wenn in einem Mail-Datenstrom von einem entfernten System ein To:-Header eintrifft. Die $>-Syntax bildet die Standardmethode, über die Regelsätze aus Rewrite-Regeln und Header-Definitionen aufgerufen werden. Der Regelsatz selbst beginnt mit einem S-Befehl, der einen Regelsatznamen CheckTo definiert. Der Regelsatz enthält zwei Rewrite-Regeln. Die erste Regel erfasst jeden To:-Header, der eine Adresse mit einem Benutzernamen enthält, die in der Klasse $={RejectToLocalparts} gefunden wird. Im Beispiel wäre das jede Mail, die an den Benutzernamen friend oder den Benutzernamen you adressiert wäre. Mail, die an einen dieser Benutzernamen adressiert ist, wird mit dem Fehler»553 Header error«abgewiesen. 248 Kapitel 6: Spam unter Kontrolle halten

267 Rechts Die zweite Rewrite-Regel erfasst alle To:-Header, die Mail an einen Hostnamen adressieren, der in der Klasse $={RejectToDomains} gefunden wird. Im Beispiel enthält die Klasse nur den Hostnamen public.com. Mail, die an public.com adressiert ist, wird mit dem Fehler»553 Header error«abgewiesen. Der Regelsatz CheckTo kann leicht mit sendmail -bt getestet werden: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > CheckTo friend@wrotethebook.com CheckTo input: wrotethebook. com CheckTo returns: $# error $: "553 Header error" > CheckTo craig@public.com CheckTo input: public. com CheckTo returns: $# error $: "553 Header error" > CheckTo craig@wrotethebook.com CheckTo input: wrotethebook. com CheckTo returns: wrotethebook. com > /quit Der Regelsatz wird aufgerufen und ihm wird der Inhalt eines Beispiel-To:-Headers übergeben. Beachten Sie, dass dem Regelsatz der Inhalt des Headers ohne den Header-Namen übergeben wird. Dies wiederholt die Methode, mit der der Regelsatz während eines wirklichen Durchlaufs aufgerufen wird. In allen drei Tests funktioniert der Regelsatz CheckTo wie erwartet der Benutzername friend und der Hostname public.com werden abgewiesen, die Adresse craig@wrotethebook.com dagegen passiert den Regelsatz unbeschadet. Der Regelsatz CheckTo ist ein vereinfachtes Beispiel. Das Implementieren eines eigenen Regelsatzes zur Header-Verarbeitung, der effektiv zur Spam-Bekämpfung eingesetzt werden könnte, wäre bedeutend komplexer. Allerdings würden bei einer selbst erstellten Header-Verarbeitung die gleiche H-Befehlssyntax zum Aufruf eines eigenen Header- Regelsatzes, das gleiche LOCAL_CONFIG-Makro und das gleiche LOCAL_RULESET-Makro wie in diesem Beispiel zum Einsatz kommen. Bevor Sie eine eigene Header-Verarbeitung in sendmail anlegen, um Spam zu bekämpfen, schauen Sie sich die Alternativen an, wie etwa das Filtern der Mail mit einem MILTER oder mit procmail, und stellen Sie sicher, dass Ihr Ansatz bei der Implementierung und Wartung der einfachste und effektivste ist. Siehe auch Rezept 6.10 enthält ebenfalls ein Beispiel aus knecht.mc. Die Rezepte 6.7 und 6.8 behandeln procmail, und Rezept 6.12 behandelt MILTER, alles Alternativen zur Verarbeitung von Headern, die Sie sich anschauen sollten, bevor Sie eigene sendmail.cf-regelsätze schreiben. Das Buch sendmail behandelt das Makro LOCAL_RULESETS in Abschnitt und das Makro LOCAL_CONFIG in Abschnitt In TCP/IP Netzwerk-Administration, dritte Auflage, von Craig Hunt (O Reilly) und Linux Sendmail Administration von Craig Hunt (Sybex) finden Sie weitere Informationen über die sendmail.cf-befehle. 6.9 Eine besondere Header-Verarbeitung auslösen 249

268 6.10 Reguläre Ausdrücke in sendmail verwenden Links Problem Für sendmail ist eine besondere Konfiguration erforderlich, um reguläre Ausdrücke zum Suchen nach Mustern in Adressen oder Headern benutzen zu können. Lösung Führen Sie den Befehl sendmail -d0.1 aus. Die Zeile»Compiled with:«, die durch den Befehl ausgegeben wird, sollte MAP_REGEX enthalten. Ist dies nicht der Fall, dann kompilieren Sie sendmail erneut, wie in Rezept 1.4 beschrieben. Ergänzen Sie die Hauptkonfigurationsdatei am Ende durch Ihren eigenen Code. Fügen Sie den K-Befehl, der den regulären Ausdruck definiert, zum Abschnitt mit den lokalen Informationen der Datei sendmail.cf hinzu. Dazu benutzen Sie das Makro LOCAL_CONFIG. Mit Hilfe des Makros LOCAL_RULESETS fügen Sie einen eigenen Regelsatz hinzu, um auf den regulären Ausdruck zuzugreifen. Die Diskussion bietet ein Beispiel dafür, wie diese Befehle verwendet werden. Erstellen Sie die Datei sendmail.cf, kopieren Sie sie nach /etc/mail/sendmail.cf, und starten Sie sendmail neu, wie in Rezept 1.8 gezeigt. Diskussion Reguläre Ausdrücke werden mit Hilfe des sendmail.cf-k-befehls definiert, der auch dazu benutzt wird, eine Datenbank zu definieren. Auf den regulären Ausdruck wird dann aus der Konfiguration heraus auf die gleiche Weise zugegriffen wie auf eine normale Datenbank. Das folgende Beispiel aus der Datei knecht.mc illustriert, wie ein regulärer Ausdruck definiert und benutzt wird: LOCAL_CONFIG # # Regular expression to reject: # * numeric-only localparts from aol.com and msn.com # * localparts starting with a digit from juno.com # Kcheckaddress regex -a@match ^([0-9]+<@(aol msn)\.com [0-9][^<]*<@juno\.com)\.?> LOCAL_RULESETS SLocal_check_mail # check address against various regex checks R$* $: $>Parse0 $>3 $1 R$+ $: $(checkaddress $1 $) R@MATCH $#error $: "553 Header error" 250 Kapitel 6: Spam unter Kontrolle halten

269 Rechts Zuerst wird das Makro LOCAL_CONFIG in die m4-hauptkonfigurationsdatei eingefügt. Das Makro LOCAL_CONFIG kennzeichnet den Beginn des Codes, der in den Abschnitt mit den lokalen Informationen der Datei sendmail.cf eingefügt werden soll. Der K-Befehl, der den regulären Ausdruck definiert, folgt auf dieses Makro. Die Syntax des K-Befehls lautet: Kname typ argumente Dabei ist K der Befehl, name ist der interne Name, der benutzt wird, um auf die Datenbank zuzugreifen, die durch diesen Befehl definiert wird, typ ist der Datenbanktyp, und die argumente definieren die Datenbank, die benutzt werden soll. Die argumente weisen folgendes Format auf: flag beschreibung Dabei definieren die flags die von der Datenbank benutzten Optionen. beschreibung identifiziert die Datenbank, die verwendet wird. Bei der beschreibung handelt es sich in den meisten Fällen um einen Pfad zu einer externen Datenbank, entweder einer lokalen Datenbank oder einer Datenbank, die durch einen Datenbank-Server erreichbar ist. Bei einem regulären Ausdruck jedoch ist die beschreibung die Definition des regulären Ausdrucks, mit dem die Eingabedaten verglichen werden. Der K-Befehl in dem Beispiel lautet: Kcheckaddress regex -a@match ^([0-9]+<@(aol msn)\.com [0-9][^<]*<@juno\.com)\.?> In diesem Beispiel sieht es also folgendermaßen aus: K ist der Befehl. checkaddress ist der interne Name. regex ist der Typ. -a@match ist ein Flag, das sendmail anweist, den zurückzuliefern, wenn eine Übereinstimmung gefunden wurde. ^([0-9]+<@(aol msn)\.com [0-9][^<]*<@juno\.com)\.?> ist ein regulärer Ausdruck. Es handelt sich hierbei um einen einfachen regulären Ausdruck, der mit Werkzeugen wie egrep und awk benutzt werden könnte. Dieser reguläre Ausdruck erfasst -Adressen von aol.com, msn.com und juno.com, die numerische Benutzernamen enthalten. Der K-Befehl definiert zwar den regulären Ausdruck, es wird jedoch eine Rewrite-Regel benötigt, um ihn zu benutzen. Das Makro LOCAL_RULESETS wird verwendet, um einen eigenen Regelsatz in die Datei sendmail.cf einzufügen. Im Zentrum des Beispielregelsatzes Local_check_mail gibt es drei R-Befehle: R$* $: $>Parse0 $>3 $1 R$+ $: $(checkaddress $1 $) R@MATCH $#error $: "553 Header error" Die Adresse, die an den Regelsatz Local_check_mail übergeben wird, wird zuerst durch den Regelsatz 3 verarbeitet (auch als canonify-regelsatz bezeichnet). Das Ergebnis dieser Verarbeitung wird dann an den Regelsatz Parse0 übergeben. Beachten Sie, dass beide Regelsätze durch den ersten Rewrite-Befehl aufgerufen werden. Diese Verarbeitung 6.10 Reguläre Ausdrücke in sendmail verwenden 251

270 bringt die Adresse in ihre kanonische Form. Für die Adresse wird dann durch die zweite Rewrite-Regel ein Mustervergleich anhand des regulären Ausdrucks checkaddress durchgeführt. Entspricht die Adresse dem regulären Ausdruck, wird sie durch den ersetzt. Die dritte Rewrite-Regel prüft, ob der Workspace diesen String enthält. Ist dies der Fall, wird ein Header-Fehler zurückgegeben. Einige Tests zeigen, wie der reguläre Ausdruck und der Regelsatz funktionieren: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > Local_check_mail 123@aol.com Local_check_mail input: aol. com canonify input: aol. com Canonify2 input: 123 aol. com > Canonify2 returns: 123 aol. com. > canonify returns: 123 aol. com. > Parse0 input: 123 aol. com. > Parse0 returns: 123 aol. com. > Local_check_mail returns: $# error $: "553 Header error" > Local_check_mail win@aol.com Local_check_mail input: aol. com canonify input: aol. com Canonify2 input: win aol. com > Canonify2 returns: win aol. com. > canonify returns: win aol. com. > Parse0 input: win aol. com. > Parse0 returns: win aol. com. > Local_check_mail returns: win aol. com. > > /quit Der erste Test übergibt die Adresse 123@aol.com an den Regelsatz Local_check_mail. Diese Adresse sollte von dem regulären Ausdruck checkaddress erfasst werden. Der Fehler, der durch den Regelsatz Local_check_mail zurückgeliefert wird, zeigt dies. Der zweite Test wird durchgeführt, um zu beweisen, dass gültige Adressen von aol.com diesen Fehler nicht hervorrufen. Dieses Beispiel, das aus der Datei knecht.mc stammt, ist keine Empfehlung dafür, numerische aol.com-adressen herauszufiltern. Stattdessen soll es Ihnen zeigen, wie ein regulärer Ausdruck definiert und benutzt wird. Das Makro LOCAL_CONFIG, das Makro LOCAL_RULESET und die Syntax des K-Befehls sind für eigene reguläre Ausdrücke und Regelsätze identisch mit denen in diesem einfachen Beispiel. Siehe auch Rezept 6.9 bietet zusätzliche Informationen, die Ihnen helfen, dieses Rezept zu verstehen. In Kapitel 1 wird beschrieben, wie Sie sendmail kompilieren. Das Buch sendmail behandelt das Makro LOCAL_CONFIG in Abschnitt , LOCAL_RULESETS in Abschnitt und den Datenbanktyp regex in Abschnitt Das O Reilly-Buch Reguläre Ausdrücke, zweite Auflage, geht ausführlich auf reguläre Ausdrücke ein. In den beiden Bü- Links 252 Kapitel 6: Spam unter Kontrolle halten

271 Rechts chern TCP/IP Netzwerk-Administration, dritte Auflage, von Craig Hunt (O Reilly) und Linux Sendmail Administration von Craig Hunt (Sybex) finden Sie weitere Informationen über die sendmail.cf-befehle Lokale Benutzer identifizieren, die Ihnen Probleme bereiten Problem Spammer verbergen ihre wahren Identitäten. Sie wollen sich so viele Informationen wie möglich verschaffen, um Spammer zu verfolgen, die Ihr System benutzen. Lösung Führen Sie den auth-dienst (identd) aus, um sich Zugangsinformationen zu beschaffen, die durch Masquerading oder andere -Techniken nicht verborgen werden können. Diskussion Das IDENT-Protokoll wird in RFC 1413, Identification Protocol, definiert. Das Protokoll bietet eine Möglichkeit, die Identität des Benutzers zu ermitteln, der eine Netzwerkverbindung initiiert hat. Der identd-daemon implementiert das IDENT-Protokoll auf Unix- Systemen. Führen Sie identd aus, um entfernten Systemadministratoren weitere Informationen zu liefern und ihnen damit zu helfen, die Ursache von Problemen zu verfolgen. Im Umfeld von sendmail könnten diese Informationen helfen, Spammer zu verfolgen, falls einer von Ihrem System aus agiert. Nehmen Sie beispielsweise an, ein Benutzer auf einem System, das identd ausführt, versucht, eine Verfälschung zu erzielen, indem er den SMTP- Befehl EHLO mit einem falschen Hostnamen aufruft: ehlo rodent.wrotethebook.com Hello wrotethebook.com [ ], pleased to meet you Wenn das entfernte System, in diesem Fall rodent.wrotethebook.com, auf den Befehl EHLO antwortet, ignoriert es den gefälschten Hostnamen Stattdessen sagt es»hello«zu dem Host, den es unter der Verbindungsadresse vorfindet. Es antwortet mit dem Hostnamen, der mit dieser Adresse verknüpft ist, also mit chef. wrotethebook.com, und den Identifikationsinformationen, die von dem identd-dienst geliefert werden, der auf chef läuft. Diese Information wird in der Mail in einem Received:-Header bekannt gemacht, wie unten gezeigt: Received: from [ ]) by rodent.wrotethebook.com (8.12.9/8.12.9) with ESMTP id gb4n6t for Wed, 4 Dec :06: Lokale Benutzer identifizieren, die Ihnen Probleme bereiten 253

272 Die Information, die von dem identd-dienst bereitgestellt wird, der auf dem Host unter läuft, identifiziert den Benutzer, der die Mail geschickt hat. Bei dem String, der von identd geliefert wird, r+9gemj2wip8fajdu8kdzlyuiretzjyc in unserem Beispiel, handelt es sich nicht um einen einfachen Benutzernamen. In diesem Fall ist die identd- Information verschlüsselt. identd überwacht Port 113. Wenn identd läuft, kann der entfernte Server Informationen über alle TCP-Verbindungen von Ihrem Server zum entfernten Server abfragen, indem er das Quell- und Ziel-Port-Paar an den Identifikationsserver schickt. identd antwortet dann, indem es entweder die angeforderten Informationen, verknüpft mit der Verbindung, oder einen Fehler schickt. Diese Informationen erlauben es entfernten Mailservern, in eingehenden Mails einen echten Benutzernamen in den Received:-Header zu setzen. Leute, die das Mail-System missbrauchen, wollen natürlich nicht, dass ihre echten Benutzernamen bekannt werden. Wenn sie ihre Namen ihren Opfern gleich mitliefern, werden sie nicht lange im Geschäft bleiben. Leider blockieren viele Firewalls Port 113, weil die Sicherheitsverantwortlichen befürchten, dass durch den identd-dienst zu viele Informationen herausgegeben werden. Diese Angst ist unbegründet, wenn die identd-informationen verschlüsselt werden, wie in diesem Beispiel. Viele Sicherheitsverantwortliche gehen jedoch lieber auf Nummer Sicher und blockieren den Port. Ist dies an Ihrer Firewall der Fall, können Sie identd nicht benutzen. Das IDENT-Protokoll ist auch unter dem Dienstnamen auth bekannt, wie dieser grep von /etc/services zeigt: $ grep ^auth /etc/services auth 113/tcp ident # User Verification Die meisten sendmail-administratoren ziehen es vor, den Dienst als ident oder identd zu bezeichnen, um eine Verwechslung mit dem ESMTP-Schlüsselwort AUTH zu vermeiden, das in Kapitel 7 erläutert wird. Außerdem ist identd kein Authentifizierungswerkzeug, sondern ein Prüfwerkzeug. Echte Spammer, die ihre eigenen Systeme kontrollieren, können beliebige Dinge in eine identd-antwort setzen, weshalb Sie der Antwort nicht wirklich für eine Authentifizierung vertrauen können. Sie sind jedoch kein Spammer. Sie führen identd aus, um zusätzliche Prüfinformationen zu beschaffen und auf diese Weise Benutzer zu verfolgen, die Ihr System missbrauchen. Viele Unix-Systeme führen identd auf Verlangen von inetd oder xinetd aus. Wenn die folgende Zeile zur inetd.conf hinzugefügt wird, implementiert sie Rezept 6.1 auf einem System, das inetd und einen bedarfsmäßigen identd-dienst betreibt: auth stream tcp nowait nobody /usr/sbin/in.identd in.identd -t120 Das ist natürlich nur ein Beispiel. Sie müssten den Programmpfadnamen und die Kommandozeilenargumente an Ihr System und Ihre Anforderungen anpassen. Sie sollten außerdem die identd-manpage nach Optionen überprüfen, die verhindern, dass der Benutzer identd deaktiviert. Links 254 Kapitel 6: Spam unter Kontrolle halten

273 Rechts Einige andere Unix-Systeme führen identd als Teil des Systemstartvorgangs aus. Unser RedHat-Linux-System ist ein Beispiel dafür. Ein chkconfig-befehl fügt identd in den Boot- Vorgang ein. Ein service-befehl startet identd sofort: # chkconfig --list identd identd 0:off 1:off 2:off 3:off 4:off 5:off 6:off # chkconfig --level 35 identd on # chkconfig --list identd identd 0:off 1:off 2:off 3:on 4:off 5:on 6:off # service identd start Generating ident key: [ OK ] Starting identd: [ OK ] Der erste chkconfig-befehl zeigt, dass identd nicht im Boot-Vorgang auf diesem Beispiel- Linux-System enthalten ist. Der zweite chkconfig-befehl fügt ihn für die Runlevel 3 und 5 in den Startvorgang ein die Runlevel, die mit dem Netzwerk- und Mehrbenutzerbetrieb auf den meisten Linux-Systemen verbunden sind. Der letzte chkconfig-befehl zeigt die Wirkung dieser Änderung. Natürlich gibt es keinen Grund, das System neu zu starten, nur um identd zu starten. Deshalb wird der Befehl service verwendet, um den Identifikationsdienst sofort auszuführen. Dies ist das erste Mal, dass identd auf diesem Server gestartet wurde. Beachten Sie die erste Ausgabezeile des service-befehls. Sie teilt uns mit, dass ein Schlüssel für identd erzeugt wurde. Dieser Schlüssel wird benutzt, um die Informationen zu verschlüsseln, die an das entfernte System gesandt werden. Die Administratoren des entfernten Systems können die Informationen nicht entschlüsseln, weil sie den Schlüssel nicht haben. Falls sie ein Problem vermuten, müssen sie Ihnen den verschlüsselten String zusenden, den Sie dann mit Hilfe der Datei /etc/identd.key und des Befehls idecrypt entschlüsseln können. Die Informationen vom identd-server sind aus Sicherheitsgründen verschlüsselt. Sicherheitsleute mögen identd nicht, weil es Informationen über Systeme und Benutzer preisgibt, die von Spammern und Eindringlingen missbraucht werden können. Das Verschlüsseln der identd- Antwort erlaubt es Ihnen, den Identifikationsdaemon ohne größere Sicherheitsrisiken auszuführen. Beispielsweise zeigt der Received:-Header, der weiter vorn in diesem Abschnitt dargestellt wurde, den 32 Zeichen langen, BASE64-kodierten String r+9gemj2wip8fajdu8kdz lyuiretzjyc, den das entfernte System als Antwort auf die IDENT-Anfrage von unserem Beispielsystem bekommen hat. Der String enthält keine Informationen, die von einem Spammer oder einem Eindringling ausgenutzt werden könnten. Er kann aber von Ihnen benutzt werden, um Informationen über den lokalen Benutzer zu liefern, der die Mail gesandt hat. Wenn der entfernte Systemadministrator Sie mit einem Problembericht kontaktiert, dann holen Sie den 32 Byte langen String, schließen ihn in eckige Klammern ein und dekodieren ihn mit dem Befehl idecrypt: # idecrypt [r+9gemj2wip8fajdu8kdzlyuiretzjyc] Wed Dec 4 17:00: Ctrl-D 6.11 Lokale Benutzer identifizieren, die Ihnen Probleme bereiten 255

274 Der dekodierte String liefert folgende Informationen: Datum und Uhrzeit, an denen die Verbindung hergestellt wurde Die UID des Benutzers, der die Verbindung initiiert hat (500 in diesem Beispiel) Die IP-Adresse der Quelle der Verbindung ( ) Den Quell-Port (1029) Die Ziel-IP-Adresse ( ) Den Ziel-Port der Verbindung (25, das ist der SMTP-Port) Diese Informationen sind hilfreich, wenn Sie feststellen wollen, wer Ihr System missbraucht. Allerdings weist identd größere Einschränkungen auf. Der Daemon liefert nur dann eine sinnvolle UID zurück, wenn sich der Benutzer tatsächlich an Ihrem System anmeldet. Wurde das System auf eine andere Weise missbraucht, dann ist diese Information möglicherweise nicht sehr hilfreich. Außerdem erhöht sich durch identd der Verarbeitungsaufwand für die einzelnen Mails. Wie die meisten Dinge auch hat identd Vor- und Nachteile. Auf unserem Beispiel-Red-Hat-Linux-System ist der identd-dienst in der Datei /etc/ identd.conf vorkonfiguriert. Darüber hinaus kann der identd-dienst mit Hilfe von Kommandozeilenoptionen von der Kommandozeile aus konfiguriert werden. Auf einem Red- Hat-Linux-System werden die identd-kommandozeilenoptionen, die während des Starts zum Einsatz kommen, als Werte für die Variable IDENTDOPTS in der Datei /etc/sysconfig/ identd definiert. In der identd-manpage finden Sie Hinweise zu den identd.conf-konfigurationsbefehlen und den Kommandozeilenoptionen. Links Siehe auch Lesen Sie die Manpages für identd, inetd.conf, chkconfig und den Befehl service MILTER benutzen Problem Sie haben ein externes Mail-Filterwerkzeug installiert, das der Sendmail Mail Filter API entspricht. Sie müssen sendmail nun so konfigurieren, dass es diesen externen Mail-Filter benutzt. Lösung Führen Sie den Befehl sendmail -d0.1 aus. Die Zeile»Compiled with:«, die von dem Befehl ausgegeben wird, sollte MILTER enthalten. Ist das nicht der Fall, aktivieren Sie die MILTER- Unterstützung, indem Sie die folgende Zeile in die Datei site.config.m4 einfügen: APPENDDEF(`confENVDEF', `-DMILTER') Kompilieren Sie sendmail nun so, wie in Kapitel 1 in den Rezepten 1.3 bis 1.7 beschrieben. 256 Kapitel 6: Spam unter Kontrolle halten

275 Rechts Fügen Sie ein INPUT_MAIL_FILTER-Makro in die sendmail-konfiguration ein, das den externen Mail-Filter identifiziert. Das Makro INPUT_MAIL_FILTER muss mindestens den internen Namen des Filters und die Socket-Spezifikation definieren, die von dem Filter verlangt wird. In der Dokumentation des MILTERs finden Sie die empfohlenen Einstellungen. Als Beispiel könnte die folgende Zeile zur sendmail-konfiguration hinzugefügt werden, um den MILTER vbsfilter zu benutzen, der unter zur Verfügung steht: INPUT_MAIL_FILTER(`sample', `S=local:/var/run/vbsfilter.sock') Erstellen Sie die Datei sendmail.cf neu, kopieren Sie sie nach /etc/mail, und starten Sie sendmail neu, wie in Rezept 1.8 beschrieben. Diskussion Bevor ein externes Programm von sendmail benutzt werden kann, muss es gefunden, installiert und richtig konfiguriert werden. Die Einführung in dieses Kapitel weist auf einige Websites hin, auf denen Sie Ihre Suche nach nützlichen MILTERn beginnen können. Wegen der Komplexität der Filterung von Spam und des Scannens nach Viren und auf Grund der sich ständig ändernden Natur der Gefahren kann das Konfigurieren eines MILTERs eine viel größere Herausforderung sein als das Konfigurieren von sendmail, um den MILTER zu benutzen. Lesen Sie die MILTER-Dokumentation sorgfältig, damit Sie genau verstehen, welche INPUT_MAIL_FILTER-Argumente benötigt werden, damit sendmail sich mit dem externen Filter austauschen kann. Die Beispiel-sendmail-Konfiguration in der Lösung verwendet ein INPUT_MAIL_FILTER- Makro, das von der Dokumentation des Mail-Filters vbsfilter empfohlen wird. Das Programm vbsfilter identifiziert verschiedene gefährliche ausführbare Anhänge und benennt sie mit der Erweiterung.txt um, so dass sie nicht automatisch vom System des Endbenutzers ausgeführt werden. Der Socket, der in dem Makro INPUT_MAIL_FILTER definiert wird, muss dem Socket entsprechen, der von dem MILTER benutzt wird. Für vbsfilter wird dies erreicht, indem der MILTER mit dem Argument -p ausgeführt wird, das vbsfilter mitteilt, welcher Socket benutzt werden soll. Nimmt man das Makro INPUT_MAIL_FILTER, das in der Lösung gezeigt wurde, dann würde vbsfilter mit dem folgenden Befehl gestartet werden: # vbsfilter -p S=local:/var/run/vbsfilter.sock Das Programm vbsfilter ist ein guter Einstieg, da es keine großartige Konfiguration verlangt. Ebenso verhält es sich mit dem Beispiel-MILTER, der in der Datei libmilter/readme mitgeliefert wird, die in der sendmail-distribution enthalten ist. Der Beispiel-Mail-Filter führt keine sinnvolle Filterung durch, ist aber einfach zu testen und nützlich, wenn Sie feststellen wollen, ob Ihr sendmail-system richtig konfiguriert und in der Lage ist, mit einem externen Filter zusammenzuarbeiten. Viele Filter sind so komplex, dass die gleichzeitige Fehlersuche beim MILTER und bei sendmail einfach zu viel sein kann. Benutzen Sie einen einfachen Filter, um die Fehler bei sendmail zu beheben, bevor Sie sendmail mit einem komplexen Filter interagieren lassen MILTER benutzen 257

276 Siehe auch Die Einführung in dieses Kapitel bietet weitere Informationen über MILTER. Das Buch sendmail behandelt MILTER in Abschnitt 7.6. Die Datei libmilter/readme behandelt dieses Thema ebenfalls, genau wie die Dateien in libmilter/docs. Links 6.13 Spam-Überprüfungen umgehen Problem Ihr sendmail ist so konfiguriert, dass es eingehende Junk-Mail blockiert. Sie wurden gebeten, Junk-Mail durchzulassen, wenn sie an bestimmte Empfänger adressiert ist. Lösung Legen Sie für jeden Empfänger, der Junk-Mail empfangen darf, einen Eintrag in der Textdatei /etc/mail/access an. Benutzen Sie das Tag Spam: und die Empfängeradresse, um das Schlüsselfeld des Eintrags zu erzeugen. Verwenden Sie das Schlüsselwort FRIEND als Rückgabewert für die einzelnen Einträge. Führen Sie makemap aus, um eine Hash-Datenbank aus der Textdatei zu erstellen. Erzeugen Sie eine sendmail-konfiguration, die die Funktion access_db und die Funktion delay_checks mit dem optionalen Argument friend enthält. Stellen Sie sicher, dass das access_db-makro FEATURE vor dem delay_checks-makro FEATURE in der Konfiguration steht. Hier sind die Zeilen, die in die sendmail-konfiguration eingefügt werden würden: dnl Use the access database FEATURE(`access_db') dnl Check for spam friends before rejecting the mail FEATURE(`delay_checks', `friend') Erstellen Sie die Datei sendmail.cf neu, kopieren Sie die neue sendmail.cf nach /etc/mail, und starten Sie sendmail neu, wie in Rezept 1.8 beschrieben. Diskussion Jemand auf Ihrem System der Postmaster, ein Sicherheitsexperte oder ein Entwickler, der Mail-Filter schreibt möchte Junk-Mail empfangen, die normalerweise von sendmail blockiert wird. Die Funktion delay_checks erlaubt dies, indem sie die Reihenfolge ändert, in der Spam-Überprüfungen durchgeführt werden. Die Funktion delay_checks lässt zu, dass die Umschlagempfängeradresse vor der Umschlagabsenderadresse oder der Verbindungsadresse geprüft wird, wodurch es wiederum möglich wird, für Mail, die an bestimmte Empfänger adressiert ist, die beiden anderen Prüfungen zu umgehen. Um die Funktion delay_checks auf diese Weise zu benutzen, muss sie mit dem Argument friend aufgerufen werden, wie in der Lösung gezeigt. 258 Kapitel 6: Spam unter Kontrolle halten

277 Rechts Die Empfänger, denen der Empfang von Junk-Mail erlaubt werden soll, werden in der access-datenbank mit Hilfe des Tags Spam: und des Rückgabewerts FRIEND definiert. Hier ist eine Beispiel-access-Datenbank: Connect:example.com REJECT FRIEND FRIEND Auf der Grundlage der sendmail-konfiguration, die in der Lösung beschrieben wird, weist diese access-datenbank Mail von example.com ab, es sei denn, sie ist an com oder an adressiert. Siehe auch Rezept 6.14 zeigt ein ähnliches Beispiel. Kapitel 3 und die Einführung in dieses Kapitel bieten weitere Informationen über die access-datenbank. Das Buch sendmail behandelt die access-datenbank in Abschnitt 7.5 und die Funktion delay_checks in Abschnitt Der Abschnitt Delay all checks der Datei cf/readme geht ebenfalls auf dieses Thema ein Spam-Überprüfungen pro Benutzer aktivieren Problem Sie wurden gebeten, eine sendmail-konfiguration anzulegen, die Überprüfungen nur dann durchführt, wenn die Mail an bestimmte Empfänger adressiert ist. Lösung Fügen Sie für jeden Empfänger, dessen Mail vor der Auslieferung alle Prüfungen durchlaufen soll, einen Eintrag in die Textdatei /etc/mail/access ein. Benutzen Sie das Tag Spam: und die Empfängeradresse, um das Schlüsselfeld des Eintrags zu erzeugen. Das Schlüsselwort HATER dient als Rückgabewert für die einzelnen Einträge. Führen Sie makemap aus, um aus der Textdatei eine Hash-Datenbank zu erzeugen. Legen Sie eine sendmail-konfiguration an, die die Funktion access_db und die Funktion delay_checks mit dem optionalen Argument hater enthält. Stellen Sie sicher, dass das access_db-makro FEATURE vor dem delay_checks-makro FEATURE in der Konfiguration steht. Hier sind die Zeilen, die Sie in die sendmail-konfiguration einfügen würden: dnl Use the access database FEATURE(`access_db') dnl Apply all checks to spam hater mail FEATURE(`delay_checks', `hater') Erstellen Sie die Datei sendmail.cf neu, kopieren Sie die neue sendmail.cf nach /etc/mail, und starten Sie sendmail neu, wie in Rezept 1.8 beschrieben Spam-Überprüfungen pro Benutzer aktivieren 259

278 Diskussion Die Funktion delay_checks ändert die Reihenfolge, in der Überprüfungen durchgeführt werden, indem sie zuerst die Umschlagempfängeradresse prüft. Wenn die Funktion delay_checks mit dem Argument hater aufgerufen wird, wie in der Lösung dargestellt, dann müssen die Umschlagempfängeradresse in der access-datenbank gefunden und der Wert HATER zurückgeliefert werden, bevor die Umschlagabsenderadresse oder die Verbindungsadresse geprüft werden. Wird die Umschlagabsenderadresse in der access-datenbank nicht gefunden oder wird nicht der Wert HATER zurückgeliefert, dann wird die Prüfung der Umschlagabsenderadresse, die von check_mail durchgeführt wird, oder die Prüfung der Verbindungsadresse, die von check_relay durchgeführt wird, umgangen. Um die check_mail- und check_relay-prüfungen an der Mail eines Empfängers durchzuführen, müssen die speziellen Empfänger in der access-datenbank mit Hilfe des Tags Spam: und des Rückgabewertes HATER definiert sein. Hier sind Beispieleinträge: Connect:example.com REJECT HATER HATER Mit Hilfe der sendmail-konfiguration dieses Rezepts weist diese access-datenbank Mail von example.com ab, wenn sie an oder an adressiert ist. Alle anderen Benutzer dürfen Mail von example.com empfangen. Links Siehe auch Rezept 6.13 zeigt ein ähnliches Beispiel. Kapitel 3 und die Einführung in dieses Kapitel bieten weitere Informationen über die access-datenbank. Das Buch sendmail behandelt die access-datenbank in Abschnitt 7.5 und die Funktion delay_checks in Abschnitt Der Abschnitt Delay all checks der Datei cf/readme geht ebenfalls auf dieses Thema ein. 260 Kapitel 6: Spam unter Kontrolle halten

279 First Kapitel 7 KAPITEL 7 Authentifizierung mit AUTH 7.0 Einführung Starke Authentifizierung nutzt kryptographische Techniken, um die Identität der Endpunkte in einem Netzwerkaustausch zu verifizieren. Für sendmail stellt starke Authentifizierung sicher, dass der verbindende Host und der empfangende Host wirklich die sind, die sie zu sein vorgeben. In diesem Kapitel schauen wir uns an, wie AUTH für die Authentifizierung verwendet werden kann. Authentifizierung ist nicht identisch mit Verschlüsselung. Verschlüsselung kann eingesetzt werden, um den Inhalt einer Mail oder den gesamten SMTP-Protokollaustausch, einschließlich der Mail, zu verbergen. (Eine Technik zum Verschlüsseln des SMTP-Austauschs und der Mail, die dabei transportiert wird, wird in Kapitel 8 behandelt.) Bei der Authentifizierung dagegen wird der Inhalt von Mails nicht verborgen; stattdessen wird sichergestellt, dass die Mail aus der richtigen Quelle stammt. Traditionelle sendmail-authentifizierungssysteme basieren auf dem Hostnamen oder der IP-Adresse. Beispiele dafür finden Sie in Kapitel 3, wo Hostnamen und IP-Adressen eingesetzt werden, um Vermittlungsberechtigungen zu gewähren. Allerdings ist die aktuelle IP-Adresse eines gültigen Clients unter Umständen nicht bekannt. Ein mobiler Client, der seine Adresse von einem DHCP-Server bezieht, könnte eine Adresse haben, die sich dauernd ändert. Mobile Clients benötigen ein Authentifizierungsschema, das von einer veränderlichen IP-Adresse unabhängig ist. Außerdem können Hostnamen und Adressen leicht gefälscht werden und eignen sich daher nicht für eine starke Authentifizierung. Natürlich könnte man nun darüber philosophieren, ob ein Dienst wie die Mail-Weitervermittlung wirklich eine starke Authentifizierung benötigt, allerdings ist es klar, dass mobile Clients eine Authentifizierung erfordern, die unabhängig von der IP-Adresse ist. Das AUTH-Protokoll bietet einige Techniken der starken Authentifizierung, die sich nicht auf die IP-Adresse oder den Hostnamen verlassen. 261

280 Das AUTH-Protokoll AUTH ist eine SMTP-Protokollerweiterung. Sie ist in RFC 2554, SMTP Service Extension for Authentication, definiert. RFC 2554 umreißt die Verhandlungen, die eingesetzt werden, um einen Authentifizierungsmechanismus auszuwählen. RFC 2554 beschreibt drei Funktionen für das Schlüsselwort AUTH: 250-AUTH ist die Antwort auf den SMTP-Befehl EHLO. Die Antwort gibt die unterstützten Authentifizierungsmechanismen bekannt. Die Konfiguration, die sendmail veranlasst, AUTH in die EHLO-Antwort aufzunehmen und eingehende AUTH-Verbindungen zu akzeptieren, wird in Rezept 7.1 behandelt. Diese Konfiguration gilt, wenn sendmail als MTA läuft, und ist nur anwendbar, wenn sendmail mit der Kommandozeilenoption -bd ausgeführt wird. AUTH ist der SMTP-Befehl, der dazu verwendet wird, die Authentifizierung anzufordern und den Authentifizierungsmechanismus für die Sitzung auszuwählen. Der verbindende Host muss einen der Mechanismen auswählen, die von dem empfangenden Host bekannt gemacht werden, oder der Authentifizierungsversuch wird abgewiesen. sendmail fordert die AUTH-Authentifizierung an, wenn es so konfiguriert wurde, wie in Rezept 7.2 beschrieben. Ein Laptop oder Desktop-Rechner, der SMTP-Mail sendet, aber keine eingehenden SMTP-Verbindungen akzeptiert, könnte nur mit Hilfe von Rezept 7.2 konfiguriert werden. Ein System, das eingehende AUTH-Verbindungen akzeptiert und ausgehende AUTH-Verbindungen erzeugt, würde die Konfigurationen aus den Rezepten 7.1 und 7.2 kombinieren. AUTH= ist ein Parameter, der auf der Zeile MAIL From: benutzt wird, um die authentifizierte Quelladresse zu identifizieren. Der Parameter AUTH= stammt als Teil der anfänglichen Umschlagabsenderadresse von dem verbindenden Host. Wenn der empfangende Host dem Parameter AUTH= vertraut, macht er ihn dem nächsten Mail Relay bekannt. Rezept 7.6 enthält weitere Informationen über den Parameter AUTH=. Das AUTH-Protokoll greift für die eigentliche Authentifizierung auf SASL (Simple Authentication and Security Layer) zurück. RFC 2222, Simple Authentication and Security Layer (SASL), beschreibt das SASL-Framework und definiert, wie Protokolle eine Authentifizierungsmethode aushandeln. RFC 2222 nennt vier Authentifizierungstechniken: KERBEROS_V4 Die Authentifizierung wird durch einen Kerberos-4-Server durchgeführt. GSSAPI Die GSS-API wird für die Authentifizierung verwendet. Diese Art der Authentifizierung kann durch einen Kerberos-5-Server durchgeführt werden. S/KEY Das Einmal-Kennwort-System S/Key wird für die Authentifizierung verwendet. EXTERNAL Die Authentifizierung hängt von einem externen Sicherheitssystem wie Transport Layer Security (TLS) ab. Links 262 Kapitel 7: Authentifizierung mit AUTH

281 Rechts Später wurden dem SASL-Framework mehrere weitere Authentifizierungstechniken hinzugefügt. Hier einige Beispiele: ANONYMOUS Diese Technik, die in RFC 2245 definiert ist, erlaubt einen nicht-authentifizierten Zugriff. PLAIN Die Authentifizierung basiert auf Klartextkennwörtern. LOGIN Dies ist eine nicht-dokumentierte Authentifizierungstechnik, die ebenfalls Klartextkennwörter einsetzt. Sie wurde hinzugefügt, um für Kompatibilität mit veralteten SMTP-Clients zu sorgen. CRAM-MD5 Dies ist eine Authentifizierungsmethode mit gemeinsam genutztem Geheimnis (Shared Secret), die für die Sicherheit Message Digest 5 (MD5) verwendet. Der Challenge Response Authentication Mode MD5 (CRAM-MD5) ist eine ältere Authentifizierungsmethode, die inzwischen von DIGEST-MD5 abgelöst wurde. DIGEST-MD5 Dies ist die bevorzugte MD5-Authentifizierungsmethode. Ebenso wie CRAM-MD5 handelt es sich um eine Shared-Secret-Authentifizierungsmethode, die Message Digest 5 (MD5) für die Sicherheit verwendet. Allerdings ist DIGEST-MD5 widerstandsfähiger gegenüber Angriffen auf die Sicherheit und benutzt eine Verschlüsselung für die SMTP-Konversation. sendmail enthält keine Implementierungen der verschiedenen Authentifizierungstechniken. Stattdessen verwendet es Techniken, die in SASL implementiert und konfiguriert sind. Damit dies funktioniert, muss Cyrus SASL auf dem sendmail-system richtig installiert und konfiguriert sein. Cyrus SASL Cyrus SASL ist als Bibliothek implementiert. Die SASL-Bibliothek standardisiert die Art und Weise, wie Anwendungen mit den Authentifizierungsmethoden kommunizieren. Auf vielen Unix-Systemen sind die SASL-Bibliotheken vorinstalliert. Bei unserem Beispiel-RedHat-Linux-System ist dies etwa der Fall. Red Hat enthält SASL als eines der Standard-RPMs. Ein rpm-befehl kann prüfen, ob es installiert ist, wie in diesem Beispiel: # rpm -qa cyrus-sasl cyrus-sasl Falls SASL auf Ihrem System nicht installiert ist, dann überprüfen Sie, ob es als Teil Ihrer Unix-Software mitgeliefert wurde. Ist dies der Fall, dann installieren Sie die Kopie von SASL, die Ihr Unix-Hersteller bereitgestellt hat. Gibt es keine Version von Ihrem Hersteller, dann laden Sie von oder von ftp://ftp.andrew. Einführung 263

282 cmu.edu/pub/cyrus-mail/ die neueste Version von SASL herunter. Informationen über SASL finden Sie unter Nachdem Cyrus SASL installiert wurde, müssen die speziellen Authentifizierungstechniken konfiguriert werden, bevor sie benutzt werden können. Um die SASL-Konfiguration zu verstehen, müssen Sie die SASL-Terminologie verstehen. Die Cyrus SASL-Dokumentation definiert vier besondere Begriffe: 1 userid Der Benutzername, der die Berechtigungen ermittelt, die dem Client gewährt werden. Dem Client werden die Berechtigungen gegeben, die normalerweise dem angegebenen Benutzer gewährt werden. userid wird auch als authorization id bezeichnet. authid Der Zugangsname, der benutzt wird, um die Verbindung zu authentifizieren. authid wird auch als authentication id bezeichnet. realm Eine Gruppe von Benutzern, Systemen und Diensten, die eine gemeinsame Authentifizierungsumgebung nutzen. Alle Mitglieder einer bestimmten Gruppe verwenden den gleichen realm-wert. Es ist üblich, einen Domainnamen oder einen Hostnamen für den Wert realm zu benutzen. mechanism Identifiziert die Art der verwendeten Authentifizierung. Beispielsweise ist DIGEST- MD5 ein gültiger Wert für mechanism. Die Werte userid und authid rufen die meiste Verwirrung hervor. Um zu verstehen, wie SASL diese beiden Werte einsetzt, sollten Sie sich eine /etc/passwd-datei mit einem Eintrag für craig und einem anderen für kathy vorstellen. Bei einem normalen Login werden Kathy, wenn sie sich am Zugang kathy anmeldet, die Berechtigungen gewährt, die diesem Zugang zugewiesen wurden. Mit SASL ist es möglich, authid auf kathy und userid auf craig zu setzen. Das bedeutet, dass das Kennwort des Zugangs kathy für die Authentifizierung erforderlich ist, die Berechtigungen, die dem Benutzer gewährt werden, jedoch denen entsprechen, die der Benutzer des Zugangs craig besitzt. Mehrere der Techniken zur starken Authentifizierung, die über SASL zur Verfügung stehen, erfordern die Konfiguration getrennter Authentifizierungsdienste KERBEROS_V4 und GSSAPI sind gute Beispiele dafür. Dieses Kapitel konzentriert sich auf Techniken zur starken Authentifizierung, die auf einem sendmail-system implementiert werden können, ohne dass andere Software als SASL installiert werden muss. Zwei Techniken zur starken Authentifizierung, DIGEST-MD5 und CRAM-MD5, werden mit den Cyrus SASL-Bibliotheken bereitgestellt. Beide Techniken können leicht für die sendmail-authentifizierung konfiguriert werden. 1 Neben diesen vier besonderen Elementen verwendet SASL ein Kennwort, wenn eines durch die Authentifizierungstechnik verlangt wird. Links 264 Kapitel 7: Authentifizierung mit AUTH

283 Rechts DIGEST-MD5 und CRAM-MD5 werden durch die /etc/sasldb-datenbank konfiguriert. Dies erfolgt mit Hilfe der saslpasswd-befehle. Benutzen Sie saslpasswd, um die SASL-authidund realm-werte sowie das Kennwort einzugeben, das der verbindende Host während der Authentifizierung verwendet. Rezept 7.1 zeigt an einem Beispiel, wie das geht. Da es sich hierbei um Shared-Secret-Authentifizierungsmechanismen handelt, muss der verbindende Host mit Werten konfiguriert werden, die denjenigen entsprechen, die in die Datei sasldb auf dem empfangenden Host eingegeben wurden. Bei sendmail-8.12-systemen werden diese Werte in einem AuthInfo:-Eintrag definiert. Normalerweise wird dieser Eintrag in die access-datenbank gesetzt, wie in Rezept 7.2 beschrieben. Optional kann eine authinfo-datei eingesetzt werden, um die AUTH-Credentials aufzunehmen, wie in Rezept 7.3 beschrieben. Die SASL-Datei Sendmail.conf DIGEST-MD5 und CRAM-MD5 sind sehr sicher und einfach zu konfigurieren, weshalb sie eine ausgezeichnete Wahl für die sendmail-authentifizierung darstellen. Es gibt jedoch andere Authentifizierungstechniken, die durch SASL zur Verfügung gestellt werden und zusammen mit sendmail eingesetzt werden können. Einige der anderen Mechanismen verlangen die Konfiguration durch die SASL-Anwendungsdatei Sendmail.conf, während dies bei DIGEST-MD5 und CRAM-MD5 nicht der Fall ist. In der Datei Sendmail.conf können drei Konfigurationsbefehle eingesetzt werden. Dies sind: srvtab Der Befehl srvtab verweist auf die Datei, die den Kerberos-4-Service-Schlüssel enthält. Das Argument, das mit diesem Befehl angegeben wird, ist der vollständige Pfadname der Service-Schlüsseldatei. auto_transition Der Befehl auto_transition veranlasst SASL, automatisch einen sasldb-eintrag für jeden Benutzer anzulegen, der sich mit der Authentifizierungsmethode PLAIN authentifiziert. pwcheck_method Der Befehl pwcheck_method definiert die Technik, die SASL verwenden soll, um das Klartextkennwort auf seine Gültigkeit zu prüfen, das während der Authentifizierung mit der Methode PLAIN empfangen wurde. Die möglichen Werte für pwcheck_method sind: passwd Weist SASL an, Kennwörter in der Datei /etc/passwd nachzusehen. shadow Weist SASL an, Kennwörter in der Datei /etc/shadow nachzusehen. Wegen der mit der Datei /etc/shadow verknüpften Dateiberechtigungen muss die Anwendung als root laufen. Einführung 265

284 pam Weist SASL an, Pluggable Authentication Modules (PAM) zu verwenden. PAM muss natürlich entsprechend konfiguriert sein, um das Kennwort zu authentifizieren. sasldb Teilt SASL mit, dass die Kennwörter für die Authentifizierungsmethode PLAIN in der Datei sasldb gespeichert sind. Normalerweise wird sasldb nur für die DIGEST-MD5- und CRAM-MD5-Authentifizierung verwendet. kerberos_v4 Weist SASL an, Klartextkennwörter durch den Kerberos-4-Server zu authentifizieren. Kerberos 4 muss installiert und konfiguriert sowie in Betrieb sein, und der Kerberos-4-Server muss so konfiguriert sein, dass er Klartextkennwörter akzeptiert. sia Weist SASL an, die Security Integration Architecture (SIA) von Digital zum Validieren von Kennwörtern einzusetzen. pwcheck Weist SASL an, die Daten zur Kennwortüberprüfung an ein externes Programm zu übergeben. Ein sendmail-system, das die PLAIN-Authentifizierungsmethode bekannt gibt, könnte eine Sendmail.conf-Datei aufweisen, die der hier gezeigten vergleichbar ist: # cat /usr/lib/sasl/sendmail.conf pwcheck_method:pam Die Rezepte in diesem Kapitel brauchen die Datei /usr/lib/sasl/sendmail.conf nicht, weil sie jeweils den DIGEST-MD5-Authentifizierungsmechanismus benutzen, bei dem die Datei Sendmail.conf nicht erforderlich ist. DIGEST-MD5 ist sicher, einfach zu konfigurieren und steht als Teil von Cyrus SASL zur Verfügung. Falls Sie einen anderen SASL-Authentifizierungsmechanismus benutzen müssen, suchen Sie in der SASL-Dokumentation nach weiteren Informationen darüber, wie dieser konfiguriert wird. Links Flags an SASL übergeben sendmail kann so konfiguriert werden, dass es für das AUTH-Protokoll eine optionale Verarbeitung von SASL anfordert. Die Definition confauth_options kann verschiedene Flags setzen, die die Art und Weise beeinflussen, wie sendmail und SASL interagieren. Diese Flags sind in Tabelle 7-1 aufgeführt. Tabelle 7-1: SASL-Flags Flags A a c Aufgabe Nutzt den Parameter AUTH= nur bei einer erfolgreichen Authentifizierung. Fordert optionalen Schutz vor aktiven Angriffen während des Authentifizierungsaustauschs an. Verlangt die Client-Credentials, falls der Authentifizierungsmechanismus diese unterstützt. 266 Kapitel 7: Authentifizierung mit AUTH

285 Rechts Tabelle 7-1: SASL-Flags (Fortsetzung) Flags d f p y Aufgabe Weist Authentifizierungstechniken ab, die anfällig für Wörterbuchangriffe sind. Verwendet nicht für jede Sitzung das gleiche statische Shared Secret (gemeinsames Geheimnis). Weist Authentifizierungstechniken ab, die anfällig für einfache passive Angriffe sind. Lässt den Authentifizierungsmechanismus ANONYMOUS nicht zu. Die Option A steuert, wann der Parameter AUTH= zur Umschlagabsenderinformation auf der SMTP-Kommandozeile Mail From: hinzugefügt wird. Die Option A wird in Rezept 7.6 benutzt, das demonstriert, wie die Flag-Definition confauth_options verwendet wird. Die Option a verstärkt die Überprüfungen, die SASL durchführt, um aktive Authentifizierungsangriffe zu entdecken. SASL wird in vielen verschiedenen Situationen eingesetzt. Bei manchen Anwendungen ist die höhere Sicherheit die Kosten wert, die durch erhöhte Verarbeitungs- und Authentifizierungsverzögerungen entstehen. Normalerweise ist das für nicht der Fall. Mail-Hosts verwenden Authentifizierung, um Spammer davon abzuhalten, Ihren Server als Relay zu benutzen. Spammer wenden weder Zeit noch Geld auf, um aktive Authentifizierungsangriffe gegen Server zu fahren, die eine starke Authentifizierung einsetzen. Wenn für eine -Verbindung eine erhöhte Sicherheit erforderlich ist, dann ist es wahrscheinlich besser, auf Transport Layer Security zurückzugreifen, wie in Kapitel 8 beschrieben wird. Das Flag c weist SASL an, Client-Credentials anzufordern, wenn ein Authentifizierungsmechanismus verwendet wird, der Client-Credentials unterstützt. (Obwohl es nicht innerhalb einer SASL-Sitzung benutzt wird, bildet das TLS-Protokoll, das in Kapitel 8 beschrieben wird, ein Beispiel für ein Protokoll, das optional den Einsatz von Client- Credentials erlaubt.) Verwechseln Sie Client-Credentials nicht mit AUTH-Credentials. Die AUTH-Credentials, die in diesem Kapitel diskutiert wurden, sind das Shared Secret und andere AUTH-Werte, die für die Authentifizierung verwendet werden. Die Authentifizierungstechniken DIGEST-MD5 und CRAM-MD5, die von sendmail benutzt werden, verlangen die AUTH-Credentials ohne die Option c. Die Option f weist SASL an, zwischen Sitzungen Forward Security einzusetzen. Das bedeutet, dass das Shared Secret, das für eine Sitzung benutzt wurde, in der nächsten Sitzung nicht mehr verwendet wird. Es muss eine Technik geben, um für jede Sitzung ein neues Geheimnis auszuhandeln. Dies erfordert selbstverständlich einen Authentifizierungsmechanismus, der mit Forward Security klarkommt. Die Authentifizierungstechniken, die üblicherweise durch sendmail benutzt werden, implementieren keine Forward Security; daher wird dieses Flag in einer sendmail-konfiguration normalerweise nicht benutzt. Die drei verbleibenden Optionen, d, p und y, schränken jeweils die Techniken ein, die für die Authentifizierung benutzt werden können. Wird beispielsweise die Option p angegeben, dann wird der Einsatz der Techniken PLAIN und LOGIN über eine unsichere Verbindung blockiert. Einführung 267

286 Diese Flags übergeben Informationen an SASL, wodurch die Art und Weise geändert wird, wie SASL sendmail dient. Werte, die von SASL übergeben werden, werden ebenfalls innerhalb von sendmail benutzt. Authentifizierungsmakros und -regelsätze sendmail nutzt die Informationen, die durch die Authentifizierung bereitgestellt werden. Es speichert Authentifizierungsdaten in mehreren Makros. Die Authentifizierungsmakros sind: ${auth_author} Dieses Makro nimmt die sendmail-autorisierungs-id auf, bei der es sich um die Adresse handelt, die dem Parameter AUTH= auf der MAIL From:-Zeile zugewiesen ist. ${auth_authen} Dieses Makro nimmt die sendmail-authentifizierungs-id auf, bei der es sich entweder um die userid oder die userid und den realm-wert, geschrieben als handelt. ${auth_type} Dieses Makro nimmt den Namen der Authentifizierungsmethode auf, die verwendet wird, um den Client zu authentifizieren. Beispielsweise wäre DIGEST-MD5 ein möglicher ${auth_type}-wert. ${auth_ssf} Dieses Makro enthält die Anzahl der Bits, die für eine optionale SASL-Verschlüsselung verwendet werden. Wird keine SASL-Verbindungsverschlüsselung benutzt, dann bleibt dieses Makro unbelegt. Zusätzlich zu den Authentifizierungsmakros werden der Hostname und die IP-Adresse des Systems am anderen Ende der Mail-Transportverbindung in Makros gespeichert, was nützliche Informationen für Authentifizierungsüberprüfungen bieten kann. Die folgenden Werte werden in den Makros gespeichert: ${server_addr} Die IP-Adresse des entfernten Servers, wie von der TCP-Verbindung festgestellt. Dieses Makro wird auf dem Client benutzt. ${server_name} Der Hostname des entfernten Servers, wie anhand einer Hostnamenabfrage des Wertes ${server_addr} festgestellt. Dieses Makro wird auf dem Client benutzt. ${client_addr} Die IP-Adresse des Clients, wie von der TCP-Verbindung festgestellt. Dieses Makro wird auf dem Server benutzt. ${client_name} Der Hostname des Clients, wie anhand einer Hostnamenabfrage des Wertes ${client _addr} festgestellt. Dieses Makro wird auf dem Server benutzt. Links 268 Kapitel 7: Authentifizierung mit AUTH

287 Rechts sendmail bietet außerdem auch Einstiegspunkte in Regelsätze, die den Vorgang des Hinzufügens von Authentifizierungsprüfungen vereinfachen. Die wichtigsten Einstiegspunkte, die mit AUTH benutzt werden, sind: Local_check_mail Dieser Regelsatz erweitert den Regelsatz check_mail um Prüfungen, was verwendet wird, um die Umschlagabsenderadresse von der Zeile MAIL From: zu verarbeiten. Der Regelsatz check_mail ist nicht AUTH-spezifisch, allerdings bedeutet die Überschneidung zwischen dem Wert ${auth_author} und der Umschlagabsenderadresse, dass Local_check_mail gelegentlich für eine eigene AUTH-Verarbeitung genutzt wird. Local_check_rcpt Dieser Regelsatz fügt Prüfungen zum Regelsatz check_rcpt hinzu, der die Umschlagempfängeradresse von der Zeile RCPT To: verarbeitet. Der Regelsatz check_rcpt ist nicht AUTH-spezifisch, da er jedoch verwendet wird, um die Auslieferung an einen Empfänger zu autorisieren, wird Local_check_rcpt gelegentlich eingesetzt, um ihn für die AUTH-Verarbeitung zu modifizieren. Local_trust_auth Dieser Regelsatz erweitert den Regelsatz trust_auth, der vom Server benutzt wird, um Prüfungen, um festzustellen, ob der Parameter AUTH= auf der MAIL From:-Zeile vertrauenswürdig ist. Der Regelsatz trust_auth ist für das AUTH-Protokoll spezifisch, weil der Parameter AUTH= nur benutzt wird, wenn AUTH auf dem Client läuft. Benutzen Sie Local_trust_auth, um die Verarbeitung des Parameters AUTH= anzupassen. Local_Relay_Auth Dieser Regelsatz wird durch den Regelsatz Rcpt_ok aufgerufen. Standardmäßig gewährt sendmail einem authentifizierten Client nur dann Vermittlungsberechtigungen, wenn der Client sich mit einem Mechanismus authentifiziert, der in der Klasse $={TrustAuthMech} aufgeführt wird. Benutzen Sie Local_Relay_Auth, um den Vorgang, wie authentifizierten Clients Vermittlungsberechtigungen gewährt werden, zu modifizieren. 7.1 Eine AUTH-Authentifizierung anbieten Problem Um eine starke Authentifizierung anzufordern, bevor besondere Berechtigungen, wie etwa die Weitervermittlung (Relaying), gewährt werden, wurden Sie gebeten, sendmail so zu konfigurieren, dass es eine AUTH-Authentifizierung anbietet. Lösung AUTH erfordert die SASL-Bibliothek. Konfigurieren Sie diejenige SASL-Authentifizierungstechnik, die Sie benutzen wollen. In der Einführung dieses Kapitels finden Sie Informationen über die SASL und woher Sie sie bekommen können. 7.1 Eine AUTH-Authentifizierung anbieten 269

288 Überprüfen Sie mit -d0.1 die sendmail-compiler-optionen. Wenn die»compiled with:«- Liste SASL anzeigt, starten Sie sendmail neu, um die frisch konfigurierten SASL-Bibliotheken zu laden, und dann können Sie loslegen. Ist SASL dagegen nicht in der Liste»Compiled with:«enthalten, dann kompilieren Sie sendmail neu, wie in Rezept 1.5 gezeigt. Links Diskussion Es ist nicht notwendig, m4-makros in die sendmail-konfiguration aufzunehmen, um grundlegende AUTH-Mechanismen bekannt zu machen. Es werden nur eine richtig installierte und konfigurierte SASL-Bibliothek und eine Kopie von sendmail, die mit SASL-Unterstützung kompiliert wurde, benötigt. Die SASL-Konfiguration wird durch die SASL-Authentifizierungstechniken bestimmt, die auf Ihrem System installiert sind, sowie durch die Frage, welche dieser Techniken für die Benutzung ausgewählt wurden. Unser Beispiel-Red-Hat-System wurde mit vorinstalliertem SASL geliefert. Abbildung 7-1 zeigt das Fenster System Environment/Libraries des RPM-Management-Programms. Abbildung 7-1: Überwachen der installierten SASL-Bibliotheken in Red Hat Linux Die Abbildung zeigt die drei SASL-Bibliotheksmodule, die mit diesem Linux-System geliefert wurden. cyrus-sasl ist die grundlegende SASL-Bibliothek. cyrus-saslplain ist das SASL-Plug-In, das die Authentifizierungstechniken PLAIN und LOGIN bereitstellt. cyrus-sasl-md ist das Plug-In, das die SASL-Authentifizierungstechniken CRAM-MD5 und DIGEST-MD5 bereitstellt. Von diesen bieten nur CRAM-MD5 und DIGEST-MD5 echte Sicherheit. 270 Kapitel 7: Authentifizierung mit AUTH

289 Rechts Der sendmail-server macht die Techniken DIGEST-MD5 und CRAM-MD5 nur dann bekannt, wenn die Datei /etc/sasldb existiert. sasldb speichert die Namen und Kennwörter, die für die MD5-Authentifizierung verwendet werden. Die Datei wird durch saslpasswd erstellt, sobald dieser Befehl das erste Mal eingesetzt wird, um ein SASL-Kennwort zu erzeugen. Um einen Client mit der sasldb zu authentifizieren, geben Sie den Namen des Clients und das Kennwort in die Datenbank ein. Nehmen Sie einmal an, wir wollen crab mittels MD5 authentifizieren und weisen crab das Kennwort It'sasecret! zu. Der folgende Befehl würde dies erreichen und sowohl CRAM-MD5 als auch DIGEST-MD5 für die sendmail-authentifizierung zur Verfügung stellen: # saslpasswd c u wrotethebook.com crab Password: It'sasecret! Again (for verification): It'sasecret! Das Argument -u definiert den SASL-Bereich (realm). Wenn Sie einen SASL-Zugang für die AUTH-Authentifizierung anlegen, definieren Sie immer explizit den Bereich mit dem Argument -u. Die Bereiche an beiden Endpunkten müssen übereinstimmen, damit die Authentifizierung erfolgreich verläuft. Kontrollieren Sie diese wichtige Information, indem Sie explizit den Bereich definieren, den sowohl der Server als auch der Client nutzen sollen. Im Beispiel ist der Bereich wrotethebook.com, was identisch mit dem lokalen Domainnamen ist. Der String, mit dem der Bereich benannt wird, ist beliebig. Sie können jeden gewünschten Wert wählen. Der Bereich muss zwar kein Domainname sein, es vereinfacht die Dinge jedoch normalerweise. Das Argument -c weist saslpasswd an, einen neuen Zugang anzulegen. Der Zugangsname, im Beispiel crab, wird an das Ende der Kommandozeile gesetzt. saslpasswd fragt dann nach dem Kennwort für den Zugang crab. Dieses Kennwort ist der Shared-Secret- Schlüssel, der für die DIGEST-MD5- oder CRAM-MD5-Authentifizierung benutzt wird. Nach dem Konfigurieren von SASL antwortet der empfangende Host auf den SMTP- Befehl EHLO, indem er die verfügbaren AUTH-Authentifizierungstechniken auflistet. Ein telnet-test zeigt dies: # telnet localhost smtp Trying Connected to localhost. Escape character is '^]'. 220 chef.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 22 Aug :01: ehlo localhost 250-chef.wrotethebook.com Hello IDENT:jlXFenYjCfmga11KxmpDxZFsKgljZB2/@localhost [ ], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH DIGEST-MD5 CRAM-MD5 250-DELIVERBY 7.1 Eine AUTH-Authentifizierung anbieten 271

290 250 HELP QUIT chef.wrotethebook.com closing connection Connection closed by foreign host. Der empfangende Host antwortet auf den EHLO-Befehl mit einer Liste der erweiterten Dienste, die er unterstützt. Die Antwort 250-AUTH zeigt, dass der Host das AUTH-Protokoll unterstützt; die Antwort listet die speziellen Authentifizierungstechniken auf, die von ihm unterstützt werden. Im Beispiel bietet der Server DIGEST-MD5 und CRAM- MD5 an, was bedeutet, dass SASL für CRAM-MD5 und DIGEST-MD5 konfiguriert wurde und sendmail angewiesen wurde, diese Authentifizierungsmethoden bekannt zu machen. Rezept 7.4 beschreibt, wie Sie steuern können, welche AUTH-Techniken von sendmail bekannt gegeben werden. Im Beispiel antwortet das empfangende System mit 250-AUTH. Falls Sie das empfangende System gerade konfiguriert haben und es nicht die Antwort 250-AUTH ausgibt, dann gibt es verschiedene Dinge, die Sie tun können, um das Problem zu entdecken. Überprüfen Sie zuerst das Protokoll, um festzustellen, ob Sicherheitsprobleme aufgezeichnet wurden. sendmail könnte nicht in der Lage gewesen sein, eine erforderliche Datei zu öffnen. Wenn die einfache Protokollierung das Problem nicht zeigt, dann erhöhen Sie LogLevel auf 13 und führen den oben gezeigten Test erneut aus. (Rezept 1.10 bietet ein Beispiel für das Setzen des sendmail-loglevel.) Untersuchen Sie dann das Protokoll noch einmal. sendmail bietet AUTH nur dann an, wenn einige der Authentifizierungsmechanismen, die es auf Grund seiner Konfiguration akzeptieren soll, von SASL aus verfügbar und richtig konfiguriert sind. Suchen Sie mit grep im Protokoll nach dem String mech=. Der Protokolleintrag available mech= listet die Mechanismen auf, von denen sendmail glaubt, dass sie durch SASL angeboten werden. Der Eintrag allowed mech= zeigt die Mechanismen, von denen sendmail glaubt, dass es ihm erlaubt ist, sie anzubieten. sendmail gibt die Antwort 250-AUTH nur aus, wenn diese Listen gemeinsame Einträge aufweisen. Wenn die Liste available mech= einen Mechanismus identifiziert, können Sie die Liste der Mechanismen, die sendmail akzeptiert, ändern, indem Sie die Definition confauth_mechanisms benutzen, die in Rezept 7.6 beschrieben wird. Ist die Liste available mech= leer und enthält das Protokoll entweder eine Fehlermeldung vom SASL mit dem String listmech=0 oder die sendmail-fehlermeldung»auth warning: no mechanisms«, dann ist SASL nicht richtig installiert und konfiguriert. SASL muss mit Authentifizierungsmechanismen installiert sein, wie bereits bei der Erläuterung von Abbildung 7-1 angemerkt wurde. Stellen Sie sicher, dass Sie wirklich alle erforderlichen Bibliotheken herunterladen und richtig installieren. Falls sich zwar SASL nicht beschwert, jedoch sendmail dies tut, sucht sendmail möglicherweise an der falschen Stelle nach den SASL-Bibliotheken. Der Pfad zu den SASL-Bibliotheken kann mit Hilfe der Umgebungsvariablen SASL_PATH gesetzt werden, indem etwa solche Zeilen zur sendmail-konfiguration hinzugefügt werden: LOCAL_CONFIG ESASL_PATH=/usr/lib/sasl Links 272 Kapitel 7: Authentifizierung mit AUTH

291 Rechts Natürlich stellt dieser Pfad nur ein Beispiel dar. Sie müssten einen Pfad verwenden, der an Ihr System angepasst wäre. Durch das Installieren von SASL, das Konfigurieren der sasldb und das Kompilieren von sendmail mit SASL-Unterstützung wird sendmail so eingestellt, dass es nur eingehende AUTH-Verbindungen akzeptiert. Falls das System auch beim Senden von Mail die AUTH-Authentifizierung benutzen soll, muss die Konfiguration aus Rezept 7.2 zu diesem Rezept hinzugefügt werden, um eine vollständige Konfiguration zu erzeugen. Siehe auch Die Rezepte 7.4 und 7.5 bieten vergleichbare Beispiele für AUTH-Konfigurationen. Das Buch sendmail behandelt die AUTH-Konfiguration in Abschnitt Zusätzliche Informationen über die SASL-Konfiguration finden Sie in der Datei sysadmin.html im Verzeichnis mit der SASL-Dokumentation. 7.2 Mit AUTH authentifizieren Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es beim Senden von Mail eine AUTH-Authentifizierung verwendet. Lösung Stellen Sie sicher, dass die SASL-Bibliotheken installiert sind und sendmail mit SASL- Unterstützung kompiliert wurde. Lesen Sie in Rezept 1.5 sowie in der Einführung in dieses Kapitel nach, falls Ihrem System eine dieser notwendigen Komponenten fehlt. Fügen Sie die Authentifizierungs-Credentials des Hosts zur access-datenbank hinzu; dazu verwenden Sie ein AuthInfo:-Tag. Benutzen Sie den Parameter u: zum Definieren der SASL-Autorisierungs-ID, den Parameter I: zum Definieren der SASL-Authentifizierungs-ID, den Parameter P: zum Definieren des gemeinsam genutzten Geheimnisses (Shared Secret), den Parameter R: zum Definieren des SASL-Bereichs und den Parameter M: zum Anfordern eines AUTH-Mechanismus. Da der AuthInfo:-Eintrag ein Kennwort enthält, das im Klartext vorliegt, ist es wichtig, dafür zu sorgen, dass die access-datenbank nur von root gelesen werden kann. Erzeugen Sie eine sendmail-konfiguration, die die Funktion access_db enthält. Hier ist das erforderliche FEATURE-Makro: dnl Use the access database for AUTH credentials FEATURE(`access_db') Erstellen Sie anhand der Anweisungen aus Rezept 1.8 die Datei sendmail.cf neu, kopieren Sie die neue sendmail.cf nach /etc/mail, und starten Sie sendmail neu. 7.2 Mit AUTH authentifizieren 273

292 Diskussion Um sich erfolgreich zu authentifizieren, muss ein Host in der Lage sein, dem empfangenden System gültige Sicherheits-Credentials zu übergeben. Diese Credentials werden auf dem verbindenden Host in der access-datenbank gespeichert; dazu kommt das AuthInfo: -Tag zum Einsatz. Hier ist ein Beispiel für das Hinzufügen eines AuthInfo:-Eintrags zur access-datenbank: # cd /etc/mail # cat >> access AuthInfo:chef.wrotethebook.com "U:crab" "I:crab" "P:It'sasecret!" "R:wrotethebook.com" "M:DIGEST-MD5" Ctrl-D # makemap hash access < access # chmod 600 access access.db Die Komponenten dieses access-datenbankeintrags sind folgende: AuthInfo: Dies ist das access-datenbank-tag. Es kennzeichnet diesen Eintrag dahingehend, dass er Informationen enthält, die für die Authentifizierung mit dem AUTH-Protokoll benutzt werden. chef.wrotethebook.com Unmittelbar auf das Tag folgt der Name des entfernten Systems, das diese Credentials akzeptiert. Die Sicherheits-Credentials in diesem Beispiel werden durch den lokalen Host verwendet, um sich selbst zu authentifizieren, wenn er eine Verbindung zu chef. wrotethebook.com herstellt. Das entfernte System kann auch durch die IP-Adresse identifiziert werden, obwohl üblicherweise der Hostname benutzt wird. Falls dieses Feld leer ist (d. h., wenn kein Host definiert ist), werden die Credentials für die Authentifizierung eingesetzt, wenn eine Verbindung zu einem System hergestellt wird, das AUTH angibt und für das es keinen speziellen AuthInfo:-Eintrag gibt. U:crab Der Parameter U: definiert die SASL-Autorisierungs-ID, die auch als User-ID bezeichnet wird. Die Autorisierungs-ID wird benutzt, um Berechtigungen auf dem entfernten System zu gewähren. Wird für U: kein Wert angegeben, dann verwendet sendmail den Wert, der I: zugewiesen ist, als Standardwert für U:. Weitere Informationen über die SASL-userid finden Sie in der Einführung in dieses Kapitel. I:crab Der Parameter I: definiert die Authentifizierungs-ID. Dabei handelt es sich um den Zugangsnamen, der während der Authentifizierung verwendet wird. Die Authentifizierungs-ID ist der Name, der mit dem Kennwort in der Datei sasldb auf dem empfangenden System verknüpft ist. Wenn für I: kein Wert angegeben ist, dann benutzt sendmail den Wert, der U: zugewiesen wurde, als Standardwert für I:. Da U: und I: aufeinander als Standardwerte verweisen, muss wenigstens einer dieser Werte in dem AuthInfo:-Eintrag enthalten sein. In der Einführung finden Sie weitere Informationen über die SASL-authid. Links 274 Kapitel 7: Authentifizierung mit AUTH

293 Rechts P:It'sasecret! Der Parameter P: definiert das Kennwort. Im Beispiel lautet das Kennwort It' sasecret!. Das Kennwort, das dem Parameter P: zugewiesen ist, muss dem Kennwort entsprechen, das mit der Authentifizierungs-ID in der Datei sasldb auf dem empfangenden Host verknüpft ist. Dieser Wert ist das gemeinsam genutzte Geheimnis, das für die Authentifizierung zum Einsatz kommt. R:wrotethebook.com Der Parameter R: identifiziert den SASL-Bereich. Dieser Wert muss dem SASL-Bereich entsprechen, der der Authentifizierungs-ID in der Datei sasldb auf dem empfangenden Host zugewiesen ist. Rezept 7.1 zeigt, wie der SASL-Bereich mit der Authentifizierungs-ID auf dem empfangenden Host verknüpft wird. Dazu wird das Argument -u des Befehls saslpasswd benutzt. Wenn kein Wert für den Parameter R: angegeben ist, benutzt sendmail den Wert, der durch $j zurückgeliefert wird, als SASL-Bereich. ($j enthält den voll qualifizierten Domainnamen des lokalen Hosts.) M:DIGEST-MD5 Der Parameter M: identifiziert die Authentifizierungstechnik, die benutzt werden wird. Wenn für M: kein Wert angegeben ist, wählt das AUTH-Protokoll die»beste«authentifizierungstechnik, die auf beiden Systemen zur Verfügung steht. Die Authentifizierungswerte, die durch den AuthInfo:-Eintrag auf dem sendenden System definiert sind, müssen mit denen übereinstimmen, die auf dem empfangenden System durch saslpasswd definiert wurden. Stimmt einer dieser Werte nicht überein, dann schlägt die Authentifizierung mit der folgenden Fehlermeldung fehl: authentication failed Senden Sie Mail an den entfernten Host, um die AUTH-Credentials zu testen. Rufen Sie sendmail mit der Option -v auf, um die Protokollinteraktionen zu beobachten. Hier ist ein Beispieltest: $ sendmail -Am -v -t To: craig@chef.wrotethebook.com From: craig@crab.wrotethebook.com Subject: Test Please ignore. Ctrl-D craig@chef.wrotethebook.com... Connecting to chef.wrotethebook.com. via esmtp chef.wrotethebook.com ESMTP Sendmail /8.12.9; Tue, 7 Jan :25: >>> EHLO crab.wrotethebook.com 250-chef.wrotethebook.com Hello IDENT:iE/rw7zeTz25z3Y8g3qLEbb5uGQ8RtyH@crab [ ], pleased to meet you 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-SIZE 250-DSN 250-AUTH DIGEST-MD5 CRAM-MD5 250 HELP >>> AUTH DIGEST-MD5 = 7.2 Mit AUTH authentifizieren 275

294 334 bm9uy2u9imfzcjb6vercswnbyupftvhnwgg2thq5vllpw1kns1zzxnz >>> dxnlcm5hbwu9imnyywlniixyzwfsbt0id3jvdgv0agvib29ryzmu3oti3nzezytg5mgjjzq== 334 cnnwyxv0ad0zyzmymtc5yzhimtqwyzqznwjintgwotzmogzjytq4mg== >>> OK Authenticated >>> MAIL SIZE= Sender ok >>> RCPT Recipient ok >>> DATA 354 Enter mail, end with "." on a line by itself >>> h07ipxt01997 Message accepted for delivery craig@chef.wrotethebook.com... Sent (h07ipxt01997 Message accepted for delivery) Closing connection to chef.wrotethebook.com. >>> QUIT chef.wrotethebook.com closing connection Zusätzlich zur Option -v startet dieser Test sendmail mit -t und -Am. -t weist sendmail an, die Empfängeradresse aus allen To:-, CC:- und Bcc:-Zeilen in der Nachricht zu beziehen. (Im Beispiel haben wir den Empfänger mit einer To:-Zeile in der Nachricht angegeben.) Die ersten fünf Zeilen nach dem sendmail-befehl enthalten unsere Testnachricht, die mit dem Dateiendezeichen Ctrl-D abgeschlossen wird. Die Option -Am weist sendmail an, als MTA mit der sendmail.cf-konfiguration zu laufen. Wenn diese Option nicht angegeben ist, läuft sendmail als Message Submission Program (MSP), benutzt die submit.cf- Konfiguration und zeigt die Interaktion zwischen dem sendmail-befehl des Benutzers und dem lokalen System. Da wir die MTA-Interaktion zwischen unserem System und einem entfernten System beobachten wollen, müssen wir die Option -Am verwenden. 2 Alle Zeilen nach dem Ctrl-D sind sendmail-ausgaben. Ausgabezeilen, die mit >>> beginnen, sind SMTP-Befehle, die vom sendenden System stammen. Zeilen, die mit einem numerischen Antwortcode beginnen, stammen vom empfangenden System. Das lokale System sendet einen EHLO-Befehl. Als Antwort zeigt das entfernte System die Liste der erweiterten Befehle an, die es unterstützt. Einer dieser Befehle teilt dem lokalen Host mit, dass das entfernte System AUTH unterstützt und dass es zwei Authentifizierungstechniken anbietet, DIGEST-MD5 und CRAM-MD5. Der lokale Host sendet einen AUTH-Befehl, der die DIGEST-MD5-Technik zum Authentifizieren der Verbindung anfordert. Die Endpunkte tauschen MD5-Challenges und -Responses aus, und das entfernte System zeigt folgende Meldung an: OK Authenticated Nach dieser Meldung wird die Mail-Auslieferung normal fortgesetzt. Die einzige Wirkung, die der Empfänger möglicherweise verspüren könnte, ist der Zusatz des Wortes»authenticated«zum Received:-Header der Mail, wie unten gezeigt: 2 Ältere Versionen von sendmail benutzen die submit.cf-konfiguration nicht und haben oder brauchen die Kommandozeilenoption -Am nicht. Links 276 Kapitel 7: Authentifizierung mit AUTH

295 Rechts Received: from crab.wrotethebook.com [ ]) (authenticated) by chef.wrotethebook.com (8.12.9/8.12.9) with ESMTP id h07ipxt01997 for Tue, 7 Jan :25: Die Tests zeigen, dass der AuthInfo:-Eintrag in der access-datenbank funktioniert und sendmail mit den korrekten Informationen beliefert, um den lokalen Host am entfernten Host zu authentifizieren. Versionen von sendmail vor sendmail 8.12 können jedoch Authentifizierungsinformationen nicht in der access-datenbank speichern. Auf diesen älteren Systemen werden die AUTH-Sicherheits-Credentials in einer separaten Datei abgelegt. Die Datei muss in der sendmail-m4-konfiguration mit Hilfe der Definition confdef_auth_info identifiziert werden. Beispielsweise teilt die folgende Zeile, wenn sie in der sendmail-konfiguration hinzugefügt wird, sendmail mit, dass die SASL-Credentials in einer Datei namens /etc/mail/default_auth_info gespeichert sind: define(`confdef_auth_info', `/etc/mail/default_auth_info') Die Definition confdef_auth_info ist veraltet und sollte mit sendmail 8.12 oder späteren Versionen von sendmail nicht mehr benutzt werden. Um genau zu sein, wird sie ignoriert, wenn sie zu einer sendmail-8.12-konfiguration hinzugefügt wird, die entweder auch die Funktion access_db oder die Funktion authinfo enthält. 3 Versionen von sendmail vor 8.12 benutzen dagegen die Datei confdef_auth_info und bieten dafür keine Unterstützung des Tags AuthInfo: für die access-datenbank. Falls Sie eine ältere Version von sendmail haben, dann rüsten Sie auf die neueste Version um, wie in Kapitel 1 beschrieben. Sie sollten die veraltete Datei nur benutzen, wenn Sie eine alte Version von sendmail haben, die Sie nicht aktualisieren können. Eine Beispiel-/etc/mail/default_auth _info-datei, angelegt für die oben gezeigte Definition confdef_auth_info, könnte Folgendes enthalten: crab crab It'sasecret! wrotethebook.com DIGEST-MD5 Die erste Zeile definiert die Autorisierungsidentität, die äquivalent zum Wert U: in der access-datenbank ist. Die zweite Zeile definiert die Authentifizierungsidentität, die äquivalent zum Wert I: ist. Die dritte Zeile enthält das Kennwort und entspricht dem Wert P: in der access-datenbank. Die vierte Zeile definiert den SASL-Bereich, das heißt, den access-datenbankwert R:. Die fünfte Zeile legt den Authentifizierungsmechanismus fest, der verwendet werden soll, was äquivalent zum Wert M: in der access-datenbank ist. (Diese fünfte Zeile ist nur bei sendmail-versionen ab 8.12 sinnvoll; frühere Versionen von sendmail ignorieren sie.) Die Datei, auf die durch confdef_auth_info verwiesen wird, 3 Es ist möglich, sendmail 8.12 zu zwingen, die Datei zu verwenden, auf die durch confdef_auth_info verwiesen wird, indem die Datei sendmail.cf bearbeitet und der Regelsatz authinfo gelöscht wird. Das wird allerdings nicht empfohlen. 7.2 Mit AUTH authentifizieren 277

296 enthält nur einen Satz mit Credentials, die für die Authentifizierung an allen entfernten Systemen benutzt werden die access-datenbank erlaubt es Ihnen, unterschiedliche Credentials für jeden entfernten Host zu definieren. Die access-datenbank ist übergeordnet und sollte nach Möglichkeit benutzt werden. Dieses Rezept konfiguriert AUTH für ausgehende Verbindungen. Rezept 7.1 konfiguriert eingehende Verbindungen. Benutzen Sie saslpasswd, wie in Rezept 7.1 beschrieben, um die Kennwörter für Systeme zu verwenden, die sich an Ihrem sendmail-system anmelden. Benutzen Sie Authinfo:-Einträge in der access-datenbank, um das Kennwort zu konfigurieren, das Ihr System einsetzt, wenn es sich an einem externen Host anmeldet. Kombinieren Sie diese beiden Rezepte, wenn Ihr Host sowohl eingehende AUTH-Verbindungen akzeptiert als auch ausgehende AUTH-Verbindungen herstellt. Links Siehe auch Rezept 7.3 zeigt eine alternative Methode, um AUTH-Credentials zu konfigurieren. Lesen Sie Rezept 7.3, bevor Sie dieses Rezept umsetzen. Rezept 1.5 behandelt das Kompilieren von sendmail mit SASL-Unterstützung. Die access-datenbank wird in Kapitel 3 und in Kapitel 6 benutzt und erläutert. Das Buch sendmail behandelt das AuthInfo:-Tag in Abschnitt und die Definition confdef_auth_info in Abschnitt AUTH-Credentials in der Datei authinfo speichern Problem Sicherheitsanforderungen machen es erforderlich, dass Sie die AUTH-Authentifizierungs-Credentials in einer Datei speichern, die von der access-datenbank getrennt ist. Lösung Legen Sie die Datei /etc/mail/authinfo an. Speichern Sie die Authentifizierungs-Credentials des Clients in dieser Datei. Dazu verwenden Sie das gleiche AuthInfo:-Tag wie in der access-datenbank. Stellen Sie sicher, dass die authinfo-textdatei und die Datenbank nur von root lesbar sind. Fügen Sie die authinfo-funktion in die sendmail-konfiguration ein. Folgende Zeilen sollten in die sendmail-konfiguration eingefügt werden: dnl Use the authinfo database for AUTH credentials FEATURE(`authinfo') Erstellen Sie anhand der Anweisungen in Rezept 1.8 die Datei sendmail.cf neu, kopieren Sie die neue sendmail.cf nach /etc/mail, und starten Sie sendmail neu. 278 Kapitel 7: Authentifizierung mit AUTH

297 Rechts Diskussion Eine Alternative zum Definieren der AUTH-Credentials in der access-datenbank besteht darin, die Credentials in einer separaten Datei namens /etc/mail/authinfo zu definieren. Der Hauptgrund für diese Vorgehensweise ist Dateisicherheit. AUTH-Kennwörter werden in der access-datenbank und in der authinfo-datei als Klartext gespeichert. Da die access- Datenbank eine Vielzahl an Informationen enthält, besteht die entfernte Möglichkeit, dass Sie mehreren Benutzern Lesezugriff auf diese Datei gewähren. Falls Sie, aus welchen Gründen auch immer, anderen Benutzern als root einen Lesezugriff auf die access-datenbank zugestehen wollen, dann verschieben Sie die AuthInfo:-Einträge aus der access-datenbank in die authinfo-datei und fügen die Funktion authinfo zur sendmail-konfiguration hinzu. Die Funktion authinfo weist sendmail einfach an, Authentifizierungs-Credentials in der authinfo-datenbank anstatt in der access-datenbank nachzusehen. Hier ist ein Beispiel für das Anlegen einer authinfo-datei: # cd /etc/mail # cat > authinfo AuthInfo:chef.wrotethebook.com "U:crab" "I:crab" "P:It'sasecret!" "R:wrotethebook.com" "M:DIGEST-MD5" Ctrl-D # makemap hash authinfo < authinfo # chmod 600 authinfo authinfo.db Einträge in der authinfo-datenbank sind die Standard-AuthInfo:-Einträge, die in der access-datenbank zum Einsatz kommen. Die Einträge haben das gleiche Format und enthalten die gleichen Informationen. Die Diskussion in Rezept 7.2 präsentiert Einzelheiten zum Format von AuthInfo:-Einträgen. Führen Sie mit der Konfiguration dieses Rezepts den sendmail -Am -v -t-test aus, der in der Diskussion von Rezept 7.2 gezeigt wird. Wieder wird die Meldung OK Authenticated ausgegeben, die anzeigt, dass sendmail den lokalen Host erfolgreich am entfernten System authentifiziert hat, ohne die access-datenbank zu benutzen. Sie können mit einem einfachen sendmail -bt-test nachweisen, dass die access-datenbank nicht zum Einsatz gekommen ist: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /map access AuthInfo:rodent.wrotethebook.com Map named "access" not found > /map authinfo AuthInfo:rodent.wrotethebook.com map_lookup: authinfo (AuthInfo:chef.wrotethebook.com) returns "U:crab" "I:crab" "P: It'sasecret!" "R:wrotethebook.com" "M:DIGEST-MD5" (0) > /quit Dieser Test zeigt, dass die access-datenbank nicht existiert, das System jedoch erfolgreich authentifiziert wurde. Ganz offensichtlich liegt das daran, dass die AuthInfo:-Einträge in der authinfo-datenbank gespeichert sind. Natürlich ist das nur ein Beispiel. Auf einem 7.3 AUTH-Credentials in der Datei authinfo speichern 279

298 echten System haben Sie sowohl die access- als auch die authinfo-datenbank. Die einzigen Gründe, die authinfo-datenbank zu benutzen, sind: Die Authentifizierungsdaten sollen von den anderen Daten getrennt werden, die bereits in der access-datenbank gespeichert sind, außerdem sollen diese Daten gesichert werden, so dass die Klartextkennwörter, die sie enthält, nicht einfach gelesen werden können. Im obigen Beispiel konnten wir die authinfo-datenbank nur deshalb lesen, weil wir den Befehl sendmail -bt als root ausgeführt haben. Dieses Rezept geht davon aus, dass das System die notwendige SASL-Unterstützung aufweist. Ist das bei Ihrem System nicht der Fall, dann suchen Sie in der Einführung nach Informationen darüber, wie Sie an die SASL-Bibliotheken kommen, und lesen Sie Rezept 1.5 um zu erfahren, wie Sie sendmail mit SASL-Unterstützung neu kompilieren, bevor Sie versuchen, dieses Rezept umzusetzen. Links Siehe auch Rezept 7.2 zeigt eine alternative Methode zum Konfigurieren der AUTH-Credentials, die Sie sich anschauen sollten, bevor Sie dieses Rezept umsetzen. Außerdem enthält Rezept 7.2 Informationen über das Format und den Inhalt von AuthInfo:-Einträgen. Rezept 1.5 behandelt das Kompilieren von sendmail mit SASL-Unterstützung, und Kapitel 1 bietet allgemeine Informationen über das Kompilieren von sendmail. Das Buch sendmail behandelt das AuthInfo:-Tag in Abschnitt und die Funktion authinfo in Abschnitt Angekündigte Authentifizierungsmechanismen beschränken Problem Für verschiedene Einsatzzwecke werden mehrere unterschiedliche SASL-Authentifizierungstechniken konfiguriert. Sie wollen steuern, welche Authentifizierungstechniken für die SMTP-AUTH-Authentifizierung bekannt gemacht werden. Lösung Fügen Sie die Definition confauth_mechanisms zur sendmail-konfiguration hinzu. Benutzen Sie die Definition, um nur solche Authentifizierungstechniken aufzulisten, die Sie bekannt machen wollen. Hier ist ein Beispiel für die confauth_mechanisms-definition, die in die sendmail-konfiguration eingefügt werden könnte: dnl Define the acceptable AUTH mechanisms define(`confauth_mechanisms', `DIGEST-MD5 CRAM-MD5') Erstellen Sie die neue sendmail-konfigurationsdatei, kopieren Sie sie nach /etc/mail/ sendmail.cf, und starten Sie sendmail neu, wie in Rezept 1.8 beschrieben. 280 Kapitel 7: Authentifizierung mit AUTH

299 Rechts Diskussion Die Definition confauth_mechanisms setzt die Werte, die der sendmail.cf-option Auth Mechanisms zugewiesen sind. sendmail gibt alle SASL-Authentifizierungstechniken bekannt, die in der Option AuthMechanisms aufgeführt sind, die auf dem lokalen Host konfiguriert wurde und ausgeführt wird. Der AuthMechanisms-Kommentar in einer einfachen sendmail.cf-datei zeigt die vorgegebene Liste der Authentifizierungstechniken, die von sendmail benutzt werden: $ grep AuthMechanisms generic-linux.cf #O AuthMechanisms=EXTERNAL GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5 Standardmäßig kündigt sendmail folgende Techniken an: EXTERNAL, falls ein externer Sicherheitsmechanismus wie TLS konfiguriert und ausgeführt wird. GSSAPI, falls der lokale Host als Kerberos 5-Client betrieben wird. KERBEROS_V4, falls der lokale Host als Kerberos 4-Client betrieben wird. DIGEST-MD5, falls die sasldb-datenbank konfiguriert wurde. CRAM-MD5, falls die sasldb-datenbank konfiguriert wurde. Der empfangende Host gibt die verfügbaren Authentifizierungstechniken bekannt, der verbindende Host jedoch wählt die Technik aus, die zum Einsatz kommt. Darin liegt das Problem. Der verbindende Host könnte nämlich eine Technik auswählen, die Sie wirklich nicht für die SMTP-Authentifizierung benutzen wollen, es sei denn, Sie legen die angekündigten Techniken explizit mit der confauth_mechanisms-definition fest. Zum Beispiel: # telnet rodent smtp Trying Connected to rodent. Escape character is '^]'. 220 rodent.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 22 Aug :01: ehlo chef 250-rodent.wrotethebook.com Hello IDENT:/tNy4XlJuCgfwrxksOjP9e2Hm3dZuOiC@chef [ ], pleased to meet you 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-SIZE 250-DSN 250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 250 HELP quit rodent.wrotethebook.com closing connection Connection closed by foreign host. Dieser telnet-test zeigt, dass rodent.wrotethebook.com Kerberos 5 als Technik angibt, die für die SMTP-Authentifizierung verwendet werden kann. Handelt es sich bei dem verbindenden System um einen Kerberos-5-Client, kann es diese Technik wählen, um sich selbst zu authentifizieren, was gut und schön ist, falls der Administrator von rodent tatsächlich 7.4 Angekündigte Authentifizierungsmechanismen beschränken 281

300 Kerberos 5 für die SMTP-Authentifizierung verwenden möchte. Falls nicht, kann die confauth_mechanisms-definition, die in der Lösung gezeigt wurde, eingesetzt werden, um die Liste der angekündigten Authentifizierungstechniken zu beschränken. Nach dem Installieren dieser confauth_mechanisms-definition auf rodent zeigt diese Maschine folgende Zeile in ihrer EHLO-Antwort: 250-AUTH DIGEST-MD5 CRAM-MD5 Die confauth_mechanisms-definition kann außerdem verwendet werden, um die Liste der angekündigten Authentifizierungstechniken zu vergrößern. Beispielsweise enthält die Standard-SASL-Konfiguration auf einem Red-Hat-Linux-System PLAIN und LOGIN sowie DIGEST-MD5 und CRAM-MD5. Falls der Administrator eines Red-Hat-Systems folgende confauth_mechanisms-definition in die sendmail-konfiguration setzen würde: define(`confauth_mechanisms', `DIGEST-MD5 CRAM-MD5 PLAIN LOGIN') würde der Server folgende Ankündigung in seiner EHLO-Antwort ausgeben: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN LOGIN In den meisten Fällen ist das nicht so günstig. PLAIN und LOGIN sind keine sicheren Authentifizierungstechniken und sollten nicht mit sendmail über eine ungesicherte Verbindung benutzt werden. PLAIN sendet Klartextkennwörter über das Netzwerk wo sie leicht abgehört werden können. LOGIN implementiert nicht-standardisierte, undokumentierte und nicht unterstützte Authentifizierungstechniken, die von älteren, kaputten SMTP-Clients benutzt werden, und sendet Kennwörter ebenfalls im Klartext. Diese Techniken dürfen nur eingesetzt werden, wenn die Verbindung selbst verschlüsselt ist, um das Ausspähen von Kennwörtern zu verhindern. Links Siehe auch Die Rezepte 7.1 und 7.5 zeigen vergleichbare Beispiele für AUTH-Konfigurationen. Das Buch sendmail behandelt die AUTH-Konfiguration in Abschnitt 10.9 und die confauth _MECHANISMS-Definition in Abschnitt Mit AUTH die Weitervermittlung erlauben Problem Sie wurden gebeten, einen Mail Relay Host zu konfigurieren, der nicht auf IP-Adressen oder Hostnamen zurückgreifen kann, um Relaying-Berechtigungen zu gewähren. Lösung Kompilieren Sie sendmail mit AUTH-Unterstützung, wie in Rezept 1.5 beschrieben. Installieren und konfigurieren Sie SASL, wie in der Kapiteleinführung und in Rezept 7.1 beschrieben. 282 Kapitel 7: Authentifizierung mit AUTH

301 Rechts Fügen Sie das Makro TRUST_AUTH_MECH zur sendmail-konfiguration hinzu, um die Authentifizierungsmechanismen aufzulisten, mit denen eine Weitervermittlung (Relaying) autorisiert werden soll. Hier ist ein Beispiel-TRUST_AUTH_MECH-Makro, das in die sendmail- Konfiguration eingefügt werden könnte: dnl List mechanisms trusted to authorize relaying TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5') Erstellen Sie die neue sendmail-konfigurationsdatei, kopieren Sie sie nach /etc/mail/ sendmail.cf, und starten Sie sendmail mit der neuen Konfiguration. Halten Sie sich an das Beispiel aus Rezept 1.8. Diskussion Die AUTH-Authentifizierung setzt eine Vielzahl von Makros, die von sendmail untersucht und in sendmail.cf-regelsätzen verwendet werden können. (Verschiedene dieser Makros werden in der Einführung besprochen.) Allerdings gewährt die AUTH-Authentifizierung keine besonderen Berechtigungen. Die Mail eines authentifizierten Hosts, dem mit traditionellen Methoden keine Vermittlungsberechtigungen gewährt wurden, wird von sendmail abgewiesen, falls er versucht, Mail zu vermitteln. Der folgende Auszug aus einem SMTP-Austausch zeigt das: OK Authenticated >>> MAIL SIZE= Sender ok >>> RCPT Relaying denied Die Antwort 235 zeigt, dass der verbindende Host sich erfolgreich authentifiziert hat. Die Antwort 550 zeigt jedoch, dass dem Host ungeachtet seiner Authentifizierung keine Relaying-Berechtigungen gewährt werden. Verwenden Sie das Makro TRUST_AUTH_MECH, um die Weitervermittlung durch AUTHauthentifizierte Clients zu erlauben. Das Makro TRUST_AUTH_MECH fügt die Klasse $={Trust AuthMech} in die Datei sendmail.cf ein und definiert die Werte für diese Klasse. Das TRUST _AUTH_MECH-Beispiel, das in der Lösung gezeigt wurde, fügt die folgende Zeile in die Datei sendmail.cf ein: C{TrustAuthMech}DIGEST-MD5 CRAM-MD5 Die Klasse $={TrustAuthMech} wird im Regelsatz Rcpt_ok verwendet, um die Weitervermittlung zu autorisieren. Dieser Test wird zu der Standardgruppe der Relaying-Tests hinzugefügt. Einem Host, dem auf der Grundlage seiner IP-Adresse oder seines Hostnamens Relaying-Berechtigungen gewährt werden, ist es auch dann erlaubt, Mail zu vermitteln, wenn er sich nicht durch AUTH authentifiziert hat. Einem Host, dem das Relaying normalerweise verboten werden würde, ist es erlaubt, wenn er sich durch AUTH mit einer der Techniken authentifiziert hat, die in der Klasse $={TrustAuthMech} aufgeführt sind. 7.5 Mit AUTH die Weitervermittlung erlauben 283

302 Der Fehler»Relaying denied«, der am Anfang dieser Diskussion gezeigt wurde, trat auf, als chef versuchte, Mail, die an crab adressiert war, durch rodent zu vermitteln. rodent ist nicht dafür konfiguriert worden, das Relaying von externen Clients zu erlauben. Nachdem das Makro TRUST_AUTH_MECH zur Konfiguration auf rodent hinzugefügt worden war, erzeugte Mail, die von chef an crab gesandt wurde und durch rodent ging, ein anderes Ergebnis, wie dieser Test beweist: # sendmail -Cauth.cf -v -t To: craig@crab.wrotethebook.com From: craig@chef.wrotethebook.com Subject: Relay test with auth Please ignore. Crtl-D craig@crab.wrotethebook.com... Connecting to rodent.wrotethebook.com. via relay rodent.wrotethebook.com ESMTP Sendmail /8.12.9; Wed, 8 Jan :14: >>> EHLO chef.wrotethebook.com 250-rodent.wrotethebook.com Hello IDENT:ntwzejGL8kWjSvERN8B101kmvotCXzx9@chef [ ], pleased to meet you 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-SIZE 250-DSN 250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 250 HELP >>> AUTH DIGEST-MD5 = 334 bm9uy2u9imdscxzhvjvxykpvdjjvu3fgwnr2uxjtr2hfhtpw1kns1zzxnz >>> dxnlcm5hbwu9imnozwyilhjlywxtpsj3cm90zxrozwjvb2ywmwzdixm2qyyme2mtvmzjy5 334 cnnwyxv0ad0znzg3zgi3n2e0m2yyyzhhmddkzgriyjg5n2njndkxoq== >>> OK Authenticated >>> MAIL From:<craig@chef.wrotethebook.com> SIZE=96 AUTH=craig@chef.wrotethebook.com <craig@chef.wrotethebook.com>... Sender ok >>> RCPT To:<craig@crab.wrotethebook.com> <craig@crab.wrotethebook.com>... Recipient ok >>> DATA 354 Enter mail, end with "." on a line by itself >>> h090ezh01410 Message accepted for delivery craig@crab.wrotethebook.com... Sent (h090ezh01410 Message accepted for delivery) Closing connection to rodent.wrotethebook.com. >>> QUIT rodent.wrotethebook.com closing connection Für diesen Test wurde auf chef eine besondere AUTH-Konfiguration angelegt, die rodent als SMART_HOST-Relay definierte. Ohne diese besondere Konfiguration würde chef die Mail einfach direkt an crab ausliefern wir wollen jedoch die Vermittlung durch rodent testen. In diesem Fall wird chef mit Hilfe der DIGEST-MD5-Technik authentifiziert. Diese Technik wird in der Klasse $={TrustedAuthMech} auf rodent aufgeführt. Deshalb akzeptiert rodent Mail von chef zur Weitervermittlung. Links 284 Kapitel 7: Authentifizierung mit AUTH

303 Rechts Siehe auch Die Rezepte 7.1 und 7.4 bieten zusätzliche AUTH-Konfigurationsbeispiele. Wie die Weitervermittlung durch die traditionellen Methoden von IP-Adresse und Hostname gesteuert wird, wird in Kapitel 3 behandelt, und die SMART_HOST-Definition wird in Rezept 3.2 besprochen. Das Buch sendmail behandelt die AUTH-Konfiguration in Abschnitt 10.9 und das TRUST_AUTH_MECH-Makro in Abschnitt Den AUTH=-Parameter steuern Problem Da einige fehlerhafte SMTP-Implementierungen den AUTH=-Parameter als Syntaxfehler betrachten, haben Sie beschlossen, sendmail so zu konfigurieren, dass Sie den AUTH=- Parameter zur MAIL From:-Zeile hinzufügen, wenn die Authentifizierung erfolgreich verläuft. Lösung Falls Sie diese Schritte noch nicht erledigt haben, dann kompilieren Sie sendmail mit AUTH-Unterstützung, wie in Rezept 1.5 beschrieben, und installieren und konfigurieren SASL, wie in der Kapiteleinführung und in Rezept 7.1 dargelegt. Erzeugen Sie als Nächstes die AUTH-Credentials für ausgehende Verbindungen, wobei Sie eine der Techniken benutzen, die in Rezept 7.2 oder 7.3 beschrieben werden. Fügen Sie eine confauth_options-definition mit gesetztem Flag A zur sendmail-konfiguration hinzu. Die erforderliche Definition lautet: dnl Send AUTH= only when authenticated define(`confauth_options', `A') Erzeugen und installieren Sie die neue sendmail.cf-datei, und starten Sie sendmail neu, wie in Rezept 1.8 gezeigt. Diskussion Benutzen Sie die Option A der Definition confauth_options, um zu verhindern, dass sendmail den AUTH=-Parameter zur Umschlagabsenderadresse hinzufügt, wenn der lokale Host nicht authentifiziert wurde. sendmail sendet keinen AUTH=-Parameter an ein entferntes System, wenn dieses System AUTH nicht anbietet. Allerdings fügt ein sendmail-system, das laut seiner Konfiguration AUTH unterstützt, standardmäßig den Parameter AUTH= an jede Mail-Nachricht an, die an ein System geschickt wird, das AUTH anbietet, selbst wenn die Authentifizierung fehlschlägt, wie dieser Auszug aus einem tatsächlichen SMTP-Austausch zeigt: 7.6 Den AUTH=-Parameter steuern 285

304 authentication failed >>> MAIL SIZE= Sender ok Um genau zu sein, fügt sendmail den Parameter AUTH= der Zeile MAIL From: auch dann hinzu, wenn gar keine Authentifizierung versucht wurde. Wenn der entfernte Host AUTH anbietet, dann sendet ein sendmail-host, der für AUTH konfiguriert wurde, immer den AUTH=-Parameter. Im folgenden Test bietet rodent AUTH-Mechanismen an, die auf chef nicht konfiguriert wurden. Daher versucht chef keine Authentifizierung; weil es aber für andere AUTH-Mechanismen konfiguriert wurde, sendet chef den AUTH=-Parameter: # sendmail -Am -v -t To: craig@rodent.wrotethebook.com From: craig@chef.wrotethebook.com Subject: Test yet again Ctrl-D craig@rodent.wrotethebook.com... Connecting to rodent.wrotethebook.com. via esmtp rodent.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 10 Jan :52: >>> EHLO chef.wrotethebook.com 250-rodent.wrotethebook.com Hello IDENT:UZFl3RUw1vRsWKcZqcKAEudx69KnFn37@chef [ ], pleased to meet you 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-SIZE 250-DSN 250-AUTH DIGEST-MD5 CRAM-MD5 250 HELP >>> MAIL From:<craig@chef.wrotethebook.com> SIZE=92 AUTH=craig@chef.wrotethebook.com <craig@chef.wrotethebook.com>... Sender ok >>> RCPT To:<craig@rodent.wrotethebook.com> <craig@rodent.wrotethebook.com>... Recipient ok >>> DATA 354 Enter mail, end with "." on a line by itself >>> h0aiqw Message accepted for delivery craig@rodent.wrotethebook.com... Sent (h0aiqw Message accepted for delivery) Closing connection to rodent.wrotethebook.com. >>> QUIT rodent.wrotethebook.com closing connection Durch das Setzen der Option A mit der confauth_options-definition wird dieses Verhalten geändert: sendmail fügt den Parameter AUTH= nur hinzu, wenn die Authentifizierung erfolgreich verläuft. Dieser Auszug zeigt, dass AUTH= nicht hinzugefügt wird, wenn die Authentifizierung fehlschlägt: authentication failed >>> MAIL From:<craig@chef.wrotethebook.com> SIZE= <craig@chef.wrotethebook.com>... Sender ok Ist die Authentifizierung dagegen erfolgreich, dann wird der Parameter AUTH= auch an die MAIL From:-Zeile angehängt, wie dieser Auszug beweist: Links 286 Kapitel 7: Authentifizierung mit AUTH

305 Rechts OK Authenticated >>> MAIL SIZE= Sender ok Der Parameter AUTH= wird am nächsten Mail Relay bekannt gemacht, wenn der empfangende Host dem Parameter AUTH= vertraut, den er vom verbindenden Host empfangen hat. sendmail vertraut diesem Parameter nur, wenn der verbindende Host authentifiziert wurde. Dem Regelsatz trust_auth wird der Parameter AUTH= übergeben; er stellt dann fest, ob diesem Wert vertraut werden kann. Sie können die Art und Weise verändern, wie der Server den Parameter AUTH= verarbeitet, indem Sie Ihren eigenen Local_trust_auth- Regelsatz schreiben. Siehe auch Die Rezepte 7.2 und 7.3 bieten zusätzliche Informationen über das Konfigurieren von AUTH. Das Buch sendmail behandelt den Parameter AUTH= in Abschnitt und die Definition confauth_options in Abschnitt Doppelte Verschlüsselung vermeiden Problem Sie haben ein System, das sowohl für externe Verschlüsselung als auch für SASL-Sicherheit konfiguriert wurde. Wenn bei solchen Gelegenheiten eine starke externe Verschlüsselung zum Einsatz kommt, wollen Sie es vermeiden, eine AUTH-Verschlüsselung einzusetzen. Lösung Erzeugen Sie eine sendmail-konfiguration, die die maximale Stärke der Verschlüsselung mit der Definition confauth_max_bits setzt. Legen Sie die maximale Anzahl der Verschlüsselungsbits auf einen Wert, der niedriger ist als die Anzahl der Bits, die durch die externe Verschlüsselung benutzt werden; wenn Sie beispielsweise diese Definition auf 128 setzen, wird die AUTH-Verschlüsselung deaktiviert, wenn die Transportschicht bereits mit TLS verschlüsselt ist. Werden die folgenden Zeilen zur sendmail-konfiguration hinzugefügt, dann wird die AUTH-Verschlüsselung ausgeschaltet, wenn eine andere Verschlüsselung zum Einsatz kommt: dnl Disable double encryption define(`confauth_max_bits', `128') Erstellen und installieren Sie die sendmail.cf, und starten Sie dann sendmail neu, wie in Rezept 1.8 gezeigt. 7.7 Doppelte Verschlüsselung vermeiden 287

306 Diskussion Dieses Rezept geht davon aus, dass AUTH so konfiguriert ist, wie in den Rezepten 7.1 und 7.2 beschrieben, und dass STARTTLS so konfiguriert ist, wie in Kapitel 8 beschrieben. Die Definition confauth_max_bits erzeugt die Option AuthMaxBits in der Datei sendmail.cf und weist dieser Option einen Wert zu. Zum Beispiel: O AuthMaxBits=128 Diese Option teilt sendmail mit, dass die SASL-Verschlüsselung, die einer bereits existierenden Verschlüsselung hinzugefügt wird, eine 128-Bit-Verschlüsselung nicht überschreiten soll. Da jede existierende externe Verschlüsselung wenigstens eine 128-Bit- Verschlüsselung bietet, schaltet diese Option die SASL-Verschlüsselung aus, wenn die Verbindung bereits verschlüsselt wird. Kapitel 8 beschreibt, wie TLS benutzt wird, um den Mail-Transport zu verschlüsseln. Wenn die Verbindung durch einen externen Mechanismus wie etwa TLS verschlüsselt wird, besteht keine Notwendigkeit, mit SASL eine zweite Verschlüsselungsebene einzufügen. Es ist auch möglich, mit Hilfe der Definition confauth_mechanisms EXTERNAL auf der Liste der angebotenen Authentifizierungstechniken anzugeben. Dadurch wird vermieden, für eine Verbindung, die bereits durch ein externes Protokoll wie TLS authentifiziert wurde, eine zweite Ebene unnötiger Authentifizierungen anzugeben. Links Siehe auch Rezept 7.4 behandelt die Definition confauth_mechanisms. Das Buch sendmail behandelt confauth_max_bits in Abschnitt Authentifizierung verlangen Problem Sie haben ein internes Mail-System, das der Außenwelt nicht bekannt gemacht wird und der Außenwelt auch niemals Dienste anbietet. Sie wurden gebeten, dieses System so zu konfigurieren, dass es von verbindenden Hosts immer eine starke Authentifizierung verlangt. Lösung Erzeugen Sie eine einfache AUTH-Konfiguration, wie in den Rezepten 7.1 und 7.2 beschrieben. 288 Kapitel 7: Authentifizierung mit AUTH

307 Rechts Fügen Sie der sendmail-konfiguration ein DAEMON_OPTIONS-Makro hinzu, das den Modifikator M=a angibt, der eine AUTH-Authentifizierung verlangt. Durch die folgenden Zeilen wird AUTH für jede Verbindung am SMTP-Port notwendig: dnl Require AUTH for all incoming SMTP connections DAEMON_OPTIONS(`Name=MTA, M=a') Erstellen Sie die Datei sendmail.cf, kopieren Sie sie nach /etc/mail/sendmail.cf, und starten Sie sendmail neu. Halten Sie sich dabei an die Anweisungen aus Rezept 1.8. Diskussion Verwenden Sie das Makro DAEMON_OPTIONS auf Systemen, die sendmail 8.12 ausführen. Vor sendmail 8.12 wurden Daemon-Portoptionen mit Hilfe der Definition confdaemon _OPTIONS gesetzt. confdaemon_options ist nicht mehr gültig. Wenn Sie versuchen, diese Definition bei einer aktuellen Version von sendmail zu benutzen, erhalten Sie folgende Fehlermeldung beim Erstellen: WARNING: confdaemon_options is no longer valid. Use DAEMON_OPTIONS( ); see cf/readme. Falls Sie eine ältere Version von sendmail haben, die die Definition confdaemon_options benutzt, empfehlen wir die Aktualisierung auf eine neuere Version von sendmail. Das Makro DAEMON_OPTIONS bietet mehr Konfigurationsmöglichkeiten. Das Makro DAEMON_OPTIONS fügt Werte zu einer sendmail.cf-daemonportoptions-anweisung hinzu oder bindet eine neue DaemonPortOptions-Anweisung in die Datei sendmail.cf ein. Eine einfache sendmail.cf-konfiguration enthält zwei DaemonPortOptions-Anweisungen eine für den MSA (Message Submission Agent) und eine für den MTA (Mail Transfer Agent). Ein grep der Datei generic-linux.cf zeigt das: # grep DaemonPortOptions generic-linux.cf O DaemonPortOptions=Name=MTA O DaemonPortOptions=Port=587, Name=MSA, M=E Das Makro DAEMON_OPTIONS in der Lösung fügt der MTA-Anweisung DaemonPortOptions einen Modifikator hinzu, wodurch folgender sendmail.cf-befehl erzeugt wird: O DaemonPortOptions=Name=MTA, M=a Die Tatsache, dass der MTA modifiziert wird, wird durch den Parameter Name=MTA verdeutlicht. Doch selbst wenn dieser Parameter nicht angegeben worden wäre, wäre der MTA verändert worden, weil der Wert Port standardmäßig smtp lautet. Das ist der Port, der durch den MTA benutzt wird. Um den Modifikator a zur MSA-Konfiguration hinzuzufügen, muss die vorgegebene MSA-Konfiguration mit der Funktion no_default_msa entfernt werden und das Makro DAEMON_OPTIONS muss explizit auf den MSA verweisen. Zum Beispiel: FEATURE(`no_default_msa') DAEMON_OPTIONS(`Port=587, Name=MSA, M=Ea') 7.8 Authentifizierung verlangen 289

308 Die schlüssel=wert-paare der Anweisung DaemonPortOptions wählen optionale Charakteristika für die Ports des sendmail-daemons aus. schlüssel kann einen der folgenden Werte annehmen: Name Ein beliebiger interner Name, der benutzt wird, um den Daemon zu identifizieren. Zwei Werte sind vordefiniert: MSA für den Message Submission Agent und MTA für den Message Transmission Agent. Port Die Portnummer oder der Name eines wohlbekannten Ports, der in der Datei /etc/ services definiert ist. Dieser lautet standardmäßig smtp, das ist der Name des vom MTA benutzten Ports 25. Der Standardport für einen MSA ist 587. Addr Die IP-Adresse der Netzwerkschnittstelle, an der der Daemon auf -Verbindungen warten soll. Standardmäßig lautet dieser Wert INADDR_ANY, was auf alle Netzwerkschnittstellen passt, die an diesem System installiert sind. Das bedeutet, dass an jeder Netzwerkschnittstelle akzeptiert wird. Wenn eine Schnittstelle mit dem Schlüssel Addr identifiziert wird, dann wird Mail nur an dieser Schnittstelle akzeptiert; das kann allerdings unbeabsichtigte Folgen haben. Wenn Sie beispielsweise Addr= zu den MTA-DaemonPortOptions auf dem Host hinzufügen, bedeutet dies, dass Mail vom lokalen Host selbst abgelehnt wird, weil die Schnittstelle localhost ist und nicht Family Die Adressfamilie, die entweder inet oder inet6 ist. Standard ist inet. Listen Die maximale Anzahl der anhängigen Verbindungen in der Warteschlange. Der Vorgabewert ist betriebssystemabhängig; auf unserem Beispiel-Linux-System liegt er standardmäßig bei 10. SndBufSize Die Größe des TCP-Sendepuffers in Bytes. RcvBufSize Die Größe des TCP-Empfangspuffers in Bytes. M Der Modifikator, ein Flag, das das optionale Verhalten für die Schnittstelle oder den Port auswählt. Die Modifikatorflags sind: a b Veranlasst sendmail, eine Authentifizierung für jede eingehende Verbindung anzufordern. Weist sendmail an, sich beim Senden ausgehender Mail an die gleiche Schnittstelle zu halten, durch die eingehende Mail empfangen wurde. Links 290 Kapitel 7: Authentifizierung mit AUTH

309 Rechts c f u A C E O S Aktiviert die Hostnamenkanonisierung. Verlangt voll qualifizierte Hostnamen bei -Adressen. Erlaubt unqualifizierte Absenderadressen, was bedeutet, dass der Hostnamenanteil der Absenderadresse nicht erforderlich ist. Deaktiviert die AUTH-Authentifizierung für diesen Port. Deaktiviert die Hostnamenkanonisierung. Deaktiviert den SMTP-Befehl ETRN. Markiert den Socket als optional. Normalerweise lauscht sendmail für jede DaemonPortOptions-Anweisung, die in der Datei sendmail.cf definiert wurde, an einem neuen Socket. Wenn O angegeben wurde, wird der Socket ignoriert, falls er nicht korrekt geöffnet werden konnte. Erlaubt kein STARTTLS an dieser Schnittstelle. Kapitel 8 behandelt STARTTLS. Standardmäßig bietet ein System, das so konfiguriert wurde, wie in Rezept 7.1 beschrieben, eine Authentifizierung, es verlangt sie jedoch nicht. Ein einfacher telnet-test eines Systems, das die einfache AUTH-Konfiguration aus Rezept 7.1 ausführt, zeigt das: # telnet localhost smtp Trying Connected to localhost. Escape character is '^]'. 220 chef.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 22 Aug :01: ehlo localhost 250-chef.wrotethebook.com Hello IDENT:QQqOd8VZzdwOiABzBr3HvETLtxcEaPg1@localhost [ ], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH DIGEST-MD5 CRAM-MD5 250-DELIVERBY 250 HELP MAIL From:<craig@chef.wrotethebook.com> <craig@chef.wrotethebook.com>... Sender ok RCPT TO:<craig@rodent.wrotethebook.com> 7.8 Authentifizierung verlangen 291

310 Recipient ok QUIT chef.wrotethebook.com closing connection Connection closed by foreign host. Die vorgegebene Konfiguration bietet das AUTH-Protokoll an, erlaubt es jedoch der Mail- Verbindung weiterzubestehen, auch wenn der verbindende Host sich selbst nicht authentifiziert. Das ist nicht nur der Standardfall, es ist außerdem auch eine Anforderung des AUTH- Standards. Wenn ein Mail-System der Außenwelt bekannt gemacht wird, kann es keine Authentifizierung verlangen. Vor allem Mail Exchangern ist dies verboten. Der Grund dafür ist einfach. MX-Records geben bekannt, dass der Mail Exchanger für die Mail-Auslieferung zur Verfügung steht. Er kann dann die Mail nicht ablehnen, für die es sich anbietet. Nur Mail-Hosts, die nicht der Außenwelt bekannt gemacht werden, dürfen eine Authentifizierung verlangen. Ein Beispiel für ein solches System könnte ein Mail Relay in einem Unternehmen sein, das sich hinter einer Firewall befindet. Dieses Rezept könnte an einem solchen System eingesetzt werden. Ein erneuter telnet-test, der ausgeführt wurde, nachdem der Modifikator DaemonPort Options installiert worden war, zeigt das folgende Ergebnis: # telnet localhost smtp Trying Connected to localhost. Escape character is '^]'. 220 chef.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 22 Aug :01: ehlo localhost 250-chef.wrotethebook.com Hello IDENT:DXXGyJYPz7FDqe1dqRJVCgvxLAaoFgWP@localhost [ ], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH DIGEST-MD5 CRAM-MD5 250-DELIVERBY 250 HELP MAIL From:<craig@chef.wrotethebook.com> Authentication required QUIT chef.wrotethebook.com closing connection Connection closed by foreign host. In diesem Fall wird der Fehler»Authentication required«ausgegeben, wenn der verbindende Host versucht, einen Mail-Dialog ohne Authentifizierung zu starten. Die Beschränkung des Makros DAEMON_OPTIONS besteht darin, dass es auf alle eingehenden Verbindungen angewandt wird. Lesen Sie Rezept 7.9, falls Ihre Konfiguration größere Flexibilität verlangt. Links 292 Kapitel 7: Authentifizierung mit AUTH

311 Rechts Siehe auch Die Rezepte 7.1 und 7.2 behandeln die grundlegende AUTH-Konfiguration. Das Buch sendmail behandelt das Makro DAEMON_OPTIONS in Abschnitt Im Buch TCP/IP Netzwerk-Administration, dritte Auflage, von Craig Hunt (O Reilly) finden Sie Informationen über wohlbekannte Ports und die Datei /etc/services. 7.9 Selektiv eine Authentifizierung verlangen Problem Sie haben einen Mail-Host, der so konfiguriert werden kann, dass er von jedem verbindenden Host eine starke Authentifizierung verlangt. Sie wurden jedoch gebeten, das System so zu konfigurieren, dass es von bestimmten verbindenden Hosts immer eine starke Authentifizierung verlangt. Lösung Stellen Sie sicher, dass die grundlegenden AUTH-Konfigurationsanforderungen aus Rezept 7.1 befolgt werden. Legen Sie Srv_Features:-access-Datenbankeinträge für alle Hosts an, von denen eine Authentifizierung mittels AUTH verlangt werden soll. Das Schlüsselfeld der einzelnen Einträge beginnt mit dem Tag Srv_Features:, dem der Domainname, der Hostname oder die IP-Adresse folgt, die das System identifiziert, das sich selbst authentifizieren soll. Der Rückgabewert jedes Eintrags ist der Buchstabe l. Fügen Sie die Funktion access_db zur sendmail-konfiguration hinzu. Hier ist das erforderliche FEATURE-Makro: dnl Enable the access database FEATURE(`access_db') Erstellen Sie mit Hilfe der Anweisungen aus Rezept 1.8 die Datei sendmail.cf neu, kopieren Sie die neue sendmail.cf nach /etc/mail, und starten Sie sendmail neu. Diskussion Srv_Features:-access-Datenbankeinträge erlauben es Ihnen, die erweiterten Funktionen zu steuern, die dem verbindenden Host auf der Grundlage des Domainnamens oder der IP-Adresse angeboten werden. Die Syntax des Srv_Features:-Eintrags lautet: Srv_Features:name flag Srv_Features: ist das erforderliche Tag. name ist der Name des verbindenden Hosts, der durch einen vollständigen oder teilweisen Domainnamen oder eine vollständige oder teilweise IP-Adresse definiert werden kann. Ein vollständiger Domainname bzw. eine vollstän- 7.9 Selektiv eine Authentifizierung verlangen 293

312 dige IP-Adresse entspricht einem einzelnen Host. Ein teilweiser Domainname entspricht allen Hosts in dieser Domain, und eine teilweise IP-Adresse entspricht allen Hosts in dem angegebenen Netzwerk. Wenn das name-feld leer ist, gilt der Eintrag für alle eingehenden Mail-Verbindungen, die keinen spezielleren Srv_Features:-Treffer haben. Der Vorrang der Treffer geht vom längsten (dem speziellsten) zum kürzesten (dem am wenigsten speziellen) Treffer. Das flag-feld ist eine Liste eines oder mehrerer Flags, die aus jeweils einem einzigen Buchstaben bestehen und anzeigen, ob für den angegebenen verbindenden Host ein erweiterter Dienst aktiviert oder deaktiviert werden soll. Wenn das Flag-Feld mehr als ein Flag enthält, dann werden die einzelnen Flags durch Whitespace getrennt. Ein Kleinbuchstabe im flag-feld aktiviert eine SMTP-Erweiterung, ein Großbuchstabe deaktiviert die Erweiterung. Alle Flags mit Ausnahme von t gibt es in Paaren von Groß- und Kleinbuchstaben. Tabelle 7-2 zeigt die Buchstaben, die SMTP-Erweiterungen aktivieren und deaktivieren. Links Tabelle 7-2: Srv_Features:-Flags Ja Nein Beschreibung a A Bietet AUTH an. b B Bietet den Befehl VERB an. d D Bietet die DSN-Erweiterung an. e E Bietet den Befehl ETRN an. l L Verlangt eine AUTH-Authentifizierung vom verbindenden Host. p P Bietet PIPELINING an. s S Bietet STARTTLS an. t Stellt die Verbindung mit einem temporären Fehler zurück. v V Fordert ein Client-Zertifikat vom verbindenden Host an. x X Bietet den Befehl EXPN an. Die Flags a/a und l/l sind Flags, die direkt mit der AUTH-Protokollerweiterung zu tun haben. Im Speziellen benutzt dieses Rezept das Flag l, um eine Authentifizierung selektiv anzufordern. Nehmen Sie beispielsweise an, Sie wollen eine AUTH-Authentifizierung von jedem Host verlangen, der sich von der Domain dialin.wrotethebook.com aus verbindet. Dazu könnten Sie den folgenden Eintrag in die access-datenbank aufnehmen: Srv_Features:dialin.wrotethebook.com l Jetzt wird ein Verbindungsversuch von einem Host aus dialin.wrotethebook.com abgewiesen, wenn dieser Host sich nicht authentifiziert. Allen anderen Hosts dagegen ist es weiterhin erlaubt, sich ohne Authentifizierung zu verbinden, da es keine weiteren Srv_Features:-Einträge in der access-datenbank gibt, die mit der AUTH-Authentifizierung zu tun haben. AUTH wird weiterhin allen Hosts angeboten; und jeder Host, der sich dafür entscheidet, darf sich authentifizieren, da es sich hierbei um das vorgegebene 294 Kapitel 7: Authentifizierung mit AUTH

313 Rechts sendmail-verhalten handelt. Fehlt ein anwendbarer Srv_Features:-Eintrag, kommt das vorgegebene sendmail-verhalten zum Tragen. Das ist genau das, was wir für dieses Rezept haben wollen, lässt sich aber in der access-datenbank deutlicher dokumentieren, indem dort zwei Einträge anstelle des einen gezeigten Eintrags eingesetzt werden: Srv_Features:dialin.wrotethebook.com Srv_Features: l L In diesem Fall wird die Authentifizierung von den Hosts in der Domain dialin. wrotethebook.com weiterhin verlangt. Dieses Mal jedoch zeigen wir explizit, dass wir von anderen keine Authentifizierung haben wollen, indem wir einen Srv_Features:-Eintrag mit einem leeren Namensfeld und dem Flag L benutzen. Diese Konfiguration könnte noch einen Schritt weiter geführt werden. Ein Flag A im zweiten Srv_Features:-Eintrag würde verhindern, dass sendmail AUTH anderen Hosts als denen in der Domain dialin.wrotethebook.com anbietet. Hier ist diese Variante: Srv_Features:dialin.wrotethebook.com Srv_Features: l L A In diesem Fall müssen sich Hosts außerhalb von dialin.wrotethebook.com nicht authentifizieren und erhalten nicht einmal die Möglichkeit dazu. Siehe auch Rezept 7.1 beschreibt die grundlegende Konfiguration, die erledigt werden muss, bevor dieses Rezept umgesetzt werden kann. Das Buch sendmail behandelt den Eintrag Srv_Features: in Abschnitt Selektiv eine Authentifizierung verlangen 295

314 FirstLeft. Kapitel 8 KAPITEL 8 Den Mail-Transport sichern 8.0 Einführung Kapitel 7 enthält Rezepte, die die SMTP-Erweiterung AUTH benutzen, um den Endpunkten in einem Mail-Austausch eine starke Authentifizierung zu bieten. In diesem Kapitel benutzen die Rezepte die SMTP-Erweiterung STARTTLS sowohl für eine starke Authentifizierung als auch für die Verschlüsselung. Verschlüsselung ist zwar einer der größten Vorteile der SMTP-Erweiterung STARTTLS, es ist jedoch wichtig, sich zu merken, dass es sich nicht um eine Ende-zu-Ende-Verschlüsselung handelt. Mail kann mehrere Stationen (»Hops«) durchlaufen, bevor sie ausgeliefert wird. Manche der durchlaufenen Stationen benutzen möglicherweise kein STARTTLS. Außerdem wird die Mail-Nachricht sowohl vom Absender als auch vom Empfänger weiterhin im Klartext gespeichert. STARTTLS bietet Verschlüsselung nur für Mail, die über eine einzige Station zwischen zwei sendmail-systemen gereicht wird, die für STARTTLS konfiguriert sind. In Kapitel 7 wurde erläutert, wie sendmail auf die Simple Authentication and Security Layer (SASL) zurückgreift, um die Sicherheitswerkzeuge bereitzustellen, die für die AUTH- Authentifizierung erforderlich sind. STARTTLS verlässt sich für die Authentifizierung und Verschlüsselung auf das Transport Layer Security-Protokoll (TLS). Transport Layer Security TLS ist ein Internet-Standardprotokoll, das in RFC 2246, The TLS Protocol Version 1.0, definiert ist. TLS basiert auf dem Secure Sockets Layer-Protokoll (SSL), das ursprünglich von Netscape entwickelt wurde, um Sicherheit im Web zu gewährleisten. Die Art und Weise, in der TLS benutzt wird, um den Mail-Transport zu sichern, ist in RFC 2487, SMTP Service Extension for Secure SMTP over TLS, definiert. Die SMTP-Erweiterung, die TLS unterstützt, wird STARTTLS genannt. Das empfangende System bietet in seiner Antwort auf den Client-Befehl EHLO Unterstützung für STARTTLS an. Das verbindende System fordert TLS- Sicherheit an, indem es als Antwort auf die Ankündigung den Befehl STARTTLS ausführt. 296 Kapitel 8: Den Mail-Transport sichern

315 Rechts TLS verwendet eine Verschlüsselung mit öffentlichem Schlüssel (Public Key Encryption), die auch als asymmetrische Verschlüsselung bezeichnet wird. Sie ist asymmetrisch, weil sie zwei unterschiedliche Schlüssel benutzt: einen öffentlichen Schlüssel, der der Welt zur Verfügung gestellt wird, und einen privaten Schlüssel, der geheim gehalten wird. Alles, was mit dem öffentlichen Schlüssel verschlüsselt wurde, kann nur mit dem privaten Schlüssel entschlüsselt werden, und alles, was mit dem privaten Schlüssel verschlüsselt wurde, kann nur mit dem öffentlichen Schlüssel entschlüsselt werden. Es sind vier Schlüssel erforderlich, um sowohl den TLS-Client als auch den TLS-Server zu authentifizieren: die öffentlichen und privaten Schlüssel des Clients und die öffentlichen und privaten Schlüssel des Servers. 1 Das Zertifikat Ein öffentlicher TLS-Schlüssel wird mit einer Datei verteilt, die als Zertifikat bezeichnet wird. Sie heißt deshalb Zertifikat, weil mit Hilfe einer digitalen Signatur zertifiziert wurde, dass sie einen gültigen öffentlichen Schlüssel enthält. Es gibt einige unterschiedliche Techniken, die benutzt werden, um die von sendmail verwendeten Zertifikate zu signieren. Zum einen gibt es kommerzielle Certificate Authorities (CAs). Gegen eine Gebühr signiert eine kommerzielle CA Ihre Zertifizierungsanforderung (Certificate Request) und erzeugt dabei ein signiertes Zertifikat. Einer CA wird dahingehend vertraut, dass sie angemessen versichern kann, dass das Zertifikat korrekt ist und auch wirklich die Einrichtung repräsentiert, die es zu repräsentieren vorgibt. Kommerzielle CAs haben sich gut bewährt, da sie bereits seit einigen Jahren Zertifikate für Websites signieren. Es ist einfach, eine kommerzielle CA zu benutzen, um sendmail-zertifikate signieren zu lassen, und bietet sogar den Vorteil, dass ein globaler Kundenstamm unterstützt werden kann Zertifikate, die von einer kommerziellen CA signiert wurden, werden weltweit akzeptiert. Da viele Websites Zugriff auf einen globalen Kundenstamm haben wollen, benutzen sie kommerzielle CAs. Tatsächlich kann eine Liste der vertrauenswürdigen kommerziellen CAs von jedem Webbrowser bezogen werden. Abbildung 8-1 zeigt die Liste der CAs, die von Netscape ausgegeben werden. Eine Alternative zum Einsatz einer kommerziellen CA besteht darin, eine private CA zu schaffen. Das Schaffen einer privaten CA ist komplizierter als die Benutzung einer kommerziellen CA und beschränkt die Kundenbasis auf solche Sites, die willens sind, Zertifikate von der privaten CA zu akzeptieren. Während eine private CA sich für eine Website nicht eignet, die einen globalen Kundenstamm unterstützen muss, bietet sie eine brauchbare Lösung für sendmail-sicherheit, da Mail-Sicherheit oft nur zwischen einer begrenzten Anzahl von Partnern gewährleistet werden muss. Rezept 8.1 zeigt Ihnen, wie Sie eine private CA aufbauen. Rezept 8.3 benutzt diese CA dann, um die Zertifikate zu erzeugen, die in den anderen Rezepten eingesetzt werden. 1 Für die SMTP-Verbindung ist der TLS-Client das System, das die Verbindung initiiert, und der TLS-Server ist das System, zu dem die Verbindung hergestellt wird. Einführung 297

316 Links Abbildung 8-1: Die Netscape-Liste der anerkannten CAs Schließlich ist es möglich, ein selbstsigniertes Zertifikat zu erzeugen, das nicht von irgendeiner CA signiert wurde. sendmail akzeptiert für die Authentifizierung keine selbstsignierten Zertifikate, da es ohne die die Zertifizierung einer anerkannten CA keine Möglichkeit gibt, die Informationen des Zertifikats zu verifizieren. Dagegen akzeptiert sendmail selbstsignierte Zertifikate für die Verschlüsselung. Falls Sie etwa nur eine Verschlüsselung wünschen, benötigt der TLS-Client überhaupt kein Zertifikat. Allerdings erhöht die Benutzung einer CA den Nutzen des STARTTLS-Protokolls, weil sie die einfache Verschlüsselung um starke Authentifizierung erweitert. Falls das sendmail-system auch ein Webserver ist, besitzt es möglicherweise bereits ein kommerziell signiertes Zertifikat, das auch für sendmail verwendet werden kann. Falls nicht, benutzen Sie openssl zum Anlegen von Zertifikaten. Damit ein sendmail-zertifikat von einer kommerziellen CA signiert werden kann, erzeugen Sie einen Certificate Signing Request (CSR) auch als Certificate Request bezeichnet und senden diesen zum Signieren an die kommerzielle CA. (Näheres erfahren Sie auf der Website der CA, die Sie gewählt haben.) Falls Sie eine private CA betreiben, erzeugen Sie den CSR und nutzen die private CA, um ihn zu signieren. Die Rezepte 8.2 und 8.3 zeigen Beispiele für das Erzeugen eines CSR und das Signieren dieses CSR zum Anlegen eines signierten Zertifikats. Zertifikate enthalten viel mehr als nur einen öffentlichen Schlüssel. Benutzen Sie openssl, um den Inhalt eines Zertifikats zu untersuchen, wie in diesem Beispiel gezeigt: # openssl x509 -noout -text -in rodent.pem Certificate: Data: Version: 3 (0x2) 298 Kapitel 8: Den Mail-Transport sichern

317 Rechts Serial Number: 2 (0x2) Signature Algorithm: md5withrsaencryption Issuer: C=US, ST=Maryland, L=Gaithersburg, O=WroteTheBook, CN=chef.wrotethebook.com/ =craig@chef.wrotethebook.com Validity Not Before: Jan 28 16:25: GMT Not After : Jan 28 16:25: GMT Subject: C=US, ST=Maryland, L=Gaithersburg, O=WroteTheBook, CN=rodent.wrotethebook.com/ =alana@rodent.wrotethebook.com Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:b0:91:de:51:14:19:91:61:39:ed:23:61:ef:9d: e4:44:9f:ff:6a:fd:5c:cc:e8:bd:79:1f:2d:bc:eb: ca:66:da:86:fb:99:17:79:07:94:dd:94:90:aa:6a: 44:55:ff:ec:65:e9:4e:41:b1:e9:e9:c4:09:89:81: 47:2b:a1:bd:a0:0b:bf:9c:c5:5e:39:de:c5:49:a3: e6:5c:af:9e:32:eb:ae:63:80:7f:c6:ad:12:d0:87: 01:db:06:a3:93:bf:41:9f:51:81:4f:09:fa:da:e3: ca:69:dc:35:4f:cd:43:fd:ab:6c:51:3d:24:97:60: bd:bf:e8:91:9c:5a:f4:b2:df Exponent: (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 76:6E:60:D0:EE:B4:62:49:84:46:04:7C:44:E6:F8:9E:CF:84:B6:DC X509v3 Authority Key Identifier: keyid:3c:d9:71:02:66:8a:d4:ad:3c:07:fd:57:2a:c5:03:c2:b8:7d:ff:d5 DirName:/C=US/ST=Maryland/L=Gaithersburg/O=WroteTheBook/ CN=chef.wrotethebook.com/ =craig@chef.wrotethebook.com serial:00 Signature Algorithm: md5withrsaencryption c4:45:4a:e4:01:eb:0b:83:c4:26:c5:de:9e:06:8f:7a:b6:2d: f0:f3:63:dd:ba:1c:22:2d:f9:ac:3d:92:04:c4:4f:a8:9c:d1: 7c:de:a7:6d:94:10:62:cb:69:c6:ba:8f:09:e7:a9:49:18:97: 4b:aa:50:b9:0a:c9:49:59:0d:65:b6:44:1a:d6:88:6c:bd:d9: 3e:89:e6:1c:76:c8:54:69:7f:b4:9d:7a:a7:de:92:12:cc:f5: 43:e5:e5:da:b0:34:9d:cf:ee:b9:65:a1:a8:d7:cc:aa:96:12: 10:7f:2b:99:94:79:f3:b4:bf:0a:58:54:65:7f:98:36:be:a5: 22:de In dieser Ausgabe sind einige wichtige Informationen zu erkennen. Zuerst ist da natürlich der öffentliche Schlüssel. Es handelt sich um den öffentlichen 1024-Bit-RSA-Schlüssel, der ungefähr in der Hälfte der Ausgabe zu sehen ist. Dies ist der Schlüssel, der dazu verwendet wird, die Sitzungsinformationen zu verschlüsseln, die an das System gesandt werden, das den privaten Schlüssel vorhält zu den Sitzungsinformationen gehört auch der Sitzungsschlüssel, der verwendet wird, um die Mail zu verschlüsseln. Einführung 299

318 Das System, dem dieses Zertifikat gehört, wird durch das Subject-Feld identifiziert. Das Subject-Feld enthält den Distinguished Name (DN) des entfernten Hosts. Der DN ist ein formaler Name, der mehrere Felder enthalten kann. In diesem Beispiel enthält der DN einen Ländercode (Country Code; C), einen Bundesstaatcode (State Code; ST), einen Ort (Locality; L), einen Organisationsnamen (O) und einen allgemeinen Namen (Common Name; CN). In der sendmail-konfiguration ist der DN des Subjects im Makro ${cert_subject} zu finden und der CN des Subjects im Makro ${cn_subject}. In unserem Beispiel gehört das Zertifikat zum Host rodent.wrotethebook.com. Die CA, die das Zertifikat signiert hat, wird durch das Issuer-Feld identifiziert, das den DN der CA enthält. In der sendmail-konfiguration ist der DN der CA im Makro ${cert_ issuer} zu finden, und der CN der CA steht im Makro ${cn_issuer}. Im Beispiel ist chef. wrotethebook.com die private CA, die in Rezept 8.1 erzeugt wurde. Am Ende der Ausgabe steht die digitale Signatur des Zertifikats, die von der CA erzeugt wurde. Es handelt sich hierbei um eine MD5-Zusammenfassung (ein Digest) des Zertifikats, das in der sendmail-konfiguration im Makro ${cert_md5} gespeichert wird. Das Digest wurde mit dem privaten Schlüssel der CA verschlüsselt. sendmail verwendet den öffentlichen Schlüssel der CA, um das Digest zu entschlüsseln. Wenn sendmail das Digest erfolgreich entschlüsselt und verifiziert hat, speichert es OK im Makro ${verify} und betrachtet das Zertifikat als gültig für die Authentifizierung. Das Makro ${verify} kann je nach Ergebnis des Verifizierungsvorgangs einen von mehreren unterschiedlichen Werten enthalten. Die möglichen Werte für das Makro ${verify} sind: FAIL Das Zertifikat hat den Verifizierungsvorgang nicht bestanden. NONE STARTTLS wird nicht benutzt. Das heißt, es wurde keine Verifizierung durchgeführt. NOT Vom entfernten Host wurde kein Zertifikat angefordert. Wenn das lokale System kein Zertifikat vom entfernten System verlangt, wird keine Verifizierung durchgeführt. NO Vom entfernten Host wurde kein Zertifikat bereitgestellt. Es gab daher kein Zertifikat zum Verifizieren. OK Das Zertifikat wurde erfolgreich verifiziert. PROTOCOL Ein Protokollfehler ist aufgetreten. SOFTWARE Der STARTTLS-Handshake ist fehlgeschlagen. TEMP Ein temporärer Fehler ist aufgetreten. Links 300 Kapitel 8: Den Mail-Transport sichern

319 Rechts Schauen Sie auch hier noch einmal auf das Zertifikat, das vom Befehl openssl x509 ausgegeben wurde. Gleich am Anfang der Ausgabe wird die TLS-Versionsnummer im Version- Feld des Zertifikats angegeben. In der sendmail-konfiguration wird die TLS-Versionsnummer im Makro ${tls_version} gespeichert. Wie wir gesehen haben, können mehrere sendmail-makros direkt auf das TLS-Zertifikat zurückgeführt werden. Zwei weitere wichtige mit TLS verbundene Makros erhalten ihre Werte von der Sitzungsverschlüsselung, die für die -Verbindung benutzt wird. ${cipher} identifiziert die Art der Verschlüsselung, die für die Verbindung zum Einsatz kommt, und ${cipher_bits} enthält die Anzahl der Bits der Verschlüsselung für die Verbindung. All die wichtigen TLS-Verschlüsselungs- und Authentifizierungsdaten stehen für die Benutzung innerhalb der sendmail-konfiguration zur Verfügung. Die access-datenbank mit TLS benutzen Die access-datenbank stellt die beste Möglichkeit dar, um zu kontrollieren, wie TLS- Sicherheitsinformationen auf Ihr System angewandt werden. Folgende access-datenbank-records bieten Kontrolle über eine TLS-Verbindung: CERTISSUER: Autorisiert die Weitervermittlung auf der Grundlage des DN der CA, die das Zertifikat signiert hat. Die Rezepte 8.5 und 8.6 stellen Beispiele für die Benutzung des CERTISSUER:-Records vor. CERTSUBJECT: Autorisiert die Weitervermittlung auf der Grundlage des DN des Hosts, der das Zertifikat präsentiert hat. Rezept 8.6 behandelt den Einsatz dieses Records. TLS_Srv: Definiert die minimale Sicherheit, die für eine ausgehende TLS-Verbindung erforderlich ist. Die Rezepte 8.7 und 8.9 zeigen, wie das TLS_SRV:-Record verwendet wird. TLS_Clt: Definiert die minimale Sicherheit, die für eine eingehende TLS-Verbindung erforderlich ist. Die Rezepte 8.8 und 8.9 enthalten Beispiele für das TLS_Clt:-Record. TLS_Rcpt: Definiert die minimale Sicherheit, die für Mail erforderlich ist, die an den angegebenen Empfänger gesandt wird. Rezept 8.10 benutzt dieses Record. Try_TLS: Kontrolliert, ob der Befehl STARTTLS auf dem angegebenen entfernten TLS-Server aufgerufen wurde. In Rezept 8.11 finden Sie ein Beispiel für die Benutzung dieses Records. Srv_Features: Kontrolliert, ob STARTTLS auf dem angegebenen entfernten TLS-Client bekannt gemacht wurde und ob der angegebene entfernte TLS-Client ein Zertifikat präsentieren muss. Die Rezepte 8.12 und 8.13 enthalten Beispiele für dieses Record. Einführung 301

320 sendmail bietet Einstiegspunkte in die Regelsätze, die die access-datenbankeinträge verarbeiten, die mit STARTTLS zu tun haben: LOCAL_TLS_CLIENT ist ein Einstiegspunkt in den Regelsatz tls_clt, der TLS_Clt:- Datenbank-Records verarbeitet. LOCAL_TLS_SERVER ist ein Einstiegspunkt in den Regelsatz tls_srv, der TLS_Srv:- access-datenbank-records verarbeitet. LOCAL_TLS_RCPT ist ein Einstiegspunkt in den Regelsatz tls_rcpt, der TLS_Rcpt:- Records verarbeitet. LOCAL_TRY_TLS ist ein Einstiegspunkt in den Regelsatz try_tls, der Try_TLS:-Records verarbeitet. Diese Einstiege bieten Zugriff auf die komplette Bandbreite der Fähigkeiten von sendmail, einschließlich aller Informationen, die sendmail zu dem Zeitpunkt besitzt, zu dem die access-datenbank-records verarbeitet werden. Alles, was nicht innerhalb der Grenzen des Formats der Standard-Datenbank-Records erledigt werden kann, lässt sich wahrscheinlich durch einen angepassten Regelsatz erledigen. Die Stärke und Einfachheit der Benutzung der access-datenbank zum Steuern der Auslieferung über eine TLS-Verbindung machen eigene TLS-Regelsätze größtenteils unnötig. Falls Sie jedoch eine Anwendung für einen eigenen Regelsatz haben, bietet sendmail alle Werkzeuge, die Sie brauchen, um einen solchen anzulegen. Links OpenSSL Die sendmail-implementierung von STARTTLS hängt für die Authentifizierung, Verschlüsselung und unterstützenden Werkzeuge von OpenSSL ab. Bevor irgendeines der Rezepte in diesem Kapitel benutzt werden kann, muss OpenSSL installiert werden. Moderne Systeme enthalten oft OpenSSL, um Web-Sicherheit zu gewährleisten. Unser Beispiel-Red-Hat-Linux-System enthält eine OpenSSL-RPM-Datei, wie dieser einfache Befehl zeigt: $ rpm -q openssl openssl-0.9.6b-18 Falls Ihr System OpenSSL enthält, können Sie fortfahren. Ist es jedoch nicht installiert, dann installieren Sie die Version, die Ihr Unix-Hersteller bereitstellt; verwenden Sie dazu die Paketverwaltungswerkzeuge des Herstellers. Stellt Ihr Unix-Hersteller kein OpenSSL zur Verfügung, dann laden Sie die Quelle von oder von ftp://ftp.openssl.org/source/ herunter. Die Quelle ist eine gzip-gepackte tar-datei. Entpacken Sie die tar-datei, und stellen Sie sie wieder her. Wechseln Sie in das neu angelegte Verzeichnis, und führen Sie config sowie make aus, um den Quellcode zu kompilieren. Führen Sie anschließend make test und make install aus, um OpenSSL zu installieren. Falls Sie Probleme beim Kompilieren der Quelle haben, lesen Sie die Datei INSTALL, die mit dem Quellcode geliefert wird. 302 Kapitel 8: Den Mail-Transport sichern

321 Rechts Außerdem muss sendmail speziell kompiliert werden, um STARTTLS zu unterstützen. Falls Ihr sendmail-programm ohne Unterstützung für STARTTLS kompiliert wurde, dann kompilieren Sie sendmail neu, wie in den Rezepten 1.6 und 1.7 beschrieben. 8.1 Eine private Certificate Authority aufbauen Problem Ihre Einrichtung hat beschlossen, nicht auf eine kommerzielle CA zurückzugreifen, und hat Sie daher gebeten, eine private CA zu erzeugen, um Zertifikate für sendmail zu signieren und zu verwalten. Lösung Wählen Sie ein Verzeichnis, in dem Sie die CA-Verzeichnisstruktur ablegen (/etc/mail/certs wird häufig ausgewählt). Wechseln Sie in dieses Verzeichnis, und führen Sie das Skript CA aus, das mit der OpenSSL-Distribution bereitgestellt wird. Verwenden Sie die Kommandozeilenoption -newca des CA-Skripts. 2 Das Skript ermöglicht es Ihnen, einen Zertifikatsdateinamen einzugeben, um mit einem existierenden CA-Zertifikat zu arbeiten. In diesem Fall arbeiten wir allerdings nicht mit einem existierenden CA-Zertifikat drücken Sie deshalb einfach die Entertaste, um eine neue CA anzulegen. Wenn Sie nach einer PEM-Passphrase gefragt werden, geben Sie das Kennwort ein, das immer dann erforderlich wird, wenn die Certificate Authority eine Zertifizierungsanforderung (Certificate Request) signieren soll. Geben Sie schließlich den Distinguished Name des Systems ein, das als CA agiert. Hier ist ein Beispiel: # cd /etc/mail # mkdir certs # cd certs # /usr/share/ssl/misc/ca -newca CA certificate filename (or enter to create) Making CA certificate... Using configuration from /usr/share/ssl/openssl.cnf Generating a 1024 bit RSA private key writing new private key to './democa/private/./cakey.pem' Enter PEM pass phrase: SaytheSECRETword! Verifying password - Enter PEM pass phrase: SaytheSECRETword! You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. 2 Das CA-Skript finden Sie im Unterverzeichnis misc des OpenSSL-Verzeichnisses ssl. Auf unserem Beispiel-Red- Hat-Linux-System lautet der vollständige Verzeichnispfad /usr/share/ssl/misc; auf anderen Systemen ist es /usr/ local/ssl/misc. 8.1 Eine private Certificate Authority aufbauen 303

322 There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank Country Name (2 letter code) [GB]:US State or Province Name (full name) [Berkshire]:Maryland Locality Name (eg, city) [Newbury]:Gaithersburg Organization Name (eg, company) [My Company Ltd]:WroteTheBook Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []:chef.wrotethebook.com Address []:craig@chef.wrotethebook.com Das Skript CA erzeugt eine Verzeichnisstruktur, die es als democa bezeichnet und die die Dateien enthält, die für eine private CA benötigt werden. Ändern Sie den Namen democa in etwas, das weniger provisorisch klingt, beispielsweise in den Verzeichnisnamen CA: # mv democa CA Wechseln Sie in die neue Verzeichnisstruktur. Erhöhen Sie die Sicherheit im Verzeichnis private, das den privaten Schlüssel der Certificate Authority enthält: # cd CA # chmod 0700 private Kopieren Sie die Datei openssl.cnf in das Verzeichnis CA. Die Kopie wird von der privaten CA benutzt werden, wenn sie sendmail-zertifikate signiert. Um sie von der ursprünglichen Datei openssl.cnf zu unterscheiden, wurde die Kopie in sendmailssl.cnf umbenannt, als sie in das Verzeichnis CA kopiert wurde: # cp /usr/share/ssl/openssl.cnf sendmailssl.cnf Bearbeiten Sie die Datei sendmailssl.cnf schließlich so, dass sie auf die neu angelegte CA- Verzeichnisstruktur verweist. Verändern Sie die Zeile in: dir =./democa # Where everything is kept dir = /etc/mail/certs/ca # Where everything is kept Die private CA kann nun dazu verwendet werden, Zertifikate zu signieren, wie in Rezept 8.3 beschrieben. Diskussion Es ist nicht absolut notwendig, eine private CA aufzubauen, nur um die Zertifikate zu erzeugen, die von STARTTLS benötigt werden. Die Einführung in dieses Kapitel beschreibt alternative Möglichkeiten, um an signierte Zertifikate zu gelangen. Dieses Rezept darf nicht als Empfehlung betrachtet werden, eine private CA zu schaffen. Es ist als Rezept in dieses Kapitel integriert, weil das Aufbauen einer privaten CA die komplizierteste Methode zum Signieren von Zertifikaten und deshalb diejenige Methode ist, die am ehesten ein Rezept benötigt, um zu erklären, wie das erledigt wird. Bevor Sie sich ent- Links 304 Kapitel 8: Den Mail-Transport sichern

323 Rechts scheiden, eine private CA aufzubauen, sollten Sie die Alternativen prüfen, um sicherzugehen, dass der gewählte Ansatz für Ihre Situation wirklich der beste ist. Eine private CA anzulegen ist eine komplexe Aufgabe. Sie wird durch das Skript CA, das mit der OpenSSL-Distribution geliefert wird, aber deutlich vereinfacht. Das Skript CA akzeptiert mehrere unterschiedliche Kommandozeilenargumente. Am nützlichsten für ein sendmail- System ist die Option -newca. Die Option -newca veranlasst das Skript, die Verzeichnisstruktur und die Dateien anzulegen, die von einer CA benötigt werden. Außerdem veranlasst sie das Skript, den privaten Schlüssel und das Zertifikat zu erzeugen, die von der CA benutzt werden. Ein ls des Verzeichnisses, das vom Skript CA erzeugt wurde, zeigt Folgendes: # ls cacert.pem certs crl index.txt newcerts private serial # ls private cakey.pem Das Verzeichnis, das vom Skript CA angelegt wurde, enthält drei Dateien: serial Diese Datei enthält die Seriennummer, die für das nächste von der CA signierte Zertifikat benutzt wird. Das Skript CA speichert die Seriennummer 01 in der ursprünglichen Datei serial. Die Seriennummer wird immer dann erhöht, wenn ein Zertifikat signiert wird. index.txt Diese Datei bildet die Seriennummer, die mit einem Zertifikat verknüpft ist, auf das Subject des Zertifikats ab. Die Seriennummer wird durch ihren numerischen Wert identifiziert, das Subject des Zertifikats wird durch seinen Distinguished Name gekennzeichnet. Anfänglich ist diese Datei leer. Jedes Mal, wenn ein Zertifikat signiert wird, werden Daten in die Datei eingefügt. cacert.pem Diese Datei ist das Zertifikat, das durch das Skript CA für die Certificate Authority erzeugt wurde. (In der Einführung finden Sie Informationen über das Format von Zertifikaten.) Dieser öffentliche Schlüssel wird an die sendmail-systeme verteilt, die diese CA anerkennen, und in ihren Konfigurationen referenziert. Wenn Sie eine private CA erzeugen, um Zertifikate für sendmail zu signieren, dann ist es üblich, diese zur obersten CA (Root-CA) in der sendmail-konfiguration zu machen. Schauen Sie sich die confcacert-definition in Rezept 8.4 als Beispiel an. Der private Schlüssel, der mit dem CA-Zertifikat verknüpft ist, wird im Unterverzeichnis private gespeichert und heißt cakey.pem, wie der zweite ls-befehl im Beispiel zeigt. Der private Schlüssel wird bei der CA sicher verwahrt. Er wird niemals an ein anderes System weitergegeben oder dort benutzt. Die Datei cakey.pem ist verschlüsselt und kann nur von jemandem benutzt werden, der die PEM-Passphrase kennt, die dem Skript CA beim Erzeugen der Datei cakey.pem übergeben wurde. Im Beispiel in der Lösung lautet die PEM-Passphrase SaytheSECRETword!. Die Passphrase wird in Rezept 8.3 benötigt, wenn die CA benutzt wird, um Zertifikate zu signieren. 8.1 Eine private Certificate Authority aufbauen 305

324 Zusätzlich zu den gerade beschriebenen Dateien enthält das Verzeichnis, das vom Skript CA erzeugt wurde, vier Unterverzeichnisse: private Dieses Verzeichnis wird verwendet, um die privaten Schlüssel aufzunehmen. Das Skript CA platziert hier den privaten Schlüssel der Certificate Authority. In der Lösung werden die Berechtigungen auf diesem Verzeichnis auf 0700 geändert. newcerts Dieses Verzeichnis enthält die Kopien aller Zertifikate, die von dieser CA signiert wurden. Die Zertifikate in diesem Verzeichnis werden anhand der Seriennummern identifiziert. Dieses Verzeichnis ist leer, wenn es vom Skript CA erzeugt wird. Dateien werden durch den Vorgang des Signierens in dieses Verzeichnis eingefügt. crl Dieses Verzeichnis enthält die Certificate-Revocation-Listen (Listen mit Zertifikatsrücknahmen). Das Skript CA erzeugt dieses Verzeichnis als leeres Verzeichnis. Im Buch Network Security with OpenSSL von Viega, Messier und Chandra (O Reilly) finden Sie Informationen über CRLs. certs Dieses Verzeichnis kann benutzt werden, um Zertifikate aufzunehmen. Allerdings setzt das Skript CA das Zertifikat der CA nicht in dieses Verzeichnis. Dieses Rezept empfiehlt das Hinzufügen einer Kopie von openssl.cnf zu den Dateien und Verzeichnissen, die vom CA-Skript erzeugt wurden. Die openssl.cnf-konfigurationsdatei wird bei jedem Ausführen von openssl gelesen. openssl wird benutzt, um Zertifikate zu erzeugen und zu signieren und kommt in den folgenden Rezepten dieses Kapitels zum Einsatz. Um die Anpassung der OpenSSL-Konfiguration für die sendmail-zertifikatsverwaltung zu vereinfachen und um jede Möglichkeit des Zusammenstoßes mit der OpenSSL- Konfiguration zu vermeiden, die vom Website-Administrator eingesetzt wird, kopieren wir openssl.cnf nach sendmailssl.cnf. Der neue Name soll verdeutlichen, dass diese Konfiguration nur von der sendmail-ca benutzt wird. Wir bearbeiten die Datei sendmailssl.cnf dann so, dass sie auf /etc/mail/certs/ca als das Verzeichnis verweist, das von der vorgegebenen CA benutzt wird. Dieses Rezept geht davon aus, dass die private CA ausschließlich für die sendmail-zertifikatsverwaltung eingesetzt wird. Da diese CA ausschließlich für sendmail benutzt wird, ist es sinnvoll, eine sendmail-spezifische OpenSSL-Konfiguration zu erzeugen. Rezept 8.3 verwendet die neu angelegte Datei sendmailssl.cnf. Siehe auch Die Rezepte 8.2 und 8.3 haben beide direkt mit diesem Rezept zu tun. Die Einführung in dieses Kapitel enthält wichtige Informationen über Zertifikate und Certificate Authorities. Das Buch sendmail erläutert Zertifikate in Abschnitt Die config-manpage bietet Informationen über die Datei openssl.cnf. Das Buch Network Security with OpenSSL von Viega, Messier und Chandra (O Reilly) liefert Informationen über Zertifikate, Certificate Authorities und Certificate-Revocation-Listen. Links 306 Kapitel 8: Den Mail-Transport sichern

325 Rechts 8.2 Eine Zertifizierungsanforderung erzeugen Problem Bevor die CA ein Zertifikat signieren kann, müssen Sie eine Zertifizierungsanforderung (Certificate Request) erzeugen. Lösung Legen Sie auf dem sendmail-host ein Verzeichnis für das Zertifikat und den privaten Schlüssel an. Hier ist ein Beispiel: # cd /etc/mail # mkdir certs Wechseln Sie in das neue Verzeichnis. Verwenden Sie den Befehl openssl req, um ein unsigniertes X.509-Zertifikat und einen privaten Schlüssel zu erzeugen. Wenn Sie nach dem Distinguished Name gefragt werden, geben Sie den DN des sendmail-hosts ein, für den dieses Zertifikat erzeugt wird. In diesem Beispiel erzeugen wir ein Zertifikat für crab. wrotethebook.com: # cd /etc/mail/certs # umask 0066 # openssl req -nodes -new -x509 -keyout key.pem -out newcert.pem Using configuration from /usr/share/ssl/openssl.cnf Generating a 1024 bit RSA private key writing new private key to 'key.pem' You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank Country Name (2 letter code) [GB]:US State or Province Name (full name) [Berkshire]:Maryland Locality Name (eg, city) [Newbury]:Gaithersburg Organization Name (eg, company) [My Company Ltd]:WroteTheBook Organizational Unit Name (eg, section) []: Common Name (eg, your name or the server's name) []:crab.wrotethebook.com Address []:admin@wrotethebook.com Benutzen Sie als Nächstes openssl x509, um einen Certificate Signing Request aus dem oben erzeugten Zertifikat und dem Schlüsselpaar zu erstellen. Die Datei newcert.pem, die oben angelegt wurde, ist eine temporäre Datei, die nach dem Erzeugen des CSR gelöscht werden kann: 8.2 Eine Zertifizierungsanforderung erzeugen 307

326 # openssl x509 -x509toreq -in newcert.pem -signkey key.pem -out csr.pem Getting request Private Key Generating certificate request # rm -f newcert.pem Senden Sie den CSR, in diesem Beispiel csr.pem, an die CA. Die CA signiert die Zertifizierungsanforderung des sendmail-hosts. Rezept 8.3 zeigt, wie Sie dies mit der privaten CA erledigen, die in Rezept 8.1 geschaffen wurde. Die CA liefert ein signiertes Zertifikat sowie eine Kopie des Zertifikats der CA an den sendmail-host zurück. Platzieren Sie auf dem sendmail-host das signierte Zertifikat des sendmail-hosts und das Zertifikat der CA in das Zertifikatsverzeichnis, das im ersten Schritt angelegt wurde. Erzeugen Sie mit dem folgenden Befehl einen symbolischen Verweis auf einen Hashwert des Zertifikats der CA: ln s ca_dateiname `openssl x509 noout hash < ca_dateiname`.0 Ersetzen Sie in dem obigen Befehl ca_dateiname durch den Dateinamen der Zertifikats der CA. sendmail verwendet den Hashwert, der durch diesen Befehl erzeugt wurde, für die Überprüfung des Zertifikats. Führen Sie diesen Befehl jedes Mal aus, wenn ein CA- Zertifikat zu dem Verzeichnis hinzugefügt wird, das durch die Definition confcacert_ PATH identifiziert wird. Ersetzen Sie dabei ca_dateiname durch den Namen der neuen CA- Zertifikatsdatei. Die Definition confcacert_path wird in Rezept 8.4 erläutert. Diskussion Der größte Teil der Arbeit bei diesem Rezept wird auf dem sendmail-host erledigt. Das muss jedoch nicht so sein. Alle Dateien, die erforderlich sind, um ein signiertes Zertifikat für crab.wrotethebook.com anzufordern, können auf jedem System generiert werden, auf dem OpenSSL installiert ist. Der Vorteil beim Erzeugen des CSR auf dem sendmail-host besteht darin, dass der private Schlüssel dort erzeugt wird und niemals das System verlassen muss. Auf diese Weise lässt sich die Sicherheit für den privaten Schlüssel leichter durchsetzen. Nachteilig ist, dass der Administrator von crab.wrotethebook.com die komplizierten openssl-befehle benutzen muss, um den CSR zu erstellen. Viele Sites bevorzugen es, einen CA-Administrator zu haben, der das Zertifikat und den Schlüssel für jeden einzelnen sendmail-host auf dem CA-Server erzeugt und die signierten Dateien dann an die sendmail-systeme verteilt. Welchen Ansatz Sie verfolgen, hängt größtenteils von der Vorgehensweise ab, die Ihre Organisation bevorzugt. Das einzige, was auf dem sendmail-host erzeugt werden muss, ist das Verzeichnis, das das Zertifikat und den privaten Schlüssel aufnimmt. Beim Namen dieses Verzeichnisses sowie bei den Namen der Zertifikatsdatei, der Schlüsseldatei und der CA-Zertifikatsdatei handelt es sich um wichtige Werte, die benutzt werden, um sendmail für STARTTLS zu konfigurieren, wie Sie in Rezept 8.4 sehen. Der Befehl openssl req in der Lösung erzeugt ein neues, selbstsigniertes X.509-Zertifikat (-new -x509). Das Zertifikat wird in eine Datei namens newcert.pem geschrieben (-out newcert.pem). Der private Schlüssel, der mit dem Zertifikat verknüpft ist, wird in einer Links 308 Kapitel 8: Den Mail-Transport sichern

327 Rechts Datei namens key.pem gespeichert (-keyout key.pem). Die Datei key.pem ist nicht mit DES verschlüsselt (-nodes). Das ist wichtig. Falls der private Schlüssel fälschlicherweise in eine verschlüsselte Datei platziert wird, wird der sendmail-administrator jedes Mal nach dem Kennwort gefragt, um die Datei zu entschlüsseln, wenn sendmail auf den privaten Schlüssel zugreifen muss. Dies könnte dazu führen, dass das sendmail-system während des Boot-Vorgangs so lange wartet, bis das Kennwort eingegeben wurde. Der Befehl openssl x509 verarbeitet ein X.509-Zertifikat. In diesem Fall wandelt der Befehl ein X.509-Zertifikat in eine Zertifizierungsanforderung um (-x509toreq). Das Zertifikat, das umgewandelt wird, ist die Datei newcert.pem, die im ersten Schritt angelegt wurde (-in newcert.pem -signkey key.pem). Der CSR wird in eine Datei namens csr.pem geschrieben (-out csr.pem). Die CSR-Datei wird an die CA gesandt. Die CA benutzt diese Datei als Eingabe für den Signaturvorgang und liefert eine andere Datei zurück, nämlich das signierte Zertifikat. Oft wird eine Datei an die CA geschickt und eine zurückgegeben. Die Lösung erwähnt jedoch auch eine zweite Datei das Zertifikat der CA. Dieses Zertifikat wird möglicherweise nicht als Teil des Signaturvorgangs von der CA geschickt. Es könnte andere Methoden geben, um diese Datei zu beziehen. Ungeachtet der Frage, wie das CA-Zertifikat bezogen wird, sollte ein Hashwert aus dem CA-Zertifikat erstellt werden, wie im letzten Schritt der Lösung gezeigt wird. sendmail benutzt den Hashwert während der Überprüfung des Zertifikats. Siehe auch Rezept 8.3 behandelt das Signieren der Zertifizierungsanforderung, die in diesem Rezept erzeugt wurde. 8.3 Eine Zertifizierungsanforderung signieren Problem Wenn Sie eine private CA für sendmail betreiben, sind Sie für das Signieren der Zertifizierungsanforderungen der sendmail-hosts verantwortlich. Lösung Benutzen Sie auf der CA den Befehl openssl ca, um die Zertifizierungsanforderung (Certificate Signing Request) zu signieren, die vom sendmail-host stammt. Wenn Sie nach der PEM-Passphrase gefragt werden, geben Sie das Kennwort ein, das für die private CA angelegt wurde. Antworten Sie»yes«auf die beiden Fragen, und das Zertifikat ist signiert. Hier ist ein Beispiel, in dem der CSR, der in Rezept 8.2 erzeugt wurde, auf der CA aus Rezept 8.1 signiert wird: # openssl ca -config./sendmailssl.cnf -policy policy_anything -out cert.pem -infiles csr.pem 8.3 Eine Zertifizierungsanforderung signieren 309

328 Using configuration from./sendmailssl.cnf Enter PEM pass phrase: SaytheSECRETword! Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows countryname :PRINTABLE:'US' stateorprovincename :PRINTABLE:'Maryland' localityname :PRINTABLE:'Gaithersburg' organizationname :PRINTABLE:'WroteTheBook' commonname :PRINTABLE:'crab.wrotethebook.com' address Certificate is to be certified until Jan 27 19:50: GMT (365 days) Sign the certificate? [y/n]:y Links 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated Bei dem CSR, der vom sendmail-system gesandt wurde, handelt es sich um eine Zwischendatei, die nicht länger benötigt wird. Löschen Sie die unnötige Datei: # rm -f csr.pem Senden Sie das signierte Zertifikat an den sendmail-host. In diesem Beispiel sendeten wir die Datei cert.pem an den sendmail-host. Wir nannten die Zertifikatsdatei cert.pem, weil dies ein neutraler Name ist, der sich gut als Beispiel in einem solchen Buch eignet. Allerdings legen Sie den Zertifikatsdateinamen selbst fest und sollten daher einen aussagekräftigen Namen wählen. So wurde etwa das Zertifikat für den Host crab.wrotethebook.com signiert, wir hätten es also crab.wrotethebook.com.cert.pem nennen können. Schicken Sie außerdem eine Kopie des Zertifikats der CA an den sendmail-host. Vorausgesetzt, dass dies die CA ist, die in Rezept 8.1 angelegt wurde, würde die CA-Zertifikatsdatei, die an den sendmail-host gesandt wird, cacert.pem heißen. Diskussion Der Befehl openssl ca wird benutzt, um Zertifikate zu signieren. In der Lösung signiert der Befehl openssl die Datei csr.pem aus Rezept 8.2 (-infiles csr.pem), wodurch ein signiertes Zertifikat in einer Datei namens cert.pem (-out cert.pem) erzeugt wird. Dieser openssl-befehl verweist auf die spezielle OpenSSL-Konfigurationsdatei (-config./sendmailssl.cnf), die in Rezept 8.1 für die private sendmail-ca erzeugt wurde. Falls die Konfigurationsdatei auf der Kommandozeile nicht mit der Option -config identifiziert wird, benutzt der Befehl openssl die Datei openssl.cnf. Die OpenSSL-Datei stellt Standardwerte bereit, die beim Anlegen und Signieren von Zertifikaten eingesetzt werden; sie definiert die Pfadnamen der Dateien und Verzeichnisse, die von einer CA benötigt werden, und sie definiert die Certificate Signing Policies (Grundsätze zum Signieren von Zertifikaten). Standardmäßig enthalten die Datei openssl.cnf und die Datei sendmailssl.cnf, die in Rezept 8.1 daraus erzeugt wurde, zwei Signatur-Policies: 310 Kapitel 8: Den Mail-Transport sichern

329 Rechts policy_match Signatur-Policies definieren, welche Informationen durch den DN des Subjects angegeben werden müssen, bevor ein Zertifikat zum Signieren akzeptiert wird. policy_ match verlangt, dass ein allgemeiner Name bereitgestellt wird. Außerdem müssen der Länder-, der Bundesstaats- und der Organisationsname angegeben werden. Diese Namen müssen den Angaben entsprechen, die im Zertifikat der CA verwendet werden. Der Name der Organisationseinheit und die -Adresse sind dadurch optional. policy_match ist der Standardwert, falls das Argument -policy auf der openssl ca- Kommandozeile eingesetzt wird. policy_anything Diese Policy verlangt, dass ein allgemeiner Name angegeben wird. Alle anderen DN- Felder werden dadurch optional. Dieses Rezept setzt -policy policy_anything ein, was beim Signieren von sendmail-zertifikaten üblicherweise getan wird. Schließlich wird dem Administrator der DN gezeigt, und er wird gefragt, ob das Zertifikat signiert werden soll. Wenn der Administrator denkt, dass der DN nicht genügend Informationen für die -Sicherheit enthält, dann kann er es ablehnen, das Zertifikat zu signieren. In diesem besonderen Fall jedoch hätten wir auch policy_match benutzen können und es hätte funktioniert. Denken Sie daran, dass dies eine private CA ist. Wir wissen, dass der Landes-, der Bundesstaats- und der Einrichtungsname der CA den Werten im DN des Servers entsprechen. policy_anything bietet dennoch ein besseres Beispiel, weil es flexibler ist und mit einer größeren Vielfalt von Konfigurationen umgehen kann. Die meisten sendmail-administratoren verwenden policy_anything, weshalb es auch in diesem Rezept enthalten ist. Nach dem Signieren der Zertifizierungsanforderung wird der CSR (csr.pem) gelöscht. Das Zertifikat cert.pem wird zusammen mit dem Zertifikat der CA cacert.pem an crab. wrotethebook.com gesandt. Der sendmail-host verweist auf beide Zertifikate in der STARTTLS-Konfiguration. Siehe auch Rezept 8.1 behandelt das Erzeugen der privaten CA, die benutzt wird, um das Zertifikat in diesem Rezept zu signieren. In Rezept 8.2 wird die Zertifizierungsanforderung angelegt, die in diesem Beispiel signiert wurde. Die Einführung in dieses Kapitel enthält wichtige Informationen über Zertifikate und Certificate Authorities. Das Buch sendmail beschreibt Zertifikate in Abschnitt Die config-manpage bietet Informationen über die Datei openssl.cnf. Die req-manpage dokumentiert den Befehl openssl req. Die x509-manpage dokumentiert den Befehl openssl x509, und die ca-manpage behandelt den Befehl openssl ca. Das Buch TCP/IP Netzwerk-Administration, dritte Auflage, von Craig Hunt (O Reilly) bietet in Kapitel 11 Beispiele für den Einsatz von openssl-befehlen. Network Security with OpenSSL von Viega, Messier und Chandra (O Reilly) bietet Informationen über Zertifikate, Certificate Authorities, openssl.cnf und den Befehl openssl. 8.3 Eine Zertifizierungsanforderung signieren 311

330 8.4 sendmail für STARTTLS konfigurieren Links Problem Sie wurden gebeten, sendmail so zu konfiguren, dass es den STARTTLS-Dienst für Transport Layer Security bereitstellt. Lösung STARTTLS verlangt, dass OpenSSL richtig installiert und konfiguriert ist. In der Einführung finden Sie Informationen über die Installation von OpenSSL. Es braucht außerdem eine Kopie von sendmail mit einkompilierter STARTTLS-Unterstützung, wie in den Rezepten 1.6 und 1.7 beschrieben. Darüber hinaus benötigt der sendmail-host ein Zertifikat, falls er eingehende STARTTLS-Verbindungen akzeptieren soll. Benutzen Sie OpenSSL, um das Zertifikat anzulegen, wie in den Rezepten 8.2 und 8.3 beschrieben. Erzeugen Sie eine sendmail-konfiguration mit Definitionen, die auf die Dateien verweisen, in denen das Zertifikat des Hosts, der private Schlüssel des Hosts, die Zertifikatsdatei der Root-CA und das Verzeichnis enthalten sind, in dem die CA-Zertifikate abgelegt wurden. Hier sind Beispiele der Definitionen: dnl Point to the CA certificate directory define(`confcacert_path', `/etc/mail/certs') dnl Point to the root CA's certificate define(`confcacert', `/etc/mail/certs/cacert.pem') dnl Point to the certificate used for inbound connections define(`confserver_cert', `/etc/mail/certs/cert.pem') dnl Point to the private key used for inbound connections define(`confserver_key', `/etc/mail/certs/key.pem') dnl Point to the certificate used for outbound connections define(`confclient_cert', `/etc/mail/certs/cert.pem') dnl Point to the private key used for outbound connections define(`confclient_key', `/etc/mail/certs/key.pem') Erstellen Sie die Datei sendmail.cf, kopieren Sie sie nach /etc/mail/sendmail.cf, und starten Sie dann sendmail neu, wie in Rezept 1.8 beschrieben. Diskussion Dieses Rezept bietet eine vollständige STARTTLS-Konfiguration. Ein System, das mit all diesen Definitionen konfiguriert ist, kann als TLS-Server oder -Client auftreten und sowohl eine Verschlüsselung als auch eine Authentifizierung durchführen. Die sechs Definitionen verweisen sendmail an die Dateien, die für diesen kompletten Bereich von Diensten erforderlich sind: confcacert_path Setzt den Wert für die Option CACERTPath in der Datei sendmail.cf. Die Option CACERTPath verweist auf das Verzeichnis, in dem Zertifikate der Certificate Authority 312 Kapitel 8: Den Mail-Transport sichern

331 Rechts gespeichert werden. Üblicherweise werden in diesem Verzeichnis sowohl die Serverals auch die Client-Zertifikate abgelegt. confcacert Setzt den Wert für die Option CACERTFile, die auf das Zertifikat der Root-CA verweist. Der Wert, der dieser Definition übergeben wird, ist der vollständige Pfadname der Datei, die das CA-Zertifikat enthält. confserver_cert Setzt den Wert für die sendmail.cf-option ServerCertFile, die den vollständigen Pfadnamen der Datei aufnimmt, die das für eingehende Verbindungen benutzte Server- Zertifikat enthält. confserver_key Setzt den Wert für die Option ServerKeyFile. Die Option ServerKeyFile verweist auf die Datei, die den privaten Schlüssel des Servers enthält. confclient_cert Setzt den Wert für die sendmail.cf-option ClientCertFile, die den vollständigen Pfadnamen der Datei aufnimmt, die das für eingehende Verbindungen benutzte Client- Zertifikat enthält. confclient_key Setzt den Wert für die Option ClientKeyFile. Die Option ClientKeyFile verweist auf die Datei, die den privaten Schlüssel des Clients enthält. Falls OpenSSL installiert und sendmail mit STARTTLS-Unterstützung kompiliert ist und diese Definitionen auf gültige Zertifikate verweisen, bietet sendmail STARTTLS in der Antwort auf den SMTP-Befehl EHLO an. Ein einfacher telnet-test zeigt, dass STARTTLS bereit ist: # telnet localhost smtp Trying Connected to localhost. Escape character is '^]'. 220 chef.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 22 Aug :01: ehlo localhost 250-chef.wrotethebook.com Hello IDENT:6l4ZhaGP3Qczqknqm/KdTFGsrBe2SCYC@localhost [ ], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH DIGEST-MD5 CRAM-MD5 250-STARTTLS 250-DELIVERBY 250 HELP QUIT chef.wrotethebook.com closing connection Connection closed by foreign host. 8.4 sendmail für STARTTLS konfigurieren 313

332 Sollte Ihr System STARTTLS nicht in seiner Antwort auf den EHLO-Befehl anbieten, dann prüfen Sie die Protokolldatei, um sicherzustellen, dass alle Dateiberechtigungen korrekt sind. Ist dies der Fall, dann erhöhen Sie probeweise den LogLevel auf 14, um zusätzliche STARTTLS-Debugging-Information zu protokollieren. In Rezept 1.10 finden Sie Informationen über das Einstellen des LogLevel. Dieses Rezept zeigt ein System, das sowohl mit Client- als auch mit Server-Zertifikaten und -Schlüsseln konfiguriert wurde. Viele Systeme sind sowohl als Clients als auch als Server für STARTTLS konfiguriert, weil Mail oft von einem System an ein anderes weitergeleitet wird. Wenn das System eingehende Mail empfängt, dann tritt es als STARTTLS- Server auf. Leitet es diese Mail dann an ein anderes System weiter, agiert es als START- TLS-Client. Deshalb muss das System sowohl als STARTTLS-Server als auch als START- TLS-Client handeln können. Normalerweise benutzt ein solches System für die Rollen als Client und Server die gleichen Zertifikate und Schlüssel. Ein STARTTLS-Client versucht, STARTTLS zu benutzen, sobald der Server es anbietet. Wird der sendmail-befehl mit der Option -v ausgeführt, sehen Sie die STARTTLS-Client- Seite der Beispiel-Konfiguration. Ein Beispiel dafür zeigt der folgende Code: # sendmail -Am -v -t To: craig@chef.wrotethebook.com From: craig@rodent.wrotethebook.com Subject: First STARTTLS test Ctrl-D craig@chef.wrotethebook.com... Connecting to chef.wrotethebook.com. via esmtp chef.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 22 Aug :01: >>> EHLO rodent.wrotethebook.com 250-chef.wrotethebook.com Hello rodent.wrotethebook.com [ ], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH DIGEST-MD5 CRAM-MD5 250-STARTTLS 250-DELIVERBY 250 HELP >>> STARTTLS Ready to start TLS >>> EHLO rodent.wrotethebook.com 250-chef.wrotethebook.com Hello rodent.wrotethebook.com [ ], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB Links 314 Kapitel 8: Den Mail-Transport sichern

333 Rechts 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH EXTERNAL DIGEST-MD5 CRAM-MD5 250-DELIVERBY 250 HELP >>> MAIL SIZE= Sender ok >>> RCPT >>> DATA Recipient ok 354 Enter mail, end with "." on a line by itself >>> h0ugn9p Message accepted for delivery craig@chef.wrotethebook.com... Sent (h0ugn9p Message accepted for delivery) Closing connection to chef.wrotethebook.com. >>> QUIT chef.wrotethebook.com closing connection Der Client (rodent) baut eine Verbindung zum Server (chef) auf und führt einen EHLO- Befehl aus. Als Antwort auf diesen Befehl gibt der Server bekannt, dass STARTTLS verfügbar ist. Der Client ruft dann einen STARTTLS-Befehl auf, um die TLS-Verbindung zu öffnen. Der Server antwortet mit dieser Meldung: Ready to start TLS Unmittelbar nach der Antwort zeigt der Test eine weitere EHLO-Meldung. Viele Systemadministratoren sind davon verwirrt. Das sollten Sie nicht sein. Die STARTTLS-Verhandlungen finden»außerhalb«des -Austauschs statt. STARTTLS erzeugt den verschlüsselten Tunnel, durch den die Mail reist. Das erste EHLO, die STARTTLS-Ankündigung des Servers, der STARTTLS-Befehl des Clients und die TLS-Antwort des Servers werden benutzt, um den Tunnel zu erzeugen. Der zweite EHLO-Befehl und alles, was dann folgt, sind Teil des Standard-SMTP-Protokollaustauschs, der durch den verschlüsselten Tunnel geschickt wird. Beachten Sie, dass dieser SMTP-Protokollaustausch durch den Befehl sendmail -v als Klartext dargestellt wird. Der Mail-Strom wird nur im Netzwerk verschlüsselt. Innerhalb der Endsysteme ist der Mail-Strom im Klartext zu sehen. Die Wirkung des STARTTLS-Protokolls kann indirekt in den Headern der Mail-Nachricht beobachtet werden, die den verschlüsselten Tunnel passierten. Die folgenden Header stammen von der Testnachricht, die durch den oben verwendeten Befehl sendmail -Am -v -t geschickt wurde: Return-Path: <craig@rodent.wrotethebook.com> Received: from rodent.wrotethebook.com (rodent.wrotethebook.com [ ]) by chef.wrotethebook.com (8.12.9/8.12.9) with ESMTP id h0ugn9p (version=tlsv1/sslv3 cipher=edh-rsa-des-cbc3-sha bits=168 verify=ok) for <craig@chef.wrotethebook.com>; Thu, 30 Jan :49: Received: (from root@localhost) by rodent.wrotethebook.com (8.12.9/8.12.9) id h0ugvpsd010157; Thu, 30 Jan :57: sendmail für STARTTLS konfigurieren 315

334 Date: Thu, 30 Jan :57: Message-Id: To: From: Subject: First STARTTLS test Der Received:-Header, der von chef.wrotethebook.com, dem STARTTLS-Server in diesem Austausch, generiert wurde, zeigt die TLS-Charakteristika der Verbindung, über die diese Mail empfangen wurde. Der Header zeigt die Version des TLS-Protokolls, das für die Verbindung zum Einsatz kam, die für die Verbindung verwendete Art der Verschlüsselung, die Anzahl der für die Verschlüsselung benutzten Bits sowie, ob das Zertifikat des Clients geprüft wurde. Da diese Informationen nur in den Header gelangen, wenn TLS für die Verbindung genutzt wird, teilen sie uns mit, dass der Client richtig konfiguriert wurde und für die Kommunikation mit diesem Server TLS einsetzt. Links Siehe auch Die Rezepte 8.2 und 8.3 zeigen, wie Zertifikate und Schlüssel erzeugt werden. Kapitel 1 bietet zusätzliche Informationen über das Kompilieren von sendmail. Das Buch sendmail behandelt STARTTLS in Abschnitt Weitervermittlung auf der Grundlage der CA Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es STARTTLS-Clients, die ein Zertifikat präsentieren, das von einer vertrauenswürdigen Certificate Authority signiert wurde, Weitervermittlungsberechtigungen (Relaying-Berechtigungen) gewährt. Lösung Stellen Sie sicher, dass OpenSSL installiert ist, wie in der Einführung beschrieben, und dass sendmail mit STARTTLS-Unterstützung kompiliert wurde, wie in den Rezepten 1.6 und 1.7 gezeigt wird. Identifizieren Sie alle vertrauenswürdigen Certificate Authorities in der access-datenbank mit Hilfe von CERTISSUER:-Einträgen. Das Schlüsselfeld eines solchen Eintrags beginnt mit dem CERTISSUER:-Tag, gefolgt vom Distinguished Name der CA. Der Rückgabewert des Eintrags ist das Schlüsselwort RELAY, das anzeigt, dass jedem Host, der ein Zertifikat präsentiert, das von der vertrauenswürdigen CA signiert wurde, Weitervermittlungsberechtigungen gewährt werden. Erzeugen Sie eine STARTTLS-sendmail-Konfiguration, und fügen Sie die Funktion access_db hinzu. Hier sind die Beispiele der Definitionen, die STARTTLS konfigurieren, und das FEATURE-Makro, das die access-datenbank aktiviert: 316 Kapitel 8: Den Mail-Transport sichern

335 Rechts dnl Point to the CA certificate directory define(`confcacert_path', `/etc/mail/certs') dnl Point to the root CA's certificate define(`confcacert', `/etc/mail/certs/cacert.pem') dnl Point to the certificate used for inbound connections define(`confserver_cert', `/etc/mail/certs/cert.pem') dnl Point to the private key used for inbound connections define(`confserver_key', `/etc/mail/certs/key.pem') dnl Point to the certificate used for outbound connections define(`confclient_cert', `/etc/mail/certs/cert.pem') dnl Point to the private key used for outbound connections define(`confclient_key', `/etc/mail/certs/key.pem') dnl Enable the access database FEATURE(`access_db') Erstellen Sie die Datei sendmail.cf neu, kopieren Sie die neue sendmail.cf nach /etc/mail, und starten Sie sendmail neu. Rezept 1.8 bietet ein Beispiel für diese Schritte. Diskussion TLS kann eine starke Authentifizierung der Endpunkte und eine Verschlüsselung des Datenstroms bieten. Trotz dieser wichtigen Sicherheitsfunktionen reicht das Etablieren einer STARTTLS-Verbindung an sich nicht aus, um Weitervermittlungsberechtigungen zu gewähren. Ein Test zeigt das: # sendmail -Am -v -t To: craig@crab.wrotethebook.com From: craig@rodent.wrotethebook.com Subject: Attempt to relay after successful TLS connection Ctrl-D craig@crab.wrotethebook.com... Connecting to chef.wrotethebook.com. via relay chef.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 22 Aug :01: >>> EHLO rodent.wrotethebook.com 250-chef.wrotethebook.com Hello rodent.wrotethebook.com [ ], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH DIGEST-MD5 CRAM-MD5 250-STARTTLS 250-DELIVERBY 250 HELP >>> STARTTLS Ready to start TLS >>> EHLO rodent.wrotethebook.com 250-chef.wrotethebook.com Hello rodent.wrotethebook.com [ ], pleased to meet you 8.5 Weitervermittlung auf der Grundlage der CA 317

336 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH EXTERNAL DIGEST-MD5 CRAM-MD5 250-DELIVERBY 250 HELP >>> MAIL SIZE= Sender ok >>> RCPT >>> DATA Relaying denied Need RCPT (recipient) >>> RSET Reset state craig... Connecting to local... craig... Sent Closing connection to chef.wrotethebook.com. >>> QUIT chef.wrotethebook.com closing connection Als Antwort auf den ersten EHLO-Befehl bietet der Server STARTTLS an. Der Client führt daraufhin einen STARTTLS-Befehl aus, und der Server antwortet, dass er bereit ist. Dies zeigt an, dass eine verschlüsselte Sitzung beginnt. Der zweite EHLO-Befehl ist der erste SMTP-Befehl in der verschlüsselten Sitzung. Ihm folgt ein MAIL From:- und ein RCPT To:- Befehl. Beachten Sie die Antwort auf den RCPT To:-Befehl. 3 Die Nachricht wird mit dem Fehler»Relaying denied«abgewiesen, obwohl sie mitten in einer verschlüsselten Sitzung kommt. Offensichtlich autorisiert TLS allein nicht die Vermittlung. Stattdessen muss der sendmail-administrator entscheiden, wann und wie die TLS-Authentifizierungsdaten benutzt werden sollen. Eine Möglichkeit, TLS-Daten zu benutzen, besteht über die access-datenbank. Die Makros ${verify} und ${cert_issuer} werden im Regelsatz Local_Relay_Auth verwendet, um die Weitervermittlung zu autorisieren. ${verify} enthält OK, wenn sendmail in der Lage ist, die CA-Signatur auf dem Zertifikat zu verifizieren, das von einer entfernten Site empfangen wurde. sendmail entnimmt den Distinguished Name der CA, die das Zertifikat signiert hat, dem Issuer-Feld des Zertifikats und speichert ihn im Makro ${cert_issuer}. Wenn ${verify} gleich OK ist, sucht sendmail in der access-datenbank nach einem CERTISSUER:-Eintrag, der dem Wert ${cert_issuer} entspricht. Wird ein Treffer gefunden, dann wird die Aktion ausgelöst, die durch den CERTISSUER:-Eintrag festgelegt wurde. Falls kein Treffer gefunden wird, wird die Verarbeitung normal fortge- 3 Da auf dem System, das die EHLO-Antwort zeigt, PIPELINING angeboten wird, werden einige SMTP-Befehle zusammen verschickt, um die TCP-Roundtrip-Zeiten zu verkürzen. Aus diesem Grund kommt in diesem Beispiel die Antwort auf den Befehl RCPT To: nach dem DATA-Befehl. Links 318 Kapitel 8: Den Mail-Transport sichern

337 Rechts setzt. Hier ist ein Beispiel für das Hinzufügen eines CERTISSUER:-Eintrags in die access- Datenbank: # cd /etc/mail # cat >> access CERTISSUER:/C=US/ST=Maryland/L=Gaithersburg/O=WroteTheBook/CN=chef.wrotethebook.com/ =craig@chef.wrotethebook.com RELAY Ctrl-D # makemap hash access < access Ist der eben gezeigte access-datenbankeintrag gegeben, dann werden Weitervermittlungsberechtigungen einer Site gewährt, die ein Zertifikat präsentiert, das von /C=US/ST=Maryland/L=Gaithersburg/O=WroteTheBook/CN=chef.wrotethebook.com/ =craig@chef. wrotethebook.com signiert wurde. /C=US/ST=Maryland/L=Gaithersburg/O=WroteThe- Book/CN=chef.wrotethebook.com/ =craig@chef.wrotethebook.com ist der vollständige DN der privaten CA, die in Rezept 8.1 erzeugt wurde. Deshalb ist es jedem Host erlaubt, Mail weiterzuvermitteln, der ein Zertifikat besitzt, das von Ihrer privaten CA signiert wurde. Ein DN kann nahezu jedes Zeichen enthalten. Einige Zeichen besitzen jedoch eine besondere Bedeutung für sendmail und andere sind schwierig in die access-datenbank einzugeben. Aus diesen Gründen verwendet der DN, der in der access-datenbank gespeichert ist, ein besonderes Format zum Speichern nicht-druckbarer Zeichen, Leerzeichen, Tabulatorzeichen, <, >, (, ), und +. Diese Zeichen werden mit ihren hexadezimalen Werten sowie einem vorangestellten Pluszeichen gespeichert. Aus einem Leerzeichen wird beispielsweise +20, eine ( wird zu +25. Nach dem Einfügen des CERTISSUER:-Eintrags in die access-datenbank führen Sie erneut den Test aus, der weiter vorn in diesem Abschnitt gezeigt wurde. Der Befehl RCPT To: liefert nun folgendes Ergebnis: >>> RCPT To:<craig@crab.wrotethebook.com> <craig@crab.wrotethebook.com>... Recipient ok Dem Client werden nun Weitervermittlungsberechtigungen gewährt, weil eine CA, die vertrauenswürdig genug ist, um die Weitervermittlung zu autorisieren, das Zertifikat des Clients signiert hat. Siehe auch Rezept 8.4 behandelt die STARTTLS-sendmail-Konfiguration, die als Grundlage für dieses Rezept verwendet wird. Die private CA, die in der Diskussion dieses Rezeptes erwähnt wurde, wird in Rezept 8.1 behandelt. In Kapitel 3 werden die traditionellen Techniken beschrieben, mit denen Weitervermittlungsberechtigungen gewährt werden können. Dies schließt auch die access-datenbank ein. Der Inhalt eines Zertifikats, einschließlich des Issuer-Feldes, wird in der Einführung dieses Kapitels behandelt. Das Buch sendmail erläutert die Benutzung der access-datenbank für STARTTLS in Abschnitt Weitervermittlung auf der Grundlage der CA 319

338 8.6 Weitervermittlung auf der Grundlage des Certificate-Subject Links Problem Sie wollen STARTTLS-Clients Weitervermittlungsberechtigungen auf der Grundlage der Identität des Clients gewähren. Die Identität des Clients ist durch das Zertifikat des Clients festgelegt. Lösung sendmail muss mit STARTTLS-Unterstützung kompiliert werden, und OpenSSL muss installiert sein. In den Rezepten 1.6 und 1.7 sowie in der Einführung in dieses Kapitel finden Sie weitere Informationen. Erzeugen Sie einen access-datenbankeintrag, indem Sie ein CERTISSUER:-Tag, gefolgt von dem DN der vertrauenswürdigen Certificate Authority, benutzen, um die CA zu identifizieren, die das Zertifikat des Clients signiert hat. Der Rückgabewert des CERTISSUER:-Eintrags muss das Schlüsselwort SUBJECT sein. Definieren Sie als Nächstes jeden Client, dem Weitervermittlungsberechtigungen gewährt werden sollen, mit einem CERTSUBJECT:-Eintrag in der access-datenbank. Das Schlüsselfeld dieser Einträge beginnt mit dem Tag CERTSUBJECT:, gefolgt vom DN des Clients. Der Rückgabewert ist das Schlüsselwort RELAY. Fügen Sie der STARTTLS-sendmail-Konfiguration die Funktion access_db hinzu. Hier sind Beispielkonfigurationszeilen: dnl Point to the CA certificate directory define(`confcacert_path', `/etc/mail/certs') dnl Point to the root CA's certificate define(`confcacert', `/etc/mail/certs/cacert.pem') dnl Point to the certificate used for inbound connections define(`confserver_cert', `/etc/mail/certs/cert.pem') dnl Point to the private key used for inbound connections define(`confserver_key', `/etc/mail/certs/key.pem') dnl Point to the certificate used for outbound connections define(`confclient_cert', `/etc/mail/certs/cert.pem') dnl Point to the private key used for outbound connections define(`confclient_key', `/etc/mail/certs/key.pem') dnl Enable the access database FEATURE(`access_db') Erstellen Sie entsprechend den Anweisungen aus Rezept 1.8 die Datei sendmail.cf neu. Installieren Sie die neue Konfiguration, und starten Sie sendmail neu. 320 Kapitel 8: Den Mail-Transport sichern

339 Rechts Diskussion Durch das erfolgreiche Etablieren einer STARTTLS-Sitzung wird nicht gleichzeitig das Relaying autorisiert. (In Rezept 8.5 finden Sie einen Test, der diese Aussage unterstreicht.) Allerdings können die Authentifizierungsdaten, die durch STARTTLS bereitgestellt werden, dazu verwendet werden, die Weitervermittlung über die access-datenbank zu steuern. Hier sind die access-datenbankeinträge, die die Weitervermittlung auf der Grundlage des Wertes im Subject-Feld des Client-Zertifikats autorisieren: CERTISSUER:/C=US/ST=Maryland/L=Gaithersburg/O=WroteTheBook/CN=chef.wrotethebook.com/ SUBJECT CERTSUBJECT:/C=US/ST=Maryland/L=Gaithersburg/O=WroteTheBook/CN=rodent.wrotethebook.com/ RELAY CERTSUBJECT:/C=US/ST=Maryland/L=Gaithersburg/O=WroteTheBook/CN=crab.wrotethebook.com/ RELAY Dieses Beispiel prüft sowohl das Issuer- als auch das Subject-Feld des Zertifikats, das vom Client präsentiert wird. Diese Werte werden durch den Regelsatz Local_Relay_Auth mit der access-datenbank verglichen, allerdings nur, wenn das Makro ${verify} den String OK enthält, der anzeigt, dass das Zertifikat erfolgreich durch sendmail überprüft wurde. Beide Felder werden nachgesehen, weil zuerst der CA vertraut werden muss, die das Zertifikat signiert und verifiziert, bevor dem Subject eines Zertifikats Vertrauen geschenkt werden kann. Falls ${verify} ein OK zurückliefert, sucht der Regelsatz Local_Relay_Auth nach einem CERTISSUER:-Eintrag, der den Distinguished Name aus dem Issuer-Feld des Zertifikats enthält. Wird ein Treffer gefunden und lautet die Aktion RELAY, dann wird die Weitervermittlung für alle Systeme mit einem Zertifikat autorisiert, das von der angegebenen CA signiert worden ist, wie in Rezept 8.5 beschrieben. Falls ein Treffer gefunden wird und die Aktion SUBJECT lautet, wird eine zweite Abfrage der access-datenbank vorgenommen. Dieses Mal sucht der Regelsatz nach einem CERTSUBJECT:-Eintrag, der den DN aus dem Subject-Feld des Zertifikats enthält. Wird dieser gefunden und enthält er die Aktion RELAY, dann wird die Weitervermittlung für den angegebenen Client erlaubt. Wird er nicht gefunden, dann wird die normale Verarbeitung fortgesetzt. Die Weitervermittlung kann dem Client immer noch durch eine der einfachen Methoden gewährt werden, die in Kapitel 3 beschrieben werden. STARTTLS bietet eine zusätzliche Methode zum Gewähren der Weitervermittlungsberechtigungen; es setzt die anderen traditionellen Methoden nicht außer Kraft. Ein Distinguished Name kann Zeichen enthalten, die eine besondere Formatierung erfordern, bevor der DN in die access-datenbank eingegeben wird. In der Diskussion von Rezept 8.5 finden Sie Informationen über dieses Thema. Siehe auch Die m4-konfigurationszeilen in diesem Rezept sind mit denjenigen aus Rezept 8.5 identisch. Beide nutzen die access-datenbank, und beide sind vollständige STARTTLS-Konfigurationen. In Rezept 8.5 finden Sie zusätzliche Informationen. In Kapitel 3 werden die 8.6 Weitervermittlung auf der Grundlage des Certificate-Subject 321

340 traditionellen Techniken beschrieben, die eingesetzt werden, um Vermittlungsberechtigungen zu gewähren, einschließlich der access-datenbank. Der Inhalt eines Zertifikats, einschließlich der Issuer- und Subject-Felder, wird in der Einführung dieses Kapitels behandelt. Das Buch sendmail erläutert die Benutzung der access-datenbank für START- TLS in Abschnitt Links 8.7 Nach außen gerichtete Verschlüsselung anfordern Problem Um zu verhindern, dass Mail, die an bestimmte Hosts gerichtet ist, im Klartext verschickt wird, wurden Sie gebeten, sendmail so zu konfigurieren, dass es Mail nur dann an die angegebenen Hosts versendet, wenn die Verbindung zufrieden stellend verschlüsselt wurde. Lösung Die Unterstützung für OpenSSL und STARTTLS ist Voraussetzung. In der Einführung und in Rezept 8.4 finden Sie weitere Einzelheiten zu diesen Grundkomponenten. Legen Sie die Stärke der Verschlüsselung fest, die für ausgehende Verbindungen erforderlich ist; benutzen Sie dazu einen TLS_Srv:-Eintrag in der access-datenbank. Das Schlüsselfeld jedes Eintrags ist das Tag TLS_Srv:, gefolgt vom Domainnamen oder der IP- Adresse des entfernten TLS-Servers, zu dem der lokale Host die Verbindung herstellen soll. Der Rückgabewert sollte das Schlüsselwort ENCR: enthalten, gefolgt von der Anzahl der Bits der Verschlüsselung, die bei einer Verbindung zum angegebenen entfernten Host verlangt werden. Erzeugen Sie eine sendmail-konfiguration, die STARTTLS und die access-datenbank unterstützt. Hier sind die Beispiel-STARTTLS-Definitionen und ein access_db-feature- Makro: dnl Point to the CA certificate directory define(`confcacert_path', `/etc/mail/certs') dnl Point to the root CA's certificate define(`confcacert', `/etc/mail/certs/cacert.pem') dnl Point to the certificate used for inbound connections define(`confserver_cert', `/etc/mail/certs/cert.pem') dnl Point to the private key used for inbound connections define(`confserver_key', `/etc/mail/certs/key.pem') dnl Point to the certificate used for outbound connections define(`confclient_cert', `/etc/mail/certs/cert.pem') dnl Point to the private key used for outbound connections define(`confclient_key', `/etc/mail/certs/key.pem') dnl Enable the access database FEATURE(`access_db') 322 Kapitel 8: Den Mail-Transport sichern

341 Rechts Erstellen und installieren Sie die Datei sendmail.cf neu, starten Sie dann sendmail erneut. In Rezept 1.8 finden Sie ein Beispiel dafür. Diskussion Die meiste Mail wird im Klartext verschickt, da die Mehrzahl der Systeme kein TLS einsetzt. Selbst wenn STARTTLS konfiguriert ist, sendet ein Host ausgehende Mail ohne Rücksicht auf die verwendete Verschlüsselungsstufe. Falls Sie eine Verschlüsselung für Mail verlangen, die an eine bestimmte Site gerichtet ist, müssen Sie sendmail über diese Anforderung in Kenntnis setzen. Die access-datenbank bietet Methoden, um sendmail über dieses Erfordernis zu informieren. Der TLS_Srv:-Eintrag definiert die STARTTLS-Anforderungen für ausgehende Verbindungen. Das Format des Eintrags lautet: TLS_Srv:name anforderung TLS_Srv: ist das erforderliche Tag. name ist der Name des entfernten TLS-Servers, der über den Domainnamen oder die IP-Adresse definiert werden kann. Wenn das name-feld leer bleibt, gilt der Eintrag für alle nach außen gerichteten Mail-Verbindungen. Da die meisten sendmail-systeme Mail an eine Vielzahl von entfernten Systemen senden, von denen einige STARTTLS haben und andere nicht, bleibt das Namensfeld fast niemals leer. anforderung ist das Schlüsselwort, das sendmail mitteilt, was von dieser TLS-Verbindung verlangt wird. Das Schlüsselwort ENCR: im anforderung-feld sagt sendmail, dass eine Verschlüsselung erforderlich ist. Dem Schlüsselwort folgt die minimale Anzahl der Verschlüsselungsbits, die verwendet werden müssen. Hier ist ein Beispiel-access-Datenbankeintrag: TLS_Srv:chef.wrotethebook.com ENCR:168 Dieser Eintrag teilt sendmail mit, dass eine Verbindung zu chef.wrotethebook.com mit wenigstens einer 168-Bit-Verschlüsselung verschlüsselt werden muss. 168 Bit ist die vorgegebene Verschlüsselungsstufe, die in unserer Beispiel-STARTTLS- Verbindung verwendet wird. Sie können die Verschlüsselungsstufe prüfen, die auf Ihrer Verbindung zum Einsatz kommt, indem Sie eine Testnachricht verschicken und sich den Received:-Header in der Nachricht anschauen. Zum Beispiel: Received: from rodent.wrotethebook.com (rodent.wrotethebook.com [ ]) by chef.wrotethebook.com (8.12.9/8.12.9) with ESMTP id h13gqdl (version=tlsv1/sslv3 cipher=edh-rsa-des-cbc3-sha bits=168 verify=ok) for Mon, 3 Feb :52: Dieser Header besagt, dass eine 168-Bit-Verschlüsselung verwendet wird (bits=168). Wäre der oben gezeigte TLS_Srv:-Eintrag auf rodent installiert, würde Mail zu chef gehen, da die Verbindung zwischen den beiden Systemen eine ausreichende Verschlüsselungsstufe aufweist. Würde die Verbindung zwischen den beiden Systemen dagegen nicht dem 8.7 Nach außen gerichtete Verschlüsselung anfordern 323

342 Minimalstandard für die Verschlüsselung entsprechen, dann würde der Client die Verbindung vor dem Senden von Mail abbrechen, wie dieser Test zeigt: # sendmail -Am -v -t To: craig@chef.wrotethebook.com From: craig@rodent.wrotethebook.com Subject: Test ENCR:168 with no TLS link Ctrl-D craig@chef.wrotethebook.com... Connecting to chef.wrotethebook.com. via esmtp chef.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 22 Aug :01: >>> EHLO rodent.wrotethebook.com 250-chef.wrotethebook.com Hello rodent.wrotethebook.com [ ], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH DIGEST-MD5 CRAM-MD5 250-DELIVERBY 250 HELP >>> QUIT chef.wrotethebook.com closing connection craig@chef.wrotethebook.com... Deferred: encryption too weak 0 less than 168 Closing connection to chef.wrotethebook.com. In diesem Fall schlägt das Anbieten von STARTTLS durch den Server fehl, während die access-datenbank des Clients eine 168-Bit-Verschlüsselung auf dieser Verbindung verlangt. Der Client beendet die Verbindung mit der Fehlermeldung»encryption too weak«. Diese Meldung zeigt die Anzahl der vom Server verwendeten Verschlüsselungsbits (in diesem Fall 0, weil TLS nicht gestartet ist) sowie die Anzahl, die vom Client verlangt wird (in diesem Beispiel 168). Der SMTP-Antwortcode dieser Fehlermeldung lautet 403, der DSN-Code ist Jeder Code beginnt mit einer 4, was andeutet, dass dies ein temporärer Fehler ist. Das Schlüsselwort»Deferred«in der Nachricht gibt an, dass sendmail versuchen wird, diese Nachricht während des nächsten Warteschlangendurchlaufs auszuliefern. Im Allgemeinen ist es korrekt, einen STARTTLS-Fehler als temporären Fehler zu behandeln. Das ist auch das Standardverhalten. Normalerweise wird ein Server in einem TLS_Srv:-Eintrag nur dann identifiziert, wenn der Server tatsächlich STARTTLS anbietet. Falls der Server nicht erfolgreich eine TLS-Verbindung zum Client herstellen kann, ist der Fehler wahrscheinlich nur temporär. Es liegt jedoch an Ihnen zu entscheiden, ob der Fehler als temporärer Fehler betrachtet werden sollte. Dem Anforderungsfeld in einem TLS_Srv:-Eintrag kann der String TEMP+ vorangestellt werden, um einen temporären Fehler zu signalisieren, oder der String PERM+, um einen dauerhaften Fehler zu wählen. Nehmen Sie beispielsweise an, die access-datenbank auf rodent enthielte den folgenden TLS_Srv:-Eintrag: TLS_Srv:chef.wrotethebook.com PERM+ENCR:168 Links 324 Kapitel 8: Den Mail-Transport sichern

343 Rechts Falls chef.wrotethebook.com nicht wenigstens eine 168-Bit-Verschlüsselung anbietet, beendet der Client die Sitzung und liefert die Mail an den Absender zurück. Es werden keine weiteren Versuche unternommen, die Mail auszuliefern. Der Absender sieht in der zurückgelieferten Nachricht die folgende Fehlermeldung: The following addresses had permanent fatal errors (reason: encryption too weak 0 less than 168) Benutzen Sie die Definition TLS_PERM_ERR als Alternative zum Hinzufügen von PERM+ zum Anforderungsfeld. Wird die folgende Zeile zur sendmail-konfiguration hinzugefügt, ändert sich die Vorgabe von einem temporären zu einem dauerhaften Fehler: define(`tls_perm_err') Bei dieser Einstellung müssen einzelne Aktionen mit Hilfe von TEMP+ als temporäre Fehler gekennzeichnet werden. Die Suche nach TLS_Srv:-access-Datenbankeinträgen erfolgt im Regelsatz tls_server, der durch den Client aufgerufen wird, sobald der Client bereit ist, den Befehl STARTTLS auszuführen. Der Regelsatz tls_server wird mit dem Wert aufgerufen, der durch ${verify} in seinem Workspace zurückgeliefert wird. Der Regelsatz tls_server unternimmt drei Versuche, eine TLS_Srv:-Übereinstimmung zu finden. Zuerst benutzt er den Regelsatz D, um einen TLS_Srv:-Eintrag zu finden, der dem von ${server_name} zurückgelieferten Hostnamen entspricht. Falls kein Treffer gefunden werden kann, verwendet er den Regelsatz A, um einen TLS_Srv:-Eintrag zu finden, der dem von ${server_addr} zurückgegebenen Wert entspricht. Gibt es immer noch keinen Treffer, dann sucht er nach einem TLS_Srv:- Eintrag mit einem leeren Namensfeld. Diese Suchen verarbeiten alle möglichen Treffer für einen bestimmten Domainnamen und eine bestimmte IP-Adresse. Beispielsweise würden bei einer Verbindung zu foo.bar.example.com mit der IP-Adresse die folgenden Suchanfragen in der angegebenen Reihenfolge durchgeführt werden, bis eine Übereinstimmung auftritt: TLS_Srv:foo.bar.example.com TLS_Srv:bar.example.com TLS_Srv:example.com TLS_Srv:com TLS_Srv: TLS_Srv: TLS_Srv: TLS_Srv:192 TLS_Srv: Der Regelsatz TLS_connection wird aufgerufen; ihm wird alles übergeben, was durch die Abfragen der access-datenbank zurückgeliefert wurde. TLS_connection verarbeitet dann auch das ENCR:-Anforderungsfeld und vergleicht die Anzahl der Bits in diesem Feld mit der Anzahl der Bits, die durch ${cipher_bits} zurückgegeben wurden. Ist der Wert aus dem Makro ${cipher_bits} kleiner als der Wert aus dem Anforderungsfeld, dann wird eine Fehlermeldung ausgegeben und die Verbindung beendet. 8.7 Nach außen gerichtete Verschlüsselung anfordern 325

344 Das m4-makro LOCAL_TLS_SERVER erlaubt es Ihnen, am Anfang der tls_server-verarbeitung eigene sendmail.cf-rewrite-regeln hinzuzufügen. Setzen Sie das Makro LOCAL_TLS_ SERVER an das Ende der Hauptkonfigurationsdatei, und listen Sie die eigenen Rewrite- Regeln nach dem Makro auf. Links Siehe auch Die Rezepte 8.8 und 8.9 behandeln verwandte access-datenbankeinträge. Speziell VERIFY: ist ein Schlüsselwort für eine alternative Aktion, das benutzt werden kann, um dieses Rezept zu implementieren. In Rezept 8.9 finden Sie Näheres über das Schlüsselwort VERIFY:. Die Rezepte 8.5 und 8.6 beschreiben ebenfalls, wie die access-datenbank mit STARTTLS benutzt wird. Das grundlegende STARTTLS-Rezept, auf dem dieses Rezept aufbaut, wird in Rezept 8.4 behandelt. Das Buch sendmail behandelt die Benutzung der access-datenbank mit STARTTLS in Abschnitt Eine nach innen gerichtete Verschlüsselung anfordern Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass die Verbindung zufrieden stellend verschlüsselt sein muss, bevor Mail von bestimmten Hosts akzeptiert wird. Lösung Alle Konfigurationen verlangen OpenSSL, wie in der Einführung beschrieben. Falls Ihr System noch nicht grundsätzlich dafür eingerichtet ist, beginnen Sie dort. Legen Sie die Verschlüsselungsstufe fest, die für eingehende Verbindungen verlangt wird; benutzen Sie dazu einen TLS_Clt:-Eintrag in der access-datenbank. Das Schlüsselfeld jedes Eintrags ist das Tag TLS_Clt:, gefolgt vom Domainnamen oder der IP-Adresse des entfernten TLS-Clients, der die Verbindung auslösen wird. Der Rückgabewert sollte das Schlüsselwort ENCR: enthalten, gefolgt von der Anzahl der Verschlüsselungsbits, die erforderlich sind, bevor eine Verbindung vom angegebenen entfernten Host akzeptiert wird. Fügen Sie der sendmail-konfiguration die STARTTLS-Definitionen sowie die Funktion access_db hinzu. Hier sind Beispiele für die Ergänzungen der Konfiguration: dnl Point to the CA certificate directory define(`confcacert_path', `/etc/mail/certs') dnl Point to the root CA's certificate define(`confcacert', `/etc/mail/certs/cacert.pem') dnl Point to the certificate used for inbound connections define(`confserver_cert', `/etc/mail/certs/cert.pem') 326 Kapitel 8: Den Mail-Transport sichern

345 Rechts dnl Point to the private key used for inbound connections define(`confserver_key', `/etc/mail/certs/key.pem') dnl Point to the certificate used for outbound connections define(`confclient_cert', `/etc/mail/certs/cert.pem') dnl Point to the private key used for outbound connections define(`confclient_key', `/etc/mail/certs/key.pem') dnl Enable the access database FEATURE(`access_db') Erstellen Sie entsprechend dem Beispiel aus Rezept 1.8 die Datei sendmail.cf neu, installieren Sie sie, und starten Sie dann sendmail neu. Diskussion Der access-datenbankeintrag TLS_Clt: benutzt das gleiche Format wie der Eintrag TLS_Srv:, der in der Diskussion von Rezept 8.7 behandelt wird. Alle Felder, die für den Eintrag TLS_Srv: beschrieben wurden name, anforderung, TEMP+ und PERM+, werden auf genau die gleiche Weise auch beim TLS_CLT:-Eintrag eingesetzt. Der Unterschied besteht darin, dass der TLS_Clt:-Eintrag vom Server verwendet wird, um auf besondere Anforderungen zu prüfen, bevor Mail vom Client akzeptiert wird. Das name-feld des TLS_Clt:- Eintrags definiert den Domainnamen oder die IP-Adresse des entfernten TLS-Clients. Wenn der Name oder die Adresse eines Clients einem TLS_Clt:-Eintrag entspricht, dann wird das anforderung-feld des Eintrags verwendet, um die Bedingungen zu definieren, die dem Client auferlegt werden, bevor die Mail akzeptiert wird. Ein Beispiel-TLS_Clt:- Eintrag lautet: TLS_Clt:rodent.wrotethebook.com ENCR:168 Dieser Eintrag teilt sendmail mit, dass eine Verbindung von rodent.wrotethebook.com mit wenigstens einer 168-Bit-Verschlüsselung verschlüsselt sein muss. Ist dies nicht der Fall, wird Mail von diesem Client abgewiesen, wie dieser Test des Clients rodent zeigt: # sendmail -Am -v -t To: craig@chef.wrotethebook.com From: craig@rodent.wrotethebook.com Subject: Test the TLS_Clt: entry Ctrl-D craig@chef.wrotethebook.com... Connecting to chef.wrotethebook.com. via esmtp chef.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 22 Aug :01: >>> EHLO rodent.wrotethebook.com 250-chef.wrotethebook.com Hello rodent.wrotethebook.com [ ], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 8.8 Eine nach innen gerichtete Verschlüsselung anfordern 327

346 250-AUTH DIGEST-MD5 CRAM-MD5 250-STARTTLS 250-DELIVERBY 250 HELP >>> STARTTLS Ready to start TLS >>> EHLO rodent.wrotethebook.com 250-chef.wrotethebook.com Hello rodent.wrotethebook.com [ ], pleased to meet you 250 ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH DIGEST-MD5 CRAM-MD5 250-DELIVERBY 250 HELP >>> MAIL encryption too weak 56 less than 168 Deferred: encryption too weak 56 less than 168 Closing connection to chef.wrotethebook.com. >>> QUIT chef.wrotethebook.com closing connection In diesem Test ist die Fehlermeldung»encryption too weak«die Antwort auf den Client- Befehl MAIL From:. Der Server prüft die TLS_Clt:-access-Datenbankeinträge im Regelsatz tls_client. Dieser Regelsatz wird an zwei unterschiedlichen Stellen im SMTP-Protokollaustausch aufgerufen. Zuerst wird er aufgerufen, wenn der STARTTLS-Befehl empfangen wird. Er wird erneut aufgerufen, wenn der Befehl MAIL From: empfangen wird. Wird der Regelsatz tls_client aufgerufen, dann wird ihm der Wert, der durch ${verify} zurückgeliefert wird, das Literal $ und eines der Schlüsselwörter STARTTLS oder MAIL übergeben. Der Regelsatz tls_client ist dem Regelsatz tls_server sehr ähnlich, der in Rezept 8.7 beschrieben wurde. tls_client benutzt zuerst den Regelsatz D, um nach einem TLS_Clt:- Eintrag zu suchen, der dem Wert entspricht, der in ${client_name} zu finden ist. Gibt es keine Übereinstimmung, dann benutzt er den Regelsatz A, um nach einem TLS_Clt:-Eintrag zu suchen, der der Adresse im Makro ${client_addr} entspricht. Gibt es immer noch keinen Treffer, dann sucht tls_client nach einem TLS_Clt:-Eintrag mit einem leeren Namensfeld. tls_client führt folgende Abfragen nach einer Verbindung von einem Client namens foo.bar.example.com mit der IP-Adresse durch, bis ein Treffer gefunden wird: TLS_Clt:foo.bar.example.com TLS_Clt:bar.example.com TLS_Clt:example.com TLS_Clt:com TLS_Clt: TLS_Clt: Links 328 Kapitel 8: Den Mail-Transport sichern

347 Rechts TLS_Clt: TLS_Clt:192 TLS_Clt: tls_client ruft dann TLS_connection auf und übergibt diesem Regelsatz alles, was er von der access-datenbank bezogen hat. Der Regelsatz TLS_connection prüft, ob die Verbindung den Anforderungen entspricht, die durch das TLS_Clt:-Record definiert wurden. Das m4-makro LOCAL_TLS_CLIENT bietet einen Einstieg in den Regelsatz tls_client. Benutzen Sie das Makro, um am Anfang der tls_client-verarbeitung eigene sendmail.cf- Rewrite-Regeln hinzuzufügen. Siehe auch Die Rezepte 8.7 und 8.9 behandeln verwandte access-datenbankeinträge. Speziell VERIFY: ist ein Schlüsselwort für eine alternative Aktion, das benutzt werden kann, um dieses Rezept zu implementieren. In Rezept 8.9 finden Sie Näheres zum Schlüsselwort VERIFY:. Die Rezepte 8.5 und 8.6 beschreiben ebenfalls, wie die access-datenbank mit STARTTLS benutzt wird. Das STARTTLS-Rezept, auf dem dieses Rezept aufbaut, wird in Rezept 8.4 behandelt. Das Buch sendmail behandelt den Einsatz der access-datenbank mit START- TLS in Abschnitt Ein verifiziertes Zertifikat anfordern Problem Sie wurden gebeten, sendmail so zu konfigurieren, dass es mit einem bestimmten Host nur dann Mail austauscht, wenn das Zertifikat, das dieser Host bereitstellt, überprüft worden ist. Lösung Auf dem System muss OpenSSL installiert sein, und sendmail muss mit STARTTLS- Unterstützung kompiliert worden sein, bevor Sie versuchen können, dieses Rezept zu implementieren. In der Kapiteleinführung sowie in Kapitel 1 finden Sie weitere Informationen über OpenSSL und über das Neukompilieren von sendmail. Legen Sie einen access-datenbankeintrag für jeden Host an, der ein verifiziertes Zertifikat bereitstellen soll. Benutzen Sie das Tag TLS_Clt:, falls der entfernte Host die Verbindung zum lokalen Host initiiert, oder das Tag TLS_Srv:, falls der lokale Host die Verbindung zum entfernten Host initiiert. Setzen Sie das Schlüsselwort VERIFY im Rückgabefeld ein, um ein bestätigtes Zertifikat vom entfernten System anzufordern. Fügen Sie einen Doppelpunkt und einen numerischen Wert hinter dem Schlüsselwort VERIFY hinzu, um zusätzlich zu dem verifizierten Zertifikat eine Verschlüsselungsstufe anzufordern. 8.9 Ein verifiziertes Zertifikat anfordern 329

348 Erzeugen Sie eine STARTTLS-sendmail-Konfiguration, die die Funktion access_db enthält. Hier sind Beispielzeilen, die der sendmail-konfiguration hinzugefügt werden könnten: dnl Point to the CA certificate directory define(`confcacert_path', `/etc/mail/certs') dnl Point to the root CA's certificate define(`confcacert', `/etc/mail/certs/cacert.pem') dnl Point to the certificate used for inbound connections define(`confserver_cert', `/etc/mail/certs/cert.pem') dnl Point to the private key used for inbound connections define(`confserver_key', `/etc/mail/certs/key.pem') dnl Point to the certificate used for outbound connections define(`confclient_cert', `/etc/mail/certs/cert.pem') dnl Point to the private key used for outbound connections define(`confclient_key', `/etc/mail/certs/key.pem') dnl Enable the access database FEATURE(`access_db') Erstellen Sie die Datei sendmail.cf neu, kopieren Sie die neue sendmail.cf nach /etc/mail, und starten Sie sendmail neu, wie in Rezept 1.8 gezeigt. Diskussion Wenn beide Endpunkte richtig konfiguriert sind, so dass sie STARTTLS unterstützen, verwendet sendmail TLS, um den Mail-Transport zu verschlüsseln, selbst wenn die Endpunkte keine verifizierten Zertifikate präsentieren. In diesem Kontext ist ein verifiziertes Zertifikat ein Zertifikat, das von einer CA signiert wurde, der sendmail vertraut. Falls sendmail die Signatur auf dem Zertifikat überprüfen kann, setzt es das Makro ${verify} auf OK. Wird ein Zertifikat empfangen, das nicht überprüft werden kann, wird ${verify} auf einen von mehreren möglichen Werten gesetzt, die in der Einführung in dieses Kapitel besprochen wurden. So ist etwa NO einer der Werte, die anzeigen, dass das Zertifikat nicht verifiziert wurde. TLS wird auch benutzt, um die Verbindung zu verschlüsseln, wenn ${VERIFY} auf NO gesetzt wurde, wie im unten gezeigten Received:-Header zu sehen ist: Return-Path: Received: from horseshoe.wrotethebook.com (horseshoe.wrotethebook.com [ ]) by chef.wrotethebook.com (8.12.9/8.12.9) with ESMTP id h14heqad (version=tlsv1/sslv3 cipher=edh-rsa-des-cbc3-sha bits=168 verify=no) for Tue, 4 Feb :40: Received: (from root@localhost) by horseshoe.wrotethebook.com (8.12.9/8.12.9) id h14hnn ; Tue, 4 Feb :49: Date: Tue, 4 Feb :49: Message-Id: < h14Hnn @horseshoe.wrotethebook.com> To: craig@chef.wrotethebook.com From: craig@horseshoe.wrotethebook.com Subject: Test self-signed certificate Der erste Received:-Header zeigt, dass die Verbindung mit einer 168-Bit-Verschlüsselung verschlüsselt und kein Zertifikat für horseshoe.wrotethebook.com verifiziert wurde. Dies lässt zwei Schlüsse zu: Links 330 Kapitel 8: Den Mail-Transport sichern

349 Rechts Erstens ist es möglich, STARTTLS zu benutzen, ohne eine Certificate Authority in Anspruch zu nehmen, falls Sie lediglich die Verbindung verschlüsseln wollen. Zweitens ist eine optionale Konfiguration erforderlich, um STARTTLS-Verbindungen auf solche Systeme mit nachprüfbaren Zertifikaten zu beschränken. Die VERIFY-Anforderung wird mit TLS_Clt: oder TLS_Srv: benutzt, um ein überprüftes (verifiziertes) Zertifikat zu verlangen. Wenn VERIFY angegeben wurde, muss der aktuelle Wert, der im Makro ${verify} gespeichert ist, OK sein. Ansonsten wird die Verbindung abgewiesen. Hier sind einige Beispieleinträge der access-datenbank: TLS_Clt:crab.wrotethebook.com TLS_Srv:smtp.wrotethebook.com TLS_Clt:horseshoe.wrotethebook.com VERIFY VERIFY:168 VERIFY:168 Der erste access-datenbankeintrag akzeptiert nur dann eingehende Mail von crab.wrotethebook.com, wenn das Zertifikat, das crab präsentiert, überprüft wurde. Die TLS_Clt:-Einträge werden durch den Regelsatz tls_client verarbeitet. In Rezept 8.8 finden Sie eine Beschreibung dieses Regelsatzes. Der zweite access-datenbankeintrag teilt sendmail mit, dass eine ausgehende Verbindung zum Server smtp.wrotethebook.com eine 168-Bit-Verschlüsselung benutzen muss und dass das Zertifikat, das durch den Server präsentiert wird, überprüft sein muss. Falls eine dieser Bedingungen nicht erfüllt wird, wird die Verbindung beendet. Der TLS_Srv:-Eintrag wird durch den Regelsatz tls_server verarbeitet, der in Rezept 8.7 behandelt wird. Der letzte Eintrag verlangt eine 168-Bit-Verschlüsselung und ein überprüftes Zertifikat für den TLS-Client horseshoe.wrotethebook.com. Wäre chef.wrotethebook.com mit diesem Eintrag konfiguriert worden, wäre die Mail, die den Received:-Header erzeugt hat, der am Anfang dieser Diskussion gezeigt wurde, nicht akzeptiert worden. Wie der Received:-Header verdeutlicht hat, benutzte horseshoe eine 168-Bit-Verschlüsselung, präsentierte aber kein überprüfbares Zertifikat. Ein Test, der von horseshoe aus durchgeführt wurde, zeigt die Wirkung, die durch das Hinzufügen dieses TLS_Clt:-Eintrags zur Konfiguration auf dem empfangenden Host erzielt wird: # sendmail -Am -v -t To: craig@chef.wrotethebook.com From: craig@horseshoe.wrotethebook.com Subject: Test VERIFY:168 Ctrl-D craig@chef.wrotethebook.com... Connecting to chef.wrotethebook.com. via esmtp chef.wrotethebook.com ESMTP Sendmail /8.12.9; Fri, 22 Aug :01: >>> EHLO horseshoe.wrotethebook.com 250-chef.wrotethebook.com Hello horseshoe.wrotethebook.com [ ], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 8.9 Ein verifiziertes Zertifikat anfordern 331

350 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH DIGEST-MD5 CRAM-MD5 250-STARTTLS 250-DELIVERBY 250 HELP >>> STARTTLS Ready to start TLS >>> EHLO horseshoe.wrotethebook.com 250-chef.wrotethebook.com Hello horseshoe.wrotethebook.com [ ], pleased to meet you 250 ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH DIGEST-MD5 CRAM-MD5 250-DELIVERBY 250 HELP >>> MAIL not authenticated Deferred: not authenticated Closing connection to chef.wrotethebook.com. >>> QUIT chef.wrotethebook.com closing connection Der STARTTLS-Befehl wird aufgerufen und akzeptiert. Der zweite EHLO-Befehl zeigt den erfolgreichen Start der verschlüsselten Sitzung an. Allerdings wird als Antwort auf den Befehl MAIL From: der Fehler»not authenticated«zurückgegeben, weil ein TLS_Clt:-Eintrag in der access-datenbank auf chef ein Zertifikat verlangte, das von einer vertrauenswürdigen Certificate Authority signiert wurde. Beachten Sie, dass die Antwortcodes 403 und in der Fehlermeldung benutzt wurden. Die 4 am Anfang der Codes zeigt an, dass es sich um einen temporären Fehler handelt. Als Antwort auf diese temporären Fehler reiht der Client die Nachricht in die Warteschlange ein und versucht, sie während nachfolgender Warteschlangendurchläufe auszuliefern. Standardmäßig sind Fehler, die durch eine VERIFY-Anforderung generiert werden, temporäre Fehler. Benutzen Sie PERM+, um aus dem Fehler einen dauerhaften Fehler zu machen, damit Sie verhindern, dass das entfernte System die Nachricht bei jedem Warteschlangendurchlauf erneut sendet. Zum Beispiel: TLS_Clt:horseshoe.wrotethebook.com PERM+VERIFY:168 In Rezept 8.7 finden Sie weitere Informationen über PERM+, TEMP+ und die Definition TLS_ PERM_ERR, die alle steuern, ob TLS-Fehler dauerhaft oder temporär sind. Links 332 Kapitel 8: Den Mail-Transport sichern

351 Rechts Der obige Test zeigt die Unterschiede zwischen Verschlüsselung und Authentifizierung. Eine Verschlüsselung kann selbst dann verwendet werden, wenn die Endpunkte sich nicht authentifiziert haben. Deshalb können besondere Berechtigungen, wie etwa die Weitervermittlung, nicht auf der Grundlage der verwendeten Verschlüsselungsstufe erweitert werden. Besondere Berechtigungen verlangen eine Authentifizierung. Glücklicherweise kann TLS bei Bedarf sowohl eine Verschlüsselung als auch eine Authentifizierung bereitstellen. Siehe auch Die Rezepte 8.7 und 8.8 bieten weitere Beispiele der TLS_Clt:- und TLS_Srv:-access- Datenbankeinträge. Die Rezepte 8.5 und 8.6 beschreiben andere Möglichkeiten, wie die access-datenbank mit STARTTLS genutzt werden kann. Dieses Rezept enthält m4- Befehle, die in Rezept 8.4 beschrieben wurden. Das Buch sendmail behandelt den Einsatz der access-datenbank mit STARTTLS in Abschnitt TLS für einen Empfänger anfordern Problem Sie wurden gebeten sicherzustellen, dass für Mails, die an bestimmte Empfänger adressiert sind, Verschlüsselung und Authentifizierung benutzt werden. Lösung Installieren Sie OpenSSL, und kompilieren Sie sendmail mit STARTTLS-Unterstützung, wie in der Einführung und in den Rezepten 1.6 und 1.7 beschrieben. Benutzen Sie die TLS_Rcpt:-access-Datenbankeinträge, um solche Empfänger zu definieren, die TLS-Sicherheit erfordern, und um die benötigte Sicherheitsstufe festzulegen. Das Schlüsselfeld der einzelnen Einträge enthält das Tag TLS_Rcpt: und die vollständige oder teilweise Adresse des Empfängers. Der Rückgabewert definiert die erforderliche Sicherheitsstufe und kann entweder das Schlüsselwort ENCR:, gefolgt von der Anzahl der verlangten Verschlüsselungsbits, oder das Schlüsselwort VERIFY, optional gefolgt von einer Anzahl Verschlüsselungsbits, sein. Fügen Sie die Funktion access_db und die STARTTLS-Definitionen zur sendmail-konfiguration hinzu. Hier sind die dazu benötigten Beispielzeilen: dnl Point to the CA certificate directory define(`confcacert_path', `/etc/mail/certs') dnl Point to the root CA's certificate define(`confcacert', `/etc/mail/certs/cacert.pem') dnl Point to the certificate used for inbound connections define(`confserver_cert', `/etc/mail/certs/cert.pem') dnl Point to the private key used for inbound connections 8.10 TLS für einen Empfänger anfordern 333

352 define(`confserver_key', `/etc/mail/certs/key.pem') dnl Point to the certificate used for outbound connections define(`confclient_cert', `/etc/mail/certs/cert.pem') dnl Point to the private key used for outbound connections define(`confclient_key', `/etc/mail/certs/key.pem') dnl Enable the access database FEATURE(`access_db') Erstellen Sie die Datei sendmail.cf neu, kopieren Sie die neue sendmail.cf nach /etc/mail, und starten Sie sendmail neu. In Rezept 1.8 finden Sie ein Beispiel. Diskussion Die access-datenbankeinträge TLS_Clt: und TLS_Srv:, die in den Rezepten 8.7, 8.8 und 8.9 verwendet werden, setzen minimale TLS-Sicherheitsanforderungen auf der Grundlage des Namens oder der Adresse des entfernten Hosts durch. sendmail prüft in TLS_CLT:-Einträgen für eingehende Verbindungen auf ${client_name} und ${client_addr} und in TLS_Srv:- Einträgen für ausgehende Verbindungen auf ${server_name} und ${server_addr}. Diese Einträge stellen sicher, dass Verbindungen zwischen den angegebenen entfernten Hosts und dem lokalen Host gesichert werden, sie garantieren jedoch nicht, dass Mail, die an einen bestimmten Benutzer adressiert ist, sicher ist. Es gibt keine Garantie, weil Mail Empfänger über verschiedene Wege erreichen kann von denen einige möglicherweise gesichert sind, andere jedoch nicht. Schauen Sie sich einige Beispiel-MX-Records an: wrotethebook.com. IN MX 10 chef.wrotethebook.com. wrotethebook.com. IN MX 20 rodent.wrotethebook.com. wrotethebook.com. IN MX 30 mail.example.com. Angesichts dieser drei MX-Records könnte Mail, die an gerichtet ist, über eine Verbindung zu chef, rodent oder mail.example.com gehen. Nehmen Sie nun an, dass chef und rodent STARTTLS-Unterstützung aufweisen, mail.example.com dagegen nicht. Mail, die von unserem System an gesandt wurde, würde verschlüsselt werden, wenn die Auslieferungsverbindung zu chef oder rodent aufgebaut werden würde; sie käme dagegen im Klartext, wenn die Verbindung zu mail.example.com bestehen würde. Wir betreiben mail.example.com nicht, wir können deshalb nicht die Art und Weise ändern, wie es konfiguriert ist wir können lediglich sicherstellen, dass Mail, die an gesandt wird, über eine angemessen verschlüsselte Verbindung läuft. Der folgende TLS_Rcpt:-Eintrag stellt sicher, dass Mail nur dann an geschickt wird, wenn der entfernte Host ein überprüftes Zertifikat präsentiert hat und die Verbindung eine 168-Bit-Verschlüsselung benutzt: VERIFY:168 Das grundlegende Format des TLS_Rcpt:-Eintrags lautet: TLS_Rcpt:empfänger anforderungen+suffix++suffix Der String TLS_Rcpt: ist das notwendige Tag für dieses Datenbank-Record. empfänger ist die vollständige oder teilweise -Adresse des Empfängers. Die Empfängeradresse kann folgendermaßen aussehen: Links 334 Kapitel 8: Den Mail-Transport sichern

353 Rechts Eine vollständige Adresse im Format Dieses Format entspricht einem bestimmten Benutzer auf einem bestimmten Host. wrotethebook.com ist ein Beispiel hierfür. Ein Hostname im Format host.domain; z. B. TLS_Rcpt:crab.wrotethebook.com. Jeder Benutzer auf dem angegebenen Host wird erfasst. Ein Domainname, um alle Benutzer auf allen Hosts der angegebenen Domain zu erfassen. Zum Beispiel würde TLS_Rcpt:wrotethebook.com allen Empfängern in der Domain wrotethebook.com entsprechen. Ein Benutzername, geschrieben in der Form z. B. Dieses Format entspricht allen Empfängern mit dem angegebenen Benutzernamen auf allen Hosts in allen Domains. Ein leeres Feld, das jeder möglichen Empfängeradresse entspricht. Dieses Format wird benutzt, um eine Standardsicherheitsanforderung für alle ausgehenden Mails zu definieren. Das anforderungen-feld definiert die minimalen Sicherheitsanforderungen, die erfüllt werden müssen, bevor Mail an den Empfänger gesandt wird. Die Schlüsselwörter ENCR oder VERIFY können im anforderungen-feld gesetzt werden, um eine Verschlüsselungsstufe oder ein geprüftes Zertifikat anzufordern. Beispielsweise verlangt ENCR:168 mindestens eine 168-Bit-Verschlüsselung, erfordert aber kein geprüftes Zertifikat vom entfernten Server. Das Schlüsselwort VERIFY verlangt ein geprüftes Zertifikat und kann optional mit einem numerischen Wert kombiniert werden, um ebenfalls eine Verschlüsselungsstufe anzufordern. Zum Beispiel verlangt VERIFY:168 ein geprüftes Zertifikat vom entfernten Server und eine 168-Bit-Verschlüsselung auf der Verbindung. Die Rezepte 8.7, 8.8 und 8.9 bieten Beispiele für die Schlüsselwörter ENCR und VERIFY. Der gerade gezeigte Beispiel-TLS_Rcpt:- Eintrag benutzt VERIFY:168, um eine Authentifizierung und Verschlüsselung anzufordern. Die Wirkung des Beispieleintrags ist zu sehen, wenn Mail, die an adressiert ist, an den Sicherungs-MX-Server mail.example.com geroutet wird: # sendmail -Am -v -t To: pat@wrotethebook.com From: david@wrotethebook.net Subject: Test TLS_Rcpt: Ctrl-D pat@wrotethebook.com... Connecting to mail.example.com. via esmtp mail.example.com ESMTP Sendmail /8.12.9; Wed, 5 Feb :33: >>> EHLO wrotethebook.net 250-mail.example.com Hello IDENT:24znrK/hAUFBK67n3St2d8DU/5bqb70s@chef [ ], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-EXPN 250-VERB 250-8BITMIME 250-SIZE 8.10 TLS für einen Empfänger anfordern 335

354 250-DSN 250-ETRN 250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 250-DELIVERBY 250 HELP >>> MAIL SIZE= Sender ok Deferred >>> RSET Reset state Closing connection to mail.example.com. >>> QUIT mail.example.com closing connection Der Sicherungs-MX-Server mail.example.com bietet in seiner Antwort auf den EHLO- Befehl keinen STARTTLS-Dienst an. Deshalb führt der Client keinen STARTTLS-Befehl aus. Stattdessen führt der Client den Befehl MAIL From: aus. Der Client sucht dann nach einem TLS_Rcpt:-Eintrag in der access-datenbank, findet ihn und beendet die Sitzung mit der Meldung: Deferred Diese Meldung zeigt an, dass die Mail in die Warteschlange geschoben wurde und beim nächsten Warteschlangendurchlauf gesendet werden wird. Das bedeutet, dass sendmail dieses Auslieferungsproblem als temporären Fehler behandelt. Standardmäßig werden die meisten TLS-Verbindungsprobleme als temporäre Fehler behandelt. Sie können dies ändern, indem Sie die Definition TLS_PERM_ERR in der Hauptkonfigurationsdatei benutzen. Oder Sie setzen den Vorgabewert für einen bestimmten TLS_Rcpt:-Eintrag außer Kraft, indem Sie PERM+ zu dem Eintrag hinzufügen. Beispielsweise würde der folgende Eintrag aus dem oben gezeigten Fehler einen dauerhaften Fehler machen: PERM+VERIFY:168 Das ist jedoch keine gute Idee. Fehler, die von TLS_Rcpt:-Einträgen verursacht werden, sollten temporäre Fehler sein. Der Fehler trat auf, weil die Verbindung an einen Sicherungs-MX-Server ging, der STARTTLS nicht unterstützt. Wenn die Mail während eines Warteschlangendurchlaufs erneut verschickt wird, geht sie wahrscheinlich an den primären MX-Server, der STARTTLS hat, und wird erfolgreich ausgeliefert. Wenn der Fehler zu einem dauerhaften Fehler gemacht wird, dann wird das Fehlerbehebungspotenzial unterlaufen, das der Warteschlangenverarbeitung von sendmail innewohnt. Es ist wahrscheinlicher, dass Sie TEMP+ benutzen, um einen Fehler als temporär zu kennzeichnen, falls die Vorgabe aus irgendeinem Grund lautet, dass TLS-Fehler mit der Definition TLS_PERM_ERR auf dauerhaft gesetzt worden sind. Die Rezepte 8.7, 8.8 und 8.9 behandeln TLS_PERM_ERR, PERM+ und TEMP+. Die anderen access-datenbankeinträge, die in diesem Kapitel behandelt wurden, benutzen ebenfalls die Schlüsselwörter ENCR:, VERIFY:, PERM+ und TEMP+. Allerdings besitzt das TLS_Rcpt:-Record mehr Optionen als diese anderen access-einträge. Dem anforderungen- Feld des TLS_Rcpt:-Eintrags können ein oder mehrere optionale Werte folgen. Diese Op- Links 336 Kapitel 8: Den Mail-Transport sichern

355 Rechts tionen werden als Suffixe bezeichnet, weil sie nach den Schlüsselwörtern ENCR oder VERIFY zum TLS_Rcpt:-Record hinzugefügt werden. Das erste Suffix wird nach einem einzelnen Pluszeichen angehängt (+), nachfolgende Suffixe werden mit zwei Pluszeichen (++) hinzugefügt. Mögliche Suffixe sind: CN:name Die Option CN prüft den allgemeinen Namen (Common Name; CN) des Subjects des Zertifikats, das vom Server präsentiert wurde. sendmail speichert den CN des Subjects im Makro ${cn_subject}. Wenn name angegeben wurde, muss der Wert von name dem Wert entsprechen, der im Makro ${cn_subject} gespeichert ist. Bleibt name leer, dann muss der Wert, der durch ${cn_subject} zurückgeliefert wird, dem Wert entsprechen, der von ${server_name} zurückgegeben wird. Das Makro ${server_ name} enthält den Hostnamen des entfernten Hosts, mit dem der Client gerade verbunden ist, wie durch einen Reverse Domain-Lookup der IP-Adresse ermittelt, die von TCP für die aktuelle Verbindung benutzt wird. CS:name Die Option CS vergleicht name mit dem Wert, der durch ${cert_subject} zurückgeliefert wird. Das Makro ${cert_subject} enthält den Distinguished Name aus dem Subject-Feld des Zertifikats, das vom entfernten Server präsentiert wird. DN und name müssen übereinstimmen. CI:name Die Option CI vergleicht name mit dem Wert, der von ${cert_issuer} zurückgeliefert wird. Das Makro ${cert_issuer} enthält den Distinguished Name aus dem Issuer- Feld des Zertifikats, das vom entfernten Server präsentiert wird. Der Wert in ${cert_ issuer} und der Wert im name-feld müssen übereinstimmen. Hier ist ein Beispiel-TLS_Rcpt:-Eintrag mit mehreren Suffixen: 4 TLS_Rcpt:pat@wrotethebook.com VERIFY:168+CN++CI:/C=US/ST=Maryland/L=Gaithersburg/ O=WroteTheBook/CN=chef.wrotethebook.com/ Dieser TLS_Rcpt:-Eintrag erfordert eine 168-Bit-Verschlüsselung und ein geprüftes Zertifikat vom entfernten Host. Der allgemeine Name des Subjects des Zertifikats muss gleich dem Hostnamen des Servers am anderen Ende der aktuellen Verbindung sein, und das Zertifikat muss durch die private CA signiert sein, die in Rezept 8.1 auf chef. wrotethebook.com angelegt wurde. Die verschiedenen Optionen, die für den TLS_Rcpt:-Eintrag verfügbar sind, erlauben es, mit den meisten möglichen Situationen umzugehen. Das heißt, es ist auch möglich, mit Hilfe des Local_tls_rcpt-Einstiegs in den Regelsatz einen eigenen Regelsatz zu erzeugen, um Ihre eigene TLS_Rcpt:-Verarbeitung durchzuführen. 4 Dies ist eine lange Zeile ohne Zeilenumbrüche TLS für einen Empfänger anfordern 337

356 Siehe auch Die Rezepte 8.7, 8.8 und 8.9 zeigen Beispiele für verwandte access-datenbankeinträge. Die Rezepte 8.5 und 8.6 beschreiben andere Möglichkeiten, die access-datenbank mit STARTTLS zu benutzen. Das Buch sendmail behandelt ${cn_subject} in Abschnitt , ${server_name} in , ${cert_subject} in , ${cert_issuer} in und TLS_Rcpt: in Links 8.11 Den STARTTLS-Dienst ablehnen Problem Normalerweise führt ein sendmail-system, das konfiguriert ist, STARTTLS auszuführen, den STARTTLS-Befehl bei jedem entfernten Host aus, der STARTTLS in seiner Antwort auf den EHLO-Befehl anbietet. Sie wurden gebeten zu verhindern, dass sendmail die START- TLS-Protokollerweiterung benutzt, wenn es mit ausgewählten entfernten Hosts kommuniziert. Lösung Stellen Sie sicher, dass Ihr System den grundlegenden OpenSSL- und STARTTLS-Konfigurationsanforderungen entspricht, die in der Einführung in dieses Kapitel und in Kapitel 1 beschrieben wurden. Fügen Sie Try_TLS:-Einträge zur access-datenbank hinzu, um die entfernten Sites zu identifizieren, für die STARTTLS deaktiviert werden soll. Das Format des Try_TLS:- Records lautet: Try_TLS:name NO Try_TLS: ist der erforderliche Tag-Wert. name ist der Hostname, Domainname oder die IP-Adresse der entfernten Site. NO ist der notwendige Rückgabewert. Fügen Sie die Funktion access_db und die STARTTLS-Definitionen der sendmail-konfiguration hinzu: dnl Point to the CA certificate directory define(`confcacert_path', `/etc/mail/certs') dnl Point to the root CA's certificate define(`confcacert', `/etc/mail/certs/cacert.pem') dnl Point to the certificate used for inbound connections define(`confserver_cert', `/etc/mail/certs/cert.pem') dnl Point to the private key used for inbound connections define(`confserver_key', `/etc/mail/certs/key.pem') dnl Point to the certificate used for outbound connections define(`confclient_cert', `/etc/mail/certs/cert.pem') dnl Point to the private key used for outbound connections 338 Kapitel 8: Den Mail-Transport sichern

357 Rechts define(`confclient_key', `/etc/mail/certs/key.pem') dnl Enable the access database FEATURE(`access_db') Erstellen Sie entsprechend den Anweisungen aus Rezept 1.8 die Datei sendmail.cf neu, kopieren Sie die neue sendmail.cf nach /etc/mail, und starten Sie sendmail neu. Diskussion Hier sind Beispiel-Try_TLS:-Einträge, die verhindern, dass STARTTLS mit zwei unterschiedlichen entfernten Hosts benutzt wird: Try_TLS:example.com Try_TLS:server.wrotethebook.org NO NO Mit diesen Try_TLS:-Einträgen wird TLS nicht verwendet, wenn eine Verbindung zum TLS-Server server.wrotethebook.org oder zu einem STARTTLS-Server in der Domain example.com hergestellt wird. Try_TLS:-Records werden durch den Regelsatz try_tls verarbeitet, der durch den Client aufgerufen wird, direkt bevor der Client den Befehl STARTTLS ausführt. try_tls benutzt zuerst den Regelsatz D, um nach einem Try_TLS:-Record zu suchen, das den Host- oder Domainnamen enthält, der durch ${server_name} zurückgeliefert wird. Wenn keine Übereinstimmung gefunden werden kann, benutzt er den Regelsatz A, um nach einem Try_TLS:-Record zu suchen, das die IP-Adresse enthält, die von ${server_addr} zurückgeliefert wurde. Kann immer noch keine Übereinstimmung gefunden werden, dann wird der Befehl STARTTLS aufgerufen. Wird eine Übereinstimmung gefunden, die den Wert NO zurückliefert, dann wird die Verbindung mit einem dauerhaften Fehler beendet. Das Makro LOCAL_TRY_TLS bietet einen Einstieg in den Regelsatz try_tls für Ihre eigenen angepassten Rewrite-Regeln. Try_TLS:-Einträge gelten nur für ausgehende Verbindungen, die eine Client-Funktion darstellen. In Rezept 8.12 finden Sie ein Beispiel für die Benutzung des SRV_Features:- Eintrags zum Kontrollieren der TLS-Server-Funktionen, die auf eingehenden Verbindungen angeboten werden. Siehe auch Rezept 8.4 erklärt die STARTTLS-Definitionen, die in dieser Konfiguration verwendet werden. Die Rezepte 8.5 bis 8.10 zeigen Beispiele für den Einsatz der access-datenbank mit STARTTLS. Das Buch sendmail behandelt ${server_addr} in Abschnitt , ${server_name} in und Try_TLS:-Records in Den STARTTLS-Dienst ablehnen 339

358 8.12 STARTTLS selektiv bekannt machen Links Problem Sie haben STARTTLS konfiguriert, wollen aber nicht die Verbindung für jeden entfernten Host verschlüsseln, der ebenfalls für STARTTLS konfiguriert ist. Sie möchten daher sendmail so konfigurieren, dass es STARTTLS nur ausgewählten Hosts anbietet. Lösung Stellen Sie sicher, dass das System den grundlegenden OpenSSL- und STARTTLS-Konfigurationsanforderungen entspricht, die in der Einführung und in Kapitel 1 beschrieben wurden. Erzeugen Sie Srv_Features:-access-Datenbankeinträge für alle Hosts, denen STARTTLS bekannt gemacht werden soll. Das Schlüsselfeld jedes Eintrags beginnt mit dem Tag Srv_Features:, gefolgt von dem Domainnamen, dem Hostnamen oder der IP-Adresse, die den verbindenden Host identifiziert. Der Rückgabewert der einzelnen Einträge ist der Buchstabe s. Fügen Sie die Funktion access_db zur STARTTLS-sendmail-Konfiguration hinzu. Hier sind das erforderliche FEATURE-Makro und Beispieldefinitionen: dnl Point to the CA certificate directory define(`confcacert_path', `/etc/mail/certs') dnl Point to the root CA's certificate define(`confcacert', `/etc/mail/certs/cacert.pem') dnl Point to the certificate used for inbound connections define(`confserver_cert', `/etc/mail/certs/cert.pem') dnl Point to the private key used for inbound connections define(`confserver_key', `/etc/mail/certs/key.pem') dnl Point to the certificate used for outbound connections define(`confclient_cert', `/etc/mail/certs/cert.pem') dnl Point to the private key used for outbound connections define(`confclient_key', `/etc/mail/certs/key.pem') dnl Enable the access database FEATURE(`access_db') Erstellen Sie entsprechend den Anweisungen aus Rezept 1.8 die Datei sendmail.cf neu, kopieren Sie die neue sendmail.cf nach /etc/mail, und starten Sie sendmail neu. Diskussion Benutzen Sie den Srv_Features:-access-Datenbankeintrag, um die erweiterten SMTP- Funktionen zu steuern, die verbindenden Hosts angeboten werden. Der Rückgabewert eines Srv_Features:-Eintrags ist ein oder mehrere Flags aus einzelnen Buchstaben, von denen einige anzeigen, ob ein erweiterter Dienst angeboten werden soll. (Wenn mehr als ein Flag zum Einsatz kommt, werden die einzelnen Flags durch Whitespace getrennt.) 340 Kapitel 8: Den Mail-Transport sichern

359 Rechts Flags in Kleinbuchstaben aktivieren SMTP-Erweiterungen und Flags in Großbuchstaben deaktivieren die Erweiterungen entsprechend. Das Flag s bietet selektiv STARTTLS an, und das Flag S blockiert selektiv das Anbieten von STARTTLS. Diese Flags sind für dieses Rezept von besonderem Interesse. 5 Nehmen Sie an, Sie wollen das Anbieten von STARTTLS auf Hosts in der Domain wrotethebook.com beschränken. Dazu könnten Sie folgende zwei Einträge in die access- Datenbank aufnehmen: Srv_Features:wrotethebook.com Srv_Features: s S In diesem Fall wird STARTTLS den Hosts in der Domain wrotethebook.com bekannt gemacht, wie das Flag s anweist. Das Flag S im zweiten Eintrag verhindert, dass START- TLS irgendeinem anderen Host angeboten wird. Ein leeres Namensfeld in einem Srv_Features:-Eintrag zeigt an, dass der Eintrag für jeden Host gilt, für den es keinen spezielleren Srv_Features:-Eintrag gibt. Im Prinzip erzeugt der zweite Eintrag eine Standardregelung für das Bekanntmachen von STARTTLS. Dieser zweite Eintrag ist erforderlich, weil die normale Vorgabe für sendmail darin besteht, STARTTLS anzubieten, wenn STARTTLS konfiguriert ist. Bei Fehlen eines passenden Srv_Features:- Eintrags kommt das Standardverhalten von sendmail zum Tragen. Alternativen Das Ändern des Standardverhaltens von sendmail mit einem DAEMON_OPTIONS-Makro stellt eine Alternative zur Benutzung des oben beschriebenen zweiten Srv_Features:-Eintrags dar. Sie könnten ein DAEMON_OPTIONS-Makro hinzufügen, das den Modifikator M=S zur sendmail-konfiguration hinzufügt. Wenn Sie beispielsweise die folgenden Zeilen zur Konfiguration hinzufügen, verhindern Sie, dass sendmail STARTTLS jedem verbindenden Host anbietet: dnl Do not advertise STARTTLS DAEMON_OPTIONS(`Name=MTA, M=S') Nach dem Ändern des Vorgabewertes könnten Sie mit einem einzelnen Srv_Features:- Eintrag die Vorgaben für die Hosts in der Domain wrotethebook.com außer Kraft setzen: Srv_Features:wrotethebook.com s Dieser alternative Ansatz funktioniert. Ich ziehe es jedoch vor, beide Regelungen in die access-datenbank zu setzen. Ich denke, dass es für andere einfacher wird, genau zu verstehen, was die Konfiguration macht, wenn sich beide Regelungen an einer Stelle befinden. Die Beispiele in diesem Abschnitt gehen davon aus, dass Sie das Anbieten auf ausgewählte Hosts beschränken wollen. Das Gegenteil kann aber auch der Fall sein. Sie wollen den meisten Hosts möglicherweise STARTTLS anbieten und möchten das Anbieten nur für bestimmte Hosts blockieren, mit denen Sie Probleme haben. In diesem Fall würden 5 Alle Flags werden in Tabelle 7-2 beschrieben, die Sie in der Diskussion von Rezept 7.9 finden STARTTLS selektiv bekannt machen 341

360 die speziellen Srv_Features:-Einträge das Flag S benutzen. Es wären keine Standard- Srv_Features:-Einträge erforderlich, weil das normale sendmail-verhalten darin besteht, STARTTLS anzubieten. Links Siehe auch Rezept 8.4 beschreibt die grundlegende STARTTLS-Konfiguration, die erledigt werden muss, bevor dieses Rezept implementiert wird. Rezept 7.9 und Rezept 8.13 bieten weitere Beispiele für die Benutzung des Srv_Features:-Records. Die Rezepte 8.5 bis 8.13 zeigen, wie die access-datenbank mit STARTTLS eingesetzt wird. Das Buch sendmail behandelt den Srv_Features:-Eintrag in Abschnitt Client-Zertifikate anfordern Problem Standardmäßig verlangt STARTTLS nicht von einem TLS-Client, ein Zertifikat zu präsentieren. Sie wollen sendmail so konfigurieren, dass es von ausgewählten TLS-Clients Zertifikate anfordert. Lösung Stellen Sie sicher, dass das System den grundlegenden OpenSSL- und STARTTLS-Konfigurationsanforderungen genügt, die in der Einführung und in Kapitel 1 beschrieben werden. Erzeugen Sie Srv_Features:-access-Datenbankeinträge für alle Clients, die ein Zertifikat präsentieren müssen. Das Schlüsselfeld jedes Eintrags ist das Tag Srv_Features:, gefolgt vom Domainnamen, Hostnamen oder der IP-Adresse des gewählten Clients. Der Rückgabewert des Eintrags ist der Buchstabe v. Fügen Sie die Funktion access_db zur STARTTLS-sendmail-Konfiguration hinzu. Hier sind das erforderliche FEATURE-Makro und einige Beispieldefinitionen: dnl Point to the CA certificate directory define(`confcacert_path', `/etc/mail/certs') dnl Point to the root CA's certificate define(`confcacert', `/etc/mail/certs/cacert.pem') dnl Point to the certificate used for inbound connections define(`confserver_cert', `/etc/mail/certs/cert.pem') dnl Point to the private key used for inbound connections define(`confserver_key', `/etc/mail/certs/key.pem') dnl Point to the certificate used for outbound connections define(`confclient_cert', `/etc/mail/certs/cert.pem') dnl Point to the private key used for outbound connections define(`confclient_key', `/etc/mail/certs/key.pem') dnl Enable the access database FEATURE(`access_db') 342 Kapitel 8: Den Mail-Transport sichern

361 Rechts Erstellen Sie entsprechend den Anweisungen aus Rezept 1.8 die Datei sendmail.cf neu, kopieren Sie die neue sendmail.cf nach /etc/mail, und starten Sie sendmail neu. Diskussion Srv_Features:-Einträge steuern die Art und Weise, in der ein Server mit seinen Clients interagiert. In Rezept 8.12 sowie in Rezept 7.9 finden Sie weitere allgemeine Informationen über den Srv_Features:-Eintrag. Benutzen Sie den Rückgabewert v mit einem Srv_Features:-Eintrag, um das Zertifikat des TLS-Clients anzufordern. Benutzen Sie den Rückgabewert V, um zu verhindern, dass sendmail nach dem Zertifikat des Clients fragt. Wenn Sie den folgenden Eintrag zur access-datenbank hinzufügen, fordern Sie ein Zertifikat von allen Hosts an, die sich aus der Domain dialin.wrotethebook.com mit dem lokalen Host verbinden: Srv_Features:dialin.wrotethebook.com Der Srv_Features:-Eintrag an sich tut nichts mit dem Client-Zertifikat. Er fordert lediglich an, dass der Client ein Zertifikat präsentiert, das dann für besondere Aufgaben, etwa das Autorisieren der Weitervermittlung, eingesetzt werden kann. Wird das Zertifikat für einen besonderen Zweck benutzt, ist eine zusätzliche Konfiguration erforderlich, wie in den anderen Rezepten dieses Kapitels zu sehen ist. Siehe auch Rezept 8.4 beschreibt die STARTTLS-Definitionen, die in dieser Konfiguration zum Einsatz kommen. Rezept 7.9 bietet weitere Beispiele für die Benutzung des Srv_Features:- Records. Die Rezepte 8.5, 8.6 und 8.9 verwenden Client-Zertifikate, um Weitervermittlungsberechtigungen zu gewähren. Das Buch sendmail behandelt den Srv_Features:- Eintrag in Abschnitt v 8.13 Client-Zertifikate anfordern 343

362 FirstLeft. Kapitel 9 KAPITEL 9 Die Warteschlange verwalten 9.0 Einführung Die Warteschlange (Queue) ist die Stelle, an der Mail aufbewahrt wird, bis sie erfolgreich ausgeliefert werden kann. Die Warteschlange nimmt die Mail für eine spätere Auslieferung auf, falls während des Auslieferungsvorgangs ein temporärer Fehler aufgetreten ist. Die meisten sendmail-administratoren haben den Text»Deferred«bereits in einer Fehlermeldung gesehen und wissen, dass dies bedeutet, dass die Mail in der Warteschlange bleibt, bis diese das nächste Mal verarbeitet wird. Mail wird auch dann in die Warteschlange verschoben, wenn die Systemlast den Lastmittelwert überschreitet, der durch die sendmail.cf-option QueueLA definiert wird, und wenn bestimmte Auslieferungsmodi zum Einsatz kommen. Die Warteschlangenverarbeitung ist eine wichtige Komponente beim Schaffen eines robusten, zuverlässigen Mail-Auslieferungssystems. Jede Mail-Nachricht in der Warteschlange kann durch bis zu vier Warteschlangendateien repräsentiert werden: Die Datei df enthält den Nachrichten-Body. Die Datei qf enthält die Nachrichten-Header und die Warteschlangensteuerinformationen, die benötigt werden, um die Nachricht auszuliefern. Die Datei xf ist eine temporäre Datei, die ein Transkript aller Fehlermeldungen enthält, die sendmail empfängt, während es versucht, die Nachricht auszuliefern. Alle Fehlermeldungen, die in der Datei xf gesammelt werden, werden an den Absender zurückgeschickt; die Datei xf wird nach dem Auslieferungsversuch gelöscht. Die Datei tf ist eine temporäre Arbeitsdatei, die sendmail verwendet, um die aktualisierte qf-datei zu erzeugen. Die Warteschlangensteuerinformationen in der Datei qf werden immer dann aktualisiert, wenn eine Nachricht erneut in die Warteschlange gelangt. Alle Änderungen an diesen Informationen finden in der Datei tf statt, um die Datei qf zu schützen. Nachdem die Datei tf erfolgreich aktualisiert wurde, wird sie in qf umbenannt. 344 Kapitel 9: Die Warteschlange verwalten

363 Rechts Von den vier Dateitypen sind nur die Dateien df und qf langfristige»bewohner«der Warteschlange. Der Inhalt dieser Dateien, selbst der der qf-dateien, die Warteschlangensteuerinformationen enthalten, hat keine Auswirkungen auf die Rezepte in diesem Kapitel. Deshalb werden wir den Inhalt dieser Dateien auch nicht näher beschreiben. Falls Sie sich für die Interna der Datei qf interessieren, lesen Sie Abschnitt des sendmail-buches. df, qf, xf und tf sind Dateinamenpräfixe, die die Art der Warteschlangendatei identifizieren. Der vollständige Name einer Warteschlangendatei besteht aus einem dieser Präfixe, gefolgt vom eindeutigen Warteschlangenidentifikator, der mit einer individuellen Nachricht verknüpft ist. Beispielsweise listet der folgende ls-befehl alle df-dateien in der Warteschlange auf: # ls df* dfg7kek4w dfg8q82lkj dfg8rdyb6v Dagegen listet dieser ls-befehl alle Dateien auf, die mit einer bestimmten Mail-Nachricht verknüpft sind: # ls *g8q82lkj dfg8q82lkj qfg8q82lkj Diese ls-befehle dienen dazu, die Struktur eines Warteschlangendateinamens zu illustrieren. ls wird normalerweise nicht dazu eingesetzt, die Warteschlange zu untersuchen. Benutzen Sie den Befehl mailq, wenn Sie sehen wollen, welche Nachrichten sich in der Warteschlange befinden. Standardmäßig benutzt die sendmail.cf-konfiguration das Verzeichnis /var/spool/mqueue für die Warteschlangendateien. Die submit.cf-konfiguration verwendet /var/spool/clientmqueue als Vorgabewert. Allerdings enthalten einige der Rezepte in diesem Buch Befehle, die die vorgegebene Warteschlange ändern und eine komplexere und flexiblere Warteschlangenverzeichnisstruktur für die sendmail.cf-konfiguration erzeugen. Diese Befehle können auch in der submit.cf-konfiguration eingesetzt werden. Die Warteschlange kann sofort verarbeitet werden, indem sendmail mit der Kommandozeilenoption -q ausgeführt wird. Typischerweise wird jedoch die Option -q mit einem Zeitintervallargument angegeben, das sendmail veranlasst, die Warteschlange periodisch zu verarbeiten. Beispielsweise würde -q15m die Warteschlange alle 15 Minuten verarbeiten. Zeitliche Planung, und zwar nicht nur dessen, wie oft die Warteschlange verarbeitet wird, ist Teil der Natur einer Warteschlange. Im Grunde wird eine Warteschlange angelegt, um nicht ausgelieferte Nachrichten für eine bestimmte Zeitspanne zu speichern. Eine sendmail-warteschlange besitzt auch Timer dafür, wie oft der Absender gewarnt wird, dass die Nachricht immer noch nicht ausgeliefert wurde und in der Warteschlange wartet. Diese Timer können für normale, dringende und nicht dringende Nachrichten konfiguriert werden. Die Timer-Optionen in der Datei sendmail.cf, die damit zu tun haben, wie lange die Nachrichten sich in der Warteschlange befinden, sind: Einführung 345

364 Timeout.queuereturn Die Option Timeout.queuereturn definiert die Zeitdauer, für die eine Nachricht in der Warteschlange verbleibt, bevor sie als nicht auslieferbar an den Absender zurückgeschickt wird. Die Option wird durch die Definition confto_queuereturn konfiguriert. Dieser Timer, der standardmäßig auf fünf Tage (5d) gesetzt wird, gilt für die meisten Mail-Nachrichten. Timeout.queuereturn.normal Diese Option definiert die Zeitdauer, für die eine Nachricht, die einen Precedence: normal-header enthält, in der Warteschlange bleibt, bevor sie als nicht auslieferbar an den Absender zurückgeschickt wird. Diese Option wird durch die Definition confto_queuereturn_normal konfiguriert. Der Vorgabewert sind fünf Tage (5d). Timeout.queuereturn.urgent Diese Option definiert die Zeitdauer, für die eine Nachricht, die einen Precedence: urgent-header enthält, in der Warteschlange bleibt, bevor sie als nicht auslieferbar an den Absender zurückgeschickt wird. Diese Option wird durch die Definition confto_queuereturn_urgent konfiguriert. Der Vorgabewert sind zwei Tage (2d). Timeout.queuereturn.non-urgent Diese Option definiert die Zeitdauer, für die eine Nachricht, die einen Precedence: non-urgent-header enthält, in der Warteschlange bleibt, bevor sie als nicht auslieferbar an den Absender zurückgeschickt wird. Diese Option wird durch die Definition confto_queuereturn_nonurgent konfiguriert. Der Vorgabewert sind sieben Tage (7d). Timeout.queuewarn Die Option Timeout.queuewarn definiert die Zeitdauer, die sendmail abwartet, bevor es eine Warnmeldung absendet, die dem Absender mitteilt, dass eine Nachricht immer noch nicht ausgeliefert wurde. Diese Option wird durch die Definition confto_ QUEUEWARN konfiguriert. Dieser Timer, der standardmäßig auf vier Stunden gesetzt ist (4h), gilt für die meisten Mail-Nachrichten. Timeout.queuewarn.normal Diese Option definiert die Zeitdauer, die sendmail abwartet, bevor es eine Warnmeldung sendet, die dem Absender mitteilt, dass eine Nachricht mit einem Precedence: normal-header immer noch nicht ausgeliefert wurde. Diese Option wird durch die Definition confto_queuewarn_normal konfiguriert. Der Vorgabewert sind vier Stunden (4h). Timeout.queuewarn.urgent Diese Option definiert die Zeitdauer, die sendmail wartet, bevor es eine Warnmeldung sendet, die dem Absender mitteilt, dass eine Nachricht mit einem Precedence: urgent- Header immer noch nicht ausgeliefert wurde. Diese Option wird durch die Definition confto_queuewarn_urgent konfiguriert. Der Vorgabewert ist eine Stunde (1h). Timeout.queuewarn.non-urgent Diese Option definiert die Zeitdauer, die sendmail wartet, bevor es eine Warnmeldung sendet, die dem Absender mitteilt, dass eine Nachricht mit einem Precedence: non-urgent-header immer noch nicht ausgeliefert wurde. Diese Option wird durch Links 346 Kapitel 9: Die Warteschlange verwalten

365 Rechts die Definition confto_queuewarn_nonurgent konfiguriert. Der Vorgabewert sind 12 Stunden (12h). Als Beispiel würde durch das Hinzufügen der folgenden confto_queuereturn-definition zur sendmail-konfiguration die Zeitdauer, die eine normale Nachricht in der Warteschlange verbleiben darf, bevor sie als nicht auslieferbar an den Absender zurückgesendet wird, auf drei Tage verkürzt werden: dnl Return normal messages after three days in the queue define(`confto_queuereturn', `3d') Die Zeitplanung könnte auf jedem System geändert werden. Die Rezepte in diesem Kapitel sind jedoch vor allem für große Sites mit großen Warteschlangen von Interesse. Auf den meisten Systemen ist die Warteschlange so klein, dass die Zeit, die für die Verarbeitung der Warteschlange aufgewandt wird, vernachlässigt werden kann. Wenn die Warteschlange hingegen auf Zehntausende von Nachrichten anwächst, dann kann bei jedem Warteschlangendurchlauf eine bedeutende Zeit vergehen. Falls Ihr System nur eine kleine Warteschlange mit einigen Hundert oder Tausend Nachrichten hat, die in der Warteschlange vorgehalten werden, dann ist die vorgegebene sendmail-konfiguration wahrscheinlich ausreichend. Wächst Ihre Warteschlange dagegen auf Zehntausende von Nachrichten an, sollten Sie weiterlesen. 9.1 Mehrere Warteschlangen anlegen Problem Sie wurden gebeten, mehrere Mail-Warteschlangen anzulegen, die sich über mehrere physische Geräte erstrecken, um eine große Anzahl von Mails effizient zu verarbeiten. Lösung Bereiten Sie die physischen Geräte vor, die die Mail-Warteschlangen aufnehmen sollen. Jedes Gerät muss entsprechend den Anforderungen Ihres Systems formatiert sein und ein Dateisystem enthalten, das mit Ihrem Betriebssystem kompatibel ist. Eine Erläuterung, wie Sie Geräte formatieren und Unix-Dateisysteme aufbauen, würde den Rahmen dieses Buches sprengen. Lesen Sie deshalb Unix-System-Administration, zweite Auflage, von Æleen Frisch (O Reilly). Legen Sie neue Verzeichnisse an, die für die verschiedenen Mail-Warteschlangen benötigt werden: # cd /var/spool/mqueue # mkdir queue.1 queue.2 queue.3 # chmod 700 queue.? Mounten Sie die physischen Geräte an den neu erzeugten Verzeichnissen. Dieses Beispiel benutzt Linux-Gerätenamen: 9.1 Mehrere Warteschlangen anlegen 347

366 # mount /dev/hda1 /var/spool/mqueue/queue.1 # mount /dev/hdb2 /var/spool/mqueue/queue.2 # mount /dev/hdd1 /var/spool/mqueue/queue.3 Bearbeiten Sie die Datei /etc/fstab oder /etc/vfstab so, dass die Geräte bei jedem Booten gemountet werden. Hier sind Beispiel-Mount-Punkte, die in einer /etc/fstab-datei auf einem Red-Hat-Linux-System definiert wurden: /dev/hda1 /var/spool/mqueue/queue.1 ext3 defaults 1 2 /dev/hdb2 /var/spool/mqueue/queue.2 ext3 defaults 1 2 /dev/hdd1 /var/spool/mqueue/queue.3 ext3 defaults 1 2 Links Beachten Sie, dass diese Zeilen zur aktuellen /etc/fstab-datei hinzugefügt wurden. Das Überschreiben oder Löschen der existierenden Einträge in der Datei fstab könnte das System ernstlich beeinträchtigen sogar so weit, dass es sich unter Umständen nicht mehr starten lässt. Seien Sie vorsichtig, wenn Sie Zeilen in die Datei fstab einfügen. Fügen Sie die Definition QUEUE_DIR zur sendmail-konfiguration hinzu, um die neuen Warteschlangenverzeichnisse zu benutzen. Hier ist ein Beispiel für diese Definition: dnl Declare the queue directory path define(`queue_dir', `/var/spool/mqueue/queue.*') Erstellen Sie die Datei sendmail.cf, kopieren Sie sie nach /etc/mail/sendmail.cf, und starten Sie sendmail neu, wie in Rezept 1.8 gezeigt. Diskussion Standardmäßig verwendet sendmail ein einziges Warteschlangenverzeichnis, das in der Datei sendmail.cf normalerweise mit /var/spool/mqueue benannt ist. Der Pfadname des Warteschlangenverzeichnisses wird durch die Option QueueDirectory definiert. Ein grep einer einfachen sendmail-konfiguration zeigt den Vorgabewert: $ grep QueueDirectory generic-linux.cf O QueueDirectory=/var/spool/mqueue Benutzen Sie die m4-definition QUEUE_DIR, um den Wert der Option QueueDirectory zu setzen. Nach dem Neukonfigurieren von sendmail mit der QUEUE_DIR-Definition, das in der Lösung gezeigt wurde, zeigt ein weiterer grep-befehl die Änderung: $ grep QueueDirectory sendmail.cf O QueueDirectory=/var/spool/mqueue/queue.* Dieses Rezept setzt ein besonderes Pfadnamenformat ein. Der Asterisk am Ende des Pfadnamens zeigt an, dass es mehrere Warteschlangenverzeichnisse gibt. Es kann nur ein Asterisk verwendet werden, um mehrere Warteschlangen anzuzeigen, und er muss am Ende des Pfadnamens stehen. Bei der oben dargestellten QueueDirectory-Option sucht sendmail nach Warteschlangen mit Namen, die mit /var/spool/mqueue.queue. beginnen, gefolgt von einem weiteren Zeichenstring. 348 Kapitel 9: Die Warteschlange verwalten

367 Rechts Dieses Rezept mountet ein eigenes physisches Gerät an jedes Warteschlangenverzeichnis. Das ist zwar nicht unbedingt notwendig, illustriert aber einen gebräuchlichen Einsatzfall für mehrere Verzeichnisse. Das Platzieren mehrerer Verzeichnisse auf ein einzelnes Gerät bietet eine Leistungssteigerung; beim Einsatz mehrerer Geräte kann sogar noch eine größere Leistungssteigerung erreicht werden. Das Buch sendmail Performance Tuning von Nick Christenson (Addison Wesley) liefert einen Einblick in diese Leistungsaspekte. Mehrere Warteschlangen, wie sie in diesem Rezept implementiert werden, erhöhen die Verarbeitungsgeschwindigkeit großer Warteschlangen. Falls sich bei Ihrem Server manchmal mehr als Nachrichten in der Warteschlange befinden, könnte Rezept 9.1 helfen, die Server-Leistung und -Zuverlässigkeit zu verbessern. Beachten Sie, dass es nicht notwendig ist, mit QUEUE_DIR mehrere Warteschlangen zu erzeugen, um einfach Mail in bestimmten Warteschlangen zu organisieren. Die Unterverzeichnisse qf, df und xf organisieren die Warteschlange anhand der Warteschlangendateitypen, wie in Rezept 9.2 beschrieben. Warteschlangengruppen (Queue Groups), die in Rezept 9.3 besprochen werden, organisieren Mail in separaten Warteschlangen. Bei den getrennten Warteschlangen, die für Warteschlangengruppen eingesetzt werden, kann es sich um Unterverzeichnisse einer einzelnen Standardwarteschlange handeln. Obwohl die Unterverzeichnisse qf, df und xf sowie Warteschlangengruppen mit mehreren Warteschlangen benutzt werden können, die durch den Befehl QUEUE_DIR definiert wurden, verlangen sie diesen Befehl nicht. Siehe auch Rezept 9.2 beschreibt eine weitere Technik für das Anlegen mehrerer Warteschlangen, die mit diesem Rezept kombiniert werden kann. Das Buch sendmail behandelt mehrfache Warteschlangen in Abschnitt Die Option QueueDirectory wird im Sendmail Installation and Operations Guide erläutert, den Sie im Verzeichnis doc/op der sendmail-distribution finden. 9.2 Die Unterverzeichnisse qf, df und xf benutzen Problem Es ist eine besondere Konfiguration erforderlich, um mehrere Mail-Warteschlangen für verschiedene Warteschlangendateitypen zu benutzen. Lösung Legen Sie eine neue Warteschlangenverzeichnisstruktur mit getrennten Verzeichnissen für die Warteschlangendateien df, qf und xf an. Hier ist ein Beispiel: # umask 077 # mkdir /var/spool/mqueue.new # cd /var/spool/mqueue.new # mkdir df qf xf 9.2 Die Unterverzeichnisse qf, df und xf benutzen 349

368 Verschieben Sie das alte Warteschlangenverzeichnis an eine andere Stelle, damit der neuen Warteschlangenverzeichnisstruktur der Pfadname gegeben werden kann, der durch die Option QueueDirectory in der Datei sendmail.cf definiert ist. Hier ist ein Beispiel: # mv /var/spool/mqueue /var/spool/mqueue.old # mv /var/spool/mqueue.new /var/spool/mqueue Starten Sie eine weitere Kopie von sendmail als Queue-Runner, um die alte Warteschlange zu leeren. Benutzen Sie das Argument -O auf der sendmail-kommandozeile, um den Queue-Runner auf die alte Warteschlange zu verweisen. Hier ist ein Beispiel: # sendmail L sm-oldq -q15m O QueueDirectory=/var/spool/mqueue.old Diskussion sendmail speichert df-, qf- und xf-dateien in eigenen Verzeichnissen, wenn das Standardwarteschlangenverzeichnis Unterverzeichnisse namens df, qf und xf enthält. Wie bei den mehrfachen Warteschlangen, die in Rezept 9.1 beschrieben wurden, reduzieren die Unterverzeichnisse df, qf und xf die Größe jedes einzelnen Warteschlangenverzeichnisses. Außerdem erlauben sie es, Unterverzeichnisse auf getrennten Geräten zu platzieren, um die I/O-Beschränkungen eines einzelnen Gerätes zu überwinden. Diese Vorteile helfen bei der Verarbeitung einer sehr großen Mail-Warteschlange. Darüber hinaus können Sie durch die Benutzung getrennter Unterverzeichnisse für die verschiedenen Typen von Warteschlangendateien ein Gerät wählen, das für die Art der Warteschlangendatei, die es verarbeiten soll, optimiert ist. Folgende Dateieigenschaften sollten Sie in Betracht ziehen, wenn Sie ein Gerät auswählen: df qf xf Eine df-datei enthält den Body der Mail-Nachricht. Normalerweise ist sie die größte der drei Dateien. Eine df-datei wird einmal in die Warteschlange geschrieben und bei jedem Auslieferungsversuch einmal gelesen, so dass sie üblicherweise weniger oft als die anderen Dateien verarbeitet wird. Ihr Hauptaugenmerk sollte der Speicherkapazität gelten, wenn Sie ein Gerät für df-dateien auswählen. Eine qf-datei enthält die Auslieferungs- und Warteschlangenanweisungen für die Nachricht sowie die Nachrichten-Header. Eine qf-datei ist klein, wird jedoch jedes Mal, wenn die Auslieferung versucht wird, neu geschrieben. Wenn eine Nachricht viele Empfänger hat oder mehrmals in die Warteschlange geschrieben wird, dann verarbeitet sendmail die qf-datei viele Male. Leistung ist daher ein wichtiger Gesichtspunkt, wenn Sie ein Gerät auswählen, das mit qf-dateien umgehen soll. Eine xf-datei wird für jeden Auslieferungsversuch erzeugt und ist nur für diesen Versuch gültig. xf-dateien sind klein und kurzlebig. Leistung ist der Hauptgesichtspunkt, wenn Sie ein Gerät für xf-dateien auswählen. Links 350 Kapitel 9: Die Warteschlange verwalten

369 Rechts Diese Unterverzeichnisse können in jeder Kombination angelegt werden. Sie könnten zum Beispiel nur ein xf-verzeichnis erzeugen sendmail würde xf-dateien in dieses Verzeichnis schreiben und df- und qf-dateien in das Basisverzeichnis setzen. In diesem Rezept wird ein temporäres Verzeichnis, /var/spool/mqueue.new, als Basisverzeichnis erzeugt. Alle drei Unterverzeichnisse, df, qf und xf, werden dann innerhalb dieses Verzeichnisses erzeugt. Das alte Warteschlangenverzeichnis wird an eine andere Stelle verschoben, und das neue Verzeichnis wird in den Wert umbenannt, der durch die sendmail.cf-option QueueDirectory definiert ist, in unserem Beispiel also /var/spool/mqueue. sendmail benutzt die neue Verzeichnisstruktur, sobald sie umbenannt wurde. Wie Nick Christenson in seinem Buch sendmail Performance Tuning (Addison Wesley) erläutert, ist die offensichtliche Wettkampfsituation (race condition), die durch das Umbenennen des Warteschlangenverzeichnisses von sendmail während des Betriebs von sendmail verursacht wird, minimal. Mail, die durch den MSP verschickt wird, benutzt das Warteschlangenverzeichnis, das in submit.cf definiert ist, üblicherweise /var/spool/ clientmqueue, so dass sie unbeeinflusst bleibt, wenn mqueue umbenannt wird. 1 Ein Prozess, der läuft, wenn das Verzeichnis umbenannt wird, wird nicht beeinträchtigt, da er den Inode des Warteschlangenverzeichnisses benutzt, und nicht den logischen Namen. Falls der Prozess deshalb mit der alten Warteschlange begonnen hat, wird er auch mit der alten Warteschlange fortgesetzt, selbst nachdem das Warteschlangenverzeichnis einen anderen Namen erhalten hat. Nach dem Neustart des sendmail-hauptprozesses benutzen alle nachfolgenden sendmail-prozesse die neue Warteschlange. Selbstverständlich verbleibt Mail, die im alten Warteschlangenverzeichnis gespeichert wurde, in diesem, auch nachdem das Verzeichnis umbenannt wurde, es sei denn, es wird ein Prozess gestartet, um die alte Warteschlange zu leeren. Benutzen Sie das Argument -O auf der Kommandozeile, um den Queue-Runner auf die alte Warteschlange zu verweisen, wie in der Lösung gezeigt. Überprüfen Sie regelmäßig die alte Warteschlange, um festzustellen, ob sie geleert wurde. Dazu benutzen Sie einen solchen Befehl: # sendmail bp O QueueDirectory=/var/spool/mqueue.old Wenn die alte Warteschlange dann leer ist, beenden Sie den speziellen Queue-Runner und löschen das überflüssige Verzeichnis. Die Unterverzeichnisse df, qf und xf können auf getrennte physische Geräte gelegt werden. So könnte beispielsweise auf einem Linux-System das Unterverzeichnis xf auf /dev/ shm gelegt werden, ein Shared-Memory-Gerät, das das Linux-Dateisystemformat tmpfs verwendet. Es funktioniert, das Unterverzeichnis xf auf ein flüchtiges, speicherbasiertes Dateisystem zu setzen, das hohe Leistung auf Kosten der Langzeitspeicherung bietet, da xf-dateien zwischen den Warteschlangendurchläufen oder Neustarts nicht aufbewahrt werden müssen. 1 sendmail vor Version 8.12 verwendete die Datei submit.cf nicht. 9.2 Die Unterverzeichnisse qf, df und xf benutzen 351

370 Mehrere Warteschlangen, wie solche, die wir in Rezept 9.1 erzeugt haben, können mit den Unterverzeichnissen df, qf und xf kombiniert werden, um die Vorteile beider Ansätze für Systeme zu erhalten, die mit großen Mail-Warteschlangen umgehen müssen. In Rezept 9.1 wurden drei Warteschlangenverzeichnisse angelegt. Innerhalb der einzelnen Verzeichnisse könnten wir die Unterverzeichnisse df, qf und xf erzeugen, so dass wir insgesamt neun unterschiedliche Verzeichnisse bekommen würden, die wir dann in beliebiger Weise physischen Geräten zuweisen könnten. Links Siehe auch In Rezept 9.1 werden mehrere Warteschlangen erzeugt, die mit diesem Rezept kombiniert werden können. Das Buch sendmail behandelt die Unterverzeichnisse df, qf und xf in Abschnitt und in Abschnitt 6.5. Das Buch sendmail Performance Tuning von Nick Christenson (Addison Wesley) behandelt dieses Thema in Abschnitt Warteschlangengruppen definieren Problem Es ist eine besondere Konfiguration erforderlich, um unterschiedliche Mail-Warteschlangen mit einheitlichen Eigenschaften zu definieren. Lösung Legen Sie die Verzeichnisse für die Warteschlangengruppen an. Die Gruppenverzeichnisse müssen Unterverzeichnisse unterhalb des vorgegebenen Warteschlangenverzeichnisses sein. In diesem Beispiel werden vier Verzeichnisse für Warteschlangengruppen erzeugt: # cd /var/spool/mqueue # mkdir slowq fastq.1 fastq.2 fastq.3 # chmod 700 slowq fastq.? Fügen Sie die QUEUE_GROUP-Makros in die sendmail-konfiguration ein, um die Warteschlangengruppenverzeichnisse zu benutzen, die im ersten Schritt erzeugt wurden. Hier sind die Beispiel-QUEUE_GROUP-Makros: dnl Define a queue group QUEUE_GROUP(`slowq', `Path=/var/spool/mqueue/slowq') dnl Define a queue group QUEUE_GROUP(`fastq', `Path=/var/spool/mqueue/fastq.*, I=10m, F=f, R=3') Erstellen Sie die Datei sendmail.cf. Kopieren Sie sie nach /etc/mail/sendmail.cf, und starten Sie sendmail neu (siehe Rezept 1.8). 352 Kapitel 9: Die Warteschlange verwalten

371 Rechts Diskussion Der erste Schritt in der Lösung erzeugt vier Warteschlangen im Verzeichnis /var/spool/ mqueue: slowq, fastq.1, fastq.2 und fastq.3. Diese Warteschlangen werden dann durch die QUEUE_GROUP-Makros als Warteschlangengruppen slowq und fastq referenziert. Die Verzeichnisse für Warteschlangengruppen werden im Basispfad der Standardwarteschlange erzeugt. Wenn ein einzelnes Verzeichnis für die Basiswarteschlange verwendet wird, dann handelt es sich bei dem Basispfad um den Pfad, der durch die Option QueueDirectory angegeben wurde. Wird QUEUE_DIR benutzt, um mehrere Warteschlangenverzeichnisse zu definieren, wie es in Rezept 9.1 der Fall war, dann sind der Pfadname der Standardwarteschlange, der durch QueueDirectory festgelegt wird, und der Basispfadname nicht genau gleich. Zum Beispiel: define(`queue_dir', `/var/spool/mqueue/queue.*') Diese QUEUE_DIR-Definition setzt die Standardwarteschlange auf /var/spool/mqueue/queue.*. Der Basispfadname ist in diesem Fall /var/spool/mqueue, nicht /var/spool/mqueue/queue.*. Das Verzeichnis, das die Unterverzeichnisse enthält, die für mehrere Warteschlangen benutzt werden, ist der Basispfad, in den die Warteschlangen platziert werden sollen, die für weitere Warteschlangengruppen verwendet werden. Deklarieren Sie die Warteschlangengruppen mit dem m4-makro QUEUE_GROUP. Die Syntax des Befehls QUEUE_GROUP lautet: QUEUE_GROUP(`gruppenname', `equates') Der gruppenname ist ein beliebiger Name, der einer Warteschlange zugewiesen wird. Dieser gruppenname wird benutzt, um die Warteschlange innerhalb der sendmail-konfiguration zu referenzieren. Außerdem kommt er in QGRP:-Records in der access-datenbank zum Einsatz. Die Standardwarteschlange wird mit mqueue bezeichnet und kann über diesen Namen angesprochen werden. Bei den equates handelt es sich um eine durch Kommata getrennte Liste von Warteschlangenattributen, die in der Form schlüsselwort=wert geschrieben werden. Das equates-feld muss vorhanden sein, auch wenn es explizit leer sein darf. Die QUEUE_GROUP-Befehle in der Lösung haben Werte im equates-feld. Hier ist ein Beispiel mit einem leeren equates-feld: QUEUE_GROUP(`normalq', `') Beachten Sie die einzelnen Anführungszeichen, die das leere equates-feld im obigen Beispiel einschließen. Wenn das equates-feld leer ist, erbt die Warteschlangengruppe alle Attribute der Standardwarteschlange mqueue. Bei dem oben gezeigten QUEUE_GROUP- Befehl würde normalq das gleiche Warteschlangenverzeichnis und die gleichen Attribute benutzen wie die Warteschlangengruppe mqueue. Alle Warteschlangengruppen erben die Attribute der Standardwarteschlange. Die schlüsselwort=wert-equates, die im equates-feld definiert werden, werden benutzt, um die vorgegebenen Werte für bestimmte Warteschlangenattribute außer Kraft zu setzen. Tabelle 9-1 zeigt die verfügbaren Schlüsselwörter und beschreibt die Warteschlangenattribute, die mit den einzelnen Schlüsselwörtern verknüpft sind. 9.3 Warteschlangengruppen definieren 353

372 Tabelle 9-1: Attribute für Warteschlangengruppen Links Schlüsselwort Flags= Interval= Jobs= Nice= Path= Recipient= Runners= Funktion Setzt optionale Laufzeit-Flags. Gibt die Zeitspanne zwischen Warteschlangendurchläufen an. Beschränkt die Anzahl der Umschläge, die während eines einzigen Warteschlangendurchlaufs verarbeitet werden. Definiert den nice-wert, der für den Warteschlangendurchlauf benutzt wird. Der vollständige Pfadname des Warteschlangenverzeichnisses, das für diese Warteschlangengruppe benutzt wird. Legt die maximale Anzahl der Benutzer fest, die für einen Umschlag zulässig sind. Definiert die maximale Anzahl der Warteschlangen-Prozessoren, die in einem Warteschlangendurchlauf benutzt werden können. Die Wirkung der Equates, die in Tabelle 9-1 aufgeführt sind, kann durch andere Konfigurationsoptionen verändert werden: conffast_split Die Zahl, die dieser Option zugewiesen ist, legt die maximale Anzahl der Umschläge fest, die während der anfänglichen Auslieferung ausgeliefert werden können, und zwar ungeachtet des Wertes, der durch Jobs gesetzt wurde. Außerdem wird durch das Zuweisen einer positiven Zahl verhindert, dass MX-Anfragen von Empfängeradressen durchgeführt werden, wenn der Umschlag gesplittet ist. Das Überspringen der MX-Anfrage kann die Umschlagverarbeitung beschleunigen; durch die Beschränkung der Anzahl der Auslieferungsprozesse kann die Leisung auf einem stark ausgelasteten System erhöht werden. Standardmäßig führt sendmail MX-Anfragen aus, wenn Umschläge gesplittet sind. Außerdem betreibt es so viele Auslieferungsprozesse, wie benötigt werden, um alle Umschläge parallel auszuliefern. confmax_queue_children Die Zahl, die dieser Option zugewiesen wird, ist die maximale Anzahl der Warteschlangenprozesse, die in allen Warteschlangengruppen zusammen erlaubt ist. Die obere Grenze, die durch diese Option festgelegt wird, wird nicht durch die Werte beeinflusst, die für Runners oder Flags gesetzt sind. Wenn confmax_queue_children auf 10 und die Gesamtanzahl von Runners auf 15 gesetzt ist, begrenzt sendmail die Anzahl der Warteschlangenprozesse auf 10. Standardmäßig ist confmax_queue_ CHILDREN auf 0 gesetzt, was bedeutet, dass sendmail eine unbegrenzte Anzahl von Warteschlangenprozessen erlaubt (bis zu der Grenze, die von Runners festgelegt ist). confmax_runners_per_queue Diese Option setzt die vorgegebene maximale Anzahl der Queue-Runner, die pro Warteschlangengruppe erlaubt sind. Der Wert, der durch Runners in einem QUEUE_ GROUP-Makro gesetzt wird, überschreibt diesen Vorgabewert für eine bestimmte Warteschlangengruppe. 354 Kapitel 9: Die Warteschlange verwalten

373 Rechts confmin_queue_age Diese Option setzt die minimale Zeitspanne, die eine in der Warteschlange befindliche Nachricht warten muss, bevor ein Auslieferungsversuch unternommen wird. Dieser Wert wird nicht davon beeinflusst, wie oft die Warteschlange verarbeitet wird. Wenn Interval auf 10 Minuten (10m) gesetzt ist und confmin_queue_age 1 Stunde (1h) beträgt, dann kann eine Nachricht für sechs Warteschlangendurchläufe in der Warteschlange verbleiben, bevor sendmail versucht, sie auszuliefern. Diese Option wird benutzt, um die Last auf solchen Systemen zu verringern, die sehr große Warteschlangen haben, aber nur ein kurzes Warteschlangenintervall einsetzen. Standardmäßig versucht sendmail jedes Mal, wenn die Warteschlange verarbeitet wird, alle Mails in der Warteschlange auszuliefern (bis zu der Grenze, die von Jobs gesetzt wurde). confnice_queue_run Diese Option setzt den vorgegebenen nice-wert, der für Warteschlangendurchläufe zum Einsatz kommt. Er kann für eine bestimmte Warteschlangengruppe durch Nice in einem QUEUE_GROUP-Makro außer Kraft gesetzt werden. confmax_queue_run_size Diese Option setzt die maximale Anzahl der Warteschlangennachrichten, die während eines Warteschlangendurchlaufs in allen Warteschlangengruppen zusammen verarbeitet werden. Standardmäßig versucht sendmail, alle Mails in der Warteschlange auszuliefern. Diese Option legt eine obere Grenze für die Anzahl der Nachrichten fest, die sendmail auszuliefern versucht, etwa so, wie Jobs dies für eine einzelne Warteschlangengruppe erledigt. Die sendmail-konfiguration in diesem Rezept enthält zwei QUEUE_GROUP-Befehle: QUEUE_GROUP(`slowq', `Path=/var/spool/mqueue/slowq') QUEUE_GROUP(`fastq', `Path=/var/spool/mqueue/fastq.*, I=10m, F=f, R=3') Der erste QUEUE_GROUP-Befehl definiert eine Warteschlangengruppe und weist ihr den Namen slowq zu. Der Pfad zum Warteschlangenverzeichnis der Gruppe slowq wird als /var/ spool/mqueue/slowq definiert. Alle anderen von slowq benutzten Attribute sind die vorgegebenen Warteschlangenattribute. Der zweite QUEUE_GROUP-Befehl definiert die Warteschlangengruppe fastq. Die Gruppe fastq benutzt mehrere Warteschlangen, wie durch das Asterisk-Suffix im Pfadnamen des Warteschlangenverzeichnisses signalisiert wird. Der Asterisk wird verwendet, um mehrere Warteschlangen für jede Warteschlangengruppe zu definieren. Das geht auf genau die gleiche Weise, auf die mehrere Warteschlangen für die Standardwarteschlangengruppe definiert werden. In Rezept 9.1 finden Sie weitere Informationen über mehrfache Warteschlangen und das Asterisk-Suffix. Neben dem Attribut Path definiert der zweite QUEUE_GROUP-Befehl noch drei weitere Attribute: Interval, Flags und Runners. Beachten Sie, dass das Schlüsselwort in den einzelnen Equates nicht unbedingt ausgeschrieben werden muss; es ist nur das erste Zeichen des Schlüsselworts von Bedeutung. Das heißt, I=10m ist äquivalent zu Interval=10m, und das Attribut Path hätte mit P=/var/spool/mqueue/fastq.* gesetzt werden können. Beachten 9.3 Warteschlangengruppen definieren 355

374 Sie außerdem, dass alle Einträge in der Equates-Liste durch Kommata getrennt sind. Der Whitespace, der im Beispiel zum Einsatz kommt, verbessert die Lesbarkeit, ist aber nicht erforderlich. Das Setzen des Attributs I=10m bedeutet, dass sendmail die Warteschlangen in dieser Warteschlangengruppe alle 10 Minuten verarbeitet. Das Setzen des Flags f, F=f, weist sendmail an, mit fork Queue-Runner für jede Warteschlange zu erzeugen bis hin zu der oberen Anzahl von Warteschlangenprozessen, die mit dem Schlüsselwort Runners definiert wurde. f ist der einzige Wert, der momentan für Flags gültig ist. Nehmen Sie immer F=f, wenn Sie das Schlüsselwort Runners benutzen. R=3 bedeutet, dass sendmail bis zu drei separate Prozesse verwenden kann, um die Warteschlangen in dieser Warteschlangengruppe zu verarbeiten. Dieses Rezept erzeugte drei Warteschlangen (fastq.1, fastq.2 und fastq.3) für die Gruppe fastq. Das Setzen von R=3 bedeutet, dass jede Warteschlange einen einzigen Warteschlangen-Prozessor für jeden Warteschlangendurchlauf hat. Bei R=15 wären für jede Warteschlange bei jedem Warteschlangendurchlauf fünf Prozesse vorgesehen. Es ist jedoch nicht immer gut, viele Queue-Runner zu haben. Lesen Sie Rezept 9.5, um herauszufinden, warum das so ist. Die QUEUE_GROUP-Makros erzeugen Q-Befehle in der Datei sendmail.cf. Folgende Q-Befehle werden durch dieses Rezept erzeugt: # grep '^Q' recipe9-3.cf Qslowq, Path=/var/spool/mqueue/slowq Qfastq, Path=/var/spool/mqueue/fastq.*, I=10m, R=3 Warteschlangengruppen werden von Funktionen zur Warteschlangenverwaltung benutzt. Beispielsweise können Sie einen sendmail-mailer so konfigurieren, dass er eine bestimmte Warteschlangengruppe als seine Standard-Mail-Warteschlange benutzt. Der Parameter Q der Mailer-Definition teilt dem Mailer mit, welche Warteschlangengruppe er benutzen soll. Alle Mailer haben eine m4-definition für den Parameter Q, all diese Definitionen werden auf exakt die gleiche Weise eingesetzt, und die meisten tragen Namen der Form NAME_ MAILER_QGRP, wobei NAME der interne Name des Mailers ist. Benutzen Sie zum Beispiel PROCMAIL_MAILER_QGRP, um Q zu setzen, falls der Name des Mailers procmail ist. Darüber hinaus können Warteschlangengruppen in der access-datenbank verwendet werden. Rezept 9.4 zeigt ein Beispiel dafür. Siehe auch Rezept 9.1 behandelt den Befehl QUEUE_DIR und beschreibt mehrfache Warteschlangen. Rezept 9.2 behandelt die Unterverzeichnisse df, qf und xf, die im Warteschlangenverzeichnis jeder Warteschlangengruppe angelegt werden können. Das Buch sendmail behandelt Warteschlangengruppen in Abschnitt 11.4, confqueue_file_mode in , conffast_split in , confmax_queue_children in , confmin_queue_age in , confmax_queue_run_size in , confnice_queue_run in und confmax_ RCPTS_PER_MESSAGE in Links 356 Kapitel 9: Die Warteschlange verwalten

375 Rechts 9.4 Empfänger bestimmten Warteschlangen zuweisen Problem Um die Warteschlangen optimal an die Eigenschaften des Ziel-Hosts anzupassen, müssen Sie Mail, die an Empfängeradressen auf diesen Hosts gerichtet ist, an die optimierten Mail-Warteschlangen routen. Lösung Erzeugen Sie die Verzeichnisse für die Warteschlangengruppen und falls erforderlich die physischen Geräte, die die Gruppenverzeichnisse benutzen werden. Einzelheiten dazu finden Sie in den Rezepten 9.1 und 9.3. Fügen Sie QGRP:-Records in die access-datenbank ein, um die Warteschlangengruppen festzulegen, die für bestimmte Empfänger benutzt werden sollen. Der Schlüssel für die einzelnen Einträge ist das Tag QGRP:, gefolgt von einer vollständigen oder teilweisen Empfängeradresse. Der Rückgabewert des Eintrags ist der Name der Warteschlangengruppe, der für den angegebenen Empfänger benutzt werden soll. Legen Sie eine sendmail-konfiguration an, die die Warteschlangengruppen definiert, die access-datenbank aktiviert und die Funktion queuegroup verwendet. Hier sind die Beispielzeilen, die in die sendmail-konfiguration eingefügt werden könnten: dnl Define a queue group QUEUE_GROUP(`slowq', `Path=/var/spool/mqueue/slowq, I=2h') dnl Define a queue group QUEUE_GROUP(`fastq', `Path=/var/spool/mqueue/fastq.*, I=10m, R=10') dnl Enable the access database FEATURE(`access_db') dnl Enable the queue group feature FEATURE(`queuegroup') Erstellen und installieren Sie die Datei /etc/mail/sendmail.cf, und starten Sie anschließend sendmail neu, wie in Rezept 1.8 gezeigt. Diskussion Die access-datenbank bietet die flexibelsten Methoden, um Warteschlangengruppen zu nutzen. QGRP:-Records in der access-datenbank erlauben es Ihnen, einzelne Domains und sogar einzelne Benutzer bestimmten Warteschlangengruppen zuzuweisen. Dadurch ist es möglich, Warteschlangengruppen mit Eigenschaften anzulegen, die kompatibel zu den Eigenschaften einer Empfänger-Site sind. Beispielsweise könnte die Warteschlange für eine Site, die wiederholte, lang andauernde Ausfälle aufweist, einen großen Interval- Wert haben. Es könnten auch einigen Domains, die die Masse Ihres ausgehenden Verkehrs ausmachen, mehrere Warteschlangen zugewiesen werden. 9.4 Empfänger bestimmten Warteschlangen zuweisen 357

376 Hier ist ein Beispiel-QGRP:-Eintrag: Links QGRP:example.com slowq Das QGRP:-Record weist sendmail an, die Warteschlangengruppe slowq zu benutzen, um Mail für alle Benutzer der Domain example.com in die Warteschlange einzureihen. Die Empfängeradresse in einem Warteschlangengruppeneintrag kann einen einzelnen Benutzer oder auch eine Gruppe von Hosts identifizieren. Mögliche Formate der Empfängeradresse sind: Eine vollständige Adresse im Format Dieses Format entspricht einem bestimmten Benutzer auf einem bestimmten Host. ist ein Beispiel. Ein Hostname im Format host.domain, z. B. QGRP:crab.wrotethebook.com. Jeder Benutzer auf dem angegebenen Host wird erfasst. Ein Domainname, um alle Benutzer auf allen Hosts der angegebenen Domain zu erreichen. Zum Beispiel würde QGRP:wrotethebook.com alle Empfänger der Domain wrotethebook.com erfassen. Ein Benutzername, geschrieben in der Form z. B. Dieses Format erfasst alle Empfänger mit dem angegebenen Benutzernamen auf allen Hosts einer Domain. Ein leeres Feld, was jeder möglichen Empfängeradresse entspricht. Mail, die an Empfänger adressiert ist, die durch einen QGRP:-Eintrag nicht erfasst werden, werden in die normale Warteschlange aufgenommen. Siehe auch Rezept 9.3 behandelt das Makro QUEUE_GROUP. Die access-datenbank wird ausführlich in den verschiedenen Rezepten dieses Buches besprochen, wobei der Schwerpunkt auf Kapitel 3 und Kapitel 6 liegt. Das Buch sendmail behandelt das QGRP:-Record in Abschnitt Persistente Queue-Runner benutzen Problem Warteschlangen können so groß werden, dass Queue-Runner (Programme zum Abarbeiten einer Warteschlange) einander stören. Lösung Suchen Sie in den Systemstartdateien nach dem Befehl, der sendmail mit dem Flag -bd startet. Suchen Sie nach einer Zeile, die ungefähr so aussieht: /usr/sbin/sendmail -bd -q15m 358 Kapitel 9: Die Warteschlange verwalten

377 Rechts Ändern Sie das Argument -q in -qp. Zum Beispiel: /usr/sbin/sendmail -bd -qp Beenden Sie den momentan laufenden Warteschlangen-Prozessor des sendmail-daemons: # kill -TERM `head -1 /var/run/sendmail.pid` Starten Sie einen neuen Daemon-Prozess mit den neuen Kommandozeilenargumenten: # /usr/sbin/sendmail -bd -qp Diskussion Der erste Schritt in diesem Rezept modifiziert das Startskript, so dass sendmail bei jedem Systemneustart mit den richtigen Kommandozeilenargumenten startet. Auf manchen Systemen ist das Suchen und Ändern der Zeilen, die sendmail beim Booten startet, einfach; auf anderen Systemen gestaltet es sich dagegen komplizierter. Unterschiedliche Unix-Versionen verwenden unterschiedliche Techniken, um sendmail beim Booten zu starten. Die meisten Unix-Versionen verwenden einen Befehl, der dem im Folgenden gezeigten ähnelt, um den sendmail-daemon zu starten: /usr/sbin/sendmail -bd -q15m Diese Zeile enthält zwei Optionen: -bd und -q. Verwenden Sie -bd, um eingehende Mail zu akzeptieren. Das Argument -bd veranlasst sendmail, an den konfigurierten TCP-Ports auf eingehende Mail zu warten. Bei diesen Ports handelt es sich standardmäßig um die Ports 25 und 587. Ohne einen Daemon, der mit gesetztem -bd läuft, kann ein richtig konfiguriertes System zwar ausgehende Mail senden, erhält aber keine eingehende Mail. 2 Die Option -q veranlasst den Daemon, regelmäßig Warteschlangen-Prozessoren zu starten. In diesem speziellen Beispiel wird der Daemon angewiesen, alle 15 Minuten (15m) Warteschlangen-Prozessoren zu starten. Dieses Rezept ändert das Flag -q in -qp. Durch das Ändern von -q in -qp wird der Daemon als persistenter (dauerhafter) Warteschlangen-Prozessor ausgeführt. Der Unterschied zwischen dem Starten eines Queue-Runners alle 15 Minuten mit -q15m und dem Anfordern eines persistenten Queue-Runners mit -qp ist deutlich. Im ersten Fall wird der neue Queue-Runner alle 15 Minuten gestartet, ohne dass Rücksicht auf den Status des vorhergehenden Warteschlangendurchlaufs genommen wird. Im zweiten Fall wird der neue Queue-Runner eine Sekunde nach dem Beenden des vorherigen Warteschlangendurchlaufs gestartet. Eine Sekunde ist der vorgegebene Intervall-Timer für die Option -qp. Dieser kann auf der Kommandozeile geändert werden, indem man einen anderen Intervallwert definiert; beispielsweise würde sendmail -qp15s das Intervall auf 15 Sekunden setzen. Eine Sekunde ist jedoch ein guter Wert. Er ermöglicht im Prinzip eine kontinu- 2 Rezept 10.1 konfiguriert sendmail so, dass es ausgehende Mail sendet, ohne einen Daemon mit der Option -bd auszuführen. 9.5 Persistente Queue-Runner benutzen 359

378 ierliche Warteschlangenverarbeitung ohne Störungen zwischen den einzelnen Queue- Runnern, weil der Intervall-Timer für den nächsten Queue-Runner erst startet, wenn der aktuelle Warteschlangendurchlauf beendet ist. Am Anfang jedes Warteschlangendurchlaufs liest der Queue-Runner alle qf-dateien, extrahiert bestimmte Steuerinformationen, sortiert sie und verwendet sie, um die Reihenfolge zu kontrollieren, in der die in der Warteschlange befindlichen Nachrichten ausgeliefert werden. Ein persistenter Queue-Runner kann vorteilhaft sein, wenn eine einzelne Warteschlange so groß ist, dass dieser erste Schritt länger dauert als das gewählte Warteschlangenintervall. Wenn Sie beispielsweise -q15m benutzen, wird das Warteschlangenintervall auf 15 Minuten gesetzt. Würde der erste Schritt 30 Minuten dauern, dann würde sendmail bei 15 Minuten einen weiteren Queue-Runner starten und einen dritten dann bei 30 Minuten. Jeder Runner würde den anfänglichen Schritt wiederholen, nur um dann von weiteren Runnern gefolgt zu werden, die die gleiche Aufgabe erledigen. Leider beschleunigen zusätzliche Queue-Runner diesen ersten Schritt nicht immer. Tatsächlich stören sie einander manchmal so sehr, dass sie die Angelegenheit sogar verlangsamen. Durch persistente Queue-Runner umgehen Sie dieses Problem. Wenn ein persistenter Queue-Runner benutzt wird, kann dieser seine Arbeit beenden, ohne dass er von anderen Queue-Runnern gestört wird. Der persistente Queue-Runner beendet den ersten Schritt, erzeugt aus sich mehrere Prozesse, um die Mail auszuliefern, die er sortiert hat, und wartet (schläft) dann während dieses Warteschlangenintervalls, bevor er wieder erwacht und von vorn beginnt. Da das Warteschlangenintervall erst dann beginnt, wenn der persistente Queue-Runner das Sortieren beendet hat, starten keine weiteren Queue-Runner während seines Betriebs. Dadurch werden die Probleme völlig vermieden, die auftreten, wenn mehrere Queue-Runner die gleiche Warteschlange sortieren. Neben den Änderungen am Boot-Skript schließt die Lösung auch aktuelle sendmail-prozesse mit einem SIGTERM aus und startet sendmail von der Kommandozeile aus mit neuen Optionen neu. Nach dem Neustart von sendmail würde ein cat der Datei sendmail. pid die Kommandozeile /usr/sbin/sendmail -bd -qp zeigen. Nachfolgende Neustarts des Daemons können mit dem HUP-Signal erledigt werden, da HUP zum Neustart von sendmail den Befehl verwendet, der in sendmail.pid zu finden ist. Warteschlangenleerung im Notfall Da dieses Rezept andauernd die Standardkonfiguration des Systems ändert, ist es für Systeme gedacht, bei denen die Verarbeitung einer sehr großen Warteschlange ein chronisches Systemproblem darstellt. Das manuelle Ausführen von sendmail mit Einstellungen, die den Zeit raubenden ersten Schritt überspringen, ist eine alternative Lösung für den Fall, dass die Warteschlange auf Grund außergewöhnlicher Umstände sehr groß geworden ist. In diesem Fall beenden Sie alle momentan laufenden sendmail-prozesse und geben dann den folgenden Befehl ein: # /usr/sbin/sendmail -OQueueSortOrder=filename -q15m Links 360 Kapitel 9: Die Warteschlange verwalten

379 Rechts Diese QueueSortOrder-Option weist sendmail an, die Mail in der Reihenfolge ihrer Dateinamen auszuliefern. Alternativen bestehen darin, die in der Warteschlange befindliche Mail in zufälliger Reihenfolge (mit Hilfe von -OQueueSortOrder=random) oder in der Reihenfolge der Änderungszeit von der ältesten bis zu neuesten (mit Hilfe von -OQueueSortOrder= modtime) auszuliefern. In all diesen Fällen werden die qf-dateien nicht geöffnet und gelesen. Deshalb wird auch die Auslieferungsreihenfolge nicht optimiert. Allerdings wird am Anfang der Warteschlangenverarbeitung ungeheuer viel Zeit gespart, die Sie auch brauchen, um eine übervolle Warteschlange zu leeren. Sobald die Warteschlange wieder leer ist, beenden Sie diese besondere Kopie und starten wieder die normale Konfiguration. Benutzen Sie Rezept 9.5, wenn chronische Probleme mit der Systemleistung routinemäßig von dem Aufwand beim Verarbeiten sehr großer Mail-Warteschlangen verursacht werden. Die Option QueueSortOrder können Sie als schnelle Lösung für ein ungewöhnliches Problem mit der Warteschlangenverarbeitung einsetzen. Siehe auch Das Buch sendmail beschreibt persistente Queue-Runner in Abschnitt 6.1 und die Option QueueSortOrder in Abschnitt Das Buch sendmail bietet interessante Statistiken über die Zeit zur Warteschlangenverarbeitung auf der Grundlage der Warteschlangengröße und der Leistungsgewinne, die mit den alternativen Lösungen zu erzielen sind. Kapitel 3 des Buches sendmail Performance Tuning von Nick Christenson (Addison Wesley) behandelt Warteschlangenprobleme und empfiehlt Lösungen. 9.6 Einen Warteschlangen-Server benutzen Problem Es ist eine besondere Konfiguration erforderlich, um Mail an einen Warteschlangen-Server zu routen, anstatt sie lokal in eine Warteschlange zu setzen. Lösung Konfigurieren Sie ein System mit viel Speicherplatz, das als Warteschlangen-Server auftreten kann. Konfigurieren Sie den Server folgendermaßen: Sehen Sie reichlich Speicherplatz für die Warteschlange vor. In Rezept 9.1 finden Sie Informationen über das Anlegen mehrfacher Warteschlangen, die sich über mehrere physische Geräte erstrecken. Verwenden Sie ein langes Warteschlangenintervall. Es sollte wenigstens eine Stunde betragen; d. h. -q1h. Lassen Sie ihn als Relay-Server für seine Warteschlangen-Clients auftreten. In Kapitel 3 finden Sie Informationen über das Gewähren von Vermittlungsberechtigungen für Clients. 9.6 Einen Warteschlangen-Server benutzen 361

380 Konfigurieren Sie die Clients so, dass sie den Warteschlangen-Server benutzen. Dazu verwenden Sie die Definition conffallback_mx in der sendmail-konfiguration des Clients. Nehmen wir an, dass es sich bei dem Warteschlangen-Server, der im ersten Schritt erzeugt worden ist, um jamis.wrotethebook.com handelt. Hier ist eine Beispieldefinition, die in die sendmail-konfiguration des Clients eingefügt werden könnte, damit dieser den Server benutzt: dnl Use jamis as the fallback mail exchanger define(`conffallback_mx', `jamis.wrotethebook.com') Erstellen und installieren Sie die Datei /etc/mail/sendmail.cf, und starten Sie anschließend sendmail neu (siehe Rezept 1.8). Diskussion MX-Records teilen sendmail mit, wohin die Mail ausgeliefert werden soll. sendmail sieht die MX-Records für eine Empfängeradresse nach. Wenn es keine MX-Records für den Empfänger-Host gibt, versucht sendmail, an den Empfänger-Host selbst auszuliefern. Dazu benutzt es das Address-Record oder das CNAME-Record des Hosts. Liefert das DNS MX-Records für den Empfänger-Host, dann versucht sendmail, an jeden Mail Exchanger in der Reihenfolge auszuliefern. Falls keiner dieser Auslieferungsversuche erfolgreich ist, reiht sendmail die Mail in die Warteschlange ein. Stellen Sie sich zum Beispiel vor, dass sendmail Mail an wrotethebook.org ausliefern muss und die angegebenen MX-Records folgendermaßen lauten: wrotethebook.org. IN MX 10 mail.example.com. wrotethebook.org. IN MX 20 oreilly.com. sendmail versucht zuerst, die Nachricht an mail.example.com auszuliefern. Falls das funktioniert, ist sendmail fertig. Schlägt die Auslieferung fehl, versucht es, an oreilly.com auszuliefern. 3 Klappt auch diese Auslieferung nicht, wird die Mail in die Warteschlange geschrieben. conffallback_mx ändert diesen letzten Schritt. Der Host, der durch conffallback_mx definiert wird, wird als Mail Exchanger-letzter- Versuch für alle Auslieferungen verwendet. Wenn Mail nicht erfolgreich an einen der Mail Exchanger ausgeliefert werden kann, die in den vom DNS gelieferten MX-Records aufgeführt sind, sendet sendmail die Mail an den Host, der durch die Definition conffallback_mx festgelegt wurde. Gibt es keine MX-Records für den Empfänger-Host, dann versucht sendmail, die Mail mit Hilfe des A- oder des CNAME-Records des Hosts zu versenden, und wenn dieser Versuch fehlschlägt, wird die Mail an den conffallback_mx- Host gesandt. Auch wenn das DNS nicht auf eine der sendmail-anfragen nach den MX-, A- oder CNAME-Records des Empfänger-Hosts antwortet, wird die Mail an den Host gesandt, der durch conffallback_mx definiert ist. Alle diese Maßnahmen verhindern, dass die Mail auf dem Client in die Warteschlange eingereiht wird. 3 MX-Records werden für jedes System in der MX-Liste nachgesehen. Eine Ausnahme bildet das System, das durch die conffallback_mx-definition hinzugefügt wurde. Links 362 Kapitel 9: Die Warteschlange verwalten

381 Rechts Wenn der Ersatz-Mail Exchanger die Mail empfängt, behandelt er sie als Mail, die an den Empfänger weitervermittelt wird. Das bedeutet, dass er die Mail nur dann akzeptiert, wenn dem Client Vermittlungsberechtigungen gewährt wurden. Falls der Ersatz-Mail Exchanger die Mail akzeptiert, bezieht er die MX-Records des Empfängers vom DNS und versucht eine Auslieferung. Ist er nicht in der Lage, die Mail auszuliefern, schreibt er sie in die Warteschlange. Der Vorteil dieses Ansatzes besteht darin, dass die Mehrzahl der Systeme (d. h. die Clients) dahingehend optimiert werden kann, dass sie mit dem Standardfall umgehen können. Der Warteschlangen-Server wird so optimiert, dass er die Warteschlangenverarbeitung erledigt. Rezept 9.7 beschreibt einen Fall, bei dem Clients so optimiert werden, dass sie in dieser Umgebung arbeiten. Der Nachteil beim Einsatz eines Warteschlangen-Servers besteht darin, dass es zwei fehlgeschlagene Auslieferungsversuche gibt, bevor die Mail in die Warteschlange gelangt, obwohl dies keine Verzögerung beim Ausliefern der Mail zur Folge hat. Ein sendmail -bt-test zeigt die Wirkung dieses Rezepts: # sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > /mx aol.com getmxrr(aol.com) returns 5 value(s): mailin-02.mx.aol.com. mailin-04.mx.aol.com. mailin-03.mx.aol.com. mailin-01.mx.aol.com. jamis.wrotethebook.com. > /mx sendmail.org getmxrr(sendmail.org) returns 5 value(s): smtp.neophilic.net. services.sendmail.org. smtp.gshapiro.net. playground.sun.com. jamis.wrotethebook.com. > /quit Der Befehl /mx liefert die MX-Liste zurück, die sendmail verwendet, um an den angegebenen Empfänger-Host auszuliefern. Unabhängig davon, welcher Empfänger-Host mit dem Befehl /mx eingegeben wurde, ist das letzte System in der Liste der durch conffallback_mx definierte Host. Siehe auch Wichtige Hintergrundinformationen über das Konfigurieren eines Warteschlangen-Servers finden Sie in Kapitel 3 sowie weiter vorn in diesem Kapitel. Das Buch sendmail behandelt conffallback_mx in Abschnitt und bietet eine ausgezeichnete Diskussion über die Benutzung eines Warteschlangen-Servers in Abschnitt Abschnitt des Buches sendmail Performance Tuning von Nick Christenson (Addison Wesley) enthält weitere Informationen über den Einsatz von Warteschlangen-Servern. 9.6 Einen Warteschlangen-Server benutzen 363

382 9.7 Protokoll-Timer setzen Links Problem Clients benötigen eine besondere Konfiguration, um problematische Mail schnell auf den Warteschlangen-Server verschieben zu können. Lösung Schaffen Sie einen Warteschlangen-Server, wie in Rezept 9.6 beschrieben. Fügen Sie auf den Clients dieses Servers Definitionen zur sendmail-konfigurationen hinzu, um fehlerhafte Verbindungen und entfernte Systeme, die nicht in der Lage sind, auf SMTP-Befehle in endlicher Zeit zu antworten oder welche anzubieten, schnell zu unterbrechen. Hier sind Beispieldefinitionen für einen Protokoll-Timer, der mit der Definition conffallback_mx benutzt werden könnte: dnl Use jamis as the fallback mail exchanger define(`conffallback_mx', `jamis.wrotethebook.com') dnl Set the protocol timers to low levels define(`confto_connect', `15s') define(`confto_command', `5m') define(`confto_datablock', `5m') define(`confto_datafinal', `5m') define(`confto_datainit', `15s') define(`confto_helo', `15s') define(`confto_hoststatus', `15s') define(`confto_iconnect', `15s') define(`confto_initial', `15s') define(`confto_mail', `15s') define(`confto_quit', `15s') define(`confto_rcpt', `15s') define(`confto_rset', `15s') Erstellen Sie die Datei sendmail.cf, kopieren Sie sie nach /etc/mail/sendmail.cf, und starten Sie sendmail neu, wie in Rezept 1.8 beschrieben. Diskussion Die Definition conffallback_mx setzt den Wert der Option FallbackMXhost in der Datei sendmail.cf. Mail wird an den Server gesandt, der durch FallbackMXhost definiert ist, wenn der Client die Mail nicht erfolgreich ausliefern kann. Dieses Rezept setzt verschiedene Protokoll-Timer auf niedrige Werte, so dass Mail an langsame oder unerreichbare Hosts zur Auslieferung ebenfalls an den Warteschlangen- Server übergeben wird. Dieses Rezept optimiert außerdem den Client für den Durchschnittsfall schnelle, erfolgreiche Mail-Auslieferungen und sendet alle problematischen Mails zur Auslieferung an den Warteschlangen-Server. 364 Kapitel 9: Die Warteschlange verwalten

383 Rechts Standardmäßig verfügt sendmail über sehr großzügige SMTP-Protokoll-Timer. Großzügig bedeutet, dass sendmail die Auslieferung erst dann aufgibt, wenn es sicher ist, dass das entfernte Ende tot ist. Das ist großartig, um die Auslieferung abzusichern, verdammt aber das sendende System dazu, auf eine Antwort des entfernten Systems zu warten. Wenn Sie kurze Timeout-Zeiten setzen, wie in diesem Rezept praktiziert, werden mehr Auslieferungen fehlschlagen. Das bedeutet aber auch, dass der Client nicht durch langsame Auslieferungen gebunden wird. Da der Warteschlangen-Server die Standard-Timeouts nutzt, werden viele der nicht ausgelieferten Mails, die auf dem Client wegen Zeitüberschreitung scheiterten, vom Warteschlangen-Server beim ersten Versuch erfolgreich ausgeliefert. Tabelle 9-2 zeigt alle Timeout-Definitionen, die in diesem Rezept benutzt werden, ihren Zweck und den normalerweise benutzten Vorgabewert. Tabelle 9-2: Die in diesem Rezept verwendeten SMTP-Protokoll-Timer Der define-befehl Setzt den Timeout für Vorgabe confto_connect Den connect-systemaufruf zum Beenden 5m confto_command Warten auf den nächsten Befehl 1h confto_datablock Lesen beenden 1h confto_datafinal Bestätigung des. am Ende des DATA-Blocks 1h confto_datainit Bestätigung des DATA-Befehls 5m confto_helo Bestätigung des HELO/EHLO-Befehls 5m confto_hoststatus Wie lange werden die Statusinformationen gespeichert 30m confto_iconnect Beendigung des anfänglichen Verbindungsversuchs 5m confto_initial Empfang der Begrüßungsnachricht 5m confto_mail Bestätigung des MAIL From:-Befehls 10m confto_quit Bestätigung des QUIT-Befehls 2m confto_rcpt Bestätigung des RCPT To:-Befehls 1h confto_rset Bestätigung des RSET-Befehls 5m Dieses Rezept verringert die Timeout-Zeit für die meisten dieser Protokoll-Timer auf 15 Sekunden (15s), was für die meisten Computer für eine Antwort ausreicht. Ausnahmen bilden die Timeout-Werte für confto_datafinal, confto_datablock und confto_command, die auf einen großzügigeren Wert von fünf Minuten gesetzt werden. Die Werte, die in diesem Rezept gesetzt werden, beruhen auf dem Fast-Daemon-Beispiel (schneller Daemon) in Abschnitt des sendmail-buches. Die Werte hier sind großzügiger gewählt worden als im sendmail-buch, eignen sich aber auch besser für unser Beispielnetzwerk. Sie müssen auf der Grundlage der Leistung Ihres Systems und Ihres Netzwerks Ihre eigenen Werte festlegen. Das Buch sendmail Performance Tuning diskutiert Protokoll-Timer in Abschnitt Protokoll-Timer setzen 365

384 Siehe auch Rezept 9.6 bietet verwandtes Material, das Sie sich anschauen sollten, bevor Sie dieses Rezept umsetzen. Das Buch sendmail behandelt den Einsatz dieser Timer in Abschnitt 6.2 und geht speziell auf eine alternative Lösung ein, die die schnellen Timer und die Standard-Timer auf einem System einsetzt, das ohne Warteschlangen-Server auskommt. Das Buch sendmail behandelt die Timer außerdem in Abschnitt Das Buch sendmail Performance Tuning von Nick Christenson (Addison Wesley) behandelt Ersatz-MX-Hosts in Abschnitt Links 366 Kapitel 9: Die Warteschlange verwalten

385 First Kapitel 10 KAPITEL 10 sendmail sichern 10.0 Einführung Sicherheit ist wichtig. Sicherheit ist sogar so wichtig, dass an vielen Stellen in diesem Buch davon die Rede ist. Um genau zu sein, handeln einige der früheren Kapitel eigentlich von Sicherheit, etwa Kapitel 7 und Kapitel 8. Doch selbst die Kapitel über Weitervermittlung und Spam-Kontrolle sind in Wirklichkeit Kapitel über Sicherheit, da der Diebstahl von Diensten ein ebenso großes Sicherheitsproblem für sendmail darstellt wie die System- und Datenintegrität. Ein sendmail-server erfordert die gleichen Sicherheitsmaßnahmen, die auf jedem vernetzten System eingesetzt werden, und sogar noch einige mehr. Auf Grund seiner Natur muss ein sendmail-server Verbindungen und Daten von unbekannten entfernten Hosts akzeptieren, während viele andere Netzwerk-Server ihre Dienste nur einer beschränkten Gruppe von Clients anbieten. Das System, auf dem sendmail läuft, muss gegen Angriffe gesichert werden, und der sendmail-dienst muss davor geschützt werden, verbotenerweise ausgebeutet zu werden. Die allgemeine Systemsicherheit kann nicht Thema dieses Buches sein. Lesen Sie dazu eine gute Referenz wie etwa Practical UNIX and Internet Security von Simson Garfinkel, Gene Spafford und Alan Schwartz (O Reilly) oder Computer Security Basics von Debbie Russell und G.T. Gangemi (O Reilly). Dieses Buch konzentriert sich ausschließlich auf Dinge, die speziell mit der sendmail-sicherheit zusammenhängen. Die Datei- und Verzeichnisberechtigungen von sendmail sind ein Bereich der allgemeinen Systemsicherheit, der sendmail-spezifisch ist. Alle Verzeichnisse, die für die administrativen Dateien von sendmail benutzt werden, sollten nur vom TrustedUser (normalerweise root) geschrieben werden dürfen. Alle übergeordneten Verzeichnisse dieser Verzeichnisse bis hin zur Wurzel des Dateisystems sollten nur für root schreibbar sein keines dieser Verzeichnisse darf Gruppen- oder Welt-Schreibberechtigungen aufweisen. Die von sendmail verwendeten Dateiberechtigungen werden durch conftemp_file_mode und confqueue_file_mode definiert. Ändern Sie diese Berechtigungen nicht. Sie sind bei sendmail so eng wie möglich gesetzt. 367

386 Entgegen seinem zweifelhaften Ruf verwendet ein vorkonfiguriertes sendmail eng gesteckte Sicherheitseinstellungen. Achten Sie darauf, dass Sie die Sicherheit nicht unterlaufen, wenn Sie sendmail konfigurieren. Einige Änderungen an der Konfiguration verringern die Sicherheit, wie in der Einführung zu Kapitel 3 erläutert wird. Beispielsweise akzeptiert die Definition confdont_blame_sendmail mehr als 40 Argumente, die sendmails normalerweise strenge Sicherheitsvorkehrungen lockern. Manchmal ist ein sendmail-administrator gezwungen, die Sicherheitsmaßnahmen zu lockern, um größere Flexibilität zu erreichen. Viele der Rezepte in diesem Kapitel gehen den entgegengesetzten Weg sie erhöhen die Sicherheit auf Kosten der Flexibilität. Sie werden nicht feststellen, dass DontBlameSendmail-Optionen verwendet werden. Stattdessen werden Sie Einschränkungen an den Dateien sehen, die sendmail schreiben kann, und an den SMTP-Befehlen, die Ihr Server unterstützt alles, um die Sicherheit zu verbessern. Übernehmen Sie diese Sicherheitsrezepte nicht leichtfertig. Das Erhöhen der Sicherheit auf Kosten der Funktionalität und der Flexibilität sollte nur nach sorgfältiger Überlegung geschehen. Achten Sie darauf, dass die Behandlung nicht schlimmer ist als die Krankheit. Alle Sites können davon profitieren, dass die sendmail-software auf dem neuesten Stand gehalten wird, wie in den Rezepten 10.3 und 10.4 beschrieben. Für die meisten Sites bringt es Vorteile, wenn die Anzahl der Systeme beschränkt wird, die eingehende Mail aus dem Netzwerk akzeptieren, wie in den Rezepten 10.1 und 10.2 beschrieben. Viele profitieren wahrscheinlich von der Benutzung von smrsh, die in Rezept 10.6 behandelt wird. Einige der Rezepte in diesem Kapitel bieten jedoch mehr Sicherheit, als die durchschnittliche Site benötigt, vor allem wenn Sie in Betracht ziehen, dass die verbesserte Sicherheit auf Kosten der Funktionalität geht. Diese Rezepte schlagen nicht vor, dass Sie solche Dinge tun sollen, wie die Auslieferung an Dateien oder den Befehl VRFY zu deaktivieren; sie sagen Ihnen, wie Sie diese Dinge erledigen, wenn Sie beschließen, dass sie für Ihr System notwendig sind. Für die meisten Sites ist die Standardsicherheit von sendmail mehr als ausreichend. Links 10.1 Die Anzahl der sendmail-server beschränken Problem Da jedes Netzwerksystem, das eingehende Verbindungen akzeptiert, ein potenzielles Ziel von Angriffen auf die Sicherheit darstellt, wollen Sie die Anzahl der Systeme einschränken, die sendmail ausführen, um die Gefährdung der Sicherheit und den Wartungsaufwand zu verringern. Lösung Wählen Sie eine begrenzte Anzahl von Hosts aus, die als Mail Exchanger und Mail Relay Hosts für Ihr Unternehmen auftreten sollen. Konfigurieren Sie die gewählten Systeme so, wie in Kapitel 2 und in Kapitel 3 beschrieben. Die anderen sendmail-systeme sollten Sie so konfigurieren, wie hier beschrieben. 368 Kapitel 10: sendmail sichern

387 Rechts Erstellen Sie eine Sicherungskopie der Datei submit.mc: # cd /usr/local/src/sendmail /cf/cf # cp submit.mc submit.mc.original Bearbeiten Sie die Datei submit.mc. Fügen Sie das Makro MASQUERADE_AS der Konfiguration hinzu, so dass Antworten auf eine Mail, die vom lokalen Host gesendet wurde, an einen Server mit einem aktiven SMTP-Port gehen, und fügen Sie den Namen des Mail Relay Hosts zum msp-feature-befehl hinzu. Hier sind die aktiven Zeilen in der Datei submit.mc aus der sendmail distribution, nachdem die Änderungen vorgenommen wurden: VERSIONID(`submit.mc modified for recipe 10.1') define(`confcf_version', `Submit') define(` OSTYPE ',`')dnl dirty hack to keep proto.m4 from complaining define(`_use_decnet_syntax_', `1')dnl support DECnet define(`conftime_zone', `USE_TZ') define(`confdont_init_groups', `True')dnl MASQUERADE_AS(`chef.wrotethebook.com') FEATURE(`msp', `chef.wrotethebook.com') Erstellen Sie die Datei submit.cf neu, und starten Sie den MSP-Daemon neu. Hier ist ein Beispiel von unserem Linux-System: #./Build submit.cf Using M4=/usr/bin/m4 rm -f submit.cf /usr/bin/m4../m4/cf.m4 submit.mc > submit.cf ( rm -f submit.cf && exit 1 ) chmod 444 submit.cf # cp submit.cf /etc/mail/submit.cf # kill -HUP `head -1 /var/spool/clientmqueue/sm-client.pid` Bearbeiten Sie das Systemstartskript. Ändern Sie den Befehl, der den sendmail-daemon startet, indem Sie das Flag -bd entfernen. Ändern Sie beispielsweise in: /usr/sbin/sendmail bd q15m /usr/sbin/sendmail q15m Beenden Sie den momentan laufenden Daemon, und starten Sie sendmail ohne das Flag -bd neu: # kill -TERM `head -1 /var/run/sendmail.pid` # /usr/sbin/sendmail q15m Diskussion Die meisten Unix-Startkonfigurationen starten den sendmail-daemon sowohl als SMTP- Listener als auch als Warteschlangen-Prozessor. Die Listener-Funktion, die durch das Kommandozeilen-Flag -bd angefordert wird, bindet sendmail an TCP-Ports, an denen es auf eingehende Mail wartet. 1 Die Option -bd wird nur benötigt, wenn das System einge- 1 Die von sendmail verwendeten Ports können in der Konfiguration geändert werden. Vorgegeben sind jedoch die Ports 25 und Die Anzahl der sendmail-server beschränken 369

388 hende Mail sammelt. Die meisten Unix-Workstations sammeln eingehende Mail nicht. Ein zentraler Server kann die Mail für eine große Anzahl von Workstations sammeln und vorhalten. Die Benutzer der Workstations können die Mail dann mit Werkzeugen wie POP und IMAP abrufen. Den SMTP-Listener auf Server zu beschränken bietet einige Vorteile für die Sicherheit. Wie die Einführung zeigt, bilden SMTP-Server Ziele für Angriffe, da sie Verbindungen und Daten von unbekannten Hosts über den SMTP-Port akzeptieren. Eindringlinge scannen Netzwerke, indem Sie nach Systemen suchen, die auf SMTP-Verbindungen antworten, und richten ihre Angriffe gegen solche Systeme. Einen SMTP-Listener auf einem System auszuführen bedeutet, dass das System zu einem möglichen Ziel wird. Mailserver müssen den SMTP-Listener ausführen; auf anderen Systemen stellt der Listener ein unnötiges Risiko dar. Das Kontrollieren der SMTP-Ports an der Firewall und das Beschränken der Anzahl der Systeme, die an diesen Ports lauschen, bietet mehrstufige Sicherheit (Defense-in-Depth-Ansatz). Falls es einem Administrator nicht gelingt, die Ports an einem Host zu deaktivieren, sollte die Firewall einen Angriff aufhalten. Versagt die Firewall, dann wird durch die Beschränkung der Anzahl der Systeme, die an den SMTP-Ports lauschen, die Anzahl der Ziele beschränkt. Durch das Beschränken der Anzahl der Systeme, die den SMTP-Listener ausführen, wird nicht nur das Risiko verringert, sondern auch die Belastung des Sicherheitsadministrators. Die Rezepte 10.3 und 10.4 sind gute Beispiele dafür. Sie zeigen, wie man Lösungen für sendmail nutzen kann, um einen Angriff abzuwehren, der über den SMTP-Port ausgeführt wird. Jedes System, das eingehende SMTP-Verbindungen akzeptiert, ist durch einen solchen Angriff verwundbar. Falls nur Server an diesem Port warten, benötigen auch nur Server die Sicherheitsmaßnahmen, die zum Schutz vor dieser Schwachstelle erforderlich sind. Eine Site mit Tausenden von Desktop-Workstations könnte nur eine Handvoll gültiger sendmail-server haben. Das Reparieren einiger weniger Server ist einfacher als das Reparieren Tausender von Desktops. Außerdem sind die Kenntnisse der Server-Administratoren im Allgemeinen als hoch zu bewerten. Die meisten dieser Administratoren können Probleme selbst bewältigen. Desktop-Benutzer benötigen dagegen bedeutend mehr Unterstützung. Falls jemand nicht in der Lage ist, eine wichtige Sicherheitslösung richtig anzuwenden, ist das gesamte Netzwerk gefährdet. Die Reduzierung der Anzahl der Systeme, die eine solche sicherheitskritische Reparatur erfordern, ist sicherlich ein Gewinn für die Sicherheit und Wartung. Dieses Rezept beschreibt Änderungen an der submit.cf-konfiguration. submit.cf ist eine besondere Konfiguration, die von sendmail eingesetzt wird, wenn es als Mail-Submission-Programm (MSP) agiert. Die MSP-Konfiguration ist eine Option, die Systemen zur Verfügung steht, die sendmail Version 8.12 und höher ausführen. Wenn die submit.mc- Änderung durchgeführt und sendmail ohne das Flag -bd neu gestartet wurde, ist es nicht notwendig, die sendmail.cf-konfiguration zu aktualisieren. Rezept 10.2 zeigt eine Alternative zu diesem Rezept, die die sendmail.cf-konfiguration anstelle der submit.cf-konfiguration ändert. Links 370 Kapitel 10: sendmail sichern

389 Rechts Wenn ein Empfänger auf eine Nachricht antwortet, die von einem System empfangen wurde, das mit diesem Rezept konfiguriert wurde, muss die Antwort an den Server gehen, weil Antworten, die direkt an die Workstation gehen, fehlschlagen, wenn die Workstation keinen Listener an einem SMTP-Port hat. Antworten können mit MX- Records, mit Maskierung auf der Workstation oder mit Maskierung auf dem Server an den Server geroutet werden, wenn alle ausgehenden Mails durch den Server vermittelt werden wie in der submit.mc-konfiguration dieses Rezepts. Hier wird die Maskierung auf der Workstation verwendet, weil das Beispiel dadurch einfacher wird und alle Konfigurationsänderungen in einer Datei durchgeführt werden können. Die Funktion msp in der submit.mc-datei konfiguriert sendmail als Mail-Submission-Programm. Standardmäßig sendet das MSP Mail an den MTA, indem es eine Verbindung zu einem SMTP-Port an herstellt der Adresse des lokalen Hosts. In diesem Fall muss der lokale Host einen SMTP-Listener ausführen, um ausgehende Mail senden zu können. Das Hinzufügen eines Hostnamens zum msp-befehl FEATURE veranlasst das MSP, eine Verbindung zum SMTP-Port auf dem angegebenen Host herzustellen. Das bedeutet, dass der Client keinen Listener benötigt, um ausgehende Mail zu senden, weil ausgehende Mail direkt vom MSP zum MTA auf dem angegebenen Host geht. In diesem Rezept wird der Hostname chef.wrotethebook.com zum Befehl FEATURE(`msp') hinzugefügt. Deshalb werden alle ausgehenden Mails zur Auslieferung an chef.wrotethebook.com gesandt. chef muss so konfiguriert sein, dass es diese Mail akzeptiert, wie in Kapitel 2 und Kapitel 3 beschrieben. Nach dem Anlegen der neuen Konfiguration bearbeiten Sie die Systemstartdateien, um sicherzustellen, dass sie bei einem Systemneustart keinen SMTP-Listener starten. Die momentan laufende Version von sendmail muss beendet werden, um den aktuellen Listener zu beenden. Schließlich rufen Sie sendmail von der Kommandozeile aus mit dem Flag -q, aber ohne das Flag -bd auf, um einen Queue-Runner zu starten, der die Warteschlange abarbeitet. Siehe auch Rezept bietet ein weiteres Beispiel der submit.mc-konfiguration. Kapitel 1 beschreibt, wie die MSP-Konfiguration während der Installation der sendmail-quellcodedistribution erzeugt wird. Rezept 10.2 enthält eine alternative Lösung, die keine Änderungen an der submit.mc-konfiguration erfordert; lesen Sie zuerst Rezept 10.2, bevor Sie dieses Rezept umsetzen. Die Kapitel 2, 3 und 4 enthalten verwandte Rezepte für Clients, die ausgehende Mails über Server senden, und zum Konfigurieren der Server, so dass sie diese Mail akzeptieren. Das Buch sendmail behandelt die Funktion msp in Abschnitt und das Makro MASQUERADE_AS in Abschnitt Die Anzahl der sendmail-server beschränken 371

390 10.2 Die Anzahl der vom Netzwerk erreichbaren Server begrenzen Links Problem Durch das Akzeptieren von SMTP-Verbindungen aus dem Netzwerk wird ein System zu einem potenziellen Ziel für netzwerkbasierte Angriffe. Es ist eine besondere Konfiguration erforderlich, um zu verhindern, dass der sendmail-daemon eingehende -Verbindungen aus dem Netzwerk akzeptiert. Lösung Wählen Sie eine begrenzte Anzahl von Hosts aus, die als Mail Exchanger und Mail Relay Hosts für Ihr Unternehmen auftreten. Konfigurieren Sie die gewählten Systeme so, wie in den Kapiteln 2 und 3 beschrieben wird. Die anderen sendmail-systeme sollten so konfiguriert werden, wie hier beschrieben. Fügen Sie der sendmail-konfiguration die Funktion no_default_msa hinzu, um zu verhindern, dass sendmail eine Standard-MSA-Konfiguration erzeugt. Erzeugen Sie anschließend mit den DAEMON_OPTIONS-Makros Ihre eigene Konfiguration, die eingehende Mail- Verbindungen auf die Loopback-Adresse begrenzt. Fügen Sie schließlich das Makro MASQUERADE_AS der Konfiguration hinzu, so dass Antworten auf Mail, die vom lokalen Host gesendet wurde, an einen Server gehen, der einen aktiven SMTP-Port besitzt. Hier sind die Beispielzeilen, die in die sendmail-konfiguration eingefügt werden könnten: dnl Don't create a default MSA configuration FEATURE(`no_default_msa') dnl Limit the MSA to the loopback address DAEMON_OPTIONS(`Name=MSA, Port=587, Addr= , M=E') dnl Limit the MTA to the interface DAEMON_OPTIONS(`Name=MTA, Addr= ') dnl Make sure replies go to the mail host MASQUERADE_AS(`chef.wrotethebook.com') Erstellen Sie entsprechend den Anweisungen aus Rezept 1.8 die Datei sendmail.cf neu, und installieren Sie sie. Starten Sie dann sendmail neu. Diskussion Das Makro DAEMON_OPTIONS setzt Werte für die sendmail.cf-daemonportoptions-anweisungen. Eine einfache sendmail-konfiguration weist zwei DaemonPortOptions-Anweisungen auf eine für den MTA-Modus des sendmail-daemons und eine für den MSA-Modus. Ein grep zeigt dies: # grep 'DaemonPortOptions' generic-linux.cf O DaemonPortOptions=Name=MTA O DaemonPortOptions=Port=587, Name=MSA, M=E 372 Kapitel 10: sendmail sichern

391 Rechts Sowohl Port 25, der vom MTA benutzt wird, als auch Port 587, der vom MSA benutzt wird, sind vom Netzwerk aus erreichbar und daher anfällig gegenüber Angriffen aus dem Netzwerk. Dieses Buch enthält viele Beispiele für Verbindungen zu Port 25. Hier ist eines, das die Netzwerkerreichbarkeit von Port 587 demonstrieren soll: $ telnet chef 587 Trying Connected to chef. Escape character is '^]'. 220 chef.wrotethebook.com ESMTP Sendmail /8.12.4; Mon, 29 Sep :45: HELO rodent 250 chef.wrotethebook.com Hello rodent.wrotethebook.com [ ], pleased to meet you MAIL From:<craig@rodent.wrotethebook.com> <craig@rodent.wrotethebook.com>... Sender ok RCPT To:<craig@chef.wrotethebook.com> <craig@chef.wrotethebook.com>... Recipient ok DATA 354 Enter mail, end with "." on a line by itself Subject: 587 test h8tejxrm Message accepted for delivery QUIT chef.wrotethebook.com closing connection Connection closed by foreign host. Der vorgegebene Addr-Wert, der von DaemonPortOptions benutzt wird, ist INADDR_ANY, was bedeutet, dass der Daemon Verbindungen von allen Adressen akzeptiert. Wird eine bestimmte Adresse mit dem Addr-Wert identifiziert, dann werden eingehende Verbindungen auf diese spezielle Adresse beschränkt. Das bedeutet: Bei Addr= werden nur Verbindungen vom lokalen Host akzeptiert, die durch die Loopback-Schnittstelle eingehen, wodurch alle eingehenden Verbindungen aus dem Netzwerk eliminiert werden. Wenn der gerade gezeigte telnet-test nach dem Vervollständigen dieses Rezepts noch einmal ausgeführt wird, ist zu sehen, dass Netzwerkverbindungen nun nicht mehr erlaubt sind: $ telnet chef 587 Trying telnet: connect to address : Connection refused $ telnet chef 25 Trying telnet: connect to address : Connection refused Diese Tests zeigen, dass Netzwerkverbindungen weder an Port 25 noch an Port 587 akzeptiert werden. Vom lokalen Host aus kann jedoch immer noch Mail gesandt werden. Beachten Sie, dass die Funktion no_default_msa benutzt werden muss, bevor die Daemon- PortOptions-Einstellungen des MSA geändert werden können. Das FEATURE-Makro muss vor dem DAEMON_OPTIONS-Makro in der Konfiguration stehen. Diese Funktion ist nicht erforderlich, wenn Sie nur MTA-Werte ändern Die Anzahl der vom Netzwerk erreichbaren Server begrenzen 373

392 Rezept 10.1 stellt eine Alternative zu diesem Rezept dar; es verhindert, dass sendmail SMTP-Verbindungen aus dem Netzwerk akzeptiert. Um genau zu sein, verhindert dieses Rezept, dass sendmail überhaupt SMTP-Verbindungen akzeptiert selbst vom lokalen Host. Rezept 10.1 bietet eine etwas größere Sicherheit als dieses Rezept, da selbst jemand mit einem direkten Zugang zum lokalen Host sendmail nicht über die SMTP-Ports angreifen kann. Allerdings ist Rezept 10.1 komplexer und schwieriger umzusetzen als dieses Rezept. Hier finden alle Änderungen in der sendmail-konfigurationsdatei statt; Rezept 10.1 verlangt Änderungen an der sendmail-konfiguration und an den Systemstartdateien. Das bedeutet: Die verbesserte Sicherheit in Rezept 10.1 sorgt auch für eine erhöhte Komplexität. Links Siehe auch Rezept 7.8 behandelt die Syntax des DAEMON_OPTIONS-Makros und zeigt ein weiteres Beispiel für seine Benutzung. Rezept 10.1 enthält eine alternative Lösung, die die submit.mc- Konfiguration ändert, um ein ähnliches Ziel zu erreichen. Sie sollten zuerst Rezept 10.1 lesen, bevor Sie dieses Rezept umsetzen. Kapitel 4 behandelt das Makro MASQUERADE_AS. Das Buch sendmail behandelt das Makro DAEMON_OPTIONS in Abschnitt , die Funktion no_default_msa in Abschnitt und das Makro MASQUERADE_AS in Abschnitt Eine Aktualisierung durchführen, um Sicherheitslücken zu schließen Problem Sie müssen die Sicherheitslücken von sendmail, die Eindringlinge ausnutzen, genau kennen. Lösung Abonnieren Sie die Mailingliste sendmail-announce, um über wichtige Sicherheits- Updates informiert zu werden. Dazu senden Sie eine Mail an majordomo@lists.sendmail. org, die die folgende Zeile enthält: subscribe sendmail-announce Laden Sie die sendmail-quellcodedistribution herunter, um alle bekannten Sicherheitsprobleme zu beheben. Ausführliche Anweisungen für das Herunterladen der sendmail- Distribution finden Sie in Rezept 1.1. Bauen Sie sendmail neu auf, und kompilieren und installieren Sie es neu, wie in Rezept 1.2 beschrieben. 374 Kapitel 10: sendmail sichern

393 Rechts Diskussion Die größte Gefahr für die Sicherheit von Systemen besteht darin, dass Sie es unterlassen, bekannte Sicherheitsprobleme zu beheben. Eindringlinge nutzen häufig bekannte Sicherheitslücken aus, um Systeme zum Absturz zu bringen oder um sich Zugang sogar root- Zugang zu verschaffen. Wenn Sie sendmail-announce abonnieren, dann erfahren Sie, ob es Sicherheitsprobleme gibt, die Ihr System betreffen. Das Herunterladen, Kompilieren und Installieren der neuen Version von sendmail ist für die Sicherheit wichtig. Siehe auch Die Rezepte 1.1 und 1.2 behandeln das Herunterladen, Kompilieren und Installieren von sendmail. Die Rezepte 1.3 bis 1.7 bieten weitere Beispiele für das Neukompilieren von sendmail. Kapitel 2 des sendmail-buches informiert ausführlich über das Installieren einer aktualisierten Version von sendmail Patches einspielen, um Sicherheitslücken zu schließen Problem Sie müssen Patches einspielen, um bekannte sendmail-sicherheitslücken zu schließen. Lösung Abonnieren Sie die Mailingliste sendmail-announce, um über wichtige Sicherheits-Patches benachrichtigt zu werden. Senden Sie dazu eine Mail an majordomo@lists.sendmail.org, die folgende Zeile enthält: subscribe sendmail-announce Laden Sie den Patch von ftp.sendmail.org oder von herunter. Verwenden Sie den Befehl patch, um den Sicherheits-Patch in den sendmail-quellcode einzuspielen. Kompilieren und installieren Sie sendmail neu, wie in Rezept 1.2 beschrieben; benutzen Sie dazu den um den Patch ergänzten Quellcode. Starten Sie sendmail neu. Zum Beispiel: # kill -HUP `head -1 /var/run/sendmail.pid` Diskussion Das Beheben eines Problems mit einem Quellcode-Patch ähnelt sehr dem Installieren einer völlig neuen sendmail-quellcodedistribution. In beiden Fällen 10.4 Patches einspielen, um Sicherheitslücken zu schließen 375

394 laden Sie Quellcode von sendmail.org herunter. In einem Fall handelt es sich um eine große tar-datei, und im anderen Fall ist es eine kleine Patch-Datei. Das Herunterladen ist ansonsten im Prinzip gleich. laden Sie eine Signaturdatei herunter, um den Quellcode zu überprüfen. benutzen Sie gpg oder pgp, um die heruntergeladene Quelldatei zu überprüfen. kompilieren, installieren und starten Sie sendmail neu. Die größten Unterschiede zwischen den beiden Ansätzen zum Schließen einer Sicherheitslücke sind: Im einen Fall benutzen Sie tar, um einen völlig neuen Quellbaum anzulegen. Im anderen Fall benutzen Sie patch, um Dateien in einem existierenden Quellbaum zu ändern. Welchen Ansatz Sie verwenden, hängt von Ihren persönlichen Vorlieben sowie von der Natur der sendmail-version ab, die gegenwärtig auf Ihrem System installiert ist. Falls Sie eine von einem Hersteller gelieferte sendmail-version benutzen, die einige besondere Funktionen aufweist, dann könnte das Einspielen eines Patches eine Möglichkeit darstellen, ein Sicherheitsproblem zu beheben, während diese Funktionen erhalten bleiben. Natürlich gibt es keine Garantie. Falls der Hersteller die sendmail-quelle allerdings stark verändert hat, könnte der Patch unter Umständen nicht funktionieren. Sollten Sie auf die von dem Hersteller gelieferte sendmail-version angewiesen sein, dann wenden Sie sich wegen der Problemlösung am besten direkt an diesen Hersteller. Für ein System mit Red Hat Linux können Sie beispielsweise die wichtigen Sicherheitslösungen direkt von der Red-Hat-Website beziehen. Abbildung 10-1 zeigt eine Webseite unter redhat.com, die auf die RPM-Dateien verweist, in denen eine sendmail-sicherheitslösung enthalten ist. Dieses Kapitel verwendet ebenso wie der Rest dieses Buches die sendmail-quellcodedistribution anstelle einer Herstellerkopie von sendmail. Speziell sendmail wird in diesem Buch benutzt, da es die neueste Version von sendmail verwendet, die zum Zeitpunkt der Entstehung dieses Buches zur Verfügung stand. Das folgende Beispiel zeigt, wie in sendmail ein Patch eingespielt wird, um ein Sicherheitsproblem zu beheben. Problemlösungen (»Fixes«) für die sendmail-quellcodedistribution können direkt von sendmail.org bezogen werden. Dieses Beispiel beginnt damit, dass der Patch aus dem Verzeichnis pub/sendmail auf ftp.sendmail.org heruntergeladen wird. Die Quellcode-Patch- Datei heißt parse ; die Signaturdatei für die Patch-Datei ist parse sig: # ftp ftp.sendmail.org Connected to ftp.sendmail.org ( ). 220 services.sendmail.org FTP server (Version 6.00LS) ready. Name (ftp.sendmail.org:win): anonymous 331 Guest login ok, send your address as password. Password: win@wrotethebook.com 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Links 376 Kapitel 10: sendmail sichern

395 Rechts Abbildung 10-1: sendmail-problemlösungen, die bei Red Hat verfügbar sind Using binary mode to transfer files. ftp> cd pub/sendmail 250 CWD command successful. ftp> get parse local: parse remote: parse Entering Passive Mode (209,246,26,22,196,166) 150 Opening BINARY mode data connection for 'parse ' (346 bytes). 226 Transfer complete. 346 bytes received in secs (9.6e+02 Kbytes/sec) ftp> get parse sig local: parse sig remote: parse sig 227 Entering Passive Mode (209,246,26,22,196,171) 150 Opening BINARY mode data connection for 'parse sig' (152 bytes). 226 Transfer complete. 152 bytes received in secs (2.2e+02 Kbytes/sec) ftp> quit 221 Goodbye. Überprüfen Sie den Patch mit Hilfe der Signatur-Datei, die Sie von sendmail.org heruntergeladen haben: # gpg --verify parse sig parse gpg: Signature made Thu 18 Sep :17:20 AM EDT using RSA key ID 396F0789 gpg: Good signature from "Sendmail Signing Key/2003 <sendmail@sendmail.org>" 10.4 Patches einspielen, um Sicherheitslücken zu schließen 377