MBOX-Line: From slusarz at curecanti.org  Thu Oct 13 10:03:47 2011
To: imap-protocol@u.washington.edu
From: Michael M Slusarz <slusarz@curecanti.org>
Date: Fri Jun  8 12:34:46 2018
Subject: [Imap-protocol] Outlook Express issue
In-Reply-To: <4E96FA93.9000902@npsl.co.uk>
References: <4E96FA93.9000902@npsl.co.uk>
Message-ID: <20111013110347.Horde.VIQ5OoF5lbhOlxnz7RbVmaA@bigworm.curecanti.org>

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


