Re: bug in spam.el and expiry issue

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 22 Jan 2003, bruce+usenet@cenderis.demon.co.uk wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>> On Sat, 18 Jan 2003, bruce+usenet@cenderis.demon.co.uk wrote:
> 
> [...]
> 
>>> Secondly, how do I sanely use spam.el with auto-expire (or
>>> total-expire)?  It seems that spam gets categorised OK, but the
>>> ham never gets processed, since (presumably) by the time the check
>>> happens, it's marked with E, which is correctly not processed.
>>
>> The processing should happen before the expired-mark is applied,
>> but I have not tested that particular setup, so if you could check
>> and let me know, I'd appreciate it.  I may have to modify the
>> behavior of total and auto expiry a little when spam.el hooks into
>> the summary exit, if the expiry happens before
>> spam-summary-prepare-exit is invoked.
> 
> It's probably not important that auto-expiry work (indeed, I don't
> think it's possible, since auto-expiry marks things for expiry as
> soon as you read them).  But total-expire really does need to work,
> since I suspect most people who use gnus for email will have most
> groups set to total-expire (indeed, the manual suggests that that's
> true).

With the following group parameters:

((total-expire . t)
 (spam-contents gnus-group-spam-classification-ham)
 (spam-process
  (gnus-group-ham-exit-processor-whitelist))
 (expiry-wait . immediate)
 (expiry-target . "temporarygroup"))

I get ham-marked articles processed into the whitelist at summary
exit, before they are moved to "temporarygroup".  This is the expected
correct behavior.

If you are observing something different, could you show the group
parameters?  Make sure to set them explicitly, not through the regex
facilities - best create a new group and do `G c' on it.

Ted