[MASOCH-L] SPF LOCAWEB

[Leandro Carlos Rodrigues]

Em 26/07/2012 12:04, Danton Nunes escreveu:
> On Thu, 26 Jul 2012, Leandro Carlos Rodrigues wrote:
>
>> Agente só recebe a mensagem porque o servidor de destino checa o SPF 
>> e bloqueia. E os casos que não há checagem de SPF?
>
> azar deles. mas ainda assim a mensagem poderia parar em outras ratoeiras.
>

kkkkkk. Pode crer. Mas é agente sofre com a burrice deles.

>> A falha neste caso é do provedor de origem permitir enviar uma 
>> mensagem de um cliente dele com remetente de domínio de terceiro.
>
> exatamente. eu pensei uma vez, mas nunca cheguei a por no papel muito 
> menos fazer testes, na idéia de um SPF reverso. No SPF clássico é o 
> dono do domínio que diz quais endereços IP podem mandar email em nome 
> do domínio. por exemplo, o meu é assim:
>
> v=spf1 a mx ip4:187.17.47.136 ip4:187.17.37.5 ip4:187.17.38.0/26 
> ip6:2001:12c4:f0da:5e::/64 -all
>
> (é, o endereço IPv6 é essa gracinha mesmo). No SPF reverso seria o 
> contrário, o dono do IP diz se esse IP está autorizado a enviar em 
> nome de um dado domínio. Para isso usaria uma cláusula TXT semelhante 
> ao SPF, mas no domínio de tradução reversa (xxx.in-addr.arpa ou 
> xxx.ip6.arpa). Por exemplo, para eu dizer que 187.17.38.5 tem direito 
> de enviar email em nome de inexo.com.br, colocaria um registro TXT 
> assim associado ao nome 5.38.17.187.in-addr.arpa:
>
> v=rspf1 +inexo.com.br -all
>
> poderia ser uma expressão regular ou com coringas, por exemplo:
>
> v=rspf1 +*.inexo.com.br -all
>
> um provedor de acesso para pessoa física poderia por um registro assim 
> para todos os endereços IP da rede de usuários "dialup":
>
> v=rspf1 -all
>
> indicando que NENHUM deles estaria apto a enviar email diretamente. 
> muito melhor que lista negra!
>
> a validação de um remetente agora seria feita com duas fontes de dados 
> que podem ser independentes ou não: o dono do domínio e o dono dos 
> endereços IP. A política resultante poderia ser: testamos o SPF e o 
> RSPF, só passa se passar nos dois! mas é claro que ainda sobraria 
> muita margem para falsificação.
>
> ATENÇÃO SENHORES PROFESSORES: desenvolver e testar um protocolo destes 
> daria um lindo trabalho de graduação, se futucar mais, até dissertação 
> de mestrado! Aproveitem! Usem o trabalho de seus escra^H^H^Htagiários!
>
> (pelo caminho que estamos tomando seria melhor passarmos esta conversa 
> para a lista do GTER, que acham?)
>

Acho que sim. Mas eles não me deram acesso a essa lista e por isso 
desejo-lhes muita sorte na discussão além do que vocês são muito mais 
preparados tecnicamente do que eu.

>> Concordo totalmente contigo. O DKIM certamente seria a melhor opção 
>> que conheço. Não precisaria nem checar o SPF.
>
> sim, porque o tipo de associação que o DKIM faz é mais "íntima" que a 
> do SPF e leva em conta o conteúdo da mensagem. e uma coisa que detesto 
> no SPF é o fato de usar um dado de rede (endereço IP) na camada de 
> aplicação, quebrando a desejável ortogonalidade entre camadas. também 
> causa uma baita dor de cabeça com os .forward da vida, necessitando de 
> gambiarras tipo reescrita de envelope.
>

Tembém odeio esses malditas reescritas. Agente cria varias regras chuchu 
beleza e depois descobre que não valem para estes casos.

> O lado ruim do DKIM é que não pode ser usado ainda na fase de envelope 
> do SMTP pois depende da ingestão de todo o conteúdo da mensagem para 
> ser processado.
>

Por isso que a proposta de criar um novo protocolo é boa. Numa tacada só 
agente elimina as reescritas, as mensagens com remetente em branco e 
embute o glorioso DKIM no protocolo fazendo com que seja, pelo menos é o 
que minha visão que pode estar limitada vê, impossível alguém enviar uma 
mensagem sem ser identificado.
Além disso acaba com esse problema do spammer contratar um provedor e 
enviar um monte de spam, e quando o IP que deram para ele for bloqueado 
ele troca de provedor mantendo o mesmo dominio para mandar mais. Agente 
resume tudo no bloqueio do dominio que é infinitamente mais fácil e 
seguro pois muitos domínios podem usar o mesmo IP na transmissão.

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