spam.el: copy/move of ham articles from unclassified groups

spam.el: copy/move of ham articles from unclassified groups

[Tim Howe]

I'm running Gnus v5.10.7 and using spam-stat.el via spam.el for spam
filtering.

My setup is as follows:

  Mail is split according to senders, then if none matches the spam
  splitter is used.  nnml:raw.spammy is my spam split destination; all
  the rest goes to nnml:raw.  These 2 groups are unclassified (neither
  spam nor ham).
  
  I have a single group classified as spam: nnml:spam.explicit.  This is
  my spam process destination.

  All other groups are classified as ham.

Currently my workflow is as follows: enter the /nnml:raw\(\..*\)?/
groups, move all the ham articles into nnml:misc to be read or manually
split later, then mark all the rest of the articles as spam and exit the
group, causing them to be processed and moved to nnml:spam.explicit.

Now (correct me if I'm wrong) I could have /nnml:raw\(\..*\)?/
classified as spam groups for the same basic effect.  However I don't
like that I lose all the score highlighting when they are auto-marked as
spam, and I'm nervous about the default mark being "spam".  Please tell
me if this is a legitimate concern.

I'm thinking what I will do is implement an interactive function which
overrides the ! key in the raw groups.  It will remove all marks and
move the article into nnml:misc.

Is there a reason that gnus-ham-process-destinations only works for spam
groups and not in non-ham groups?  If the registry is used that should
avoid double-processing concerns, no?

-- 
vsync
http://quadium.net/~vsync/

The beauty of Amendment II is that it protects the ability to deal
with both a tyrannical government and a zombie apocalypse.
        -- Eochada,
           http://forums.fark.com/cgi/fark/comments.pl?IDLink=2749371

Re: spam.el: copy/move of ham articles from unclassified groups

[Tim Howe]

Tim Howe <vsync@quadium.net> writes:

> I'm thinking what I will do is implement an interactive function which
> overrides the ! key in the raw groups.  It will remove all marks and
> move the article into nnml:misc.

For the record here is what I came up with:

(defun gnus-summary-unread-and-hammify-article ()
  (interactive)
  (gnus-summary-clear-mark-forward 1)
  (gnus-summary-move-article nil "nnml:misc"))

(defun gnus-summary-process-mark-all-extant ()
  (interactive)
  (save-excursion
    (let ((beg (point-min))
	  (end (point-max)))
      (goto-char beg)
      (while (< (point) end)
	(let ((article-number (gnus-summary-article-number)))
	  (unless (char= (gnus-summary-article-mark article-number) ?G)
	    (gnus-summary-set-process-mark article-number)))
	(forward-line 1))))
  (gnus-summary-position-point))

(defun gnus-summary-maybe-unread-and-hammify-article ()
  (interactive)
  (if (string-match "^nnml:raw\\(\\..*\\)?" gnus-newsgroup-name)
      (gnus-summary-unread-and-hammify-article)
      (gnus-summary-tick-article)))

(defun gnus-summary-mark-all-as-spam-and-exit ()
  (interactive)
  (when (gnus-y-or-n-p "Mark everything as spam? ")
    (gnus-uu-unmark-buffer)
    (gnus-summary-process-mark-all-extant)
    (dolist (article (gnus-summary-work-articles nil))
      (gnus-summary-goto-subject article)
      (gnus-summary-mark-as-spam 1))
    (gnus-uu-unmark-buffer)
    (gnus-summary-exit)))

(define-key gnus-summary-mode-map
  "!" 'gnus-summary-maybe-unread-and-hammify-article)
(define-key gnus-summary-mode-map
  "$" 'gnus-summary-mark-all-as-spam-and-exit)

(remove-hook 'gnus-get-top-new-news-hook 'spam-maybe-spam-stat-load)

-- 
vsync
http://quadium.net/~vsync/

The beauty of Amendment II is that it protects the ability to deal
with both a tyrannical government and a zombie apocalypse.
        -- Eochada,
           http://forums.fark.com/cgi/fark/comments.pl?IDLink=2749371

Re: spam.el: copy/move of ham articles from unclassified groups

[Ted Zlatanov]

On Sat, 21 Apr 2007 12:43:05 -0400 Tim Howe <vsync@quadium.net> wrote: 

TH>   Mail is split according to senders, then if none matches the spam
TH>   splitter is used.  nnml:raw.spammy is my spam split destination; all
TH>   the rest goes to nnml:raw.  These 2 groups are unclassified (neither
TH>   spam nor ham).

Tim,

sorry for the late reply.  I cc-ed your e-mail address to make sure
you'd get it.
  
TH>   I have a single group classified as spam: nnml:spam.explicit.  This is
TH>   my spam process destination.

TH>   All other groups are classified as ham.

TH> Currently my workflow is as follows: enter the /nnml:raw\(\..*\)?/
TH> groups, move all the ham articles into nnml:misc to be read or manually
TH> split later, then mark all the rest of the articles as spam and exit the
TH> group, causing them to be processed and moved to nnml:spam.explicit.

OK.

TH> Now (correct me if I'm wrong) I could have /nnml:raw\(\..*\)?/
TH> classified as spam groups for the same basic effect.  However I don't
TH> like that I lose all the score highlighting when they are auto-marked as
TH> spam, and I'm nervous about the default mark being "spam".  Please tell
TH> me if this is a legitimate concern.

There's not much I can do about the score highlighting.  I wouldn't
worry about the spam mark, but honestly I would recommend a server-side
filter such as CRM114 instead of the setup you describe.  It's much more
satisfying and about 10 times easier to train on error than train your
filters all the time.

TH> I'm thinking what I will do is implement an interactive function which
TH> overrides the ! key in the raw groups.  It will remove all marks and
TH> move the article into nnml:misc.

TH> Is there a reason that gnus-ham-process-destinations only works for spam
TH> groups and not in non-ham groups?  

The assumption is that if you want to process things as ham, it's
because they were marked as spam beforehand.  The anti-spam systems I
know don't need to be told they did the right thing with ham.  If that's
not true, let me know what you think.

TH> If the registry is used that should avoid double-processing
TH> concerns, no?

It should if I fixed my code :)  I've been too swamped to look at it,
and the gnus-registry has not been maintained by anyone meanwhile.  I
know I had at least one bug report regarding double processing.

I am cc-ing the Gnus developers list in case someone is interested in
taking over spam.el and gnus-registry.el since I'm unable to keep them
current and respond to bug reports quickly.

Ted