looking for Cyrus mail format documentation

[Phil Howard]

On Tue, Feb 04, 2003 at 07:20:57PM +0900, Mark Keasling wrote:

| 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.

I guess moving them all as a group would help retain the apparent order.


| 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.

The intent was to have a faster machine for road warrier users to connect
to while the office is connected via a slow 28.8k analog modem.  The idea
is to avoid overloading the 28.8k line.  And to further help doing that,
the outside server would be the internet's MX host (fallback to the inside
server anyway), whereas the intranet would see the MX hosts the other way
around.  Mail from the internet would be delivered on the outside server
and replicated in.  Mail from the intranet would be delivered on the inside
server and replicated out.

One thing I was thinking of would be a hack to make one server always use
only odd UIDs, and the other always use only even UIDs, and to do catchups
while they are reachable with each other.  But this is getting into hacking
code I know nothing about, yet.  Maybe a later time.

My original design was for a Maildir based mailstore, and would work at the
file replication level (somewhat like rsync, but with some differences to
handle it two-ways).

-- 
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam at ipal.net | Texas, USA | http://ka9wgn.ham.org/    |
-----------------------------------------------------------------