IMAP problem

IMAP problem

[Jens Gorm Rye-Andersen]

Hi

I am new to gnus, so this may be a simple problem, but I have
been unable to find a solution in the manual or by searching google :(

I read my mail from 3 imap servers. Two of these servers work fine, but
whenever gnus try to open the last server I get the following error
message:

"error in process filter: Internal error, tag 18 status BAD code nil
text STATUS Too few args (empty list)"

I can still access the INBOX on this server and read my mail, but every
time I press "q" to exit to the group buffer gnus hangs with the
message "Settings marks in INBOX...". From this point I can only cancel
by pressing C-g and switch to another buffer with C-b.  

I used mozilla-mail before converting to gnus, and mozilla had no
problem with this IMAP account. The MTA on the server is Postfix and the
imap daemon is mailutils-imap4d.

Any help would be appreciated.

Cheers, Jens

Re: IMAP problem

[Simon Josefsson]

Jens Gorm Rye-Andersen <jens@abk.auc.dk> writes:

> Hi
>
> I am new to gnus, so this may be a simple problem, but I have
> been unable to find a solution in the manual or by searching google :(
>
> I read my mail from 3 imap servers. Two of these servers work fine, but
> whenever gnus try to open the last server I get the following error
> message:
>
> "error in process filter: Internal error, tag 18 status BAD code nil
> text STATUS Too few args (empty list)"
>
> I can still access the INBOX on this server and read my mail, but every
> time I press "q" to exit to the group buffer gnus hangs with the
> message "Settings marks in INBOX...". From this point I can only cancel
> by pressing C-g and switch to another buffer with C-b.  
>
> I used mozilla-mail before converting to gnus, and mozilla had no
> problem with this IMAP account. The MTA on the server is Postfix and the
> imap daemon is mailutils-imap4d.
>
> Any help would be appreciated.

I recall seeing this too, it was a bug in mailutils if I recall
correctly.  Try (setq imap-log t) and look in *imap-log* and search
for STATUS last in the buffer.  Most probably, it violate the
protocol.  Try sending a bug report about it, or update to a later
version.

Re: IMAP problem

[Vincent Bernat]

OoO En cette aube naissante du dimanche 23 novembre 2003, vers 07:09,
Simon Josefsson <jas@extundo.com> disait:

> I recall seeing this too, it was a bug in mailutils if I recall
> correctly.  Try (setq imap-log t) and look in *imap-log* and search
> for STATUS last in the buffer.  Most probably, it violate the
> protocol.  Try sending a bug report about it, or update to a later
> version.

I have some similar message when marking a lot of messages. I will
check the trace the next time.
-- 
A FIRE DRILL DOES NOT DEMAND A FIRE
A FIRE DRILL DOES NOT DEMAND A FIRE
A FIRE DRILL DOES NOT DEMAND A FIRE
-+- Bart Simpson on chalkboard in episode 4F16

imap problem

[Andrew K. Bressen]

Hi--

I have a certain nnimap group I can no longer enter. 
When I try, the minibuffer displays something like:
  Process not open for writing: #<process "imap" pid 2037 state:exit>

Which I take to be the imap process buying it. 
This folder/group has been around for ages.
I can read many other groups on the same server.

When getting message counts in the summary buffer, the count is 
correctly updated for the group. 

I can use imap clients other than gnus to read this group. 

I tried blowing away the latest few messages in the group using another
client, and doing a cyrus reconstruct, but neither made any difference. 

On the server end, the read attempt with cyrus also kills off a server
process with "Signaled to death by 11". 

I'm using gnus 5.10.2 on xemacs 21.4. Intel linux machine.
Imap server is Cyrus 2.1.9. 
 
Help?

  --akb

Re: imap problem

[Andrew K. Bressen]

>> I have a certain nnimap group I can no longer enter. 
[...]
>> Help?

On Fri, 11 Jul 2003 09:57:47 +0200, Simon Josefsson wrote:
> Set `imap-log' and have a look in *imap-log* when this happens.

heisenbug, sigh. Today the group works ok again. 
It received some messages in the interval. 
I'll try for debugging info if the problem returns. 
Thanks for the clue!