On 28.9.2004, at 22:19, Michael Wener wrote:
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.
It only happens to be correct in that case. It could easily be wrong as well.
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.
It is still valid. The message may not physically exist anymore, but the sequence number still points to that one specific message. The message is completely gone from the session only after EXPUNGE is sent to client.
Here's an example of how you can easily break by trusting sequence numbers to be same with different sessions:
Session 1: 1 IDLE + idling * 1 EXPUNGE * 5 EXISTS
Session 2:
1 FETCH 5 UID // tries to fetch the "new" message, while in fact it fetches old one
* 6 EXISTS
* 5 FETCH (UID 5)
1 OK
2 NOOP
* 1 EXPUNGE
2 OK
Of course the session 2 could keep track of what expunges haven't been yet notified, but that gets complex and still doesn't make it entirely safe. Better to keep completely separete states for each connection.
PGP.sig
Description: This is a digitally signed message part
