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

--===============0761142417909068271==
Content-Type: multipart/alternative; boundary="94eb2c0dd4b86bcc1f055b134608"

--94eb2c0dd4b86bcc1f055b134608
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Oct 8, 2017 at 3:26 PM, Gene Smith <[email protected]> wrote:
>
>     C: aaa UID COPY 1267 "Mbox"
>>     S: aaa OK [COPYUID 123456789 1267 1007] UID COPY completed
>>     C: bbb UID store 1267 +Flags (\Deleted)
>>
>>     C: ccc UID COPY 1007 "Inbox"
>>     S: ccc OK [COPYUID 987654321 1007 1267] UID COPY completed
>>     C: ddd UID store 1007 +Flags (\Deleted)
>
>
I think the server is thinking, "its the same message I am copying back to
> Inbox (how does it knows? Same Message-ID or maybe checksum?) so I don't
> have to do anything." If the server had at least reset the \deleted flag =
on
> message at UID 1267 in Inbox I think it would be OK. The rfc says COPY mu=
st
> preserve the flags. It also says messages added to a mailbox must have UI=
D
> >=3D UIDNEXT. But if the server is copying in a message that is already
> present but just flagged as \deleted, maybe RFC doesn't say you can't
> COPYUID to the original UID which is < UIDNEXT? But I think the server
> should reset \deleted at the destination.
>

Recovering a used UID is never permitted*. If there is no EXPUNGE, there
should be two copies of the message in Inbox in this example. (Setting
\Deleted is reversible.)

The design of the specification is concerned with what happens when a
separate client connects before and after this exchange. Because UIDNEXT
has not been used correctly, clients that have cached state wouldn't see
changes to the mailbox correctly.

I guess the server might have an optimization (aka hack) for this, but it
doesn't appear to be properly protocol compliant.

* unless the UIDVALIDITY is reset, which trashes everyone's caches anyway.

Tim
=E2=80=8B

--94eb2c0dd4b86bcc1f055b134608
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sun, Oct 8, 2017 at 3:26 PM, Gene Smith=C2=A0<span dir=
=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=3D"_blank">gds@cha=
rtertn.net</a>&gt;</span>=C2=A0wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><span class=3D"gmail-"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">=C2=A0 =C2=A0 C: aaa UID COPY 1267 &quot;Mbox&quot;<br>=C2=A0 =
=C2=A0 S: aaa OK [COPYUID 123456789 1267 1007] UID COPY completed<br>=C2=A0=
 =C2=A0 C: bbb UID store 1267 +Flags (\Deleted)<br><br>=C2=A0 =C2=A0 C: ccc=
 UID COPY 1007 &quot;Inbox&quot;<br>=C2=A0 =C2=A0 S: ccc OK [COPYUID 987654=
321 1007 1267] UID COPY completed<br>=C2=A0 =C2=A0 C: ddd UID store 1007 +F=
lags (\Deleted)</blockquote></span></blockquote><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">I think the server is thinking, &quot=
;its the same message I am copying back to Inbox (how does it knows? Same M=
essage-ID or maybe checksum?) so I don&#39;t have to do anything.&quot; If =
the server had at least reset the \deleted flag on message at UID 1267 in I=
nbox I think it would be OK. The rfc says COPY must preserve the flags. It =
also says messages added to a mailbox must have UID &gt;=3D UIDNEXT. But if=
 the server is copying in a message that is already present but just flagge=
d as \deleted, maybe RFC doesn&#39;t say you can&#39;t COPYUID to the origi=
nal UID which is &lt; UIDNEXT? But I think the server should reset \deleted=
 at the destination.<br></blockquote><div><br></div><div>Recovering a used =
UID is never permitted*.=C2=A0If there is no EXPUNGE, there should be two c=
opies of the message in Inbox in this example. (Setting \Deleted is reversi=
ble.)</div><div><br></div><div>The design of the specification is concerned=
 with what happens when a separate client connects before and after this ex=
change. Because UIDNEXT has not been used correctly, clients that have cach=
ed state wouldn&#39;t see changes to the mailbox correctly.</div><div><br><=
/div><div>I guess the server might have an optimization (aka hack) for this=
, but it doesn&#39;t appear to be properly protocol compliant.</div><div><b=
r></div><div>* unless the UIDVALIDITY is reset, which trashes everyone&#39;=
s caches anyway.</div><div><br></div><div>Tim</div>=E2=80=8B</div>

--94eb2c0dd4b86bcc1f055b134608--

--===============0761142417909068271==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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