spam.el not saving spam-stat dictionary

spam.el not saving spam-stat dictionary

[Chong Yidong]

I've been trying to set up the spam-stat spam filtering library, and I
noticed that the new emails I receive aren't being saved into the
spam-stat dictionary.  From what I gather, emails that I mark as spam
are supposed to be "taught" to the dictionary as spam, and the rest of
the email as ham.  In practice, ~/.spam-stat.el hasn't changed since I
first initialized it.


After digging around, I found the follow suspicious code in
`spam-summary-prepare-exit':


	    (dolist (article changed-articles)
	      (let ((id (spam-fetch-field-message-id-fast article)))
		(when (spam-log-unregistration-needed-p
		       id 'process classification check)
		  (push article unregister-list))))
	    (when (and unregister-list (symbol-value check))
	      (spam-register-routine classification check t unregister-list)

The call to spam-register-routine is intended to save the article's
contents to the spam-stat dictionary.

However, in practice unregister-list is always nil, because
spam-log-unregistration-needed-p is defined as

  (defun spam-log-unregistration-needed-p (id type classification check)
    (when spam-log-to-registry
  	....))

And spam-log-to-registry defaults to nil.  Nothing ever gets pushed
onto unregister-list, and spam-register-routine is never called!
Surely this can't be the intended result?

Re: spam.el not saving spam-stat dictionary

[Ted Zlatanov]

On  7 Oct 2005, cyd@stupidchicken.com wrote:

> I've been trying to set up the spam-stat spam filtering library, and I
> noticed that the new emails I receive aren't being saved into the
> spam-stat dictionary.  From what I gather, emails that I mark as spam
> are supposed to be "taught" to the dictionary as spam, and the rest of
> the email as ham.  In practice, ~/.spam-stat.el hasn't changed since I
> first initialized it.
...>
> And spam-log-to-registry defaults to nil.  Nothing ever gets pushed
> onto unregister-list, and spam-register-routine is never called!
> Surely this can't be the intended result?

I'll take a look at this.  It does look suspicious :)  Thanks!
Ted

Re: spam.el not saving spam-stat dictionary

[Ted Zlatanov]

On  7 Oct 2005, cyd@stupidchicken.com wrote:

> I've been trying to set up the spam-stat spam filtering library, and I
> noticed that the new emails I receive aren't being saved into the
> spam-stat dictionary.  From what I gather, emails that I mark as spam
> are supposed to be "taught" to the dictionary as spam, and the rest of
> the email as ham.  In practice, ~/.spam-stat.el hasn't changed since I
> first initialized it.
>
> After digging around, I found the follow suspicious code in
> `spam-summary-prepare-exit':
>
>
> 	    (dolist (article changed-articles)
> 	      (let ((id (spam-fetch-field-message-id-fast article)))
> 		(when (spam-log-unregistration-needed-p
> 		       id 'process classification check)
> 		  (push article unregister-list))))
> 	    (when (and unregister-list (symbol-value check))
> (spam-register-routine classification check t unregister-list)
>
> The call to spam-register-routine is intended to save the article's
> contents to the spam-stat dictionary.
>
> However, in practice unregister-list is always nil, because
> spam-log-unregistration-needed-p is defined as
>
> (defun spam-log-unregistration-needed-p (id type classification check)
> (when spam-log-to-registry
> 	....))
>
> And spam-log-to-registry defaults to nil.  Nothing ever gets pushed
> onto unregister-list, and spam-register-routine is never called!
> Surely this can't be the intended result?

Chong,

The code you reference is not in the Gnus CVS, but in the 5-10
branch.  The latest spam.el doesn't have this bug, I believe.

As for the actual bug you refer to, this is unregistration, where
spam-register-routine is called to unregister articles (in the
spam-stat case, to remove stats).  I think you want to debug the
following parts of the function and there you'll find the reasons why
you are not getting things into your dictionary.  In the latest
spam.el I do registration/unregistration in a much cleaner (IMHO) way,
so it should work properly regardless.  This is one of the reasons I
wanted to put the latest spam*.el code in Emacs CVS and the 5-10, the
backend code is just much cleaner.

Ted