Migração de Momentum para KumoMTA

O modelo de Tenant, explicado

A contribuição que mais interessa a quem vem de Momentum costuma ser o conceito de Tenant. No Momentum, o controle do envio se governava sobretudo por bindings e grupos de bindings, atados em boa medida aos IPs de origem. O KumoMTA mantém esse nível — com as suas Egress Sources e Egress Pools — e adiciona por cima uma camada lógica: o Tenant, uma entidade que representa, por exemplo, um cliente, uma marca ou uma linha de negócio, e sobre a qual você pode fixar políticas de envio com independência de qual IP ou pool ele use a cada momento. Para um ESP ou uma plataforma que envia por conta de muitos, isso muda o jogo: você pode limitar, priorizar ou isolar o comportamento por cliente sem reorganizar o seu mapa de IPs a cada vez, e raciocinar sobre a entrega em termos de negócio e não só de infraestrutura. É o tipo de controle que no Momentum era preciso improvisar com disciplina e convenções, e que no KumoMTA é uma peça de primeira classe do modelo. Transferir a sua configuração é também a ocasião de usar essa camada para ordenar o que antes vivia disperso.

Onde o KumoMTA vai morar: a porta 25 no Brasil

Sair do Momentum costuma trazer junto uma decisão de onde o motor novo vai viver, e no mercado brasileiro essa escolha tem uma particularidade que convém atender antes de tudo. O KumoMTA roda só em Linux e foi pensado para a nuvem, e ao montá-lo entra em jogo a porta 25: pela Gerência de Porta 25 do CGI.br, as redes residenciais brasileiras bloqueiam a saída por essa porta, que é a que um MTA usa para o transporte entre servidores, deixando a submissão de clientes na porta 587 com autenticação. Por isso o KumoMTA de destino precisa viver em um datacenter ou nuvem onde a porta 25 de saída esteja disponível, e em nuvens como a AWS ela vem bloqueada por padrão e exige uma solicitação para ser liberada, com o registro reverso correspondente. Na própria transferência confirmamos esse ponto e preparamos o DNS reverso de cada IP no novo ambiente, de modo que, no momento da virada, o motor já esteja pronto para sair pela 25 sem surpresas. Vale lembrar a divisão: a porta 587 fica para a submissão autenticada a partir da sua aplicação, e a 25 para o trânsito entre o KumoMTA e os servidores de destino. Esquecer esse detalhe transforma uma migração impecável em um motor que recebe o tráfego mas não consegue entregá-lo.

// Momentum: um binding com os seus throttles (ecelerity.conf, sintaxe estilo C)
binding "pool-a-1" 
  source_ip = "198.51.100.10"
  outbound_throttle_connections = "10/per_domain"
  outbound_throttle_messages = "180/min/per_domain"


# KumoMTA: a mesma intenção como egress source + shaping (Lua + TOML)
egress_sources = {
  ['pool-a-1'] = { source_address = '198.51.100.10' },
}
# shaping.toml — os throttles viram shaping por provedor, TSA reage ao vivo
['default'] connection_limit = 10 max_message_rate = '180/min'

O método é o mesmo; a origem só é mais velha

Quem já tiver visto uma migração de PowerMTA para KumoMTA reconhecerá o método, porque os princípios de uma migração segura não mudam com o motor de origem. A reputação vive nos seus IPs e nos seus domínios, então o objetivo é transferir o envio sem tocar o que os provedores de caixa já conhecem e respeitam. Monta-se o KumoMTA em paralelo ao seu Momentum, traduz-se e testa-se a configuração com tráfego de teste, e verifica-se que a autenticação — SPF, DKIM e o alinhamento de DMARC — se reproduz com exatidão. Depois transferem-se os fluxos por passos, um pool de cada vez, observando a entrega de cada um antes de mover o seguinte, enquanto o Momentum segue enviando o que ainda não foi migrado. A única diferença real com uma migração a partir de PowerMTA é que o material de partida é um ecelerity.conf em vez de uma configuração de PowerMTA; o cuidado e a sequência são idênticos.

Os riscos reais e como os neutralizamos

Toda migração tem riscos, e nomeá-los é a melhor forma de desativá-los. O primeiro é o corte de serviço: neutraliza-se montando o KumoMTA em paralelo e transferindo por passos, de modo que nunca há um instante em que o envio dependa de um sistema pela metade. O segundo é a perda de reputação por enviar a partir da nova infraestrutura sem que os provedores a reconheçam: evita-se reutilizando os seus IPs e domínios atuais e verificando a autenticação antes de mover tráfego, para que a troca seja invisível para as caixas. O terceiro é a tradução incompleta da configuração, que deixaria comportamentos sutis sem replicar: ataca-se entendendo a intenção de cada parte do ecelerity.conf e testando-a com tráfego de teste antes da transferência real. O quarto é o correio preso na transição: gere-se deixando que o Momentum esvazie as suas filas do já aceito enquanto o KumoMTA pega o tráfego novo. Nenhum desses riscos é exótico, e todos se controlam com método e paciência em vez de com pressa.

Verificação: como sabemos que a migração deu certo

Uma migração não termina quando o tráfego passa pelo motor novo; termina quando comprovamos que ele entrega igual ou melhor do que antes. Essa comprovação é deliberada e mensurável. Antes de mover um fluxo, envia-se tráfego de teste pelo KumoMTA e verifica-se que SPF, DKIM e o alinhamento de DMARC passam exatamente como no Momentum. Durante a transferência por passos, vigia-se a entrega de cada pool migrado — taxas de aceitação, diferimentos, bounces e colocação — provedor a provedor, incluídos os locais como UOL, Terra e BOL, e só se avança ao seguinte quando o atual se comporta como deve. Comparam-se as métricas antes e depois para confirmar que a reputação se mantém e que nenhum fluxo perdeu terreno. E deixa-se o monitoramento do KumoMTA em marcha para que qualquer desvio posterior se veja a tempo. Migrar sem essa verificação é cruzar os dedos; migrar com ela é saber, e poder demonstrar, que o correio segue chegando.

Migração e conformidade no Brasil

Sair do Momentum é também a ocasião de pôr em ponto a camada de conformidade, porque ela vive exatamente onde a migração trabalha. Aos requisitos de Gmail, Yahoo e Microsoft — autenticação alinhada, descadastro em um clique, taxas de reclamação sob controle — soma-se no Brasil o CAPEM, o Código de Autorregulamentação para a Prática de E-mail Marketing avalizado pelo CGI.br, que exige bases opt-in ou soft opt-in, envio a partir de um domínio próprio, e um opt-out respeitado em no máximo dois dias úteis pelo link de descadastro e cinco por outros meios, com uma segunda alternativa de baixa não clicável. Além disso, uma migração que mude a hospedagem ou o país de destino traz à mesa a residência dos dados: a LGPD no Brasil, fiscalizada pela ANPD, e o RGPD em Portugal e na Europa marcam princípios que é melhor respeitar de fábrica do que remendar depois. Por isso, ao transferir o seu Momentum, revisamos de passagem que o envio sai conforme do KumoMTA desde o primeiro dia, e desenhamos o destino levando em conta onde os seus dados precisam viver. O projeto que você contrata para trocar de motor resolve, de quebra, o de chegar à caixa cumprindo as regras locais.

Um caminho que outros já percorreram

Há tranquilidade em saber que você não é o primeiro a fazer esta viagem. A saída do Momentum rumo ao KumoMTA é uma rota estabelecida, com remetentes de grande escala que a completaram ao ver que o suporte do seu motor declinava, e com material e ferramentas pensados especificamente para esta transferência. Isso significa que os problemas habituais já estão identificados, que o mapa de equivalências entre conceitos está traçado, e que a migração é um procedimento conhecido, não um experimento. Para um operador que leva anos com Momentum e teme que trocar seja saltar para o desconhecido, essa maturidade do caminho é justo o que rebaixa o risco: o que parecia um salto acaba sendo uma trilha pela qual já passaram plataformas sérias.

Quando convém programar uma migração de Momentum?

Uma migração bem-feita se adapta à sua operação, e não o contrário. Como o KumoMTA se monta em paralelo e os fluxos se transferem por passos, o projeto não exige uma janela de parada nem um fim de semana heroico: o envio segue saindo durante todo o processo, primeiro pelo Momentum e cada vez mais pelo KumoMTA, até que o motor velho fica sem tráfego e se desliga. Isso permite programar a transferência em torno das suas campanhas e dos seus picos, movendo primeiro os fluxos menos críticos para ganhar confiança e deixando os mais sensíveis para quando o padrão já está validado. A pergunta de quando começar tem uma resposta simples: antes que um incidente decida por você, enquanto o Momentum ainda funciona e você pode fazê-lo com calma.

O que precisamos para começar

O arranque é leve. Precisamos entender o seu parque atual de Momentum: o seu ecelerity.conf e a lógica que ele encerra, o mapa dos seus IPs e domínios, os seus fluxos e a sua criticidade, e como a sua plataforma ou a sua aplicação se conecta ao motor. Com isso podemos traçar o plano de transferência, traduzir a configuração e dimensionar o KumoMTA de destino. Não é preciso tocar nada do seu envio em marcha para começar a planejar; o trabalho de desenho ocorre em paralelo, e o seu Momentum segue operando com normalidade até o plano estar pronto e acordado. A auditoria gratuita de 25 pontos é um bom ponto de partida, porque deixa claro o estado da sua autenticação e da sua reputação antes de mover um único IP.

O que acontece com o spool e o correio em fila

Uma dúvida legítima em qualquer transferência é o que ocorre com o correio que já está aceito e esperando nas filas do Momentum quando a migração começa. A resposta é que ele não é abandonado. A transferência por passos permite que o Momentum siga processando e entregando o que já tem no seu spool enquanto o KumoMTA assume o tráfego novo de cada fluxo migrado. Desse modo, nenhuma mensagem aceita se perde na transição: o motor velho esvazia as suas filas com normalidade e só se desliga quando já não lhe resta nada por entregar e não recebe tráfego novo. Coordenar esse esvaziamento com a virada de cada fluxo é parte do método, e é o que evita o cenário temido de mensagens presas entre dois sistemas. Para fluxos com retentativas longas, basta dar ao Momentum o tempo de drenar antes de retirá-lo, uma espera tranquila quando o tráfego novo já vai pelo motor novo.

Depois do desligamento: retirar o Momentum com ordem

O fim de uma migração bem-feita não é deixar o motor velho ligado «por via das dúvidas» de forma indefinida, nem desligá-lo de uma vez no primeiro dia. Uma vez que todos os fluxos enviam pelo KumoMTA e as suas filas estão vazias, o Momentum se mantém um tempo prudente inativo como rede de segurança, e depois se retira com ordem: conservam-se as suas configurações e registros caso sejam necessários para uma consulta ou uma auditoria, liberam-se os recursos que ocupava, e documenta-se o estado final para que ninguém tenha que adivinhar mais tarde o que ficou onde. Encerrar assim evita dois extremos igualmente ruins: arrastar para sempre uma infraestrutura morta que consome recursos e atenção, ou apagar de uma penada algo que ainda poderia ser necessário para entender o passado. A retirada ordenada é a última parte do serviço, e a que deixa a sua operação limpa de verdade.

O que custa ficar no Momentum

Adiar a saída tem um custo que não aparece em nenhuma fatura até ser tarde. O primeiro é de segurança: um motor com desenvolvimento magro recebe menos correções, e cada vulnerabilidade que não se corrige é uma porta que fica aberta na peça que move o seu correio. O segundo é de compatibilidade: os grandes provedores mudam as suas regras com regularidade — autenticação, limites, formatos —, e um motor sem desenvolvimento ativo vai ficando para trás frente a essas mudanças, com a entrega se erodindo aos poucos. O terceiro é de talento: a cada ano há menos profissionais que conheçam Ecelerity a fundo e mais que dominem os motores modernos, então operar Momentum se torna progressivamente mais caro e mais difícil de cobrir. O quarto é de oportunidade: enquanto você mantém com esforço uma peça em retirada, não está ganhando as capacidades que um motor atual lhe daria. Nenhum desses custos dói no primeiro dia; todos se acumulam, e juntos convertem o «depois a gente migra» em uma dívida que se paga com juros no dia em que algo se quebra sem ninguém para consertar.

Migrar antes ou depois de o suporte acabar?

A diferença entre uma migração tranquila e uma migração no desespero é o momento em que se decide. Enquanto o Momentum segue funcionando, você tem o luxo do tempo: pode montar o KumoMTA em paralelo, testar sem pressa, transferir por passos e desligar o motor velho quando estiver seguro. Se esperar que uma falha sem suporte, uma incompatibilidade nova ou um incidente de entrega forcem a saída, perde essa margem e migra com o seu correio de produção na corda bamba. Sair de um motor em retirada é uma dessas tarefas que nunca é urgente até que de repente é, e a essa altura o custo se multiplica. Ajudamos você a fazê-lo no momento confortável, preservando o que importa, sem vender nenhum dos dois motores e cobrando só pela transferência bem-feita. Essa neutralidade importa mais do que parece: um fornecedor que vende o seu próprio MTA tem interesse em empurrar você para ele, e um que revende KumoMTA gerenciado tem interesse em prendê-lo à sua operação; nós ganhamos o mesmo, termine você levando as rédeas ou nos deixando com elas, então o plano que propomos se decide pelo seu caso. E o momento, de novo, é o único que você de verdade controla: hoje o Momentum ainda arranca, ainda entrega, ainda lhe dá o luxo de migrar com calma. Esse luxo não é permanente. Cada mês que passa, o ecossistema se esvazia um pouco mais e o dia do incidente sem suporte se aproxima um pouco. Começar agora converte uma migração em um projeto tranquilo; esperar a converte, cedo ou tarde, em uma urgência com o seu correio de produção em jogo. A escolha não é entre migrar ou não migrar, porque esse encerramento já está escrito; a escolha é entre fazê-lo com calma agora ou à força depois, e só uma das duas protege a sua reputação.