Exchange Server und 3rd Party Antispam Software

Für den Exchange-Server 2003 gibt es, wie viele schon wissen, kostenlos den Intelligent Message Filter, welcher auf der Microsoft SmartScreen-Technologie von Microsoft Research basiert und im kommenden SP2 in einer erweiterten Version integriert sein wird. Viele Kunden setzen jedoch, teilweise zusätzlich, Antispam-Software von 3rd Party-Herstellern ein. An dieser Stelle treten dann oft Fragen auf, die mit der Integration dieser Tools zu tun haben:

  • Wie kann man vorgefilterte Nachrichten in den Junk-E-Mail-Ordner von Outlook automatisiert verschieben?
  • Wie kann der Anwender Nachrichten, die nicht oder die falsch erkannt wurden, an die Filter-Engine zurückgeben, damit diese lernen kann?
  • Wie kann das 3rd Party-Relay Mails nur für tatsächlich existierended Empfänger annehmen und geratene Empfänger abweisen?

Wie kann man vorgefilterte Nachrichten in den Junk-E-Mail-Ordner von Outlook automatisiert verschieben?

Typischerweise werden 3rd Party-Tools auf dem Exchange-Server installiert und hängen sich mittels Event Sinks direkt in die Kommunikationskanäle hinein. Dabei wird dann oft in jedem Postfach ein eigener Ordner erzeugt, in den Spam verschoben wird oder es wird gleich der Junk-E-Mail-Ordner benutzt. Was kann man aber tun, wenn der Spamfilter sich auf einem Relay vor dem eigentlichen Exchange befindet?

Diese Kombination ist inbesondere mit UNIX-basierenden Relayservern in einer DMZ beliebt, bei der SpamAssassin als Antispam-Software genutzt wird. Im Gegensatz zum SCL-Wert des IMF wird hier das Ergebnis des Spamfilters direkt in die Email geschrieben. Meist kann der Administrator auswählen, ob er entweder das Subject durch spezifische Tags (Beispiel "[SPAM]") umschreiben läßt und/oder ob der Status als X-Header in den Header jeder Email eingetragen wird.

Der erste Lösungsansatz wäre eine serverbasierende Regel, die man mit Outlook einrichten kann. Eine derartige Regel könnte zum Beispiel auf das Vorkommen bestimmter Schlüsselworte in der Nachrichtenkopfzeile abheben und dann die zutreffenden Mails in den Junk-E-Mail-Ordner verschieben, damit auch bei Nutzung über OWA, OMA oder Active Sync die Emails schon serverseitig aus dem Posteingang entfernt werden.

Problematisch ist aber das zentrale Verteilen von serverseitigen Regeln innerhalb einer Exchange-Umgebung, da diese im Postfach des Anwenders gespeichert werden und der Administrator darauf nicht so einfach zugreifen kann. Um jetzt nicht auf jedem Client manuell eine Regel-Datei importieren zu müssen, hat Microsoft im Exchange Server 2003 SDK im Juni diesen Jahres eine beispielhafte Lösung im Quelltext dokumentiert:

The Microsoft Exchange Server 2003 anti-spam infrastructure takes advantage of the SMTP service that ships in the Microsoft Windows 2000 and Microsoft Windows Server 2003 operating systems. The SMTP service provides an event architecture that allows custom extensions of the core RFC 2821 protocol. For more information about this architecture, see the Microsoft Windows 2000 SMTP Service Events white paper and the SMTP Server Events documentation on MSDN.

  • The Anti-Spam Infrastructure section describes the anti-spam infrastructure in Exchange Server 2003 and discusses how the protocol sink template and your custom spam filter fit into this structure.
  • The Spam Filter section discusses the functionality your spam filter should include, as well as what the spam confidence level (SCL) is and how your filter should use the SCL value.
  • The Administration section contains information about the settings you will need to set on the content filter object.
  • The Configuration section illustrates how to create the content filter object and discusses the data held by that object.
  • The Protocol Sink Template section describes the sample protocol sink template, the code files included, and how to extend and build the template.

Wer den Eventsink nicht selbst bauen möchte (oder kann), der kann mit dem SpamMover for MS Exchange 2000/2003 auch eine fertige Lösung käuflich erwerben.

Wie kann der Anwender Nachrichten, die nicht oder die falsch erkannt wurden, an die Filter-Engine zurückgeben, damit diese lernen kann?

Ein interessanter Ansatz ist die Nutzung von öffentlichen Ordnern für Spam-Management. In vielen Organisationen ist die Nutzung privater Emails nicht erlaubt und damit die Möglichkeit gegeben, zentral Spam zu managen. An dieser Stelle werden als Spam erkannte Emails nicht mehr gekennzeichnet an die Anwender zugestellt, sondern an eine zentrale Emailadresse umgeleitet, die zum Beispiel durch einen öffentlichen Ordner abgebildet wird. Auf diesen bekommt dann das Antispam-Team Zugriff und kann regelmäßig nach falsch erkanntem Spam, auch false positives genant, Ausschau halten.

Diesen zentralen Ansatz kann man im nächsten Schritt dahingehend erweitern, dass man einen weiteren Ordner zur Verfügung stellt, in den Mitarbeiter nicht erkannten Spam hineinschieben können. Damit umgeht man das Problem, dass bei einer eventuellen Weiterleitung durch den Anwender relevante Header der Orginalmail möglicherweise beschädigt werden oder verlorengehen, was für das Lernen des Spamfilters negative Auswirkungen hat. Diese Problematik ist für eine Reihe von Mailclients bei Spamcop in dem FAQ-Punkt How do I get my email program to reveal the full, unmodified email? beschrieben.

SpamAssassin aus unserem obigen Beispiel ist in der Lage, nicht erkannten Spam über das eingebaute Bayesian statistical-filtering system zu lernen und an drei unterstützte Hash Sharing-Systeme Razor, Pyzor und DCC weiterzugeben. Eine beispielhafte Konfiguration in Kombination mit einem Exchange-Server könnte dabei so aussehen:

  • Anwender verschieben nicht sowie falsch erkannten Spam in je einen öffentlichen Ordner Spam undetected und Spam false positives.
  • Der SpamAssassin-Server holt Spam undetected regelmäßig mit fetchmail über IMAP4 ab und gibt sie an procmail als MDA mit einer speziellen Konfiguration für Spam weiter.
  • Der SpamAssassin-Server holt Spam false positives regelmäßig mit fetchmail über IMAP4 ab und gibt sie an procmail als MDA mit einer speziellen Konfiguration für Ham weiter.
  • Procmail übergibt die Email dabei jeweils serialisiert SpamAssassin im Lernmodus, um Lastspitzen zu vermeiden.

Eine dazu geeignete .fetchmailrc könnte bei Platzierung der beiden Ordner in einen Toplevel-Public Folder mit dem Namen SPAM so aussehen:

set postmaster "root"
set bouncemail
set no spambounce
set properties ""
set syslog

poll Exchange-Servername
proto IMAP
port 143
user 'User'
pass 'Password'
mda "/usr/bin/procmail -m $HOME/.procmailrc-spam"
folder "Public Folders/SPAM/SPAM undetected"
fetchall
no keep
no rewrite

poll Exchange-Servername
proto IMAP
port 143
user 'User'
pass 'Password'
mda "/usr/bin/procmail -m $HOME/.procmailrc-ham"
folder "Public Folders/SPAM/SPAM false positives"
fetchall
no keep
no rewrite

Fetchmail holt dabei die Mails ab und löscht nach erfolgreicher Verarbeitung diese auf dem Quellserver. Der Zugriff über IMAP4 kann dabei auch noch mit SSL abgesichert werden, damit die Benutzerdaten und das Kennwort nicht im Klartext übertragen wird. Als Benutzeraccount benötigt man einen Windows-User, der schreibenden Zugriff auf diese beiden öffentlichen Ordner hat sowie IMAP4 als Protokoll gegen den Exchange-Server nutzen darf. Der Exchange-Server muß so eingerichtet werden, dass der Zugriff mittels IMAP4 möglich ist.

Da bei verschiedenen Exchange Server- und Sprachversionen der Top Level Public Folderroot auch Öffentliche Ordner anstelle Public Folders heißen kann, sollte man am einfachsten einmal mit Ouotlook Express auf den Ordner zugreifen und dabei das Debuglog aktivieren. Im Logfile sieht man dann sehr schön, wie genau der Ordner anzusteuern ist. In diesem Beispiel wäre es dann &ANY-ffentliche Ordner - die deutschen Umlaute müssen zum Beispiel hier maskiert werden.

Fetchmail übergibt die abgerufenen Mails dann an Procmail, für welches ich zwei verschiedene Konfigurationen .procmailrc-spam und .procmailrc-ham angelegt habe. Als erstes schauen wir auf die Verarbeitung von nicht erkanntem Spam:

SHELL=/bin/sh
UMASK=133
PATH=/usr/local/bin:/usr/local/lib:/bin:/usr/bin:/usr/bin/mh/:/usr/lib/mh/
BASEDIR=$HOME

LOGFILE=$BASEDIR/procmail-spam.log
VERBOSE=no
LOGABSTRACT=yes

:0: spamassassin.lock
* ^TO_
|spamassassin --report

:0
/dev/null

Die Nutzung eines Lockfiles mittels spamassassin.lock dient zur Serialisierung der Abarbeitung der Emails, um möglichen Performanceproblemen durch zuviele parallele Spamassasin-Aufrufe zu begegnen. Emails, die aus irgendeinem Grund nicht vom Procmail-Filter erfaßt werden, werden zum Schluß nach /dev/null in das Datennirwana geschickt.

Die Verarbeitung von falsch erkanntem Spam erfolgt ähnlich. Hier wird einmal sa-learn zum Lernen von Ham aufgerufen und in einem zweiten Aufruf die Auto-Whitelist von Spamassasin genutzt:

SHELL=/bin/sh
UMASK=133
PATH=/usr/local/bin:/usr/local/lib:/bin:/usr/bin:/usr/bin/mh/:/usr/lib/mh/
BASEDIR=$HOME

LOGFILE=$BASEDIR/procmail-ham.log
VERBOSE=no
LOGABSTRACT=yes

:0Wic: sa-learn.lock
* ^TO_
|sa-learn --ham

:0Wi: auto-whitelist.lock
* ^TO_
|spamassassin -aW

:0
/dev/null

Wie kann das 3rd Party-Relay Mails nur für tatsächlich existierended Empfänger annehmen und geratene Empfänger abweisen?

Ein weiteres Problem bei der Nutzung von Antispam-Software auf externen Relays ist das Problem nicht zustellbarer Empfänger. Seitdem Spammer mittels Namenslisten oder auch mittels brute force versuchen, gültige Email-Empfangsadressen zu erraten, stehen wir vor dem Problem von tausenden Mails an zum Beispiel bob@domain.tld und alice@domain.tld.

Diese werden standardmäßig von Exchange Servern angenommen, wenn diese für *@domain.tld zuständig sind und mit einem NDR beantwortet, wennn es keinen internen Empfänger gibt. Genau diese NDRs gehen dann an die gefälschte Absendeadresse und belasten das eigene Mail-System und das Postmaster-Postfach unnötig. Im schlimmsten Fall bekommt ein ahnungsloser Dritter, dessen Emailadresse der Spammer als gefälschte Absendeadresse benutzt, tausende NDRs.

Seit Exchange Server 2003 kann durch die Nutzung der Recipient Filter-Funktion vor der Annahme der Email beim RCPT TO:-Kommando eine Abprüfung direkt gegen das Active Directory erfolgen. Hier wird geprüft, ob der angegebene Empfänger intern überhaupt existiert. Ist dies nicht der Fall, wird die SMTP-Session direkt mit einem 550 User unknown beendet. Der Vorteil dieser Lösung liegt darin, daß a) der Exchange-Server keinen NDR generieren muß (für diesen ist in diesem Moment ja noch der einliefernde Mailserver zuständig) und man b) Systemresourcen spart, da ein LDAP-Lookup wesentlich weniger Ressourcen verbraucht als die Antispam-Filterung und die Email samt Attachment noch gar nicht übertragen wurde.

Für Exchange 5.5 und Exchange 2000 gibt es 3rd Party Tools, welche die Recipient Filter-Funktion nachrüsten. Als Beispiel sei an dieser Stelle für Exchange 2000 ORF Enterprise Edition von Vamsoft sowie GFI MailEssentials für Exchange 5.5 und 2000 genannt. Preislich unterscheiden sich beide Produkte: Während bei Vamsoft pro Server lizenziert wird, erfordert GFI eine Lizenz pro Postfach. Das führt zu einem deutlichen Preisvorteil für Vamsoft, wenn man nur die Recipient Filter-Funktion als Kriterium für die Anschaffung heranzieht. Dafür unterstützt GFI aber auch Exchange 5.5.

Wenn man also auf der Mailbox-Serverseite die Recipient Filter-Funktion eingerichtet hat, stellt sich nun die Frage, wie der davor liegende Relayserver mit der Antispam-Software daraus Nutzen ziehen kann. Eine oft in den Newsgroups empfohlene Lösung über die Nutzung von Emailadress-Exports, wie sie zum Beispiel auch Patrick Ben Koetter und Ralf Hildebrandt in Postfix - Exchange Server Mailrelay propagieren, halte ich für den falschen Ansatz. Derartige Export/Import-Jobs laufen immer asynchron und sind anfällig für Probleme im laufenden Betrieb.

Die bessere Lösung ist an dieser Stelle aus meiner Sicht die Nutzung von LDAP oder SMTP call ahead. Dabei nimmt der Relayserver die SMTP-Session an und fragt nach dem RCPT TO: -Kommando entweder per LDAP-Lookup, oder mittels einer zweiten SMTP-Session den internen Server an, ob er eine Mail an diese Adresse überhaupt annehmen würde. Für die gängigen Mailserver unter UNIX wie Postfix oder Exim ist das kein Problem, für Sendmail gibt es dafür Milter-Plugins wie zum Beispiel milter-ahead.

Das einzige Problem, welches sich bei Nutzung der Recipient Filter-Funktion ergibt, sind dictionary attacks, welche zu Denial of Service-Angriffen und dem Enumerieren von gültigen Emailadressen genutzt werden können. Patrick und Ralf warnen im obigen Link deshalb auch zurecht:

Probably the first impulse will be to have Postfix do LDAP lookups on demand by connecting to the Exchange Server through LDAP and query for valid recipients. This is not recommended, because in critical situations e.g. during a dictionary attack there will be thousands of queries a minute, distracting the Exchange server from its primary job being a groupware server. There will be so many queries that the Exchange server will slow down so badly that the dictionary attack will result in a DoS to your groupware server.

Sie verkennen dabei zwar, daß die LDAP-Lookups nicht an den Exchange Server, sondern an einen Globalen Katalog-Server (GC) gestellt werden müssen. Man könnte ja auch einen GC exklusiv für die Nutzung durch Postfix vorsehen, damit der Exchange Server nicht von der Last dieser Anfragen belastet wird. Trotzdem bleibt der Kern der Warnung im Prinzip richtig.

Aus diesen Gründen sind Methoden zur Vermeidung derartiger Angriffe in Kombination mit der Recipient Filter-Funktion auch sehr sinnvoll. Bei der Nutzung von LDAP muß der Schutz auf dem Relayserver direkt erfolgen, bei SMTP call ahead reicht auch die Implementierung auf dem dahinter liegenden Mailbox-Server. Von Microsoft gibt es für den Exchange Server 2003 sowie den IIS 6.0 im Window Server 2003 entsprechende Konfigurationsanleitungen: