MBOX-Line: From mrc at CAC.Washington.EDU  Sat Mar 17 21:23:12 2007
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:38 2018
Subject: [Imap-protocol] what does UIDNOTSTICKY really mean?
In-Reply-To: <07Mar16.184958pst."57996"@synergy1.parc.xerox.com>
References: <07Mar16.123633pst."57996"@synergy1.parc.xerox.com>
	<alpine.WNT.0.83.0703161613040.1748@Tomobiki-Cho.CAC.Washington.EDU>
	<07Mar16.184958pst."57996"@synergy1.parc.xerox.com>
Message-ID: <alpine.OSX.0.83.0703172102150.14619@pangtzu.panda.com>

On Fri, 16 Mar 2007, Bill Janssen wrote:
> My system will persist UIDs until the the server is re-booted for some
> reason; that is, UIDVALIDITY may be different each time a mailbox is
> selected, though it's not likely to be.  Depends on the frequency of
> selection.  So UIDs tend to be persistent, but are not guaranteed to be.
> Should I send UIDNOTSTICKY, or not?

You should not set UIDNOTSTICKY.  UIDNOTSTICKY is only when the 
UIDVALIDITY is never persistent.

HOWEVER!!  As a general "quality of implementation" issue, UIDVALIDITY 
SHOULD always be persistent for a mailbox.  The ONLY time that UIDVALIDITY 
should change is if a mailbox is deleted and a new mailbox with the same 
name is created.

UIDNOTSTICKY is an admission by the server that either the server or the 
mail store is of inferior quality that can not comply with the design 
requirements of IMAP UIDs.  Not announcing UIDNOTSTICKY, but changing the 
UIDVALIDITY on a mailbox is an admission by the server that either it or 
the mail store has an defect that caused it to fail to comply with the 
design requirements of IMAP UIDs.

Now, before people start jumping on me for saying such negative things 
about servers...let's note that the new mix format in UW imapd is the 
FIRST and ONLY mail store that is NOT inferior/defective by the above 
criteria.

Specifically, the mh, mtx, tenex, and arbitrary file formats are all 
"inferior", and the mbx, mmdf, mx, and traditional UNIX formats are all 
"defective".  The problems in those formats are due to legacy issues. 
One of the design goals of the mix format was to break free of legacy and 
not have those problems.

Put another way, UW imapd isn't "inferior"/"defective", but most of its 
supported mail stores (all but the newest mix format) are.  I am not happy 
about this; nor that it took me so long to come up with a mail store that 
didn't have this problem.

Any "inferior" or "defective" server and/or mail store causes considerable 
trouble to clients which depend upon UIDs for synchronization.  Only pure 
online clients such as Pine/Alpine will be relatively unscathed (and even 
Pine/Alpine uses UIDs for reply drafts to note the message being replied).

To be fair to UW imapd, the "defective" mail stores (most notably mbx and 
traditional UNIX) only show their defect under fault conditions; that is, 
something unexpected happened to screw things up.  Sadly, such faults do 
occur, and far more often than I (or my users!) like.  [Hence another 
motivation for mix format...]

Thus, unless you have legacy issues constraining you, you should exert 
heroic efforts to try to avoid inflicting yet another "inferior" or 
"defective" server and/or mail store on the world.  Yes, the 
specifications leave loopholes to allow it; but it should be considered 
embarassing to use those loopholes.  It's not "alright" to use those 
loopholes if you can avoid it.

Please try to have full sticky UIDs in your server and mail store.

[Do what I say, not what I do....]

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

