[Dovecot] antispam plugin
First off, I have to say I really like the antispam plugin. I am
running a (relatively) new freebsd 8.0 server with
postfix/dovecot/dspam/squirrelmail and it works great. Create a SPAM
folder and tell the dovecot antispam plugin to use INBOX.SPAM as the
spam folder and drag messages from INBOX to the spam folder and they are
trained as spam. Here is the problem though: after training dspam for
a couple of weeks, I had a couple hundred messages in the SPAM folder,
so I selected them and hit the DELETE button and they were gone. Except
they weren't. I had forgotten that by default squirrelmail moves
deleted messages to a Trash folder under INBOX. So the messages were
moved out of the SPAM folder, resulting in them being retrained as ham.
Oops :( I then hit the purge link in squirrelmail and the messages were
forever gone, so I couldn't rectify my gaffe. I have temporarily
reconfigured squirrelmail to delete messages outright rather than save
them in the Trash folder, but I don't like that as a long-term
solution. What occurred to me is this: the current algorithm is: if
message moves from * => SPAM, it is trained as spam, if it moves from
SPAM => *, it is trained as ham. It would be nice if you could
elaborate on that such that the ham rule was "if message moves from SPAM
to X, it is ham" (and in my case, I would defined X as INBOX. Thoughts?
Dan Swartzendruber wrote:
First off, I have to say I really like the antispam plugin. I am running a (relatively) new freebsd 8.0 server with postfix/dovecot/dspam/squirrelmail and it works great. Create a SPAM folder and tell the dovecot antispam plugin to use INBOX.SPAM as the spam folder and drag messages from INBOX to the spam folder and they are trained as spam. Here is the problem though: after training dspam for a couple of weeks, I had a couple hundred messages in the SPAM folder, so I selected them and hit the DELETE button and they were gone. Except they weren't. I had forgotten that by default squirrelmail moves deleted messages to a Trash folder under INBOX. So the messages were moved out of the SPAM folder, resulting in them being retrained as ham. Oops :( I then hit the purge link in squirrelmail and the messages were forever gone, so I couldn't rectify my gaffe. I have temporarily reconfigured squirrelmail to delete messages outright rather than save them in the Trash folder, but I don't like that as a long-term solution. What occurred to me is this: the current algorithm is: if message moves from * => SPAM, it is trained as spam, if it moves from SPAM => *, it is trained as ham. It would be nice if you could elaborate on that such that the ham rule was "if message moves from SPAM to X, it is ham" (and in my case, I would defined X as INBOX. Thoughts?
There is also a plugin setting that defines your Trash folder, which is meant to fix the issue you're seeing (excluding junk->trash moving from retraining).
# semicolon-separated list of Trash folders (default unset i.e. none) # antispam_trash = # antispam_trash = trash;Trash;Deleted Items; Deleted Messages
-- Regards, Tom
I am using the antispam plugin and am very happy with it. I also have a default sieve rule that I found online somewhere that says if you see a message that is flagged as spam and not reclassified as innocent, to mark it as seen and move it to the INBOX.SPAM folder. That too works just fine. One annoyance is that spam I retrain by dragging to the spam folder is not being marked as seen (I think I understand why, based on the sieve rule.) My question: is it possible to configure the antispam plugin to do this for me? Or do I need a rule in sieve to detect that case and just set the seen flag? If the former, how? If the latter, I'm not quite sure I understand the sequence of events that takes place when a message is dragged from, say, inbox to spam folders. e.g. at what point is the antispam plugin invoked vs the sieve plugin? Thanks!
Forgive me if this is a stupid question. I know that when I drag a message to the SPAM folder, it is being trained properly, since the stats indicate so. Dragging back to the inbox retrains it as ham. I happened to notice that despite the fact that dspam says this in the debug log:
"appending header X-DSPAM-Reclassified: Spam"
nothing is actually being done to the message. Looking at the debug log for a newly delivered message, I can see it is calling dovecot's deliver agent. I am guessing here that this is just the way it works? e.g. the plugin detects a message being moved from inbox to inbox.spam and calls dspam with the requisite arguments to retrain the message, but the message isn't really being modified?
-------- Original-Nachricht --------
Datum: Tue, 23 Feb 2010 14:59:43 -0500 Von: Dan Swartzendruber <dswartz@druber.com> An: dovecot@dovecot.org Betreff: [Dovecot] dspam plugin and updating of headers?
Forgive me if this is a stupid question. I know that when I drag a message to the SPAM folder, it is being trained properly, since the stats indicate so. Dragging back to the inbox retrains it as ham. I happened to notice that despite the fact that dspam says this in the debug log:
"appending header X-DSPAM-Reclassified: Spam"
nothing is actually being done to the message. Looking at the debug log for a newly delivered message, I can see it is calling dovecot's deliver agent. I am guessing here that this is just the way it works? e.g. the plugin detects a message being moved from inbox to inbox.spam and calls dspam with the requisite arguments to retrain the message, but the message isn't really being modified?
Probably you are using reclassification based on the DSPAM signature. So nothing really happens with the original message. It does not get modified at all. Just the data that is related to the DSPAM signature will be used to increase/decrease SPAM/HAM counters. That's it.
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser
Dan Swartzendruber wrote:
I am using the antispam plugin and am very happy with it. I also have a default sieve rule that I found online somewhere that says if you see a message that is flagged as spam and not reclassified as innocent, to mark it as seen and move it to the INBOX.SPAM folder.
That too works just fine. One annoyance is that spam I retrain by dragging to the spam folder is not being marked as seen (I think I understand why, based on the sieve rule.) My question: is it possible to configure the antispam plugin to do this for me? Or do I need a rule in sieve to detect that case and just set the seen flag? If the former, how? If the latter, I'm not quite sure I understand the sequence of events that takes place when a message is dragged from, say, inbox to spam folders. e.g. at what point is the antispam plugin invoked vs the sieve plugin? Thanks!
I take it from the lack of response that no-one has any suggestions?
Dan Swartzendruber wrote:
Dan Swartzendruber wrote:
I am using the antispam plugin and am very happy with it. I also have a default sieve rule that I found online somewhere that says if you see a message that is flagged as spam and not reclassified as innocent, to mark it as seen and move it to the INBOX.SPAM folder. That too works just fine. One annoyance is that spam I retrain by dragging to the spam folder is not being marked as seen (I think I understand why, based on the sieve rule.) My question: is it possible to configure the antispam plugin to do this for me? Or do I need a rule in sieve to detect that case and just set the seen flag? If the former, how? If the latter, I'm not quite sure I understand the sequence of events that takes place when a message is dragged from, say, inbox to spam folders. e.g. at what point is the antispam plugin invoked vs the sieve plugin? Thanks!
I take it from the lack of response that no-one has any suggestions?
The antispam plugin is triggered when you manually move a message via the imap server interface. Sieve rules are triggered only when dovecot delivery agent puts a message in the maildir (or mbox). So they never cross paths: moving delivered messages around, with or without antispam plugin, never triggers sieve rules.
The way that you could implement this, would be by changing the source code of the antispam plugin. However, while your use case is valid, I think this behaviour would be very dependant on the end-user's preference...
-- Regards, Tom
Okay, thanks. I'll live with it the way it is.
participants (3)
-
Dan Swartzendruber
-
Steve
-
Tom Hendrikx