Sendmail gilt zu Unrecht als nicht beherrschbares Ungetüm – dieser Workshop beweist es. Etwas strukturierte Arbeitsweise vorausgesetzt können Sie mit dem Oldie unter den MTAs flexible und wirksame Antispam- und Antivirenlösungen aufbauen.

Wer ein echter Unix-Administrator sein will, muss einmal in seinem Leben Sendmail konfiguriert haben – wer es ein zweites Mal tut, ist verrückt. Solche Sprüche sind lustig, verkennen aber die Realität. In mehr als 20 Jahren Entwicklungszeit (siehe Kasten “Sendmails Geschichte”) ist Sendmail [1] zu einem robusten und zuverlässigen Mail Transport Agent (MTA) herangewachsen, für den es viele Zusatzprodukte und Addons gibt.

Dieser Artikel erläutert neben der sicheren Grundkonfiguration auch drei praktikable Antispam- und Antivirus-Szenarien. Am Schluss diskutiert er ein viertes, radikales Szenario, bei dem das Spam-Aufkommen auf praktisch null absinkt. Die vollständigen Konfigurationsdateien sind unter [2] abrufbar.

Vorspeise

Stellvertretend für andere Distributionen benutzt dieser Workshop Debian 3.1 Sarge, die Unterschiede zu anderen Linux-Systemen sind marginal. Die zentralen Komponenten zum Versand von E-Mails installieren Sie mit »apt-get install sendmail sasl2-bin libsasl2-dev«. Die Installationsroutine gibt dabei Hinweise für die weitere Konfiguration, der Kasten “Sendmail-Konfiguration” ebenso.

Um kein Open Relay für Spam-Versender zu schaffen, stellen Sie Sendmail so ein, dass es nur Mails versendet, wenn ein Benutzer sich authentisiert hat. (Andere Restriktionen, die beispielsweise das Versenden von E-Mails an eine IP-Adresse binden, sind natürlich auch möglich.) Zuständig für die Authentisierung ist der Saslauthd [3]. Um ihn dauerhaft zu aktivieren, setzen Sie in »/etc/default/saslauthd« den Parameter »START=yes«. Danach lässt er sich mit »/etc/init.d/saslauth start | stop | restart« steuern.

Um Fehlkonfigurationen in Sendmail schneller zu erkennen, lohnt es, den Loglevel in der »sendmail.mc« zu erhöhen: »define(`confLOG_LEVEL\’,`15\’)dnl«. Fehlermeldungen gibt Sendmail normalerweise in »/var/log/syslog« beziehungsweise »/var/log/mail.info« aus. Um die SMTP-Authentisierung zu aktivieren, führen Sie – wie es das Installationsprogramm vorschlägt – »/usr/share/sendmail/update_auth« aus und tragen »include(`/etc/mail/sasl/sasl.m4\’)dnl\’« in die »sendmail.mc« ein.

Von Haus aus ist Sendmail nur am Loopback-Interface 127.0.0.1 aktiv. Um E-Mails auch von anderen Clients aus verwenden zu können, müssen Sie Sendmail an eine externe IP-Adresse binden. Dazu ersetzen Sie »127.0.0.1« durch die echte IP-Adresse des Mailservers »\’DAEMON_OPTIONS(`Family=inet, Name=MSP-v4, Port=submission, Addr =IP-Adresse \’)dnl\’«.

Danach muss der Administrator die Konfigurationsdateien durch den Aufruf »sendmailconfig« neu generieren. Beim ersten Start gibt es einige Start-TLS-Fehlermeldungen, die beseitigen Sie später. Ob alles bis hierhin funktionsfähig ist, überprüfen Sie leicht mit Telnet:

telnet mailserver 25
Mail FROM: bill.gates@microsoft.com
RCPT To: root@kernel.org

Wenn alle Einstellungen korrekt sind und Sie Sendmail neu gestartet haben, antwortet der Server mit: »Relaying denied. Proper authentication required.«

Gut gesichert verschicken

Bevor der Benutzer E-Mails versendet, muss er sich mit Benutzernamen und Kennwort authentisieren. Der Prozess sollte unbedingt verschlüsselt ablaufen, um Passwortmissbrauch zu verhindern. »include(`/etc/mail/tls/starttls.m4\’)dnl« aktiviert den Start-TLS-Mechanismus und »define(`confCRL\’, `/etc/mail/tls/revocation.list\’)dnl« definiert eine Widerrufsliste für Zertifikate. Die Widerrufsliste legen Sie mit

touch /etc/mail/tls/revocation.list && chmod 600 /etc/mail/tls/revocation.list

an und schützen sie gegen unbefugte Zugriffe. Die SSL-Zertifikate sollten auf jeden Fall von einer vertrauenswürdigen Certificate Authority unterschrieben sein, um Fehlermeldungen im E-Mail-Client und damit das Abstumpfen der Benutzer gegenüber Sicherheitsmaßnahmen zu verhindern.

Die vertrauenswürdige CA kann auch organisationsweit sein, dann muss allerdings das Root-Zertifikat auf jedem Client installiert sein. Um zu überprüfen, ob die Verschlüsselung funktioniert, eignet sich ein Netzwerksniffer. Normalerweise dürfen Sie dem Verschlüsselungssymbol des E-Mail-Clients aber vertrauen, beispielsweise dem Schloss.

Ein MTA kann nur senden

Die Benutzer wollen E-Mails natürlich auch empfangen. Sendmail leitet Mails nicht selbstständig in die Mailboxen der Benutzer weiter, dazu bedarf es eines Mail Delivery Agent. Dieser Workshop verwendet Procmail [6] als MDA, alternativ wären auch Maildrop [7] oder das direkte Ausliefern an den Cyrus-IMAP-Server möglich.

Die Benutzer sollen ihre E-Mails über IMAP oder POP3 beziehungsweise IMAPs oder POPs abholen. Dazu benötigt man einen entsprechenden Server. Sehr sicher und flexibel ist der Dovecot-Mailserver [8]. Er kann sowohl mit Mbox als auch mit dem Maildir-Format umgehen und ist leicht zu konfigurieren.

Ältere Installationen setzen oft noch das Mbox-Format ein. Auch wenn es einige Nachteile gegenüber Maildir hat, müssen Sie es nicht unbedingt ändern, wenn es seit Jahren funktioniert und Sie den Unmut der Benutzer scheuen. Die Konfiguration der Datei »/etc/dovecot.conf« ist sehr einfach, siehe Listing 1. Eine globale Beispielkonfiguration für Procmail zeigt Listing 2; Benutzer-individuelle Optionen gehören jeweils in die »~/.procmailrc«-Dateien.

01 protocols = imap imaps pop3 pop3d
02 default_mail_env = mbox:~/mail/mbox
03 ssl_cert_file = /etc/ssl/certs/dovecot.pem
04 ssl_key_file = /etc/ssl/private/dovecot.pem
05 default_mail_env = mbox:~/mail/mbox

01 PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin
02 MAILDIR=$HOME/mail # Verzeichnis muss existieren
03 DEFAULT=$MAILDIR/mbox # MTA benutzt das Mbox-Format
04 LOGFILE=$MAILDIR/procmail.log # Logdatei

Nach Inbetriebnahme des IMAP-POP3-Servers können die Benutzer nun E-Mails empfangen – leider zu viele. Ohne Spamfilter müssten die Benutzer alle unerwünschten E-Mails manuell aussortieren, was höchst unökonomisch wäre. Eine Strategie sind DNS-Blacklisten (DNSRBL), auf denen die IPs von Spam-Versendern stehen. Diese Listen sind direkt in Sendmail integrierbar. Danach verweigert der Mailserver sofort die Annahme der solcher Mail.

Blacklisten allein sind heikel

Der Nachteil an dieser Lösung ist, dass manchmal auch große E-Mail-Provider wie GMX oder Web.de auf diesen Blacklisten stehen. Um dem Verlust von Mails vorzubeugen, ist es sicherer, einen Spamfilter mit DNSRBLs zu kombinieren und entsprechende Bewertungskriterien einzustellen. Andererseits helfen Blacklists gegen Wörterbuchangriffe. Hier probiert der Spammer mit Brute Force E-Mails an Benutzer zu schicken, ohne vorher zu wissen, ob diese überhaupt existieren. Wer DNSRBLs aktivieren will, kann dies zum Beispiel so tun:

FEATURE(`dnsbl', `relays.ordb.org', `"557 Rejected " $&{client_addr} " - see http://ordb.org/')dnl

Weitere kostenfreie Listen finden Sie in Tabelle 1 sowie unter [9] und [10].

Mach mal Pause

Ein sehr schlecht dokumentiertes, aber wirkungsvolles Feature im Kampf gegen Spam ist der »greet_pause«-Parameter. Er arbeitet ähnlich wie Greylisting, bei dem der Server beim ersten Mal behauptet, dass ein temporärer Fehler aufgetreten sei [11]. Bei »greet_pause« reizt Sendmail dagegen nur die SMTP-Spezifikation aus und antwortet langsamer, ohne einen vorgetäuschten Fehler. Laut RFC 2821 [12] sind bis zu fünf Minuten Verzögerung erlaubt. Der Parameter definiert die Zeitspanne, die Sendmail beim Entgegennehmen von Kommandos abwartet. Spammer haben es aber eilig und brechen die Verbindung oft ab, wenn der Mailserver sich nicht schnell zurückmeldet. Allerdings gibt es auch größere Provider wie Gmail, die dann keine Mails mehr zustellen.

Sie aktivieren das Feature mit »FEATURE(`greet_pause\’, `5000\’)dnl«, dies führt zu fünf Sekunden Verzögerung. Ausnahmen für bestimmte Bereiche definieren Sie über die »/etc/mail/access« (siehe Listing 3) und aktivieren sie mit »FEATURE(`access_db\’)dnl«. Aus der »access«-Datei müssen Sie die »access_db« generieren. Dazu führen Sie im »/etc/mail«-Verzeichnis einfach »make« aus. Sendmail brauchen Sie nicht neu zu starten, die Änderungen werden nach Erzeugung der Datenbank sofort aktiv.

01 GreetPause:my.domain 0
02 GreetPause:example.com 5000
03 GreetPause:10.1.2 2000
04 GreetPause:127.0.0.1 0

Eine Option, die nur wirksam ist, wenn es zu viele ungültige Empfänger in einer E-Mail gibt, ist »define(`confBAD_RCPT_THROTTLE\’,`2\’)dnl«. Sie bewirkt, dass bei zwei ungültigen Empfängern in einer SMTP-Transaktion, sich die Verbindung künstlich verlangsamt. Beide Einstellungen sind jede für sich allein nicht besonders effektiv. Um mehr Wirkung zu erzielen, benötigt es etwas mehr Planung. Im Folgenden werden drei Lösungen zur Konfiguration eines Antispam- und Antiviren-Gateway gezeigt.

Bevor Sie eine der folgenden Lösungen installieren, sollte Sie sich die juristische Seite vergegenwärtigen. So unterliegen E-Mails beispielsweise in Deutschland dem Post- und Fernmeldegeheimnis. Wer sie löscht, macht sich unter Umständen nach Paragraph 206 StGB strafbar.

Darum sollte in den Arbeitsverträgen der Mitarbeiter klar definiert sein, dass alle E-Mails, die den Firmen-Mailserver passieren, Eigentum der Firma sind und von ihr unter Umständen verändert oder gelöscht werden können. Dies gilt sowohl für Spam als auch für virenverseuchte E-Mails. Um rechtliche Unsicherheit zu vermeiden, sollte der Mailserver Spam nicht löschen, sondern nur markieren. Dann kann der Benutzer Client-seitig selbst entscheiden, wie er Spam behandelt.

Ein Interface verbindet

Amavisd-new [13] ist ein Interface zwischen MTA und Contentfilter, also Virenscanner und/oder Spamassassin. Amavis ist für viele MTAs in verschiedenen Konfigurationen erhältlich und bietet zudem eine Schnittstelle zum Anfertigen von Statistiken.

Sicherheitstechnisch ist Amavis wenig bedenklich, da es als Perl-Programm für Buffer Overflows nicht so anfällig ist. Die relativ wenigen Sicherheitshinweise auf Seiten wie Securityfocus und Frsirt [14] untermauern diese These. Amavis läuft im Normalfall nicht mit Root-Rechten, kann im Chroot arbeiten und bietet diverse Konfigurationsmöglichkeiten, um Denial-of-Service-Angriffe durch Mailbomben zu verhindern.

Sie installieren das Interface ganz einfach mit »apt-get install amavisd-new«. Da Amavis standardmäßig auf Viren prüft, sollten Sie einen Virenscanner gleich mitinstallieren. Die Konfiguration erfolgt in der »/etc/amavis/amavisd.conf«, die Optionen hängen vom Einsatzszenario ab. Vorher müssen Sie jedoch die Sendmail-Installation anpassen.

Es gibt mehrere Möglichkeiten, Amavis an Sendmail anzubinden. Zu empfehlen ist die Sendmail-Dual-Variante, die Abbildungen 1 bis 3 zeigen sie. Amavis nimmt dabei E-Mails über Port 10024 am lokalen Interface vom ersten Sendmail-Prozess an und leitet sie nach einer Überprüfung an die zweite Sendmail-Instanz weiter, die auf Port 10025 lauscht.

Abbildung 1: Einfach, aber relativ unflexibel: Sendmail und Amavis handhaben die Spam- und Virenabwehr allein.

Abbildung 2: Flexibleres, datenbankgestütztes Setup aus Sendmail, Amavisd und Maia.

Abbildung 3: Im Maia-Webfrontend verwaltet jeder Mail-Benutzer seine eigene Konfiguration – hier Blacklisten.

Sendmail dual

Der Betrieb von Amavis erfordert zwei Sendmail-Prozesse, die separate Queues verwalten. Ein Prozess managt den Empfang (MTA-RX), der zweite den Versand von E-Mails (MTA-TX), dazwischen arbeitet Amavisd-new als Spam- und Virenprüfer. Der MTA-RX-Prozess hört auf TCP Port 25, seine Konfiguration bezieht er aus »/etc/mail/sendmail-rx.cf« und »/etc/mail/submit.cf« sowie dem Sourcefile »/etc/mail/hostname-rx.mc«.

Das Verzeichnis für die Mailqueue legen Sie mit »mkdir /var/spool/mqueue-rx« an. Für die richtigen Zugriffsrechten sorgt:

chown root:amavis /var/spool/mqueue-rx && chmod 700 /var/spool/mqueue-rx

Als Nächstes definieren Sie einen eigenen so genannten Control Socket, da sich andernfalls beide Sendmail-Prozesse zu streiten beginnen:

define(`confCONTROL_SOCKET_NAME',`/var/run/sendmail/mta/smcontrol-rx')dnl

Der MTA-TX-Prozess bindet sich an Port 10025 am lokalen Interface und verwendet die normale Mailqueue und Konfigurationsdatei. Als vereinheitlichtes Sourcefile dient der Übersicht wegen »/etc/mail/Hostname-tx.mc«. Alle Einstellungen zum Empfang von E-Mails inklusive Ressourcenlimits definieren Sie in »hostname-rx.mc«.

Alles was den Versand betrifft, egal ob lokal oder nicht, steuern Sie in »hostname-tx.mc«. Ein Vorteil der Sendmail-Dual-Installation ist, dass der MTA-RX, der aus dem Internet direkt erreichbar ist, nicht mit Root-Rechten zu laufen braucht, da er nicht auf die Homeverzeichnisse der User zugreifen muss. Die Konfigurationsoptionen sind Listing 4 und 5 zu entnehmen.

01 define(`confPID_FILE', `/var/run/sendmail-rx.pid')dnl Non-default pid file
02 define(`STATUS_FILE', `/etc/mail/stat-rx')dnl Non-default stat file
03 define(`QUEUE_DIR', `/var/spool/mqueue-rx')dnl Non-default queue area
04 define(`confQUEUE_SORT_ORDER',`Modification')dnl Modif or Random are reasonable
05 FEATURE(stickyhost)dnl Keep envelope addr "u@local.host" when fwd to MAIL_HUB
06 define(`MAIL_HUB', `esmtp:[127.0.0.1]')dnl Forward all local mail to amavisd
07 define(`SMART_HOST',`esmtp:[127.0.0.1]')dnl Forward all other mail to amavisd
08 define(`confDELIVERY_MODE',`q')dnl
09 define(`ESMTP_MAILER_ARGS',`TCP $h 10024')dnl To tcp port 10024 instead of 25
10 MODIFY_MAILER_FLAGS(`ESMTP', `+z')dnl Speak LMTP (this is optional)
11 define(`SMTP_MAILER_MAXMSGS',`10')dnl Max no. of msgs in a single connection
12 define(`confTO_DATAFINAL',`20m')dnl 20 minute timeout for content checking
13 DAEMON_OPTIONS(`Name=MTA-RX')dnl Daemon name used in logged messages
14 MAILER(`smtp')dnl

01 define(`confREFUSE_LA',999)dnl Disable the feature, limiting belongs to MTA-RX
02 define(`confMAX_DAEMON_CHILDREN',0)dnl Disable, limiting belongs to MTA-RX
03 FEATURE(`no_default_msa')dnl No need for another MSA, MTA-RX already has one
04 DAEMON_OPTIONS(`Addr=127.0.0.1, Port=10025, Name=MTA-TX')dnl Listen on lo:10025

Formwandler

Wenn die nötigen Einstellungen getroffen sind, wandeln Sie die »*.mc«-Dateien wieder in Konfigurationsdateien um. Dies funktioniert allerdings nicht mehr mit »sendmailconfig«, sondern so:

m4 /usr/share/sendmail/cf/m4/cf.m4 /etc/mail/hostname-rx.mc > /etc/mail/sendmail-rx.cf
m4 /usr/share/sendmail/cf/m4/cf.m4 /etc/mail/hostname-tx.mc > /etc/mail/sendmail.cf

Sendmail lässt sich ab nun auch nicht länger über »/etc/init.d/sendmail start | stop | restart« steuern. Der Start erfolgt durch diese drei Befehle:

/usr/sbin/sendmail -C /etc/mail/sendmail-rx.cf -L sm-mta-rx -bd -qp
/usr/sbin/sendmail -L sm-mta-tx -bd -q15m
/usr/sbin/sendmail -Ac -L sm-msp-queue -q10m

Der MSP-Prozess ist für das Senden von Mails von der Konsole aus zuständig. Um Konflikte zu vermeiden, sollten Sie das Init-Skript deaktivieren oder entsprechend umschreiben. Startet Sendmail korrekt, muss der Amavisd, falls nicht bereits geschehen, auch starten. Andernfalls kommt keine Verbindung zwischen den beiden Sendmail-Prozessen zu Stande. Ist noch kein Virenscanner installiert, müssen Sie in der »/etc/amavis/amavisd.conf« den Kommentar vor der Zeile»# @bypass_virus_checks_acl = qw( . );« entfernen.

Scanner gegen Schadsoftware

In den meisten Netzwerke stehen auch Windows-PCs, daher sollte der Mailserver E-Mails auf Viren scannen. Ein kostenloser Open-Source-Virenscanner ist Clam-AV, für den es täglich Signaturupdates gibt. Er ist für viele Linux-Distributionen als Binärpacket erhältlich. Leider ist er in jüngster Zeit durch einige schwere Sicherheitsprobleme negativ aufgefallen und daher nur bedingt eine Empfehlung. Über Amavisd-new ist es sehr einfach möglich, mehrere Virenscanner parallel zu betreiben, eine Übersicht über gängige ist in [15] zu finden.

Lösung 1: Amavis allein zu Haus

Die einfachste und zugleich unflexibelste Möglichkeit zur Spam- und Virenbekämpfung ist die ausschließliche Verwendung von Amavis (Abbildung 1). Das Interface bindet Spamassassin, dessen Plugins und ein Antivirenprogramm automatisch ein. Die Optionen dafür sind vielfältig. Ohne die Variable » funktioniert fast nichts – die belegen Sie zuerst. Zur Fehlersuche und Logauswertung passen Sie » und » auf geeignete Werte an.

Dann überlegen Sie, was mit Spam- und Virenmails passieren soll, und definieren » und » entsprechend. Möglich sind »D_PASS«, »D_DISCARD«, »D_BOUNCE>« und »D_REJECT«, verantwortungsbewusste Admins verzichten wegen der gefälschten Absenderadressen auf »D_BOUNCE« und »D_REJECT«.

Spamassassin steuern Sie bei dieser Lösung über die »*«-Parameter, die weitgehend selbsterklärend sind. Um jede Mail mit einem X-Spam-Header zu kennzeichnen, setzen Sie » = -999«. Damit die Benutzer Spam sofort am E-Mail-Betreff erkennen, ist ein aussagekräftiges » sinnvoll. Zur Verbesserung der Erkennungsrate soll Amavis auch externe Quellen (Blacklists, DCC, Razor, Pyzor) heranziehen. Dies passiert mit Setzen der Option » = 0«.

Für », der für die Markierung als Spam/Nicht-Spam sorgt, hat sich ein Wert zwischen »2« und »2.5« als sinnvoll erwiesen. Treten False Positives auf, müssen Sie ihn vorsichtig nach oben korrigieren. Über die Option » können Sie steuern, ab welcher Größe Amavis E-Mails nicht mehr auf Spam überprüft – große Mails sind selten Spam.

Die Option » stellt die Sekunden ein, die Amavis auf Spamassassin wartet, bevor es E-Mails weiterreicht. Die White- und Blacklisten sowie die Empfänger, die keine Spam-Überprüfung (») wünschen, sind flexibel konfigurierbar. Whitelisten bleiben gleichwohl wegen der gefälschten Absenderadressen problematisch.

Scanner-Kaskade

Die Lösung 1 kann auch auf Viren prüfen, sogar mit mehreren Virenscannern parallel. (Der Autor hat das mit Clam-AV und McAfee erfolgreich getestet.) Hat ein Virenscanner einen Virus entdeckt, wäre es Ressourcenverschwendung, die Mail auch noch dem anderen zu verfüttern. Der Parameter » = 1« verhindert genau dies.

Möglich wäre es, den Absender der verseuchten Mail mit » = 1« zu warnen. Dieser Service hat aber wenig Sinn, da sorglose Zeitgenossen solche Mails für Spam halten oder sie durch gefälschte Absender sowieso den Falschen treffen. Wer virenverseuchte E-Mails nicht automatisch löschen will, kann mit » ein Quarantäne-Verzeichnis bestimmen und muss dafür genug Festplattenplatz einplanen.

Das Scannen auf Viren kann sich für den Mailserver schnell zu einem Ressourcenproblem auswachsen und damit zu einem Denial of Service führen. Insbesondere Mailbomben blasen sich beim Entpacken vor dem eigentlichen Scanvorgang so gewaltig auf, dass Arbeitsspeicher und Swapspace ausgehen. Dem wirkt der »-Parameter entgegen, der die Packtiefe mehrfach komprimierter Dateien begrenzt. Ist sie erreicht, bricht Amavis sein Vorhaben ab. Die Option » limitiert die Dateianzahl pro Mail.

Die »*«-Parameter bestimmen Byte-genau wie viel Speicherplatz der Dekomprimierungsvorgang verwenden darf. Überschreitet eine E-Mail eines der drei gesetzten Limits, markiert Amavisd-new ab der Version 20030616-p8 den Betreff mit »***UNCHECKED***«. Solche E-Mails sollten Sie ausfiltern, da sich in ihnen wahrscheinlich Viren versteckt halten.

Lösung 2: Amavis geht mit Maia

Die Lösung 1 ist einfach zu konfigurieren, lässt aber wenig Spielraum für Benutzer-individuelle Einstellungen. Besser verhält sich ein um Maia Mailguard [16] erweiterter Amavisd, entsprechend dem Schema in Abbildung 2. Maia ist ein einfach zu bedienendes, mehrsprachiges Webfrontend, dass auf PHP und Perl aufbaut. Es verwendet einen gepatchten Amavisd-new, der die Einstellungen für jeden einzelnen Benutzer in einer MySQL- oder PostgreSQL-Datenbank speichert. Die Installation ist umfangreich, aber problemlos. Hinweise dazu gibt der Kasten “Maia installieren”.

Die individuellen Einstellungen bearbeiten die Benutzer über das Webfrontend. Jeder User muss sich dort mit seiner vollständigen (!) E-Mail-Adresse anmelden. Dann kann er mehrere Postfächer verwalten, individuell Blacklisten definieren (Abbildung 3) oder den Schwellenwert für die Spam-Einstufung ändern (Abbildung 4).

Abbildung 4: Das Maia-Benutzerinterface eröffnet praktischerweise allen Usern auch die Möglichkeit, den Schwellenwert für die Spam-Einstufung ihres E-Mail-Empfangs zu regulieren.

Den höheren Komfort für die Benutzer bezahlt der Admin jedoch mit einem höheren Risiko für sich selbst: Mehr Komponenten bedeuten immer eine höhere Ausfallswahrscheinlichkeit. H&;auml;ngt die Datenbank, liefert der Server keine E-Mails mehr aus. (Glück im Unglück: Er speichert sie zwischen und stellt sie nur verspätet zu, sobald die Datenbank wieder verfügbar ist.) Um die Ausfallsicherheit zu erhöhen, darf der Admin mehrere SQL-Server definieren.

apt-get install php-mail-mime php4-pear-log php4-imap php4-ldap php4-mcrypt php4-gd libphp-jpgraph libcrypt-cbc-perl libcrypt-blowfish-perl
pear install Mail_Mime
pear install DB_Pager
pear install Log

cp -r /usr/share/jpgraph /Pfad_zu_Maia/php

patch -b amavisd < amavisd-maia.patch

Updates sind schwierig

Der zweite kritische Punkt ist, dass distributionseigene binäre Sicherheitsupdates für Amavisd-new nicht mehr möglich sind – das Maia-Patch würde dabei verloren gehen. Für Mailserver mit großem Mailaufkommen ist zudem der Performanceverlust durch die vielen Datenbankzugriffe von Bedeutung (siehe weiter unten). Dem kann der Admin wieder durch Aufteilung auf mehrer Server entgegenwirken.

Abbildung 5: Die flexible Lösung 2 mit Maia macht dem Admin die Konfiguration leicht, birgt aber Risiken.

Lösung 3: Per Milter-API

Für maximale individuelle Konfigurierbarkeit ohne grafischen Schnickschnack bietet sich ein Modell wie in Abbildung 6 an. Es verwendet die Milter-Schnittstelle [17] von Sendmail, um auf einen separat laufenden Spamd (Spamassassin-Daemon) zuzugreifen. Jeder Benutzer darf in »~/.spamassassin/user_prefs« seine eigenen Einstellungen treffen. Der Spamd greift auf diese »user_prefs«-Datei zu und bewertet Spam entsprechend. Fehlt die Datei, übernimmt Spamassassin die Einstellungen des Administrators aus »/etc/spamassassin/local.cf«.

Abbildung 6: Sendmails Milter-Schnittstelle erlaubt über »user_prefs« individuelle Einstellungen.

Da der Spam-Daemon auf die Homeverzeichnisse zugreifen muss, läuft er mit Root-Rechten. Wer einstellt, dass der Spamd-Prozess regulär Lesezugriff auf alle Verzeichnisse bekommt, kann ihn auch ohne Root-Rechte ausführen und so die Sicherheit erhöhen. Installiert ist Lösung 3 sehr schnell: »apt-get install spamass-milter spamassassin«. Danach fügen Sie die Zeile

INPUT_MAIL_FILTER(`spamassassin',`S=local:/var/run/sendmail/spamass.sock, F=,T=S:4m;R:4m;E:10m')dnl

in die »hostname-rx.mc«-Konfigurationsdatei des MTA-RX ein, kompilieren die Konfigurationsdateien mit »m4« und starten Sendmail neu. In der »/etc/spamassassin/local.cf« definieren Sie die globalen Einstellungen.

Die genauen Optionen listet [18] auf, die wichtigsten: Um individuelle Benutzerkonfiguration zu ermöglichen, setzen Sie »allow_user_rules 1«. Für Spam-Markierung sind »required_score 2.5«, »rewrite_subject 1« und »rewrite_header Subject ***Spam***« zuständig.

Die Standard-Bewertungskriterien sind recht gut, die genauen Konfigurationsmöglichkeiten lesen Sie unter [19] nach. Für bestimmte Merkmale in E-Mails vergibt Spamassassin Punkte, überschreitet die Punktzahl den Wert von »required_score«, markiert es eine Mail als Spam. Um die Spam-Erkennungsrate zu steigern, hat sich das Erhöhen der Punkte für »RAZOR2_CHECK«, »RAZOR2_CF_RANGE_51_100« und »DCC_CHECK« bewährt. Der »PYZOR_CHECK«-Wert ist bereits ausreichend hoch.

Drei globale Spamjäger: DCC, Razor und Pyzor

Diese drei Parameter bestimmen die Bewertungskriterien für Daten aus drei weltweiten Mailnetzen, die Hashes von E-Mails sammeln und auswerten. Die für diesen Zweck verwendeten Hashfunktionen arbeiten anders als die bekannten Vertreter MD5 und SHA1. Sie benutzen so genannte Soft-Hashes, bei denen kleine Teile einer E-Mail variieren dürfen, beispielsweise der Empfänger, ohne dass sich der Hash ändert.

Jeder Mailserver, der diese externen Netze verwendet, sendet die Hashes der selbst empfangenen Mails an die Netzwerke. Laufen 100000 – der Wert ist definierbar – identische Hashes im Netzwerk ein, ist anzunehmen, dass es sich um Spam handelt. Denn es ist unwahrscheinlich, dass 100000 identische E-Mails legitimen Inhalts auftreten.

DCC, Razor und Pyzor installieren Sie einfach mit »apt-get«. Spamassassin erkennt danach selbstständig ihre Gegenwart. Für DCC ist ab 250000 E-Mails täglich ein eigener DCC-Server nötig, häufigere Zugriffe blockt DCC als Denial-of-Service-Angriff. Die Funktionsfähigkeit des Plugin können Sie entweder in den E-Mail-Headern von Spam-E-Mails oder auf den Ports 6277/UDP (DCC), 2703/TCP, 7/TCP (Razor) und 24441/UDP (Pyzor) mit Tcpdump überprüfen.

Die Ports müssen auf der Firewall ausgehend erlaubt sein, um eine Verbindung zum entsprechenden Netz zu ermöglichen. Der parallele Einsatz dieser Programme mag übertrieben erscheinen; es hat sich jedoch herausgestellt, dass er die Spam-Erkennung deutlich steigert.

Lösung 4: Null Prozent Spam – mit Nebenwirkung

Eine wenig bekannte und auch nur unter ganz bestimmten Voraussetzungen sinnvolle Möglichkeit, Spam effektiv zu bekämpfen, ist der so genannte Tagged Message Delivery Agent [20]. Der TMDA verfolgt einen Challenge-Response-Ansatz, bei dem jede E-Mail, die der Server zustellen soll, beweisen muss, dass sie kein Spam ist.

Wie das prinzipiell funktioniert, verdeutlicht Abbildung 7: Ein fremder Mailserver versucht eine E-Mail an eine Mailbox auf dem Mailserver zu senden. Der eigene Mailserver bittet daraufhin den Absender um eine Bestätigungsmail. Erst wenn er auch die erhält, stellt er die ursprüngliche E-Mail zu. Spammer werden die Bestätigungsmail nicht senden, da sie ihre Mails geballt und automatisiert verschicken und wegen des gefälschten Absenders die Aufforderung auch gar nicht erhalten. Dadurch reduzieren sich unerwünschte E-Mails auf null Prozent, allerdings mit starken Nebenwirkungen. Eine etwas ausgefeiltere Art von TMDA beschreibt Abbildung 8.

Abbildung 7: Challenge-Response-Ansatz zur Spam-Vermeidung per Tagged Message Delivery Agent: Der Absender bekommt per Mail eine Aufforderung, die Ernsthaftigkeit seiner Absicht zu bestätigen. Erst jetzt erhält der Empfänger die Mail zugestellt.

Abbildung 8: Gute ins Töpfchen, schlechte ins Kröpfchen: In der ausgefeilteren TMDA-Technik sortiert Spamassassin die Mails vor.

Merkliste für TMDA

Wenn Sie sich für diese Null-Toleranz-Variante entscheiden, sollten Sie dringend folgende Dinge beherzigen:

• Da Spammer besonders gern erbeutete Absenderadressen von
  Unbeteiligten benutzen, sollte Ihr Mailserver diese nicht mit
  Bestätigungsanforderungen belästigen. Darum reichen Sie
  E-Mails, die der Spamfilter bereits als Spam erkannt hat, nicht an
  den TMDA weiter.
• Mails mit besonders niedrigem Spam-Level können Sie unter
  Umgehung des TMDA direkt zustellen lassen.
• Stehen sich zwei TMDA-Systeme gegenüber, können
  theoretisch Endlosschleifen entstehen. Laut TMDA-Homepage [20] soll
  dies nicht passieren, eine Garantie gibt’s aber nicht. Weitere
  Probleme und wie sie zu umgehen sind, erklärt die FAQ auf
  derselben Homepage.
• Empfehlenswert ist das Pflegen einer von Spamassassin
  unabhängigen persönlichen Whitelist. Am besten nehmen Sie
  gleich das komplette Adressbuch auf. Insbesondere für die
  Anmeldung und Benutzung von Mailinglisten sind Whitelists
  nötig.

Ein praktischer Nebeneffekt ist, dass der Absender einer E-Mail, solange er nicht auf der Whitelist steht, bestätigt bekommt, dass seine E-Mail angekommen ist. Gleichwohl ist bereits zu erkennen, dass sich TMDA aufgrund der Nebenwirkungen und der Komplexität nicht für jeden Benutzer und Einsatzzweck eignet.

TMDA installieren

Nach der Installation des TMDA-Pakets aus dem »unstable«-Zweig, was in Sarge problemlos geht, kann jeder interessierte Benutzer seine TMDA-Einstellungen vornehmen. Wichtig: Es dürfen keinesfalls ».tmdarc«-Dateien in den Homeverzeichnissen existieren – auch wenn die TMDA-Homepage anderes schreibt. Sendmail verwendet dann nämlich in den E-Mail-Adressen »-«-Zeichen statt »+« und stellt E-Mails dann überhaupt nicht zu.

Damit die E-Mails schon einmal TMDA-bestätigte Absender den Mechanismus nicht nochmals durchlaufen müssen, empfehlen sich automatische Whitelists. Dazu erstellen Sie in »~/.tmda/filters/incoming« einen Incoming-Filter mit dem Inhalt »from-file ~/.tmda/lists/whitelist ok« und fügen in der »~/.tmda/config«-Datei die Zeile

CONFIRM_APPEND = "/home/mail1/.tmda/lists/whitelist"

ein. Ab sofort passieren die Mails mit bestätigten Absendern die TMDA-Funktion ungehindert. Um auch E-Mails mit weniger als »1.0« Punkten im Spamtest automatisch durchzuwinken, fügen Sie im »incomig«-Filter folgende Zeilen ein:

headers 'X-Spam-Status:.*score=U0..*' ok
headers 'X-Spam-Status:.*score=U1.0.*' ok

Performance der Lösungen

Eier legende Wollmilch-Mailserver setzen sich automatisch der Gefahr aus, zur Performancebremse zu werden, sobald der Maildurchsatz anschwillt. Darum hat das Linux-Magazin die vorgestellten Lösungen dem gleichen Performancetest unterzogen, den sich in der letzten Ausgabe schon eine Mailappliance unterziehen musste [21].

Diesmal stresste der Postal [22] einen Pentium 4 mit 2,8 GHz und 512 MByte Speicher. Das Benchmarkprogramm schickte fünf Minuten lang E-Mails mit maximal 15 KByte Größe an den Server. Mit Lösung 1 (Amavis allein zu Haus) war es ihm möglich, rund 600 E-Mails in einer Minute zuzustellen. Es dauerte dann weitere 5 Minuten bis alle zugestellt waren. Das Zuschalten von Clam-AV verlangsamte den Ablauf kaum. Setzt man Spamassassin mit externen Tests wie in Lösung 3 ein, hängt der Durchsatz stark von der Internet-Bandbreite und -Latenzzeit ab. Ein TMDA (Lösung 4) lässt die Performance dagegen merklich fallen.

Ungeheuer flexibel

Dieser Artikel kann naturgemäß keine 1000-seitigen Bücher ersetzen und darum nur eine Einführung in Sendmail und einige Komponenten geben. Die ersten drei vorgestellten Konzepte werden in den meisten Umgebungen auf Anhieb zufrieden stellend arbeiten. Die Lösung 4 sollten Sie nur nach eingehender Überlegung zur Favoritin machen.

Allen vieren ist gemeinsam, dass sie sich durch die starke Modularität sehr gut skalieren lassen, angefangen von getrennten Festplatten für die Mailqueues bis zu separaten Servern für jede einzelne Komponente. Sie haben\’s gesehen: Das Monster lässt sich zähmen. (jk)