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

[Rafael Henrique Faria]

Acho que no 1, poderia ser usado alguma técnica de FIRST MATCH.

Por exemplo, se o IP do servidor que está sendo usado é
127.127.127.127, e o cara possui a seguinte sintaxe:

"v=spf1 include:_spf.google.com ip4:127.127.127.127 -all"

O primeiro include nem seria feito... pois o IP está ali, liberado...
ele só iria acessar o include caso nenhum campo deste registro batesse
com o endereço do servidor em questão. E a mesma coisa para cada nível
de include.
Se o IP desejado está no 2 nível, ele nem precisa continuar para o seguintes...


2015-06-15 11:30 GMT-03:00 Danton Nunes <danton.nunes at inexo.com.br>:
> On Mon, 15 Jun 2015, Leandro Carlos Rodrigues wrote:
>
>> 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...
>
>
> mas quanto mais, mais permissivo fica, né? e estamos de acordo que muito
> permissivo deve ir pro brejo. assim não tenho qualquer dor na consciência em
> estabelecer um limite arbitrário. veja a própria RFC4408 recomenda preferir
> redirect a include.
>
>>> 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.
>
>
> eu não tenho essa benevolência toda.
>
>>
>> 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.
>
>
> no meu entender tem que dar erro e ponto final. há ferramentas automáticas
> para gerar esses registros sem qualquer erro. se o cara é principiante,
> use-as.
>
>> 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.
>
>
> o aviso pode ser automatico, uma mensagem 500 na recusa da mensagem tipo
> 'SPF syntax error'.
>
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l



-- 
Rafael Henrique da Silva Faria