Erfahrungen mit rspamd

[Patrick Ben Koetter]

* Harald Witt <postfixbuch-users at listen.jpberlin.de>:
> Hallo P at trik,
> 
> danke für die offenen Worte betreffs amavis. Ich setze es auch noch ein, obwohl die Resultate zunehmend schlechter werden. Die rspamd-Geschichte erscheint  mir vielversprechend. Danke!

Die "zunehmend schlechteren Ergebnisse" liegen eher am eingebundenen SpamAssassin, oder?


> Aber ich schreibe das hier jetzt eigentlich, weil mir der Terminus "Monolith" so gefallen hat. Ach ja: MS-DOS und die frühen Windows-Versionen. Da war ja der TCP/IP-Stack monolithisch. Mann ist das lange her :-)

Gell, der Begriff hat was. :) Erinnert mich an die Anfänge von Postfix, als
wir erklärt haben, warum Postfix so ist wie es ist:

    Monolith Sendmail vs. Postfix Multi-Daemon Compartmentalized Architecture

Im Alltag werden die Privatanwender und kleine Unternehmen mit "nur" einem
Host, auf ewig mit amavis Systemarchitektur glücklich sein. Da schmerzt es
dann wohl eher, dass diese Nutzergruppen nicht so häufig über das
erforderlichen Perl-KnowHow verfügen, um amavis punktgenau zu konfigurieren.
Mit nativem Perl in der Config-Datei muss man auch erst mal umgehen können. Es
ist eine Stärke und zugleich einer der größten Schwackpunkte, dass man amavis
nativ mit Perl konfiguriert und nicht über eine Konfigurationssprache.

Wer amavis auf mehr als einem Mailhost, z.B mit dem Ziel ein
Performance-Cluster aufzubauen, einsetzen will, der begegnet den Grenzen
seiner Architektur und der seiner Helfer (SpamAssassin, Virenscanner).

Bei der Provisionierung und Konfiguration helfen die CM-Tools wie Puppet,
ansible, chef und - wie wir es am liebsten machen wenn man uns läßt -
SaltStack. (Angefangen habe ich mit cfengine 2 und seitdem sehe ich zu wie die
nächste CM-Sau durch das Dorf getrieben wird…. Soviel zum Thema "Alte Säcke"…)

Schwierig wird es wenn Du allen Hosts live Daten zur Verfügung stellen
willst/musst. Ich denke da z.B. an Bayes Token (für SpamAssassin), die man
zwischen Clustern an mehreren Standorten in einem master/master Setup in sync
halten will.

Been there, done that in 2013 mit einem SQL-Backend. Zum Glück gibt es da
mittlerweile mit Redis Backends, die besser für solche Aufgaben geeignet sind
- so sehr ich PostgreSQL auch schätze.

amavis erstellt Prüfsummen für Nachrichten, die es inspiziert hat, und stellt
diese seinen children lokal zur Verfügung. So muss es eine Nachricht, die
schon mal geprüft worden war (Massenvirus etc.), nicht nochmal aufwändig
analysieren. Liegt die Prüfsumme bereits vor, spart es sich die Analyse und
verwendet sofort auch die ebenfalls abgespeicherte Content Class und führt die
damit verknüpften Aktionen aus.

Das funktioniert gut auf einem Host, teile diese Informationen mal zwischen
allen Hosts eines Performance-Clusters, das von einem LoadBalancer angesteuert
wurde, der absichtlich keine stickyness für recurring clients vorgegeben hat.

Gerade hier - auf grossen Plattformen - wirken sich Maßnahmen zur Einsparung
unnötiger Aktivitäten besonders gut aus - weniger und seltener Hardware
kaufen, weniger Stromverbrauch etc. pp.

Wir haben amavis ein wenig gepimpt als wir vor 2 Jahren einen Patch
eingereicht haben mit dem amavis DNSBL-artig DNS-Server fragen kann und in
Abhängigkeit von der Antwort Policies anwenden kann.

So haben wir z.B. Clients der CSA (Certified Sender Alliance) von teuerer
Spam-Prüfung ausgenommen. Erkannt haben wir sie, indem wir die Liste aller
CSA-Netze - als CSA-Member hat man Zugriff auf sie - in einen rbldnsd gepackt
und diese dem amavis-Cluster zur Verfügung gestellt haben.

Jeder amavis aus dem Cluster konnte - mit dem von uns entwickelten
DNSBL-Feature in die @client_ipaddr_policy eingebunden - live die IPs im DNS
des rbldnsd-Dienstes abfragen. Je nach Antwort wurde die IP dann einer
policy_bank zugewiesen, die Spam-Prüfung deaktiviert (und Malware-Scannen
anläßt).

Das hat damals die Anschaffung von 6 neuen Servern gespart. Die Runde
nachdenken und zwei Tage Entwicklung haben sich da echt bezahlt gemacht.

Solche Features könnte ich mehr gebrauchen. Ich bin mir aber auch durchaus
bewußt, dass meine Requirements bisweilen durchaus den Rahmen des Normalen
(lies: Alltäglich) verlassen. :)


> Also jetzt wisst ihr, dass ich auf die Rente zugehe :-(((

Da kannst Du dann wieder Software erforschen und beim Versuchen und Irren Zeit
vertrödeln ohne dass jemand mit der Stechuhr hinter Dir steht. Hat auch was! :)

p at rick

-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein