MBOX-Line: From blong at google.com  Fri Oct 13 18:13:31 2017
To: imap-protocol@u.washington.edu
From: Brandon Long <blong@google.com>
Date: Fri Jun  8 12:34:55 2018
Subject: [Imap-protocol] Is server re-use of UID OK?
In-Reply-To: <20430a7a-eeda-a60b-bf79-d55f1289f17a@chartertn.net>
References: <38137c2b-f1f1-2bed-e22f-2aea7fa50ac3@chartertn.net>
	<CAByav=gBnVkLg+4z90ewBvKRVtOrEQ7XESfirEQ1dyx=Sb0MXw@mail.gmail.com>
	<abb75221-a38a-3317-86a2-98a8340e55d3@chartertn.net>
	<CAByav=gfGNd2KHyx8kb9GQ-XEfs3L0LzqJuQGJRwDXg9x9mdMA@mail.gmail.com>
	<1a206274-8bce-f789-4dc9-638ed20e9372@chartertn.net>
	<d0bd4b95-90bb-4fae-937e-f4ad0c2ebd09@gulbrandsen.priv.no>
	<CABa8R6ucJXxUp9kAQ+_fDvtEAwmAYtJ6Hmr60J5=SW48SLvmig@mail.gmail.com>
	<b60bb28d-a16d-397d-784b-830265501279@chartertn.net>
	<CABa8R6sMcLPOF2gbv-EYAOzwVMVi5CwZC_GZ2aHmuu2xFpovGw@mail.gmail.com>
	<20430a7a-eeda-a60b-bf79-d55f1289f17a@chartertn.net>
Message-ID: <CABa8R6uN09NiGww5LC_Aiv_E9UrLW1wHE7sH4iPBo9bwYJNTvA@mail.gmail.com>

On Oct 13, 2017 5:40 PM, "Gene Smith" <gds@chartertn.net> wrote:

On 10/13/17 3:19 AM, Brandon Long wrote:

>
>
> What is the utility of the leave in folder marked as deleted?
>
> Most clients moved to a trash folder concept, which doesn't require the
> leave deleted state.
>

Well, I prefer the move to trash concept but some Thunderbird users still
prefer the "Just mark it as deleted" non-default mode where a Trash folder
is not involved and deleted messages just get crossed out in the UI after
the \Deleted flag is set.



> Gmail added auto-expunge as soon as we started testing imap, since people
> would delete messages... And they'd still be there in the web interface.
> We had no interest in adding the weird deleted still there mode to the
> Gmail client.  We debated a couple different modes, and they basically
> wound up as advanced settings, but just expunging made the most sense,
> especially since most mobile clients at the time never called expunge, and
> the main use case of imap for Gmail was for mobile clients.
>
> It is not a violation of RFC 3501, since another client could be connected
> and issue an expunge, as long as it's only visible at a sync point.
>

You're right, I looked at the rfc again and nowhere does it say an
auto-expunge can't occur; but, it never really mentions the concept.



> It did cause the occasional issue with clients that couldn't handle it in
> all cases, but those were all client bugs.
>
>
Since you can turn off auto-expunge at gmail it works around the problem in
Thunderbird when using "just mark deleted" mode.



>     OK, if I do this with auto-expunge set to false:
>     Copy message "test" (uid 5604) from Inbox to [Gmail]/f1
>     Message test is visible in Inbox and f1. Not crossed-out.
>     In Inbox, mark test with \deleted. It becomes crossed-out.
>     In f1 copy test to Inbox. Goes to uid 5604 in Inbox.
>     test in Inbox keeps \Deleted flag and remain crossed-out.
>
>     So gmail imap behaving same as openwave imap! It copies back to the
>     original UID and doesn't clear the \Deleted flag on UID 5604 in
>     Inbox and message remains crossed-out in client.
>
>     Why doesn't \Deleted on UID 5604 in Inbox get cleared after copy back?
>
>
> What is the proper thing to do?  We're mixing two mailbox models which
> aren't entirely compatible.
>
> I agree that clearing the flag is probably the right choice.  Most likely,
> this is a fairly unlikely scenario that only occurs with a really small
> number of clients when a very unused setting is enabled, so no one ran into
> it and made a decision.  I could probably file a bug for it.
>
>
This is also what I observed for the openwave server that I thought was a
bug. So it sounds like you agree a copy back to the same UID should result
in the same flag states at the destination that are present at the source.


I think that severs could implement either, the usage isn't write to spec
or quite against.  That said, leaving \Deleted can result in the unexpected
behavior of message loss, which should be avoided, so the user friendly
choice is to not leave \Deleted in that case.

Brandon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20171013/9aa917b0/attachment.html>
