On Tue, 2004-09-28 at 13:43, Timo Sirainen wrote: > On 28.9.2004, at 20:30, Michael Wener wrote: > > > Session 1 > > 1 IDLE > > + IDLE Accepted > > <Some time passes and then new mail arrives> > > * N EXISTS > > * 1 RECENT > > > > Session 2 > > <Ah Ha, I see I have new mail> > > 2 FETCH N BODYSTRUCTURE > > * N EXISTS > > * 1 RECENT > > 2 NO the specified message set is invalid > > This is clearly a client bug. There are no guarantees that multiple > sessions have compatible sequence numbers. Expunges especially may make > the fetch return wrong message. At minimum the client should do UID > FETCH and do some fallback processing if it doesn't return anything.
The point here is that it *is* currently a valid sequence number. After all the next FETCH confirms this. There is no guarantee within a *single* session that a sequence number is valid. Another session could have expunged SN N while my fetch was in transit in the network. For example on Exchange 2000 I get the peculiar series of responses. Again we see a one command lag of sorts ... Session 1 1 STORE N FLAGS (\Deleted) * N FETCH (FLAGS (\Deleted)) 1 OK STORE Completed 3 CLOSE 3 OK CLOSE Completed < Then after above command series is completed> Session 2 2 FETCH N FLAGS * N FETCH (FLAGS (\Deleted)) 2 NO Some Messages in the mailbox had previously been expunged 4 FETCH N FLAGS 4 NO Some Messages in the mailbox had previously been expunged It would not be difficult to craft a client that tolerated failed commands and then adjusted behavior. The strange thing here is that the responses are wrong, or more accurately stated, delayed. I'm very curious about this pattern of delay. Mike
