Uma mensagem pode apresentar uma falha temporária antes de uma entrega posterior. Greylisting é uma causa possível. Throttling e outros problemas temporários podem produzir a mesma classe de status.
Como o greylisting funciona?
O destinatário adia temporariamente um cliente remetente desconhecido e verifica se uma tentativa posterior se qualifica como retentativa.
A RFC 6647 descreve essa técnica anti-abuso. Softwares que nunca tentam novamente não conseguem completar a entrega por essa verificação.
O destinatário retorna uma falha temporária SMTP, deixando o sistema remetente responsável por reter e reenviar a mensagem. Passar no teste de retentativa remove esse obstáculo. As demais regras de filtragem do destinatário continuam valendo.
Como o destinatário reconhece uma retentativa?
O destinatário compara informações da nova tentativa com um registro da tentativa anterior.
A RFC 6647 recomenda rastrear o IP remetente, o envelope sender e o primeiro destinatário. O envelope sender é o endereço usado para avisos de falha na entrega.
Uma alteração nesses identificadores pode fazer uma retentativa parecer uma mensagem nova. Enviar a partir de vários servidores pode, portanto, complicar a correspondência, dependendo da política do destinatário.
A RFC recomenda permitir tráfego subsequente do IP após uma retentativa bem-sucedida. Ela também recomenda expirar registros inativos, para que a permissão não precise durar indefinidamente.
Por que o greylisting pode barrar alguns e-mails indesejados?
Ele barra softwares de envio que fazem uma única tentativa e abandonam diante de uma falha temporária.
A técnica testa o comportamento de retentativa. Ela não determina se o conteúdo da mensagem é seguro ou desejado. Softwares abusivos que tentam novamente também podem passar.
O destinatário, portanto, precisa de outros sinais de filtragem. Passar pelo greylisting com sucesso não estabelece autenticação, consentimento ou boa reputação de envio.
Quanto tempo o atraso pode durar?
O atraso depende de quando o remetente tenta novamente e de quais tentativas o destinatário aceita como dentro do prazo.
A RFC 6647 recomenda uma janela padrão de retentativa de um minuto a 24 horas para acomodar cronogramas típicos de retentativa. Essa é uma faixa no lado do destinatário para reconhecer retentativas. Ela não garante entrega dentro desse período.
Por exemplo, uma retentativa após 30 segundos é cedo demais para essa janela padrão. Uma retentativa após 30 horas pode ser tratada como uma nova tentativa. Uma retentativa válida ainda enfrenta as demais verificações do destinatário.
Um remetente que tenta novamente somente após uma hora não consegue entregar pela verificação antes disso. Para um código de verificação que expira após dez minutos, essa entrega chega depois que o código se torna inutilizável.
Como você diferencia greylisting de outra falha?
Use os detalhes da resposta e o histórico de retentativas. Um código de status temporário sozinho não comprova greylisting.
| Observação | O que estabelece |
|---|---|
4xx, depois entrega bem-sucedida | Uma falha temporária foi resolvida. Greylisting é uma causa possível |
Respostas 4xx repetidas até a expiração | A entrega nunca foi concluída. O texto da resposta e o padrão de retentativa podem ajudar a identificar o motivo |
Resposta 5xx | Uma falha permanente para essa solicitação SMTP |
A RFC 6647 discute 421 ao encerrar a conexão e 450 nos demais casos. Ela não prescreve o texto da resposta, então a mensagem não precisa mencionar greylisting explicitamente.
E-mail adiado e bounces descrevem os resultados temporário e final.
O que o operador de envio deve investigar?
Confirme que a mensagem é retentada e que suas informações de identificação permanecem adequadas para a política de correspondência do destinatário.
Verifique se as retentativas alteram o envelope sender ou transitam entre IPs de envio. Verifique também se diferentes servidores MX de destino reconhecem o mesmo histórico de retentativas.
A RFC 6647 recomenda que os servidores de destino compartilhem um banco de dados de greylisting, porque uma retentativa pode chegar a um destino diferente. Uma incompatibilidade pode atrasar repetidamente e-mails legítimos.
Forneça ao operador de destino os horários das tentativas, IPs e texto da resposta quando o atraso persistir. A RFC prevê exceções gerenciadas pelo destinatário para remetentes legítimos que não funcionam bem com greylisting.
O destinatário deve aplicar greylisting em envios autenticados?
A RFC 6647 recomenda que os operadores excluam do greylisting os clientes autenticados de seu próprio serviço de envio. Esses clientes já se autenticaram para enviar e-mails, então testar se um remetente desconhecido tenta novamente adiciona um atraso evitável. Aplique a regra no serviço de recebimento ou de envio que a controla.
Para uma aplicação que usa uma plataforma de envio, revise o resultado da entrega da mensagem. Criar outro envio pela aplicação não corrige a correspondência de greylisting da primeira tentativa. Isso pode gerar duplicatas.
Em resumo
O greylisting testa o comportamento de retentativa.
Uma falha temporária pede ao servidor remetente que tente novamente. Ela não estabelece uma rejeição permanente.
Uma retentativa não garante aceitação.
A tentativa precisa satisfazer as verificações de tempo e identidade do destinatário, junto com suas outras políticas de e-mail.
O tempo depende de ambos os servidores.
A janela de retentativa do destinatário e o cronograma do remetente determinam juntos o atraso.
Adiamentos repetidos precisam de investigação.
Verifique os detalhes da resposta, as retentativas e a mudança de identificadores do remetente antes de concluir que a causa é greylisting.