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
--
Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
