Instalação e configuração do KumoMTA

Por que a porta 25 de saída precisa ser aberta primeiro?

Um requisito merece ser resolvido primeiro porque sem ele nada funciona: a porta 25 de saída. É a porta que os servidores de correio usam para conversar entre si —o transporte entre servidores—, enquanto a entrega a partir de um cliente corre pela 587 com autenticação. As linhas residenciais costumam bloqueá-la, e as grandes nuvens não são mais generosas: a AWS bloqueia a porta 25 de saída por padrão em todas as instâncias e exige o formulário «Request to remove email sending limitations», com um registro A e DNS reverso anexados, e uma resposta que costuma levar até um par de dias. Outras nuvens têm barreiras parecidas. A consequência direta para quem implanta um MTA: o KumoMTA tem que viver num data center ou numa nuvem onde a porta 25 de saída esteja de fato aberta, com cada IP de envio portando um registro PTR que os receptores possam verificar. Confirmar isso —e apresentar a solicitação de desbloqueio cedo para que o prazo corra em paralelo com o resto da preparação— é o passo um de toda implantação que fazemos, porque um motor que não consegue sair pela porta 25 simplesmente não entrega, por melhor configurado que esteja.

O KumoMTA deve rodar em bare metal, Docker ou Kubernetes?

O KumoMTA é incomumente flexível quanto ao seu lar. A rota clássica é uma instalação a partir de repositório sobre um Linux suportado —Rocky e Ubuntu entre eles—, que deixa um serviço systemd numa máquina que você controla de ponta a ponta. O projeto também publica um contêiner oficial do Docker, e a arquitetura do motor combina bem com Kubernetes para equipes que querem que seu MTA se implante, escale e seja lançado como o resto da plataforma. O critério de seleção honesto não são os números de benchmark —um único nó bem configurado move milhões de mensagens por hora em qualquer dos três— mas a sua realidade operacional: o que sua equipe consiga corrigir, monitorar e recuperar com confiança. Duas notas técnicas condicionam a escolha. O spool quer disco local rápido porque o KumoMTA persiste as mensagens para durabilidade, então um contêiner sem armazenamento é uma ferida autoinfligida. E o vínculo do IP de origem precisa ser projetado com cuidado: em implantações com contêineres e multinó, o padrão limpo é pôr as IPs de saída num proxy que fale o protocolo HAProxy —ou o próprio companheiro proxy do KumoMTA—, de modo que os endereços, e a reputação atada a eles, vivam independentes de qualquer nó. Essa arquitetura decidimos antes de instalar qualquer coisa, porque refazê-la depois significa mover reputação, e a reputação se move mal.

Como o KumoMTA é configurado: init.lua e a pilha de helpers?

O traço que define o KumoMTA é que sua configuração é um programa: a política vive em Lua, executada dentro do MTA, o que dá ao motor condicionais, consultas contra dados ao vivo e lógica que você pode versionar e revisar como qualquer outro código. Uma política de produção não significa escrever tudo à mão. O projeto inclui uma pilha de helpers de política —módulos pré-construídos para shaping, gestão de filas, fontes de saída, assinatura DKIM e domínios de escuta— que consomem arquivos TOML simples, de modo que os botões do dia a dia vivem em arquivos de dados legíveis enquanto a cola Lua se mantém pequena e estável. Nossa implantação usa essa pilha de helpers de propósito: mantém sua política perto do que o projeto documenta e testa, torna as atualizações previsíveis, e significa que quem a mantiver daqui a um ano lerá TOML estruturado em vez de arqueologia. Escrevemos a política, a comentamos, a versionamos no seu repositório e a validamos com a própria ferramenta do projeto —há um validador de shaping na linha de comando justamente para que um erro de digitação nunca chegue à produção. A configuração como código é a característica que torna o KumoMTA poderoso; tratá-la com disciplina de software é o que a torna segura.

# Validar as regras de shaping fora de linha: um erro de digitação nunca chega a uma fila viva
$ kumo-tsa-daemon --validate-shaping /opt/kumomta/etc/policy/shaping.toml
shaping.toml: 142 regras analisadas · 0 erros · 0 avisos
resolve gmail.com → connection_limit=8 max_message_rate=180/min (comunidade + local)

# O que cada provedor faz agora? (D=entregue T=trânsito C=conex Q=na fila)
$ kcli queue-summary
SITE                         D      T   C       Q
gmail.com                 4821    132   8       0
outlook.com               3940     61   5      14
yahoo.com                 2104     40   4       0

# Mover um fluxo envenenado para uma fila mais saudável, regras reavaliadas
$ kcli rebind --domain outlook.com --reason "reset de reputação"
14 mensagens reagrupadas · regras TSA reaplicadas

Fontes de saída e pools: identidade por projeto

O que os operadores do PowerMTA conhecem como VirtualMTAs vive no KumoMTA como fontes de saída e pools: cada fonte é uma identidade de envio —uma IP com seu nome EHLO e seu comportamento— e os pools agrupam fontes para que as classes de tráfego se roteiem, regulem e reputem em separado. Acertar esse projeto no início é a maior parte do que «escalar limpo» significa depois. O correio transacional, que o destinatário espera e abre, não deve compartilhar IPs com o marketing massivo, cujo perfil de reclamações é diferente; uma marca ou um cliente importante pode merecer um pool isolado; e um fluxo novo ou de risco fica em quarentena para que um incidente não arraste o resto. O helper de fontes mapeia atributos da mensagem —campanha, inquilino, classe de correio— ao pool certo, de modo que a segmentação é imposta pela política em vez do hábito. E como as fontes podem vincular através de um proxy, o mesmo projeto viaja de um nó a um cluster sem renumerar nada. Dimensionamos o número de IPs contra o seu volume real —endereços suficientes para que nenhuma pareça agressiva, poucos o bastante para que cada uma construa reputação reconhecível— e documentamos qual fluxo vive onde e por quê.

Shaping por provedor: as regras de cada porta

Cada grande provedor de caixa tem suas próprias tolerâncias —quantas conexões simultâneas, quantas mensagens por conexão, qual ritmo por hora, quando o TLS se complica— e enviar a todos com uma política genérica deixa entrega sobre a mesa. O KumoMTA expressa essas regras em arquivos de shaping: valores padrão globais sensatos, e depois entradas por domínio que afinam limites de conexão, ritmos de entrega e timeouts ao que cada receptor de fato tolera. Duas coisas tornam essa camada mais forte que um throttling artesanal. O projeto mantém regras de shaping contribuídas pela comunidade para os grandes provedores, destiladas por operadores com volume real, que usamos como piso e depois ajustamos à sua reputação e à sua mistura. E o motor resolve as regras por destino com ferramentas para inspecionar exatamente qual política se aplica a um domínio dado, de modo que «o que estamos fazendo com este provedor agora» tem uma resposta verificável em vez de um palpite. O shaping não é uma tabela de pôr-e-esquecer —os limites respiram com a sua reputação—, mas uma implantação que parte do piso comunitário, afinada por provedor, começa educada. Educado é o que a infraestrutura nova precisa ser.

O que é a automação da modelagem de tráfego no KumoMTA?

A peça que separa o KumoMTA dos motores da geração anterior é a automação da modelagem de tráfego. Um daemon independente observa as respostas que o seu tráfego recebe e ajusta o shaping automaticamente contra regras que você define: quando o Gmail começa a responder com sua linguagem de limite de ritmo num limiar que você fixa, a regra pode baixar o ritmo de mensagens dessa rota por trinta minutos; quando um provedor devolve uma assinatura de bloqueio, a regra pode suspender a fila por duas horas em vez de martelar uma porta que se fecha. As regras comunitárias vêm com padrões para exatamente essas respostas conhecidas, e suas próprias regras as estendem. Isto é o backoff como um sistema de primeira classe e observável: a automação roda no seu próprio processo para nunca competir com a entrega, funciona através de um cluster, e cada ajuste é política explícita em vez de um reflexo cabeado. Configuramos essa automação em cada implantação —daemon, cabeamento de publicação/assinatura e regras— porque é a diferença entre um motor que reage à carranca de um provedor em segundos e um que espera um humano ler os registros pela manhã. A tempestade de adiamentos das 3 da manhã se gerencia às 3 da manhã; você lê sobre ela às 9.

Qual DNS e autenticação o KumoMTA precisa antes de enviar?

Antes de a primeira mensagem sair, o DNS e a autenticação precisam estar terminados, porque é aqui que se ganha ou se perde a entrega frente a Gmail, Yahoo e Microsoft em 2026. Cada IP de envio precisa do seu registro PTR resolvendo a um nome coerente com o seu domínio de envio —uma IP sem DNS reverso é uma bandeira vermelha imediata. O domínio publica um SPF que cobre as fontes de envio sem estourar o limite de dez consultas, chaves DKIM que o helper de assinatura do KumoMTA aplica por domínio em cada mensagem, e um registro DMARC que alinha por SPF ou DKIM. O alinhamento é o detalhe que derruba implantações de resto corretas: não basta que SPF e DKIM passem, o domínio que passa precisa coincidir com o que o destinatário vê no remetente. Fechamos e verificamos essa camada antes de o aquecimento começar, incluídas as confirmações chatas que se pulam: que o encaminhamento não quebre as assinaturas onde você possa evitá-lo, que a política DMARC tenha um caminho da observação à imposição, e que cada fluxo que a política assina seja um que você de fato envia. Um motor perfeito enviando correio que retorna por uma autenticação pela metade é a falha mais evitável deste ofício.

Quanto leva o aquecimento de IPs no KumoMTA?

As IPs novas não têm reputação, e os provedores desconfiam dos desconhecidos que aparecem com volume, então a implantação inclui um plano de aquecimento escrito, nunca uma ideia de última hora. A mecânica é pouco glamorosa e funciona: começar com números diários modestos por IP e por provedor, multiplicar em degraus ao longo de quatro a oito semanas, enviar primeiro aos seus destinatários mais engajados para que os sinais iniciais digam que este correio é desejado, e deixar as respostas dos provedores governarem o ritmo em vez de um calendário rígido. O KumoMTA dá ao aquecimento duas vantagens estruturais. O shaping expressa a rampa como limites explícitos por provedor em vez de uma disciplina do lado da campanha que alguém esquece sob pressão. E a automação atua como guarda-corpo de segurança: se um degrau dispara adiamentos ou um pico de reclamações, a automação desacelera essa rota de imediato enquanto o plano se detém e se recupera. Pular ou apressar essa fase é a causa mais comum de que implantações tecnicamente perfeitas entreguem mal nos seus primeiros meses. Preferimos dar a você um arranque um pouco mais lento e uma reputação que aguenta —e pomos esse trato por escrito no primeiro dia, para que ninguém se surpreenda de que a semana dois não seja volume pleno.

Retornos, loops de feedback e monitoramento desde o dia um

O envio saudável se nota em como gerencia o que retorna, e essa maquinaria se configura antes da primeira campanha, não após o primeiro susto. O KumoMTA classifica as respostas com uma taxonomia de retornos rica; nós a cabeamos para que os retornos duros —endereços que não existem— se suprimam de imediato e não se retentem nunca, as falhas suaves retentem com paciência sensata, e os bloqueios por política se tratem com os intervalos longos que merecem. Os loops de feedback dos provedores que os oferecem se registram para que os eventos de reclamação fluam de volta automaticamente, e cada reclamante aterrissa na lista de supressão sem um humano no meio. Insistir em endereços mortos ou relutantes está entre as formas mais rápidas de ensinar aos provedores que você é descuidado; uma implantação que suprime sem piedade desde o dia um se lê como um remetente sério desde a sua primeira semana. A lista de supressão é também onde a conformidade se torna concreta: descadastros honrados dentro dos prazos que as regras de remetentes massivos exigem, e a linha de 0,30 % de reclamações —o limiar em que os provedores agem sem importar a sua autenticação— mantida a distância respeitosa por disciplina de lista em vez de por sorte.

Registros, contabilidade e webhooks fora de banda

Tudo o que o motor faz deixa rastro, e o registro do KumoMTA é feito para os volumes onde os rastros ficam caros: registros estruturados escritos como segmentos JSONL comprimidos, com os campos, a rotação e a retenção sob o seu controle. Versões recentes adicionaram um módulo para ler e escrever esses segmentos diretamente, o que desbloqueia um padrão de implantação de que gostamos muito para operações sérias: o processamento de webhooks e analítica rodando fora de banda, como um processo à parte e longevo com o seu próprio checkpointing, suas retentativas e seus modos de falha, em vez de cavalgar dentro do caminho quente do MTA. A sua plataforma fica sabendo quase em tempo real do que foi entregue, adiado e retornado, sem que o transporte de registros possa nunca frear a entrega. Projetamos essa camada na implantação: quais eventos se registram com qual detalhe, quanto tempo os segmentos se retêm antes de se apagarem ou anonimizarem conforme a lei de privacidade que se aplica a você, e como os dados chegam aos seus painéis. Um motor sem visibilidade acaba surpreendendo você; este é feito para se vigiar, e o deixamos vigilável.

Integração: SMTP, API HTTP e a sua stack

O KumoMTA é a camada de infraestrutura, e encontra a sua aplicação onde ela já está. A rota clássica é a injeção SMTP a partir da sua camada de campanha ou aplicação, aceita num listener que você controla e roteada por política. Ao lado dela há uma API de injeção HTTP nativa para sistemas que preferem falar JSON a um endpoint em vez de manter um cliente SMTP, o que também torna o motor agradável de usar a partir de produtores serverless e dirigidos por filas. Na saída, o fluxo de eventos alimenta webhooks para o estado de entrega, e o motor se conecta com o ecossistema que uma plataforma moderna espera —filas de mensagens como AMQP e Kafka para o transporte de eventos, métricas Prometheus com painéis Grafana para a operação, segredos guardados num vault em vez de em arquivos de configuração, e consultas diretas a dados a partir da política quando as decisões de roteamento precisam de respostas ao vivo. Projetamos as rotas de injeção e de eventos de forma explícita: o que entra onde, autenticado como, e quais eventos os seus sistemas consomem. Bem feito, o MTA deixa de ser uma caixa-preta na borda do diagrama e se torna uma peça comum e observável da sua plataforma.

Segurança: controle de acesso, disciplina de relay e TLS

Um motor de envio é um alvo atraente, e o KumoMTA dá a uma implantação primitivas modernas para fechá-lo —versões recentes adicionaram um framework completo de autenticação, autorização e contabilidade, com controle granular e uma trilha de auditoria sobre cada interação com as APIs do motor. Nós o usamos. Os listeners de injeção aceitam correio apenas de fontes autenticadas e enumeradas, de modo que o clássico desastre do relay aberto fica estruturalmente fora da mesa; a API HTTP e os endpoints de métricas respondem apenas a redes confiáveis; exige-se TLS onde correio e credenciais se movem; e as chaves privadas DKIM vivem com as permissões de arquivo e a disciplina de rotação de qualquer segredo de produção. Em torno do motor aplica-se o endurecimento habitual —serviços mínimos, firewall, sistema operacional corrigido— e a trilha de auditoria significa que «quem tocou o quê» tem resposta. Um MTA comprometido ou permissivo não só envergonha você; gasta a reputação da sua IP no spam de outro e mete você em listas de bloqueio em horas. Essa camada raramente aparece na demo, que é justamente por que nos recusamos a tratá-la como opcional.

Retenção de dados e a lei que se aplica a você

Os registros de entrega são dados pessoais com um relógio em cima. As anotações de contabilidade carregam endereços de destinatário e comportamento, o que faz da retenção uma decisão legal de projeto, não de espaço em disco: sob a legislação de proteção de dados que lhe corresponda —a LGPD no Brasil, o RGPD na Europa, equivalentes na América Latina— você guarda o que precisa pelo tempo que possa justificar, e depois apaga ou anonimiza no prazo. A implantação fixa isto desde o início: quais campos se registram, como rodam os segmentos para que o detalhe nunca encha o disco, e uma política de retenção escrita que a rotação de fato impõe. A mesma previsão cobre o consentimento: construímos infraestrutura de envio apenas para programas baseados em permissão, com listas de supressão que fazem os descadastros colarem, porque nenhuma configuração de motor resgata um remetente que escreve a quem nunca pediu. No Brasil, a LGPD acrescenta direitos do titular e bases legais que uma infraestrutura de envio deve conseguir atender desde o começo, e a política os codifica em vez de confiar que alguém se lembre. A conformidade projetada de entrada é barata; a conformidade acrescentada sob pressão de reclamações não é.

Escalonamento e alta disponibilidade

Um único nó bem construído carrega um volume enorme, mas o crescimento e a tolerância a falhas se projetam, não se improvisam. O KumoMTA faz cluster com limpeza: vários nós kumod repartem o tráfego, o daemon de automação do shaping pode rodar como seu próprio subcluster pequeno para que o tráfego de registros não se entrelace por cada nó, o estado compartilhado como os reguladores pode viver no Redis, e as IPs de saída vinculadas por um proxy sobrevivem à falha de qualquer nó com a reputação intacta em vez de congelada numa máquina morta. O padrão que implantamos mantém a configuração de cada nó idêntica —mesma política, mesmo shaping, seleção de fonte por pool—, de modo que adicionar capacidade é provisionar, não operar. Mesmo que você comece num único servidor, deixamos essas costuras postas: o proxy diante das IPs, a política em controle de versão, o cabeamento da automação pronto para cluster. A versão cara do escalonamento é aquela em que a reputação precisa se mover; a barata é aquela em que a arquitetura já tinha lugar. O dia um é quando essa escolha custa menos.

O KumoMTA vem com um painel de controle?

O KumoMTA não inclui uma interface web, e é uma postura de projeto deliberada: o projeto trata a configuração como código e a operação como APIs, métricas e ferramentas, não a cliques. Para muitas equipes de engenharia isso é justo o correto. Para operações que querem uma camada visual —filas de relance, estado de entrega por provedor, uma interface que um não operador consiga ler— construímos um painel de controle sobre o KumoMTA sem comprometer o modelo de código primeiro que há embaixo: o painel observa e instrui através das mesmas APIs que a sua automação usa, então nunca há uma segunda fonte da verdade. Durante a implantação montamos a base operacional de qualquer forma —painéis, alertas sobre adiamentos, rejeições e sinais de armadilha de spam, visibilidade de filas—, porque um painel é opcional, mas a observabilidade não.

Deveria ser sequer o KumoMTA?

A pergunta honesta antes de implantar é se o KumoMTA é o motor certo para você, e a nossa resposta pode ser não. O seu ponto ideal é volume de saída real com necessidade de controle fino por provedor e por IP, infraestrutura própria, e uma equipe —sua ou nossa— que trate o MTA como um sistema de produção. Para volumes modestos, um MTA convencional bem afinado ou um relay na nuvem cobre o caso com menos superfície a operar. Se você já roda o PowerMTA satisfeito sob licença, a mudança é um cálculo, não um reflexo —expomos essa conta na página de migração e estamos igualmente à vontade com qualquer dos dois resultados. E quando o campo está de fato aberto —KumoMTA, PowerMTA, Halon, MailerQ— tratamos como um exercício de seleção de MTA com o seu interesse à frente, porque não revendemos nenhum. A implantação mais barata é a que você não precisava; preferimos dizer isso a construí-la.

Que aspecto tem «terminado»

Uma implantação está terminada quando se sustenta sozinha e se entende sem nós. Em concreto: as IPs aquecem segundo um plano escrito a bom ritmo; o DNS e a autenticação passam e alinham para cada fluxo; as fontes e os pools separam o correio por natureza, com shaping por provedor que parte do piso comunitário e se afina ao seu; a automação reage ao empurrão dos provedores de forma automática e visível; os retornos se processam, os endereços mortos se suprimem sozinhos, os loops de feedback estão cabeados; os registros fluem aos seus painéis com a retenção imposta; o controle de acesso e o TLS estão ativos, com trilha de auditoria atrás das APIs. E tudo está documentado —como está construído, por que se tomou cada decisão, o que tocar quando algo muda— com a política em controle de versão. Uma implantação que só funciona enquanto o seu construtor estiver localizável não está terminada; é um repasse que ainda não aconteceu. Damos o projeto por encerrado quando a sua equipe, ou o nosso serviço gerenciado, consegue operá-lo sem folclore.

Como se desenrola uma implantação do KumoMTA, passo a passo?

Começamos com a auditoria gratuita de 25 pontos, que confirma que o motor encaixa e fixa o estado de partida do DNS, das IPs e da autenticação. Daí, o trabalho segue a ordem que esta página descreve: confirmar a porta 25 de saída e apresentar cedo o desbloqueio da nuvem; preparar e endurecer o host —ou a plataforma de contêineres— e decidir a arquitetura de vínculo de IPs; fechar DNS, autenticação e alinhamento; instalar a partir de repositório ou contêiner e assentar a política com a pilha de helpers; projetar fontes, pools e shaping por provedor desde o piso comunitário; cabear a automação da modelagem de tráfego e validar cada arquivo de shaping com a ferramenta do projeto; conectar o processamento de retornos, os loops de feedback, a supressão e o monitoramento; escrever o plano de aquecimento; e depois arrancar a rampa sob vigilância diária. A preparação e a configuração costumam levar dias ou um par de semanas conforme o seu ambiente, com o prazo da porta 25 correndo em paralelo; o aquecimento acrescenta depois quatro a oito semanas até o volume-alvo com uma reputação que aguenta. No fechamento, você recebe a instalação documentada para que a sua equipe a opere, ou seguimos operando-a como KumoMTA gerenciado. A infraestrutura é sua o tempo todo, e a relação fatura por trabalho, sem um motor a vender do outro lado da mesa.

Se você está planejando uma implantação do KumoMTA —primeiro MTA, capacidade nova ou a reconstrução de algo que nunca acabou de funcionar—, o ponto de partida não custa nada: a auditoria de 25 pontos confirma o encaixe e o estado do seu DNS, das suas IPs e da sua autenticação antes de construir qualquer coisa. Daí, nós o implantamos como operamos o nosso: modelado, aquecido, vigiado e por escrito.