Relocating a Mailbox

Once the user has been selected, the mailbox is migrated. Migration of a user's mailbox can be achieved by the following steps;

1.

Lock the user's mailbox, on the server to which the mailbox will be migrated to. This is to ensure that there is no contention on write access during migration. If the user's mailbox is MBOX and sendmail is used as the MTA, this can be achieved by creating a file MBOX.lock with the same user, group and mode as MBOX.

2.

If the user has an existing alias or user_map entry then remove it. Enter an alias or update the user_map for the user in question and propagate this throughout the mail system. All servers should now send mail for the user to the server to which the mailbox is being migrated to. Mail will be queued up by this server, while the user's mailbox remains locked.

3.

Update the pop map to reflect the new server for the user and propagate this throughout the system. The user will now be collecting mail from the new server, though there is no mail there yet. Note that users who indulge in the irritating habit of leaving mail on the server will more than likely download fresh copies of all messages, once their mailbox has been transfered. In my opinion these users deserve whatever they get.

4.

Lock the user's mailbox, on the mail server that it is being migrated from. If a message is currently being delivered to the user, then this will have to complete, before the lock is obtained. In the case of MBOX.lock semantics, this involves waiting for MBOX.lock to be removed. This shouldn't be too much of an issue as no new messages will be delivered to this mailbox, as a result of the alias or user_map changes that are now in effect.

5.

Transfer the user's mailbox, to the server that the user's mail is being migrated too. This can conveniently be done by using scp, the secure copy programme that is part of the Secure Shell or ssh package. Alternatively, the mailbox could be transfered using SMTP, however, this will add additional headers to the mail and compensation for such transfers will need to be made when calculating server usage.

6.

Remove the mailbox on the server, that the mailbox is being migrated from and relinquish the lock on this mailbox. No more mail should be delivered on this server, for this user.

7.

Relinquish the lock on the user's mailbox, on the server that mail is being migrated to. Mail for the user should now be delivered, on this server.

Once the mailbox has been relocated, the user should be added to a file listing users who were migrated, for use in calculating the decayed metric on subsequent days. The user should then be removed from the list for the server that the mailbox was migrated from and the total metric for this server should be updated accordingly. The list for this server should now been truncated, so that only mailboxes whose removal would not cause the server's metric to fall below the mean metric for all servers are on the list. If this list is empty, then the server is no longer overloaded. The total metric for the server to which the mailbox was migrated to, is also recalculated. If this server is no longer underloaded, then it is not considered for any further migration. Each underloaded server is considered for one migration at a time, in a round-robin fashion, until there are either no more underloaded servers or no more mailboxes suitable for migration.