looking for Cyrus mail format documentation

[Kendrick Vargas]

I've been sorta following this thread, and I don't claim to know a whole 
lot about programming, but I'm wondering why something simple like what 
I'm about to suggest wouldn't work... Here goes:

If a group of servers are gonna be in constant communication, why not just 
have each server assign UID's in increments of the number of servers in 
the group? For example, if you have 3 servers, and they realize they've 
disconnected, each of the servers could number in increments of 3 starting 
from different points.

Assuming the last UID was 502, server 1 would receive messages and number
them as 503, 506, 509, etc... Server 2 would number at 504, 507, 510, etc. 
And Server 3 would number at 505, 508, 511, etc. When the servers 
re-connect, the file numbers would be unique, the biggest issue you'd run 
into would be that the incomming sort order will be a little off, and not 
really. If the user sets their MUA to sort on date, it would be even less 
of an issue.

Why wouldn't something like this work? I mean, assuming that there's some 
logic involved in the software, the individual servers could figure out 
which incremented number they could use as their UID next. 
			-peace

On Tue, 4 Feb 2003, Mark Keasling wrote:

> On Tue, 4 Feb 2003 03:19:12 -0600, Phil Howard <phil-info-cyrus at ipal.net> wrote...
>
> > On Tue, Feb 04, 2003 at 02:16:36AM -0500, Rob Siemborski wrote:
> > 
> > | On Tue, 4 Feb 2003, Phil Howard wrote:
> > | 
> > | > Does the RFC say that the IMAP UIDs have to be the file name?
> > | 
> > | No, of course not.
> > | 
> > | > Do the IMAP UIDs have to be the same between different sessions?
> > | 
> > | They cannot change without also chanigng the UIDVALIDITY of the mailbox,
> > | which is an expensive operation for disconnected clients (it forces them
> > | to resync)
> > | 
> > | So yes, every time you need to resync, you can increment the uidvalidity,
> > | but your disconnected users are going to hate you for it, and this isn't a
> > | tremendously good solution for the real world (where temporary outages
> > | between distant nodes is the norm).
> > 
> > So the message with UID 123 during one session has to still have UID 123
> > during the next session.  That indeed will break the ability to have
> > unique remote syncronization.
> 
> Not really, it just makes it much more complex.  When the machines
> reconnect, they would need to have a way to determine if the same uid
> was referring to two different messages.  If so, appending those messages
> to the end of the folder with new uids and deleteing the old uid would
> re-uniquify the messages.  You may want to do that with all of the
> messages that two machines received while they were incommunicado.
> Essentially, the machines would have to remember their UIDNEXT value at
> the time that communication was lost.  Once communication was reestablished,
> all of the messages from the old UIDNEXT upto the current UIDNEXT held
> by each machine would need to be moved (append and delete) to the end of
> the folder.  The new uids would start from the largest UIDNEXT held by
> either machine. I think something like that would workat least in theory.
> 
> The main problem would be if the two machines appeared to users as
> the same machine due to DNS trickery and a user could connect to either
> one but the machines still could not connect to each other.  (One leg out
> of the triangle)  In that case, the user's client could see the mailbox
> having one message one time and a different message the next even though
> the uid was the same.  So if the client connected, fetched enough info to
> make a message cache list and then disconnected.  If the next time it
> connected to the other machine to fetch the message, the result would not
> be what was expected.
> 
> > What's curious to me is how, with a Maildir format, that IMAP could be
> > implemented to retain that state without either storing some extra data
> > or updating the files in place.  I had thought that real unique message
> > IDs were the same as in RFC 822.  I didn't read RFC 2060 because I had
> > been talked out of implementing my own IMAP daemon.  But I guess I
> > should have read it, anyway, to understand its limitations.  Probably
> > better do that soon before I design something else that can't work :-)
> > 
> > -- 
> > -----------------------------------------------------------------
> > | Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
> > | phil-nospam at ipal.net | Texas, USA | http://ka9wgn.ham.org/    |
> > -----------------------------------------------------------------
> 
> 
> Regards,
> Mark Keasling <mark at air.co.jp>
> 
> 

-- 
Let he who is without clue kiss my ass