Funcionalidades

Algumas alterações foram implementadas no SPFBL com a intenção de minimizar as respostas negativas ou incoerentes do SPF convencional.

 

Correção de sintaxe SPF

 

As vezes alguns administradores de DNS acabam cometendo erros pequenos ao registrar um SPF para um determinado domínio. O SPFBL é capaz de fazer algumas correções destes erros.

 

Por exemplo, o domínio “farmaciassaorafael.com.br”, com o registro SPF “v=spf1 ipv4:177.10.167.165 -all”, retorna falha no SPF convencional, mas o SPFBL reconhece um REGEX CIDR dentro de um token e deduz que o administrador queria dizer “ip4” invés de “ipv4”.

 

Além disto, se um mecanismo não puder ser reconhecido pelo SPFBL, este mesmo mecanismo é apenas ignorado, dando chance de acontecer um match em outros mecanismos que são reconhecidos pelo SPFBL.

 

Merge de múltiplos registros SPF

 

Se o administrador registrar vários registros SPF para um determinado domínio, o SPFBL faz o merge de todos eles e considera como se fosse apenas um.

 

Mecanismos permissivos demais

 

O SPF convencional permite o registro de alguns mecanismos que são permissivos demais ao ponto de retornar sempre PASS para qualquer parâmetro utilizado na consulta.

 

Um destes mecanismos é o +all, que no SPFBL foi abolido e substituido por ?all sempre que encontrado.

 

Os mecanismos de blocos de IP que contém algum endereço IP reservado são ignorados pelo SPFBL.

 

Consideração de IPv6 para mecanismo “mx” sem máscara

 

Sempre que o mecaninsmo “mx” for utilizado sem a máscara num registro SPF, o SPFBL irá considerar tanto IPv4 quanto IPv6 do host para manter compatibilidade de pilha dupla neste MX.

 

Quando a máscara for mencionada, então não é possível utilizar esta solução pois as máscaras de IPv4 e IPv6 são incompatáveis.

 

O protocolo SPF convencional não prevê pilha dupla em mecanismo “mx”, então é possível que uma consulta SPF convencional não resulte em PASS sendo que a mesma consulta resulte PASS no SPFBL.

 

Domínios sem registro SPF

 

Quando um domínio não tem registro SPF, o SPFBL considera a recomendação “best-guess” do SPF: best-guess.

 

Porém mesmo considerando esta recomendação, alguns domínios que não tem registro SPF não funcionam bem com o “best-guess”. Nestes casos é possível registrar um “best-guess” específico para um determinado domínio. Por exemplo, o domínio “yahoo.com.br” não tem registro SPF e costuma enviar os seus e-mails pelos servidores listados no registro SPF do domínio “yahoo.com”. A solução para este problema é adicionar o “best-guess” “v=spf1 redirect=yahoo.com” para o domínio “yahoo.com.br”.

 

Quantidade máxima de interações DNS

 

O SPF convencional tem um limitador que finaliza a busca quando ele atinge 10 interações de DNS. O motivo deste limitador é garantir que não haja loop infinito, porque a estrutura de dados do SPF é um grafo, e também para evitar respostas com alta latência. O problema deste limitador é que diversos administradores de domínio utilizam o mecanismo include no SPF para transferir a responsabilidade de configuração correta aos administradores de servidores de e-mail e as vezes estes últimos abusam do mecanismo include, gerando um grafo grande demais.

 

O SPFBL não trabalha com grafo e sim com árvore. Isso é feito ignorando os nós já processados anteriormente.

 

O SPFBL não tem o limitador de 10 interações de DNS do SPF convencional porque além de trabalhar com estrutura em árvore utiliza cache de registros SPF, que agiliza o processamento. A única limitação que existe é a limitação de nós abaixo de 10 níveis na árvore, que seria um absurdo atingir este limite. Estes nós abaixo de 10 níveis são então apenas ignorados, uma poda de árvore, e atingir este limite não é considerado uma falha de SPF. Isto faz com que as falhas por limite sejam extintas no SPFBL.

 

Se a árvore for grande demais para ser percorrida e não houver registros desta árvore em cache, pode acontecer do cliente SPFBL considerar o timeout, fechar a conexão e gerar um erro temporário para o servidor da origem. Se acontecer isto, o SPFBL continua a varredura da árvore em background, mesmo com a conexão fechada, e quando a mesma consulta for realizada novamente, a resposta do SPFBL será imediata porque a árvore já estará toda em cache.

 

Cache dos registros SPF

 

O SPFBL mantém em cache todos os registros SPF encontrados e procura mantê-los atualizados em background de acordo com o volume de consultas de cada um deles.

 

Registro de provedores de e-mail

 

É possível registrar um provedor de e-mail no SPFBL. Sempre que um provedor for registrado, o SPFBL vai considerar os respectivos endereços de e-mail como responsável pelo envio, sendo que o provedor será isentado da responsabilidade.

 

Denúncia de SPAM

 

Quando o resultado da consulta SPFBL retorna um ticket, dentro dele segue informações sobre o responsável pelo envio e a data que a consulta foi realizada. Este ticket pode ser utilizado para formalizar uma denúncia, que contabiliza para o responsável o peso de denúncia. Cada denúncia expira em sete dias após a data da consulta e não pode ser feita após cinco dias da consulta.

 

Greylisting

 

A mensagem será atrasada 25min sempre que o responsável estiver com reputação YELLOW.

 

Blacklisted

 

A mensagem será marcada como SPAM usando o padrão “X-Spam-Flag: YES” do Spamassassin.

 

Serviço DNSBL

 

O SPFBL abre a porta DNS para receber consultas padrão DNSBL.

 

Para utilizar este serviço, é necessário registrar um host “dnsbl” como NS apontando para o hostname dnsbl.<dominio>, onde este hostname aponta para o IP do servidor SPFBL.

 

Exemplo: dnsbl.spfbl.net (serviço disponível)