spam.el buglets.

spam.el buglets.

[Malcolm Purvis]

Having used spam.el with bogofilter for a while I have the following comments
on this generally excellent tool:

1) gnus.texi still refers to the spam mark as 'H' instead of '$'.

2) In ham groups it looks like read messages are still sent to ham filter for
   processing even if the group is exited with 'Q'
   (gnus-summary-exit-no-update).  Is this the intended behaviour?  My
   expectation is that no such processing should occur.

3) I am having difficulty understanding the advantages of having the choice of
   both spam and ham exit processors (ie
   gnus-group-spam-exit-processor-bogofilter and
   gnus-group-ham-exit-processor-bogofilter) for a given group when only one
   will apply.  Wouldn't a more generic symbol (ie
   gnus-group-exit-processor-bogofilter) be less confusing and the appropriate
   type of exit processing determined from the group's spam/ham
   classification?

Malcolm

-- 
	       Malcolm Purvis <malcolmpurvis@optushome.com.au>

The hidden, terrible cost of nuclear warfare is Really Bad Public Art.
			        - Angus McIntyre, alt.peeves, 13/3/02.

Re: spam.el buglets.

[Ted Zlatanov]

On Mon, 27 Jan 2003, malcolmpurvis@optushome.com.au wrote:
> 1) gnus.texi still refers to the spam mark as 'H' instead of '$'.

Fixed, thanks.

> 2) In ham groups it looks like read messages are still sent to ham
>    filter for processing even if the group is exited with 'Q'
>    (gnus-summary-exit-no-update).  Is this the intended behaviour?
>    My expectation is that no such processing should occur.

Hmm, this sounds like a bug, but how would I know that no-update was
requested?  That function doesn't seem to set any variables to let
summary exit hooks know it was a no-update situation.

> 3) I am having difficulty understanding the advantages of having the
>    choice of both spam and ham exit processors (ie
>    gnus-group-spam-exit-processor-bogofilter and
>    gnus-group-ham-exit-processor-bogofilter) for a given group when
>    only one will apply.  Wouldn't a more generic symbol (ie
>    gnus-group-exit-processor-bogofilter) be less confusing and the
>    appropriate type of exit processing determined from the group's
>    spam/ham classification?

Spam processors make sense for any group (including ham groups), so we
need to distinguish between spam and ham processors.

Ted

Re: spam.el buglets.

[Malcolm Purvis]

>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:

Ted> On Mon, 27 Jan 2003, malcolmpurvis@optushome.com.au wrote:

>> 3) I am having difficulty understanding the advantages of having the choice
>> of both spam and ham exit processors (ie
>> gnus-group-spam-exit-processor-bogofilter and
>> gnus-group-ham-exit-processor-bogofilter) for a given group when only one
>> will apply.

Ted> Spam processors make sense for any group (including ham groups), so we
Ted> need to distinguish between spam and ham processors.

I can see the value in having different groups (even the same group) processed
with  different spam processors, but not the ability for a given processor to
handle a group's ham but not spam. ie, why would I want bogofilter to progress
a group's ham but not spam.  Surely a more general 'feed everything in this
group to bogofilter (and/or whatever) would be easier to understand.

BTW, this is what happened to me.  For a week or so I all of my spam being sent
to bogofilter, but none of the ham, and I was wondering what was going on!

Malcolm


-- 
	       Malcolm Purvis <malcolmpurvis@optushome.com.au>

The hidden, terrible cost of nuclear warfare is Really Bad Public Art.
			        - Angus McIntyre, alt.peeves, 13/3/02.

Re: spam.el buglets.

[Ted Zlatanov]

On Sun, 02 Feb 2003, malcolmpurvis@optushome.com.au wrote:
>>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:

> Ted> Spam processors make sense for any group (including ham
> Ted> groups), so we need to distinguish between spam and ham
> Ted> processors.
> 
> I can see the value in having different groups (even the same group)
> processed with different spam processors, but not the ability for a
> given processor to handle a group's ham but not spam. ie, why would
> I want bogofilter to progress a group's ham but not spam.  Surely a
> more general 'feed everything in this group to bogofilter (and/or
> whatever) would be easier to understand.

Well, ifile for instance is good at filtering messages into
categories, but I don't personally like the way it classifies spam.
I'd want it to only process ham, and I'd want Bogofilter to handle all
spam processing.  Then I'd split incoming mail with Bogofilter first,
and then with ifile (so that Bogofilter will eliminate new spam).
Does that make sense?

I guess we could have a spam-exit-process-bogofilter symbol that would
activate both the ham and the spam Bogofilter processor.  Would that
be useful?

> BTW, this is what happened to me.  For a week or so I all of my spam
> being sent to bogofilter, but none of the ham, and I was wondering
> what was going on!

Sorry about that.  Do you have suggestions for improving the manual?

Ted