looking for Cyrus mail format documentation

[Phil Howard]

On Fri, Jan 31, 2003 at 08:33:41PM -0500, John A. Tamplin wrote:

| Phil Howard wrote:
| 
| >One of the needs I have is to build a two-way mail store replica.  Either
| >node may be delivered to, and either node may be accessed by the user but
| >only one at a time.  The two nodes are topologically and geographically
| >far apart, and bandwidth between them is to be considered costly and thus
| >should be not much more than the cost of actually transferring content.
| >If mail arrives at one, it should be replicated to the other ASAP.  If
| >mail is deleted at one, it should be deleted from the other ASAP.  If
| >mail is moved around between folders unchanged, it should be moved the
| >same on the other without transferring content.  Now here is the big one:
| >If the two nodes are unreachable between each other, changes have to be
| >stored in a way they can be re-syncronized when reachability is again
| >established.  And this may involve some changes to both and some issues
| >that have to be dealt with as best as possible such as noting dates of
| >changes (it can be assumed the two nodes are time syncronized).
| >
| >This is one of needs I have.
| >
| Then I would suggest a better way of doing that than trying to figure 
| out what changes have happened by looking at low-level data structures 
| would be to put proxies in front of Cyrus (LMTP, IMAP, and if you use it 
| POP).  The proxies would pass the data on to the local Cyrus to do the 
| action as well as contacting the other proxy to duplicate the work.  If 
| the other proxy is not accessible, keep a log of the work that needs to 
| be performed (but allowing disconnected operation when the other node is 
| not truly down will likely lead to changes that can't be automatically 
| resolved -- better would be to have 3, run two-phase commit and only 
| commit if you get agreement of two, but that may not be practical) and 
| do those changes when the other proxy comes back up.  The level of 
| abstraction you want is precisely the level you get at the higher level 
| protocols rather than having to dig through all the folders and see what 
| has changed.

If by proxy in from of Cyrus you mean to implement a layer of IMAP that
is connected to by clients, and then connected to Cyrus on some hidden
port, then I'd say that's not really practical.  That would mean doing
an implementation of IMAP, and it is things like this that I was trying
to avoid in the first place.  I might as well just directly access the
files, and hence have my own IMAP implementation.  But it's to avoid this
that I get so many suggestions to use Cyrus (or Courier) instead.  Doing
the syncronizing at the filesystem later won't be too hard, although a
few hacks are needed (for example deletes are saved as an empty file
with zero permissions, dated when the delete happened, until after the
syncronization clears it everywhere).


| Of course replicating some things such as seen state will be quite 
| painful, and you may need to do some hacks to keep uids unique between 
| the machines.

How does Cyrus manage uids?  I hope these are not uids in /etc/passwd.

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