looking for Cyrus mail format documentation

[Mark Keasling]

Hi,

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>