Zarafa spamtrain und UCS

Hallo zusammen,

auch wenn der Thread schon etwas länger liegt, kann ich hier meinen Senf dazu geben. Ich habe ebenfalls nach Lösungen gesucht, wie das Trainieren des Bayes Filter in UCS etwas komfortabler gestaltet werden kann, wenn Zarafa benutzt wird.
Dabei bin ich über diesen Thread gestolpert und demzufolge das spamtrain WebApp - Plugin. Dieses konnte ich so zum laufen bekommen:

Normalerweise wird spamassassin im UCS täglich über einen cron - job trainiert, hier der entsprechende Auszug aus dem Script, welches letztlich per cron.daily aufgerufen wird:

[code]find /var/spool/cyrus/mail/domain/ ( -wholename */*/*/user/*/Spam )
-exec $SA_LEARN --dbpath /var/lib/amavis/.spamassassin --spam {} ;

find /var/spool/cyrus/mail/domain/ -wholename */*/*/user/*/Ham
-exec $SA_LEARN --dbpath /var/lib/amavis/.spamassassin --ham {} ;
[/code]
Wie zu sehen, werden dabei u.a. alle Mails in allen “Spam” Ordnern der Benutzer mittels /usr/bin/sa-learn verarbeitet. Da spamassassin bei Univention als amavis - “Plugin” läuft, wird per --dbpath Parameter die entspr. Bayes - DB angegeben.
Das Ganze funktioniert aber nicht, wenn Zarafa benutzt wird, denn in dem Fall liegen die Mails ja in der MySQL DB von Zarafa und nicht als mbox - Dateien irgendwo unterhalb von /var/spool.

Damit nun das spamtrain Plugin für die Zarafa Webapp richtig funktioniert, muß nach dessen Installation folgendes angepaßt werden:

1.) Der Aufruf in der config.php des Plugins muss so abgeändert werden:
Von:

/** Spam Filter train commands (choose the one suitable for your setup) */ // DSPAM with shared spam database define('PLUGIN_SPAMTRAIN_TRAIN_SPAM_CMD', '/usr/bin/dspam --user dspam --source=error --class=spam'); define('PLUGIN_SPAMTRAIN_TRAIN_HAM_CMD', '/usr/bin/dspam --user dspam --source=error --class=innocent'); // DSPAM with per user spam database //define('PLUGIN_SPAMTRAIN_TRAIN_SPAM_CMD', '/usr/bin/dspam --user %u --source=error --class=spam'); //define('PLUGIN_SPAMTRAIN_TRAIN_HAM_CMD', '/usr/bin/dspam --user %u --source=error --class=innocent'); // SpamAssassin with per user database //define('PLUGIN_SPAMTRAIN_TRAIN_SPAM_CMD', '/usr/bin/sa-learn --spam --username %u'); //define('PLUGIN_SPAMTRAIN_TRAIN_HAM_CMD', '/usr/bin/sa-learn --ham --username %u');

Nach:

/** Spam Filter train commands (choose the one suitable for your setup) */ // DSPAM with shared spam database //define('PLUGIN_SPAMTRAIN_TRAIN_SPAM_CMD', '/usr/bin/dspam --user dspam --source=error --class=spam'); //define('PLUGIN_SPAMTRAIN_TRAIN_HAM_CMD', '/usr/bin/dspam --user dspam --source=error --class=innocent'); // DSPAM with per user spam database //define('PLUGIN_SPAMTRAIN_TRAIN_SPAM_CMD', '/usr/bin/dspam --user %u --source=error --class=spam'); //define('PLUGIN_SPAMTRAIN_TRAIN_HAM_CMD', '/usr/bin/dspam --user %u --source=error --class=innocent'); // SpamAssassin with per user database define('PLUGIN_SPAMTRAIN_TRAIN_SPAM_CMD', 'sudo /usr/bin/sa-learn --spam --dbpath /var/lib/amavis/.spamassassin'); define('PLUGIN_SPAMTRAIN_TRAIN_HAM_CMD', 'sudo /usr/bin/sa-learn --ham --dbpath /var/lig/amavis/.spamassassin');
Es müssen also zum Einen die sa-learn Kommandos “Einkommentiert” und die “dspam” - Kommandos “auskommentiert” werden. Des weiteren muß statt des “–username” - Parameters der “–dbpath” Parameter (s. Univention Cron - Script) benutzt werden.

2.)
Da das Verzeichnis “/var/lib/amavis/.spamassassin” nur vom Benutzer “amavis” beschrieben werden darf, das sa-learn Kommando aber als “www-data” abgesetzt wird (es kommt ja letztlich vom Webserver, der als www-data läuft), habe ich hier “sudo” verwendet, damit das sa-learn Kommando mit root - Rechten aufgerufen wird, und so in das Verzeichnis “/var/lib/amavis/.spamassassin” schreiben kann.
Damit das klappt, muß das dem www-data “erlaubt” werden. Dazu in “/etc/sudoers.d/” eine neue Datei anlegen (bspw. “www-data”):

cmnd_Alias SALEARN = /usr/bin/sa-learn %www-data ALL=(ALL) NOPASSWD: SALEARN
Damit darf fortan der Benutzer “www-data” den Befehl “/usr/bin/sa-learn” per “sudo” mit root-Rechten ausführen, ohne nach seinem Passwort gefragt zu werden.

Wenn man dann in der WebApp eine Mail per Kontext-Menü als “Spam” kennzeichnet, wird das konfiguierte sa-learn Kommando aufgerufen und - wenn dieses mit RC 0 zurück kommt - die Mail anschließend gelöscht.
Sollte ein Fehlerfenster erscheinen (das evtl. sogar keinen Text enthält), kann man mit Aktivieren des Loggings in der config.php:

/** Logging */ define('PLUGIN_SPAMTRAIN_LOGGING_ENABLED', true); define('PLUGIN_SPAMTRAIN_LOGGING_FILE', '/tmp/spamtrain.log');

auf Fehlersuche gehen.

Vllt. hilft das ja hier dem Ein oder Anderen weiter…

Viele Grüße
T0mcat

Und weiter gehts…

Habe mir das hier:

mal angesehen und auch das funktioniert offensichtlich gut.
Hier muß lediglich in der “zarafa-spamhandler.cfg” das spamcommand geändert werden:

[spamcommand] command = /usr/bin/sa-learn --spam --dbpath /var/lib/amavis/.spamassassin/
(Dies wurde vorher per “sudo -u amavis” als amavis ausgeführt. Wenn geplant ist, das script als “root” auszuführen, ist das mMn. nicht nötig)

Wenn man nun zarafa-spamhandler.sh ausführbar macht und ausführt, funktioniert das Ganze auch gut und kann somit als Cron-Job eingerichtet werden.

I’m trying to “install” the spamtrain plugin. I’m having trouble to find out which folder to place it in. I would expect the webapp folder to be in /var/www, but it isn’t. Can anyone tell me?

NB: with “find . -name “webapp” -type d”, I find only /etc/zarafa/webapp. It has a htaccess file, but I am not used to find webcontent in /etc

Hello sakgRtd2w,

the webapp itself is located in /usr/share/zarafa-webapp. The plugins are installed in subfolders of the folder “plugins”.

Thanks! Running “/usr/bin/sa-learn --spam --dbpath /var/lib/amavis/.spamassassin/” takes a long time as it seems. I wonder how I can check whether it works well?

Hallo Zusammen,

leider muss ich diesen Thread noch mal hoch holen.

Inwieweit funktioniert das Spam und Ham handling nun in Kopano.
Können die hier angegebenen Scripte/Plugins auch in Kopano genutzt werden, da dieses ja eigentlich für Zarafa gemacht sind.
Da unser SMB Server nun einwandfrei mit den Testaccounts werkelt aber in der Spam Sache noch nichts unternommen wurde und auch dieser auch nicht auf den bekannten Teststring reagiert, möchte ich dieses ändern.
Wäre auch toll wen man dem Server auch fälschlich erkannte Spam Mails wieder abgewöhnen könnte.

Freue mich auf Anregungen, damit ich meine Tutorial vervollständigen kann.

Viele Grüße Holger

Entschuldigt dass ich nun nach rund 21 Tagen den Beitrag pusche…Keiner eine Idee, ein Howto wie man dem Kopano spam und ham beibringt?
Danke Holger

Hallo Holger,

grundsätzlich funktionieren hier unter Kopano die selben Skripte, wie auch unter Zarafa. Einen Möglichen Ansatz haben wir mal unter https://kb.kopano.io/display/WIKI/Kopano-spamd beschrieben.

@fbartels

den Beitrag habe ich schon studiert, der funktioniert aber soweit ich es verstehe nur für Spam aber nicht für Ham also unlearn…
Zum andere, wenn ich einen Teststring um die Spamerkennung zu testen an die UCS sende wird dieser nicht erkannt…
sprich diesesn:
XJSC4JDBQADN1.NSBN32IDNENGTUBE-STANDARD-ANTI-UBE-TEST-EMAILC.34X

Danke Holger

ja, das stimmt das verlinkte Beispiel macht nur Spam und keinen Ham.

Bezüglich des Teststrings kann ich leider nichts sagen, wir nutzen hier nur den Standardstack von Univention ohne darüber hinaus gehende Konfiguration.

Danke @fbartels

Wird dass Skript noch um Ham erweitert?
Mit dem Tesstring wollte ich nur aufzeigen, dass wohl in der Univention konfiguration mit Kopano zusammen keine Spamerkennung stattfindet.

zumindest gibt es dazu derzeit von unserer Seite aus keine Pläne. Pull Requests sind aber willkommen.

Danke noch mals Herr Bartels @fbartels

Eine Erkenntnis habe ich noch und ich denke in dem Fall hat es was mit zarafa/Kopano zu tun.
Ich habe auf dem System einen Account zum Testen und dort läuft die Mail mit diesem Auffälligen Teststring der dann die Mail als Spam vorgaukelt richtig ab und liefert diese in den Spamordner von Kopano.
Kann es sein, dass bei der Migration mit dem zarafa Migration Tool irgendwas schief gelaufen ist.
Falls ja, was könnte ich/wir da tun.

Danke Noch mal Holger

hm… kann ich mir nicht direkt vorstellen. Das Migrationstool sollte eigentlich bestehende Ordner erkennen und diese nicht überschreiben. Kommt denn bei der Zustellung eventuell ein Fehler im dagent.log?

nein…der dagent.log sagt nichts dazu…

Mon Apr 3 06:43:35 2017: [warning] [27382] renovate_encoding: unknown charset “cp-850”, skipping
Mon Apr 3 06:43:35 2017: [error ] [27382] HTML part not readable in any charset. Storing as attachment instead.
Mon Apr 3 17:18:47 2017: [warning] [ 3540] renovate_encoding: unknown charset “cp-850”, skipping
Mon Apr 3 17:18:47 2017: [error ] [ 3540] HTML part not readable in any charset. Storing as attachment instead.
Tue Apr 4 09:26:18 2017: [error ] [17556] Client disconnected
Tue Apr 4 09:26:18 2017: [error ] [17560] Client disconnected
Tue Apr 4 14:19:49 2017: [warning] [22406] renovate_encoding: reading data using charset “us-ascii” produced partial results: Invalid or incomplete multibyte or wide character
Wed Apr 5 14:47:11 2017: [ notice] [ 3370] LMTP service will now exit
Wed Apr 5 15:09:14 2017: [ notice] [ 3387] Starting kopano-dagent LMTP mode version 8,1,1,10 (10), pid 3387
Wed Apr 5 15:25:55 2017: [ notice] [ 3387] LMTP service will now exit
Wed Apr 5 15:25:55 2017: [ notice] [ 9095] Starting kopano-dagent LMTP mode version 8,1,1,10 (10), pid 9095
Wed Apr 5 15:29:10 2017: [ notice] [ 9095] LMTP service will now exit
Wed Apr 5 15:31:09 2017: [ notice] [ 3385] Starting kopano-dagent LMTP mode version 8,1,1,10 (10), pid 3385
Thu Apr 6 06:38:38 2017: [ notice] [ 3385] LMTP service will now exit
Thu Apr 6 07:13:04 2017: [ notice] [ 3367] Starting kopano-dagent LMTP mode version 8,1,1,10 (10), pid 3367
Thu Apr 6 08:03:45 2017: [ notice] [ 3367] LMTP service will now exit
Thu Apr 6 08:03:45 2017: [ notice] [25521] Starting kopano-dagent LMTP mode version 8,2,1,530 (530), pid 25521
Thu Apr 6 08:10:59 2017: [ notice] [25521] LMTP service will now exit
Thu Apr 6 08:12:22 2017: [ notice] [ 732] Starting kopano-dagent LMTP mode version 8,2,1,530 (530), pid 732

Mehr steht da nicht…echt merkwürdig…

Muss da ggf. der Loglevel hoch gesetzt werden…wenn ja, wo und/oder wie…(hab im Forum diesbezüglich nichts gefunden, nur dass Kollegen diesen mal auf 5 gesetzt hatten):

Update auf 4.2 gemacht?

Ich würde raten das Loglevel einmal zu erhöhen und dann eine Mail mit dem Teststring zuzustellen.

Ja, Update heute Morgen…hat aber nichts geändert…
Hab jetzt in /etc/kopano/dagent.cfg den Loglevel auf 5 und dann auf 6 gesetz und mit /etc/init.d/kopano-server restart kopano neu gestartet…im Logfile steht das gleiche wie vorher…

/etc/kopano/dagent.cfg den Loglevel auf 5 und dann auf 6 gesetz und mit /etc/init.d/kopano-server restart

in diesem Falle sollte auch kopano-dagent neugestartet werden (ein reload würde aber auch reichen). Für Änderungen die dauerhaft erfolgen sollen bietet es sich bei Univention eher an den Wert über die UCR zu verändern. Über die Konsole wäre das ein:

ucr set kopano/cfg/dagent/log_level=6

Danke Herr Bartels @fbartels nun hat es geklapt mit dem Log…können Sie daran was erkennen?

Email an mit zarafa migration Tool importierten Account:
Thu Apr  6 19:15:46 2017: [info   ] [17841] Accepted connection from [::ffff:127.0.0.1]:56768
Thu Apr  6 19:15:46 2017: [info   ] [18254] Starting worker for LMTP request pid 18254
Thu Apr  6 19:15:46 2017: [debug  ] [18254] PYTHONPATH = /usr/share/kopano-dagent/python
Thu Apr  6 19:15:47 2017: [debug  ] [18254] < 220 2.1.5 LMTP server is ready
Thu Apr  6 19:15:47 2017: [debug  ] [18254] > LHLO ucs.domain.intranet
Thu Apr  6 19:15:47 2017: [debug  ] [18254] LHLO ID: ucs.domain.intranet
Thu Apr  6 19:15:47 2017: [debug  ] [18254] < 250-SERVER ready
Thu Apr  6 19:15:47 2017: [debug  ] [18254] < 250-PIPELINING
Thu Apr  6 19:15:47 2017: [debug  ] [18254] < 250-ENHANCEDSTATUSCODE
Thu Apr  6 19:15:47 2017: [debug  ] [18254] < 250 RSET
Thu Apr  6 19:15:47 2017: [debug  ] [18254] > MAIL FROM:<testmailer2345@googlemail.com>
Thu Apr  6 19:15:47 2017: [debug  ] [18254] < 250 2.1.0 Ok
Thu Apr  6 19:15:47 2017: [debug  ] [18254] > RCPT TO:<mail@user-domain.de>
Thu Apr  6 19:15:47 2017: [debug  ] [18254] Resolved command "RCPT TO:<mail@user-domain.de>" to recipient address "mail@user-domain.de"
Thu Apr  6 19:15:47 2017: [notice ] [18254] Resolved recipient mail@user-domain.de as user userdomain
Thu Apr  6 19:15:47 2017: [debug  ] [18254] < 250 2.1.5 Ok
Thu Apr  6 19:15:47 2017: [debug  ] [18254] > DATA
Thu Apr  6 19:15:47 2017: [debug  ] [18254] < 354 2.1.5 Start mail input; end with <CRLF>.<CRLF>
Thu Apr  6 19:15:47 2017: [info   ] [18254] * Loading plugins started
Thu Apr  6 19:15:47 2017: [info   ] [18254] ** Checking plugins in /var/lib/kopano/dagent/plugins
Thu Apr  6 19:15:47 2017: [info   ] [18254] * Loading plugins done
Thu Apr  6 19:15:47 2017: [info   ] [18254] Mail will be delivered in Inbox
Thu Apr  6 19:15:47 2017: [debug  ] [18254] Trying to parse alternative multipart 1 of mail body
Thu Apr  6 19:15:47 2017: [debug  ] [18254] HTML document contains no HEAD tag
Thu Apr  6 19:15:47 2017: [debug  ] [18254] Charset is "UTF-8" (case #8).
Thu Apr  6 19:15:47 2017: [debug  ] [18254] renovate_encoding: reading data using charset "UTF-8" succeeded.
Thu Apr  6 19:15:47 2017: [info   ] [18254] * PostConverting processing started
Thu Apr  6 19:15:47 2017: [info   ] [18254] * PostConverting processing done
Thu Apr  6 19:15:47 2017: [info   ] [18254] * PreDelivery processing started
Thu Apr  6 19:15:47 2017: [info   ] [18254] * PreDelivery processing done
Thu Apr  6 19:15:47 2017: [info   ] [18254] * PreRuleProcess processing started
Thu Apr  6 19:15:47 2017: [info   ] [18254] * PreRuleProcess processing done
Thu Apr  6 19:15:47 2017: [debug  ] [18254] Processing rule Bahn Tickets for userdomain
Thu Apr  6 19:15:47 2017: [info   ] [18254] Rule Bahn Tickets doesn't match: 0x8004010f
Thu Apr  6 19:15:47 2017: [debug  ] [18254] Processing rule Tipp24 Quittungen for userdomain
Thu Apr  6 19:15:47 2017: [info   ] [18254] Rule Tipp24 Quittungen doesn't match: 0x8004010f
Thu Apr  6 19:15:47 2017: [debug  ] [18254] Target user has OOF inactive

Thu Apr  6 19:15:47 2017: [info   ] [18254] * PostDelivery processing started
Thu Apr  6 19:15:47 2017: [info   ] [18254] * PostDelivery processing done
Thu Apr  6 19:15:47 2017: [info   ] [18254] * SendNewMailNotify processing started
Thu Apr  6 19:15:47 2017: [info   ] [18254] * SendNewMailNotify processing done
Thu Apr  6 19:15:47 2017: [debug  ] [18254] Send 'New Mail' notification
Thu Apr  6 19:15:47 2017: [info   ] [18254] Delivered message to 'userdomain', Subject: "dagent test", Message-Id: <CAGran6nr5NTCQisEvQKT0sKBBf1Px_8bvzVk57pwWvxPT-mNjQ@mail.gmail.com>, size 4581
Thu Apr  6 19:15:47 2017: [info   ] [18254] Finished processing message
Thu Apr  6 19:15:47 2017: [debug  ] [18254] < 250 2.1.5 mail@user-domain.de Ok
Thu Apr  6 19:15:47 2017: [debug  ] [10499] > QUIT
Thu Apr  6 19:15:47 2017: [debug  ] [10499] < 221 2.0.0 Bye
Thu Apr  6 19:15:47 2017: [info   ] [10499] LMTP thread exiting


Testmail an neu angelegten User ohne Import von Daten:

Thu Apr  6 19:39:22 2017: [info   ] [18655] Accepted connection from [::ffff:127.0.0.1]:33186
Thu Apr  6 19:39:22 2017: [info   ] [18763] Starting worker for LMTP request pid 18763
Thu Apr  6 19:39:22 2017: [debug  ] [18763] PYTHONPATH = /usr/share/kopano-dagent/python
Thu Apr  6 19:39:22 2017: [debug  ] [18763] < 220 2.1.5 LMTP server is ready
Thu Apr  6 19:39:22 2017: [debug  ] [18763] > LHLO ucs.domain.intranet
Thu Apr  6 19:39:22 2017: [debug  ] [18763] LHLO ID: ucs.domain.intranet
Thu Apr  6 19:39:22 2017: [debug  ] [18763] < 250-SERVER ready
Thu Apr  6 19:39:22 2017: [debug  ] [18763] < 250-PIPELINING
Thu Apr  6 19:39:22 2017: [debug  ] [18763] < 250-ENHANCEDSTATUSCODE
Thu Apr  6 19:39:22 2017: [debug  ] [18763] < 250 RSET
Thu Apr  6 19:39:22 2017: [debug  ] [18763] > MAIL FROM:<testmailer2345@googlemail.com>
Thu Apr  6 19:39:22 2017: [debug  ] [18763] < 250 2.1.0 Ok
Thu Apr  6 19:39:22 2017: [debug  ] [18763] > RCPT TO:<ludwigtest@domain.intranet>
Thu Apr  6 19:39:22 2017: [debug  ] [18763] Resolved command "RCPT TO:<ludwigtest@domain.intranet>" to recipient address "ludwigtest@domain.intranet"
Thu Apr  6 19:39:22 2017: [notice ] [18763] Resolved recipient ludwigtest@domain.intranet as user ludwigtest
Thu Apr  6 19:39:22 2017: [debug  ] [18763] < 250 2.1.5 Ok
Thu Apr  6 19:39:22 2017: [debug  ] [18763] > DATA
                                                                  43,1          62%

Ist auch merkwürdig, dass bei dem Account in dem funktioniert viel weniger Logdaten sind (bis auf die Filter, was klar ist),
Mit freundlichen Grüßen Holger

hört die zweite Zustellung wirklich bei

Thu Apr 6 19:39:22 2017: [debug ] [18763] > DATA

auf?

Bis zu diesem Zeitpunkt sind die Logausgaben (bis auf Zeitstempel und Adressen) identisch.

Mastodon