Mercury: Schlanker Mailserver für Windows

Mercury ist ein Mailserver für eine Vielzahl von Anwendungsbereichen. Er unterstützt SMTP und POP3 jeweils als Client und Server. Das heißt, Mercury kann Nachrichten von mehreren Mail-Accounts abholen und lokal verteilen. Auch das Versenden von Nachrichten innerhalb eines LAN ist möglich. Ausgefeilte Filterregeln helfen beim Kampf gegen Spam. Der Listserver übernimmt das Versenden von Messages an große Benutzergruppen. Über Plugins von Drittanbietern bietet Mercury auch Anti-Spam- und Anti-Virus-Funktionen.

Für nicht kommerzielle Nutzung ist Mercury kostenlos, aber auch die kommerzielle Nutzung kostet nicht die Welt. Die Site-Lizenz (unlimitierte Benutzer und beliebige Anzahl an Servern) kostet gerade einmal 695 US-Dollar. Bis zu 15 Nutzer auf einem Server schlagen nur noch mit 75 US-Dollar zu Buche. Eine – für Ende August 2007 versprochene – Möglichkeit zum Erwerb für kommerzielle Lizenzen fehlt jedoch immer noch. Das ist zwar nicht schlimm, da Mercury auch ohne Lizenz funktioniert, dennoch sollten Sie David Harris seinen verdienten Lohn zukommen lassen, wenn Sie sein Produkt nutzen.

Der Server wurde ursprünglich für den Einsatz mit dem Client Pegasus Mail entworfen. Auf Grund seiner Konformität zu bestehenden Internet-Standards kann dieser aber auch problemlos als Server für beliebige Mail-Clients dienen, in der neuen Version auch für IMAP4-Clients. Trotz seiner Leistungsfähigkeit benötigt Mercury nur wenig Speicherplatz: Auf der Festplatte fallen lediglich 11 MByte Installationsdateien an, im Betrieb begnügt sich der Server mit wenigen MByte Hauptspeicher.

Der folgende Beitrag gibt einen Einblick in die grundlegende Konfiguration und den Einsatz von Mercury.

Quickinfo

Produkt	Mercury/32 4.52
Hersteller	David Harris
Preis	Kostenlos / ab 75 US-Dollar
Download	www.pmail.com (7,2 MByte)
Systemvoraussetzungen
Hardware	256 MByte RAM, 11 MByte Festplattenplatz
Software	Windows 95, 98, NT4, 2000, XP

Mercury-Module

Seine zahlreichen Funktionen stellt Mercury in verschiedenen Modulen zur Verfügung. In der folgenden Tabelle finden Sie einen Überblick über die einzelnen Module und deren jeweiligen Funktionen.

Mercury-Module

Modul	Beschreibung
MercuryS	SMTP Server: Stellt im LAN einen SMTP-Server zum Übermitteln von Mails zur Verfügung.
MercuryC	SMTP Relay Client: Versendet Mails aus dem LAN über einen externen SMTP-Server.
MercuryE	SMTP Delivery Client Module: Versendet Mails aus dem LAN direkt an den SMTP-Server des Empfängers.
MercuryP	POP3 Server: Stellt den Clients im lokalen LAN den Zugriff auf die Mailboxen zur Verfügung.
MercuryD	POP3 Client: Empfängt Mails aus verschiedenen POP3-Mailboxen im Internet.
MercuryX	Connection Scheduler: Ermöglicht das zeitgesteuerte Ausführen von Mercury-Modulen.
MercuryH	Verzeichnisdienst: Ermöglicht beispielsweise das Anlegen eines LAN-weiten Adressbuchs.
MercuryI	IMAP-Server für IMAP4rev1-kompatible Clients.
MercuryW	Server für Passwort-Änderungen.
MercuryF	Finger-Server
MercuryB	Web-Server-Modul, über das die Mailing-Liste verwaltet wird.

Installation von Mercury

Die Installation von Mercury ist in wenigen Minuten erledigt. Zahlreiche Servereinstellungen lassen sich bereits währenddessen vornehmen. Es ist jedoch übersichtlicher, wenn man erst nach der Installation die Konfiguration aller Module vornimmt.

Da in unserem Beispiel keine Novell-Netware-Server zum Einsatz kommen, deaktivieren Sie die entsprechende Unterstützung. Wenn Sie in Ihrem LAN als Mail-Client Pegasus Mail einsetzen, sollten Sie die entsprechende Integration aktivieren. In diesem Fall kann Mercury eingehende Nachrichten direkt in die Postfächer verteilen. Pegasus Mail ist somit in der Lage, ohne POP3 direkt auf eingehende Mails zuzugreifen. Da wir in unserem Beispiel den Server dahingehend konfigurieren, dass er mit allen Mail-Clients zusammenarbeitet, deaktivieren Sie das "Pegasus Mail Interface".

Unter "Protocol Modules" installieren Sie folgende Module: MercuryP, MercuryD, MercuryS und MercuryX. Damit Sie auch Nachrichten ins Internet versenden können, wählen Sie im nächsten Schritt zusätzlich das SMTP-Client-Modul "MercuryC". So steht Ihnen ein kompletter lokaler Mailserver zur Verfügung. Die "Configuration Informations" überspringen Sie vorerst. Als Sicherheitsstufe für die Relay Control wählen Sie "Normal".

Im nächsten Schritt bietet Mercury die Installation von einigen Zusatzmodulen an, die nicht direkt von David Harris stammen, sondern von Lukas Gebauer. Das sind im Einzelnen SpamHalter, ClamWall und GreyWall. SpamHalter implementiert einen Bayes’schen Anti-Spam-Filter, ClamWall integriert den Virusschutz von Clam-AV in Mercury und GreyWall nutzt die (umstrittene) Greylisting-Methode zur Spam-Abwehr.

Hier wird der erste Sendeversuch eines fremden Mail-Servers mit einem temporären Fehler abgewiesen. Grundlage dieser Methode ist die Annahme, dass es ein legitimer Mail-Server nach einer kurzen Zeitspanne erneut versuchen wird, wohingegen die meisten Spam-Bots diese Wiederholungsfunktion (noch) nicht haben.

Damit ist die Installation von Mercury abgeschlossen. Im nächsten Schritt konfigurieren wir die einzelnen Module. Haben Sie eines der Tools von Lukas Gebauer installiert, sollten Sie erst deren Konfigurationsschritte durchführen. Beispielsweise sollten Sie mittels SpamHalterTools.exe die grundlegende Datenbank erzeugen lassen.

Core module - General

Um die Grundeinstellungen von Mercury zu konfigurieren, wählen Sie „Mercury core module“ im Menü „Configuration“. In der folgenden Tabelle finden Sie eine Beschreibung der wichtigsten Optionen.

Core module Configuration - General

Option	Beschreibung
Internet name for this system	Name oder Adresse des Rechners, auf dem Mercury läuft. Wird eine IP-Adresse angegeben, muss diese in eckigen Klammern stehen, zum Beispiel "[192.168.80.192]".
Local mailbox directory path	Legt den Speicherort für die Mailboxen der lokalen User fest. Dabei steht der Platzhalter "~N" für den Login-Namen des Users, zum Beispiel "C:\MERCURY\MAILBOX\~N".
Time zone	Gibt die lokale Zeitzone an, in Stunden abweichend von der GMT.
Poll mail queue every x seconds	Gibt an, wie oft das "Core Module" die Warteschleife nach zu bearbeitenden Mails überprüfen soll. Aus Performance-Gründen sollte der Wert größer als 10 Sekunden sein.
Username of postmaster	Jedes System, das Mails aus dem Internet empfängt, sollte einen User "Postmaster" haben. An diesen sendet der Server alle Fehlermeldungen und Statusreports. In diesem Feld ist der User-Name des Anwenders einzutragen, der diese Rolle übernimmt, zum Beispiel "Admin".
For delivery failures return x lines of the message	Wenn beim Versenden einer Mail Fehler auftreten, wird eine Fehlermeldung über ein Template generiert. Hier legen Sie fest, wie viele Zeilen der ursprünglichen Nachricht an die Fehlermeldung angehängt werden.

Bei allen weiteren, nicht erläuterten, Auswahlfeldern in diesem Register empfiehlt es sich, für eine erste Konfiguration alles außer "Send copies of all errors to the postmaster" zu deaktivieren. Die Option bewirkt, dass alle Fehlermeldungen sowohl zum Versender als auch an den Postmaster geschickt werden.

Core module – Mail Queue

Für die Verarbeitung von Mails nutzt Mercury so genannte Queues (Warteschlangen), die in Verzeichnissen abgelegt sind. Es muss mindestens eine Queue – die Primary Queue - auf einem System existieren.

Primary queue directory: Gibt das Verzeichnis an, das Mercury als primäre Mail-Warteschlange verwendet. Dieses Verzeichnis sollte auf dem lokalen Rechner liegen und nicht auf einem Netzwerk-Speicher, da bei Nichtverfügbarkeit des Shares Mails verloren gehen oder beschädigt werden könnten.

Sie sollten zudem sicherstellen, dass dieses Verzeichnis nicht von einem auf dem System installierten Echtzeit-Virenscanner bearbeitet wird, da dies unter Umständen den Zugriff von Mercury auf seine Dateien behindert und zu Mail-Verlust oder –Beschädigung führt. Verwenden Sie entweder ein passendes Plugin für Mercury wie ClamWall oder legen Sie eine Mercury Policy an.

Unter "Queue Processing controls" legen Sie fest, wie oft Mercury versuchen soll, eine Nachricht zu versenden, bis diese als unzustellbar an den Sender zurückgesendet wird. Die Voreinstellung können Sie ohne Änderungen übernehmen. Die übrigen Einstellungen auf dieser Seite können Sie ebenfalls so belassen, wie sie sind.

Core module - Local Domains und Groups

Die Einstellungen in diesem Register sind der wichtigste und zugleich der heikelste Punkt bei der Konfiguration von Mercury. Hier sollte Ihnen kein Fehler unterlaufen. Ansonsten erhalten Sie Mailschleifen und andere Probleme. Klicken Sie auf "Add new domain" und legen für den unter "General" als "Internet name for this system" festgelegten Namen den lokalen Server fest.

Im Register "Groups" nehmen wie keine Änderungen vor, da dies für eine erste Konfiguration nicht notwendig ist. Die Gruppenoption erlaubt es, mehrere lokale User zu einer Gruppe zusammenzufassen.

Core module - Locations und Queue settings

Im Register "Files" legen Sie die Speicherorte für zahlreiche Dateien fest, die Mercury für seinen Betrieb benötigt. An dieser Stelle sind, wenn überhaupt, nur wenige Änderungen notwendig.

Unter "System log file" legen Sie den Namen und Speicherort der Datei fest, in der alle Aktivitäten des Core module protokolliert werden. Damit diese Datei im Laufe der Zeit nicht zu groß wird, kann man den Namen dynamisch generieren lassen, so dass Mercury regelmäßig eine neue Datei anlegt. Dazu vergeben Sie im Namen die Platzhalter ~Y für das Jahr und ~M für den Monat, zum Beispiel "C:\\MERCURY\\LOGS\\MERC~Y~M.LOG". Mercury legt nun jeden Monat eine neue Protokolldatei an. Wird dieses Feld leer gelassen, werden ausgeführte Jobs nicht mitprotokolliert.

Das Feld "Directory for noticeboards" ist nur bei einem Einsatz von Pegasus Mail relevant und wird in unserem Beispiel frei gelassen.

Core module – Reporting, Advanced und Policy

In den beiden Registern, "Reporting" und "Advanced", sind für eine Grundkonfiguration keine Änderungen notwendig. Dort können Sie beispielsweise Statistiken generieren lassen. Diese werden dann per Mail an den Administrator gesendet oder in einer Datei abgespeichert. So kommen Sie eventuellen Schwachstellen wie Performance-Probleme leicht auf die Schliche.

Über den Reiter „Policy“ können Sie festlegen, was mit Mails geschehen soll, die das System passieren. So könnten Sie beispielsweise ein Kommandzeilen-Tool für einen Virus-Scan starten, von jeder Mail eine Kopie anlegen lassen oder nach unerwünschten Inhalten suchen, beispielsweise um zu verhindern, dass bestimmte Dokumente das Haus per Mail verlassen. Für unsere Basisinstallation benötigen wir allerdings noch keine Policies.

Anlegen lokaler User

Im nächsten Schritt der Installation legen Sie lokale User an. Dazu wählen Sie im Menü „Configuration“ den Punkt „Manage local users“. Die Optionen sind weit gehend selbsterklärend: "Username" legt einen Login-Namen für den neuen Anwender fest. Unter "Personal name" geben Sie den kompletten Namen des Users an, unter "POP3 password" das Passwort zum Abrufen der Mails.

Vergessen Sie dabei nicht, auch einen User anzulegen, der als Administrator alle Fehlermeldungen erhält. Verwenden Sie hierfür den Benutzernamen, den Sie in der Konfiguration des Core module unter "Username of postmaster" eingetragen haben.

Unter "APOP secret" können Sie festlegen, wie das POP3-Passwort verschlüsselt werden soll, damit dieses nicht im Klartext über das Netz übertragen wird. Auf diese Variante gehen wir aber in unserem Beispiel nicht näher ein. Nähere Informationen dazu und zum POP3-Protokoll erfahren Sie in unserem Beitrag "E-Mail-Technologie im Detail".

Die beiden letzten Punkte, "Administrator privileges" und "Copy default message", sind nur beim Einsatz von Pegasus Mail von Bedeutung. Daher deaktivieren Sie beide Optionen.

MercuryS - SMTP-Server

Das Modul MercuryS stellt den Clients im LAN einen SMTP-Server zum Übermitteln der Mails zur Verfügung. Diesen konfigurieren Sie im Menü "Configuration" unter "MercuryS SMTP Server". Die Tabelle unten gibt Ihnen einen Überblick über die wichtigsten Optionen im Register "General".

MercuryS SMTP-Server - Konfiguration

Option	Beschreibung
Announce myself as	Soll nicht der unter „Internet name for this system“ konfigurierte Domainname erscheinen, können Sie hier einen anderen eintragen. Normal sollte die Option leer bleiben.
ESMTP maximum size	Maximale Größe einer E-Mail, die MercuryS von einem Extended SMTP-fähigen Client akzeptiert. Geben Sie "0" ein, wird diese Option nicht verwendet.
IP Interface to use	IP-Adresse, unter der der SMTP-Server den Clients seine Dienste zur Verfügung stellt. Hier geben Sie die IP-Adresse ein, die Sie an die Netzwerkkarte gebunden haben.
Sender kill file	Definiert eine Datei mit Email-Adressen, von welchen keine Mails angenommen werden. Es sind Wildcards erlaubt.
Display session progress and debugging information	Wenn diese Option aktiviert ist, zeigt MercuryS auf der Konsole ausführliche Informationen über jede Verbindung an.
Accept 8BITMIME data connections	Ist diese Option aktiviert, teilt der SMTP-Server den Clients beim Verbindungsaufbau über das entsprechende ESMTP-Kommando die Unterstützung für 8-Bit-MIME-Mails mit. Diese Option sollte auf jeden Fall aktiviert sein.
Accept mail for invalid local addresses	Ermöglicht das Versenden von Mails an eine ungültige lokale Adresse. Diese Funktion sollte aktiviert sein, da der Sender in diesem Fall eine ausführliche Fehlermeldung bekommt und eine Kopie an den Postmaster geht. So lassen sich Fehler bei der Adressvergabe leichter beheben.

Im Register "Connection Control" legen Sie fest, von welchen IP-Adressen der SMTP-Server Verbindungen annehmen soll. Unter "Add restriction" geben Sie die Adressen der entsprechenden Clients in Ihrem LAN an, die auf den Server zugreifen dürfen. Die Option "Do not permit SMTP relaying of non-local mail"sollten Sie aktivieren. Damit können nur lokale User den SMTP-Server verwenden. "Use strict local relaying restrictions" und "Authenticated SMTP connections may relay mail" können wir in unserem Beispiel deaktivieren.

Unter “Spam control” können Sie Mercury anweisen, diverse Black- und Whitelists wie beispielsweise ORBS oder RBL abzufragen. Damit verbieten Sie Mails von bekannten SPAM-IP-Adressen oder erlauben nur Verbindungen von „sauberen“ Mail-Servern. Fürs erste lassen wir diese Möglichkeit außen vor.

MercuryS - SMTP Compliance

Der Reiter „Compliance“ erlaubt Ihnen zusätzliche Einschränkungen, die die Sicherheit erhöhen sollen. Mit der Option „Require Clients to use an ESMTP Size declaration“ legen Sie beispielsweise fest, dass die Gegenseite im Zuge des SMTP-Befehls MAIL TO: auch gleich die Größe der abzuliefernden Nachricht angibt. Damit können Sie beispielsweise Größenbeschränkungen durchsetzen. Allerdings haben manche ältere Clients noch Schwierigkeiten damit, daher lassen wir die Option aus.

„Limit maximum number of failed RCPT commands to“ ist ein nützliches Tool gegen Adress-Sammler. Viele Spammer sammeln nämlich Email-Adressen, indem sie dem Server eine lange Liste mit RCPT TO:-Befehlen präsentieren. Liefert der SMTP-Server dann keinen Fehler, kann der Spammer seinem Pool eine weitere Adresse hinzufügen. Diese Option können Sie beruhigt mit einem Wert von 4 aktivieren.

„Limit maximum number of relay attempts to“ können Sie ausgeschaltet lassen, da Relaying ohnehin eingeschränkt ist. „Enable short-term blacklisting for compliance failures“ sorgt dafür, dass Verstöße gegen die obigen Einstellungen mit einer 30-minütigen Sperre belegt werden. Mercury nimmt also für eine halbe Stunde keine Verbindungen von dieses System an.

Über „Enable transaction-level expression filtering“ und die Datei TRANSFLT.MER können Sie Regeln als reguläre Ausdrücke hinterlegen, die für jede verarbeitete Nachricht ausgeführt werden. Sie könnten beispielsweise den Inhalt der SMTP-Kommandos HELO/EHLO/RCPT/MAIL FROM und die Betreffzeile überprüfen lassen. Trifft eine Bedingung zu, haben Sie beispielsweise die Möglichkeit, die Transaktion zu verhindern, die Verbindung zu beenden, einen Log-Eintrag zu schreiben oder einen Fehler zu melden. Für unsere einfache Konfiguration ist das allerdings zu aufwändig und wir schalten die Option aus.

MercuryS - SMTP Inhaltsanalyse

Die bisher unter „Compliance“ beschriebenen Optionen betreffen die Transaktion, bevor die eigentliche Mail angenommen wird. Mit den Einstellungen unter „Restrictions to apply to message content“ legen Sie fest, wie Mercury eine Email weiter testen soll.

„Check originator address fields against the killfile“ ermöglicht eine weitergehende Absenderprüfung während der Mail-Session. Diese Option nutzt den „Sender kill file“ aus dem Reiter „General“, überprüft jedoch nicht das MAIL FROM aus dem SMTP-Envelope sondern die Felder From, Sender und Reply-To im Nachrichtentext. Findet Mercury dort eine gesperrte Adresse, erhält der abliefernde Server eine Fehlermeldung.

„Refuse messages containing pure HTML data“ sorgt dafür, dass HTML-Emails zurückgewiesen werden, die nicht auch einen Plain-Text-Part aufweisen. Mails, die ausschließlich aus HTML bestehen, sind ein sehr deutlicher Indikator für SPAM oder Virus/Trojaner.

„Refuse non-MIME messages“ weist Emails zurück, die nicht über eine gültige MIME-Signatur verfügen. David Harris begründet diese Option damit, dass es keinen vernünftigen Grund mehr für ein Mail-System gibt, MIME nicht zu verwenden. Diese Option einzuschalten könnte aber dennoch zu Problemen führen, daher lassen wir sie zunächst aus.

Die nächsten beiden Optionen, die nur Mails mit Betreffzeile akzeptieren, sollten besser ausgeschaltet bleiben. Dagegen können Sie „Refuse messages that have no ‚date’ field“ einschalten, da jeder ordentliche Mail-Client ein entsprechendes Feld einfügt.

Keine Regel ohne Ausnahmen. Über „Exceptions“ legen Sie eine Datei fest - beispielsweise EXCEPT.MER – in der Sie Absender-Adressen auflisten, die von der Inhaltsanalyse ausgenommen sind, etwa weil Ihr Backup-Programm nur Berichte ohne Datumsfeld verschickt.

MercuryC - SMTP Relay Client

Damit Mercury die von den Usern angenommen E-Mails weiterversenden kann, muss das Modul MercuryC konfiguriert werden. Dazu wählen Sie im Menü "Configuration" den Punkt "MercuryC SMTP Client". Dort tragen Sie die entsprechenden Daten Ihres Providers ein.

Neben den in der Tabelle beschriebenen Optionen sollten Sie besonderes Augenmerk auf die Authentifizierungs-Einstellungen legen. Hier kommen je nach Provider verschiedene Möglichkeiten in Betracht. Zum einen die direkte SMTP-Authentifizierung (SMTP AUTH) und zum anderen „SMTP after POP3“. Für beide Verfahren tragen Sie bei „Login username“ und „Password“ die entsprechenden Daten ein. Für „SMTP after POP3“ aktivieren Sie „Authenticate via prior POP3 connection“ und tragen bei „Connect to POP3 host“ den Namen oder die IP-Adresse des POP3-Servers ein. Für „Connection port/type“ gilt die Beschreibung in der Tabelle, lediglich die Ports sind 110 und 995 (SSL).

MercuryC SMTP Relay Client - Konfiguration

Option	Beschreibung
Smart host	Name oder Adresse des SMTP-Servers, an den Mercury alle ausgehenden Mails übermittelt. Geben Sie hier den SMTP-Server Ihres Internet- oder Webspace-Providers an.
Connection port/type	TCP/IP-Port, an dem oben angegebener Host Verbindungen annimmt. Bei den Typen „normal“ und „encryption via STARTTLS“ ist dies in der Regel der Port 25. Verschlüsselte Verbindungen erfolgen meist über 465.
Announce myself as	Identifikations-String, der dem SMTP-Server beim Verbindungsaufbau übermittelt werden soll. Dieses Feld kann frei gelassen werden. In diesem Fall wird der Name des Rechners, auf dem Mercury läuft, verwendet.
Delivery failure template	Falls beim Übermitteln einer Mail zum SMTP-Server Fehler auftreten, generiert Mercury eine Fehlermeldung. Das entsprechende Template wird hier festgelegt.
TCP/IP timeout	Zeit in Sekunden, die Mercury während einer Verbindung auf Daten wartet, bis die Verbindung abgebrochen wird. Die Standardeinstellung von 30 Sekunden können Sie in den meisten Fällen übernehmen.
Poll the queue every xx seconds	Zeitspanne in Sekunden, nach der Mercury die interne Warteschleife nach zu sendenden Mails durchsucht, zum Beispiel 1800 Sekunden für ein halbstündliches Versenden.
Use extended SMTP features where possible	Aktiviert die Nutzung von Extended SMTP (ESMTP). Diese Option sollte man auf jeden Fall aktivieren.

MercuryD - POP3 Client

Im nächsten Schritt konfigurieren Sie das Modul MercuryD im Menü "Configuration" unter "MercuryD POP3 Client". Dieses Modul übernimmt das Abrufen der E-Mails von mehreren POP3-Servern und stellt diese den einzelnen Usern in ihrem Netz zur Verfügung.

Die Einstellungen unter "Work directory" und "TCP/IP Timeout" übernehmen Sie ohne Änderungen. Unter "Check every xx seconds" legen Sie fest, in welchem zeitlichen Intervall Mercury die einzelnen POP3-Konten nach neuen Nachrichten überprüft. Sollen die Server beispielsweise alle 30 Minuten nach neuen Mails überprüft werden, geben Sie in das Feld 1800 ein. Die per Default eingestellten 30 Sekunden sollten Sie nicht übernehmen, da Ihnen Ihr Provider sonst möglicherweise aufs Dach steigt.

Unter "Session logging" können Sie optional alle Aktivitäten des Moduls MercuryD mitprotokollieren lassen. Mit einem Klick auf "Add" fügen Sie die gewünschten POP3-Konten hinzu. Folgende Tabelle bietet Ihnen einen Überblick über die einzelnen Felder und Optionen, die für eine erste Konfiguration erforderlich sind.

MercuryD POP3 Client - Konfiguration

Option	Beschreibung
Host	Name oder IP-Adresse des POP3-Servers.
Username	Benutzername für das Login auf dem Server.
Password	Login-Passwort.
Local user	Name eines lokalen Users, in dessen Mailbox alle Mails weitergeleitet werden. Wenn es sich bei der Mailbox um eine Domänen-Mailbox (eine Mailbox für viele Anwender) handelt und Sie dieses Feld leer lassen, untersucht Mercury die Felder TO, CC und BCC nach einem lokalen Benutzer.
Default user	Findet Mercury bei einer Domänen-Mailbox keinen passenden lokalen Benutzer, wird eine eingehende Mail an diesen Account geschickt. Diese Einstellung ist nur sinnvoll, wenn „Local user“ leer ist.
Connection port/type	TCP/IP-Port, an dem oben angegebener Host Verbindungen annimmt. Bei den Typen „normal“ und „encryption via STARTTLS“ ist dies in der Regel der Port 110. SSL-Verbindungen erfolgen meist über 995.
Headers	Hier können Sie zusätzliche Mail-Header angeben, in denen Mercury nach einem lokalen Benutzer-Account suchen soll - beispielsweise X-Deliver-To

MercuryP - POP3 und IMAP4 Server

Damit die Anwender im lokalen Firmennetz auf die empfangenen E-Mails auch zugreifen können, ist noch das Modul MercuryP zu konfigurieren. Mercury stellt damit einen lokalen POP3-Server zur Verfügung. Dazu wählen Sie im Menü "Configuration" den Punkt "MercuryP POP3 Server".

Unter "IP Interface to use" geben Sie die IP-Adresse ein, die Sie an die Netzwerkkarte gebunden haben. Unter dieser Adresse stellt dann der POP3-Server den Clients seine Dienste zur Verfügung. Die Einstellungen für den TCP/IP-Port belassen Sie bei Port 110, dem Standard-Port für POP3-Verbindungen. Die Voreinstellungen für den TCP/IP-Timeout können Sie ebenfalls ohne Änderungen übernehmen.

Alle Optionen unter "Global profile settings" sollten Sie deaktivieren. Diese Funktionen entsprechen teilweise nicht dem POP3-Standard und werden für eine erste Konfiguration nicht benötigt. Sie können auch Mailbox-spezifische Profileinstellungen vornehmen, indem Sie im Mailverzeichnis eines Nutzers die Datei POP3.PRO anlegen und beispielsweise die folgende Zeile einfügen, um bei diesem Nutzer heruntergeladene Mails als gelesen zu markieren:

mark read: Y

MercuryP - POP3 Server Zusatzoptionen und IMAP4

Wichtig ist der Reiter "Connection control". Hier legen Sie fest, von welchen IP-Adressen im LAN der POP3-Server Verbindungen annehmen soll. Unter "Add" tragen Sie die einzelnen Adressen der Clients oder ganze Adressbereiche ein. Sie können auch bestimmten IP-Adressen den Zugriff verwehren.

Wenn Sie „refuse“ und „allow“ kombinieren, geht Mercury nach einem einfachen Schema vor: Der spezifischere Eintrag (also derjenige, welcher die wenigsten IP-Adressen einschließt) gewinnt.

Für eine grundlegende Konfiguration sind die unter dem Reiter „SSL“ abgelegten Optionen nicht notwendig. Hier könnten Sie SSL/TLS-Verbindungen konfigurieren, damit die Clients verschlüsselt auf den Server zugreifen können. Wenn Sie kein „offzielles“ Zertifikat haben, erstellt Mercury per „Create“ eines für Sie.

Über den eingebauten IMAP4-Server erlauben Sie den Benutzern den Zugriff auf Ihre Mailbox über das IMAP4-Protokoll. Die grundlegenden Einstellungen können Sie einfach so belassen. Für den Reiter „Connection control“ gelten dieselben Regeln wie bei POP3.

SPAM vermeiden

In der aktuellen Version von Mercury haben Sie eine Reihe von Möglichkeiten, SPAM abzuwehren. Zum einen sind das die Einstellungen, die Sie beim SMTP-Server vornehmen können, um schon bei der Verbindungsaufnahme Spammer abzuwehren. Zusätzlich bietet Mercury selbst das Menu „Configuration / Content Control“. Hier ist allerdings eine Menge Wissen über reguläre Ausdrücke und viel Handarbeit erforderlich, die immer wieder anfällt, um Mercury auch die neuesten Spams beizubringen.

Hier kommt der SpamHalter von Lukas Gebauer ins Spiel. Er erweitert Mercury um einen Spam-Filter, der einen einfachen Bayes’schen Algorithmus einsetzt. Wählen Sie „Configuration / SpamHalter“ und Sie gelangen ins Setup für das Plugin. Parallel sollten Sie SPAMHALTER.pdf aus dem Hauptverzeichnis von Mercury öffnen. Hier ist die Dokumentation zu finden – eine eingebaute Hilfe bietet SpamHalter nämlich nicht.

SpamHalter einrichten

Der Tab „General Settings“ bietet genau eine Option, nämlich das Einschalten der Spam-Filterung. Wählen Sie die Checkbox an und wechseln zum Reiter „Basic Settings“. Das Datenbank-Verzeichnis können Sie so lassen, dort legt das Tool die verschiedenen Datenbanken im sqlite3-Format ab.

SpamHalter verwendet zwei lokale Mailboxen, über die er falsch erkannte Mails nachtrainieren kann. Nicht erkannte Spam-Mails können Benutzer an die unter „Correction account for missed spams“ festgelegte Mailbox schicken. Fälschlicherweise als Spam markierte Mails (False-Positives) schicken Benutzer an den Account, den Sie bei „Correction account for false positives“ eintragen. Hierbei muss es sich um echte Mailboxen handeln – Alias-Konten sind nicht erlaubt!

Unter „Local IP networks“ tragen Sie die Netzwerk-Maske(n) für das lokale Netzwerk ein, damit SpamHalter Mails von lokalen Anwendern nicht klassifiziert. Netzwerk-Masken haben beispielsweise das Format 192.168.0.0/16. Mit dieser Maske würden alle IP-Adressen selektiert, die mit 192.168. anfangen. Näheres hierzu finden Sie im Artikel So funktionieren TCP/IP und IPv6.

Im Feld „Road warrior’s dynamic DNS names“ können Sie DNS-Einträge hinterlegen, die Ihre mobilen Clients beispielsweise per dyndns.org identifizieren. Wenn er sich mit diesem Hostnamen (z.B. meinaccount.dyndns.org) beim SMTP-Server anmeldet, löst SpamHalter den Hostnamen auf und vergleicht ihn mit der tatsächlichen IP. Stimmen sie überein, wertet das Tool die Mail als lokal.

Bayes-Einstellungen

Die beiden Reiter „Bayesian settings“ und „Bayesian tokenizer“ sind für die Funktionsweise des Bayes-Filters verantwortlich. Vor allem der erste Reiter wird sicherlich häufiger von Ihnen verwendet werden, denn er bietet Möglichkeiten zum Fein-Tuning.

Bei der „Database update strategy“ sollten Sie mindestens eine Weile den Punkt „Train always“ beibehalten, damit SpamHalter genügend Material für die Bayes-Analyse sammeln kann. Haben Sie einen stabilen Level erreicht, können Sie auf „Train on Errors“ umschalten. Dann lernt der Bayes-Filter nur noch, wenn Mails an spam oder nospam weitergeleitet werden.

Mittels „SPAM probability percent level“ legen Sie den Schwellwert fest, ab dem SpamHalter eine Mail als SPAM einordnet. Setzen Sie ihn zu hoch, erkennt er nicht genug SPAMs, setzen Sie ihn zu niedrig, gibt es „False Positives“.

Noch nicht in der Datenbank enthaltene Wörter erhalten den unter „Probability level for unknown tokens“ festgelegten Wert für die SPAM-Wahrscheinlichkeit. Das ist nur der initiale Wert, im Betrieb wird er sich entsprechend anpassen.

Die Anzahl „guter“ Wörter wird mit dem Wert von „Level of not-spam preference“ multipliziert. Damit sinkt die Wahrscheinlichkeit, dass eine Mail fälschlicherweise als Spam deklariert wird. Lukas empfiehlt für den Anfang einen Wert von 4. Enthält die Datenbank genug Trainingsmaterial, können Sie ihn auf 2 absenken.

Mit „Count of classified tokens“ legen Sie fest, wie viele Wörter SpamHalter zur Klassifizierung der Mail benutzt. Den Standardwert von 20 können Sie ruhig beibehalten. Die Einstellungen im Reiter „Bayesian tokenizer“ können Sie so belassen.

Weitere Einstellungen

Der Reiter „Advanced settings (1)“ bietet Ihnen die Möglichkeit, bestimmte Mails automatisch als SPAM einordnen zu lassen und damit den Bayes-Filter zu trainieren. Wenn Sie beispielsweise ein Mailkonto „honey@ihredomain“ eingerichtet haben, das Sie als Honeypot für Spammer nutzen wollen, tragen Sie es bei „Honeypot:“ ein.

Findet SpamHalter einen der unter „Block messages with headers“ konfigurierten Email-Header, wird die Mail ebenfalls als Spam einsortiert. Hier können Sie beispielsweise x-blocked eintragen und Mercury über den Reiter „Spam Control“ vom SMTP-Server anweisen, unter bestimmten Bedingungen den Header x-blocked zu setzen.

Über den Reiter „Whitelist“ können Sie Absende-Adressen eintragen, die nicht auf SPAM geprüft werden sollen. Mit den Optionen auf dem Reiter „Message tagging“ legen Sie fest, wie SpamHalter bearbeitete Mails kennzeichnen soll.

Die Veränderung der Betreffzeile über „Subject prefix“ ist nicht zwingend zu empfehlen. Zwar erlaubt Sie dem Benutzer eine einfache Zuordnung, macht sich aber nicht besonders schön beim Antworten. Tragen Sie dennoch etwas ein, erscheint der Text eingerahmt in eckige Klammern vor dem eigentlichen Betreff, also beispielsweise „[SPAM] ursprünglicher Betreff“.

Nützlicher sind die Informationen, die SpamHalter in den Nachrichtenkopf einträgt. Diese Daten können von einem Mailprogramm problemlos ausgelesen und verwendet werden. Den Default-Header X-SPAMHALTER können Sie so beibehalten. Je nachdem, welche Regeln gegriffen haben, fügt das Tool die folgenden Informationen ein:

Kommt die Nachricht von einem Absender, der in der Whitelist steht, erhält der Message-Header den unter „Message was whitelisted“ eingetragenen Text. Also beispielsweise:

X-SPAMHALTER: Whitelisted

Ist dort nichts konfiguriert, erzeugt SpamHalter auch keinen Header. Trifft die weiter oben beschriebene Regel „Block Messages with headers“ zu, schreibt SpamHalter den unter „Message was blocked“ eingetragenen Text in den Header:

X-SPAMHALTER: Blocked SPAM!

Zudem können Sie Debug-Informationen in den Header schreiben lassen, um beispielsweise herauszufinden, warum bestimmte Mails als Spam deklariert werden. Dazu schalten Sie die Checkbox „Add headers with debug information“ ein und legen Sie einen Debug-String fest.

Ist der Wert für „Spam probability information prefix“ gesetzt, schreibt das Programm eine Header-Zeile, die Auskunft über die Spam-Wahrscheinlichkeit gibt. Dies hilft unter anderem dabei, den optimalen Grenzwert festzulegen, ab dem Mails als Spam deklariert werden.

Wird der Grenzwert überschritten, schreibt SpamHalter zusätzlich die Header-Zeile, die Sie unter „Message was detected as SPAM:“ konfiguriert haben:

X-SPAMHALTER: SPAM detected!

Wenn Sie die Mail-Clients so konfigurieren, dass sie Mails auf diese Zeile untersuchen, können Sie problemlos eine automatische Sortierung vornehmen lassen.

Anlegen von Alias-Namen

Zu guter Letzt legen Sie bei der Konfiguration von Mercury noch Alias-Namen für E-Mail-Adressen an. Dies ermöglicht es, innerhalb des LAN bequem Mails zu verschicken, ohne dass diese über das Internet versendet werden. Auch wenn Sie zum Senden einer Mail an einen Kollegen die externe Mailadresse angeben, erkennt Mercury anhand der Alias-Einstellungen, dass es sich dabei um einen lokalen User handelt und speichert die Nachricht direkt in der Mailbox des Empfängers.

Zum Anlegen eines Alias-Namen gehen Sie wie folgt vor: Wählen Sie im Menü "Configuration" den Punkt "Aliases". Für jeden internen Mercury-User können Sie nun eine externe Mailadresse als Alias anlegen. E-Mails an diese externen Adressen werden von nun an intern weitergeleitet.

Konfiguration der E-Mail-Clients

Nun können Sie von allen Clients aus im LAN Mails versenden und empfangen. Dazu tragen Sie in den Mail-Clients als SMTP- und POP3-Server jeweils die IP-Adresse des Rechners ein, auf dem Mercury läuft. In unserem Beispiel ist diese die Adresse 192.168.80.192 sowie die Standard-Ports 110 für POP3 und 25 für SMTP. Als Benutzername verwenden Sie die in Mercury angelegten lokalen User.

Nun können Sie E-Mails an beliebige Mailadressen versenden. Bei lokalen Usern verwenden Sie wahlweise die lokale Adresse, wie zum Beispiel "Admin", oder die entsprechende externe Adresse.

System-Meldungen und erster Test

Nach der Installation und Konfiguration von Mercury testet man den Mailserver am einfachsten über Telnet. So kann man überprüfen, ob der Server den Clients zur Verfügung steht und ein Verbindungsaufbau möglich ist. Dazu bauen Sie von einem der Clients eine Telnet-Verbindung zum Mailserver auf.

Hierzu geben Sie in Windows unter "Start" - "Ausführen" das Kommando telnet 192.168.4.32 25 ein. Entsprechend Ihrer Konfiguration verwenden Sie die korrekte IP-Adresse des Rechners, auf dem Mercury läuft. Der Mailserver sollte nun korrekt antworten und das Versenden einer Mail ermöglichen. Weitere Details zu den POP3- und SMTP-Kommandos erfahren Sie in unserem Beitrag "E-Mail-Technologie im Detail".

Über das Menü "Window" unter "Statistics" und "System messages" kann man zahlreiche Statistiken und Systemmeldungen abrufen. So kommen Sie dem einen oder anderen Fehler beim Versenden und Empfangen leichter auf die Schliche.

Zudem steht die ausführliche Online-Hilfe für alle Optionen über die Taste F1 zur Verfügung.

Fazit

Das in diesem Beitrag beschriebene Beispiel reizt die Fähigkeiten von Mercury bei weitem nicht aus. Mit den vorgestellten Schritten haben sie den Mailserver soweit eingerichtet, dass dessen Einsatz im LAN Sinn macht. Diesen müssen Sie nur an die lokalen Gegebenheiten in Ihrem Netz anpassen.

Bei Bedarf lässt sich das System nach Belieben ausbauen: Ausgefeilte Filterregeln und Zusatzmodule helfen beim Kampf gegen Spam und der eingebaute Listserver hilft beim Versenden von Mails an große Benutzergruppen. Eine detaillierte Beschreibung dieser weiteren Funktionen würde jedoch den Rahmen dieses Beitrags sprengen. (mha)