Spam in der Dose Nachdem bei uns bald die Umstellung von über 2800 Exchange Postfächern auf Groupwise 7 unter OES Linux bevorsteht war auch die Anschaffung eines Spamfilters notwendig. Auf die Empfehlung eines Consulters hin wurde GWAVA 4 von beginfinite installiert und an die Groupwise Internet Agents gehängt.

Um eine optimale Konfiguration zu erzielen wurde ein Berater von der Inetra de GmbH hinzugezogen.

Die dann folgende Einführung in das GWAVA 4 System offenbarte dann aber 3 erhebliche Mängel, welche vom anwesenden Berater jedoch als "Intended-by-design" erklärt wurden.

  1. Die Verwendung von RBLs in den Received-Headern einer RFC821/SMTP Nachricht: GWAVA 4 prüft jede (!!!) IP-Adresse in einer Email gegen eine Liste von definierbaren RBLs. Was sich zuerst harmlos liest erweist sich aber nach kurzer Betrachtung als fataler Fehler, sollten RBLs zum Einsatz kommen, die dynamische IP-Adressen listen. Der erste Received-Header, der in eine RFC821 Nachricht geschrieben wird, wird bei legitimen Emails vom SMTP-Server der jeweiligen Firma oder ISP geschrieben, der die Email von der Client-Anwendung entgegengenommen hat, z.B.:
    Received: from endor.clients.fladi.at ([::ffff:85.127.229.xxx]) (AUTH: LOGIN xxxxxxxxxx) by uni.fladi.at with esmtp; Thu, 14 Jun 2007 23:29:56 +0200 id 0006B2A8.4671B354.xxxxxxxxxx
    Hier nimmt der SMTP-Server auf uni.fladi.at die Email nach einem SMTP-AUTH von dem Client endor.clients.fladi.at an, welcher aber eine dynamische IP besitzt. Wenn uni.fladi.at nun diese Nachricht an ein System relayen würde, das GWAVA 4 im Einsatz hat, wird die IP 85.127.229.xxx dort von einer RBL als dyn. IP erkannt und die Email, obwohl sie absolut legitim ist, von GWAVA 4 als Spam erkannt werden und je nach Einstellung diese Email sogar droppen. Somit können alle SMTP-Server, die ein Relay für alle authentifizierten User (meist über SMTP-AUTH) oder bei IPSs, die ihre IP-Ranges (meist dyn. IP) über ihren SMTP-Server relayen von GWAVA fälschlicherweise als Spam eingestuft werden. Der Designfehler liegt hier darin, dass GWAVA 4 nur noch die bereits vom GWIA angenommene Nachricht im Dateisystem des Servers abgreit, und somit die IP-Adressen nur noch aus dem Header lesen kann, jedoch nicht mehr die IP-Adresse zu sehen bekommt, mit der sich der Remotehost zum GWIA verbunden hat. Auf dieses Problem angesprochen verwies der Berater von Inetra auf Spamhaus.org, welche mehrere RBLs betreiben. Auf der Homepage dort sollte laut ihm angeblich darauf hingewiesen werden, dass die Überprüfung von Received-Headern empfohlen wird. Jedoch dürfte er hier wohl die Anwendung von SBLs mit derer von RBLs verwechselt haben. Jedoch findet sich auf keiner namhaften Anti-Spam-Seite eine Empfehlung für die Überprüfung von Received-Headern, es wird sogar auf verschiedenen Mailingliste explizit davon abgeraten.
  2. RBLs sollten immer nur direkt vom GWIA benutzt werden da nur dieser zuverlässig die IP des Gegenüber kennt, und diese gegen eine RBL prüfen kann.
  3. GWAVA 4 bietet keine Ausfallssicherheit: Es können zwar mehrere Scanner auf eine gemeinsame sogenannte Engine geschaltet werden, um einheitliche Filtersets zu gewährleisten. Fällt jedoch diese Engine aus, so können auch die verteilten Filter nicht mehr arbeiten. Eine Lösung für eine Synchronisation von mehrereren verteilten Engines gibt es nicht.

Auch wenn ich in einem vorherigen Post einmal GWAVA empfohlen habe, so muss ich inzwischen nach diesen Erfahrungen vom Einsatz von GWAVA 4 im produktiven Betrieb abraten!