Instalação e configuração de PowerMTA

A porta 25, e a gerência de porta no Brasil

Há uma peça que no Brasil precisa de atenção especial antes de qualquer outra coisa: a porta 25. Pela Gerência de Porta 25, o conjunto de políticas que o CGI.br e o NIC.br promoveram através da Resolução CGI.br/RES/2009/002, as redes de acesso residenciais brasileiras bloqueiam a saída pela porta 25, deixando-a reservada ao transporte de mensagens entre servidores; a submissão a partir de um cliente passou à porta 587 com autenticação. Essa medida tirou o Brasil dos primeiros lugares do ranking de países que mais emitem spam, e tem uma consequência direta para quem opera um MTA: o PowerMTA, que se comunica com os servidores de destino justamente pela porta 25, não pode viver em um link residencial, e sim em um datacenter ou nuvem onde essa porta de saída esteja disponível. Confirmar isso é o primeiro passo da implantação no Brasil, porque um motor que não consegue sair pela 25 simplesmente não entrega, por mais bem configurado que esteja.

Onde o PowerMTA deve rodar: nuvem, VPS ou hardware?

A primeira decisão de implantação é o alojamento, e o PowerMTA se dá bem com quase tudo: roda no seu próprio hardware, em um VPS ou em uma nuvem pública como AWS ou Azure, e rende muito com relativamente pouco ferro, capaz de mover milhões de mensagens por hora a partir de um único servidor bem configurado. A escolha depende menos da potência bruta e mais de três coisas: o controle que você queira sobre os IPs e a sua reputação, a facilidade para escalar horizontalmente quando crescer, e as restrições do seu provedor sobre a porta 25 e o envio de saída. Esse último ponto pega muita gente de surpresa: a AWS, por exemplo, bloqueia por padrão a saída pela porta 25 em todas as instâncias EC2 e exige preencher o formulário «Request to remove email sending limitations», com um registro A e um rDNS associados, e uma resposta que costuma levar até cerca de quarenta e oito horas. Outras nuvens têm restrições parecidas. Por isso parte do trabalho é confirmar, antes de implantar, que o provedor escolhido permite o caso de uso e libera a porta. Quando o volume pede, o PowerMTA admite repartir o tráfego entre vários nós e implantar os IPs em um proxy externo com o protocolo HAProxy, o que simplifica o balanceamento e a tolerância a falhas. Essa arquitetura se decide no começo, porque refazê-la mais tarde custa reputação.

O endurecimento do servidor e a segurança

Um servidor de envio é um alvo apetecível, e um PowerMTA mal protegido é um presente para quem queira mandar spam à sua custa ou roubar a sua reputação. O endurecimento começa pelo sistema operacional: uma distribuição de Linux suportada, atualizada, com só os serviços necessários de pé. O firewall restringe o acesso de modo que a porta 25 e as de envio fiquem abertas onde devem, e a consola de monitoramento do PowerMTA fique acessível unicamente a partir de endereços de confiança ou atrás de uma VPN, nunca exposta à Internet. A autenticação dos clientes SMTP que entregam ao motor se fecha para que ninguém alheio possa injetar correio, evitando o clássico relay aberto que termina em qualquer lista negra em horas. Aplicam-se TLS nas conexões, chaves e permissões cuidadas sobre os arquivos de configuração e de chaves DKIM, e um registro de acesso que permita ver quem toca o quê. Essa camada raramente aparece nos guias rápidos, e é justo a que separa uma instalação profissional de uma que acaba sequestrada ou em uma lista negra por descuido.

# Instale o pacote licenciado, depois confirme que o serviço vincula
$ rpm -ivh PowerMTA-5.0r*.rpm && systemctl enable --now pmta
$ pmta show status | head -1
PowerMTA v5.0 running — 0 messages queued

# O controle que salva um lançamento: o PTR combina com o host de envio?
$ dig -x 198.51.100.25 +short
mta1.send.example.com.
$ dig +short mta1.send.example.com
198.51.100.25        # direto e reverso combinam — pronto para autenticar

Por que o DNS e a autenticação decidem a rejeição?

Antes de o PowerMTA enviar uma única mensagem, o DNS e a autenticação têm que estar impecáveis, porque é aí que se ganha ou se perde a entrega frente a Gmail, Yahoo e Microsoft. Cada IP de envio precisa do seu registro PTR de DNS reverso, resolvendo para um nome coerente com o domínio de envio; um IP sem PTR é uma bandeira vermelha imediata para os filtros. O domínio publica SPF que inclua as fontes de envio sem ultrapassar o limite de consultas, DKIM com uma chave por domínio que o PowerMTA assina em cada mensagem, e um DMARC que alinhe por SPF ou por DKIM. O alinhamento é o detalhe que mais derruba implantações corretas: não basta que SPF e DKIM passem, o domínio que passa tem que coincidir com o que o destinatário vê no remetente. Deixar esta camada fechada e verificada antes do primeiro envio evita o cenário mais frustrante: um motor perfeito enviando correio que volta por uma autenticação montada pela metade.

O domínio de rastreamento, separado

Um detalhe que as instalações apressadas deixam passar é o domínio de rastreamento, o que assina os links de abertura e de clique. Convém que seja um domínio ou subdomínio à parte do domínio principal da marca, por duas razões. A primeira é de reputação: a atividade de rastreamento e de redirecionamento não deve contaminar a reputação do domínio corporativo principal. A segunda é de controle: separar o rastreamento permite geri-lo, rotacioná-lo ou isolá-lo sem tocar no domínio do qual depende o seu correio sério. O PowerMTA gere o rastreamento de forma nativa, e configurá-lo bem desde o começo — com o seu próprio DNS, o seu certificado TLS e o seu alinhamento — evita ter que desenrolá-lo mais tarde, quando já há reputação em jogo. É uma dessas decisões pequenas no início que se agradecem muito um ano depois.

Como se projetam os VirtualMTAs, pools e a segmentação?

Aqui vive o coração de uma boa configuração. Um VirtualMTA é, em termos práticos, uma identidade de envio: um IP de origem com o seu nome, a sua saudação e o seu comportamento. Agrupando VirtualMTAs em pools, separam-se os fluxos de correio segundo a sua natureza: o transacional, que o usuário espera e abre, não deve compartilhar IPs com o promocional em massa, cujo perfil de reclamações é distinto; um cliente importante pode merecer o seu próprio pool isolado; e um fluxo novo ou de risco se mantém à parte para que um problema não arraste o resto. Essa segmentação é o que permite que a reputação se gerencie por fluxo e não como um único bloco frágil. Sobre essa base se montam os limites por provedor — quantas conexões e quantas mensagens por hora ao Gmail, ao Outlook, ao Yahoo —, que o PowerMTA aplica com o seu agrupamento por MX para tratar de forma coerente os muitos domínios que cada grande provedor esconde. Desenhar bem os VirtualMTAs e os pools no começo é o que distingue um envio que escala com ordem de um que se enrola assim que cresce.

Limites por provedor e agrupamento por MX

Enviar ao ritmo correto a cada provedor é o que separa a entrega da parede de rejeições, e aqui o PowerMTA dá um controle fino que é preciso usar com critério. Para cada destino se ajustam o número de conexões simultâneas, as mensagens por conexão e a taxa por hora, valores que Gmail, Outlook e Yahoo toleram de forma distinta e que ainda mudam com a sua reputação. O motor agrupa os muitos domínios que cada grande provedor esconde mediante o agrupamento por MX — que as versões recentes podem fazer de forma automática —, de modo que as dezenas de domínios que na verdade apontam para a infraestrutura do Google se tratam com uma política coerente e não domínio por domínio. Igual de importante é a resposta ao freio: quando um provedor começa a diferir ou a responder com códigos de desaceleração, a configuração deve reduzir o ritmo e reintentar com cabeça, em vez de empurrar mais forte contra uma porta que está se fechando. Afinar esses limites não é um ajuste único; é um trabalho vivo que segue o pulso da reputação, e é boa parte do que aporta operar o motor com experiência. No mercado brasileiro convém lembrar ainda que, ao lado dos grandes provedores globais, há provedores locais como UOL, Terra e BOL com a sua própria base de usuários, e tratá-los com regras próprias em vez de uma política genérica é o que distingue um envio afinado para o público lusófono.

O plano de aquecimento

Um IP novo não tem reputação, e os provedores desconfiam por padrão de quem aparece do nada enviando a volume. O aquecimento é o processo de subir o envio em degraus ao longo de várias semanas, começando baixo e aumentando a um ritmo que os provedores aceitem, priorizando no começo os destinatários mais engajados para acumular sinais positivos. O PowerMTA não aquece sozinho: o plano se desenha e se vigia, ajustando o ritmo conforme os provedores respondem, freando se aparecem diferimentos e avançando quando os sinais acompanham. Pular o aquecimento, ou forçá-lo rápido demais, é a causa mais comum de que uma implantação tecnicamente perfeita entregue mal as primeiras semanas e arraste uma reputação danificada durante meses. Por isso o tratamos como parte inseparável da instalação, e não como um acréscimo posterior: no dia em que o motor está pronto, o plano de aquecimento já está escrito. Na prática, esse plano arranca com cifras modestas por IP e por provedor e as multiplica em degraus ao longo de quatro a oito semanas, com o ritmo governado pela resposta dos provedores e não por um calendário rígido. Os primeiros envios se dirigem ao segmento mais engajado — quem abre e clica —, porque os seus sinais positivos ensinam ao provedor que o seu correio se quer receber, e só depois se amplia a destinatários mais frios. Se em qualquer degrau aparecem diferimentos ou sobe a taxa de reclamações, o plano se detém ou recua antes de avançar. Documentar esse escalonamento, e vigiá-lo a cada dia durante o arranque, é o que converte um aquecimento em uma subida ordenada de reputação em vez de uma aposta.

Bounces, feedback loops e monitoramento desde o dia um

Um envio saudável se reconhece em como gere o que volta, e isso se configura antes da primeira mensagem, não depois do primeiro susto. O PowerMTA classifica os bounces e convém conectá-los a um processador que distinga o bounce duro — endereço que não existe, a suprimir de imediato — do brando — problema temporário, a reintentar com critério —, porque seguir enviando a endereços mortos é um dos sinais que mais rápido afundam a reputação. Ao mesmo tempo, assinam-se os feedback loops dos provedores que os oferecem, para receber e suprimir quem marca o seu correio como spam. E deixa-se de pé o monitoramento: a consola do PowerMTA, as métricas por domínio e por VirtualMTA, e alertas sobre diferimentos, rejeições e armadilhas de spam. Montar tudo isso desde o dia um converte os problemas em sinais que você vê chegar, em vez de surpresas que descobre quando já custaram entrega.

Integração com a sua aplicação: SMTP, HTTP e webhooks

O PowerMTA é a camada de infraestrutura, e se conecta à camada de campanhas ou de aplicação que você já tiver. A via clássica é entregar o correio por SMTP a partir da sua plataforma ao motor, que o aceita, o roteia e o envia segundo as políticas configuradas. As versões modernas adicionam uma via HTTP: pode-se injetar correio mediante uma API, ao estilo dos serviços na nuvem, o que simplifica a integração para aplicações que preferem falar HTTP a SMTP. No sentido inverso, o PowerMTA emite webhooks de accounting que o seu sistema pode receber para saber em tempo quase real o que se entregou, o que voltou e o que se diferiu, alimentando os seus relatórios e as suas listas de supressão sem ter que ler arquivos de registro. Desenhar essa integração com cuidado — o que entra por onde, que eventos se recebem e como se processam — é o que converte o motor em uma peça ordenada da sua pilha e não em uma caixa-preta que envia sem que o resto do sistema fique sabendo.

Registro, accounting e retenção de dados

Tudo o que passa pelo motor deixa rastro, e esse rastro é ao mesmo tempo uma mina de diagnóstico e uma responsabilidade. O PowerMTA escreve registros de accounting que detalham cada entrega, bounce e diferimento, com o nível de detalhe que você configurar. Bem geridos, são a primeira ferramenta para entender por que um provedor freia ou por que sobe a taxa de bounce; mal geridos, lotam o disco e viram um problema operacional ou de privacidade. A configuração cuida de três coisas: que campos se registram, de quanto em quanto rotacionam os arquivos para não esgotar o armazenamento, e quanto tempo se conservam antes de apagar ou anonimizar, em linha com o que exija a lei de proteção de dados que se aplica a você. No Brasil isso significa a LGPD, e em Portugal e na Europa o RGPD, ambas com prazos e princípios de minimização que convém respeitar de fábrica. Uma boa implantação deixa a retenção pensada desde o começo, com a rotação automatizada e um critério claro do que se guarda e por quanto, em vez de descobrir o problema no dia em que o disco enche ou chega uma solicitação de dados.

Conformidade lusófona: CAPEM, LGPD e RGPD

Uma implantação pensada para o público lusófono leva em conta regras que o mercado de língua inglesa não conhece. No Brasil, além das exigências de Gmail, Yahoo e Microsoft, existe o CAPEM — o Código de Autorregulamentação para a Prática de E-mail Marketing, avalizado pelo CGI.br e subscrito por entidades como ABEMD, ABRANET e IAB —, que fixa os seus próprios critérios do que é envio eticamente correto. O código exige que as bases sejam opt-in ou soft opt-in, isto é, com permissão prévia comprovável ou uma relação comercial ou social prévia com o destinatário; que o remetente envie apenas a partir de um domínio próprio; e que cada mensagem ofereça um opt-out que se respeite em no máximo dois dias úteis quando solicitado pelo link de descadastro e cinco dias úteis por outros meios, além de uma segunda alternativa de baixa que não seja um link clicável. Configurar a implantação para honrar esses prazos e esses requisitos — e não só os cabeçalhos técnicos dos grandes provedores — é parte de montar um envio que entrega e se sustenta no Brasil. Em Portugal e na Europa, o RGPD governa o consentimento e os direitos do destinatário com a sua própria exigência, e em Angola e Moçambique aplicam-se as respectivas leis de proteção de dados. Deixar essa camada de conformidade pensada desde o início poupa retrabalho e protege a reputação que todo o resto tenta construir.

Licença e versão: o que você traz

Convém ser explícito com a peça que mais confusão gera. O PowerMTA é software comercial, desenvolvido em seu dia pela Port25 e hoje parte do portfólio da Bird, com um preço por orçamento conforme volume, ambientes e instâncias. A licença você traz: contrata com a Bird ou com um parceiro, é o titular dela, e nós implantamos e configuramos por cima. Não revendemos o motor nem operamos com cópias pirateadas, uma prática comum nos cantos turvos deste setor que, além de ilegal, costuma trazer portas dos fundos e deixa o seu envio sem atualizações de segurança nem suporte. Trabalhar na pista limpa significa software legítimo, atualizado e sob a sua titularidade; qualquer outra coisa é construir a sua infraestrutura de correio sobre areia. A versão concreta — dentro das linhas 5.x e 6.x com suporte — importa menos que mantê-la em dia, porque uma instalação atualizada fecha falhas conhecidas e mantém a compatibilidade com as mudanças dos grandes provedores.

Listas de supressão e consentimento

Nenhuma configuração salva um remetente que envia a quem não quer recebê-lo, então a pista limpa começa antes do motor, em como se constroem e se cuidam as listas. Uma instalação séria deixa de pé listas de supressão que apartam automaticamente quem deu bounce duro, quem se descadastrou e quem marcou o correio como spam, e que o motor consulta para não voltar a escrever-lhes. O PowerMTA respeita essas supressões no envio, mas a disciplina de mantê-las e de não reintroduzir endereços retirados é do remetente. Operamos unicamente com envio de permissão — opt-in legítimo — e não montamos infraestrutura para listas compradas nem para spam, porque nenhuma potência de motor compensa uma lista que gera reclamações: a linha de 0,30% de reclamações que dispara a ação dos provedores se cruza com listas ruins muito antes que com configurações ruins. Deixar a supressão e o consentimento bem planejados protege a reputação que todo o resto tenta construir, e conecta diretamente com as exigências de opt-in do CAPEM e do RGPD que vimos acima.

Escalonamento horizontal e alta disponibilidade

Um só PowerMTA bem configurado move um volume enorme, mas o crescimento e a tolerância a falhas pedem pensar em mais de um nó. O motor admite repartir o tráfego entre vários servidores, e implantar os IPs de origem em um proxy externo mediante o protocolo HAProxy, de modo que os IPs vivem no proxy e não atados a um nó concreto. Isso aporta duas vantagens: o balanceamento do tráfego de saída entre nós se simplifica, e se um nó cai, os seus IPs seguem disponíveis através do proxy em vez de ficarem fora de jogo com a sua reputação congelada. Desenhar esse escalonamento desde o começo — ainda que você arranque com um só nó — evita refazer a arquitetura mais tarde, que é justo quando há reputação acumulada que não convém mover de qualquer jeito. Para quem prevê crescer, deixar a porta aberta ao escalonamento horizontal é uma decisão barata no início e cara de adicionar depois.

Que aspecto tem «concluído»

Uma implantação está concluída quando se sustenta sozinha e se entende sem nós. Isso significa várias coisas concretas: os IPs aquecem segundo um plano escrito e a bom ritmo; o DNS e a autenticação passam e alinham para todos os fluxos; os VirtualMTAs e os pools separam o correio por natureza e aplicam limites sensatos por provedor; os bounces se processam e os endereços mortos se suprimem sozinhos; os feedback loops estão conectados; e o monitoramento avisa dos problemas antes de afetarem a entrega. E, não menos importante, tudo fica documentado: como está montado, por que se decidiu assim e o que tocar quando algo mudar. Uma implantação que só funciona enquanto quem a montou estiver disponível não está concluída; está pendente de uma passagem que ainda não se fez.

Uma implantação nova deve usar PowerMTA sequer?

A pergunta honesta antes de implantar é se o PowerMTA é o motor adequado para você, e a resposta nem sempre é que sim. O PowerMTA tem o seu melhor encaixe em remetentes de alto volume que precisam de controle fino por IP e por provedor, com uma equipe capaz de operá-lo ou com um parceiro que o faça. Para volumes menores, ou para quem prefere delegar a infraestrutura, um Postfix bem afinado ou uma nuvem como a Amazon SES cobrem o caso com menos custo, menos manutenção e menos superfície de falha. Como não revendemos o PowerMTA nem ganhamos com a sua licença, não temos motivo para montá-lo se ele não encaixa; preferimos dizer isso antes e, se for o caso, orientar você para a opção que de verdade lhe convém. Essa conversa faz parte do serviço, e muitas vezes poupa a um cliente uma implantação que ele não precisava. Quando a dúvida é qual motor escolher, o abordamos com calma na seleção de MTA.

Como se desenvolve uma implantação?

Começamos pela auditoria gratuita de 25 pontos, que confirma o encaixe do PowerMTA e deixa claro o ponto de partida de DNS, IPs e autenticação. A partir daí, o trabalho segue a sequência que esta página descreve: confirmar a disponibilidade da porta 25 de saída e preparar o servidor e o alojamento; fechar o DNS, a autenticação e o domínio de rastreamento; instalar a versão suportada da sua licença; desenhar os VirtualMTAs, os pools e os limites por provedor; escrever o plano de aquecimento; conectar o processamento de bounces, os feedback loops e o monitoramento; e arrancar o aquecimento sob vigilância. Ao fechar, entregamos a você a instalação documentada para que a sua equipe a leve, ou a operamos nós como serviço gerenciado, conforme você preferir. A infraestrutura e a licença são suas em todo momento, e a relação se fatura pelo trabalho, sem um motor para vender do outro lado da mesa. Quanto a prazos, a preparação e a configuração costumam ocupar de alguns dias a um par de semanas conforme a complexidade do seu ambiente, com o tempo da liberação da porta 25 na nuvem somado a isso, e o aquecimento acrescenta depois de quatro a oito semanas até alcançar o volume objetivo com boa reputação. Não prometemos um envio a pleno rendimento de um dia para o outro, porque fazê-lo exigiria pular o aquecimento e pagá-lo em entrega; preferimos um arranque um pouco mais lento e uma reputação que aguente. Esse é o intercâmbio honesto, e é o que recomendamos a quem quer que vá depender do seu correio.

Se você está pensando em montar ou refazer um PowerMTA, o ponto de partida não custa nada: a auditoria de 25 pontos confirma o encaixe do motor e o estado do seu DNS, dos seus IPs e da sua autenticação antes de implantar. Quando a implantação estiver de pé, a operação gerenciada a mantém em ponto.