How to test and actually perform a transfer of an internet domain to a new server regarding mail?

Solution 1:

I did this by letting the old server 1.1.1.1 forward all mail to the new server 1.1.1.2. Using postfix on the old server 1.1.1.1, you can do the following to send a copy of each incoming mail to the other server:

  1. Add a blind recipient in each mail for some bogus domain. E.g., for [email protected] a BCC recipient [email protected] is added to each mail
  2. Configure this bogus domain to be delivered to your new server. Thus, mail for example.migration is delivered to 1.1.1.2.
  3. Convert this bogus domain back to normal during delivery to the new server. Thus, upon SMTP delivery replace example.migration by example.com.

To achieve this, create the following files:

  • /etc/postfix/migration/recipient_bcc_map:

    /^(.*)@example\.com$/ [email protected]
    
  • /etc/postfix/migration/transport_map:

    example.migration smtp:[1.1.1.2]
    
  • /etc/postfix/migration/smtp_generic_maps:

    /^(.*)@example\.migration$/ [email protected]
    

Now include all this into your main.cf:

recipient_bcc_maps = pcre:/etc/postfix/migration/recipient_bcc_map
transport_maps = hash:/etc/postfix/migration/transport_map
smtp_generic_maps = pcre:/etc/postfix/migration/smtp_generic_maps

Postfix from version 2.3 on avoids bounces in this configuration. Thus, if errors occur on 1.1.1.2, they are not returned (see http://www.postfix.org/postconf.5.html#recipient_bcc_maps).

Now all mail is delivered as a copy to 1.1.1.2. With this setting you can test all your migration stuff like filters on the new server. Be sure to have /etc/aliases in sync.

To perform the migration itself:

  1. Do the above setup.
  2. Stop postfix and IMAP service on both servers.
  3. Copy mailboxes from old to new server.
  4. Start postfix on both servers, IMAP on the new server.
  5. Change domain to point to new server.
  6. Users can access their mailboxes after domain switch has spread in DNS.

For incoming mail the downtime is minimal as they are only deferred between step 2 and 3.

Solution 2:

To answer number 2:

Set the TTL on the current MX record to an appropriate setting (1 hour might be good). Then change the MX record to point to the new server. Then wait an hour (or whatever amount of time you set the TTL to) for any email that might be delivered to the old server (based on some systems having the old MX record cached), and then transfer the email from the old server to the new server.

Once you change the MX record to point to the new server, any email servers that don't already have the MX record cached (the old MX record) will resolve the new MX record immediately and send email there. Any email servers that do have the MX record cached (the old MX record) will continue to send email to the old server until the TTL of the MX record expires, at which time, they'll perform a new lookup for the MX record and find the new MX record and deliver email there.

Solution 3:

There is no way to test compleately except with software like Roundhouse that mirrors delivery to your second server. This level of testing probably isn't neccessary; manual inbound testing using telnet should be fine.

After you're sure delivery (inbound and outbound) is working as intended you can cutover like this:

  1. Set postfix on 1.1.1.1 to deliver all user mail to the new server 1.1.1.2. Example config: When your system is SECONDARY MX host...
  2. Add a new mx record for 1.1.1.2 and remove existing record. When the queue is empty on 1.1.1.1, shutdown postfix forcing senders to deliver to new mx.
  3. Move client access cname from 1.1.1.1 to 1.1.1.2 (clients need to know their existing mail may not appear for a bit).
  4. Transfer mailbox contents from 1.1.1.1 to 1.1.1.2
  5. When outbound mailqueue is empty, shutdown 1.1.1.1

Mail will be queued at senders for a bit if they are caching as joeqwerty says; in my experience, most software will try other mx records. Note that the mx records should point to actual host names, not a cname such as mail.example.com. The hard piece is managing client access; early communication to customers will help.