Re: SPAM in spam group is processed into that exact same group

[Tassilo Horn <tassilo@member.fsf.org>]

Ted Zlatanov <tzz@lifelogs.com> writes:

Hi Ted,

>>> Try the attached patch, it just prefilters the groups list.
>
> TH> No, it doesn't seem to work correctly.  Now the message was copied
> TH> successfully to INBOX.training.ham but the copy to my INBOX (which
> TH> should have been a move anyway) failed.
>
> Can you trace `spam-copy-or-move-routine' as it walks through the
> articles and groups?  Also set `gnus-verbose' to 10 so you'll see the
> debug messages in `spam-copy-or-move-routine'.  Your settings may be a
> little unusual so I can't replicate the problem here.

Ok, here we go.  In "nnimap+Fastmail:INBOX.Junk Mail" I mark one spam
article as read, to indicate a false positive that should be
copied/moved to my INBOX.training.ham an INBOX.  Here's the output:

--8<---------------cut here---------------start------------->8---
20101103T172621.741> Exiting summary buffer and applying spam rules
20101103T172621.746> Registering 1 specific articles as ham using backend spam-use-move
20101103T172621.747> Copying article 11958 to group nnimap+Fastmail:INBOX.training.ham
20101103T172621.748> Copying to nnimap+Fastmail:INBOX.training.ham: (11958)...
20101103T172622.593> No more newsgroups
20101103T172622.595> Deleting article 11958
20101103T172622.945> Copying article 11958 to group nnimap+Fastmail:INBOX
20101103T172622.945> Copying to nnimap+Fastmail:INBOX: (11958)...
20101103T172622.951> *nnimap*<1> killed

20101103T172622.951> Couldn't Copy article 11958: *nnimap*<1> killed

20101103T172622.952> No more newsgroups
20101103T172622.952> Deleting article 11958
20101103T172623.153> 1 ham messages were registered by backend spam-use-move.
20101103T172623.155> Expiring articles...
20101103T172623.369> Expiring articles...done
20101103T172623.473> No more unread newsgroups
--8<---------------cut here---------------end--------------->8---

Looking at the code, it seems to me that the (setq deletep t) in the
copying part is wrong, isn't it?  I mean, if you want to put false
positives/negatives in N groups, you first copy N-1 times (without
deletion) and then move 1 time (which includes deletion), right?

--8<---------------cut here---------------start------------->8---
            ;; else, we are not respooling
            (if (or (not backend-supports-deletions)
                    (> (length groups) 1))
                (progn              ; if copying, copy and set deletep
                  (gnus-message 9 "Copying article %d to group %s"
                                article group)
                  (gnus-summary-copy-article nil group)
                  (setq deletep t))
              (gnus-message 9 "Moving article %d to group %s"
                            article group)
              (gnus-summary-move-article nil group))))) ; else move articles
--8<---------------cut here---------------end--------------->8---


> TH> BTW: I cannot figure out exactly how to mark a false positive in a spam
> TH> group as ham.  I always remove the spam mark (or all marks) using M-u,
> TH> but that alone doesn't make the article moved away on exit.  I somehow
> TH> need to reopen that group, read the message and exit summary again.  How
> TH> is it meant to be?
>
> You have to mark it with at least one ham-mark.  Those are defined as
> group/topic parameters in gnus.el with the default:
>
> '((".*" ((gnus-del-mark gnus-read-mark gnus-killed-mark gnus-kill-file-mark gnus-low-score-mark))))
>
> I should really add gnus-ticked-mark to that default list, btw.  Do you agree?

I agree.

But I still have a hard time marking false positives in "INBOX.Junk
Mail", because it seems new mail in that group is not automatically
marked as spam.  But I have

  (setq gnus-spam-newsgroup-contents
      '(("\\(spam\\|Junk\\)" gnus-group-spam-classification-spam)))

which says that new messages would be marked according the
classification on summary entry.  That seems to work fine for the group

  nnimap+Uni:Junk

but not for

  nnimap+Fastmail:INBOX.Junk Mail

although the regexp matches both.  In the latter, the articles are only
marked expirable.  Maybe that's a server side issue?

Bye,
Tassilo