Meus artigos: Passos para migração de servidor de email
De Ramoni
Conteúdo |
Introdução
- Migrar um domínio de um servidor de emails para outro não é uma tarefa complicada quando bem planejada.
- Para que a migração seja tranquila, alguns aspectos devem ser observados. Todo administrador de um sistema de emails deveria saber de todos os detalhes envolvidos que vou citar, mas se todos os administradores fossem administradores de verdade, o email na Internet não estaria o caos que está hoje.
- Tentarei explicar a coisa de forma que independa se o servidor antigo está sob seu controle ou não, assim como o servidor DNS. O que importa é que os passos sejam seguidos.
- Para o exemplo, usarei o domínio example.com
Preparação do ambiente
- TTL do domínio
- Qual o TTL do domínio ? O TTL é o tempo em que os registros de um domínio podem ficar em cache dos outros servidores DNS, e isso é configurado no servidor do próprio domínio. Seria bom que o TTL fosse configurado para algo do tipo 1h, com intuito de minimizar o tempo que levará para outros servidores DNS ficarem cientes da mudança. Se o TTL está em 2 dias por exemplo, configure para 1h e somente daqui a dois dias continue a mudança no registro MX (para ter certeza de que ninguém mais possuirá o antigo em cache, a não ser por no máximo 1h após a mudança).
- IP do servidor novo
- É uma mudança entre diferentes provedores ? Não importa. O que importa é o IP a ser utilizado para a saída de email do domínio. O servidor de saída de email para o mundo será alterado ?
- Se for, é importante verificar o seguinte:
- - O novo IP de saída está em alguma DNSBL ? Consultar www.rbls.org é uma boa idéia. (esta preocupação não se restringe somente no momento de migração ou configuração de novo domínio. Um administrador deve sempre checar se algum dos seus servidores está nessas DNSBLs)
- - O IP de saída possui reverso no DNS do bloco de IPs ? Lembre-se que nem sempre o servidor de DNS reverso é o mesmo do domínio. Se você não tem um range IP classe C, certamente a configuração de reverso deve ser feita por seu backbone.
Mudança no DNS
- Se você tiver um filtro anti-spam que recebe os emails da Internet e depois repassa para o servidor final, ótimo. Assim fica mais suave a migração. Se você não possuir, e o servidor novo será o único ponto de entrada de emails para o domínio, também dá.
- A idéia é ter um servidor de emails sob seu controle que nele seja feito o "chaveamento" na troca do servidor, em vez de ser pelo DNS.
- Configure este servidor para ao receber emails para example.com, encaminhe para o servidor antigo (o ainda em vigor). Não há problema caso este servidor vá ser o futuro servidor final do domínio, basta que por hora, ele encaminhe.
- Configure no DNS, o MX do domínio para apontar para este servidor. Deste momento até dentro de 1h, TODOS os emails deverão checar por este servidor, e não mais pelo antigo. A parte do DNS acabou.
- Mas porquê não criar as contas no servidor novo e somente depois mudar o MX no DNS ? Porque de qualquer forma, quando você criar o domínio no servidor novo sem o encaminhamento para o antigo, os emails dos domínios hospedados neste servidor com destino ao domínio que está sendo migrado já cairão nas caixas novas, e se todas as caixas ainda não estiverem criadas, emails serão retornados. É apenas um detalhe para evitar que hajam problemas na migração, e por isso, somente deixar o servidor novo receber emails do domínio quando ele estiver com todas as contas e nenhum email novo deva ir para o antigo.
Mudança de servidor
- Ok, depois de um tempo teremos todos os emails da Internet chegando no filtro anti-spam ou no servidor final (caso seja o único), e sendo redirecionados para o servidor antigo.
- Mude o redirecionamento para o servidor novo, ou apenas retire o redirecionamento no caso de servidor único. Neste ponto, você deve fazer com que as mensagens cheguem diretamente no servidor novo.
- Neste mesmo momento, configure o servidor antigo para redirecionar os emails para o servidor novo. Não exclua as contas ainda, apenas certifique-se de que não haja mais entrega local para as contas deste domínio, e sim que redirecione para o novo servidor.
- Este redirecionamento é importante porque podem existir alguns casos em que alguém por algum motivo ainda esteja enviando emails para este servidor, e não para o MX novo que já está no DNS faz horas.
Configuração dos clientes
- Oriente ao cliente neste momento que dê a última checada de emails na configuração atual, e por isso é importante que as contas ainda não tenham sido removidas do servidor antigo.
- Após a checagem, oriente-o a mudar as configurações necessárias para o servidor novo. Não há risco de novas mensagens chegarem no servidor antigo se você fez o redirecionamento para o servidor novo que citei anteriormente.
Configuração no servidor antigo
- Quando TODOS tiverem checado seus emails, remova as contas do servidor antigo (fazendo backup se quiser).
- Analise nos logs se ainda chegam emails da Internet para o domínio. Não deveria. Se houver, mantenha o redirecionamento.
- Alguns servidores guardam em cache o MX mais tempo do que o TTL autoriza, e por isso causam problemas em migrações. O redirecionamento vai te salvar quanto à isso.
- Bom, você não pode ficar com este redirecionamento para sempre, pois não há mais motivos para alguém entregar emails para o domínio no servidor antigo. :Retire o redirecionamento e crie um mapa de relocated avisando que a conta não está mais neste servidor (é para isso que o relocated serve).
Coclusão
- Bom, é isso.
- Claro que, para um domínio bem pequeno e sem muita importância, você pode fazer tudo descoordenadamente. Pode criar as contas no novo e depois trocar o MX e logo depois remover do antigo. Isso tudo as 03:00 de um domingo.
- O que eu tentei expor é como eu faço uma migração tentando evitar problemas no caminho.
- Migração das contas de email de passwd, vpopmail, exchange ou mysql estão fora do escopo deste docomento.
- Migração dos dados (emails) também estão fora do escopo deste documento. Existem outros HOW-TOs de migração de mailbox->maildir etc.
- Quaisquer sugestões: andre.ramoni@gmail.com
