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

[Leandro Carlos Rodrigues]

On 15/06/2015 11:30, Danton Nunes wrote:
> 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.

Ótimo argumento. Me convenceu. Vou colocar um limite de nível na árvore.

>
>>> 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.

kkkkkk

>
>>
>> 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.

Certo. Mas quando seu usuário não receber a mensagem destes caras, eles 
vão encher seu saco. Eles tão pouco se lixando se o erro é do 
administrador infeliz da origem. Não sei ao certo que tipo de usuário 
você lida, mas com certeza os usuários de provedores de e-mail devem 
receber uma enxurrada de reclamações por conta deste tipo de problema.

Mas eu concordo que dar ERROR quando o erro de sintaxe for grosseiro 
demais para ser entendido é obrigatório, sem dúvida.

>
>> 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'.

Mas ai você precisaria que dropar a mensagem, que seria o contrário da 
proposta que seria minimizar as reclamações.

De qualquer forma você me deu uma ótima ideia agora. Daria para fazer um 
aviso automático para o responsável pelo domínio consultando o WHOIS e 
pegar o e-mail dele para enviar a mensagem.

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