Sistema de feeback SPFBL
Diversos serviços anti-spam disponibilizam métodos de envio de alertas, para que os administradores de serviço de e-mail consigam saber sobre denúncias contra seus próprios remetentes. Estes alertas são muito importantes para o administrador do serviço, pois abusos em demasia podem comprometer a reputação do IP usado pelo serviço. Se a reputação do IP estiver comprometida, vários provedores podem deixar de receber mensagens daquele serviço.
O sistema de alerta mais conhecido é o Feedback Loop (FBL). O grande problema deste sistema é que depende de cadastro prévio em cada provedor de destino. Ou seja, se o administrador do serviço de e-mail quiser ter amplo acesso às informações de denúncia contra seus remetentes, deve se cadastrar em cada provedor com sistema FBL.
Esse procedimento de cadastro FBL é oneroso e complicado. Por este motivo, o projeto SPFBL criou um prefixo de rejeição especial, usando a própria a camada SMTP, para que os administradores dos serviços de envio possam obter informações sobre denuncias, de tal forma que não precisem se cadastrar nos provedores com sistema SPFBL.
Sobre o sistema de reputação SPFBL
O sistema de reputação SPFBL consiste em capturar a contagem de todas as mensagens legitimas (HAM) e a contagem de mensagens ilegítimas (SPAM) dentro de um determinado período de tempo, para cada IP de origem, sendo que este período nunca será maior que sete dias. Esta informação é coletada em todos os colaboradores do projeto SPFBL, através de uma rede P2P.
Utilizando as duas contagens, é calculada a proporção de SPAM pelo volume total de envio, que será a soma de HAM e SPAM daquele IP:
P = SPAM /(HAM+SPAM)
Se esta proporção ultrapassar o limiar de 50%, o IP será listado na DNSBL do SPFBL.net.
Como identificar um prefixo de rejeição SPFBL
O prefixo de rejeição SPFBL é gerado na camada SMTP e composto pelo código 5.7.1, que significa que o envio não é autorizado, mais a palavra SPFBL, que significa que houve pontuação negativa, com incremento da contagem SPAM:
5.7.1 SPFBL <message>
A mensagem, que sucede o prefixo, descreve o motivo da pontuação negativa.
Como limpar a reputação de um IP
Todo administrador de serviço de envio de e-mail deve determinar políticas de uso aos seus clientes e monitorar o prefixo de rejeição SPFBL nos arquivos de LOG do MTA dos últimos sete dias:
egrep "5\.7\.1.+SPFBL" <mta_log_file>
Se estiver usando o Exim, o administrador pode encontrar estes registros com o seguinte comando:
exigrep "5\.7\.1 SPFBL" /var/log/exim4/mainlog*
Se estiver usando o cPanel, o administrador pode encontrar estes registros com o seguinte comando:
exigrep "5\.7\.1 SPFBL" /var/log/exim_mainlog*
Caso algum sistema, que use o serviço SPFBL, receba um volume demasiadamente grande de SPAM e gere rejeições com este prefixo, o administrador do sistema de origem deve advertir ou banir o remetente que está enviando o SPAM rejeitado. A meta é que o MTA de origem não receba novas rejeições com este prefixo, cuja consequência será um ponto negativo para cada rejeição.
Not allowed to send mail
Essa rejeição acontecerá quando a política de SPF do remetente não permitir que o IP de origem envie seus e-mails. Para saber mais sobre as diretivas do SPF, visite http://www.open-spf.org/SPF_Record_Syntax/
Rejeição por bloqueio temporário
Pode ocorrer da rejeição ser motivada por bloqueio temporário. Neste caso, uma URL será enviada dentro da mensagem:
5.7.1 SPFBL BLOCKED https://matrix.spbl.net/...
No caso de bloqueio indevido, será necessário realizar o procedimento de liberação. O procedimento de liberação, por meio da URL, depende da interação do destinatário. Neste caso, é importante que o remetente entre em contato com o destinatário, por outro meio de comunicação, para avisar que foi bloqueado indevidamente pelo sistema anti-spam e irá iniciar o processo de liberação. Uma vez iniciado o processo, o destinatário irá receber um e-mail do sistema:
O remetente 'leandro@spfbl.com.br' deseja lhe enviar mensagens porém foi bloqueado pelo sistema como fonte de SPAM.
Se você confia neste remetente e quer receber mensagens dele, acesse esta URL e resolva o reCAPTCHA:
http://matrix.spfbl.net/<ticket>
Se o destinatário finalizar este procedimento, o sistema irá remover todos os bloqueios que impeçam a aceitação da mensagem e irá registrar o remetente na whitelist do destinatário, de tal forma que o MTA do destinatário passe a aceitar incondicionalmente todas as mensagens daquele remetente para o mesmo destinatário.
Rejeição por bloqueio permanente
Pode ocorrer da rejeição ser motivada por bloqueio permanente. Neste caso, nenhuma URL será enviada dentro da mensagem:
5.7.1 SPFBL permanently blocked.
Quando isso ocorrer, significa que o administrador do sistema de recebimento realizou um bloqueio permanente daquele remetente, cuja liberação depende de contato direto com esse administrador. Essa rejeição pode ser entendida como uma solicitação de opt-out.
Rejeição por banimento
Pode ocorrer da rejeição ser motivada por banimento. Neste caso, nenhuma URL será enviada dentro da mensagem e sua conexão será derrubada:
5.7.1 SPFBL permanently banned.
Quando isso ocorrer, significa esse remetente está cometendo abuso malicioso em excesso. Você deve investigar o caso para fazê-lo parar.
Como identificar futuros spamtraps
Os endereços desativados são registrados como inexistentes no serviço SPFBL, retornando o seguinte prefixo:
5.1.1 SPFBL <message>
Todas as rejeições, com este prefixo, são o sinal de que tal endereço de e-mail deve ser removido imediatamente da lista de contatos ou da lista de e-mail marketing.
Caso esta remoção não seja feita, corre-se o risco do serviço de disparo ser listado na rede SPFBL, pois o endereço pode ser convertido em spamtrap a qualquer momento. A rigor, cada endereço de e-mail é convertido em spamtrap um ano após sua inclusão na lista de destinatários inexistentes. Disparos com alto volume de destinatários inexistentes também pode fazer com que o IP seja listado.
Ainda que endereços de spamtrap permaneçam em alguma lista de contatos, sem conhecimento do remetente, existe um mecanismo que simula o bloqueio do remetente pelo suposto destinatário, que seria na verdade um robô e não um destinatário real. Esse bloqueio é realizado de forma pseudo-aleatória, para que não seja possível que o remetente descubra quais endereços são de destinatários reais ou quais são spamtraps. Caso o bloqueio automático por spamtrap seja realizado, o remetente deve considerar o caso exatamente como se fosse um destinatário real e removendo seu endereço da lista de contatos, pois estaria removendo na verdade um spamtrap sem se dar conta disso.
Identificação inválida do remetente
Nos casos onde o serviço de e-mail não tiver validação FCrDNS, e ao mesmo tempo não houver validação do remetente por SPF, poderá ocorrer das mensagens serem rejeitadas com a seguinte mensagem:
5.7.1 SPFBL invalid sender indentification.
Basta corrigir o FCrDNS ou corrigir o SPF do remetente para que as mensagens passem a ser aceitas normalmente.
Recursos de segurança não suportados
Algumas vezes, o MTA não aceitará recursos de segurança, como STARTTLS ou AUTH. Portanto, a persistência de tentativas desses comandos pode causar problemas de reputação. Todos os recursos de segurança não aceitos serão rejeitados com o prefixo 5.7.4.
Se o seu MTA receber uma rejeição para o comando STARTTLS, você deverá corrigir o seu MTA para não tentar usar esse comando quando o comando EHLO não responder a esse comando como uma opção:
5.7.4 SPFBL TLS not available.
Se o seu MTA receber uma rejeição por comando AUTH, você está fazendo isso muito errado ou provavelmente você está procurando por vulnerabilidades de sistema:
5.7.4 SPFBL authentication not supported.
Neste último caso, o seu MTA será bloqueado imediatamente.
Feedback por meio de envio de ARF
Algumas instâncias SPFBL, de versões mais recentes, estão preparadas para envio de Abuse Reporting Format (ARF) para administradores de serviço de envio de e-mail. Para que esse serviço funcione corretamente, a tecnologia DNS Abuse List (DNSAL) foi criada para determinar qual endereço de e-mail é responsável por cada IP de serviço de envio de e-mail na Internet.
Se sua empresa tiver interesse em passar a receber ARFs de algumas instâncias do SPFBL, solicite um orçamento de inclusão de cada range de IP em nossa DNSAL. Todas as novas instâncias SPFBL estão preparadas para consultar nossa DNSAL a fim de determinar qual endereço de e-mail deve ser enviado o ARF.
Links externos
Enhanced Mail System Status Codes
Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry