Good thread on a Cyrus forum discussing the same concept of UID collistion in server clusters.
http://tinyurl.com/9kcgv Might be good to see how they are handling this. Murder has been under development for some time now, so this is likely resolved. Kevin > On Fri, 2005-05-27 at 10:51 -0700, Kevin Baker wrote: >> Thanks for the explination I totally understand now. >> >> That being said, what is the actual harm in one message >> id >> being even a second off for the UID. They will both be >> entered in the mailstore, even if they are slightly out >> of >> order. > > It matters because if a client sees a mailbox and the > highest UID is 287 > and UID 286 comes in later it will NEVER KNOW about UID > 286 which means > mail is lost and the user is confused. > > RFC2060 actually _encourages_ IMAP client authors to make > this > optimization. > > >> Ultimately the Mail client will sort by the header >> information and if the clocks are different then they >> will >> be out of order. > > No. You're confusing Received-time and UID-time. > > You also assume clients perform an IMAP SEARCH ALL NOT > DELETED operation > whenever a new message comes in. There's no such > guarantee. If a client > saw "LAST UID=287" twice in a raw, then it'll never > download UID 286. > It'll just never be fetched. > > Here's the roadmap: > > UID 287 inserted > client sees highest UID number is 287 > UID 286 inserted > client NEVER DOWNLOADS UID 286 > > It never does because it has no reason whatsoever to think > it exists. > Some IMAP clients will detect it later because they do an > IMAP SEARCH > operation and treat the mailbox as a cache (Netscape, > Thunderbird), but > others will never notice it until UIDVALIDITY changes. > > >> I should note that I've been running a Cyrus system for >> some time now that occasionally has messages arrive one >> or >> two spots out of order, due to latency with mailfilters. >> It really isn't a problem. > > Cyrus _NEVER_ inserts UIDs before the highest number. > Received time has > nothing to do with it. > >> I realize this might bend the RFC slightly... but the >> added functionality is great and it will not break any >> mail clients. I am all for complete RFC compliance, but >> if >> we are talking about a matter of a second here and there >> due to processor lag I think we are probably going >> overboard. > > No. It's a very serious violation of RFC2060. This > "optimization" breaks > client optimizations. It breaks _most_ mail clients in > very subtle ways. > > People will complain. > > -- > Internet Connection High Quality Web Hosting > http://www.internetconnection.net/ > >
