Re: new spam.el functionality

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 23 Jan 2003, harinath@cs.umn.edu wrote:
> Andreas Fuchs <asf@void.at> writes:

>> Hm, isn't whitelist and blacklist functionality a subset of the
>> regex matching functionality? Could these three be merged easily?
> 
> Also applies to spam-check-bogofilter-headers.

spam-check-bogofilter-headers uses (message-fetch-field
spam-bogofilter-header), then extracts the spamicity score.

spam-check-blacklist (whitelists are similar) uses
(message-fetch-field "from"), and stores its regular expressions in a
file.  It's intended for large numbers of entries in the blacklist.

spam-check-regex-headers does a re-search-forward call on the message.

I think those are three pretty different functions.  At best, you can
come up with an improved message-fetch-field.  But maybe I'm
misunderstanding.

I'm not sure what you and Andreas are proposing: a merging of the user
interface variables, or a simplification of the code?

I am against merging of the user interface variables.  Users want a
Bogofilter header check, not Lisp code.  I don't think anyone would
prefer to add "^X-Bogosity: Yes.*spamicity=\\([0-9]+\\)" to the
spam-spam-regex-headers, to setting spam-use-bogofilter-headers to t.
If they want, they can do it, but spam.el is intended to be simple and
easy to use and configure.  Does anyone disagree with this?

Simplification of the code is a good goal, but sometimes it's not
necessary.  Can you produce code or a patch that shows how you would
like to abstract spam-check-bogofilter-headers, spam-check-blacklist,
and spam-check-regex-headers into one function?

Ted

p.s. should spam-*-regex-headers be "regexp-headers" instead of
"regex-headers"?

p.p.s. should it be just "regexp" instead of "regexp-headers", since
it does a match on whatever is available in the article buffer while
splitting?  spam-check-regex-headers is intended for headers, but
could be used on the body.