mailing list archives

I've had an issue reported against an IMAP server that I've written 
where OE thinks it has a deleted message that's not actually deleted. 
I've got a log file from the client, the relevant bits are:

IMAP: 15:01:29 [tx] domn UID FETCH 1:356478 (UID FLAGS)
...
IMAP: 15:01:35 [rx] * 4504 FETCH (UID 356256 FLAGS ())
...
IMAP: 15:01:42 [tx] h7mh UID STORE 356256 -FLAGS.SILENT (\Deleted)
IMAP: 15:01:43 [rx] h7mh OK STORE completed

i.e. it's trying to remove a \Deleted flag that isn't set on the 
message, which I guess means that locally it thinks that it's deleted 
and it hasn't picked up the flags from the fetch response.

I can't see anything wrong with the server responses, so it looks to me 
like OE is incapable of synchronising flags properly.  Is this known 
about/something that can be worked around, or have I just got something 
in the output format?

Thanks,

Mark

Quoting Mark Weaver <mark-clist@npsl.co.uk>:

> IMAP: 15:01:29 [tx] domn UID FETCH 1:356478 (UID FLAGS)
> ...
> IMAP: 15:01:35 [rx] * 4504 FETCH (UID 356256 FLAGS ())
> ...
> IMAP: 15:01:42 [tx] h7mh UID STORE 356256 -FLAGS.SILENT (\Deleted)
> IMAP: 15:01:43 [rx] h7mh OK STORE completed
>
> i.e. it's trying to remove a \Deleted flag that isn't set on the  
> message, which I guess means that locally it thinks that it's  
> deleted and it hasn't picked up the flags from the fetch response.
>
> I can't see anything wrong with the server responses, so it looks to  
> me like OE is incapable of synchronising flags properly.  Is this  
> known about/something that can be worked around, or have I just got  
> something in the output format?

It doesn't necessarily mean OE is not synchronising properly,  
especially without further context of the STORE command.  Is it just  
randomly sending a STORE request?  Or is that STORE request wedged in  
between other requests (e.g. a selective EXPUNGE on a message without  
the aid of UIDPLUS).

Or maybe OE's UI is not very refined and the user is allowed to  
undelete a message no matter the current flags set for that message.   
Or maybe OE is working around bugs found in past IMAP servers  
involving inconsistent flag state, resulting in seemingly spurious  
commands.  Or maybe OE is simply, at best, inefficient or, at worst,  
broken.

Point is, it is impossible to try to determine the logic without  
benefit of looking at the MUA's source code.  Not sure why you are  
concerned though: that command may be inefficient and redundant, but  
it is perfectly valid IMAP.

michael

Your IMAP transcript looks reasonable. Lacking any additional evidence,
I'm inclined to say that this is YAOEBWWNBF (Yet Another Outlook Express
Bug Which Will Never Be Fixed).

On Thu, 13 Oct 2011, Mark Weaver wrote:
> I've had an issue reported against an IMAP server that I've written
> where OE thinks it has a deleted message that's not actually deleted.
> I've got a log file from the client, the relevant bits are:
>
> IMAP: 15:01:29 [tx] domn UID FETCH 1:356478 (UID FLAGS)
> ...
> IMAP: 15:01:35 [rx] * 4504 FETCH (UID 356256 FLAGS ())
> ...
> IMAP: 15:01:42 [tx] h7mh UID STORE 356256 -FLAGS.SILENT (\Deleted)
> IMAP: 15:01:43 [rx] h7mh OK STORE completed
>
> i.e. it's trying to remove a \Deleted flag that isn't set on the
> message, which I guess means that locally it thinks that it's deleted
> and it hasn't picked up the flags from the fetch response.
>
> I can't see anything wrong with the server responses, so it looks to me
> like OE is incapable of synchronising flags properly.  Is this known
> about/something that can be worked around, or have I just got something
> in the output format?
>
> Thanks,
>
> Mark
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
>

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.