Re: [Imap-protocol] Is server re-use of UID OK?

On 10/9/17 5:32 PM, Dave Warren wrote:
> 
> I think it might reduce confusion if we stop saying "Message was 
> deleted". "Deleted" doesn't have a clear definition in this context 
> because it isn't really a thing in IMAP (although it is how IMAP clients 
> present multiple different behaviours to users). At the protocol level, 
> you can set the \Deleted flag or you can EXPUNGE.

OK, s/Message was deleted/Message was deleted in the client program/  :)

> 
> Since a \Deleted flag can be trivially removed, there is no "reuse" of a 
> UID, the UID was still being reused and the COPY was just returning an 
> accurate (if unusual) result. Expunging and then reusing the UID 
> (assuming an unchanged UIDVALIDITY) would be a very significant problem 
> with regards to clients maintaining the validity of their caches, but 
> simply changing a flag is perfectly valid.

Openwave has no problem if the copy destination mbox is first expunged 
or if the original UID now having the \deleted flag is expunged with 
"uid expunge <uid>" since openwave has UIDPLUS capability. In that case 
the server copies to a new UID >= UIDNEXT with \deleted not set so the 
copied-in message is visible in the client program.

So I think if there is a bug in the openwave server it because it 
somewhat violates this requirement for the COPY command from rfc 3501:

"The COPY command copies the specified message(s) to the end of the 
specified destination mailbox.  The flags and internal date of the
message(s) SHOULD be preserved, and the Recent flag SHOULD be set,
in the copy."

1.The copy does not always copy messages to the "end" of specified 
destination mbox. (I don't see an explicit definition for "end" in the 
rfc but I am sure it means at UID >=UIDNEXT or at the next greater 
sequence number.)

2.When it does a copy to an existing and unexpunged UID not at the "end" 
it does not preserve the flag states from the source mbox/UID. Also, the 
Recent flag is not set. Of course, this is a SHOULD requirement so maybe 
there are valid reasons for not doing these that I'm not aware of.

-gene








> 
> _______________________________________________
> Imap-protocol mailing list
> [email protected]
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol