Various nnimap problems

Various nnimap problems

[Michael Welsh Duggan]

I'm going to use this thread to detail various nnimap problems I have
been running into.  Please keep in mind that I am working from bzr
emacs updated daily, so I am generally up to 1 day behind gnus
development right now.  (I may switch to using git gnus later on, if I
can help in the debugging process.)

I am working with three different IMAP servers.  One is Microsoft
Exchange, with all its implicit evil.  The others are different Cyrus
servers.

Capabilities for Exchange:
("IMAP4" "IMAP4REV1" "AUTH=NTLM" "AUTH=GSSAPI" "AUTH=PLAIN" "IDLE"
"NAMESPACE" "LITERAL+")

Capabilities for Cyrus 1:
("IMAP4" "IMAP4REV1" "LITERAL+" "ID" "LOGINDISABLED" "ACL" "RIGHTS=KXTE" "QUOTA" "MAILBOX-REFERRALS" "NAMESPACE" "UIDPLUS" "NO_ATOMIC_RENAME" "UNSELECT" "CHILDREN" "MULTIAPPEND" "BINARY" "SORT" "SORT=MODSEQ" "THREAD=ORDEREDSUBJECT" "THREAD=REFERENCES" "ANNOTATEMORE" "CATENATE" "CONDSTORE" "IDLE" "LISTEXT" "LIST-SUBSCRIBED" "X-NETSCAPE" "URLAUTH")

Capabilities for Cyrus 2:
("IMAP4" "IMAP4REV1" "ACL" "QUOTA" "LITERAL+" "NAMESPACE" "UIDPLUS" "ID" "NO_ATOMIC_RENAME" "UNSELECT" "CHILDREN" "MULTIAPPEND" "BINARY" "SORT" "THREAD=ORDEREDSUBJECT" "THREAD=REFERENCES" "ANNOTATEMORE" "IDLE" "LOGINDISABLED")

For the Exchange server I have nnimap-expunge-inbox set to t.

In all scenarios I am running the following demon:
(gnus-demon-add-handler 'gnus-demon-scan-news 10 nil)

Here are some of the problems I have experienced today (updated from
Emacs bzr trunk this morning):

*) On Exchange, I am seeing the 'junk split from nnmail-split-fancy not
   actually deleting the message.

*) On Cyrus 2, I am spuriously seeing an odd behavior when I am in a
   summary buffer reading messages.  Sometimes when going to the next
   message, it appears to have vanished from the server (marked with
   G).  When this happens, usually all articles in the summary buffer
   exhibit the same behavior.  Exiting the group (carefully unmarking
   the G articles) and reentering allows me to read those messages
   again.

*) Cyrus 1 is a public IMAP repository.  Before the new nnimap, I had
   several articles ticked in some of its groups.  For a couple of the
   groups, I tried unticking the articles.  This causes the following to
   happen:

   11:34:48 908 UID STORE 514 -FLAGS.SILENT (\Flagged)
   908 NO Permission denied

   Similarly, if I tick a message in a group, then hit g in the group
   buffer, the tick goes away.  (Same 908 problem.)

I have seen things that seemed like other problems.  I will add those
when I can pin them down and/or replicate them reliably.

-- 
Michael Welsh Duggan
(mwd@cert.org)

Re: Various nnimap problems

[Michael Welsh Duggan]

Michael Welsh Duggan <mwd@cert.org> writes:

[...]

> Capabilities for Cyrus 2:
> ("IMAP4" "IMAP4REV1" "ACL" "QUOTA" "LITERAL+" "NAMESPACE" "UIDPLUS" "ID" "NO_ATOMIC_RENAME" "UNSELECT" "CHILDREN" "MULTIAPPEND" "BINARY" "SORT" "THREAD=ORDEREDSUBJECT" "THREAD=REFERENCES" "ANNOTATEMORE" "IDLE" "LOGINDISABLED")

[...]

> In all scenarios I am running the following demon:
> (gnus-demon-add-handler 'gnus-demon-scan-news 10 nil)

[...]

> *) On Cyrus 2, I am spuriously seeing an odd behavior when I am in a
>    summary buffer reading messages.  Sometimes when going to the next
>    message, it appears to have vanished from the server (marked with
>    G).  When this happens, usually all articles in the summary buffer
>    exhibit the same behavior.  Exiting the group (carefully unmarking
>    the G articles) and reentering allows me to read those messages
>    again.

Some further information on this one.  It happens when sitting in a
summary buffer for a while.  I suspect it happens when a message is
added to the group behind gnus's back (via sieve).

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Various nnimap problems

[Julien Danjou]

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

On Wed, Sep 22 2010, Michael Welsh Duggan wrote:

> *) On Cyrus 2, I am spuriously seeing an odd behavior when I am in a
>    summary buffer reading messages.  Sometimes when going to the next
>    message, it appears to have vanished from the server (marked with
>    G).  When this happens, usually all articles in the summary buffer
>    exhibit the same behavior.  Exiting the group (carefully unmarking
>    the G articles) and reentering allows me to read those messages
>    again.

I see the same thing here with 2 differents Dovecot 1.2 servers on 2
differents computers.

I did not manage to get a pattern to reproduce so far. I'll try to look
on *nnimap* buffer next time, now that I know I'm not alone. :)

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Various nnimap problems

[Julien Danjou]

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

On Wed, Sep 22 2010, Julien Danjou wrote:

> I did not manage to get a pattern to reproduce so far. I'll try to look
> on *nnimap* buffer next time, now that I know I'm not alone. :)

Just happened. I think it's happening when I leave the summary open for
several minutes without doing anything else.

I had only one line with:
18258 OK Fetch completed.

in the nnimap buffer, and selecting other message just raised an error
and did not print anything else in the nnimap buffer.

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Various nnimap problems

[Lars Magne Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> Just happened. I think it's happening when I leave the summary open for
> several minutes without doing anything else.
>
> I had only one line with:
> 18258 OK Fetch completed.

Hm.  Odd.

I've now opened an nnimap summary buffer, and leaving it open for a few
minutes.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Various nnimap problems

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I've now opened an nnimap summary buffer, and leaving it open for a few
> minutes.

Opening an nnimap group, and then pressing `g' in the group buffer
reproduced the bug.

Fixed and pushed.


-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Various nnimap problems

[Lars Magne Ingebrigtsen]

Michael Welsh Duggan <mwd@cert.org> writes:

> *) On Exchange, I am seeing the 'junk split from nnmail-split-fancy not
>    actually deleting the message.

Ah.  No.  It's just left in the inbox?  Looking at the code,
`nnmail-article-group' doesn't have a callback to the backend to dispose
of junk messages, which it should.  I think I'll ... er ... Actually,
that's way more difficult than I thought.  Hm.  *ponder*

How annoying.

But there has to be a non-hacky way to achieve this...  I'll figure it
out.

> *) On Cyrus 2, I am spuriously seeing an odd behavior when I am in a
>    summary buffer reading messages.  Sometimes when going to the next
>    message, it appears to have vanished from the server (marked with
>    G).  When this happens, usually all articles in the summary buffer
>    exhibit the same behavior.  Exiting the group (carefully unmarking
>    the G articles) and reentering allows me to read those messages
>    again.

It sounds like something changed the current group behind your back, and
selecting a new article didn't change it back again.  Which is odd,
since the first thing `nnimap-request-article' does is change the group
back.

When this happens (when you get the first "G"), could you pop over to
the *nnimap <server> ...* buffer and see what in there?  Looking in the
*imap log* buffer may also hold clues.

> *) Cyrus 1 is a public IMAP repository.  Before the new nnimap, I had
>    several articles ticked in some of its groups.  For a couple of the
>    groups, I tried unticking the articles.  This causes the following to
>    happen:
>
>    11:34:48 908 UID STORE 514 -FLAGS.SILENT (\Flagged)
>    908 NO Permission denied
>
>    Similarly, if I tick a message in a group, then hit g in the group
>    buffer, the tick goes away.  (Same 908 problem.)

So nnimap shouldn't sync flags from public repositories?  How does
IMAP say that that's the case?  Is there a per-mailbox flag?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Various nnimap problems

[Michael Welsh Duggan]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Michael Welsh Duggan <mwd@cert.org> writes:
>
>> *) Cyrus 1 is a public IMAP repository.  Before the new nnimap, I had
>>    several articles ticked in some of its groups.  For a couple of the
>>    groups, I tried unticking the articles.  This causes the following to
>>    happen:
>>
>>    11:34:48 908 UID STORE 514 -FLAGS.SILENT (\Flagged)
>>    908 NO Permission denied
>>
>>    Similarly, if I tick a message in a group, then hit g in the group
>>    buffer, the tick goes away.  (Same 908 problem.)
>
> So nnimap shouldn't sync flags from public repositories?  How does
> IMAP say that that's the case?  Is there a per-mailbox flag?

Yes.  As part of a SELECT, the response should include an OK
[PERMANENTFLAGS (<list-of-flags>)] clause.  (Section 6.3.1 of RFC 3501
mandates this response.)  

         OK [PERMANENTFLAGS (<list of flags>)]
                     A list of message flags that the client can change
                     permanently.  If this is missing, the client should
                     assume that all flags can be changed permanently.

The RFC includes these examples:
         * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
         * OK [PERMANENTFLAGS ()] No permanent flags permitted

My Cyrus 1 server seems to include this:
         * OK [PERMANENTFLAGS ()]  

Also, from the spec:

      PERMANENTFLAGS

         Followed by a parenthesized list of flags, indicates which of
         the known flags the client can change permanently.  Any flags
         that are in the FLAGS untagged response, but not the
         PERMANENTFLAGS list, can not be set permanently.  If the client
         attempts to STORE a flag that is not in the PERMANENTFLAGS
         list, the server will either ignore the change or store the
         state change for the remainder of the current session only.
         The PERMANENTFLAGS list can also include the special flag \*,
         which indicates that it is possible to create new keywords by
         attempting to store those flags in the mailbox.


-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Various nnimap problems

[Lars Magne Ingebrigtsen]

Michael Welsh Duggan <md5i@md5i.com> writes:

> Yes.  As part of a SELECT, the response should include an OK
> [PERMANENTFLAGS (<list-of-flags>)] clause.  (Section 6.3.1 of RFC 3501
> mandates this response.)  
>
>          OK [PERMANENTFLAGS (<list of flags>)]
>                      A list of message flags that the client can change
>                      permanently.  If this is missing, the client should
>                      assume that all flags can be changed permanently.

I've started implementing this, but then I discovered that EXAMINE
always returns 

* OK [PERMANENTFLAGS ()]

on all the mail boxes.

*sigh*

So to inhibit the copying of marks from the server to Gnus on read-only
groups, nnimap has to maintain a cache so that it knows which groups not
do fiddle with.

Geez.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Various nnimap problems

[Michael Welsh Duggan]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Michael Welsh Duggan <mwd@cert.org> writes:
>
>> *) On Cyrus 2, I am spuriously seeing an odd behavior when I am in a
>>    summary buffer reading messages.  Sometimes when going to the next
>>    message, it appears to have vanished from the server (marked with
>>    G).  When this happens, usually all articles in the summary buffer
>>    exhibit the same behavior.  Exiting the group (carefully unmarking
>>    the G articles) and reentering allows me to read those messages
>>    again.
>
> It sounds like something changed the current group behind your back, and
> selecting a new article didn't change it back again.  Which is odd,
> since the first thing `nnimap-request-article' does is change the group
> back.
>
> When this happens (when you get the first "G"), could you pop over to
> the *nnimap <server> ...* buffer and see what in there?  Looking in the
> *imap log* buffer may also hold clues.

14:26:56 32587 UID FETCH 113674 BODY.PEEK[]
32587 OK Completed (0.000 sec)

But the messages before the FETCH were from a demon, and it changed the
group using SELECT.  I think the fix you mentioned elsewhere in this
thread may handle this.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Various nnimap problems

[Lars Magne Ingebrigtsen]

Michael Welsh Duggan <md5i@md5i.com> writes:

> But the messages before the FETCH were from a demon, and it changed the
> group using SELECT.  I think the fix you mentioned elsewhere in this
> thread may handle this.

Yup.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Various nnimap problems

[Michael Welsh Duggan]

Michael Welsh Duggan <md5i@md5i.com> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> Michael Welsh Duggan <mwd@cert.org> writes:
>>
>>> *) On Cyrus 2, I am spuriously seeing an odd behavior when I am in a
>>>    summary buffer reading messages.  Sometimes when going to the next
>>>    message, it appears to have vanished from the server (marked with
>>>    G).  When this happens, usually all articles in the summary buffer
>>>    exhibit the same behavior.  Exiting the group (carefully unmarking
>>>    the G articles) and reentering allows me to read those messages
>>>    again.
>>
>> It sounds like something changed the current group behind your back, and
>> selecting a new article didn't change it back again.  Which is odd,
>> since the first thing `nnimap-request-article' does is change the group
>> back.
>>
>> When this happens (when you get the first "G"), could you pop over to
>> the *nnimap <server> ...* buffer and see what in there?  Looking in the
>> *imap log* buffer may also hold clues.
>
> 14:26:56 32587 UID FETCH 113674 BODY.PEEK[]
> 32587 OK Completed (0.000 sec)
>
> But the messages before the FETCH were from a demon, and it changed the
> group using SELECT.  I think the fix you mentioned elsewhere in this
> thread may handle this.

Okay, I'm wrong.  In this case I got the error even though there was no
intermediate SELECT.  No idea what is going on here.

15:49:06 36205 SELECT "mail.Gnus"
15:49:06 36206 UID FETCH 179:181,218,226,240,266,279:280 (UID RFC822.SIZE BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)])
15:49:07 36207 UID FETCH 279 BODY.PEEK[]


* 281 EXISTS
* 3 RECENT
* 279 FETCH (UID 279 BODY[] {3727}
Return-Path: <ding-owner+M19838=md5i=md5i.com@lists.math.uh.edu>
Received: from maru.md5i.com ([unix socket])
	 by maru (Cyrus v2.2.13-Debian-2.2.13-19) with LMTPA;
	 Wed, 22 Sep 2010 15:44:50 -0400
X-Sieve: CMU Sieve 2.2
Received: from Debian-exim by maru.md5i.com with spam-scanned (Exim 4.72)
	(envelope-from <ding-owner+M19838=md5i=md5i.com@lists.math.uh.edu>)
	id 1OyVFG-0002nY-S2
	for md5i@md5i.com; Wed, 22 Sep 2010 15:44:50 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on maru.md5i.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD
	autolearn=ham version=3.3.1
Received: from util0.math.uh.edu ([129.7.128.18])
	by maru.md5i.com with esmtp (Exim 4.72)
	(envelope-from <ding-owner+M19838=md5i=md5i.com@lists.math.uh.edu>)
	id 1OyVFG-0002nT-MF
	for md5i@md5i.com; Wed, 22 Sep 2010 15:44:46 -0400
Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu)
	by util0.math.uh.edu with smtp (Exim 4.63)
	(envelope-from <ding-owner+M19838=md5i=md5i.com@lists.math.uh.edu>)
	id 1OyVFG-00068y-Aj
	for md5i@md5i.com; Wed, 22 Sep 2010 14:44:46 -0500
Received: from mx2.math.uh.edu ([129.7.128.33])
	by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.63)
	(envelope-from <postmaster@quimby.gnus.org>)
	id 1OyVFE-00068n-RL
	for ding@lists.math.uh.edu; Wed, 22 Sep 2010 14:44:44 -0500
Received: from quimby.gnus.org ([80.91.231.51])
	by mx2.math.uh.edu with esmtp (Exim 4.72)
	(envelope-from <postmaster@quimby.gnus.org>)
	id 1OyVFA-0004NK-Ja
	for ding@lists.math.uh.edu; Wed, 22 Sep 2010 14:44:44 -0500
Received: from lo.gmane.org ([80.91.229.12])
	by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian))
	id 1OyVF9-0005v4-00
	for <ding@gnus.org>; Wed, 22 Sep 2010 21:44:39 +0200
Received: from list by lo.gmane.org with local (Exim 4.69)
	(envelope-from <ding-account@m.gmane.org>)
	id 1OyVF2-0004E5-4d
	for ding@gnus.org; Wed, 22 Sep 2010 21:44:32 +0200
Received: from bas3-london14-1096786111.dsl.bell.ca ([65.95.160.191])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <ding@gnus.org>; Wed, 22 Sep 2010 21:44:32 +0200
Received: from jdc by bas3-london14-1096786111.dsl.bell.ca with local (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <ding@gnus.org>; Wed, 22 Sep 2010 21:44:32 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ding@gnus.org
From: Dan Christensen <jdc@uwo.ca>
Subject: Re: nnfolder change?
Date: Wed, 22 Sep 2010 15:41:03 -0400
Lines: 15
Message-ID: <877hidh8hc.fsf@uwo.ca>
References: <87r5gofpa1.fsf@escher.home> <m3iq1z9irf.fsf@quimbies.gnus.org>
	<87lj6vvslw.fsf@escher.home> <m339t2by47.fsf@quimbies.gnus.org>
	<871v8myyzd.fsf@escher.home> <874odiq8o6.fsf@uwo.ca>
	<m3mxr9kag0.fsf@quimbies.gnus.org> <87hbhhpss5.fsf@uwo.ca>
	<m3fwx1d1gq.fsf@quimbies.gnus.org>
Mime-Version: 1.0
Content-Type: text/plain
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: bas3-london14-1096786111.dsl.bell.ca
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (gnu/linux)
Cancel-Lock: sha1:EdHODppAS/3gV+e84Dw8QRwM1U4=
List-ID: <ding.gnus.org>
Precedence: bulk

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> With the change I pushed right now, could you try eval-in the following
> in a few of the *nnimap ... * buffers?
>
> (nnimap-server nnimap-object)

I just did a git pull and restarted emacs and gnus, and now there are
no *nnimap...* buffers for that jdc server (which is good, because its
groups are at a high level and so shouldn't be activated).  I'll let you
know if they show up again.

But I still do get lots of nnfolder buffers hanging around.

Dan


)
36207 OK Completed (0.000 sec)


-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Various nnimap problems

[Lars Magne Ingebrigtsen]

Michael Welsh Duggan <md5i@md5i.com> writes:

> Okay, I'm wrong.  In this case I got the error even though there was no
> intermediate SELECT.  No idea what is going on here.
>
> 15:49:06 36205 SELECT "mail.Gnus"
> 15:49:06 36206 UID FETCH 179:181,218,226,240,266,279:280 (UID RFC822.SIZE BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)])
> 15:49:07 36207 UID FETCH 279 BODY.PEEK[]

Are you using git or bzr Gnus now?

The "G" article thing should be fixed in git Gnus now, unless I've
missed some pattern that should reset `nnimap-group' in the nnimap
object. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Various nnimap problems

[Michael Welsh Duggan]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Michael Welsh Duggan <md5i@md5i.com> writes:
>
>> Okay, I'm wrong.  In this case I got the error even though there was no
>> intermediate SELECT.  No idea what is going on here.
>>
>> 15:49:06 36205 SELECT "mail.Gnus"
>> 15:49:06 36206 UID FETCH 179:181,218,226,240,266,279:280 (UID RFC822.SIZE BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)])
>> 15:49:07 36207 UID FETCH 279 BODY.PEEK[]
>
> Are you using git or bzr Gnus now?
>
> The "G" article thing should be fixed in git Gnus now, unless I've
> missed some pattern that should reset `nnimap-group' in the nnimap
> object. 

I've switched to git gnus now.  I'll let you know if this occurs again.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Various nnimap problems

[Michael Welsh Duggan]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Michael Welsh Duggan <md5i@md5i.com> writes:
>
>> Okay, I'm wrong.  In this case I got the error even though there was no
>> intermediate SELECT.  No idea what is going on here.
>>
>> 15:49:06 36205 SELECT "mail.Gnus"
>> 15:49:06 36206 UID FETCH 179:181,218,226,240,266,279:280 (UID RFC822.SIZE BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)])
>> 15:49:07 36207 UID FETCH 279 BODY.PEEK[]
>
> Are you using git or bzr Gnus now?
>
> The "G" article thing should be fixed in git Gnus now, unless I've
> missed some pattern that should reset `nnimap-group' in the nnimap
> object. 

It still happens with git Gnus as of
18913660c8707b4c488fc210d4fafc037528b206.  I didn't catch the log in
time, though.  Next time I'll M-x gnus-demon-cancel when I notice it, so
I can investigate.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Various nnimap problems

[Michael Welsh Duggan]

Michael Welsh Duggan <md5i@md5i.com> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> Michael Welsh Duggan <md5i@md5i.com> writes:
>>
>>> Okay, I'm wrong.  In this case I got the error even though there was no
>>> intermediate SELECT.  No idea what is going on here.
>>>
>>> 15:49:06 36205 SELECT "mail.Gnus"
>>> 15:49:06 36206 UID FETCH 179:181,218,226,240,266,279:280 (UID RFC822.SIZE BODYSTRUCTURE BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)])
>>> 15:49:07 36207 UID FETCH 279 BODY.PEEK[]
>>
>> Are you using git or bzr Gnus now?
>>
>> The "G" article thing should be fixed in git Gnus now, unless I've
>> missed some pattern that should reset `nnimap-group' in the nnimap
>> object. 
>
> It still happens with git Gnus as of
> 18913660c8707b4c488fc210d4fafc037528b206.  I didn't catch the log in
> time, though.  Next time I'll M-x gnus-demon-cancel when I notice it, so
> I can investigate.

I've finally recreated this again.  I select a message in a group, and
it appear to have been canceled or deleted.  After exiting the group and
reentering, the article is there.  I managed this time to capture the
nnimap and imap-log buffers immediately after the problem.  I have
stripped the carriage returns, so if you need to check the byte count on
the message, add them in before checking.  The last two imap queries
were:

14:19:49 71661 UID FETCH 514 BODY.PEEK[]
14:19:57 71662 UID FETCH 515 BODY.PEEK[]

The article I was attempting to read was article 515.  The response to
query 71662 was:

* 692 EXISTS
* 1 RECENT
* 515 FETCH (UID 515 BODY[] {4285}
Return-Path: <ding-owner+M20073@lists.math.uh.edu>
Received: from maru.md5i.com ([unix socket])
	 by maru (Cyrus v2.2.13-Debian-2.2.13-19) with LMTPA;
	 Sat, 25 Sep 2010 07:08:11 -0400
X-Sieve: CMU Sieve 2.2
Received: from Debian-exim by maru.md5i.com with spam-scanned (Exim 4.72)
	(envelope-from <ding-owner+M20073@lists.math.uh.edu>)
	id 1OzSbu-0004Lm-S0
	for md5i@md5i.com; Sat, 25 Sep 2010 07:08:11 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on maru.md5i.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD
	autolearn=ham version=3.3.1
Received: from util0.math.uh.edu ([129.7.128.18])
	by maru.md5i.com with esmtp (Exim 4.72)
	(envelope-from <ding-owner+M20073@lists.math.uh.edu>)
	id 1OzSbu-0004Lh-Et
	for md5i@md5i.com; Sat, 25 Sep 2010 07:08:06 -0400
Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu)
	by util0.math.uh.edu with smtp (Exim 4.63)
	(envelope-from <ding-owner+M20073@lists.math.uh.edu>)
	id 1OzSbp-0004Ae-8b; Sat, 25 Sep 2010 06:08:01 -0500
Received: from mx1.math.uh.edu ([129.7.128.32])
	by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.63)
	(envelope-from <postmaster@quimby.gnus.org>)
	id 1OzSbn-0004AM-HH
	for ding@lists.math.uh.edu; Sat, 25 Sep 2010 06:07:59 -0500
Received: from quimby.gnus.org ([80.91.231.51])
	by mx1.math.uh.edu with esmtp (Exim 4.72)
	(envelope-from <postmaster@quimby.gnus.org>)
	id 1OzSbi-0003Ws-Ne
	for ding@lists.math.uh.edu; Sat, 25 Sep 2010 06:07:59 -0500
Received: from lo.gmane.org ([80.91.229.12])
	by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian))
	id 1OzSbh-0001ZW-00
	for <ding@gnus.org>; Sat, 25 Sep 2010 13:07:53 +0200
Received: from list by lo.gmane.org with local (Exim 4.69)
	(envelope-from <ding-account@m.gmane.org>)
	id 1OzSbe-0005pH-Ku
	for ding@gnus.org; Sat, 25 Sep 2010 13:07:50 +0200
Received: from bas2-toronto63-1088793133.dsl.bell.ca ([64.229.170.45])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <ding@gnus.org>; Sat, 25 Sep 2010 13:07:50 +0200
Received: from cpchan by bas2-toronto63-1088793133.dsl.bell.ca with local (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <ding@gnus.org>; Sat, 25 Sep 2010 13:07:50 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ding@gnus.org
From: Charles Philip Chan <cpchan@sympatico.ca>
Subject: Re: Gravatar support
Date: Sat, 25 Sep 2010 07:07:16 -0400
Organization: Linux Private Site
Lines: 30
Message-ID: <87k4ma84kb.fsf@MagnumOpus.khem>
References: <1285348436-7582-1-git-send-email-julien@danjou.info>
	<87d3s3vyiy.fsf@lifelogs.com> <87eicjf27q.fsf@keller.adm.naquadah.org>
	<m3r5gjatro.fsf@quimbies.gnus.org> <87pqw380cd.fsf@lifelogs.com>
	<m3mxr7at1y.fsf@quimbies.gnus.org> <87hbhf7zga.fsf@lifelogs.com>
	<m362xvash9.fsf@quimbies.gnus.org> <87vd5u3884.fsf@rimspace.net>
	<87y6aqf60g.fsf@topper.koldfront.dk>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: bas2-toronto63-1088793133.dsl.bell.ca
X-Face: G;Z,`sm>)4t4LB/GUrgH$W`!AmfHMj,LG)Z}X0ax@s9:0>0)B&@vcm{v-le)wng)?|o]D<V6&ay<F=H{M5?$T%p!dPdJeF,au\E@TA"v22K!Zl\\mzpU4]6$ZnAI3_L)h;fpd}mn2py/7gv^|*85-D_f:07cT>\Z}0:6X
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)
Cancel-Lock: sha1:/VCZTxBfid+9ZRQahzGqM6pNJ+c=
List-ID: <ding.gnus.org>
Precedence: bulk

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

asjo@koldfront.dk (Adam Sj=C3=B8gren) writes:

> I just tried installing the picon-packages. And article-headers turned
> into fruit-salad.

Yes, the default "inline" style looks terrible. However, I quite like it
if you set "gnus-picon-style" to "right".

Charles

=2D-=20
"Oh, I've seen copies [of Linux Journal] around the terminal room at The
Labs."
(By Dennis Ritchie)

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)

iEYEARECAAYFAkyd1/EACgkQ3epPyyKbwPYRdACgw243k5wtvHwD25Mt2ICLgNYH
MqQAn2CBEJB5aJk4K8/V5o6MqvyoU26S
=edrE
-----END PGP SIGNATURE-----
--=-=-=--


)
71662 OK Completed (0.000 sec)


-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Various nnimap problems

[Lars Magne Ingebrigtsen]

Michael Welsh Duggan <md5i@md5i.com> writes:

> 14:19:49 71661 UID FETCH 514 BODY.PEEK[]
> 14:19:57 71662 UID FETCH 515 BODY.PEEK[]
>
> The article I was attempting to read was article 515.  The response to
> query 71662 was:
>
> * 692 EXISTS
> * 1 RECENT
> * 515 FETCH (UID 515 BODY[] {4285}
> Return-Path: <ding-owner+M20073@lists.math.uh.edu>

D'oh.  I understand what the issue is.  Stupid parsing bug.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Various nnimap problems

[Lars Magne Ingebrigtsen]

Michael Welsh Duggan <mwd@cert.org> writes:

> *) On Exchange, I am seeing the 'junk split from nnmail-split-fancy not
>    actually deleting the message.

This is now implemented.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Various nnimap problems

[Michael Welsh Duggan]

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

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Michael Welsh Duggan <mwd@cert.org> writes:
>
>> *) On Exchange, I am seeing the 'junk split from nnmail-split-fancy not
>>    actually deleting the message.
>
> This is now implemented.

Thank you.  This seems to work for the most part.  However, looking at
the code, it looks like if the only items in the inbox are marked as
'junk, they are not deleted.  This looks like a minor paren bug.  One
two few parens at then end of the (when sequences) clause in
nnimap-split-incoming-mail, and one too many at the end.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 653 bytes --]

diff --git a/lisp/nnimap.el b/lisp/nnimap.el
index 2d4f0de..42fe4d4 100644
--- a/lisp/nnimap.el
+++ b/lisp/nnimap.el
@@ -1154,8 +1154,8 @@ not done by default on servers that doesn't support that command.")
 	      ;; And then mark the successful copy actions as deleted,
 	      ;; and possibly expunge them.
 	      (nnimap-mark-and-expunge-incoming
-	       (nnimap-parse-copied-articles sequences))
-	      (nnimap-mark-and-expunge-incoming junk-articles))))))))
+	       (nnimap-parse-copied-articles sequences)))
+            (nnimap-mark-and-expunge-incoming junk-articles)))))))
 
 (defun nnimap-mark-and-expunge-incoming (range)
   (when range

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


-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Various nnimap problems

[Lars Magne Ingebrigtsen]

Michael Welsh Duggan <md5i@md5i.com> writes:

> -	       (nnimap-parse-copied-articles sequences))
> -	      (nnimap-mark-and-expunge-incoming junk-articles))))))))
> +	       (nnimap-parse-copied-articles sequences)))
> +            (nnimap-mark-and-expunge-incoming junk-articles)))))))

Thanks; installed and pushed.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen