[MASOCH-L] O que você mais odeia no SPF?

[Leandro Carlos Rodrigues]

On 15/06/2015 09:24, Danton Nunes wrote:
> On Mon, 15 Jun 2015, Leandro Carlos Rodrigues wrote:
>
>> Segue as soluções que pretendo implementar, algumas já implementadas, 
>> na minha implementação SPF.
>>
>> Se alguém tiver melhores soluções, vamos discutir para chegarmos em 
>> algo que realmente será útil para todos.
>>
>>> 1. *Looping pelo mecanismo include:*
>> Resolvido registrando cada include visitado e pulando os includes que 
>> já foram visitados. Tecnicamente seria a poda da árvore: 
>> http://pt.wikipedia.org/wiki/Poda_%28computa%C3%A7%C3%A3o%29
>
> não bastaria ter um limite superior para o número de inclusões? 
> atingiu o limite declara como bichado. Infelizmente a RFC4408 não 
> estabelece tal limite.

Poderia ser assim Danton. Mas qualquer limite que estipulemos, sempre 
vai ter um conjunto de administradores infelizes que irão superá-lo. O 
problema desse maldito limite é que o administrador de um domínio 
recorre a um include, normalmente um (ex: "v=spf1 
include:_spf.locaweb.com.br ?all"). No momento do registro, o limite não 
foi alcançado. Ai que vem a merda, o administrador do domínio que foi 
usado como include (ex: _spf.locaweb.com.br) simplesmente adiciona 
outros includes, que por sua vez os demais adicionam mais e mais...

O administrador do primeiro domínio mencionado não teria como ficar 
controlando os includes alheiros e acaba se ferrando. Só vai descobrir a 
merda depois que um tempo. Veja que do ponto de vista dos 
administradores dos domínios adicionados, nem sempre eles estão errados 
pois se contar o registro deles como a raiz da árvore, eles estão 
corretos, pois a quantidade de nós para ele não ultrapassa o limite de 10.

O grande desafio seria determinar esse limite, se quisermos colocar um. 
Porém se tratando de um serviço, talvez não valha a pena. Se a árvore 
for grande demais para um domínio e a consulta for feita pela primeira 
vez (sem cache), o máximo que vai acontecer é esta primeira consulta ter 
uma latência grande, e as demais seriam instantâneas.

Por outro lado, acho que seria interessante estipular um limite mas, 
invés de dar erro ao ultrapassá-lo, simplesmente ignorar os includes a 
mais. Seria outra solução.

>
>>> 5. *Registro permissivo demais:*
>> Para os mecanismos ip4 ou ip6, testar os IPs reservados de cada 
>> versão. Se passar algum reservado, ignorar aquele mecanismo.
>
> Bingo! ::1, 127.0.0.1, ou algum endereço de anycast são os meus 
> favoritos para isto.
>
>>> 6. *Erro de sintaxe no registro:*
>> Uso de corretores, quando a correção for possível, e no caso de não 
>> ser possível, ignorar o mecanismo com erro. No caso de algum 
>> mecanismo estiver com erro, só apresentaria o erro caso nenhum outro 
>> mecanismo, com exceção do all, desse match. Se o administrador errou 
>> um mecanismo pouco importante mas manteve integro os demais, então a 
>> consulta vai funcionar para maioria dos casos.
>
> para mim, erro de sintaxe = fail. sem concessões. pode mandar uma 
> mensagem de erro própria.

A ideia de tentar corrigir as falhas de sintaxe é para tentar minimizar 
o número de reclamações por parte dos destinatários. Como o Rafael Lima 
sugeriu, o sistema poderia gravar um log para que o administrador do 
servidor de destino possa informar a cagada ao responsável pela origem, 
quando possível. Se a gente conseguir continuar recebendo as mensagens e 
ao mesmo tempo podermos avisar o responsável por um erro bobo, seria o 
melhor dos dois mundos.

Olhe este exemplo:

    farmaciassaorafael.com.br "v=spf1 ipv4:177.10.167.165 -all"

O erro de sintaxe ai é ipv4 deveria ser ip4. No spfquery convencional dá 
erro. Mas na implementação que fiz ele consegue extrair um CIDR de 
qualquer token e acaba entendendo e corrigindo o registro errado, dando 
PASS como resposta.

Agora se eu depender de avisar todos os administradores que cometeram 
erros semelhantes para fazer com que meus usuários recebam mensagens 
destes caras, eu estaria na roça! Ficaria o tempo todo fazendo isso.

Pior que esse cara ai teve a melhor das intenções, pois usou -all. Ele 
só cometeu um erro bobo na qual um sistema minimamente inteligente 
consegue superar.

>
>>> 7.*domínios com acl terminando em +all*
>> Não permitir o mecanismo +all. Vamos banir o +all. Considerar sempre 
>> SOFTFAIL quando usarem +all.
>
> de fato, isto é um caso particular de 5. eu havia sugerido sem ter 
> prestado suficiente atenção ao 5.

Beleza. Lembrei de outro caso. Sempre que o domínio não existe, o 
spfquery original dá ERROR. Eu fiquei pensando se o melhor não seria dar 
FAIL.

> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l