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

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

[Ted Zlatanov]

The following message is a courtesy copy of an article
that has been posted to gnu.emacs.gnus as well.

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