looking for Cyrus mail format documentation

[David Lang]

you stated that you want to have the outside box act as a secondary MX for
the inside one, if you do this and accept the extra bandwidth used then
you could still do this and have the mail only delivered to the inside box
and then replicated out to the outside one.

this doesn't solve the problem of changing flags, but does solve the
problem of getting the messages in correctly.

for the flags the real question is do you HAVE to allow them to be updated
when the primary can't be reached? or can your users tolorate being able
to see their mail, but not have the flags change if you have a connection
problem? (or possibly allow some flags to be changed and queued up, seen
flags can be reconsiled by changing both sides to the the or of the two
when they reconnect, deletes can be queued and processed later, etc)

there are some useage patterns here that can narrow the scope of the
limitation more then the generic database two-way-sync problem

David Lang

 On Tue, 4 Feb 2003, Phil Howard wrote:

> Date: Tue, 4 Feb 2003 03:19:12 -0600
> From: Phil Howard <phil-info-cyrus at ipal.net>
> To: Rob Siemborski <rjs3 at andrew.cmu.edu>
> Cc: info-cyrus at lists.andrew.cmu.edu
> Subject: Re: looking for Cyrus mail format documentation
>
> 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.
>
> 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/    |
> -----------------------------------------------------------------
>