Lokale Spam-Erkennung mit rspamd (fetchmail, dovecot, KEIN postfix) sehr langsam

M

mido

0
Hallo liebes HaBo,

derzeit möchte ich ein altes, vernachlässigtes E-Mail-Konto, welches zu 90% Spam beinhaltet, archivieren.
Das im Idealfall ohne den Spam.

Da die E-Mails alle bereits auf einem IMAP-Server liegen, war mein Gedanke, diese mit fetchmail abzuholen und mit rspamd zu klassifizieren.

Das klappt soweit auch:
fetchmail -> rspamc -> dovecot deliver -> lokales maildir

Fetchmail ruft dabei rspamd im "LDA-Mode" auf:
mda "/usr/bin/rspamc --mime --exec \"/usr/lib/dovecot/deliver -d %T\""

Das Problem:
Das scannen und ablegen einer einzelnen Mail (nach Abruf durch fetchmail) dauert 1 - 5 Sekunden.
Das Postfach ist nicht gerade klein, grob überschlagen würde es noch 3 - 4 Tage dauern, bis alle Mails abgerufen sind.

Ich vermute mal, dass v.a. der direkte Aufruf von rspamc / deliver anstelle einer Integration von rspamd über smtp/lmtp der wesentliche Flaschenhals ist.
Das sauberste wäre es wohl, einen lokalen MTA wie postfix zu installieren, darüber rspamd als milter zu integrieren und fetchmail die Mails über (s|l)mtp an Postfix zu leiten.

Fällt euch eventuell ein alternatives Vorgehen ein?

Falls jemand generelle Erfahrungen zu rspamd (natürlich auch im Server-Umfeld) teilen möchte, würde mich das sehr freuen.
Ich betreue noch ein etwas veraltetes Setup mit amavis/spamasassin und würde ggf. auf rspamd umsteigen wollen (da dann natürlich in einem "üblichen" Setup mit rspamd im "Proxy-Mode").

Kurzer Nachtrag zum System:
- Ubuntu 19.04
- rspamd 1.8.1
- fetchmail 6.3.26+GSS+NTLM+SDPS+SSL-SSLv3+NLS+KRB5
- dovecot 2.3.4.1

Lieben Dank!
mido
 
Zuletzt bearbeitet:
Manchmal hilft es, die Binaries und Libraries im RAM abzulegen (z.B. mittels RAM-Disk), wenn man einen Prozess ständig neu forken will. Der Flaschenhals beim Forken von Prozessen ist ja meist der Plattendurchsatz, der ggf. durch Swapping auch noch verlangsamt wird. Ansonsten schau dir mal das Speicherverhalten und sämtliche Datendurchsätze des Prozesses an, um zu sehen, warum ein fork() so lange dauert. strace und ltrace sind dabei deine Freunde um zu sehen an welchen Stellen der Prozess besonders lange hängt. Daraus lassen sich dann eher Rückschlüsse auf Optimierungsmaßnahmen treffen. Im Optimalfall hat man aber natürlich so ein Tool als Dämon dauerhaft laufen und spart sich die ganzen exec-Calls.
 
Ein spätes Danke, bitmuncher. :)
Leider endete dann irgendwann mein Urlaub und das alte Mailkonto wurde mit ~30% weniger Spam archiviert.
Die RAM-Disk hatte ich damals noch ausprobiert, brachte auch eine leicht bessere Performance.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben