Diagnóstico e resgate do KumoMTA

O que a automação da modelagem de tráfego fez durante o incidente?

Num parque KumoMTA há uma pergunta de diagnóstico que não existe em motores mais velhos, e ela vem primeiro: o que a automação da modelagem de tráfego já fez a respeito? Uma fila que parou de drenar muitas vezes não é mistério nenhum: uma regra coincidiu com uma resposta do provedor e suspendeu essa rota por duas horas, ou baixou em silêncio o seu ritmo de mensagens, exatamente como foi projetado. Isso é o sistema funcionando; o incidente, se houver, está rio acima no que disparou a regra, ou numa regra que reage demais —suspendendo por horas onde uma redução curta de ritmo teria mantido o correio em movimento. Então lemos o histórico de automação junto com as filas: quais regras dispararam, com que frequência, sobre qual texto de resposta, com qual ação e duração. Às vezes o achado é que nada está quebrado e o movimento certo é deixar a suspensão expirar enquanto se corrige a causa; às vezes é uma regra de fábrica que precisa de ajuste ao seu tráfego. Em qualquer caso, diagnosticar um parque Kumo sem ler o diário da TSA é adivinhar decisões que o motor já escreveu.

Os registros: onde tudo fica escrito

A verdade de um incidente vive nos registros de entrega, não nas impressões. O KumoMTA registra cada tentativa como dado estruturado —o código e o texto de resposta, o receptor, a fila, a fonte, os tempos— em segmentos JSONL comprimidos feitos para se processar em volume; os registros de rejeição capturam até o comando que os disparou. Duas regras práticas mantêm honesta a leitura. A contabilidade sai desses registros, não dos instantâneos de fila: os contadores ao vivo se reiniciam quando as filas prontas são coletadas, então só o fluxo de registros te dá totais confiáveis. E o registro de diagnóstico —o que o próprio daemon reporta através do journal do sistema— tem uma verbosidade ajustável que pode ser subida dinamicamente enquanto você investiga e deve ser baixada depois, porque os níveis mais loquazes enchem um disco com velocidade impressionante. Um parque com registros bem mantidos se diagnostica em horas; um que desabilitou ou matou o seu registro te obriga a esperar o problema reaparecer antes que alguém possa vê-lo. A primeira coisa que pedimos, sempre: acesso de leitura a este material.

A caixa de ferramentas: respostas ao vivo de um motor em marcha

O KumoMTA traz um cliente de linha de comando que converte «o que está acontecendo agora» em perguntas respondíveis, e um incidente é quando ele ganha o seu salário. O resumo de fila mostra, por site de destino e por fonte, o que entrega, o que está em trânsito e o que espera: a forma mais rápida de ver se um problema é um provedor, um IP ou tudo de uma vez. Um resumo por provedor agrega a mesma imagem por receptor; uma visão top ao vivo a observa se mover. O filtro de registro pode ser subido na hora, sem reinícios, quando o journal precisa dizer mais. E dois verbos operacionais importam num resgate: o rebind, que move um fluxo de mensagens em fila para uma fila diferente com as regras reavaliadas —inestimável quando uma rota está envenenada e o seu correio precisa de uma via mais saudável— e o bounce ou transferência administrativa do correio em fila quando é preciso drenar um nó. Nada disso requer tocar a política; é observação e cirurgia sobre um motor em marcha, que é justo o que as primeiras horas de um incidente pedem.

# Qual fila está travada, e qual é a última resposta? (Q=na fila)
$ kcli queue-summary --by-site
SITE              D       T    C       Q   última-resposta
yahoo.com       402      0    0   28140   421 4.7.0 [TSS04] deferred

# Antes de tocar o shaping: a automação já suspendeu esta rota?
$ kcli tsa-status --domain yahoo.com
SUSPEND ativo, 47m restantes · gatilho: rajada 421 4.7.0 · auto-aplicado

# Leia os eventos reais, não adivinhe — últimos 5 adiamentos da rota
$ kcli tail-log --domain yahoo.com --type deferral --limit 5
421 4.7.0 [TSS04] Mensagens adiadas temporariamente por volume

# Causa achada: a automação faz o seu trabalho. Deixe expirar, não rebind.

Observar o fio: rastrear conversas reais

Quando os registros dizem o que aconteceu e você precisa ver acontecer, o motor pode te mostrar a conversa em si. O rastreamento do lado do cliente transmite o diálogo SMTP de saída em tempo real —o banner, o EHLO, o passo TLS, o momento e a redação exatos da rejeição do receptor— filtrado para a fila pronta ou a fonte que te importa, porque num servidor ocupado o rastreamento sem filtro afoga. O rastreamento do lado do servidor faz o mesmo para as conexões de entrada, o que despacha rápido os problemas de injeção: a aplicação que diz que envia enquanto o motor não vê nada, a autenticação que falha antes do primeiro byte de carga, a mensagem malformada que um gerador produz sob carga. Esta é a diferença entre deduzir um problema de handshake pelos seus escombros e vê-lo ocorrer; algumas classes de falha —um receptor rejeitando a saudação de um IP específico, TLS falhando contra um MX específico— são minutos com um rastreamento e dias sem ele. Usamos com cirurgia, com filtros, e te deixamos sabendo como.

Adiamentos ou retornos duros: qual você está vendo?

Duas coisas se confundem constantemente numa crise, e tratá-las igual é um erro com juros compostos. Um adiamento é «agora não, volte depois»: o receptor está retendo o seu correio, e com o ritmo certo ele aterrissará. Um retorno duro é «isto não existe» ou «nunca»: insistir só gasta reputação. Quando um incidente mistura ambos —e as tempestades de retornos costumam fazê-lo— a primeira tarefa é separar, porque as respostas que exigem são opostas: paciência e backoff para os adiamentos, supressão imediata para os mortos. Um motor que retenta retornos duros como se fossem adiamentos afunda sozinho; um que descarta adiamentos como mortos perde correio que estava a minutos de aterrissar. A classificação de retornos do KumoMTA faz bem essa separação quando está cabeada para isso; parte de cada diagnóstico é verificar que a separação de fato acontece, e que a lista de supressão se alimenta dela em vez de existir como um folclore paralelo.

O que significa uma resposta 421 do Gmail?

A chamada mais comum é também a pior gerida. Quando o Gmail devolve a sua linguagem de ritmo 421, está aplicando um freio temporário —reputação, ritmo ou engajamento— e pedindo que você baixe a velocidade; não está construindo um muro. O Gmail ajusta dinamicamente quanto aceita de cada remetente, e cruzar a sua cota atual produz exatamente este código. A armadilha é tratá-lo como uma falha dura e retentar a toda velocidade, o que amplifica o mesmíssimo sinal que disparou o freio. O movimento certo é o contrário: baixar o ritmo, deixar a automação sustentar a rota —isto é justo aquilo para o que estão escritas as regras de shaping da comunidade— e reconstruir a confiança, momento em que os 421 se desvanecem sozinhos. Se a origem foi um aquecimento apressado ou um problema de lista, nós o identificamos e o corrigimos. Este quase sempre se resolve com paciência e método, quase nunca com força, e a correção mais rápida é com frequência deter a «correção» já em marcha.

Quando a Microsoft se fecha: o S3150

Poucos erros frustram como o S3150 da Microsoft, então o explicamos sem verniz. Chega como um 550 5.7.1 —formalmente uma rejeição permanente— dizendo que parte da sua rede está na lista de bloqueio deles, apontando para um portal que às vezes não carrega. A experiência de operadores ao longo dos anos o associa a um bloqueio em nível de IP da filtragem deles, devolvido como permanente embora a causa subjacente costume ser temporária: reputação ou ritmo. Essa contradição é o problema operacional: um código permanente para uma condição não permanente gera retornos, supressões e endereços marcados como mortos que não estão, então o primeiro movimento defensivo no KumoMTA é garantir que o seu tratamento de retornos não deixe uma tempestade de S3150 envenenar a lista de supressão. A resolução corre pelos canais de delisting deles e, sobretudo, por corrigir a causa de reputação, porque sem isso o bloqueio volta. Dizemos desde o primeiro dia qual parte do calendário é nossa e qual é de Redmond, porque não publicam os limiares e a honestidade ganha do teatro.

5xx repentino e massivo: um bloqueio em marcha

Quando as rejeições permanentes disparam de uma vez contra um receptor, quase sempre é um bloqueio ativo, e a reação decide o desfecho. Isto não é a garoa normal de endereços mortos; é um muro que um provedor acabou de levantar contra o seu IP ou domínio, por reputação ou política. O instinto de continuar empurrando é o pior disponível: cada tentativa confirma o raciocínio do bloqueio. Primeiro, detenha a pressão sobre essa rota —suspenda-a deliberadamente se a automação não o fez já— depois identifique exatamente qual IP ou domínio está bloqueado e leia a razão que a rejeição dá, que no KumoMTA está literal nos registros de rejeição. Daí a via é corrigir a causa e usar o canal de delisting onde houver. Um 5xx massivo repentino é uma das poucas situações onde a velocidade de reação —no sentido de parar, nunca de empurrar— de fato muda como a história termina.

Como funciona de fato o delisting de listas negras?

Quando o problema é uma lista de bloqueio, a honestidade é a única política útil. Aterrissar numa lista como a da Spamhaus, ou na lista interna de um receptor, freia a entrega em todas as frentes, e sair é possível, mas não por mágica: a maioria das listas exige primeiro a causa corrigida —uma fonte comprometida, uma lista suja, um pico de reclamações— e algumas re-listam automaticamente se detectam que o problema persiste. O delisting sério é portanto sempre dois passos em ordem estrita: reparar a origem, depois solicitar a remoção. Cobrimos a disciplina completa na página de delisting de listas negras, mas dentro de um incidente o princípio é idêntico: fazer delisting sem reparar compra tempo, não uma solução, e o tempo que compra costuma ser curto. E convém saber qual lista é qual: as públicas como a Spamhaus publicam o seu critério e a sua via de remoção, enquanto as internas do Gmail ou da Microsoft não expõem nem limiar nem formulário, o que muda por completo o calendário realista de recuperação.

Por que uma fila do KumoMTA não drena?

Uma fila que cresce assusta as pessoas para justo o movimento errado: subir ritmos para «esvaziá-la». Uma fila que não drena é um sinal, nunca a doença: algo rio acima freia a entrega, e no KumoMTA a lista de suspeitos é curta e verificável. Uma suspensão de automação ainda ativa nessa rota. Um teto de provedor cruzado, com os adiamentos para prová-lo. Uma política de retentativas paciente demais ou ansiosa demais para esse receptor. Um regulador compartilhado entre nós fazendo o seu trabalho. Ou —o que as pessoas esquecem— a fila agendada se reabastecendo mais rápido do que a fila pronta pode legalmente drenar, que é um problema do lado de injeção disfarçado do lado de entrega. O resumo de fila os separa em minutos: as contagens por site e por fonte mostram se o coágulo é um provedor, um IP ou sistêmico, e o histórico de automação diz se o próprio motor está segurando a porta. Pisar no acelerador com o freio de mão puxado queima combustível e reputação; nós achamos primeiro o freio de mão.

Por que o KumoMTA deixaria de aceitar correio?

Um incidente especificamente Kumo, alarmante na primeira vez e instrutivo depois: os listeners deixam de aceitar mensagens novas, os injetores veem recusas, e a equipe conclui que o MTA caiu. Normalmente não caiu: se protegeu. Sob pressão real de memória o motor encolhe os corpos de mensagem de volta ao spool, purga os seus caches, e a margem zero deixa deliberadamente de aceitar trabalho novo até se recuperar; o health check diz unhealthy de propósito. A mesma família inclui a saturação de E/S do spool —uma camada de armazenamento que não dá conta convertendo um motor rápido num que trava— e a variante autoinfligida, um registro de diagnóstico deixado no seu nível mais loquaz até o disco encher. O diagnóstico corre pelas métricas que o motor publica sobre a sua própria memória e spool, e a correção é de dimensionamento rio acima: limites de fila pronta casados com a distribuição de tráfego, spool em armazenamento que aguente as escritas, verbosidade de registro devolvida ao sensato. A proteção se comportando não é o incidente; o dimensionamento que a tornou necessária é.

As correções que pioram tudo

Uma boa parte do trabalho de incidentes é evitar que o pânico agrave o dano, então detemos a hemorragia antes de tudo. Retentar um 421 a toda velocidade grita ao receptor justo o que o incomodou. Martelar um 5xx permanente desperdiça recursos e proclama descuido. Subir ritmos para drenar uma fila acrescenta pressão sobre um receptor que já te retém. Desabilitar a automação porque «não para de suspender coisas» tira o sistema de segurança no meio do incidente —a versão específica do Kumo de cortar os freios porque o carro não para de frear. E mudar muitas coisas de uma vez torna a causa e o efeito permanentemente incognoscíveis, o que converte um incidente de uma semana num mistério de um mês. A primeira regra de um incidente é não aprofundá-lo; alguns dos minutos mais valiosos que faturamos são os que passamos detendo as correções já em marcha.

Picos de reclamações: a causa silenciosa

Atrás de muitas quedas repentinas de entrega se esconde um pico de reclamações que ninguém viu chegar. Quando destinatários demais marcam o seu correio como spam —após uma campanha a um segmento rançoso, uma mudança de nome de remetente, conteúdo que as pessoas não esperavam— os receptores reagem rápido e sem cerimônia: os adiamentos sobem, a colocação escorrega, os bloqueios seguem. Diferente de um retorno, uma reclamação nem sempre deixa um rastro barulhento nos seus próprios registros; tem que ser procurada, nos loops de feedback e em correlação com o que foi enviado e a quem. Então cada incidente inclui a pergunta: um pico de reclamações explica isto? Porque se explica, nenhum ajuste de motor conserta nada: o problema é a audiência ou a mensagem, e o limiar de 0,30 % onde os receptores agem não negocia com a configuração. Achar isto cedo poupa dias de caçar a falha num motor que nunca teve culpa.

A autenticação como causa oculta

Às vezes os adiamentos não são sobre ritmo ou reputação em absoluto, mas sobre uma autenticação que quebrou sem se anunciar. Um registro SPF que se esgueirou além do seu limite de consultas depois que alguém acrescentou um provedor; uma chave DKIM rotacionada de um lado e não do outro; um alinhamento que deixou de aguentar em silêncio após uma migração de DNS; qualquer destas se lê, de fora, como correio perdendo colocação ou colhendo adiamentos estranhos sem uma mensagem que diga «a sua autenticação falhou». Em qualquer incidente de colocação sem causa óbvia, revisamos a camada de autenticação como suspeito permanente: assinaturas ativas e alinhadas para cada fluxo, SPF dentro dos seus limites, DMARC coerente com o que de fato se envia. Esconde-se bem porque um parque que «sempre funcionou» pode quebrar aqui por uma mudança feita em lugar nenhum perto da equipe de correio. Descartá-la cedo evita caçar fantasmas em arquivos de shaping enquanto a falha real está sentada num registro DNS.

Quando o problema é a mensagem, não o motor

Há incidentes onde a configuração é impecável, a reputação limpa, os retornos sem nada notável, e a colocação caiu igual, porque o correio em si mudou. Um modelo redesenhado pesado de imagens e links, um assunto que divergiu do corpo, um encurtador de URL que pegou má reputação, um domínio de tracking novo que os filtros nunca viram: qualquer destes pode caminhar um fluxo que sempre aterrissava direto para a pasta de spam. Revisamos se a queda coincide com uma mudança de conteúdo, comparando o que entregou com o que deixou de entregar —os registros datam o precipício com precisão, o que costuma datar a causa. Não somos uma agência de copy, mas os sinais técnicos que os filtros punem são legíveis, e parte do diagnóstico honesto é dizer quando a correção é editorial e não de infraestrutura. Afinar o shaping contra um problema de conteúdo é ajustar parafusos que já estavam apertados enquanto a falha viaja em cada mensagem.

Parque novo que nunca arrancou, veterano que quebrou de repente

Duas histórias de origem precisam de forenses diferentes. Uma implantação fresca que entregou mal desde o primeiro dia costuma carregar um pecado original: uma configuração de quickstart promovida a produção —o próprio projeto é explícito em que a instalação do tutorial não é de produção—, um aquecimento pulado, uma autenticação nunca terminada, uma porta 25 de saída nunca aberta de fato no provedor de nuvem, ou IPs com um histórico que ninguém revisou. Aí auditamos os alicerces um a um, porque um arranque torto se endireita voltando à base, não enviando mais. Um parque veterano que funcionou anos e quebrou numa terça é a investigação oposta: algo mudou, ainda que ninguém admita, e o KumoMTA dá a esta caça um presente que nenhum motor herdado oferece, porque a configuração é código em controle de versão. O diff entre «funcionava» e «quebrado» está com frequência sentado no histórico do repositório com uma marca de tempo e um autor. Reconstruímos a linha do tempo, a cruzamos com o que as respostas dizem, e a pequena mudança recente de grande efeito costuma se render rápido.

O que o diagnóstico do KumoMTA não promete?

Parte do diagnóstico honesto é nomear o que está fora de alcance. Não temos um botão que apague um bloqueio controlado por completo por um receptor que não publica critérios; temos o método para corrigir a causa, os canais para solicitar a remoção, e a franqueza de dizer quanto do calendário não é nosso. Não reconstruímos uma reputação arruinada numa tarde, porque as reputações se reconstroem com comportamento ao longo de semanas, não com uma mudança de configuração. E não fazemos um envio sujo entregar limpo: se a causa é uma lista comprada ou um consentimento que nunca existiu, nenhuma reparação de motor ajuda, e diremos isso em vez de vender uma ficção reconfortante. Preferimos prometer menos e cumprir do que prometer um milagre e acrescentar decepção ao seu incidente. Saber o que não se pode fazer é parte de fazer bem o que se pode.

O que precisamos de você para começar

Quanto mais rápido pudermos ler, mais rápido a causa aparece, e a lista é curta. Acesso de leitura aos registros de entrega, à política e às métricas: aí vive a evidência. Uma linha do tempo tal como você a viveu: quando começou, o que notou primeiro, e sobretudo o que mudou nos dias ao redor —uma edição de DNS, um IP novo, uma campanha incomum, uma atualização, um injetor novo. Essas respostas a «o que mudou?» costumam ser o fio que desenrola o nó inteiro, e com a política em controle de versão, «o que mudou» muitas vezes tem uma resposta literal que podemos ler. Um punhado de mensagens de rejeição reais ganha de qualquer paráfrase delas. E a versão do motor mais o arquivo de política, que é o mesmo checklist que o próprio projeto pede quando um problema pode ser um bug genuíno —um pedido que montamos dormindo. Você descreve o que vê; nós traduzimos os códigos numa causa e num plano.

Como trabalhamos um incidente

Deliberadamente metódicos, porque as mãos apressadas são as que quebram coisas. Primeiro estabilizamos: deter as correções que pioram, suspender deliberadamente onde a pressão faz dano, conter. Depois diagnosticamos sobre evidência —registros, histórico de automação, estado de fila, reputação— até ter uma causa, não uma suspeita. Depois a correção certa, que muitas vezes é baixar o ritmo, esperar e ajustar em vez de empurrar, aplicada uma mudança de cada vez e validada contra os números à medida que a entrega se recupera. E por último o relatório: o que aconteceu, por quê, o que foi mudado, e o que evitará que volte, confirmado junto à política, onde o próximo a responder de fato o encontrará. A cobertura abrange fusos horários europeus, norte-americanos e latino-americanos, porque os incidentes de entrega não respeitam o horário de escritório. A diferença entre um incidente gerenciado e um sofrido é alguém com o contexto e a calma para ler a situação antes de agir sobre ela.

O relógio, e o padrão por trás do fogo

Num incidente de entrega o tempo é dinheiro literal —cada hora que o correio não aterrissa é receita que não converte, e cada dia que um problema de reputação corre o torna mais caro de reverter, porque o dano se compõe. A velocidade de diagnóstico é portanto a alavanca que importa, e não vem de agir rápido às cegas; vem de saber onde olhar e reconhecer o padrão à vista, que é o que operar o mesmo motor em produção compra. Mas a pergunta que poupa dinheiro além desta semana é por que o fogo começou. Muitos incidentes são sintomas: um aquecimento que produzirá mais 421, um desenho de pools que mistura reputações, uma regra de automação que vai transbordar de novo, uma lista azedando em silêncio. Quando fechamos um incidente dizemos a você se foi um evento isolado ou a ponta visível de um padrão, e o que seria preciso para não nos encontrarmos de novo. Essa leitura é o que separa um remendo de uma correção, e é com frequência o argumento para passar de nos chamar quando arde a nos ter vigiando para que não arda, com as causas de fundo geridas como otimização em vez de emergências.

Se você está no meio de um incidente, o primeiro passo é entender o que acontece: a auditoria gratuita de 25 pontos dá uma leitura rápida do seu envio e do seu KumoMTA e nos diz onde olhar primeiro. Se a origem se revelar viver por completo fora do motor, a auditoria de entregabilidade a persegue onde ela vive. Em qualquer caso: evidência primeiro, depois ação, nunca o contrário.