new spam.el functionality

new spam.el functionality

[Ted Zlatanov]

Regular expression matching against headers.  You define a list of
regular expressions in spam-regex-headers-spam and
spam-regex-headers-ham, and set spam-use-regex-headers to t.
spam-split will invoke spam-check-regex-headers.

Pretty simple, really, but probably useful to people like a user on
the gnus newsgroups I responded to today, who get X-Spam-Flag: YES
headers and such added to their mail.  The default header regexps are
for the X-Spam-Flag header currently.

The manual was updated as well.

Ted

Re: new spam.el functionality

[Andreas Fuchs]

Today, Ted Zlatanov <tzz@lifelogs.com> wrote:
> Regular expression matching against headers.  You define a list of
> regular expressions in spam-regex-headers-spam and
> spam-regex-headers-ham, and set spam-use-regex-headers to t.
> spam-split will invoke spam-check-regex-headers.

Hm, isn't whitelist and blacklist functionality a subset of the regex
matching functionality? Could these three be merged easily?

Happy hacking,
-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

Re: new spam.el functionality

[Ted Zlatanov]

On Thu, 23 Jan 2003, asf@void.at wrote:
> Today, Ted Zlatanov <tzz@lifelogs.com> wrote:
>> Regular expression matching against headers.  You define a list of
>> regular expressions in spam-regex-headers-spam and
>> spam-regex-headers-ham, and set spam-use-regex-headers to t.
>> spam-split will invoke spam-check-regex-headers.
> 
> Hm, isn't whitelist and blacklist functionality a subset of the
> regex matching functionality? Could these three be merged easily?

I wouldn't merge them, they have very different purposes and
white/blacklists store their lists in files, but you could certainly
emulate white/blacklists with regex-headers if you wanted.  I don't
think anyone would.

Ted

Re: new spam.el functionality

[Raja R Harinath]

Hi,

Andreas Fuchs <asf@void.at> writes:

> Today, Ted Zlatanov <tzz@lifelogs.com> wrote:
>> Regular expression matching against headers.  You define a list of
>> regular expressions in spam-regex-headers-spam and
>> spam-regex-headers-ham, and set spam-use-regex-headers to t.
>> spam-split will invoke spam-check-regex-headers.
>
> 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.

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu

Re: new spam.el functionality

[Ted Zlatanov]

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.