Como testar e realmente realizar uma transferência de um domínio da Internet para um novo servidor em relação ao correio?

Question

Minha configuração é um servidor produtivo (por exemplo, 1.1.1.1 ) hospedando um domínio, digamos example.com . Atualmente, postfix e courier (apenas IMAP) estão fazendo o trabalho de hospedagem de email. Estou planejando transferir o domínio para um novo servidor (por exemplo, 1.1.1.2 ), também usando o postfix, mas com o dovecot como um novo servidor IMAP. Eu já configurei o postfix em 1.1.1.2 para aceitar todos os e-mails de example.com, que são entregues às caixas de correio e podem ser acessados via IMAP. Todas as contas, incluindo email, são contas de shell. Eu uso o Debian para ambos os servidores.

Na interface web do meu provedor de host virtual, eu posso definir o IP do servidor (registro A) e do servidor de e-mail (registro MX) para example.com . Atualmente, eles estão apontando para 1.1.1.1 , respectivamente server.example.com (o último também resolve automaticamente para 1.1.1.1 ). Não consigo influenciar nenhuma configuração TTL. E não vou alterar meu provedor, apenas alterando a máquina virtual em que o domínio está hospedado.

Duas perguntas:

1. Eu gostaria que meu antigo servidor 1.1.1.1 entregasse todos os e-mails recebidos para o novo servidor 1.1.1.2 para fins de teste (por exemplo, para testar filtros de e-mail, reconhecimento de SPAM etc., pois nem tudo será configurado de forma idêntica) . Esta é uma boa ideia (por exemplo, sobre rejeições, etc.)? Qual é a maneira correta no postfix para conseguir isso (algo como proxy reverso no Apache HTTP Server)?

2. Qual é a melhor maneira de executar a transferência de domínio do servidor antigo para o novo servidor, de modo que o tempo de inatividade seja mínimo (pelo menos durante a transferência da conta IMAP, tenho certeza de que preciso parar todos os servidores de email) e nenhum email é se perder / são adiados? Eu tive a idéia de deixar o servidor antigo encaminhar e-mails para o novo servidor por um certo tempo, de forma que os e-mails também possam ser recebidos de sistemas com cache DNS desatualizado.

De um modo geral, estou procurando uma maneira conveniente e prática de realizar isso. E não sei se minhas idéias sobre as duas perguntas estão apontando na direção correta.

    

Answer 1

Eu fiz isso deixando o servidor antigo 1.1.1.1 encaminhar todas as mensagens para o novo servidor 1.1.1.2 . Usando o postfix no antigo servidor 1.1.1.1 , você pode fazer o seguinte para enviar uma cópia de cada mensagem recebida para o outro servidor:

1. Adicione um destinatário cego em cada mensagem para algum domínio falso. Por exemplo, para [email protected] , um destinatário do BCC [email protected] é adicionado a cada e-mail
2. Configure esse domínio falso para ser entregue ao seu novo servidor. Assim, o e-mail para example.migration é enviado para 1.1.1.2 .
3. Converta esse domínio falso de volta ao normal durante a entrega ao novo servidor. Assim, após a entrega de SMTP, substitua example.migration por example.com .

Para conseguir isso, crie os seguintes arquivos:

• / 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]
  

Agora inclua tudo isso no seu 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

O postfix da versão 2.3 evita os saltos nessa configuração. Assim, se ocorrerem erros no 1.1.1.2 , eles não serão retornados (consulte o link ).

Agora, todos os e-mails são entregues como uma cópia para 1.1.1.2 . Com essa configuração, você pode testar todos os seus itens de migração, como filtros, no novo servidor. Certifique-se de ter /etc/aliases em sincronia.

Para realizar a migração :

1. Faça a configuração acima.
2. Pare o serviço postfix e IMAP nos dois servidores.
3. Copiar caixas de correio do antigo para o novo servidor.
4. Inicie o postfix nos dois servidores, o IMAP no novo servidor.
5. Altere o domínio para apontar para o novo servidor.
6. Os usuários podem acessar suas caixas de correio após a mudança de domínio no DNS.

Para mensagens recebidas, o tempo de inatividade é mínimo, pois elas são apenas adiadas entre as etapas 2 e 3.

    

Answer 2

Para responder ao número 2:

Defina o TTL no registro MX atual para uma configuração apropriada (1 hora pode ser boa). Em seguida, altere o registro MX para apontar para o novo servidor. Em seguida, aguarde uma hora (ou qualquer quantidade de tempo para a qual você tenha configurado o TTL) para qualquer email que possa ser entregue ao servidor antigo (com base em alguns sistemas com o cache MX antigo armazenado) e transfira o email do servidor antigo para o novo servidor.

Depois de alterar o registro MX para apontar para o novo servidor, todos os servidores de email que ainda não tiverem o registro MX em cache (o antigo registro MX) resolverão o novo registro MX imediatamente e enviarão email para ele. Todos os servidores de e-mail que tiverem o registro MX armazenado em cache (o antigo registro MX) continuarão enviando e-mails para o servidor antigo até que o TTL do registro MX expire. Nesse momento, eles realizarão uma nova pesquisa para o registro MX e encontre o novo registro MX e entregue o email lá.

    

Answer 3

Não há como testar completamente, exceto com softwares como o Roundhouse que espelha a exibição para o seu segundo servidor. Este nível de teste provavelmente não é necessário; teste de entrada manual usando telnet deve estar bem.

Depois de confirmar que a entrega (entrada e saída) está funcionando conforme o esperado, você pode fazer uma transferência assim:

1. Defina o postfix no 1.1.1.1 para entregar todos os emails do usuário ao novo servidor 1.1.1.2. Exemplo de configuração: Quando seu sistema é host MX SECUNDÁRIO ...
2. Adicione um novo registro mx para 1.1.1.2 e remova o registro existente. Quando a fila está vazia em 1.1.1.1, o postfix de desligamento força os remetentes a entregarem para novo mx.
3. Mova o acesso do cliente cname de 1.1.1.1 para 1.1.1.2 (os clientes precisam saber que seus e-mails existentes podem não aparecer por algum tempo).
4. Transferir o conteúdo da caixa de correio de 1.1.1.1 para 1.1.1.2
5. Quando o mailqueue de saída está vazio, desligamento 1.1.1.1

O correio será enfileirado nos remetentes por algum tempo se eles estiverem em cache, como diz joeqwerty; na minha experiência, a maioria dos softwares experimenta outros registros mx. Observe que os registros mx devem apontar para os nomes de host reais, não para um cname como mail.example.com. A parte difícil é gerenciar o acesso do cliente; comunicação antecipada para os clientes ajudará.