spam splitting : "already done".

spam splitting : "already done".

[Richard Riley]

There might be a setting to cover this - I can't spot it. It's like snow
blindness except more emacsy...

When I enter an email group and its marked for spam-split processing
then the selected spam functions are called for all unread articles.

I dont always then read all emails. If I leave that group and come back
later then they are checked again.

spam-split takes an age calling spamassassin for example.

Is there some way to have unread articles marked as being already
processed for spam and thus skipped by spam-split the next time I enter
that group?

Re: spam splitting : "already done".

[Lars Ingebrigtsen]

Richard Riley <rileyrg@googlemail.com> writes:

> Is there some way to have unread articles marked as being already
> processed for spam and thus skipped by spam-split the next time I enter
> that group?

See `spam-mark-only-unseen-as-spam'.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: spam splitting : "already done".

[Richard Riley]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Richard Riley <rileyrg@googlemail.com> writes:
>
>> Is there some way to have unread articles marked as being already
>> processed for spam and thus skipped by spam-split the next time I enter
>> that group?
>
> See `spam-mark-only-unseen-as-spam'.


I already have this set to t and the spam functions are still rerun on
unread messages when I reenter the same group. With one message in my
INBOX the calls to spamassassin check is about 5 seconds per message.

the doc string for spam-mark-only-unsees-as-spam says

,----
| Documentation:
| Whether only unseen articles should be marked as spam in spam groups.
| When nil, all unread articles in a spam group are marked as
| spam.  Set this if you want to leave an article unread in a spam group
| without losing it to the automatic spam-marking process.
`----

Should that say "when nil all unread articles are checked for
spam". There may or may not be marking involved.

Re: spam splitting : "already done".

[Lars Ingebrigtsen]

Richard Riley <rileyrg@googlemail.com> writes:

> Should that say "when nil all unread articles are checked for
> spam". There may or may not be marking involved.

I see.  Perhaps the spam checking should be running on only the unseen
articles?  Ted?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: spam splitting : "already done".

[Ted Zlatanov]

On Thu, 27 Jan 2011 17:48:42 -0800 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Richard Riley <rileyrg@googlemail.com> writes:
>> Should that say "when nil all unread articles are checked for
>> spam". There may or may not be marking involved.

LI> I see.  Perhaps the spam checking should be running on only the unseen
LI> articles?  Ted?

The spam processors are run on whatever is spam-marked.

spam-marks are applied when you enter the group according to the basic
rules, using `spam-mark-new-messages-in-spam-group-as-spam'[1] and
`spam-mark-only-unseen-as-spam'.  It also matters if the group is a spam
group and if you've customized the group or topic.

The goal is to mark only articles you haven't seen before as spam.  It
sounds like the problem is that you're getting seen but unread articles
marked as spam (and you have spam-mark-only-unseen-as-spam set to t).
The logic is (IMO) very simple, see below.  Can you please add

(debug 1 spam-mark-new-messages-in-spam-group-as-spam 
       2 spam-mark-only-unseen-as-spam
       3 (spam-group-spam-contents-p gnus-newsgroup-name)
       4 gnus-newsgroup-name)

right before the (when...) below, hit `M-C-e' to evaluate, then tell us
what you get in the debug trace?  Hit `q' to abort it or `c' to
continue, then just remove the debug line and use `M-C-e' again to get
back the original behavior.

The reason for this is to make sure that your variables and parameters
are set to what you think.  Can you also confirm my understanding of
your problem is correct, and that you're not getting the results we're
expecting?

Thanks and sorry for the lengthy explanation...
Ted

[1] contender for "longest variable name with a purpose" :)

(defun spam-mark-junk-as-spam-routine ()
  ;; check the global list of group names spam-junk-mailgroups and the
  ;; group parameters
  (when (spam-group-spam-contents-p gnus-newsgroup-name)
    (gnus-message 6 "Marking %s articles as spam"
                  (if spam-mark-only-unseen-as-spam
                      "unseen"
                    "unread"))
    (let ((articles (if spam-mark-only-unseen-as-spam
                        gnus-newsgroup-unseen
                      gnus-newsgroup-unreads)))
      (if spam-mark-new-messages-in-spam-group-as-spam
          (dolist (article articles)
            (gnus-summary-mark-article article gnus-spam-mark))
        (gnus-message 9 "Did not mark new messages as spam.")))))

Re: spam splitting : "already done".

[Richard Riley]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 27 Jan 2011 17:48:42 -0800 Lars Ingebrigtsen <larsi@gnus.org> wrote: 
>
> LI> Richard Riley <rileyrg@googlemail.com> writes:
>>> Should that say "when nil all unread articles are checked for
>>> spam". There may or may not be marking involved.
>
> LI> I see.  Perhaps the spam checking should be running on only the unseen
> LI> articles?  Ted?
>
> The spam processors are run on whatever is spam-marked.
>
> spam-marks are applied when you enter the group according to the basic
> rules, using `spam-mark-new-messages-in-spam-group-as-spam'[1] and
> `spam-mark-only-unseen-as-spam'.  It also matters if the group is a spam
> group and if you've customized the group or topic.
>
> The goal is to mark only articles you haven't seen before as spam.  It
> sounds like the problem is that you're getting seen but unread articles
> marked as spam (and you have spam-mark-only-unseen-as-spam set to t).

No. Not marked as spam. *checked* for spam each time. They are not
spam. They remain unread (in this use case example). But each time I
enter the group they are rechecked.

"mark", to me, suggests the records/emails are marked. They are not.


I'll try out the debug suggestions as soon as I am off this dinky netbook
. Thanks a lot.

I be it comes down to some legacy group edit ;