On Tue, 02 Apr 2002, teodor.zlatanov@divine.com wrote:
> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
>> The spam.el file contains rudimentary whitelist/blacklist support,
>> and you can build on that.
> 
> What features are missing that you wanted to add?
> 
> Did you want to finish the work?  It looks like spam.el is
> semi-complete already.  I don't mind picking up - it's always fun to
> polish my Lisp.  Just let me know what features/functions you
> wanted.

> What did you think about the "spam" mark?  I've added it to
> gnus-sum.el; patch attached.  I picked the "H" character for the
> company that brought us the original word, since "S" was taken.  I
> can see it being applied by score or by a splitting-time function.
> I also added a gnus-summary-mark-as-spam function, which could be
> augmented to also report the spam to user-defined destinations.

I haven't heard about the patch I submitted to add a "spam" mark.
Will that be committed by anyone, or is there a problem with the
patch?  

Also, I wanted to know what features were missing from spam.el that I
should add.  I know one eventual goal was to use it for splitting spam
in nnml-split-fancy with spam-address-whitelisted-p, and it seems like
it's already there.  What else?  Hooks for spamcop, TMDA, etc?

The spam-check-blackholes code will break on a full IPv6 address, is
there existing Emacs functionality to match those?  I didn't want to
write out the full IPv6 spec, it's pretty nasty.  Do we even care - do
those blackhole servers support IPv6 addresses?

I'm attaching a simple patch for a new function, spam-enter-blacklist,
which just invokes spam-enter-whitelist with the BLACKLIST parameter
t.  I think users will find it convenient.  The patch also fixes the
docstring for the blacklist file var, and adds more information to
both the whitelist and the blacklist file vars.

I'd like to add a gnus-summary-mark-as-spam-hooks hooks list to the
gnus-summary-mark-as-spam function, and then the user can invoke the
spam-enter-blacklist functions on a message as it is being marked as
spam.  That makes sense to me (mark as spam -> trigger add to
blacklist).  Does that sound reasonable?  Marking as spam with the
universal prefix might invoke the gnus-summary-mark-as-nonspam
function and the corresponding gnus-summary-mark-as-nonspam-hooks
hooks list.  This might require extra care, because we don't
necessarily want to add the same header always.  So there might be
"blacklist this sender", "blacklist this message-ID", and so on
functions.

Thanks
Ted