Best (Safe) way migrating mail server to a new One

mehargags

Hi all,

I'd like to know the best way forward when migrating mailboxes (in bulk) for a particular client's domain. I'm not concerned about the data, but rather how to make /offer new passwords to them ? I have the list of user mailboxes in CSV which I should be able to make user's with, but setting them all same default a password can be "Wrong".

(I've setup ISPconfig on the new mail server.)

Let me know what comes to your minds...esp. @Jar, pls enlighten!

4n0nx

Just export the database? What mail server software? Postfix/Dovecot?

A longer while ago I migrated from text based to database based Postfix/Dovecot. The passwords were saved like [email protected]{CRAM-MD5}longhashhere , so it was fairly easy to let users log in one time with their original password and to then insert a new password into the database (SHA512).

//EDIT: The inboxes I simply synced with rsync

tommy

No need to change user password.

Lower DNS TTL if you change IP address

1. sync all of email files from old server to new one including mail configuration (you can tweak that configuration later)
2. stop mail services on old server (ex. postfix and dovecot)
3. change A record to new IP
4. test by send few email to different mail server (gmail, yahoo, hotmail, etc).

done.

I've using this many times but only on Postfix, Dovecot, MySQL machine.

mehargags

Well, I'm using Axigen, but I guess under the hood it used postfix only.
Its on Centos 5.1

What would be the usual path to look for the DB to be backed ?

4n0nx

mehargags said: What would be the usual path to look for the DB to be backed ?

That depends entirely on how you set it up. I assume there must be either a text file or a database containing the hashed passwords somewhere.

I know nothing about axigen, but the demo web panel looks like it has an export/import function somewhere..

mehargags

yes it has a Python script for exporting account list, but the passwords can't be exported. (atleast that's what is listed on forums)

jar

Yeah, this is a process that is going go vary greatly even with systems using the same MTA/LDA. I mean you can take for example a cPanel/VestaCP environment where the primary user is in /etc/shadow and the others are dropped in a passwd file in the account's home folder, or take another example where the accounts are all outlined in the database. Each one is going to be a very different approach.