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

[Danton Nunes]

On Sun, 5 Aug 2012, Roberto Alcântara wrote:

>>> Apenas o detentor do IP possui a chave privada que é o par da pública
>>> que está no TXT do reverso do IP.
>>>
>>> Sendo assim, apenas ele pode assinar as entradas que vão nos TXT dos
>>> domínios e dar o aval para o envio dos e-mails daquele domínio por
>>> aquele IP.
>
>> mas qual é a vantagem disso em relação a pedir para o detentor do IP inserir
>> um registro no .in-addr.arpa ou .ip6.arpa? operacionalmente é a mesma coisa.
>
> Não é a mesma coisa se você adicionar e remove vários domínios com
> frequência nos seus servidores. Para quem não muda realmente não tem
> vantagem.

mas a cada domínio você tem que pedir para assinar. esse é o ponto. tanto 
faz pedir para assinar quanto pedir para inserir um registro no reverso. 
nos dois casos tem que pedir.

a alternativa é o cliente gerar o par de chaves e passar a pública para o 
dono do IP e ele mesmo assinar os registros dos domínios, aí ele tem que 
pedir uma vez só.

mas de qualquer caso temos um problemão: este esquema só serve para 
PERMITIR um par (domínio,IP), não para PROIBIR, e isso é que é mais 
interessante. Por exemplo, um provedor de usuário final pode se interessar 
em dizer para o mundo que ninguém está autorizado a enviar email 
diretamente de qualquer IP do bloco. como se faz isso com esse esquema de 
chave pública?

> Olha o cenário para ver se fica clara a idéia. Acho que ainda não me
> expressei corretamente.
>
> 1. Eu sou provedor e tenho um /29 da operadora e não controlo a zona
> reversa. Uma vez na vida, quando eu recebo o bloco, gero um par de
> chaves (P e K) eu peço para a operadora colocar no TXT do reverso do
> IP a chave publica P. Isso é só uma vez (ou quando a chave
> expirar...).
>
> 2. Todos os dias eu adiciono um domínio no meu servidor de e-mail.
> Logo, para cada domínio que eu adiciono, eu gero uma assinatura
> utilizando K em função do domínio xyz.com e publico esta assinatura no
> TXT de xyz.com.
>
> 3. Nesse TXT pode ter também o PASS, NEUTRAL ou FAIL - que é o que o
> dono da chave *privada* determinou (que é quem recebeu o bloco e está
> assinando).
>
> Ao meu ver,
>
> dominio.com.br  TXT  'rspf [assinatura K(dominio.com.br)]  PASS'
>
> significa a mesma coisa que o
>
> dominio.com.br.A.B.C.D.in-addr.arpa TXT  'rspf PASS'

mas aí teríamos que ter os dois esquemas funcionando simultaneamente, não? 
e nesse caso o resultado deveria ser PASS, NEUTRAL, FAIL ou DELEGATE, com 
a chave pública junto.

> do ponto de vista de dizer qual a política para o dominio.com.br  que
> o "detentor" do IP A.B.C.D determinou, porque na validação os passos
> seriam:
>
> 1. Consulta o reverso do endereço A.B.C.D e pega a chave pública.

ou, consulta o reverso do endereço A.B.C.D e pega o resultado, se for 
DELEGATE pega a chave pública e prossegue, senão, termina.

> 2. Consulta o TXT do dominio.com.br e pega a assinatura
> 3. Se a assinatura estiver ok (isto é, tiver sido gerada pelo par
> privado da chave pública) , a política que o dono das chaves (o
> provedor) determinou para esse dominío é PASS.
>
>
>> seja qual for o algoritmo, o esquema de chave pública tem um defeito muito
>> sério: ele facilita registrar respostas afirmativas, mas não tem uma
>> provisão para respostas negativas! e é exatamente nas respostas negativas
>> que estamos mais interessados.
>> então, seja lá qual for o esquema, com o provedor de IP ou seu cliente
>> assinando respostas, não se presta ao propósito original que é perguntar ao
>> dono do IP se o domínio x pode enviar email a partir desse IP.
>
> Para mim dá no mesmo em relação ao     hash(dominio.com.br).A.B.C.D.in-addr.arpa
>
> O dono do IP na sua visão é a operadora ou o provedor que recebeu o
> /29?  Se for a operadora, realmente não, mas não faz muito sentido - a
> gente tem que saber a 'opinião' do cara que detém o direito de uso
> desse /29, que é o provedor. Neste caso presta ao propósito original
> sim.

o que você chama de operadora, eu chamo de provedor, o que você chama de 
provedor eu chamo de cliente e muita confusão foi criada por essa 
divergência de nomenclatura.

eu entendo que o dono "pra valer" dos IPs é o cara que consta do whois, 
pois é por meio do whois que quem não gostou de receber um spam vai 
encontrar os contatos para reclamação. é usual ao repassar um bloco /29 
por exemplo, cadastrá-lo no whois? não adianta nada fulano autorizar um 
domínio a sair por seu IP mas não responder por esse IP via whois.

>> até agora a melhor idéia para implementar o SPF reverso são registros TXT
>> formados por:
>> 1. hash(domínio),

note que este hash é necessário porque o número de componentes de um 
domínio é limitado em 127.

>> 2. endereço IP invertido,
>> 3. in-addr.arpa ou ip6.arpa.
>> com valor contendo uma parte de identificação do protocolo e uma palavra que
>> pode ser PASS, NEUTRAL ou FAIL.
>> se o interessado tiver um bloco IPv4 menor que /24 terá que implorar para o
>> seu provedor que ou bem delegue no esquema BCP-20 ou insira o registro na
>> zona reversa. ou não fazer nada, o que resultaria em NEUTRAL (a não ser que
>> a política padrão do provedor seja outra).
>
>
> Eu gosto dessa alternativa, mas ela sofre desse problema de quem não
> detém a SOA e está em constante mudança. Simplesmente ignorá-los e
> deixar o NEUTRAL para eles pode limitar a adoção.

essa "constante mudança" eu não entendi. para mim praticamente só spammer 
está em constante mudança. e esses nós queremos mais é que se explodam.

> A outra abordagem com as chaves, apesar de mais cara, resolve este
> problema - eu não entendi porque você acha que não atende ao propósito
> original.

porque facilita a permissão mas não a proibição, ok, agora vi que você 
coloca a possibilidade de FAIL e NEUTRAL, não havia visto isso antes, mas 
ainda não há como definir uma política default para o bloco todo. começo a 
concordar com a idéia, desde que ao passar o bloco o provedor de montante 
ou operadora registre o fato no whois.