Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einleitung
TEIL I: Einstieg in Linux
2 Die Installation
3 Erste Schritte
4 Linux als Workstation für Einsteiger
TEIL II: Grundlagen
5 Kernel
6 Grundlagen aus Anwendersicht
TEIL III: Die Shell
7 Die Shell
8 Reguläre Ausdrücke
9 Konsolentools
10 Die Editoren
11 Shellskriptprogrammierung mit der bash
12 Die C-Shell
TEIL IV: System- & Netzwerkadministration
13 Benutzerverwaltung
14 Grundlegende Verwaltungsaufgaben
15 Netzwerkgrundlagen
16 Anwendersoftware für das Netzwerk
17 Netzwerkdienste
18 Mailserver unter Linux
19 LAMP & Co.
20 DNS-Server
21 Secure Shell
TEIL V: Die grafische Oberfläche
22 Die grafische Oberfläche
23 Window-Manager und Desktops
24 X11-Programme
25 Multimedia und Spiele
TEIL VI: Systeminterna
26 Prozesse und IPC
27 Bootstrap und Shutdown
28 Dateisysteme
29 Virtualisierung und Emulatoren
TEIL VII: Programmierung und Sicherheit
30 Softwareentwicklung
31 Crashkurs in C und Perl
32 Einführung in Computersicherheit
33 Netzwerksicherheit überwachen
TEIL VIII: Anhang
A Lösungen zu den einzelnen Aufgaben
B Kommandoreferenz
C X11-InputDevices
D MBR
E Buch-DVDs
F Glossar
G Literatur
Stichwort
Ihre Meinung?

Spacer
Linux von Johannes Plötner, Steffen Wendzel
Das umfassende Handbuch
Buch: Linux

Linux
Rheinwerk Computing
1282 S., 5., aktualisierte Auflage 2012, geb., mit 2 DVDs
49,90 Euro, ISBN 978-3-8362-1822-1
Pfeil 18 Mailserver unter Linux
Pfeil 18.1 Mailserver in Theorie und Praxis
Pfeil 18.1.1 Funktionsweise von Internet-Mail
Pfeil 18.1.2 Virenschutz
Pfeil 18.1.3 Spamschutz
Pfeil 18.2 SMTP-Server mit Exim
Pfeil 18.2.1 Die Exim-Philosophie
Pfeil 18.2.2 Exim installieren und konfigurieren
Pfeil 18.2.3 Die Arbeit mit Exim-Tools
Pfeil 18.3 POP3/IMAP-Server mit Courier
Pfeil 18.4 Zusammenfassung

»Interaktive Dienste sollten höher priorisiert werden,
da bei ihnen die Geschwindigkeit direkt erfahren wird!«
– Aus den Weisheiten eines Administrators

18 Mailserver unter LinuxZur nächsten Überschrift

In diesem Kapitel möchten wir einige der vielfältigen Möglichkeiten betrachten, einen Mailserver unter Linux zu betreiben. Bevor wir uns jedoch auf konkrete Konfigurationsdateien stürzen, sollen noch einige Anmerkungen gemacht werden.


Rheinwerk Computing - Zum Seitenanfang

18.1 Mailserver in Theorie und PraxisZur nächsten ÜberschriftZur vorigen Überschrift

Zuerst einmal möchten wir klären, wer überhaupt welchen Mailserver braucht. Normalerweise sind Mailserver nur für Unternehmen mit eigenem IP-Segment und Standleitung interessant – Hobby-Bastler können zwar mit über Nacht laufenden Systemen und DynDNS experimentieren, aber ein produktives System sollte man aufgrund der Ausfallgefahr trotzdem nicht unbedingt aufsetzen. [Fn. Darüber hinaus werden E-Mails von Mailservern aus Dial-up-Pools von den meisten Providern auch gar nicht erst angenommen.]

SMTP versus POP3/IMAP

Auch sprechen wir bei E-Mail in der Regel von zwei Serverklassen: von SMTP-Servern, die Mails entgegennehmen und versenden, und von POP3-/IMAP-Servern, über die die Benutzer ihre Mails abrufen können. In kleinen Umgebungen kann man beide Dienste zwar auch über ein System realisieren, doch gerade in größeren Unternehmen skaliert der verteilte Ansatz besser.


Rheinwerk Computing - Zum Seitenanfang

18.1.1 Funktionsweise von Internet-MailZur nächsten ÜberschriftZur vorigen Überschrift

Wie aber funktioniert »E-Mail« nun konkret? Im Folgenden wollen wir die wichtigsten Schritte vom Schreiben bis zur Auslieferung einer Mail betrachten, um anschließend auf wichtige Features und Techniken gesondert einzugehen.

Das Simple Mail Transfer Protocol

E-Mails versenden

Das Simple Mail Transfer Protocol (SMTP) ist das Protokoll, das seit Urzeiten zum Versenden von E-Mails benutzt wird. Da es textbasiert und für Menschen lesbar arbeitet, kann man die Funktionsweise anhand einer einfachen telnet-Sitzung nachvollziehen. Dazu wird eine Verbindung mit einem Mailserver auf Port 25 aufgebaut, dem Standard-Port für SMTP.

Listing 18.1 Eine SMTP-Sitzung

$ telnet mail.ploetner-it.de 25
Trying 89.110.147.184...
Connected to mail.ploetner-it.de.
Escape character is '^]'.
220 v935.ncsrv.de ESMTP Exim 4.63 Tue, 01 May 2007 13:34:46 +0200
HELO localhost

250 mail.ploetner-it.de Hello localhost
MAIL FROM: test@localhost

250 OK
RCPT TO: jploetner@ploetner-it.de

250 Accepted
DATA

354 Enter message, ending with "." on a line by itself
From: "Ich bin's!" <test@localhost>
To: "Johannes" <jploetner@ploetner-it.de>
CC: xyz@ploetner-it.de
Subject: Dies ist eine Testmail

Hallo.

Dies ist eine normale Testmail mit einem Header und etwas Text.
Nix Besonderes.

MfG
.

250 OK id=1Hiqdl-0007Hn-Am
QUIT

221 mail.ploetner-it.de closing connection
Connection closed by foreign host.

In diesem Beispiel kann man die fünf wichtigsten SMTP-Befehle erkennen: HELO, MAIL FROM, RCPT TO, DATA und natürlich QUIT. Mit HELO stellt sich der versendende Rechner vor, und mittels MAIL FROM und RCPT TO gibt er den Absender beziehungsweise den Empfänger an. Die eigentliche Mail wird dann aber – samt Header! – im DATA-Befehl übertragen.

Der im Beispiel verwendete Beispiel-Mailheader enthält wiederum das eigentliche »From«, »To«, »CC« und »Subject« der Mail. Im Normalfall werden »From« und »To« mit den in MAIL FROM und RCPT TO angegebenen Adressen übereinstimmen – sie müssen es aber nicht. Zwischen dem Header und dem eigentlichen Text der Mail muss eine Leerzeile liegen, abgeschlossen wird der Text durch einen auf einer Zeile einzeln stehenden Punkt. Die Verbindung wird anschließend noch durch ein QUIT korrekt geschlossen.

Nach jedem SMTP-Befehl antwortet der Server mit einem Statuscode. Folgende Statuscodes sind definiert:

  • 1XX
    Bei diesem Statuscode wurde die Eingabe zwar akzeptiert, jedoch ist noch eine Bestätigungsmeldung erforderlich.
  • 2XX
    Der Befehl wurde korrekt und ohne Fehler ausgeführt. Im Beispiellisting wurden ausschließlich 2XX-Codes zurückgegeben.
  • 3XX
    Bei diesem Code benötigt der Mailserver weitere Informationen, um den Befehl ausführen zu können.
  • 4XX
    Dieser Status zeigt einen temporären Fehler oder eine Überlastsituation beim Mailserver an. Zu einem anderen Zeitpunkt kann dieselbe Befehlsfolge durchaus zum Erfolg führen.
  • 5XX
    Dieser Statuscode zeigt einen fatalen Fehler an: Die Ausführung des SMTP- Befehls ist fehlgeschlagen.

Mailversand in der Praxis

Im Folgenden soll nun das SMTP-Protokoll in den richtigen Praxiskontext gesetzt werden. Die einzelnen Schritte beim Versenden einer E-Mail sehen dabei in der Regel wie folgt aus:

  1. Mailclient: Senden an den Smarthost
    Im Mailclient ist konfiguriert, an welchem Mailserver – dem sogenannten Smarthost – alle ausgehenden E-Mails versendet werden sollen. [Fn. Ein Smarthost ist ein E-Mail-Server, der von einem Sender E-Mails annimmt und an beliebige Empfänger weiterleitet.] Der Mailclient verständigt sich mit diesem Server über das SMTP-Protokoll. Steht dieser Server im Internet, so muss sich der Mailcient in der Regel über eines von vielen möglichen Verfahren authentifizieren. Da das ursprüngliche SMTP-Protokoll keine Mechanismen zur Authentifizierung [Fn. Wird der Zugriff auf einen Smarthost nicht eingeschränkt und kann jeder beliebige Internetnutzer über diesen Server E-Mails versenden, so spricht man von einem offenen Relay. Es ist ein großer Fehler, ein offenes Relay einzurichten, da der Server ziemlich schnell von Spammern missbraucht und in der Folge von vielen E-Mail-Anbietern geblockt werden wird.] bietet, wurden später verschiedene Features nachgerüstet. Diese Authentifizierungs-Verfahren kann man nur mit Extended-SMTP (ESMTP) nutzen – das erste Kommando des SMTP-Clients heißt hier dann nicht mehr HELO, sondern EHLO. Je nach SMTP-Server und Konfiguration stehen dann weitere Befehle zur Verfügung, um sich mit dem eigenen Benutzernamen und Passwort einzuloggen. Erst danach kann mit MAIL FROM und den anderen Befehlen eine E-Mail verschickt werden.
  2. Smarthost: Lookup des Empfängers
    Damit der Smarthost dem Empfänger die E-Mail zustellen kann, muss er wissen, welcher Server überhaupt für die Domain des Empfängers zuständig ist. Dazu ruft er aus dem DNS den MX-Record der Domain des Empfängers ab.
  3. Listing 18.2 Den MX-Record per Hand aus dem DNS abfragen

    $ host -t MX ploetner-it.de
    ploetner-it.de mail is handled by 10 mail.ploetner-it.de.

    Anschließend wird die E-Mail mittels SMTP an diesen Server übertragen.

  4. Optional: Sender Policy Framework (SPF)
    Der Mailserver des Empfängers kann durch das Sender Policy Framework feststellen, ob der sendende Mailserver überhaupt autorisiert ist, Mails für eine bestimmte Domain zu versenden. Welche Systeme zum Versenden von E-Mail einer Domäne berechtigt sind, ist aus dem SPF- oder TXT-Record des DNS-Eintrags der Domain ersichtlich:
  5. Listing 18.3 Den SPF-Record per Hand aus dem DNS abfragen

    $ host -t TXT gmx.de
    gmx.de descriptive text "v=spf1 ip4:213.165.64.0/23 -all"

    Dieses Beispiel zeigt, dass für die Domain gmx.de nur Rechner aus dem Netz 213.165.64.0/23 Mails verschicken dürfen. Ein Mailserver, der SPF unterstützt, wird also keine Mails mit einer GMX-Absenderadresse annehmen, wenn diese von anderen Rechnern verschickt werden. [Fn. Darum sollten Sie sich auch hüten, Mails von solchen »fremden« Adressen über einen selbst betriebenen E-Mail-Server zu verschicken.]

    Allerdings wird SPF nicht von allen Mailservern unterstützt oder genutzt, da es durchaus einige Probleme und Kritikpunkte an diesem Verfahren gibt: Beispielsweise ist das automatische Weiterleiten von E-Mails schwierig, da der weiterleitende Rechner unter Umständen nicht per SPF autorisiert ist, entsprechende Absenderadressen zu verwenden. Abhilfe schafft hier jedoch ein Whitelisting (siehe Abschnitt Whitelist) des Servers beziehungsweise der Absenderadressen auf dem Mailserver, der die weitergeleiteten Mails empfängt.

    Mails abholen

  6. Mailserver: Mails abholen mit POP3 oder IMAP
    Auf dem Zielsystem angekommen, müssen die Mails noch vom Empfänger abgeholt werden. Für diesen Vorgang kommt nicht SMTP, sondern ein anderes Protokoll – in der Regel POP3 oder IMAP – zum Einsatz. Über eines der beiden Protokolle wird sich der E-Mail-Client des Empfängers mit dem Server verständigen, um sich über die Anzahl ungelesener E-Mails informieren zu lassen und diese gegebenenfalls auch herunterzuladen.

SMTP-Server müssen nun aber oft mehr leisten, als E-Mails einfach nur korrekt weiterzuleiten beziehungsweise auszuliefern. Gerade in Produktivsystemen mit vielen Nutzern ist es wichtig, böswilligen Content bereits frühzeitig auszufiltern. Virenscanner sind dabei ein wichtiger Baustein.


Rheinwerk Computing - Zum Seitenanfang

18.1.2 VirenschutzZur nächsten ÜberschriftZur vorigen Überschrift

ClamAV

Der bekannteste Virenscanner für Linux ist sicherlich die Open-Source-Software ClamAV. Sie kann als Bibliothek in eigene Programme eingebunden werden, steht jedoch auch als Dämon und als Kommandozeilenprogramm zur Verfügung. Neben ClamAV gibt es für Linux noch weitere Virenscanner wie beispielsweise VirusScan von McAfee. Jedoch sollte man nicht vergessen, dass diese Scanner fast ausschließlich nach Viren für »Fremdbetriebssysteme« suchen und deshalb auch vor allem auf Mail- oder Fileservern eingesetzt werden.


Rheinwerk Computing - Zum Seitenanfang

18.1.3 SpamschutzZur nächsten ÜberschriftZur vorigen Überschrift

Ein weiterer wichtiger Punkt ist der Schutz vor Spam. Kaum ein Mailserver kommt heute noch ohne effektiven Spamfilter aus. Der unter Linux und anderen Unix-Systemen am häufigsten eingesetzte Spamfilter ist SpamAssassin. Die Perl-basierte Software kann mit vielen verschiedenen SMTP-Servern, aber teilweise auch mit Mailclients eingesetzt werden, um eingehende E-Mails auf Spam zu untersuchen.

SpamAssassin wendet auf jede Mail einen ganzen Satz von Regeln an. Jedes Zutreffen einer Regel führt zur Vergabe eines bestimmten Punktwerts, und erst wenn die Summe der Punkte einen gewissen Schwellenwert übersteigt, wird die Mail als Spam gekennzeichnet. Je nach Konfiguration werden die Mails in diesem Fall mit einem bestimmten Betreff (beispielsweise **** SPAM ****) oder einen speziellen Header-Eintrag entsprechend markiert.

Reguläre Ausdrücke

Normale SpamAssassin-Regeln sind eigentlich nichts weiter als reguläre Ausdrücke. [Fn. Falls Sie selbst Regeln schreiben wollen: Regulären Ausdrücken haben wir das ganze Kapitel 8 gewidmet.] Eine einfache Regel kann dabei beispielsweise so aussehen:

Listing 18.4 Regel im SpamAssassin

body     FB_HARD_ERECTION  /hard(?:er)? (?:erection|penis)/i
score FB_HARD_ERECTION 2.169

Der Name der Regel ist hier FB_HARD_ERECTION. Wird in der Mail ein Text wie »harder erection« gefunden, auf den der reguläre Ausdruck passt, so werden zum aktuellen Score der E-Mail 2,169 Punkte addiert. Da der Standard-Schwellenwert meist bei 5 Punkten liegt, ist dann die Grenze zur Markierung als »Spam« schnell überschritten. Solche Regeln kann man auch recht einfach selbst schreiben, allerdings erfordern die Punkte-Bewertung und die genaue Gestaltung des regulären Ausdrucks ein hohes Maß an Fingerspitzengefühl und Erfahrung.

Bayes-Filter

Statistisches Filtern

In SpamAssassin kann aber auch ein sogenannter Bayes-Filter zum Einsatz kommen. Dieser statistische Filter schließt anhand von charakteristischen Wörtern in einer E-Mail auf die Wahrscheinlichkeit, dass es sich bei ihr um Spam handelt. Damit ein Bayes-Filter ordentlich funktionieren kann, muss man ihn »trainieren«: Man gibt SpamAssassin eine Mailbox voller Spam sowie eine Mailbox voller »Ham« (also Nicht-Spam, normale Mails). Anhand dieser Charakteristiken wird dann eine Bayes-Datenbank aufgebaut, mithilfe derer dann die Wahrscheinlichkeit ermittelt werden kann, dass es sich bei einer untersuchten E-Mail um Spam handelt. Je nach Wahrscheinlichkeit können dann wieder unterschiedliche Punktwerte vergeben werden. [Fn. Dabei sind für geringe Wahrscheinlichkeiten natürlich auch negative Werte möglich, um den Score insgesamt etwas abzusenken.]

White- und Blacklists

Auch eine Art »Regel« stellen White- und Blacklists dar. In einer Whitelist sind alle Absender oder Absenderdomains eingetragen, denen man vertraut und von denen man keinen Spam erwartet. Diese Mails sollen also – unabhängig von ihrem Inhalt – immer unmarkiert ankommen. Im Gegensatz dazu kann man über Blacklists bestimmte Absender oder ganze Domains von vornherein sperren. Natürlich gliedern sich auch White- und Blacklists in das Punkteschema des SpamAssassins ein. So vergeben Whitelists normalerweise –100 und Blacklists 100 Punkte.

Greylisting

Temporäres Zurückweisen

Greylisting beschreibt ein relativ neues Konzept, mit dem Spam effektiv abgewehrt kann. Die Idee hinter Greylisting ist, eine E-Mail beim ersten Zustellungsversuch temporär abzuweisen. »Echte« SMTP-Server werden die Zustellung nach einer gewissen Zeit erneut versuchen, während von fiesen Spammern gekaperte Rechner diesen Zustellungsversuch wahrscheinlich nicht erneut unternehmen.

[zB]Im Detail ist der Ablauf beim Greylisting wie folgt:

  1. SMTP-Verbindung des Absenders
    Die Verbindung des Absenders läuft bis zum RCPT-TO:-Schritt genau so ab wie in obigem Beispiel. Danach allerdings wird ein temporärer Fehler gemeldet:
  2. Listing 18.5 Eine SMTP-Sitzung

    $ telnet mail.ploetner-it.de 25
    Trying 89.110.147.184...
    Connected to mail.ploetner-it.de.
    Escape character is '^]'.
    220 v935.ncsrv.de ESMTP Exim 4.63 Tue, 01 May 2007 13:34:46 +0200
    HELO localhost
    250 mail.ploetner-it.de Hello localhost
    MAIL FROM: johannes.ploetner@de.clara.net
    250 OK
    RCPT TO: jploetner@ploetner-it.de
    451-212.82.240.100 is not yet authorized to deliver mail from
    451 <johannes.ploetner@de.clara.net> to <jploetner@ploetner-it.de>.

    Please try later.

    Zu diesem Zeitpunkt kennt der Greylisting einsetzende Empfänger drei Daten: die Absender-IP-Adresse, von der die Verbindung stammt, den Absender sowie den Empfänger der Mail. Dieses Tripel wird nun gespeichert.

  3. Warteschlange
    Der Absender ist laut SMTP-Protokoll verpflichtet, den Zustellungsversuch nach einer gewissen Zeit (meist ist eine halbe Stunde eingestellt) zu wiederholen. Sollte dieser Versuch wieder fehlschlagen, wird die Zeit bis zum nächsten Versuch meist etwas erhöht.
  4. Zweiter Versuch
    Beim zweiten Versuch des absendenden Mailservers hat der Empfänger das Tripel (Absender-IP, Absender-E-Mail, Empfänger-E-Mail) schon in seiner Datenbank und wird diesen Zustellversuch annehmen.
  5. Whitelists
    Normalerweise wird das betreffende Tripel nach einer solchen erfolgreichen Zustellung noch in eine temporäre Whitelist eingetragen, damit bei einer erneuten Kommunikation des betreffenden Absenders mit dem zugehörigen Empfänger für die Dauer des Whitelistings keine temporäre Zurückweisung mehr erfolgt.

Spam-Erkennung zur Versandzeit

Error nach DATA

Normalerweise werden E-Mails erst nach dem Empfang auf Spam gescannt und gegebenenfalls in einen separaten Spam-Ordner verschoben oder gleich ganz gelöscht. Eine Alternative dazu ist das Scanning zur Versandzeit SMTP-time filtering). Dabei wird, während vom versendenden Host noch die DATA-Sektion gesendet wird, die E-Mail bereits auf Spam gescannt. Wird eine Spam-Mail vermutet, bekommt dies der versendende Host direkt nach der DATA-Sektion als Error-Code zurückgeliefert. Normalerweise hat der SMTP-Server, der die Mail nicht ausliefern konnte und den Fehlercode empfing, dann eine Error-Mail an den Absender zu schicken. Diese Mail soll den Absender informieren, dass sein Zustellversuch fehlgeschlagen und die E-Mail nicht angekommen ist.

Im Folgenden wollen wir nun eine Möglichkeit betrachten, wie man unter Linux einen SMTP- oder POP3/IMAP-Server aufsetzen kann. Aufgrund der vielfältigen Softwareprojekte kann man die hier vorgestellte Funktionalität aber auch mit ganz anderen Komponenten realisieren.



Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück
 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Rheinwerk-Shop: Linux Handbuch






 Linux Handbuch


Zum Rheinwerk-Shop: Linux Server






 Linux Server


Zum Rheinwerk-Shop: Raspberry Pi






 Raspberry Pi


Zum Rheinwerk-Shop: Ubuntu 14.04 LTS






 Ubuntu 14.04 LTS


Zum Rheinwerk-Shop: Roboter bauen mit Arduino






 Roboter bauen
 mit Arduino


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2012
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: 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.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern