[GTER] uma ideia para discussão: SPF reverso.

[Giovane Heleno]

No caso de um servidor de email com vários domínios, como um provedor de
hospedagem por exemplo... aí sim faria sentido o +all no RSPF.
Mas somente no IP do servidor.

Ou seja, este IP estaria autorizado a enviar qualquer domínio, já que é um
servidor de email compartilhado com vários domínios.


Giovane Heleno
www.giovane.pro.br



Em 28 de julho de 2012 23:00, Fernando Ulisses dos Santos <
fernando at bluesolutions.com.br> escreveu:

> Danton,
>
> Tenho algumas dúvidas sobre a aplicação dessa técnica nos links atuais das
> grandes operadoras e provedores.
>
> O cliente decide hospedar o e-mail dentro da empresa, tem 1 IP fixo (praxe
> para links xDSL). Hoje o trabalho é só pedir o DNS reverso casando com o
> DNS direto para passar por algumas validações anti-spam.
>
> Com o RSPF, além de pedir pra operadora (já que o cliente não tem poder
> sobre o DNS reverso do único IP dele) o DNS reverso, vai ter que pedir o
> cadastro dos domínios hospedados, o cliente teria que pedir um RSPF assim:
>
> "v=rspf1 +dominio1.com.br +dominio2.com.br +dominio3.com.br -all"
>
> Isso irá gerar dificuldades para lançar novos domínios para e-mail, e com
> o tempo é capaz de pegarem a manha igual no SPF e pedir cadastros assim:
>
> "v=rspf1 +*.com.br +*.br +*.com +*.net -all"
>
> Os quais a operadora de link não tem o direito de negar. Ok, é
> tecnicamente contornável, mas é o mesmo problema que tem no SPF hoje,
> exemplo: "v=spf1 ip4=128.0.0.0/4"
>
> A maior dificuldade seria para grandes provedores de domínios, imagina um
> deles, com milhares de clientes, onde um pool de dezenas servidores faz o
> MTA dos clientes, todos esses servidores deveriam ter o RSPF de todos os
> clientes:
> "v=rspf1 +cliente1.com.br +cliente2.com.br +cliente3.com.br ..... +
> cliente1001.com.br -all"
>
> Isso deixaria exposto toda a carteira de clientes do provedor, além de
> que, estouraria o tamanho do campo TXT e geraria dificuldades de validação
> e implementação (alto processamento, rotinas complexas).
>
> Se eu realmente entendi tua proposta de implementação, ela tem esses
> problemas técnicos e comerciais que inviabilizam a utilização em massa, por
> favor, diga que estou errado.
>
> Fernando Ulisses dos Santos
>
> Em 26-07-2012 17:16, Danton Nunes escreveu:
>
>
>  Esta proposta nasceu dentro de uma discussão na MASOCH-L, mas acho que o
>> GTER é o forum mais pertinente. Se isto mostrar que dá pé poderemos
>> apresentá-la ao IETF como um "draft".
>>
>> Apresento aqui o "SPF reverso", que espero venha ajudar no combate ao
>> envio não autorizado e frequentemente fraudulento de email.
>>
>> 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/26ip6:2001:12c4:f0da:5e::/64 -all
>>
>> (é, o endereço IPv6 é essa gracinha mesmo), mas ninguém pergunta para os
>> donos dos endereços se isso é verdade. então se um spammer cria uma lista
>> de SPF cujo default é +all qualquer endereço IP da galáxia internet está
>> autorizado a enviar email em nome desse domínio e a driblar várias
>> ratoeiras antispam. para que o dono dos endereços possa dizer quais
>> domínios podem enviar email a partir deles proponho o SPF reverso.
>>
>> No SPF reverso 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!
>>
>> os patifes que tem SPF com +all para fazer com que seus bots possam
>> ganhar 'pass' seriam impedidos, já que o SPF reverso mostraria que o dono
>> do IP não o autorizou a enviar email de lá. (eu conheço 48 domínios com
>> +all!)i
>>
>> 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, nada é perfeito.
>>
>> 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!
>>
>> Próximos passos:
>> - formalizar o protocolo,
>> - escrever uma librspf ou estender a atual libspf2,
>> - testar para provar que funciona.
>> - escrever a RFC dentro dos padrões do IETF.
>> - vender o peixe.
>>
>> -- Danton.
>> --
>> gter list    https://eng.registro.br/**mailman/listinfo/gter<https://eng.registro.br/mailman/listinfo/gter>
>>
>
> --
> gter list    https://eng.registro.br/**mailman/listinfo/gter<https://eng.registro.br/mailman/listinfo/gter>
>