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

[Giovane Heleno]

Bom, pensando melhor...

Se for na base da confiança... o rSPF perde seu principal objetivo, que é
validar se o domínio pode sair pelo IP consultado.
Neste caso, o controle passará para o servidor de email, ou faça gerência
da porta 25 nos IPs sem servidores de email e pronto, ou seja... soluções
já existentes.

BCP-20 também cairia na mesma situação... terá que confiar que o seu
cliente não colocará um domínio spammer no rSPF.

Mas pelo menos, especificando o domínio no registro, TXT ou outra forma,
minimizará open relay, servidores mal configurados, etc.

Como o webservice que o Itamar sugeriu... ou um TXT mesmo, com a lista de
dominios que o seu cliente fornecerá.
Algum processo (servidor de dns, script, php, etc) deverá ler esta listagem
e gerar os registros dinâmicamente.
Independente da conclusão que cheguem no formato do registro... SRV, TXT,
com hash, sem hash, etc.

Isso pensando na gerência... depois o papel será do protocolo.

Desculpem se são inadequados no momento os meus questionamentos, é que
também estou pensando com visão de hosting e não somente acesso dono do IP.

Giovane Heleno
www.giovane.pro.br



Em 2 de agosto de 2012 17:35, Giovane Heleno <webgeo at gmail.com> escreveu:

>
> Em 2 de agosto de 2012 10:49, Danton Nunes <danton.nunes at inexo.com.br>escreveu:
>
>  On Wed, 1 Aug 2012, Giovane Heleno wrote:
>>
>>  Ou o dono do IP não tem controle sobre os domínios autorizados a enviar
>>> através daquele IP.
>>> É a mesma problemática com um ponto de vista diferente.
>>>
>>
>> exatamente!
>>
>> o SPF permite ao dono do domínio dizer quais IPs podem enviar. Por que
>> não ouvir também o dono do IP? O protocolo que estou tentando formalizar é
>> um mencanismo para que o dono do IP se manifeste.
>>
>> uma motivação para isso são domínios que atribuem 'pass' para endereços
>> que não tem nada a ver com ele, normalmente para permitir que spambots
>> consigam driblar os 'mata-burros'. então, se tivermos uma segunda
>> verificação, desta vez por conta do dono do IP, esse artifício cairia por
>> terra. outro caso é um provedor de dialup ou adsl, poderia declarar 'fail'
>> para todos os seus endereços de usuário final, de modo que não
>> precisariamos de listas de bloqueio específicas de dialup.
>>
>>
> Entendi a necessidade e o funcionamento...
>
> Fica perfeito em cenários acima de /24, pois a gerência provavelmente será
> ser da mesma entidade administradora do servidor de email.
>
> Se um cliente seu, supomos, de uma empresa de hospedagem, tenha
> 4mil domínios e este número varia diariamente e contrate só um /29 de você.
> Você passaria a gerência do RSPF para o cliente, com um registro NS ou
> equivalente? Como vocês fariam a administração neste cenário?
>
> Ou seja, estou pensando no QUE queremos... escalabilidade para quantidades
> de domínios.
>
> A aplicação ainda está obscura pra mim, e pela forma apresentada, este
> formato de administração, por mais automatizada que seja, será um
> dificultador.
>
> Sei que vão me xingar... kk... mas um +all na base da confiança não seria
> adequado neste cenário?
>
> Se você for transferir a gerência do RDNS para o seu cliente, concorda que
> se baseará na base da confiança da gerência dele?
> Se for na confiança, qual o problema em um +all neste IP, já que você
> confia que o servidor de email deste cliente é bem configurado e seguro
> afim de evitar saída de spam?
>
> Agora, em outros IPs... -all mesmo.. kk
>
>
> Giovane Heleno
> www.giovane.pro.br
>