looking for Cyrus mail format documentation

Phil Howard phil-info-cyrus at ipal.net
Thu Feb 6 02:38:10 EST 2003


On Tue, Feb 04, 2003 at 09:35:34PM -0800, David Lang wrote:

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

That would result in doubling the bandwidth on the inside server connection
since it would be dealing with the mail first coming in to the MX, then
being replicated back out to the other server.  By delivering outside mail
to the outside server first, the only bandwidth usage is replicating to
the inside server (reverse the scenario for mail originating inside).


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

If there was a way to track when the flags got changed.  I feel it's OK
to trust the clocks on the servers, and simply decide which flag state
prevails based on which has the later timestamp.  But I bet that metadata
isn't in the current mailstore design.

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




More information about the Info-cyrus mailing list