spam-check-BBDB bug?/bbdb whitelist split function

spam-check-BBDB bug?/bbdb whitelist split function

[Bill White]

I was futzing around defining my own "if he's in bbdb then he's not
spam" split function when I discovered spam-check-BBDB in spam.el:

----------------------------------------------------------------------
(defun spam-check-BBDB ()
    "Mail from people in the BBDB is never considered spam"
    (let ((who (message-fetch-field "from")))
      (when who
	(setq who (regexp-quote (cadr
				 (gnus-extract-address-components who))))
	(if (bbdb-search-simple nil who)
	    nil spam-split-group))))
----------------------------------------------------------------------

It seems in my tests that bbdb-search-simple does not search for a
regexp but for a simple string representation of an address, so I
suspect the regexp-quote bit should be removed.

I've also adjusted this to return a positive match for bbdb persons;
folks who maintain bbdb as a whitelist might find it useful (adjust
for local conditions, YMMV, etc.):

----------------------------------------------------------------------
(defun billw-BBDB-whitelist ()
  "BBDB is a whitelist."
  (let ((who (message-fetch-field "from")))
    (when who
      (setq who (cadr (gnus-extract-address-components who)))
      (if (bbdb-search-simple nil who)
	  (format-time-string "mail.misc.%Y.%m")
	nil))))

(setq nnmail-split-fancy
      '(|
	("to" ".*billw@wri\\.com" "spamtrap")
        ("List-Id" ".*gnucash-announce\\.lists\\.gnucash\\.org.*" "gnucash-announce")
	("List-Id" ".*gnucash-user\\.lists\\.gnucash\\.org.*" "gnucash-user")
	("List-Id" ".*gnucash-devel\\.lists\\.gnucash\\.org.*" "gnucash-devel")
	("List-Id" ".*gnucash-patches\\.lists\\.gnucash\\.org.*" "gnucash-patches")
        ("List-ID" ".*developer list for mt\\.el.*" "mt-el")

;;      [...]

;; my bbdb is a whitelist: save these
	(: billw-BBDB-whitelist)
;; check for scum       
	(: spam-stat-split-fancy)
;; non-whitelist non-spam: save these
	(: (lambda nil (format-time-string "mail.misc.%Y.%m")))
))
----------------------------------------------------------------------

Cheers -

bw
-- 
Bill White . billw@wolfram.com . http://members.wri.com/billw
"No ma'am, we're musicians."

Re: spam-check-BBDB bug?/bbdb whitelist split function

[Ted Zlatanov]

On Tue, 04 Feb 2003, billw@wolfram.com wrote:
> I was futzing around defining my own "if he's in bbdb then he's not
> spam" split function when I discovered spam-check-BBDB in spam.el:
> 
> It seems in my tests that bbdb-search-simple does not search for a
> regexp but for a simple string representation of an address, so I
> suspect the regexp-quote bit should be removed.

Thanks, that was left over from the old bbdb-search function call.

> I've also adjusted this to return a positive match for bbdb persons;
> folks who maintain bbdb as a whitelist might find it useful (adjust
> for local conditions, YMMV, etc.):

Currently, spam-split will fall through to the next spam/ham check on
a whitelist match.

I thought of having whitelists return t for a positive ham match, and
then spam-split wouldn't examine the rest of the spam/ham checks but
simply return nil altogether. Does that makes sense?  Or should
spam-split have a ham-split-group analogous to spam-split-group?  

I always assumed people would rather have spam-split fall through on
ham than have it be an absolute arbiter, but maybe users would like it
the other way.  Or both ways.  This is Gnus, after all.  I'm sure
there's a user out there that wants spam-split to retrieve his daily
comics :)

Ted

Re: spam-check-BBDB bug?/bbdb whitelist split function

[Bill White]

On Wed Feb 05 2003 at 08:47, Ted Zlatanov <tzz@lifelogs.com> said:

>> I've also adjusted this to return a positive match for bbdb
>> persons; folks who maintain bbdb as a whitelist might find it
>> useful (adjust for local conditions, YMMV, etc.):
>
> Currently, spam-split will fall through to the next spam/ham check
> on a whitelist match.
>
> I thought of having whitelists return t for a positive ham match,
> and then spam-split wouldn't examine the rest of the spam/ham checks
> but simply return nil altogether. Does that makes sense?

Kinda, but I don't have a clear picture of the whole thing (hence my
little function to do the one thing I wanted at that precise place).

> Or should spam-split have a ham-split-group analogous to
> spam-split-group?

Aha - that's exactly what I was grepping for last night.

> I always assumed people would rather have spam-split fall through on
> ham than have it be an absolute arbiter, but maybe users would like
> it the other way.  Or both ways.  This is Gnus, after all.

Yes - a user can always whip up some working code that reflects the
way he sees reality.

> I'm sure there's a user out there that wants spam-split to retrieve
> his daily comics :)

Now there's an idea...

Cheers -

bw
-- 
Bill White . billw@wolfram.com . http://members.wri.com/billw
"No ma'am, we're musicians."

Re: spam-check-BBDB bug?/bbdb whitelist split function

[Niklas Morberg]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Currently, spam-split will fall through to the next
> spam/ham check on a whitelist match.
>
> I thought of having whitelists return t for a positive ham
> match, and then spam-split wouldn't examine the rest of the
> spam/ham checks but simply return nil altogether. Does that
> makes sense? 

Given that I understand you correctly: yes! I get some false
positives on mail from people who are in my BBDB when I use
spam-stat.el. If what you are writing means: turn on BBDB
whitelisting and all mail from everybody in your BBDB will
be considered ham, then I am all for it.

False positives are really really bad because it means I
have to sift through my spam group looking for valid emails.
But you knew this already.

Niklas

Re: spam-check-BBDB bug?/bbdb whitelist split function

[Ted Zlatanov]

On Wed, 05 Feb 2003, niklas.morberg@axis.com wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>> Currently, spam-split will fall through to the next
>> spam/ham check on a whitelist match.
>>
>> I thought of having whitelists return t for a positive ham
>> match, and then spam-split wouldn't examine the rest of the
>> spam/ham checks but simply return nil altogether. Does that
>> makes sense? 
> 
> Given that I understand you correctly: yes! I get some false
> positives on mail from people who are in my BBDB when I use
> spam-stat.el. If what you are writing means: turn on BBDB
> whitelisting and all mail from everybody in your BBDB will
> be considered ham, then I am all for it.

Well, here's the embarassing thing: this was how things were supposed
to work when Francois Pinard wrote the code, but I didn't pay
attention and made whitelist/BBDB checks fall through to the next
spam-split rule (they returned nil instead of t).  So it's all my fault.

> False positives are really really bad because it means I have to
> sift through my spam group looking for valid emails.  But you knew
> this already.

I think the new code will fix that, try it (just committed to CVS).

I also added spam-use-{whitelist,BBDB}-exclusive for those who want to
consider all mail from people NOT in the BBDB/whitelist spam.

Ted

Re: spam-check-BBDB bug?/bbdb whitelist split function

[Ted Zlatanov]

On Wed, 05 Feb 2003, billw@wolfram.com wrote:
> On Wed Feb 05 2003 at 08:47, Ted Zlatanov <tzz@lifelogs.com> said:
> 
>>> I've also adjusted this to return a positive match for bbdb
>>> persons; folks who maintain bbdb as a whitelist might find it
>>> useful (adjust for local conditions, YMMV, etc.):
>>
>> Currently, spam-split will fall through to the next spam/ham check
>> on a whitelist match.
>>
>> I thought of having whitelists return t for a positive ham match,
>> and then spam-split wouldn't examine the rest of the spam/ham
>> checks but simply return nil altogether. Does that makes sense?
> 
> Kinda, but I don't have a clear picture of the whole thing (hence my
> little function to do the one thing I wanted at that precise place).

I had screwed up my code in spam.el - now, spam-use-BBDB and
spam-use-whitelist will not go to the next rule, if the sender is in
the BBDB/whitelist but simply exit spam-split altogether; also they
will only consider messages from people NOT in the BBDB/whitelist spam
if spam-use-{whitelist,BBDB}-exclusive is set.  Basically, I ended up
doing what you (and I assume everyone else) wants out of
BBDB/whitelisting, instead of the broken behavior I had in place
before.

>> Or should spam-split have a ham-split-group analogous to
>> spam-split-group?
> 
> Aha - that's exactly what I was grepping for last night.

I'd rather have spam-split fall through to the next rule in the
split-fancy sequence, I think.  It was just not doing the right thing
before, that's all...  The bug was in the code, not the design.

But if people want ham-split-group, I can add it to the ham checks as
an option, instead of fall-through.  This variable name is getting
dangerously close to "split-pea and ham soup."

Thanks
Ted

spam-stat broken? (was: spam-check-BBDB bug?/bbdb whitelist split function)

[Niklas Morberg]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I think the new code will fix that, try it (just committed
> to CVS).

I'm afraid something else broke. Spam-stat hasn't caught a
single spam for me lately. I think it stopped working around
this time. I tried both to enable and disable the new BBDB
related variables.

Judging from the message buffer, it does get called -- it's
just that the messages are never ever reported as spam. They
were before.

Snippet from the Messages buffer:

Loading c:/cygwin/home/niklas/.spam-stat.el (source)...done
spam-split: calling the spam-check-stat function
IMAP split moved mailse01.axis.se:INBOX:130822 to incoming

Niklas

Re: spam-stat broken?

[Niklas Morberg]

Niklas Morberg <niklas@axis.com> writes:

> I'm afraid something else broke. Spam-stat hasn't caught a
> single spam for me lately.

Sorry, I spoke too soon. It does seem to work, although more
spams than previously get through.

OTOH I am having problems using the spam functionality with
the agent, but I haven't looked at it closely enough to
submit a proper problem description. It just feels a bit
shaky...

There's also the known problem of not being able to
automatically move more than one ham message out of the
spam group that is a bit annoying.

Niklas

Re: spam-stat broken?

[Ted Zlatanov]

On Tue, 11 Feb 2003, niklas.morberg@axis.com wrote:
> Niklas Morberg <niklas@axis.com> writes:
> 
>> I'm afraid something else broke. Spam-stat hasn't caught a
>> single spam for me lately.
> 
> Sorry, I spoke too soon. It does seem to work, although more
> spams than previously get through.

I'm not sure how to fix that, but I'd guess your statistics database
got skewed somehow.

> OTOH I am having problems using the spam functionality with
> the agent, but I haven't looked at it closely enough to
> submit a proper problem description. It just feels a bit
> shaky...

I'll follow up in the other thread.

> There's also the known problem of not being able to
> automatically move more than one ham message out of the
> spam group that is a bit annoying.

I looked into that, and could not find anything wrong in spam.el's
behavior (I'm pretty sure I posted a message to that effect to the
ding list, asking for some help).  I think the problem was with this
code:

    (dolist (article articles)
      (when (and (memq (gnus-summary-article-mark article) ham-mark-values)
		 (stringp group))
	(let ((gnus-current-article article))
	  (gnus-summary-move-article nil group))))

in spam-ham-move-routine, but when I ran the routine interactively I
could not figure out what was wrong.  I'll look at it again, but
I can't promise I'll do better this time :)

Ted

Re: spam-stat broken?

[Ted Zlatanov]

On Tue, 11 Feb 2003, tzz@lifelogs.com wrote:
> On Tue, 11 Feb 2003, niklas.morberg@axis.com wrote:
>> There's also the known problem of not being able to
>> automatically move more than one ham message out of the
>> spam group that is a bit annoying.
> 
> I looked into that, and could not find anything wrong in spam.el's
> behavior (I'm pretty sure I posted a message to that effect to the
> ding list, asking for some help).  I think the problem was with this
> code:

Hm, I think I may have inadvertently fixed the problem :)

I'm not sure if it's the right way to do it, but I now set the
process-mark on every article that is to be moved, and then call
gnus-summary-move-article.  It seems to work in my testing.

Ted

Re: spam-stat broken?

[Niklas Morberg]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Hm, I think I may have inadvertently fixed the problem :)

The move routines seem to be working better now, but after
some more testing I still see the problem with non-existing
messages being displayed in the summary buffer by the agent.

> I'm not sure if it's the right way to do it, but I now set the
> process-mark on every article that is to be moved, and then call
> gnus-summary-move-article.  It seems to work in my testing.

Is it really necessary to call g-s-m-a for every article?
Wouldn't it be more effective to first mark all articles
with the process mark and then call g-s-m-a once?

Niklas

Re: spam-stat broken?

[Ted Zlatanov]

On Wed, 12 Feb 2003, niklas.morberg@axis.com wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:

>> I'm not sure if it's the right way to do it, but I now set the
>> process-mark on every article that is to be moved, and then call
>> gnus-summary-move-article.  It seems to work in my testing.
> 
> Is it really necessary to call g-s-m-a for every article?
> Wouldn't it be more effective to first mark all articles
> with the process mark and then call g-s-m-a once?

As I said, I'm not sure it's the right way.  Another issue is, what if
you have articles process-marked before you exit a group?  Will the
process-mark get removed before the spam.el routines get invoked?  I
didn't test this yesterday because I was in a hurry.

Ted

Re: spam-stat broken?

[Ted Zlatanov]

On Wed, 12 Feb 2003, tzz@lifelogs.com wrote:
> As I said, I'm not sure it's the right way.  Another issue is, what
> if you have articles process-marked before you exit a group?  Will
> the process-mark get removed before the spam.el routines get
> invoked?  I didn't test this yesterday because I was in a hurry.

Both issues fixed:

- previously process-marked articles are unmarked now before spam/ham
  articles of interest are process-marked

- gnus-summary-move-article is called just once

Thanks
Ted

Re: spam-stat broken?

[Ted Zlatanov]

On Wed, 12 Feb 2003, niklas.morberg@axis.com wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>> Hm, I think I may have inadvertently fixed the problem :)
> 
> The move routines seem to be working better now, but after
> some more testing I still see the problem with non-existing
> messages being displayed in the summary buffer by the agent.

Can you check now?  If there is still a problem, something is wrong in
the interaction between the agent and gnus-summary-move-article.

Ted

The agent shows ghost messages (was: spam-stat broken?)

[Niklas Morberg]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Wed, 12 Feb 2003, niklas.morberg@axis.com wrote:
>> 
>> The move routines seem to be working better now, but after
>> some more testing I still see the problem with non-existing
>> messages being displayed in the summary buffer by the agent.
>
> Can you check now? If there is still a problem, something
> is wrong in the interaction between the agent and
> gnus-summary-move-article.

There is a problem, but it has nothing to do with the spam
functionality. I'm pretty sure the problem is with the agent.

Here's a way to repeat it:

1. Start with two unread and undownloaded messages in a
   group.

2. Read the first message.

3. Move the second message to another group with `B m'
   without reading it.

4. Exit the group.

5. Re-enter the same group. The second message shows up in
   the summary buffer, but it not possible to look at it.
   It has not been downloaded and it is not on the server.

This only happens if gnus-agent-mark-unread-after-downloaded
is nil. Setting g-a-m-u-a-d to non-nil makes the problem go
away.

I saw this a lot because I used the spam functionality to do
step 3 above and assumed that that was the culprit.

Thanks for the other fixes in spam.el, though -- they were
certainly not made in vain. I find the spam functionality
much more stable now.

Niklas

Re: The agent shows ghost messages

[Ted Zlatanov]

On Wed, 12 Feb 2003, niklas.morberg@axis.com wrote:
> Thanks for the other fixes in spam.el, though -- they were certainly
> not made in vain. I find the spam functionality much more stable
> now.

Thanks for reporting the bugs, and sorry it took me a while to get
back to you.  I'm going back to the message registry now :)

Ted

Re: The agent shows ghost messages (was: spam-stat broken?)

[Kevin Greiner]

Niklas Morberg <niklas.morberg@axis.com> writes:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> On Wed, 12 Feb 2003, niklas.morberg@axis.com wrote:
>>> 
>>> The move routines seem to be working better now, but after
>>> some more testing I still see the problem with non-existing
>>> messages being displayed in the summary buffer by the agent.
>>
>> Can you check now? If there is still a problem, something
>> is wrong in the interaction between the agent and
>> gnus-summary-move-article.
>
> There is a problem, but it has nothing to do with the spam
> functionality. I'm pretty sure the problem is with the agent.

Well, I don't use the spam functionality so this is going to be interesting.

> Here's a way to repeat it:
>
> 1. Start with two unread and undownloaded messages in a
>    group.
>
> 2. Read the first message.
>

Niklas, pls do the following command at this point:
M-: (debug-on-entry 'gnus-agent-expire)
M-: (setq gnus-verbose 7)

> 3. Move the second message to another group with `B m'
>    without reading it.

You should have been thrown into the debugger.  Did that happen?  Was
the first argument to gnus-agent-expire a list of one integer; the
article # of the article being moved?

Type 'c' to continue.

Take a look at the message buffer.  gnus-agent-expire should have
printed messages telling you that it removed the NOV entry for the
article in question.  Did it?

> 4. Exit the group.
>
> 5. Re-enter the same group. The second message shows up in
>    the summary buffer, but it not possible to look at it.
>    It has not been downloaded and it is not on the server.
>
> This only happens if gnus-agent-mark-unread-after-downloaded
> is nil. Setting g-a-m-u-a-d to non-nil makes the problem go
> away.

You should be using revision 6.142, or later, of gnus-agent.el.  Are
you?


Kevin

Re: The agent shows ghost messages

[Niklas Morberg]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> Niklas Morberg <niklas.morberg@axis.com> writes:
>>
>> There is a problem, but it has nothing to do with the
>> spam functionality. I'm pretty sure the problem is with
>> the agent.
>
> Well, I don't use the spam functionality so this is going
> to be interesting.
>
>> Here's a way to repeat it:

I see that I should have been more clear. What I meant was
"Here's a way to repeat it without involving spam functions
at all".

In other words, following the steps I described should make
the problem appear for you as well.

I'll respond separately with the information you asked for,
Kevin.

Niklas

Re: The agent shows ghost messages (was: spam-stat broken?)

[Niklas Morberg]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

>> 1. Start with two unread and undownloaded messages in a
>>    group.
>>
>> 2. Read the first message.
>>
>
> Niklas, pls do the following command at this point:
> M-: (debug-on-entry 'gnus-agent-expire)
> M-: (setq gnus-verbose 7)
>
>> 3. Move the second message to another group with `B m'
>>    without reading it.
>
> You should have been thrown into the debugger.  Did that happen?  

Yes.

> Was the first argument to gnus-agent-expire a list of one
> integer; the article # of the article being moved?

Yes. Complete output:

* gnus-agent-expire((8673) "incoming" force)
  gnus-request-move-article(8673 "incoming" "mailse01.axis.se" (gnus-request-accept-article "INBOX" (quote nil) t t) t)
  gnus-summary-move-article(nil)
* call-interactively(gnus-summary-move-article)

> Type 'c' to continue.

Once again, I end up in the debugger. I hit 'c' again.

> Take a look at the message buffer.  gnus-agent-expire should have
> printed messages telling you that it removed the NOV entry for the
> article in question.  Did it?

No. The contents of the message buffer (after having exited
and re-entered the "incoming" group says):

Moving to INBOX: (8673)...
Loading gnus-dup...done
Entering debugger...
 [2 times]
Mark set [2 times]
iswitchb-read-buffer: Quit
Continuing.
Expiring articles in incoming
gnus-agent-expire: Loading overview... Done
gnus-agent-expire: Sorting entries... Done
gnus-agent-expire: Merging entries... Done
Expiry...done
Entering debugger...
 [2 times]
Mark set [2 times]
Continuing.
nnimap: Setting marks in INBOX...done
nnimap: Updating info for INBOX...done
nnimap: Setting marks in incoming...done
Retrieving newsgroup: incoming...
nnimap: Updating info for incoming...done
Fetching headers for incoming...done
Generating summary...done
No more unread articles

>> 4. Exit the group.
>>
>> 5. Re-enter the same group. The second message shows up in
>>    the summary buffer, but it not possible to look at it.
>>    It has not been downloaded and it is not on the server.
>>
>> This only happens if gnus-agent-mark-unread-after-downloaded
>> is nil. Setting g-a-m-u-a-d to non-nil makes the problem go
>> away.
>
> You should be using revision 6.142, or later, of
> gnus-agent.el. Are you?

Yup:

$ cvs status gnus-agent.el
===================================================================
File: gnus-agent.el     Status: Up-to-date

   Working revision:    6.142
   Repository revision: 6.142   /usr/local/cvsroot/gnus/lisp/gnus-agent.el,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

Before doing the steps above I disabled all spam
functionality, exited emacs, downloaded a fresh gnus from
CVS, built it, installed it and then started emacs.

Niklas

Re: The agent shows ghost messages

[Kevin Greiner]

[-- Attachment #1: Type: text/plain, Size: 3476 bytes --]

Niklas Morberg <niklas.morberg@axis.com> writes:

> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
>>> 1. Start with two unread and undownloaded messages in a
>>>    group.
>>>
>>> 2. Read the first message.
>>>
>>
>> Niklas, pls do the following command at this point:
>> M-: (debug-on-entry 'gnus-agent-expire)
>> M-: (setq gnus-verbose 7)
>>
>>> 3. Move the second message to another group with `B m'
>>>    without reading it.
>>
>> You should have been thrown into the debugger.  Did that happen?  
>
> Yes.
>
>> Was the first argument to gnus-agent-expire a list of one
>> integer; the article # of the article being moved?
>
> Yes. Complete output:
>
> * gnus-agent-expire((8673) "incoming" force)
>   gnus-request-move-article(8673 "incoming" "mailse01.axis.se" (gnus-request-accept-article "INBOX" (quote nil) t t) t)
>   gnus-summary-move-article(nil)
> * call-interactively(gnus-summary-move-article)
>
>> Type 'c' to continue.
>
> Once again, I end up in the debugger. I hit 'c' again.
>
>> Take a look at the message buffer.  gnus-agent-expire should have
>> printed messages telling you that it removed the NOV entry for the
>> article in question.  Did it?
>
> No. The contents of the message buffer (after having exited
> and re-entered the "incoming" group says):
>
> Moving to INBOX: (8673)...
> Loading gnus-dup...done
> Entering debugger...
>  [2 times]
> Mark set [2 times]
> iswitchb-read-buffer: Quit
> Continuing.
> Expiring articles in incoming
> gnus-agent-expire: Loading overview... Done
> gnus-agent-expire: Sorting entries... Done
> gnus-agent-expire: Merging entries... Done
> Expiry...done
> Entering debugger...
>  [2 times]
> Mark set [2 times]
> Continuing.
> nnimap: Setting marks in INBOX...done
> nnimap: Updating info for INBOX...done
> nnimap: Setting marks in incoming...done
> Retrieving newsgroup: incoming...
> nnimap: Updating info for incoming...done
> Fetching headers for incoming...done
> Generating summary...done
> No more unread articles
>
>>> 4. Exit the group.
>>>
>>> 5. Re-enter the same group. The second message shows up in
>>>    the summary buffer, but it not possible to look at it.
>>>    It has not been downloaded and it is not on the server.
>>>
>>> This only happens if gnus-agent-mark-unread-after-downloaded
>>> is nil. Setting g-a-m-u-a-d to non-nil makes the problem go
>>> away.
>>
>> You should be using revision 6.142, or later, of
>> gnus-agent.el. Are you?
>
> Yup:
>
> $ cvs status gnus-agent.el
> ===================================================================
> File: gnus-agent.el     Status: Up-to-date
>
>    Working revision:    6.142
>    Repository revision: 6.142   /usr/local/cvsroot/gnus/lisp/gnus-agent.el,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)
>
> Before doing the steps above I disabled all spam
> functionality, exited emacs, downloaded a fresh gnus from
> CVS, built it, installed it and then started emacs.
>
> Niklas

Niklas,

The problem is that gnus-agent-expire failed to expire the
article. That shouldn't happen when the third parameter is force.  It
implies that either g-a-e is broken or that 8673 was never fetched
into the agent.  I've attached a copy of just g-a-e from revision
6.136 as I've been concerned with some recent changes to it.  Either
append this file to your gnus-agent.el or load it AFTER opening a
group.  Once you've loaded it, set gnus-verbose to 7 and repeat the 
'B m' test.


[-- Attachment #2: Old version of gnus-agent-expire --]
[-- Type: application/emacs-lisp, Size: 12460 bytes --]

[-- Attachment #3: Type: text/plain, Size: 17 bytes --]



Thanks,
Kevin

Re: The agent shows ghost messages

[Niklas Morberg]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> The problem is that gnus-agent-expire failed to expire the
> article. That shouldn't happen when the third parameter is
> force. It implies that either g-a-e is broken or that 8673
> was never fetched into the agent.

Oh. The article wasn't downloaded. I realize I wasn't
clear about this in my description. I'm trying to move an
undownloaded article because I can tell from its subject
alone that I want it in another group.

Niklas