Bug 3919 - manual filtering does not move spam
Summary: manual filtering does not move spam
Status: RESOLVED FIXED
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: Filtering (show other bugs)
Version: 3.16.0
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2017-11-17 02:40 UTC by Pierre Fortin
Modified: 2018-01-20 08:40 UTC (History)
1 user (show)

See Also:


Attachments

Description Pierre Fortin 2017-11-17 02:40:08 UTC
Using this filtering rule:
enabled rulename "SPAM-tld" from regexpcase ".bid>" | from regexpcase ".date>" | from regexpcase ".download>" | from regexpcase ".email>" | from regexpcase ".stream>" | from regexpcase ".top>" | from regexpcase ".trade>" | from regexpcase ".tv>" color 7 mark_as_spam

incoming msgs are automatically processed as specified, including moving the msg to my SPAM folder as specified in 
  Configuration->Preferences->SpamAssassin->[x]Save spam in <folder>

[The use of regexpcase vs matchcase has no bearing on this bug.]

However, when I get a spam msg from a new TLD, I add that TLD to the list; then verify the rule via Tools->Filter selected messages.  The msg gets colored, sent to spamassassin via sa-learn; but does not get moved as specified -- not even if I add an explicit Move to the rule:
enabled rulename "SPAM-tld" from regexpcase ".bid>" | from regexpcase ".date>" | from regexpcase ".download>" | from regexpcase ".email>" | from regexpcase ".stream>" | from regexpcase ".top>" | from regexpcase ".trade>" | from regexpcase ".tv>" color 7 mark_as_spam move "#mh/Mailbox/inbox/SPAM"

[Coloring helps identify messages processed by this rule vs those handled directly by SpamAssassin.]
Comment 1 Shai Berger 2017-12-30 12:48:26 UTC
Hi,

I think my case is relevant to this bug: I don't have an anti-spam plug-in installed at all; I never expected mark_as_spam to move the message, so I just added a "move" action after it. Here's a piece of filtering log for a relevant message:

[13:38:41] processing rule 'Spam handling' [ header "X-Spambayes-Classification" matchcase "spam" mark_as_spam move "#mh/Mail/junk" stop ]
[13:38:41] checking if message matches [ header "X-Spambayes-Classification" matchcase "spam" ]
> message matches
[13:38:41] applying action [ mark_as_spam ]

As you can see, after "mark_as_spam", processing just stops, although the other actions are clearly there in the log.
Comment 2 Andrej Kacian 2018-01-05 21:16:48 UTC
I think I know what is going on. A while ago, the action "mark_as_spam" used to also move the marked message to a spam folder. That was changed in 2015, in this commit:
http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=8549b2a

The idea was for users to add an explicit move action if they wanted to have the messages moved.

However, I seem to have missed the fact that "mark_as_spam" is considered by Claws Mail as one of "final actions", after which any processing stops. See here:
http://git.claws-mail.org/?p=claws.git;a=blob;f=src/filtering.c#l774

It seems that solution would be to remove this action from there. Pierre or Shai, can you recompile with the line "case MATCHACTION_MARK_AS_SPAM:" removed and test if the processing continues past that action?
Comment 3 Pierre Fortin 2018-01-06 00:58:04 UTC
Compiled and running.  It now moves the msg on manual filtering; will have to wait for spam to check auto filtering.

If mark_as_spam no longer moves messages, then shouldn't the spamassassin option:
     "[X] Save spam in [_____________] [Browse]" 
be removed since an explicit "move" is required in Filtering?
Comment 4 Pierre Fortin 2018-01-06 01:13:59 UTC
Oops...  I missed something regarding the spamassassin option -- it's still needed for automatic spam filtering via the plug-in v. matcherrc filtering.
Comment 5 Andrej Kacian 2018-01-06 10:50:11 UTC
Indeed. The mark_as_spam action only tells the spamassassin plugin to "learn" the marked message as spam (train its database using the message contents).

On the other hand, during automatic scan on receiving, the plugin:
- scans the message and determines whether it is spam or not,
- uses it to train its database accordingly,
- moves the message if configured to do so.

The option you mention is roughly equivalent to you adding a "move" action after "mark_as_spam" in your manual TLD-based filtering rule. Then the procedure, in comparison to above is:
- the rule conditions determine whether the message is spam or not,
- the mark_as_spam action triggers the learning
- the move action triggers the move
Comment 6 Shai Berger 2018-01-06 13:25:55 UTC
Is the list of final operations documented anywhere? I wouldn't have added a "stop" after every "move" in my rules if I had known...
Comment 7 Shai Berger 2018-01-07 21:51:38 UTC
(In reply to comment #3)
> Compiled and running.  It now moves the msg on manual filtering; will have
> to wait for spam to check auto filtering.
> 

I confirm this too, and also confirm on automatic spam filtering.
Comment 8 users 2018-01-18 21:15:07 UTC
Changes related to this bug have been committed.
Please check latest Git and update the bug accordingly.
You can also get the patch from:
http://git.claws-mail.org/

++ ChangeLog	2018-01-18 21:15:06.695097503 +0100
http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=6328a6be5e87b3ff6a974714b0e4ba881202002a
Merge: b18c96c 4302636
Author: Colin Leroy <colin@colino.net>
Date:   Thu Jan 18 21:15:05 2018 +0100

    Merge branch 'master' of file:///home/git/claws

http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=4302636fb7a93c42287ffc9c37862bd21e29dc2c
Author: Andrej Kacian <ticho@claws-mail.org>
Date:   Thu Jan 18 21:13:46 2018 +0100

    Do not consider "mark_as_spam" as a final action, since it does not move the marked message.
    
    Fixes Bug 3919 - manual filtering does not move spam

Note You need to log in before you can comment on or make changes to this bug.