Changing how your organisation handles it's email is often an area that people are wary of changing. Email has become such a business critical service, that the shortest loss of service can be catastrophic.

For this reason, many companies carry on with an email service which doesn't meet their bandwidth or other requirements.

Moving your mail from one supplier to another can be a complicated process, but with carefull planning can happen very smoothly. Before discussing how the changeover can happen though, it is usefull to have an overview of how internet mail is actually delivered.

This is a high level overview, so some of the complexity has been eliminated, but the general principles are sound.

SMTP

All internet email is transferred through the internet as SMTP (Simple Mail Transport Protocol) formatted streams of information. From leaving the senders mail server, it is transmitted via any intermediate stages using a 'store and forward' method. Quite often though, the mail is delivered directly to it's destination in one jump - it all depends of the configuration of sending and receiving mail systems.

Internet Name Resolution - DNS

Before the sending mail server can send the mail, it first needs to know where to send it. To do this, it needs to take the email addresses suffix (the bit after the @ sign), and check against what is basically the internet phone book. This phone book is called DNS (Domain Name System), and is the same system used to find out where your favourite web site (www.consilium-uk.com) is located on the web.

To handle the vast number of domains on the internet the DNS system works by splitting up the virtual phone book into smaller chunks, and distributing these around the internet on DNS servers. Therefore, there are only a couple of servers in the world that have all the details of the consilium-uk.com domain, and these servers are know as 'authoritative servers for the consilium-uk.com domain'.

So how do you find these servers? Well all DNS servers are linked in a heirarchy, with each part of the domain name between the '.' forming the heirarchy.

Fig 1: DNS Heirarchy

Every DNS server knows about the root servers and the server immediately below it in the heirarchy. To find details about 'consilium-uk.com' you would first go to the root servers. The root servers would see that the domain name had 'com' at it's first level, and pass you onto one of the 'com' DNS servers. It would check the second level, and pass you to the 'consilium-uk' server. You could then ask that server where to deliver the mail.

DNS Caching

If you had to work down the heirarchy every time, the servers at the higher levels would start to become overloaded. To help stop this from happening, DNS servers usually cache any information they are given for a period of time. Taking the previous example, if you had just queried consilium-uk.com, and then queried microsoft.com, you could start from the 'com' DNS server, missing out the root. If you needed more information about 'consilium-uk.com' you could go directly there, or if you had to deliver more mail, you wouldn't even need to check DNS, as you already know the answer

This leads to a problem if you need to change information. Although you may change the details on consilium-uk.com, there are likely to be a large number of DNS servers throughout the internet which have a cached answer, and therefore don't check for an update.

This caching is dependant on how the DNS server was set up, but times of up to 10 days are possible.

Changing DNS Entries

Because of the way DNS operates, the only way to ensure that you don't have loss of service during the transitional period is to continue to receive mail as you have before, while also receiving mail from your new provider. All outgoing mail, however, can immediately be sent via your new provider.

The technicalities of how you configure your mail system to use both ISP's simultaneously is different for virtually every scenario. A couple of examples are outlined below:

1) Leased Line Connection to New Leased Line Connection

Your incoming internet connection is probably entering you network via a router or firewall. As it passes through the router, a service called Network Address Translation (NAT) translates the IP address given by internet DNS to the internal IP address or the mail gateway on your network.

When the new connection is added, this again will probably be connected through another router or firewall. The router should be able to use NAT to translate the new IP address given by your ISP to the same internal IP address or your mail server as before. That means that mail coming in from either ISP will arrive at your mail server. You can then configure your network (or in some cases your mail gateway as well) to start to use the new ISP connection as it's preferred outbound connection.

Once you are sure that no more mail is being delivered via your old connection, usually after a two week period to ensure all DNS replication has occcured, the old connection can be decomissioned.

2) Dialup Access to Leased Line Connection

Incoming mail will probably be delivered to a Mail Relay Host (MRH) or POP3 mailbox on your ISP's side of the network. Your mail gateway will then connect to this at given times to download any mail. Outgoing mail will be configured to be delivered via your ISP's outgoing MRH.

When the new connection is put in place, you will need to configure the inbound NAT as in example 1. Incoming mail can be left as is. However, outgoing mail will probably require some reconfiguration at the mail gateway to ensure that it transfers out via the new connection. During the transition, it is often usefull to configure the systems to deliver mail via both routes, given resilience during the migration, but this is dependant on the mail server and mail gateway that you have in place.

Again, once the DNS changes have propogated, you can again reconfigure your gateway to stop dialing up your old ISP, and the transfer will be complete.