[Postfixbuch-users] amavisd-new-Intergation: forward_method aus Lookup?

[Stefan Förster]

Am 29.05.2008 um 23:12 schrieb Peer Heinlein:

>> Peer, ich dreh' den Spieß jetzt mal rum: Wieviel weißt Du konkret  
>> über
>> die dspam-Integration in amavisd-new, z.B. Über Dinge wie:
>>
>>      my($proc_fh,$pid) = run_command('&'.fileno($fh), "&1", $dspam,
>>             # qw(--stdout --deliver-spam)  # dspam < 3.0
>
> Nichts weiß ich darüber, darum Frage ich doch. Ich will doch was
> lernen :-) Das war eine ganz ehrlich ganz ernst gemeinte Frage, kein
> rhetorisches Gegenhalten. Bitte nicht mißverstehen.

Dann entschuldige bitte. Die dspam-Integration in amavisd-new sieht,  
soweit ich das Überblicken kann so aus, daß für jede Nachricht ein  
"dspam"-Prozess erzeugt wird und diesem die Nachricht dann vorgesetzt.  
Das alles geschieht mit einem einzelnen User, also ist schonmal nichts  
mit "per user bayes dictionaries" (was für ein Ausdruck!). Dann schaut  
er sich das Ergebnis an und vergleicht das mit dem Ergebnis von SA.  
Liegt dspam falsch, wird ihm die Nachricht zum Trainieren neu  
vorgesetzt. Später kann mann dann in der local.cf auf den DSPAM-Header  
Punkte vergeben, das muss man aber selbst einstellen.

Kurz gesagt: amavisd-new trainiert dspam und benutzt dazu die  
Ergebnisse von SA. Es tut dies nur für einen Account ("$demon_accont")  
und in dem es pro Mail mehrere Prozesse spawnt, mindestens jedoch einen.

Eigentlich - und wir haben das mal mit Konten von zehn Leuten  
getestet, die wirklich unterschiedlicher nicht sein könnten, möchte  
man dspam zum einen mit einer "Gruppe" und auf der Basis einzelner  
Benutzer einsetzen: Für neue Benutzer werden die Ergebnisse der Gruppe  
solange als Stütze hinzugezogen, bis der entsrpechende Benutzer seine  
dspam-Instanz soweit hat, daß er diese Hilfestellung nicht mehr  
braucht. Bei den zehn Konten waren dazu nach dem initialen Training  
mit schon vorhandenen im Schnitt zwischen zehn und zwanzig Mails  
notwendig, die der Benutzer manuell nachkorrigieren musste. Dann  
jedoch war die Quote mit 99,72% bis 99,94% Spam-Erkennungsrate besser  
als alles, was SA bei uns bisher geliefert hat (ja, mit rules_du_jour,  
sa-update etc.). Und während die Zustellzeit für eine Mail mit amavisd- 
new (clamav!) und SA (mit RBL-, RHSBL-, URIBL-Lookups, Razor2, Bayes)  
zwischen 3,6 und 7 Sekunden liegt, dauert es mit amavisd-new (clamav!)  
und dspam selten länger als 700ms, wobei der Löwenanteil für das  
Entpacken der MIME-Parts vor dem clamav-Lauf draufgeht.

dspam ist sicher nicht alleinig glücklich-machend, aber wir würden  
einen schlechten Job bei einer Evaluierung machen, wenn wir nur  
testen, was wir schon kennen ;-)

Und damit mein Geschreibsel auch zu etwas führt: Wenn man die Mails  
via LMTP an dspam übergibt, dann unterscheidet der selbständig  
zwischen verschiedenen Usern. Und um die Verwaltung der Userdatenbank  
nicht zu verkomplizieren (man hält die Daten doch sowieso schon vor,  
für den MTA und den LDA), wäre das mit den verschiedenen  
$forward_method-Ergebnissen eben toll gewesen.


>> Daran hatte ich auch schon gedacht, aber während das mit SQL als
>> Backend noch geht (SELECT IF(..., 'FILTER ... 10024', 'FILTER ...
>> 10030') ...) bist Du damit LDAP halt aufgeschmissen.
>
> Naja, man müßte halt dafür sorgen, daß die Filter-Action dann direkt  
> in
> dem jeweiligen Attribut drin steht...

Ja - und irgendwann sieht der LDAP-Baum dann aus wie ein ADS ;-)


>> Was Du mit
>> Echtzeitfilterung meinst, erschließt sich mir jetzt gerade nicht,
>> ehrlich gesagt.
>
> smtpd_proxy_filter, also pre-queue. Da gehen die FILTER-Actions eben
> nicht.


Ah, also um ehrlich zu sein, das evaluieren wir derzeit noch gar  
nicht, das wollten wir in der zweiten Juni-Woche beginnen. Ich muß  
aber sagen, daß ich ganz ganz ernste Bedenken wegen der Performance  
habe. Kannst Du da vielleicht mal etwas aus dem Nähkästchen plaudern?


Gruß
Stefan
-- 
Updated to Mac OS X 10.5.3. My ~/.signature is still amiss!