Re: Serious problems with multiple connections working with the same mailbox

On Thu, 15 Sep 2005, [ISO-8859-1] Jerry Lundstr=F6m wrote:
>1 UID FETCH 1276 FLAGS
>* 344 EXISTS
>* 1 RECENT
>* 344 FETCH (FLAGS (\Recent))
>If you read the rfc it clearly state that the server response EXISTS and
>RECENT should be used in the response of SELECT and EXAMINE.

You misread the RFC. You can get EXISTS and RECENT at any time; even as a
result of NOOP. EXPUNGE is restricted, but otherwise you can get mostly
any pending status update at any time.

>I also noticed that the function pendingUpdates can send information
>about FLAGS if that type is set and it doesnt check what type of command
>was sent.
>And yes, altho clients "should" be able to handle this, these types of
>responses are not ment to be sent here, yes I might have missed a rfc
>extension somewhere.

No, the server can send any response at any time. It can reorder them,
delay them, and so on. It can even send responses while you're sending
requests.

>Here is more confusing output from Binc that pendingUpdates makes:
>1 UID FETCH 1278 FLAGS
>* 346 FETCH (FLAGS (\Deleted) UID 1278)
>* 346 FETCH (FLAGS (\Deleted))
>1 OK FETCH completed
>operator-fetch outputs the correct line and pendingUpdates adds the line
>without UID.

That looks strange, yes, but it's harmless. The first line is your
response, the second is a pending update. The pending update isn't
necessary, because your client already knows this message is Deleted. So
we could remove it for saving some bandwidth.

Andy :-)

--
Andreas Aardal Hanssen   | http://www.andreas.hanssen.name/gpg
Author of Binc IMAP      |  "It is better not to do something
http://www.bincimap.org/ |        than to do it poorly."