Re: Gnus SPAM support, and email based reporting.

["Ted Zlatanov" <tzz@lifelogs.com>]

On Mon, 24 May 2004, daniel@rimspace.net wrote:

On 19 May 2004, Ted Zlatanov wrote:

>> I'm planning to do a major overhaul (version 3 of spam.el, so to
>> speak) where a lot of the unnecessary complexity is at least only
>> done once.  Probably by the end of the year.
> 
> It struck me that there was an awful lot of writing of wrapper functions
> around what is, at heart, pipe to command A to learn as spam, or command
> B to learn as ham.
> 
> OTOH, I don't really understand your code so well and I am probably
> missing the reason why a bunch of this complexity exists.

The complexity is necessary to accomodate all the spam detection and
training backends.  BBDB, for instance, is VERY different from
Bogofilter.  Some backends don't detect incoming spam (the reporters),
others don't learn (spam-use-blackholes).  Like I said, I'll try to
simplify it, but the code will have to remain very abstract to handle
all the possible backends.  There will probably be
spam-register-backend which will handle all the various types of
backends.

>> With spam.el, you just make (spam spam-use-resend) the exit
>> processor of the group.  All spam articles will be processed
>> through it.
> 
> That didn't work.  I needed to add to the group parameters:
> 
>     (spam-process (gnus-group-spam-exit-processor-report-resend))
> 
> The other one didn't trigger, for some reason.

Looks like a bug in my code, because
gnus-group-spam-exit-processor-report-resend is supposed to be no
longer necessary.  I'll look today.

> Er, and finally, I think that it would be better to set `defcustom
> spam-report-resend-to' to `nil' by default.
> 
> Then, in the report function we could test that address and if it was
> `nil', display an error to the user and instruct spam.el to mark the
> article as "not processed"
> 
> That seems more user-friendly to me.  Alternately, we could actually
> prompt for the destination and save that with custom, but I don't know
> how to do that - custom is still a mysterious (and probably explosive)
> black box to me. :)

The resend-to address should be a Gnus group/topic variable that
overrides the default spam-report-resend-to, I think.  What do you think?

I applied your bug fix, thanks!

Ted