Thanks for the commercial software pointers, I am lookng into them and will follow up. If I actually *get* this job, this will become more pressing; right now it is mostly educational.
The basic requirement for mail is that no message should ever get lost. Slow delivery and duplicate delivery are undesirable but not stoppers. A small interruption of POP availability during failover is OK; interruption of inbound SMTP is not acceptable (but won't be a problem in this case) Using rsync could get sticky. With a simple rsync, no matter how frequently you sync'ed you would have the problem of messages that came in after the sync started. Once you failed over to the backup mail server, failing back to the primary would be complicated by needing to check for messages that came in after the last sync. Incoming mail would have to be paused, I'd think. Then, frequent rsync's over a network where different users are using different POP servers would be a big performance hit. And I don't think rsync can't tell the difference between a message that came into machine A since the last sync, and one that was sync'ed from A to B previously and then deleted on B. And it is a hairier problem if the mail is in one big spool file. And, then there's IMAP. Hmmm. I have to think about this, a lot but it almost seems like some sort of staging server is called for, something that could separate synchronization from POP, making sure that everything is backed up before the user sees it. Hmm, but how to then remove the messages that the user has downloaded.... Lots to think about. --- Send mail for the `bblisa' mailing list to `[EMAIL PROTECTED]'. Mail administrative requests to `[EMAIL PROTECTED]'.
