Re: test im script
Bjoern Schmidt wrote:
Markus Schulz wrote:
Allerdings benutze ich Shared IMAP Folder (SPAM/HAM/Missed Spam) die
mittels Cyradm so eingestellt wurden, das nur EMails dort
reingeschoben werden dürfen.(lesen nicht erlaubt)
Dann weisst Du aber nicht (ohne weiteres) wem die Mails gehören,
z.B. um sie zurück zu liefern oder für Benutzerspezifische BayesDB.
Die Mails werden bei mir auch nicht zurückgeliefert.
Die Folder sind ausschliesslich zum explizieten Trainieren gedacht.
Sprich ein Nutzer kann dort Mails ablegen um das Training von
Spamassassin weiterzuführen.
Der Nutzer muss dies daher aber auch selbst erledigen.
Wer sonst? Nur der Nutzer selber kann klassifizieren ob ham
oder spam. Oder was meintest Du damit?
Diese Folder dumpe ich dann mittels cyrdump via Cron,
Das würde ich in der cyrus.conf eintragen, nicht in der crontab.
Dann bist Du nämlich schon cyrus.
Das wollte ich mir auch noch einmal anschauen. Das Problem ist dabei,
das Spamassasin von Amavis aufgerufen wird und daher die Dateien auch
Amavis gehören. Wird aber bestimmt zu Lösen sein.
konvertiere noch ein wenig (damit ein korrekte mbox Format rauskommt)
und lerne das File dann mit sa-learn.
Anschliessend leere ich die 3 Folder mittels einem kleinem Perl Script
(Net::IMAP Modul).
Bekommen Deine User den Ham nicht zurück???
Nein, sie haben ja die Mails nur zum Trainieren in den
HAM/SPAM/MissedSpam Folder als Kopie (oder verschoben falls Original
nicht mehr gebraucht wird) abgelegt.
Wäre das cyrdump nicht auch etwas für deinen Anwendungsfall? Damit
könntest du dir das Bewegen der Dateien sparen. Allerdings brauchst du
Nein. Das Speicherformat der Mails ist genau das was sa-learn
verarbeiten kann, so wie es ist. Warum konvertieren? Im Prinzip bewegst
Du die Dateien ja auch, nur anders.
Cyrdump schreibt den Folder als eine Datei raus, diese ist noch kein
korrekte MBox Format (enthält z.B. einige xml tags). Daher muss die
Datei noch ein wenig modifiziert werden.
Meine Mailboxen sehen alle mindestens so aus:
INBOX.Trash
INBOX.Spam
INBOX.Ham
INBOX.Ham.learned
Mein aktuellstes Skript funktionert so:
1. verschiebe (mv) sofort von INBOX.Ham nach INBOX.Ham.learned
2. sa-learn von INBOX.Ham.learned und INBOX.Spam
3. verschiebe von INBOX.Spam nach INBOX.Trash
4. reconstruct -r von INBOX.Trash und INBOX.Ham
Ich glaube effizienter gehts nimmer.
Ein riesiges Problem ist noch ungelöst: Beim verschieben können
Mails in Trash und learned überschrieben werden!
Wenn ich dein Konzept richtig verstehe, verschieben deine Nutzer die
Mails z.B. mit clientseitigen Filtern in die Folder Ham und Spam, dort
entnimmst du sie und gibst sie Spamassassin zum Lernen. Der Nutzer
findet seine Ham Mails dann im Learned Folder wieder?
Was ich nicht ganz verstehe ist, wenn deine Nutzer die Ham und Spam
Mails expliziet in die entsprechenden Ordner legen müssen, warum können
sie nicht auch eine Kopie extra für das Training dort ablegen?
Es wird doch kaum ein Nutzer alle seine Mails in dem Ham Order verwalten
wollen?
Kann man Nutzerspezifisches Spamtraining mit amavisd-new implementieren?
Ich habe bisher nur Nutzerspezifische Spameinstellungen (eigene
web-cyradm Erweiterung implementiert) wo jeder Nutzer für seinen Account
eigene SpamLevel usw. für die SQL Lookups von Amavis einrichten kann.
MfG
Markus Schulz
Reply to: