looking for Cyrus mail format documentation

[Rob Siemborski]

Well, for one, this requires change to Cyrus, which Phil doesn't seem to
want to do.

Also, it still doesn't solve the problem of flag changes.

-Rob

On Tue, 4 Feb 2003, Kendrick Vargas wrote:

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

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper