Filas e backoff: como funcionam de verdade as retentativas e os diferimentos

Backoff exponencial: o padrão, e por quê

Quando uma mensagem é diferida, o seu servidor não reintenta de imediato e sem parar; usa backoff exponencial, alargando o intervalo entre tentativas à medida que as falhas se acumulam. A primeira retentativa pode disparar em poucos minutos, a seguinte em quinze, depois trinta, depois uma hora, depois mais, até o ponto em que o servidor desiste. A lógica equilibra duas necessidades em conflito: reintentar cedo o bastante para limpar rápido um problema breve, e esperar o bastante para não martelar um receptor que precisa de tempo. A tabela mostra um calendário orientativo; os intervalos exatos se configuram, mas a forma — curto no começo, alargando-se de forma sustentada — é quase universal porque é o que fazem os remetentes com bom comportamento e o que os receptores esperam ver.

Greylisting: o atraso deliberado

O greylisting merece a sua própria explicação porque é o diferimento que a maioria dos remetentes encontra com mais frequência, e alarma quem não o entende. Um receptor com greylisting rejeita temporariamente o correio de uma combinação que não viu antes — o trio de IP de envio, endereço do remetente e endereço do destinatário — e o aceita em uma tentativa posterior. O truque descansa em uma diferença de comportamento: um servidor de correio real, ao receber uma falha temporária, reintenta com diligência, enquanto muita ferramenta de spam dispara uma vez e segue. Assim o atraso filtra os spammers preguiçosos ao custo de uns minutos para todos os demais. Na prática, uma mensagem com greylisting entrega na segunda ou terceira tentativa, normalmente em quinze a trinta minutos, e você não tem que fazer nada: a sua fila se encarrega. O conserto de fundo, onde você quer pular o atraso, é a autenticação: um SPF, DKIM e DMARC bem alinhados permitem que muitos receptores reconheçam você e pulem o greylisting por completo.

Quando um diferimento vira bounce

Um diferimento não é para sempre. O seu servidor reintenta durante um máximo configurado — de um dia a vários dias, normalmente — e se o receptor segue se negando quando essa janela se fecha, o servidor para de tentar e gera um bounce permanente próprio de volta ao remetente original. É assim que uma falha puramente temporária no outro extremo pode aflorar, com o tempo, como um bounce duro nos seus registros, ainda que o receptor nunca tenha devolvido um 5xx. A lição prática é tratar os diferimentos persistentes como um problema em vez de como algo que se arrumará sozinho. Uma mensagem que leva horas diferida, subindo a escada do backoff sem aceitação, vai a caminho de virar bounce, e as falhas brandas repetidas do mesmo provedor significam que algo sistêmico — reputação, autenticação, throttling — precisa de atenção antes de a janela de retentativa se esgotar em silêncio.

Os padrões que os receptores vigiam

Convém lembrar que reintentar é em si um comportamento que o receptor observa e julga. Um remetente que usa um backoff padrão e crescente parece um sistema de correio legítimo e bem configurado, e ganha confiança com o tempo. Um remetente que reintenta de forma agressiva — a mesma mensagem batendo contra o receptor a cada poucos segundos — parece quebrado ou hostil e pode ganhar um bloqueio mais duro pelo incômodo. A metáfora que encaixa é bater em uma porta: uma batida educada, repetida em intervalos sensatos, está bem; a mesma batida martelada sem parar vira razão para deixar de abrir. Pior ainda, reintentar antes de passar uma janela de greylisting indicada muitas vezes só reinicia o relógio do receptor, então a impaciência literalmente alonga o atraso que pretendia encurtar. O espaçamento respeitoso não é só cortesia; é mais rápido.

Throttling frente a greylisting: problemas distintos

Duas das causas de diferimento mais comuns pedem respostas opostas, e confundi-las desperdiça esforço. O greylisting é sobre identidade — o receptor ainda não reconhece você — e o conserto é reintentar com normalidade e autenticar bem, após o que ele cessa. O throttling é sobre ritmo — você envia rápido demais para o que a sua reputação com aquele receptor permite agora mesmo — e o conserto é baixar o ritmo, pautando os seus envios àquele destino em vez de simplesmente reintentar a mesma avalanche. Ajustar o seu backoff de retentativa não faz nada por um problema de throttling, porque a questão é com que rapidez você envia no conjunto, não quando reintenta; ao contrário, pautar o seu ritmo de envio não faz nada pelo greylisting, que só quer uma segunda tentativa. Diagnosticar qual você enfrenta — normalmente pelo código e por se os diferimentos escalam com o seu volume — decide se você mexe no botão do backoff ou no do ritmo.

Como os provedores sinalizam o throttling: explícito e silencioso

O throttling se manifesta de duas formas, e a silenciosa pega as pessoas. A explícita é honesta: o receptor devolve um 4xx, normalmente um 421, que diz com todas as letras que você atingiu um limite de frequência e deveria ir mais devagar. A sua fila vê o código, faz backoff e reintenta, e o sinal é fácil de ler. A silenciosa é mais sutil: em vez de uma resposta clara de limite, o receptor simplesmente aceita as suas conexões mais devagar, alonga as respostas, ou roteia calado mais do seu correio para o spam à medida que você empurra volume. Não há erro óbvio sobre o qual alertar, só uma lentidão que se infiltra e um abrandamento da colocação. Detectar o throttling silencioso exige vigiar as métricas certas — tempos de conexão que se esticam, taxa de aceitação que cai, profundidade de fila que sobe sem um pico equivalente em nenhum código — em vez de esperar uma queixa explícita. Os receptores que freiam em silêncio dizem a você para baixar o ritmo com a mesma firmeza que os que o dizem; você só tem que escutar com mais atenção.

Conexões, concorrência e como alimentam os diferimentos

O volume não é o único que os receptores limitam; também lhes importa quantas conexões você abre de uma vez e quantas mensagens empurra por cada uma. Abra conexões simultâneas demais a um provedor, ou mantenha-as tempo demais, e você dispara limites de concorrência que afloram como diferimentos mesmo com um volume total modesto. Por isso dois remetentes que empurram a mesma contagem diária podem ver taxas de diferimento muito distintas: um reparte o seu correio em conexões sensatas e constantes, enquanto o outro martela o receptor com uma rajada de sessões paralelas que parece agressiva. Ajustar a concorrência — quantas conexões por destino, quantas mensagens por conexão, com que rapidez você sobe o paralelismo — é parte do pautado, e errar produz diferimentos que nenhum ajuste de backoff curará, porque o problema é a forma do seu tráfego, não o momento das suas retentativas. Os receptores premiam o tráfego que parece tranquilo e constante acima do que chega em picos.

A profundidade de fila como métrica de saúde

O número mais útil para detectar cedo problemas de diferimento é a profundidade da sua fila de retentativa. Em um sistema sadio, as mensagens entram em retentativa e se limpam mais ou menos no ritmo em que chegam, então a fila fica baixa e estável. Quando os diferimentos começam a superar as retentativas bem-sucedidas, a fila cresce, e uma fila que sobe de forma sustentada — sobretudo rumo a um provedor — é um aviso precoce e mensurável de que algo sistêmico vai mal: estão freando você, a sua reputação escorregou, a sua autenticação falha, ou um receptor está caído. Vigiar a profundidade de fila por provedor junto à taxa de 4xx converte uma vaga sensação de lentidão em um sinal concreto e a tempo. É uma das métricas que pomos em primeiro plano quando levamos a entregabilidade gerenciada, justo porque uma fila crescente detectada a tempo é um problema resolvido antes de virar uma onda de bounces.

Ajustar as retentativas no seu próprio MTA

Quem opera a sua própria infraestrutura tem controle direto sobre o backoff, e uns poucos princípios evitam que esse controle se volte contra. Fixe a primeira retentativa em ou acima da janela de greylisting que um receptor indique, porque reintentar antes só ganha outra falha temporária. Mantenha o intervalo de varredura de fila não mais longo que o seu backoff mínimo, para que o calendário que você configurou seja o que de verdade corre. Use o pautado por destino — controlar com que rapidez você envia a um receptor concreto — para sintomas de throttling, e reserve as mudanças de backoff para diferimentos genuínos, já que arrumam problemas distintos. Evite forçar esvaziamentos de fila repetidos, que reiniciam a janela de espera do receptor e alongam os atrasos, e evite temporizadores de backoff muito curtos, que criam ruído e mais falhas temporárias. Esses são justo os controles que uma instalação limpa de PowerMTA configura de propósito, e o tipo de ajuste que devolve uma tempestade de diferimentos a uma entrega fluida quando nos chamam para diagnosticar uma queda de entrega.

Diferimentos durante o aquecimento

Um IP novo recebe muitos diferimentos, e isso é normal em vez de alarmante. Os receptores são cautelosos com as identidades desconhecidas, então diferem o correio de um remetente novo enquanto decidem se confiam nele, e os diferimentos cedem à medida que a reputação se acumula. Durante o aquecimento, essas respostas 4xx são retroalimentação: um provedor que começa a diferir você mais à medida que você sobe volume está dizendo para frear a rampa, e respeitar esse sinal — manter o volume, deixar a aceitação se recuperar — é como um aquecimento segue o seu curso. Empurrar mais forte contra diferimentos crescentes é como ele descarrila. A interação entre diferimentos e rampa é estreita o bastante para que tratemos lê-los como parte de aquecer um IP, subindo o volume em degraus e lendo as respostas dos receptores a cada passo em vez de acelerar contra os seus avisos.

Diferimentos e correio urgente

Há correio que não pode esperar, e os diferimentos são um problema particular para ele. Uma redefinição de senha, um código de uso único, uma confirmação de pedido: estes perdem boa parte do seu valor se chegam vinte minutos tarde porque um receptor com greylisting diferiu a primeira tentativa. O instinto é reintentar esse correio mais rápido, mas como vimos isso sai mal. As melhores respostas são estruturais. Envie o correio transacional de uma infraestrutura com reputação forte e consolidada e autenticação limpa, para que ele seja menos diferido de entrada; separe-o do tráfego em massa e promocional para que um problema de throttling no fluxo de marketing nunca atrase uma redefinição de senha; e, para as mensagens mais críticas, tenha presente que o correio é por natureza um meio de melhor esforço e que a entrega de verdade instantânea talvez precise de um segundo canal. Separar os fluxos para que o correio urgente viaje pela sua própria rota bem aquecida é uma das razões mais claras para segmentar o envio por tipo em vez de empurrar tudo por uma única fila.

O custo de gerir mal os diferimentos

Os diferimentos mal geridos saem caros de formas que se acumulam. O custo imediato é o atraso: correio que deveria chegar em segundos fica em fila durante horas, e as mensagens urgentes perdem o seu propósito. O custo seguinte são os bounces, quando diferimentos que nunca se limpam envelhecem fora da janela de retentativa e viram falhas permanentes, então um problema de throttling que você ignorou se converte em correio não entregue e em um pior histórico de remetente. Depois vem a reputação: reintentar de forma agressiva, as filas crescentes e as taxas de falha branda em alta são em si sinais para os receptores de que você não é um remetente bem-conduzido, o que ganha a você ainda mais diferimentos — o laço se alimentando sozinho. E embaixo de tudo está o custo de oportunidade de voar às cegas: uma equipe que não vigia a sua fila nem as suas métricas de diferimento fica sabendo de cada um deles só depois que já danificou a entrega. Nada disso é dramático em um momento concreto, que é justo por que é perigoso; os problemas de diferimento erodem em silêncio até alguém notar que o correio vai lento e os bounces subiram.

O que você não deve fazer

Um punhado de hábitos converte de forma fiável um problema de diferimento gerenciável em um pior. Não reintente mais rápido para «forçar» a entrega; os laços de retentativa agressivos ganham suspeita e podem endurecer um bloqueio brando em um real. Não force esvaziamentos de fila repetidos esperando empurrar o correio, porque cada esvaziamento pode reiniciar a janela de espera do receptor e alongar o atraso. Não ponha temporizadores de backoff minúsculos, que geram uma tempestade de tentativas prematuras e mais falhas temporárias. Não ignore uma fila crescente dando por certo que as retentativas a resolverão, porque um diferimento que nunca se limpa acaba em bounce. E não ajuste os seus temporizadores de retentativa quando o problema real é de ritmo — nem paute os seus envios quando o problema real é greylisting — porque aplicar o conserto errado deixa intacta a causa de verdade. A paciência e o botão certo ganham do pânico e do botão errado sempre.

O que uma entrada de log de diferimento diz a você

Cada diferimento deixa uma linha nos seus registros, e essa linha é um pequeno pacote de diagnóstico se você a lê. Uma entrada útil registra o domínio do destinatário, o IP de envio usado, a resposta SMTP que o receptor deu — tanto o código de três dígitos quanto o código melhorado e o seu texto —, a hora da tentativa, e quando está agendada a próxima retentativa. Lê-las juntas responde às perguntas que importam: que provedor difere, com que código, quantas horas tem a mensagem, e se o backoff se comporta. Um diferimento de greylisting mostra um 451 4.7.1 que se limpa em uma tentativa posterior; um de throttling mostra um 421 que escala com o seu volume; um escorregão de reputação mostra diferimentos que se alargam nas mensagens a um provedor sem aceitação. Comparar a idade em fila, o código de resposta e o comportamento da próxima retentativa antes de mudar nada é a disciplina que impede você de ajustar o botão errado. Quem lê a entrada de log sabe se espera, freia ou investiga; quem lê só o agregado «a entrega vai lenta» está adivinhando.

Ler os diferimentos por provedor

Os diferimentos só ganham sentido provedor por provedor, porque cada receptor tem os seus próprios limites, a sua própria política de greylisting e a sua própria visão de reputação de você. Uma taxa de diferimento que está bem para um provedor pode ser sinal de problema em outro, e um backoff que encaixa com a janela de greylisting de um receptor pode ser errado para a de outro. Num público brasileiro isso inclui os provedores locais — UOL, Terra e BOL — ao lado de Gmail, Outlook e Yahoo, cada um com o seu próprio comportamento de greylisting e de throttling que convém ler à parte, porque um backoff afinado para a janela do Gmail pode não encaixar com a de um provedor local. Os remetentes que gerem bem os diferimentos os vigiam segmentados por destino: este provedor faz greylisting nos primeiros envios e os limpa ao reintentar, aquele outro faz throttling porque o volume subiu rápido demais, um terceiro difere por um buraco de reputação. Essa vista por provedor, combinada com os sinais de profundidade de fila e taxa de 4xx, é o que deixa você responder de forma específica — pautar o que freia, seguir reintentando o que faz greylisting, investigar aquele cujos diferimentos parecem um escorregão de reputação — em vez de tratar um conjunto variado de problemas como um único e indiferenciado «o correio vai lento».

Em resumo

Um diferimento é uma conversa, não um veredito. O receptor devolve um 4xx para dizer «depois», o seu servidor enfileira a mensagem e reintenta com um backoff crescente, e a troca se resolve em entrega se você responder bem, ou em bounce se não, uma vez que a janela de retentativa se esgota. Gerencie-o lendo o código para conhecer a causa, fazendo backoff com educação em vez de martelar, distinguindo o throttling do greylisting e mexendo no botão certo, vigiando a profundidade de fila por provedor como o seu sinal de alerta precoce, e autenticando limpo para que você seja diferido menos de entrada. Faça isso e os diferimentos seguem sendo o que devem ser: uma pausa breve e autorresolúvel a caminho da caixa. Gerencie-os mal e eles se coalham em atrasos, bounces e uma reputação que ganha a você ainda mais diferimentos — o laço do qual convém ficar de fora. Os remetentes que nunca parecem brigar com a sua fila não têm sorte; autenticam limpo, pautam o seu tráfego, fazem backoff com educação e leem os seus registros, e assim os diferimentos que recebem se limpam calados, como o sistema pretende.