Geographically Redundant mail stores

Michael Fair michael at daclubhouse.net
Tue Mar 18 18:58:59 EST 2003


> On Tue, 18 Mar 2003, Michael Fair wrote:
>
> > I'm doing some work on how to create a somewhat
> > reliable geographically redundant mail system.
>
> Since I'm guessing you don't want to hear the reasons that this won't work
> (synchronizing UIDs and flags, for example, is hard), I won't go into
> that.


Thanks.  I've given up on trying to provide a perfect/correct
solution.  Instead I'm shooting for something more along the
lines of being able to look at a live backup and then synchronizing
any new mail that comes in.  State flags and other things above
and beyond the email messages themselves are not a concern (but
would be nice to have).

The main problem is just that if the main server is ever unavailable
communications come to a grinding halt.  Since we have people
outside the office as well as in, we wanted some way for them to
at least continue to send/receive new mail.

I've been thinking about this problem for some time, and at the
moment the best concepts I have going are:
1) Use Cyrus 2.2 and have the NNTP server sync the mailboxes.
   (This does nothing for state flags and probably will not
    help with the creation/deletion of new folders)
2) Create a "file locking server" that replaces the file
   locking calls with something that is cross machine compatible
   then use Coda, Intermezzo, or NFS to mirror the file store.
3) Turn Cyrus on the backup server off, use rsync to copy all
   the files from one server to the other (making the UID/GIDs
   match on the two servers shouldn't be a problem), then in the
   event of a failure activate the Cyrus server, then flush the
   MTA queue to deliver the queued mail to Cyrus (the queued mail
   will that which has been delivered since primary failure).
   It would look like I restored from a backup (which wouldn't
   be too far from the truth).
   (This is just admin intensive, and slow, and assumes that an
    admin will always be available to manually make the changes)
4) Enhance Mailsync which does a good job at synchronizing
    the mail stores for an individual user to do an entire
    mail store.
    (Without enhancement it needs to be setup per user.)
    (With enhancment, by default an administrator cannot read
     the emails within users mailboxes and therefore cannot
     sync them)
5) Wait for people smarter than myself to add redundancy to
   Cyrus directly (perhaps with a Group Communication Library
   like Spread or something similar).




>  Instead I'll answer your main question directly.

> > My question was that the only user I know that
> > can see the whole tree is an admin user.  But
> > by default admin users can't select the mailboxes
> > because they don't have the proper permissions.
>
> Admin users can authorize as any user they want.  So simply have the admin
> user authorize as each user, and they can get to that mailbox with no
> trouble.
>
> Note that if you SELECT a mailbox as a user, it *will* change the state of
> \Recent flags for the user.

Is there a reliable way to query the known list of users?
I thinking of big loop:
    foreach $user (@users) { syncMailbox($user); }

I suppose I could just use the output of saldblistusers
as STDIN input to the perl script (or the perl script
could run it directly) since that's the backend I use.
Or doing a List of the "user" folder one level deep.


Any other ideas?

How would you do it?

The problem is:
When the primary mail site is down, all email communication
ceases despite the availability of other sites that could
handle the load.

In addition to allowing sending/receiving of new email,
The system must integrate any new mail back into the main
    site when it becomes available again.
The system should allow people to see all their email and
    folders older than some sane value (like 1 hour prior
    to main site failure (shorter times preferred)).
The system may (as added bonus points and extra special
    kudos) preserve flag states for users email.

Just as an FYI, the systems are Debian servers running
Henrique's amazingly wonderful packages.
The servers are Cyrus 2.1, Postfix 1.1.11, both integrated
with sasldb for Authentication (SMTP AUTH is only allowed
during a TLS session with Postfix - not that it matters).
Site A has a 4MB link, Site B has 1.5MB link.

-- Michael --





More information about the Info-cyrus mailing list