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

[Roberto Alcântara]

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


> para evitar que o cliente de acesso que tem bloco menor que /24 tenha que
> implorar alguma coisa para seu provedor a cada domínio que habilite a enviar
> email é o cliente criar seu par de chaves, entregar a pública para seu
> provedor publicá-la no domínio reverso, e assinar tantos registros de
> domínios que quiser, sem ter que implorar pela assinatura do provedor ou
> pela publicação de um registro no reverso a cada novo domínio.

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'

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


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

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.

sds,


- Roberto