[MASOCH-L] Guerra aos IPs dinâmicos

Bruno Cabral bruno at openline.com.br
Thu Apr 20 11:56:05 BRT 2017


Hum o SPF já não é usado para garantir quem pode enviar? Exigir certificados requer mudanças de cultura, o que não é trivial (IPv6 por ex tem 25 anos e ainda não "pegou")

!3runo
________________________________
De: masoch-l <masoch-l-bounces at eng.registro.br> em nome de Danton Nunes <danton.nunes at inexo.com.br>
Enviado: quinta-feira, 20 de abril de 2017 10:54:49
Para: Mail Aid and Succor, On-line Comfort and Help
Assunto: Re: [MASOCH-L] Guerra aos IPs dinâmicos

On Thu, 20 Apr 2017, Leandro wrote:

>> 1. esqueçam o reverso. não faz parte da cultura IPv6 configurar reverso
>> para todos os endereços. artifícios bonitinhos como geração automática de
>> AAAA e PTR representam mera adição de burocracia.
>>
>
> E acho que o reverso passará a ser amplamente utilizado em servidores de
> e-mail, quando se derem conta do tamanho do problema. Esse é aquele tipo de
> solução que não vem de norma mas sim do pragmatismo.
>
> Se o reverso para servidores pegar mesmo em IPv6, no fundo isso será uma
> espécie de cadastro de MTA, que o Paulo sugeriu.

acredito que um "cadastro" mais confiável pode vir do uso de certificados,
como já se faz na web. hoje praticamente todo transporte de email é feito
sob TLS, então, aproveitimos os certificados envolvidos não só para obter
as chaves, mas também para garantir as identidides dos participantes.

> Vamos aguardar cenas dos próximos capítulos para sabermos quem vai vencer:
> norma ou pragmatismo.

a boa norma vem da prática. reverso não é norma porque causa mais
problemas do que resolve. acompanhe as discussões dos GTs correspondentes
do IETF.

>> 4. procurar critérios que não dependam do IP, e estejam embutidos dentro
>> do próprio protocolo de aplicação ou no transporte. uma ideia que me parece
>> simples é verificar a validade do certificado usado para estabelecer a
>> sessão TLS, quando for o caso, tanto para a MTA que recebe quanto para a
>> que envia! Claro que o spammer pode arranjar um certificado válido, mas aí
>> a CA que o assinou corre o risco de ser declarada não-confiável ou o
>> próprio administrador do lado receptor pode manter uma lista revogação
>> particular.
>>
>
> Exatamente. Esse critério pode ser o domínio de remetente também, além
> disso tudo.

sim, o remetente tem que apresentar um certificado em que o nome do
domínio do remetente (no envelope) seja um CN dentro da parte assinada do
certificado. e o remetente pode verificar se o certificado do destinatário
tem o domínio do destinatário num CN assinado, se for uma entrega final,
isto é, para o MX do domínio. Com isto os dois podem ir dormir sossegados,
quem entregou sabe que entregou para o cara certo, quem recebeu sabe que
recebeu de um MTA autorizado. e isso sem consulta ao DNS e sem ter que
focinhar dentro do conteúdo da mensagem, só com os envelopes e com os
certificados do TLS. No entanto é bom lembrar que TLS é opcional.

note que um procedimento assim já é usado opcionalmente por clientes de
email ao submeter mensagens pela porta 587 com TLS.

creio que este mecanismo teria a mesma função do cadastro já mencionado,
sem a necessidade de uma terceira parte confiável a manter o cadastro.

spams que furassem esta barreira poderiam ser usados para avaliar a
reputação das CAs que assinam os certificados, mudando a pontuação ou
mesmo removendo aquelas que assinam certificados de spammers. além disso
cada administrador poderia ter sua própria lista de certificados revogados
ou uma terceira parte poderia prover tal serviço, mais ou menos como as
listas de bloqueio baseadas em IP atuais.

O DNS poderia ter um papel aqui, porque os certificados poderiam ser
guardados no próprio DNS (veja RFC-4398 e RFC-6944).

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


More information about the masoch-l mailing list