I am moving my existing IMAP services to a third-party, specifically FastMail. I started this process back in March 2017 when I signed up with FastMail. I did a mail migration then, but never proceeded. At present I am hosting my own IMAP server, via Dovecot, RoundCube, and Postfix, running in a FreeBSD jail.
I got out of running a public incoming mail server back in 2010. It has been nearly 9 years now that Google has acted as my first line of defense for spam protection. They have done that well. They then forward my mail to a Postfix server which is tightly firewalled off from the rest of the world.
Dovecot has long been my IMAP server of choice, and I will continue to use it as a warm-standby. More details about that in future post.
My FastMail account has sat idle for two years and I was happy to pay them, because I like what they do.
Now I have reached the point of not wanting to run an IMAP server any more. If my server goes down, I still need my email, and I’m sure FastMail can do that better than I can. I will still perform backups of my mail, but they will be my primary mail provider.
I like the way I can configure my domains at FastMail. For $50 a year I can use up to 100 domains. Sounds good to me.
I was in the process of moving my IMAP server to another more power host. The current host has 8GB of RAM and runs several jails (including bsdcan.org & pgcon.org). The host is under pressure. I was nearly ready to complete the move when I starting thinking about putting this on FastMail instead.
Several steps
I see the migration as several distinct steps:
- Create and configure your FastMail account (done).
- Sync your mail (I used their service, but then I ran imapsync two years later).
- Add forwarding for email at your existing service. This way you won’t miss any messages as the DNS changes propogates.
- Adjust your DNS with the new MX values
- Wait for mail to start flowing in
I will only outline some of these steps and it might not have sufficient detail for you. Please read the original docs as well.
Sync your mail
I originally used the service provided by FastMail. It worked. Then I wanted to use imapsync.
My command was something like this:
/usr/local/bin/imapsync \ --host1 mailjail.example.org --user1 dan --passfile1 /usr/home/dan/imapsync/mailjail.password \ --host2 imap.fastmail.com --user2 dvl@example.com --passfile2 /usr/home/dan/imapsync/fastmail.password \ --automap --ssl1 --ssl2 --addheader
–host1 is the source
–host2 is the destination
–user1 and –passfile1 are the credentials for –host1 – be sure the file not world readable.
The rest of the arguments should make sense if you read up on them.
The first sync took many hours, as it had two years of email to catch up.
The second sync took 140 minutes.
The third was 40 minutes.
Add forwarding
I started forwarding email from my old host to my new host after my first imapsync. I wanted to be sure that my filtering was correct. I was moving from maildrop to sieve and wanted to have some run-in time with them. sieve is a language for filtering e-mail and is available on FastMail; they also have a GUI interface.
How you do the forwarding varies, but what you forward do is pretty straight forward: use the FastMail Forwarding tunnel.
Adjust your DNS with the new MX values
I reduced the TTL on my MX records first. This will help the changeover. It will go faster. Theoretically.
FastMail has great documentation. You can use one of FastMail’s many domains, or use your own domain. FastMail refers to the latter as Custom Domains. From that page, I selected Nameservers hosted elsewhere, but MX records pointing to FastMail. That took me to Configuring your domain with MX only.
For each of my domains I will set my MX records to:
- in1-smtp.messagingengine.com
- in2-smtp.messagingengine.com
This is the script I will use for setting the new MX values:
$ cat set-MX-for-FastMail-nsupdate
#!/bin/sh
echo starting ${DOMAIN} with ${TTL}
/usr/local/bin/nsupdate -k ${KEY} -v<<EOT
server ${SOA}
zone ${DOMAIN}
update delete ${DOMAIN}. IN MX
update add ${DOMAIN}. ${TTL} IN MX 10 in1-smtp.messagingengine.com.
update add ${DOMAIN}. ${TTL} IN MX 20 in2-smtp.messagingengine.com.
send
EOT
echo done
I will use it in conjunction with the scripts I created yesterday for dropping the TTL.
Testing delivery before MX changes
I decided to test delivery of at least one test mail before changing my MX records. The purpose is to first verify that the provider will accept mail for that domain.
smtp is just that: simple. So simple you can use telnet.
Here we go. What I typed in in bold.
[dan@mailjail:~] $ telnet in2-smtp.messagingengine.com 25 Trying 64.147.123.52... Connected to in2-smtp.messagingengine.com. Escape character is '^]'. 220 wmx2.messagingengine.com ESMTP mx. No UCE permitted. helo mailjail 250 wmx2.messagingengine.com mail from:dvl@example.com 250 2.1.0 Ok rcpt to:dan@example.org 250 2.1.5 Ok data 354 End data with. testing to dan@example.org . 250 2.0.0 Queued as 5749C162D48 quit 221 2.0.0 Bye Connection closed by foreign host. [dan@mailjail:~] $
In this example, I am sending email to dan@example.org from dvl@example.com.
With that, I’m confident enough to change my MX records.
Changing the MX
I did one domain first, verified mail flowed, then did them all. It just worked.
I wrote up this script to drive the one I mentioned earlier:
$ cat set-MX-for-FastMail
#!/bin/sh
. ./config
for domain in ${DOMAINS}
do
export DOMAIN=${domain}
./set-MX-for-FastMail-nsupdate
done
I will run that script again, to bump the TTL. I kept the new MX low, at 180, in case I had to revert my MX changes.
So far, so good.
Hope this helps.
