Diagnóstico de PowerMTA

Quando o e-mail para de entrar, o relógio corre e a tentação é fazer algo, qualquer coisa, já. E aí está o problema: em um incidente de entrega, as reações de pânico costumam piorar as coisas. Reintentar com mais força, subir as taxas, ignorar o que os bounces dizem... cada um desses impulsos pode converter um freio passageiro em um bloqueio sério. O diagnóstico de PowerMTA existe para substituir o pânico por método: ler o que o motor e os provedores estão dizendo a você, identificar a causa real e aplicar o conserto correto, que muitas vezes é o contrário do que o instinto pede. Esta página explica como lemos um problema e como trabalhamos um incidente, porque saber o que está acontecendo é, quase sempre, metade da solução.

Por onde se começa quando o correio para de chegar?

A boa notícia do PowerMTA é que ele não falha em silêncio: cada rejeição vem com um código e uma mensagem do provedor que diz, com bastante precisão, o que ocorre. O primeiro passo de qualquer diagnóstico é ler isso em vez de reagir ao susto. Um parque que entrega mal não é um mistério insondável; é um conjunto de respostas SMTP que contam uma história, se a pessoa souber lê-las. A diferença entre um remetente que se recupera rápido e um que afunda está, em boa medida, em se ele escuta esses sinais ou os atropela. Por isso começamos sempre pelos logs e pelos bounces, não pelas conjecturas: ali está escrito qual provedor freia você, desde quando e, muitas vezes, por quê. Diagnosticar é, antes de tudo, um exercício de leitura atenta.

4xx ou 5xx: o primeiro dígito muda tudo

A distinção mais importante de uma rejeição está no seu primeiro dígito. Um código 4xx é uma falha temporária: o provedor não aceita a mensagem agora, mas poderia aceitá-la mais tarde, então o correto é reintentar com paciência, segundo as regras de backoff. Um código 5xx é uma rejeição permanente: insistir não servirá, e o conserto está na configuração, no conteúdo ou na reputação, não em tentar de novo. O PowerMTA classifica essas respostas e age de acordo, mas só se estiver bem configurado para isso. O erro clássico — e caro — é tratar um 4xx como se fosse definitivo, ou um 5xx como se bastasse reintentar. Ler bem esse primeiro dígito marca a diferença entre uma recuperação ordenada e um agravamento, e é a primeira coisa que conferimos ao abrir os seus logs.

Como se vai do sintoma à causa?

Cada sintoma aponta para um punhado de causas prováveis e para um primeiro passo sensato. Esta tabela resume os problemas pelos quais mais nos chamam e por onde se começa a resolvê-los, antes de entrar no detalhe de cada um.

Diferimentos contra bounces duros

Duas coisas que se confundem com frequência são os diferimentos e os bounces duros, e tratá-las igual é um erro. Um diferimento é um «agora não, volte depois»: o provedor retém o seu e-mail temporariamente, e com o tempo e o ritmo adequados ele acabará entrando. Um bounce duro é um «isto não existe» ou «nunca vou aceitar»: insistir só gasta reputação. Quando um incidente mistura ambos, o primeiro é separá-los, porque exigem respostas opostas: paciência e backoff para os diferimentos, supressão imediata para os bounces duros. Um parque que reintenta bounces duros como se fossem diferimentos afunda sozinho, e um que dá os diferimentos por mortos perde entregas que iam chegar. Distingui-los bem, lendo o código e o texto de cada um, é das primeiras coisas que ordenamos em um diagnóstico.

Como se lê um código de bounce na prática?

Um bounce bem lido diz muito mais que «não entrou». Olhamos três coisas em cada um. O código, que separa o temporário do permanente. O momento da sessão em que aparece: uma rejeição na saudação, antes de apresentar a mensagem, costuma apontar para o IP que conecta, para a carga de conexões ou para uma política de TLS ou de tráfego, enquanto uma mais adiante pode envolver o domínio remetente, o destinatário, o ritmo ou o conteúdo. E o texto de diagnóstico que acompanha o código, onde o provedor muitas vezes nomeia a razão e até vincula o seu portal. Cruzando essas três pistas no volume dos seus logs — não em um bounce isolado — sai o padrão: qual provedor, que tipo de problema e desde quando. Essa leitura é a matéria-prima do diagnóstico, e a que evita atirar às cegas.

Os logs: onde está escrito tudo

A verdade de um incidente está nos logs, não nas impressões. O PowerMTA guarda um rastro detalhado de cada tentativa de entrega: o código de resposta, o motivo, o provedor, a hora, a fila envolvida. Esse registro é a cena do crime, e lê-lo bem é a diferença entre saber o que acontece e adivinhá-lo. Olhamos a contabilidade para ver o panorama — quanto entra, quanto se difere, quanto dá bounce e por onde — e os logs detalhados para reconstruir o porquê de um caso concreto. Um parque com bons logs se diagnostica em horas; um com logs pobres obriga a esperar o problema se repetir para poder vê-lo. Por isso, quando começamos, a primeira coisa que pedimos é acesso de leitura a esses dados: ali está escrito quase tudo o que precisamos saber.

# Quais provedores devolvem quais códigos, ordenados por volume?
$ pmta show queues | grep -E "outlook|hotmail" | head
outlook.com   recipients 84120   status 550 5.7.606   bloqueado

# Confirme que é bloqueio de IP, não de conteúdo ou auth — conte o código
$ grep "5.7.606" /var/log/pmta/acct-*.csv | wc -l
84120        # todo o ecossistema Microsoft de uma vez — cruze com o SNDS

# É só Microsoft, ou o Gmail também adia? (leia o padrão)
$ awk -F, '{print $7}' /var/log/pmta/acct-*.csv | sort | uniq -c | sort -rn | head
  84120 550 5.7.606     # só Microsoft
  41880 250 2.0.0       # Gmail ainda entregando normal

Por quais sintomas os remetentes nos chamam?

As ligações se parecem mais do que parece. A mais frequente: «o Gmail está nos diferindo e não sabemos por quê». Segue a Microsoft, com os seus bloqueios súbitos e o seu famoso código da família 550. Depois estão as filas que crescem e não baixam, as tempestades de bounces que aparecem após uma campanha, e a queda lenta de colocação na caixa que ninguém relaciona com uma causa concreta até que as vendas caem. Num público brasileiro soma-se às vezes um diferimento dos provedores locais — UOL, Terra ou BOL —, que têm os seus próprios sinais e que convém ler à parte em vez de assumir que se comportam como os globais. Às vezes é um parque novo que nunca chegou a entregar bem; outras, um que funcionou durante anos e de repente quebrou. Atrás dessa variedade há, quase sempre, um repertório limitado de causas, e reconhecer o sintoma é o primeiro passo para acertar a causa em vez de tentar a sorte.

O que significa o 421 do Gmail?

O caso mais comum tem também o pior manejo habitual. Quando o Gmail devolve um 421 4.7.0, está pondo um freio temporário por reputação, ritmo ou pouca interação, não levantando um muro permanente. O Gmail ajusta dinamicamente quanto tráfego aceita de cada remetente, e quando você supera o seu limite, ele pede que você baixe o ritmo com esse código. A armadilha é tratá-lo como uma falha definitiva e responder reintentando a todo vapor: isso reforça justo o sinal que disparou o freio e o agrava. O correto é o contrário: baixar o ritmo, deixar o backoff fazer o seu trabalho e reconstruir confiança, com o que o 421 se desvanece sozinho à medida que a reputação se estabiliza. Se a origem foi um aquecimento apressado, o identificamos e o corrigimos. É um problema que quase sempre se resolve com paciência e método, raramente com força.

O que significam os códigos 550 5.7.515 e 5.7.606 da Microsoft?

Poucos erros frustram tanto quanto o S3150 da Microsoft, e convém explicá-lo com franqueza. Chega como um 550 5.7.1 — isto é, uma rejeição permanente — que diz que parte da sua rede está na lista de bloqueio deles, e remete você a um portal que às vezes nem carrega. A comunidade reconstruiu ao longo dos anos que ele se associa a um bloqueio no nível de IP pelo seu filtro de protocolo, e que se devolve como permanente embora a causa de fundo costume ser temporária: reputação ou ritmo. Essa contradição é o problema: um código permanente para algo que não o é gera bounces, supressões e endereços marcados como mortos que não estão. E a Microsoft não publica limites claros, então o conselho de «envie mais devagar» fica sem um número ao qual mirar. Trabalhamos isso pelos canais de delisting deles e corrigindo a reputação, mas diremos desde o começo que parte depende deles.

5xx súbito e massivo: um bloqueio em marcha

Quando as rejeições permanentes disparam de uma vez contra um provedor concreto, quase sempre é um bloqueio ativo, e a reação importa. Mais que o pingar normal de endereços mortos, é uma parede que um provedor acaba de levantar contra o seu IP ou o seu domínio, por reputação ou por política. O instinto de seguir empurrando é o pior possível: cada tentativa confirma o motivo do bloqueio. O primeiro é parar de pressionar aquele provedor, identificar exatamente qual IP ou domínio está bloqueado e ler o motivo que a rejeição dá. A partir daí, o caminho é corrigir a causa de reputação e, se houver um portal de delisting, usá-lo. Um 5xx massivo e súbito é das poucas situações onde a velocidade de reação — no sentido de parar, não de empurrar — muda de verdade o desfecho.

Vocês podem nos tirar de uma lista negra e como o delisting funciona?

Quando o problema é uma lista negra, a honestidade é a melhor política. Aparecer em uma lista como as da Spamhaus ou na de um provedor freia a sua entrega, e sair dela é possível, mas não por arte de magia: a maioria das listas exige que você primeiro corrija a causa que o pôs ali — um IP comprometido, uma lista suja, um pico de reclamações — antes de retirá-lo, e algumas repõem a listagem se detectam que o problema segue. Por isso o delisting a sério é sempre dois passos: arrumar a origem e depois solicitar a saída, nessa ordem. Tratamos isso a fundo na página de saída de listas negras, mas em um incidente o princípio é o mesmo: deslistar sem arrumar a causa apenas compra tempo em vez de resolver o problema.

O backoff que piora as coisas

Em muitos incidentes, o agravante não é o provedor, e sim o próprio backoff mal configurado. A função existe para que, quando um provedor freia você, o motor reduza o ritmo àquela fila e reintente mais devagar até a situação melhorar. Mas um backoff mal posto — padrões que não pegam os avisos reais, modos que não voltam ao normal, retentativas agressivas demais — pode provocar filas descontroladas e bucles de retentativa que pioram justo o que pretendiam arrumar. Por isso, diante de uma fila que não baixa ou de um provedor que se fecha, revisamos sempre o backoff: muitas vezes o problema que parece do provedor é, na verdade, a resposta atrapalhada do seu próprio motor ao sinal do provedor. Ajustá-lo bem converte uma espiral em uma recuperação ordenada.

Os consertos que pioram tudo

Boa parte do diagnóstico é impedir que o pânico faça mais estrago. Há reações instintivas que quase sempre agravam um incidente, e as freamos. Reintentar a toda velocidade um 421 grita ao provedor justo o que o incomodou. Insistir sobre um 5xx permanente desperdiça recursos e manda sinais de remetente descuidado. Subir as taxas para «esvaziar» uma fila que não baixa adiciona pressão sobre um provedor que já estava contendo você. Tirar o backoff porque «está lento» elimina a rede que protegia você. E mudar dez coisas ao mesmo tempo torna impossível saber o que ajudou e o que prejudicou. A primeira regra de um incidente é não piorá-lo, e às vezes o movimento mais valioso que fazemos nas primeiras horas é deter os consertos que já estavam em marcha.

Picos de reclamações: a causa silenciosa

Atrás de muitas quedas de entrega há um pico de reclamações que ninguém viu chegar. Quando gente demais marca o seu e-mail como spam — após uma campanha a uma lista velha, uma troca de remetente ou um conteúdo que não esperavam —, os provedores reagem rápido e sem avisar de forma evidente: começam a diferir, a mandar para spam ou a bloquear. A reclamação é um sinal potentíssimo e, ao contrário de um bounce, nem sempre deixa um rastro tão claro nos seus logs, então é preciso buscá-la nos feedback loops e na correlação com o que você enviou. Em um incidente, conferimos se um pico de reclamações explica a queda, porque se a causa é essa, ajustar o motor não arruma nada: o problema está em a quem e o que você enviou. Identificá-lo a tempo evita perseguir a avaria no lugar errado.

A autenticação como causa oculta

Às vezes o diferimento não vem do ritmo nem da reputação, e sim de uma autenticação quebrada que o bounce não nomeia de forma óbvia. Uma falha de alinhamento de SPF, DKIM ou DMARC pode se traduzir em diferimentos ou em e-mail que cai no spam sem uma mensagem que grite «a sua autenticação falha». Por isso, em um incidente de colocação ou de diferimentos sem causa aparente, conferimos a autenticação como suspeita habitual: que as assinaturas estejam ativas e alinhadas, que o SPF não ultrapasse o seu limite de consultas, que o DMARC seja coerente com o que você envia. É uma causa oculta porque raramente se apresenta com o seu nome, e porque um parque que «sempre funcionou» pode quebrar aqui após uma troca de DNS ou de provedor. Descartá-la cedo evita perseguir fantasmas no motor quando o problema está em um registro.

E quando a causa é o conteúdo e não o motor?

Há incidentes em que a configuração está impecável, a reputação em ordem e os bounces não acusam nada técnico, e ainda assim a colocação caiu — e a causa está no próprio conteúdo do e-mail. Uma mudança de modelo que encheu a mensagem de imagens e links, um assunto que destoa do corpo, um encurtador de URL que apareceu em listas, ou uma palavra que os filtros passaram a tratar com desconfiança: qualquer um pode empurrar um envio que sempre entrou para a aba de promoções ou para o spam. Em um incidente assim, conferimos se a queda coincide com uma mudança de conteúdo, comparando o que entregava bem com o que parou de entregar. Não somos uma agência de copy, mas sabemos reconhecer os sinais técnicos que os filtros punem e dizer quando o ajuste não é de motor, e sim de mensagem. Perseguir essa avaria no PowerMTA seria afinar parafusos que já estão certos enquanto o verdadeiro problema segue intacto no e-mail.

Incidentes em operações multimarca

Quando um PowerMTA envia por várias marcas ou clientes, um incidente tem uma camada a mais: descobrir se o problema é de uma marca ou de toda a operação. A boa notícia de uma estrutura bem segmentada é que costuma conter o estrago — uma marca com uma lista ruim afeta o seu próprio pool sem arrastar as outras —, mas só se a segmentação foi desenhada para isso. Em um diagnóstico multimarca, primeiro isolamos: qual subconta, qual pool, qual conjunto de IPs mostra o sintoma, e se ele vaza para o restante. Às vezes o achado é justamente que a separação não existia e duas reputações que deveriam ser independentes estavam compartilhando o mesmo destino. Resolver o incidente, nesses casos, é ao mesmo tempo apagar o fogo e corrigir a arquitetura que o deixou se espalhar, para que o próximo problema de uma marca fique contido onde nasceu.

O que não prometemos

Parte de um diagnóstico honesto é dizer o que está fora do nosso alcance. Não temos um botão para apagar um bloqueio que depende inteiramente de um provedor que não publica os seus critérios; o que temos é o método para corrigir a causa e os canais para solicitar a saída, e a franqueza de dizer quanto do prazo não está em nossas mãos. Não recuperamos uma reputação arruinada em uma tarde, porque ela se reconstrói com comportamento ao longo de semanas, não com um ajuste de configuração. E não fazemos um envio sujo entregar limpo: se a causa é uma lista comprada ou um consentimento que não existe, nenhum conserto de motor resolve, e o diremos em vez de vender uma esperança falsa. Preferimos prometer menos e cumprir do que prometer um milagre e gerar uma frustração maior que o incidente original. Saber o que não se pode fazer é parte de fazer bem o que se pode.

Quando um parque novo nunca arrancou

Nem todos os incidentes são de um parque que quebrou; alguns são de um que nunca chegou a funcionar. Um PowerMTA recém-montado que entrega mal desde o primeiro dia costuma arrastar um de uns poucos pecados de origem: um aquecimento que se pulou ou se acelerou, uma autenticação incompleta, uma configuração copiada sem entender, ou IPs com um histórico que não se conferiu antes de usar. No Brasil há um pecado de origem adicional e muito comum: o motor montado num ambiente sem a porta 25 de saída liberada. Pela Gerência de Porta 25 do CGI.br as redes residenciais bloqueiam essa porta, e em nuvens como a AWS ela vem bloqueada por padrão, então um parque que «nunca arrancou» às vezes recebe o tráfego mas não consegue sair para entregar, ou o faz sem o DNS reverso que os receptores esperam. Diagnosticar um parque novo é diferente de resgatar um veterano: em vez de buscar o que mudou, buscamos o que nunca esteve bem. Revisamos os alicerces um a um — autenticação, aquecimento, segmentação, limites — e os pomos em ordem, porque um arranque torto não se endireita enviando mais, se endireita voltando à base. É frustrante descobrir que o problema esteve ali desde o começo, mas também é a classe de avaria que, uma vez vista, se arruma de raiz.

Quando um que funcionava quebrou de uma vez

O caso contrário, e o mais angustiante, é o do parque que funcionou durante anos e um dia para de entregar. Aqui a pergunta-chave é o que mudou, porque algo o fez, ainda que não seja evidente. Uma troca de DNS que quebrou a autenticação, um IP novo sem aquecer metido em produção, um provedor que endureceu as suas regras, um salto de volume por uma campanha incomum, uma atualização mal aplicada: a lista de suspeitos é conhecida. Diagnosticar um parque veterano quebrado é, sobretudo, reconstruir a linha do tempo — o que se tocou, quando começou o problema — e cruzá-la com o que os bounces dizem. Muitas vezes a causa é uma mudança recente e pequena com um efeito grande, e encontrá-la é questão de olhar o antes e o depois com método. O que «sempre funcionou» raramente quebra sozinho.

O que precisamos de você para começar

Para diagnosticar rápido, quanto mais contexto você nos dá, antes chegamos à causa. O essencial é pouco: acesso de leitura à sua configuração de PowerMTA e aos seus logs e contabilidade, que é onde está o rastro. Além disso, ajuda muito uma linha do tempo do que aconteceu: quando começou o problema, o que você notou primeiro — diferimentos, bounces, queda de aberturas — e, sobretudo, o que se tocou nas datas próximas, como uma troca de DNS, um IP novo, uma campanha incomum, uma atualização ou um provedor novo. Esses «o que mudou?» são muitas vezes o fio que desenrola todo o novelo, porque um problema que começou numa terça costuma ter uma causa daquela segunda. Se você tiver à mão exemplos concretos de bounces, melhor ainda: um punhado de mensagens de rejeição reais diz mais que uma descrição geral. Com isso começamos a ler de imediato, sem pedir que você vire especialista: você conta o que vê e o que mudou, e nós traduzimos os códigos em uma causa e um plano.

O reverso e o HELO: a causa que não está no config

Algumas rejeições não têm explicação no arquivo de configuração porque a causa vive na rede. Um IP sem DNS reverso, e um FCrDNS que não fecha, são motivo de diferimento ou rejeição, e não deixam rastro no config. O mesmo vale para um nome de saudação HELO incoerente com o domínio. Quando um motor bem ajustado segue entregando mal, revisamos essa camada antes de tocar nada, porque é onde se esconde a avaria que um scanner não vê.

Como vocês trabalham um incidente de PowerMTA?

A nossa forma de trabalhar um incidente é deliberadamente metódica, porque a pressa mal levada é a que quebra. Primeiro estabilizamos: detemos os consertos que pioram e contemos o dano. Depois diagnosticamos sobre dados — os seus logs, os seus bounces, a sua reputação — até ter a causa identificada, para além de uma simples suspeita. Em seguida aplicamos a correção correta, que muitas vezes é baixar, esperar e ajustar antes de empurrar, e validamos que a entrega se recupera de verdade. E, por fim, deixamos claro o que aconteceu e o que evitará que volte. Tudo isso com cobertura em fusos horários da Europa, América do Norte e América Latina, porque os incidentes de entrega não respeitam o horário de escritório. A diferença entre um incidente gerenciado e um sofrido é ter alguém com o contexto e a calma para ler a situação antes de agir.

O relógio importa: a rapidez de diagnóstico

Em um incidente de entrega, o tempo é dinheiro de verdade. Cada hora que o seu e-mail não entra é e-mail que não converte, e cada dia que um problema de reputação se prolonga é mais difícil de reverter, porque o dano se acumula. Por isso a rapidez de diagnóstico é uma vantagem competitiva antes de um luxo: quanto antes se identifica a causa, antes se detém o dano e começa a recuperação. Essa velocidade não vem de agir rápido às cegas — isso piora —; vem de saber onde olhar e reconhecer os padrões na hora, que é o que dá ter visto o mesmo problema muitas vezes. Chegar com o contexto e o método já postos poupa as horas mais caras de um incidente: as primeiras, quando o dano ainda pode ser contido.

Um incêndio ou o padrão por trás?

Apagar o fogo de hoje importa, mas a pergunta que de verdade poupa dinheiro é por que ele se acendeu. Muitos incidentes são sintomas de um problema de fundo: um aquecimento mal feito que produzirá mais 421, uma segmentação pobre que mistura reputações, um backoff frágil que voltará a transbordar, uma lista que segue se sujando. Resolver o incidente sem olhar o padrão garante o seguinte. Por isso, ao fechar um incidente, dizemos a você se foi um caso isolado ou a ponta de algo maior, e o que faria falta para que não se repita. Essa leitura é o que separa um remendo de uma solução, e muitas vezes é o argumento para passar de nos chamar quando há fogo a nos ter vigiando para que não haja.

Diagnóstico pontual ou vigilância contínua

O diagnóstico vale por si só: você nos chama quando algo quebra, resolvemos e você segue o seu caminho, com o problema entendido e corrigido. Para muitos, porém, a lição de um incidente é que vigiar sai mais barato que apagar fogos. Aí, o diagnóstico se converte no ponto de entrada a uma operação gerenciada que detecta os problemas antes de estourarem, ou a uma otimização que corrige as causas de fundo. Não condicionamos uma coisa à outra: resolver o seu incidente é útil tanto se seguirmos juntos quanto se não. E se a origem acaba estando fora do motor, o abordamos com a auditoria geral de entregabilidade.

Se você está no meio de um incidente, o primeiro passo é entender o que acontece: a auditoria de 25 pontos dá uma leitura rápida do seu envio e do seu PowerMTA, e nos orienta sobre onde olhar. A partir daí agimos com dados, não às cegas.