Mailserver mit Spamfilter

Test & Kaufberatung | Test

Das OpenSuse Linux 10.1 von der Heft-DVD eignet sich nicht nur für den Desktop. Mit ein paar Zusatzpaketen wird daraus ein Mail-Server, der alle E-Mails auf Virenprüft, Spam filtert, sauber sortiert und ganz nebenbei als zentrale Postsammelstelle dient.

Dieser Artikel ist ein Vorabdruck aus dem c't-Special "Linux", das am 10. Juli erscheint. Das Sonderheft kostet 8,50 Euro und ist am gut sortierten Zeitschriftenhandel erhältlich. Auch kann es über den heise-Shop bestellt werden.

Das neue c't-Special Linux

Seit Monaten steht der ausgemusterte, aber noch voll funktionstüchtige PC unter dem Schreibtisch. Die eingebaute Grafikkarte ist von anno dazumal, Prozessor und Board aus der Pentium-Generation und auch die 40-GByte-Festplatte lockt keinen Power-User mehr hinterm Ofen hervor. Die Zeit scheint also gekommen, den Rechner für einen Apfel und ein Ei zu versteigern. Oder besser: ihm eine neue Aufgabe zu geben, etwa als zentralem Mail-Server, der alle ein- und ausgehende Post frei von Viren hält, windige Geschäftsvorschläge, lästige Reklame für Erektionsförderer oder Benachrichtigungen über groteske Lotteriegewinne als Spam erkennt sowie als Sammelstelle für die Mail-Accounts der Familienmitglieder dient. Die müssen dann nicht mehr selbst ihre E-Mails von diversen Konten abrufen, sondern verwalten sie bequem auf dem zentralen IMAP-Server, wo alle Mails bereits sauber vorsortiert in separaten Ordnern liegen.

Als Grundlage für das Projekt eignet sich Suse Linux 10.1 von der Heft-DVD. Für alle, die ihren Server ohne KDE- oder Gnome-Desktop, also mit einer textbasierten Oberfläche neu aufsetzen möchten, haben wir im Folgenden die wichtigsten Schritte zusammengefasst.

Nach dem Booten von der DVD sollte man per Druck auf F2 zunächst Deutsch als Systemsprache wählen und dann erst die Installation über den entsprechend lautenden Menüpunkt starten. Nach einem mitunter langwierigen Startvorgang – das Betätigen von Escape schaltet auf eine Konsole mit den Systemmeldungen um, die Ungeduldigen die Wartezeit etwas versüßen kann – ist die Lizenzvereinbarung zu akzeptieren und dann "Neuinstallation" zu wählen. Im Schirm "Desktop auswählen" nimmt man "Andere/Textmodus".

In den Installationseinstellungen konfiguriert man anschließend Tastaturbelegung, Zeitzone, Partitionierung, Sprache und Bootloader. Weil sich dank des OpenSuse-eigenen Konfigurationswerkzeugs Yast alle gewünschten Programme und Bibliotheken bequem nachinstallieren lassen, beginnt man in der "Software-Auswahl" zunächst mit einem "Minimal-System", das nur gut 580 MByte auf der Platte beansprucht. Sämtliche Mail landet später in einem Unterordner von /var. Die Partition, in der dieses Verzeichnis liegt, sollte also genügend Freiraum für die kommenden Jahre als Postlagerstelle bieten. Nach der Installation startet der Rechner neu und man gelangt automatisch zum Setzen des Rechnernamens, zum Beispiel "homeserver" als Hostname plus "example.com" als Domainname. Die Wahl des Domain-Anteils im Namen ist frei, nur empfiehlt es sich, keine Domain anzugeben,die bereits im Internet verwendet wird, weil sonst alle Mails an diese Domain im lokalen Mail-Server landen. Das Häkchen neben "Hostnamen über DHCP ändern" sollte man entfernen. Dazu gleich mehr.

Nach dem Setzen des root-Passworts gelangt man in die Netzwerkkonfiguration. Da die Mail-Clients via IMAP und SMTP mit dem Mail-Server sprechen, muss man die entsprechenden Ports in der Firewall freischalten; bei OpenSuse heißt der für SMTP zu erlaubende Dienst "Mailserver". Wer den Rechner nicht nur über die Konsole, sondern außerdem per SSH aus der Ferne steuern möchte, fügt hier unter "Firewall/Erlaubte Dienste" in der "externen" Zone "SSH" zur Liste erlaubter Dienste hinzu. Soll die Fernsteuerung auch über VNC (Virtual Network Console) [3] stattfinden, muss man außerdem ein Loch für "Verwaltung via entfernten Rechner (remote)" in die Firewall bohren und die "Verwaltung vom entfernten Rechner aus (remote) über VNC" aktivieren. Anwender, die über einen Proxy ins Internet gehen, geben unter "Proxy" die URLs für den Zugriff via HTTP oder FTP sowie die gegebenenfalls erforderlichen Zugangsdatenfür den Proxy ein.

Die IP-Adresse eines Servers sollte man möglichst nicht automatisch per DHCP setzen lassen, sondern via "Ändern/Netzwerkschnittstellen" fest einstellen. Da der Server nur im lokalen Netz zugänglich sein soll, empfiehlt sich der Internet-Zugang über einen separaten Router mit eingebauter Firewall, die alle eingehende Verbindungen blockiert, aber ausgehende Verbindungen jeder Art erlaubt.

In unserem Beispiel liegen alle lokalen IP-Adressen im Netz 192.168.0.0/24. Als Adresse für den Server haben wir die 192.168.0.199 gewählt, als IP-Adresse für die interne Schnittstelle des Routers die 192.168.0.1. Die interne Router-IP-Adresse ist als "Standardgateway" unter dem Menüpunkt "Routing" einzutragen.

Glücklich dürfen sich die schätzen, deren Router als DNS-Proxy fungiert. Die wählen unter dem Menüpunkt "Hostname und Namenserver" als "Nameserver 1" die Adresse des Internet-Gateway, also die 192.168.0.1. Alle anderen müssen sich bei ihrem Provider erkundigen, unter welchen IP-Adressen deren DNS-Server zu erreichen sind. Typischerweise sind das zwei oder drei verschiedene, die man als "Nameserver 1" bis "Nameserver 3" vorgibt.

Das wars auch schon mit der Netzwerkkonfiguration. Danach gehts zum Test der Netzwerkverbindung, den man Yast vornehmen lässt, um sicherzustellen, dass die vorangegangenen Einstellungen korrekt sind. Meldet Yast hier einen Fehler, hat sich der vermutlich bei der Eingabe von Gateway oder Nameserver eingeschlichen, und man sollte seine Eingaben nochmals prüfen. Anschließend lässt man Yast die neuesten Patches herunterladen.

Bei der nachfolgenden Wahl der Authentifikationsmethode belässt man es der Einfachheit halber bei "Lokal (/etc/passwd)". Im Schirm "Neuer lokaler Benutzer" gibt man seine Benutzerdaten ein. Das Setzen eines Häkchens neben "Systemmail empfangen" leitet alle Meldungen des Systems (etwa über gefundene Viren) an diesen Benutzer weiter. Weitere Benutzer lassen sich unter dem Punkt "Benutzer-Verwaltung" anlegen.

Die folgenden Bildschirme bestätigt man so lange mit "Weiter", bis Yast einen zur gelungenen Installation beglückwünscht. Nach "Beenden" meldet man sich als root am System an und startet das Konfigurationswerkzeug erneut per Eingabe von yast.

fetchmail holt E-Mails von POP3- oder IMAP-Postfächern ab. Anschließend scannt der Mail-Server sie auf Viren und legt sie in lokalen IMAP-Ordnern ab.

Nun geht es ans Nachinstallieren der für den Mail-Server benötigten Software. Da einige Programme nicht auf der Heft-DVD enthalten sind, muss man sie sich von einem der OpenSuse-Mirrorserver besorgen [2]. Als Installationsquelle wählt man einen räumlich möglichst nahe gelegenen. Im Zweifel funktioniert der FTP-Server ftp.gwdg.de/pub/opensuse/distribution/SL-10.1/inst-source/, den man in Yast unter "Software/Installationsquelle wechseln" als primäre Quelle einstellt. Eine Warnung über das Fehlschlagen einer Signaturprüfung darf man ignorieren und die Nachfrage, ob man die Datei tatsächlich verwenden möchte, getrost bejahen.

Via "Software/Software installieren oder löschen" sind folgende Pakete einzuspielen: amavisd-new, clamav, cyrus-imapd, fetchmail, screen, spamassassin, sudo und razor-agents. Abhängigkeiten von anderen Programmen und Bibliotheken löst Yast automatisch auf.

Nach der Installation geht es an die Konfiguration des Mail-Servers unter "Netzwerkdienste/Mail Transfer Agent". Bei OpenSuse wird als Mail Transfer Agent (MTA) standardmäßig Postfix installiert. Da unser Beispiel den Zugang über ein dauerhaft mit dem Internet verbundenes Gateway voraussetzt, ist als Verbindungsart "Permanent" zu wählen. Um alle über den Mail-Server ein- und ausgehenden Mails auf Viren zu prüfen, aktiviert man die Virusüberprüfung durch Setzen des entsprechend beschrifteten Häkchens. Nach Betätigen von "Weiter" braucht Postfix den Namen des Mail-Relay beim Provider. T-Online-Kunden wählen hier smtprelay.t-online.de, Arcor-Kunden mail.arcor.de. Andere Kunden müssen die Server-Adressen bei ihrem Provider erfragen. Falls der Mail-Server des Providers nach Authentifizierung verlangt, gibt man den Benutzernamen für diesen Zugang und das dazugehörige Passwort unter dem Menüpunkt "Authentifikation" ein. In unserem Beispiel mit Arcor als Provider bleiben die Felder leer.

Über den Menüpunkt "Masquerading" lässt sich einstellen, wie Postfix unvollständige E-Mail-Adressen erweitern soll. Lautet der Absender einer Mail beispielsweise nur "ola", wird er zu "ola@example.com", wenn man im Feld "Domain für den Header 'Von'" die Zeichenfolge "example.com" eingibt. Wie das Umschreiben von Adressen bei Postfix im Detail funktioniert, erläutert [4]. Typischerweise senden E-Mail-Clients – auch als Mail User Agents (MUA) bezeichnet – aber eine komplette E-Mail-Adresse in der From-Zeile mit, sodass dieses Feld leer bleiben kann. Auch im Feld darunter ("Domain-Namen für die lokale Mail-Zustellung") braucht man nichts einzutragen – Yast füllt dieses Feld später automatisch, sodass keine an lokale Benutzer gerichteten Mails ins Internet geroutet werden.

Der nächste Bildschirm verlangt nach den Einstellungen für den Mail-Empfang. Als erste Option findet sich hier die Einstellung "Entfernte SMTP-Verbindungen akzeptieren", deren Aktivieren bewirkt, dass Postfix nicht nur auf lokal eingehende Verbindungsversuche reagiert, sondern auch auf von entfernten Rechnern eingehende. Das ist wichtig, damit die auf den Arbeitsplatzrechnern im LAN laufenden Mail-Clients per SMTP mit dem MTA sprechen können.

Damit derlei Kommunikation nicht gleich an der Homeserver-Firewall abprallt, muss man durch Setzen des zweiten Häkchens den SMTP-Port öffnen. Der Schutz gegenüber dem Internet bleibt durch die Router-Firewall erhalten.

Auch beim Versand prüft der in den lokalen Mail-Server eingeschleifte Virenscanner Mails auf Schädlingsbefall. Auf diesem Weg gelangen nur saubere Mails zum Empfänger.

Im Kasten "Herunterladen" befinden sich die Einstellungen für den Mail-Einsammler fetchmail. Bei fetchmail handelt es sich um ein im Hintergrund laufendes Programm, das in benutzerdefinierten Intervallen von einem oder mehreren Mail-Servern die neu eingegangene Post abholt und einem lokalen Benutzer zustellt. Im Feld "Server" trägt man den Namen des Rechners ein, von dem fetchmail die Mails abholen soll; GMX-Nutzer schreiben hier beispielsweise "pop.gmx.net".

Im Feld "Protokoll" wählt man das Protokoll das dieser Server spricht, bei Freemailer wie GMX ist das meistens POP3. Die Felder "Entfernter Benutzer" und "Passwort" nehmen die Zugangsdaten zum Zugriff auf den POP3-Server auf, "Lokaler Benutzer" die Kennung des Nutzers, an den fetchmail die abgeholten Mails zustellen soll. Weitere Postfächer, die fetchmail abfragen soll, lassen sich über den Punkt "Details" eintragen. An welchen Benutzer Mails an root weitergeleitet werden sollen, bestimmt der Eintrag im Feld darunter.

Das Feld "Auslieferungsmodus" legt fest, wie der MTA Mails an lokale Benutzer ausliefern soll. "Direkt" bedeutet, dass die Mails im persönlichen Postfach unter /var/spool/mail/ unter Umgehung aller Filtermöglichkeiten gleich im Dateisystem landen – was unserem Anliegen zur bequemen Mail-Verwaltung mit beliebigen IMAP-tauglichen Clients eher abträglich ist –, "procmail" stellt die Mail über den gleichnamigen Mail-Filter zu. Die richtige Wahl für unser Beispielszenario ist die selbst erklärende Option "An Cyrus IMAP-Server". "Beenden" schließt die Mail-Server-Konfiguration ab. Yast schlägt danach eine Einstellung vor, anhand derer Postfix entscheidet, welche Ziel-Domains in E-Mail-Adressen der MTA als lokale interpretieren soll, damit Mails an diese Adresse nicht fälschlicherweise ins Internet geroutet werden. Die Vorgabe bestätigt man einfach mit "Ja".

Beim Abholen von Mails via POP3 gehen die Zugangsdaten im Klartext über die Leitung. Viele POP3-Server, so auch die von Google Mail oder GMX, bieten jedoch die Möglichkeit, Mails über eine SSL-verschlüsselte Verbindung abzurufen, bei der die Zugangsdaten für Dritte nicht mehr ohne weiteres einsehbar sind. Leider lässt sich diese Einstellung nicht im Yast vornehmen, sondern nur direkt in der fetchmail-Konfigurationsdatei /etc/fetchmailrc. Hat man eben beispielsweise als POP3-Server "pop3.gmx.net" mit der Benutzerkennung "xyz@gmx.net" und dem Passwort "geheim" sowie als lokalen Nutzer "ola" eingetragen, hat Yast folgende Zeile in die Konfigurationsdatei geschrieben:

poll "pop3.gmx.net" protocol POP3 : user "xyz@gmx.net" there with password "geheim" is "ola" here;

Weitere Postfächer lassen sich nach dem gleichen Schema hinzufügen. Möchte man eine Verbindung mit SSL schützen, genügt es, in die betreffende Zeile vor dem abschließenden Semikolon "ssl" einzutragen. Doch damit nicht genug der Konfiguration: Der optionale Parameter "fetchall" bewirkt, dass fetchmail sämtliche Mails abholt, auch die, die der Mail-Server wegen eines vorherigen Zugriffs (etwa von einem anderen Client aus) als gelesen markiert hat. Den sollte man allerdings nicht zusammen mit "keep" einsetzen, weil fetchmail sonst bei jedem Abruf alle bisher eingesammelten E-Mails dupliziert. Weitere Konfigurationsmöglichkeiten verrät man fetchmail.

Wie oft fetchmail im Hintergrund die Mail-Server abfragen soll, lässt sich in /etc/sysconfig/fetchmail festlegen; voreingestellt sind 10 Minuten (FETCHMAIL_POLLING_INTERVAL=600).

Der Mail-Server steht durch die Router-Firewall geschützt im lokalen Netzwerk.

Wenn fetchmail eine E-Mail abgeholt hat, landet sie anschließend via SMTP im lokalen MTA (Postfix). Dessen Konfiguration sorgt dafür, dass die Mail eine Schleife durch den E-Mail-Virenscanner Amavis nimmt, bevor Postfix sie an den Empfänger ausliefert. Amavis ruft dazu die per Yast konfigurierten Virenscanner auf, in unserem Beispiel den bei OpenSuse mitgelieferten auch für kommerzielle Zwecke frei erhältlichen Clamav.

Findet Amavis einen Virus in einer E-Mail, schiebt er die gesamte E-Mail in Quarantäne. Wo genau er sie im Dateisystem ablegt, darüber informiert er den User in einer automatisch erzeugten Mail. Darin steht auch, welcher Virus gefunden wurde und von wem die verseuchte Mail stammt; die generierte Mail enthält außerdem den gesamten Text der Ursprungsmail – ohne den Virus natürlich.

Um die Virus-Signaturen von Clamav stets auf dem neuesten Stand zu halten, muss im Hintergrund der freshclam-Dienst laufen. In der Standardeinstellung aktualisiert freshclam die Signaturen alle zwei Stunden. Die Anzahl der Aktualisierungsversuche pro Tag lässt sich in der Datei /etc/freshclam.conf über den Parameter "Checks" einstellen. Ebenfalls dort zu konfigurieren: die Proxy-Einstellungen über die Parameter HTTPProxyServer, HTTPProxyPort, HTTPProxyUsername und HTTPProxyPassword, falls der Homeserver über einen Proxy ins Web geht. Den freshclam-Dienst aktiviert man am einfachsten im Runlevel-Editor von Yast. Dort sollte man prüfen, ob die anderen mit dem Mail-Server zusammenhängenden Dienste laufen und beim Systemstart automatisch hochfahren: amavis, cyrus, postfix, saslauthd.

So sollte es aussehen: Die Firewall ist aktiviert, der SSH-Zugriff freigeschaltet, das Netzwerk korrekt eingerichtet.

Nur Mails, die der Scanner als "clean", das heißt virenfrei, markiert hat, leitet Postfix an den IMAP-Server weiter, in unserem Beispiel ist das der vom OpenSuse-Mirror nachinstallierte Cyrus-IMAP-Daemon der Carnegie Mellon University [9].

Damit eine Mail bei einem lokalen User landen kann, muss man ihn erst einmal einrichten. Das geht am einfachsten per Yast unter dem Menüpunkt "Sicherheit und Benutzer". Ein erster Benutzer existiert ja bereits, im Beispiel "ola".

Um einen Benutzer zu authentifizieren, bedient sich der IMAP-Daemon eines SASL (Simple Authentication and Security Layer) genannten Frameworks [10]. In der OpenSuse-Standardkonfiguration greift der zuständige Hintergrundprozess saslauthd auf das systemeigene PAM (Pluggable Authentication Module) zu. Damit lässt sich das Passwort zur Anmeldung am Login-Prompt zur Authentifizierung von IMAP-Nutzern verwenden.

Das Systemkonto alleine reicht aber nicht – der Benutzer benötigt auch ein Postfach, in das der IMAP-Server die Mails legen kann. Das lässt sich mit Hilfe des Cyrus-IMAP-Administrationswerkzeugs cyradm einrichten. Wer dieses Werkzeug zu administrativen Zwecken nutzen darf, legt der Eintrag "admins" in der Datei /etc/imapd.conf fest. Vorgegeben ist hier "cyrus". Dieser Benutzer hat allerdings noch kein Login-Passwort. Daher muss man ihm erst einmal mit

passwd cyrus

eines zuweisen. Danach lässt sich das Konfigurationswerkzeug als beliebiger Nutzer mit

cyradm -u cyrus localhost

starten. Als Passwort ist das eben für cyrus vergebene zu verwenden. Auf Eingabe eines Fragezeichens zeigt cyradm die Liste der Kommandos, die es versteht. Zum Einrichten eines Postfachs verwendet man createmailbox. Die Kurzform

cm user.ola

legt eine Mailbox für den User "ola" an. Diese Mailbox erscheint in gängigen Mail-Clients typischerweise als "INBOX" oder "Posteingang". Was "ola" mit dem Postfach anstellen darf, listet lam user.ola auf (List ACL Mailbox, Anzeigen der Berechtigungen für ein Postfach). Es erscheint eine Zeile mit dem Benutzernamen, gefolgt von einer Zeichenkette wie "lrswipc-da", wobei jeder Buchstabe für eine bestimmte Berechtigung steht, etwa "l" für "lookup", "r"für "read" oder "p" für "post" (siehe Tabelle "Mailbox-Berechtigungen").

Mailbox-BerechtigungenKürzelDer Nutzer darf …lookupMails in diesem Ordner auflistenreadMails in diesem Ordner lesenseenMails in diesem Ordner als gelesen ("read") oder neu ("recent") markierenwritein diesem Ordner Flags wie "beantwortet" ("answered") oder "Entwurf" ("draft") änderninsertMails in diesen Ordner verschieben oder kopierenpostMails beispielsweise über die Zieladresse "ola+privat@example.com" direkt an den Ordner "user.ola.privat" zustellencreatein diesem Ordner Unterordner anlegen und löschendeleteMails in diesem Ordner (und den Ordner selbst) löschenadministerBenutzerrechte für diesen Ordner vergeben

Das Kommando sam (Set ACL Mailbox) weist einem Nutzer Berechtigungen für einen Mail-Ordner zu. Mit sam user.ola as lrs gestattet der Anwender ola beispielsweise seinem Kollegen as, Mails in seiner Inbox zu lesen.

Neben den benutzereigenen Mailboxen lassen sich vom Benutzer unabhängige einrichten. Das ist beispielsweise praktisch, wenn man einer Gruppe von Anwendern Mailing-Listen oder News-Verteiler zur Verfügung stellen möchte, ohne dass jeder einzelne Benutzer die Mailing-Listen separat abonnieren muss. Dazu bietet sich etwa eine Mailbox "pub.Mailinglists" (englisch public, öffentlich) an, die ein in cyradm eingegebenes cm pub.Mailingslists anlegt.

Doch wer soll die ganzen Mails dort einsortieren – der, der sich hat breitschlagen lassen, alle Mailing-Listen auf seinen Namen zu abonnieren? Was bei geringem Mail-Aufkommen vielleicht noch leicht von der Hand geht, wächst sich bei Anwendern, die sich in einem Dutzend oder mehr hochfrequenter Verteiler eingeschrieben haben, zu einer zeitraubenden Tätigkeit aus. Besser also, ein Automatismus schiebt die Mails auf der Grundlage eines einfach zu programmierenden Regelwerks ins gewünschte Fach. Einen solchen bringt das Cyrus-IMAPD-Paket gleich mit: Sieve. Wer sich etwa zu den regen eBay-Nutzern zählt, möchte vielleicht alle Mails von eBay in einen eigenen Ordner schieben. Folgende Regel veranlasst Sieve, jede eingehende Mail in den Ordner INBOX.eBay zu verschieben, wenn die From-Zeile im Mail-Header die Zeichenfolgen "ebay.de" oder "ebay.com" enthält (:contains) oder die In-Reply-To- beziehungsweise Message-ID-Zeile die Zeichenfolge "JavaMail.ebayapp":

require ["fileinto", "reject"];
if anyof (header :contains
"from" ["ebay.de", "ebay.com"],
header :contains
["In-Reply-To", "Message-ID"]
"JavaMail.ebayapp") {
fileinto "INBOX.eBay"; }

Alternativ soll Sieve prüfen, ob die Mail vom Zitat-des-Tages-Verteiler des Online-Dienstleisters zitate.at stammt. Das Schlüsselwort elsif zeigt an, dass Sieve die Regel immer genau dann anwenden soll, wenn die vorangegangenen nicht gegriffen haben. Das Schlüsselwort allof bezeichnet im Unterschied zu anyof aus dem Beispiel davor nicht eine Oder-, sondern eine Und-Verknüpfung der :contains-Regeln.

Nach folgender Regel muss der Mail-Header demnach eine From-Zeile enthalten, in der die Zeichenfolge "zitate.at" vorkommt und eine Betreffzeile mit "Zitat des Tages"; trifft das zu, legt Sieve die Mail im Ordner pub.Mailinglists.Zitate ab:

elsif allof (header :contains "from" "zitate.at",
header :contains "subject" "Zitat des Tages")
{
fileinto "pub.Mailinglists.Zitate";
}

Was keine Filterregel abgefangen hat, soll anschließend im Hauptpostfach des Users landen:

else { fileinto "INBOX"; }

Neben fileinto gibt es noch eine Reihe weiterer Aktionen, beispielsweise redirect, um eine Mail an eine andere Adresse weiterzuleiten, oder reject, um den Absender davon in Kenntnis zu setzen, dass man keine Mails von ihm in Empfang nimmt, etwa wenn sie eine Größe von 10 MByte überschreitet:

if size :over 10M { reject; }

Die Sieve-Syntax und sämtliche Schlüsselwörter erklärt [1], ein Beispielskript finden Sie unter [12]. Um Sieve die Regeln bekannt zu geben, bedient man sich des Kommandozeilenwerkzeugs sieveshell. Da der Sieve-Filtermechanismus beim Cyrus-IMAP-Server benutzerabhängig ist – jeder Benutzer soll ja seine eigenen Regeln einrichten dürfen und sich nicht auf das verlassen müssen, was ihm der Mail-Administrator vorgibt –, ruft man sieveshell immer als der Nutzer auf, unter dessen Kennung man sich auch beim IMAP-Server anmeldet:

sieveshell localhost

verbindet Sie mit dem lokalen Rechner. Läuft der IMAP-Daemon auf einem anderen Rechner, ersetzt man "localhost" durch dessen DNS-Namen oder IP-Adresse. Nach Eingabe des Cyrus-Passworts (das im Beispiel identisch ist mit dem Login-Passwort auf dem Mail-Server) wird man mit einem nüchternen Prompt begrüßt. Liegt das Regelwerk in der Datei "default", schiebt es ein

put default

auf den Mail-Server,

activate default

aktiviert das Regelskript. Mit Hilfe dieses Verfahrens lassen sich also mehrere Skripte auf den Server laden und fallweise aktivieren, etwa um sämtliche direkt an den User adressierten Mails während des Urlaubs mit einer vorgefertigten Abwesenheitsnachricht zu beantworten. Das Kommando list zeigt die Liste der hochgeladenen Skripte an, deactivate deaktiviert ein Regelskript, get lädt es herunter und delete löscht es. Die Syntax der Kommandos beschreibt die Manual-Page (man sieveshell).

Mails aller Art schickt Postfix durch den Virenscanner, bevor sie den Spam-Filter SpamAssassin durchlaufen, der deren Inhalt nach Spam-Wahrscheinlichkeit klassifiziert. Erst danach stellt Postfix sie dem Empfänger zu.

Per Sieve lassen sich auch Spam-Mails aussortieren. Damit Sieve Mails als Spam erkennt, muss man deren Header mit einer Markierung wie

X-Spam-Level: ******

versehen, die Auskunft über die Spam-Klassifizierung gibt: je mehr Sternchen, desto höher die Wahrscheinlichkeit, dass die Mail unerwünschtes Material enthält. Erfahrungsgemäß genügt ein Spam-Level von fünf und höher (also fünf Sternchen und mehr), um eine Mail mit Hilfe von Sieve als Spam zu ignorieren oder in einen Ordner der Wahl zu schieben.

Die Software zum Markieren der Mails heißt SpamAssassin. Bei dem sich automatisch in SpamAssassin einklinkenden Razor [13] handelt es sich um ein Werkzeug, das die Spam-Erkennung verbessert, indem es über die untersuchten Mails mehrere Prüfsummen bildet und diese mit denen auf einem zentralen Server vergleicht. Details zum Razor-Verfahren finden sich in [14].

SpamAssassin lässt sich wie Amavis als Content-Filter in Postfix einschleifen. Als Mechanismus dafür hat sich das Weiterreichen der Mails zwischen Postfix und Filter (und zurück) via TCP/IP bewährt (siehe Grafik). Der Vorteil: Anders als bei der Content-Filterung über lokale Interprozess- kommunikation (IPC) dürfen Mail-Relay, Virenscanner und Spam-Blocker auf unterschiedlichen Rechnern laufen. Das ist praktisch, um die von der Filter-Kaskade beanspruchte Rechenleistung auf mehrere Maschinen zu verteilen, denn die Spam-Analyse kann selbst für nur wenige KByte große Mails durchaus mal 10 bis 15 Sekunden dauern. Den Löwenanteil machen dabei Anfragen an den Razor-Server aus.

Leider versteht sich SpamAssassin nur auf den Datentransport über Pipes sowie Ein- und Ausgabeumleitungen, aber nicht auf die Kommunikation per TCP-Socket. Als Lösung für dieses Problem bietet sich der SpamAssassin Proxy Daemon (spampd) an, der ständig im Hintergrund läuft, über einen Socket Mails empfängt, diese mit Hilfe der SpamAssassin-Bibliothek prüft und das Resultat über eine neue TCP/IP-Verbindung an Postfix zurücksendet.

Das spampd-Perl-Skript laden Sie einfach unter [12] herunter und speichern es zum Beispiel ins Verzeichnis /usr/bin. Der Befehl

chmod a+x /usr/bin/spampd

kennzeichnet es als ausführbar. Sie können auch ein anderes Verzeichnis wählen, wenn Sie sicherstellen, dass es sich im Systempfad (Umgebungsvariable PATH) befindet.

Damit der SpamAssassin Proxy Daemon bei jedem Booten automatisch gestartet wird, legen Sie das Boot-Skript spampd.rc aus dem Listing-Archiv zu diesem Artikel im Verzeichnis /etc/init.d ab und benennen es danach in spampd um. Anschließend aktivieren Sie es im Runlevel-Editor von Yast.

Das Boot-Skript liest die Kommandozeilenparameter für den Spam-Filter aus der Datei /etc/sysconfig/spampd. Da diese Datei noch nicht vorhanden ist, müssen Sie sie als root neu anlegen. Sie enthält nur eine Zeile:

SPAMPD_OPTIONS="--port=10026 --relayhost=127.0.0.1:10027 --tagall"

Mit diesen Optionen lauscht spampd an Port 10026 auf eingehende Mails und leitet sie nach erfolgter Spam-Analyse an Port 10027 des lokalen Rechners weiter – an Postfix. Der Parameter --tagall bewirkt, dass sämtliche Mails mit einem X-Spam-Level-Header versehen werden und nicht nur die, die einen Spam-Level erzielt haben, der den Wert des Parameters required_score (normalerweise 5) in der SpamAssassin-Konfigurationsdatei /etc/mail/spamassassin/local.cf übersteigt.

Weil der Virenscanner nach dem gleichen Prinzip wie der Spam-Blocker auf Port 10024 Mails empfängt und über den Port 10025 an Postfix weiterleitet, ergeben sich die folgenden Einstellungen in der Postfix-Konfigurationsdatei /etc/postfix/master.cf:

smtp inet n - n - 2 smtpd -o content_filter=smtp:[127.0.0.1]:10024
localhost:10025 inet n - y - - smtpd -o content_filter=smtp:[127.0.0.1]:10026
localhost:10027 inet n - n - - smtpd -o content_filter=

Die erste Zeile ist bereits vorgegeben, die zweite, weiter unten in der Konfigurationsdatei zu findende Zeile ist um die Angabe des auf dem lokalen Rechner (127.0.0.1) auf Port 10026 hörenden Content-Filters zu ergänzen, die dritte Zeile an beliebiger Stelle in der Datei hinzuzufügen.

Besonders kritische Zeitgenossen werden an dieser Stelle einwenden, dass eine auf Port 25 bei Postfix eingehende Mail nach der Prozedur dreimal in der Queue steht. Dem ist aber nicht so, weil der Postfix-Queue-Manager Duplikate automatisch verwirft und stets nur die neueste Version einer Mail übrig bleibt.

Bevor Sie den Mail-Server neustarten, sollten Sie einen Blick in die Log-Datei /var/log/messages werfen. Wenn Sie dort Einträge wie "May 31 09:06:16 homeserver kernel: audit (1149059176.208:4): REJECTING w access to /var/spool/postfix/pid/inet.local host: 10025 (smtpd ..." finden, sind noch weitere Konfigurationen nötig, die mit AppArmor, Novells Software-Paket zur Zugriffskontrolle zusammenhängen. Man kann in AppArmor Regelwerke, so genannte Profile, für Programme erstellen. Die Regeln legen fest, welche Rechte die Anwendung hat, beispielsweise auf welchem Netzwerkport sie lauscht, auf welche Dateien sie zugreifen darf und so weiter. Postfix bildet keine Ausnahme: Wenn der Mailer auf einem weiteren TCP-Port als dem Standard-Port 25 lauschen soll  in diesem Fall der Socket 127.0.0.1:10025 – möchte er beim Start eine leere Datei mit dem Namen "inet.localhost:10025" im Verzeichnis /var/spool/postfix/pid anlegen. Und genau das schlägt fehl, wenn OpenSuse beim Booten AppArmor über das Skript /etc/init.d/boot.apparmor gestartet hat.

Abhilfe schaffen eine Reihe von Änderungen in den unter /etc/apparmor.d zu findenden Konfigurationsdateien. Der Einfachheit halber haben wir alle betroffenen Dateien in einer gezippten tar-Datei zusammengefasst (Download via [12] ), die Sie als root im Hauptverzeichnis des Mail-Servers entpacken:

tar -xzvf apparmor-config.tar.gz

Nach dem Neustart von Mail-Server und AppArmor als root mit

/etc/init.d/postfix restart
/etc/init.d/boot.apparmor restart

schließen Sie die Inbetriebnahme des Viren und Spam filternden Mail-Gateways ab.

Die Spam-Erkennungsleistung eines Bayes-Filters ist nur so gut, wie die Daten, mit denen er gefüttert wird. Um SpamAssassin beizubringen, was gute Mails sind (Ham) und was schlechte, verwenden Sie das mitgelieferte Kommandozeilenwerkzeug sa-learn.

Hat der Nutzer ola schon fleißig Spam-Mails beispielsweise im IMAP-Ordner "SPAM" gesammelt, kopieren Sie diese als root zunächst in das gegebenenfalls neu anzulegende Verzeichnis /tmp/spam:

cp /var/spool/imap/user/ola/SPAM/[0-9]*\. /tmp/spam

Hier offenbart sich, wie der Cyrus-IMAP-Server Mails auf der Platte ablegt: Als Stammverzeichnis ist bei OpenSuse 10.1 das Verzeichnis /var/spool/imap vorgegeben, die Mailbox eines Anwenders liegt in einem nach dessen Login-Kennung benannten Unterverzeichnis von /var/spool/imap/user. Sämtliche Mails lagern darin in Dateien, die mit einer Zahl beginnen und auf einen Punkt enden.

Ein anschließendes

chown mail /tmp/spam
sudo -u mail -H sa-learn --spam --showdots --dir tmp/spam

führt dazu, dass der Bayes-Algorithmus die typischen Wortmuster aller in dem Ordner enthaltener Mails lernt. sa-learn ist unter der Kennung mail auszuführen, weil der spampd-Prozess ebenfalls als mail läuft und die von spampd verwendete SpamAssassin-Bibliothek die Datenbank für den Bayes-Filter sets im Heimverzeichnis des Users erwartet, unter dessen Kennung auf die Bibliothek zugegriffen wird.

Erfahrungsgemäß benötigt der Lernmechanismus sehr viele Mails, um die Treffergenauigkeit merklich zu verbessern: 10.000 und mehr Spam-Botschaften dürfen es gerne sein. Wer so viel postalischen Schund nicht in seinen eigenen Ordnern findet, greift alternativ auf ein öffentliches Archiv wie www.spamarchive.org zurück. Speichert man die dort zu findenden gezippten Mailbox-Dateien im Verzeichnis /tmp/spam ab, lassen sie sich in einem Rutsch entpacken und in sa-learn einspeisen. Das erledigt ein in /root/bin angelegtes Shell-Skript namens "learn.sh" mit folgendem Inhalt, das Sie mit chmod a+x als ausführbar kennzeichnen:

#!/bin/sh
for f in `ls /tmp/spam/*.gz`; do
echo Lernen der Spam-Mails aus Datei $f ...
gzip -cd $f | sa-learn --spam --showdots --mbox;
done

Um den Lernvorgang in Gang zu setzen – der je nach Rechenleistung durchaus ein paar Tage dauern kann und nicht unterbrochen werden sollte –, starten Sie das Skript als root mit folgendem Kommandozeilenbefehl:

screen sudo -u mail -H /root/bin/learn.sh

Auf Strg+A/Strg+D verlassen Sie die Screen-Konsole, ohne dass das Skript beendet wird. Mit screen -r zeigen Sie alle laufenden Screens an, mit screen -r 7651.pts-4.homeserver klinken Sie sich wieder in einen verlassenen Screen ein (hier der Screen mit der Kennung 7651.pts-4.homeserver). man screen führt in die Benutzung dieses Utility ein.

Wichtig ist darüber hinaus, dem Bayes-Filter mitzuteilen, wie erwünschte Mails aussehen (Ham). Dazu ersetzt man den sa-learn-Parameter --spam einfach durch --ham und lässt das Lern-Werkzeug nach dem eben beschriebenen Verfahren auf Mails mit erwünschtem Inhalt los.

Die Spam-Marker in den Mails lassen sich bequem mit Hilfe eines Sieve-Regelwerks auswerten. Die folgende Regel nimmt an, dass Mails mit einem Spam-Level von zehn aufwärts zu 100 Prozent unerwünscht sind und verwirft sie:

if header :contains "X-Spam-Level" "**********" {
discard;
}

Mails mit einem Spam-Level von fünf oder größer werden sicherheitshalber im Ordner SPAM des jeweiligen Nutzers gespeichert:

elsif header :contains "X-Spam-Level" "*****" {
fileinto "INBOX.SPAM";
}

Und ein Spam-Level von drei oder vier soll Sieve veranlassen, die betreffenden Mails im Ordner Junk abzulegen – den Sie sich etwas genauer als den SPAM-Ordner anschauen sollten, bevor Sie alle darin enthaltenen Mails mit einem Tastendruck löschen:

elsif header :contains "X-Spam-Level" "***" {
fileinto "INBOX.Junk";
}

Anschließend schiebt man das überarbeitete Regelwerk wieder mit put auf den Server. So gerüstet, braucht man seinen Lieblings-Mail-Client nur noch auf einen einzigen Server einzustellen: seinen Homeserver. Ob Thunderbird, Outlook oder Pine – Hauptsache, der Client ist IMAP-tauglich [11]. (ola)

[1] Tim Showalter, Sieve: A Mail Filtering Language (RFC 3028), www.ietf.org/rfc/rfc3028.txt

[2] Suse-Spiegelserver: http://www.novell.com/products/linuxprofessional/downloads/ftp/ int_mirrors.html

[3] Dušan Živadinovic, Universalfernbedienung, Linux, Mac OS X und Windows per VNC fernsteuern, c't 10/05, S. 106

[4] Postfix Address Rewriting: www.postfix.org/ADDRESS_REWRITING_README.html

[5] RFC 1939: Post Office Protocol – Version 3, www.ietf.org/rfc/rfc1939.txt

[6] RFC 3501: Internet Message Access Protocol Version 4 rev. 1, www.ietf.org/rfc/rfc3501.txt

[7] RFC 2821: Simple Mail Transfer Protocol, www.ietf.org/rfc/rfc2821.txt

[8] RFC 2033: Local Mail Transfer Protocol, www.ietf.org/rfc/rfc2033.txt

[9] Homepage des Cyrus IMAP Server an der Carnegie Mellon University: http://asg.web.cmu.edu/cyrus/imapd/

[10] RFC 2222, Simple Authentication and Security Layer (SASL), www.ietf.org/rfc/rfc2222.txt

[11] Jo Bager, Holger Bleich, Urs Mansmann, Fliegende Boten, E-Mail-Clients für Windows, Mac OS und Linux, c't 2/05, S. 156

[12] ftp://ftp.heise.de/pub/ct/spezial/susemail.tgz

[13] Razor, http://razor.sourceforge.net

[14] Sören Gerlach, Saubere E-Mail, Mail-Gateway gegen Viren und Spam, c't 1/04, S. 176

MDA: Ein Mail Delivery Agent nimmt via LMTP oder SMTP Mails von einem MTA oder MUA an, um sie lokalen Benutzern zuzustellen.

MTA: Als Mail Transfer Agent bezeichnet man alle Server, die für den Weitertransport von Mails zuständig sind. MTAs sprechen SMTP.

MUA: Mail User Agent ist der Oberbegriff für Mail-Clients wie Outlook,Thunderbird, Pine und so weiter.

IMAP4: Ähnlich POP3 handelt es sich beim Internet Message Access Protocol [6] um ein Protokoll, über das ein Client E-Mails von einem Server abruft. Im Unterschied zu POP3 bleiben die Mails auf dem Server liegen. Die E-Mails werden also zentral auf dem Server gespeichert und in Ordner einsortiert und nicht dezentral in den Clients.

POP3: Post Office Protocol, Version 3 [5]. Neben IMAP das wichtigste Protokoll, über das ein Client mit einem Mail-Server spricht, um E-Mails abzuholen. Typischerweise werden die Mails nach dem Abholen auf dem Server gelöscht. Der Verwaltung der E- Mails findet demnach dezentral auf den Mail-Clients statt.

LMTP: Mit Hilfe des mit SMTP verwandten Local Mail Transfer Protocol lassen sich Mails auch an MDS zustellen, die über keine Abarbeitungsschlange (Queue) verfügen [8].

SMTP: Simple Mail Transfer Protocol. Dieses Protokoll sprechen MUAs mit MTAs und die MTAs untereinander [7].