Re: [Imap-protocol] Synchronizing multiple mailbox

Timo Sirainen <[email protected]>
Newsgroups gmane.mail.imap.general
Message-ID <[email protected]>
On 15.6.2013, at 0.42, Bron Gondwana <[email protected]> wrote:

> On Sat, Jun 15, 2013, at 03:55 AM, Timo Sirainen wrote:
>> On 14.6.2013, at 15.36, Bron Gondwana <[email protected]> wrote:
>> 
>>> On Fri, Jun 14, 2013, at 10:22 PM, Timo Sirainen wrote:
>>>> On 14.6.2013, at 13.08, Bron Gondwana <[email protected]> wrote:
>>>> 
>>>>> We cheat at FastMail - we've got a patched Cyrus server which uses a single HIGHESTMODSEQ counter per user, as well as a single MAXUIDVALIDITY.  Since we always bump the UIDVALIDITY of folders on rename, create or delete (keeping a tombstone record), we only need to keep track of two numbers - one for any changes to the folder listing, and a second for any changes to any mailbox.  This allows us to optimise our web interface significantly (and provide the same advantages to any future clients that talk to our JSON API directly).
>>>> 
>>>> Won't the UIDVALIDITY change on RENAME invalidate the local cache even for the client that issued the RENAME command?
>>> 
>>> It has no guarantee anyway.  You can't keep the UIDVALIDITY on rename if the destination name previously existed with that same UIDVALIDITY.  Which means it either has to either trust that it's still the same folder after rename…
>> 
>> I'm increasing UIDVALIDITY every time a new mailbox is created, so no two mailboxes have the same. This avoids conflicts with RENAME.
> 
> We do this as well - but only within individual users, and mailboxes can be copied between users (yay shared mailboxes), so that would become prohibitively messy on a really large Cyrus instance.

I don't allow RENAME across user boundaries. Seems potentially dangerous.

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.