DKIM, conhecido como Domain Keys Identified Mail, em português Mail
identificado com Chave de Domínio, é um método de identificar e
autenticar a origem de uma mensagem. A implementação, o uso e
interpretação é voluntário e depende dos entendimentos do dono do
serviço de email, tanto do remetente quanto do destinatário. Importante,
para melhor entendimento aqui, quando falamos de remetente ou
destinatário NÃO referimos ao usuário mas sim ao SERVIDOR SMTP de envio e
recebimento (MTA = Mail Transfer Agent). Este meconismo é um pouco dificil de configurar porque existem muitas informações na Internet, quais eventualmente estão misturadas (domainkey e DKIM) ou os documentos originais RTF interpretados de forma errada ou baseadas em informações ou documentos antigos.
Fato é que Domainkeys é um mecanismos antigo, é o original desenvolvido pelo Yahoo, DKIM é a evolução mais nova e em constante desenvolvimento. Ocorre que, ainda estão trabalhando na forma de avaliar e usar a chave. Dificulta que poucos provedores de serviço usam esse método e ainda menos colaboram com resultados, experiências e sugestões. Esperamos que este artigo esclarece um pouco o assunto, deixa ele mais claro e ajuda a usar uma correta configuração no Brasil que, no final, ajuda a diminuir a quantidade de SPAM que enche nossas (e as suas!) caixas postais.
Resumo explicativo da operação
1. Básico - Email em transito
Sempre existe um MTA, Mail Transfer Agent, que é o servidor de envio e recebimento de mensagens. É o nome que o usuário configura no seu programa de email como servidor de envio, de praxe algo como smtp.dominio.com.br. Este servidor (máquina) está localizado nas instalações do provedor de acesso.
MTA Origem <----> MTA DestinoO pequeno diagrama de cima demonstra o que ocorre. As mensagens estão sendo enviados de um servidor para o outro, o usuário ou a máquina do dono do email nome@dominio.com.br não tem conexão direto como a caixa postal do destinatário final, por exemplo nome@outro_dominio.com.br
Dessa forma, dependendo de quem envia, qualquer MTA num provedor de acesso pode ser remetente ou destinatário.
2. Problema - Origem verdadeira ou não?
É realmente fácil configurar no programa de email um endereço de remetente qualquer. Outras formas de falsificar a origem existem e com emails falsos o interessado pode obter dados ou simplesmente provocar reações não desejados. O sistema DKIM é destinado a combate anti-spam e anti-fraude. Com o uso do mecanismo DKIM os provedores podem reduzir a qauntidade de SPAM e as tentativas de roubo ou estelionato na Internet.
3. Identificar a Origem
O dono do MTA configura o sistema dele para inserir uma chave encriptada e única em cada mensagem de email autentica que seus usuários enviam através dele. Junto a chave ele publica alguns parametros e a política de identificação o que permite ao servidor de destino verificar a chave e tomar medidas de aceitar ou não essa mensagem.
4. Efeito e Política
Caso as medidas estão corretamente implementadas uma relação de confiança pode ser estabelecida entre o montante de MTAs na Internet, onde de um lado o remetente publica uma política de assinatura rigorosa, ou seja, assina todas as mensagens suas - e - de outro lado o destinatário interpreta rigorosamente essa política e aplica-la, ou seja, rejeita ou descarta qualquer mensagem sem a correta assinatura.
5. Quem pode?
Qualquer pessoa que é detentor (dono) de um domínio internet pode usar essa prática. As vezes precisa a ajuda do provedor de serviços onde o domínio está hospedado.
Requisitos do mecanismo
1. Um domínio Internet devidamente cadastrado no registro.brConfiguração do Sistema MTA
2. Um sistema DNS que publica as informações.
3. Um servidor de email (MTA)
4. Um programa de Milter/Filter para inserção e verificação da chave.
5. Opcional um programa anti-spam para classificar as mensagens
No site DKIM.ORG encontra detalhes e referencias específicos para o seu sistema operacional e programa MTA, assim como implemetar no seu sistema.
Para a maioria de sistemas de envio de email (MTA), os mais comuns Sendmail, Postfix, Qmail e outros, existem boas instruções e how-to que podem assistir perfeitamente na instalação e configuração do Milter. Muitas vezes a configuração padrão insere corretamente as chaves nas mensagens, um empreendimento bastante fácil.
A dificuldade encontramos sempre na correta divulgação das chaves com os devidos parametros e especialmente da política e como configurar o serviço DNS.
Configuração DNS, Publicação DKIM
Para poder publicar uma chave precisa gerar essa. A ferramenta para faze-lo é o comando openssl. Precisamos gerar uma chave RSA encriptada com algoritmo de 1024 bits. Existem documentos na Internet indicando 256 ou 512 bits mas essas chaves, a pesar de poderem estar aceitadas no destinatário, não são corretas. O comando é assim:
openssl genrsa -out rsa.private 1024
Gravamos assim a chave num arquivo rsa.private para ser usada depois. Caso quer usar ou ver na tela execute o comando sem ou abre o arquivo.
A chave privada deve estar num lugar seguro no servidor MTA. Crie um diretório, por exemplo /etc/mail/dkim. Limite o acesso a este diretório com
chown root:milter_user_group
e depois com
chmod -R 640
milter_user_group seria o grupo do usuário (GUID) que roda o dkim-milter.
Essa chave privativa está sendo usada pelo programa dkim-milter para gerar a chave de assinatura. A chave privativa nunca está sendo publicada e deve ser mantido em segredo.
Anunciamos com o serviço DNS a chave pública (RSA Pulic Key) e essa geramos da seguinte forma:
openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM
Gravamos assim outro arquivo que contém a chave pública, rsa.public, e essa pode ser divulgada sem problema alguma or ser destinado exatamente ara essa finalidade.
No programa dkim-milter indicamos na configuraçao qual arquivo usar, seguindo neste exemplo, o caminho /etc/mail/dkim/rsa.private como path para a chave privativa. Veja no manual desse programa como fazer
A chave pública, no arquivo rsa.public, tem um contedo semelhante a:
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCwSNEaXsdi
SpUAqbuMskkYHYDGrQAMzIVxWOPLvkKWS8Dx6qCkUvY/sHD5
kctG1uNks5ui7shOoNFjrmILlfZ+u9lnhwPY9EksEiGPhVPj
Cv2zJggBQG7fdPI/kZykV35kgnn2Dm0TodNFbItV/hVQ3bX4
kSneD8kJ5YVWLZlVewIDAQAB
-----END PUBLIC KEY-----
onde a chave é entre as linhas que começam com ----
Essa chave usamos no DNS. Procure não confundir as duas, somente a chave rsa.public funciona e somente essa deve ser usada.
A entrada no seu DNS tem a seguinte sintaxe:
nome._domainkey IN TXT "p=rsa.public;"
E é aqui onde começa a confusão com diversas informações que você encontra na Internet.
Observação: As informações a seguir são corretas e baseiam-se no nosso entendimento e data base de Setembro de 2009. Depende o funcionamento ainda na correta configuração do seu programa dkim-milter e a correta interpretação no destino. Mesmo que não podemos assumir garantia, confirmamos que a configuração a seguir funciona. Em caso de dúvida consulte-nos.
nome é um nome, pode definir livremente o que quiser. Serve apenas para diferenciar caso usa chaves diferentes.A confusão que falei em cima ocorre devido a instruções incorretas de usar outros parâmetros entre as aspas. É confuso, mesmo para administradores experientes, porque existem aqui pequenas diferenças entre DK e DKIM mas o importante é que os parâmetros adicionais estão sendo inseridos pelo seu programa dkim-milter no cabeçalho da mensagem. O sistema DNS serve somente para divulgar a chave pública.
_domainkey é uma palavra chave e deve ser usada exatamente como tal.
IN TXT define a entrada e definição da linha no arquivo DNS do domínio. Deve constar exatamente como tal.
"p=rsa.public;" é o texto a ser publicado. Deve começar com aspas e no fechar com aspas e contém a chave pública que geramos antes. Não deve ser o nome do arquivo, deve conter a chave, começando com p= assim:
p=MIGfMA0GCSqGSIb3DQEBAQUA...5YVWLZlVewIDAQAB;
e observe que termina com ; antes de fechar as aspas. Observe também que deve ser UMA ÚNICA linha e não pode ter quebra de linha na chave. Caso queira usar mais de uma linha consulte o manual do seu servidor DNS para faze-lo corretamente.
Existem apenas dois parâmetros adicionais que podem ser usados aqui. O parâmetro k= pode ser usado para indicar um algoritmo diferente, quando não usa RSA, enquanto usa RSA que é o padrão atualmente, não precisa inserir. O segundo parâmetro seria t= e a única opção que pode ser usada é t=y e significa que este domínio está testando o sistema, sugerindo assim ao destinatário de tomar nenhuma ação de filtragem rejeição ou descarte. É uma opção válida durante os primeiros dias de uso do sistema para conferir e testar mesmo. A entrada completa de exemplo poderia ser assim:
nome._domainkey IN TXT "t=y; p=MIGfMA0GCSqG...;"
Configurado assim, seu servidor DNS divulga corretamente a chave para outros MTAs poderem consulta-la.
Dentro das configurações do seu programa dkim-milter deve definir o nome, chama-se SELECTOR (selecionador) e é necessário. Este nome pode ser qualquer, por exemplo dkim ou nome do seu cachorrinho, tanto faz, apenas deve existir e deve ter um ponto assim nome._domainkey. Lembre, _domainkey é uma palavra chave e deve ser escrita exatamente assim.
Lembre! Não oriente-se e não use qualquer outra opção nessa linha do DNS sob o perigo que a consulta feita por outro MTA falha ou produz resultados incorretos ou não desejados.
Opcional
Caso quer usar DK e DKIM junto, que é válido, publique a mesma linha duas vezes. Use apenas u, SELECTOR (nome) diferente. Mais tarde verá o porque, use por exemplo dk._domainkey .... e dkim._domainkey ....
Agora temos um programa, por exemplo dkim-milter que faz a inserção na mensagem de email e o sistema DNS que publica a nossa chave para consulta. Com estes dados o sistema remoto, aquele que recebe uma mensagem desse domínio e pode marcar ela como suspeita caso a chave está incorreta, não coincide com a publicação pelo DNS ou falta. Fica depois por critério do destinatário, o usuário final, o que fazer com essa mensagem.
Essa política requer que o usuário abre o código fonte de mensagem ou visualiza todos os cabeçalhos dela, portanto um pouco fora da realidade. Por isso divulgamos ainda a nossa política de identificação.
As informações na Internet novamente são confusas ou incompletas. Existem aparentemente três políticas a serem aplicadas. Princípio delas é indicar como ocorre a assinatura dos emails e uma sugestão como proceder no destino com essas mensagens. Definem-se as seguintes opções:
Em SSP e ADSP
< >
A. unknown - o domínio eventualmente assina ou não a sua mensagens.Os nomes das políticas SSP e ADSP aparentemente definem o mesmo, tanto que possuem as mesmas opções, mas SSP é relacionado ao sistema DK e ADSP ao sistema DKIM. São porém palavras chaves e devem ser usadas exatamente assim, _ssp ou _adsp como prefixo para _domainkey. A configuração dessas políticas no DNS deve ser feito assim:
B. all - o domínio assina todas as mensagens, mas deixa por conta do MTA destinatário como proceder.
C. discardable - o domínio assina todas as mensagens e orienta o MTA destinatário para descartar ou rejeitar todas sem ou com incorreta assinatura.
_ssp._domainkey IN TXT "dkim=all"Já sabemos da confusão e como são definições únicas sugiro o uso das duas com a mesma política, all ou discardable, mesmo que usa somente DK ou só DKIM. Não causa dano nenhum e não provoca consultas com erro.
e ou
_adsp._domainkey IN TXT "dkim=discardable"
Em política geral
o=~ mensagens desse domínio podem aparecer sem assinaturaEstes parâmetros pode ser divulgados numa linha de política de assinatura geral que define-se somente com a palavra _domainkey numa linha DNS, sintaxe é:
o=- todas as mensagens desse domínio estão sendo assinadas
t=y política em teste
n=texto um comentário onde texto pode ser uma página na internet fornecendo informações sobre a prática em uso
r=email um endereço de email aonde enviar relatórios de erro caso houver
_domainkey IN TXT "o=-; t=y; r= chefe@dominio.com.br;"
Bom, agora já tratamos de todo, espero que ficou compreensível. Quem tiver dúvidas pode entrar em contato e quem sabe se consigo ajudar. Veja no final mais um exemplo completo de como ficariam as linhas no DNS:
_ssp._domainkey IN TXT "dkim=discardable"
_adsp._domainkey IN TXT "dkim=discardable"
_domainkey IN TXT "o=-; t=y; r= chefe@dominio.com.br;"
dk._domainkey IN TXT "t=y; p=MIGfMA0GCSq...ewIDAQAB;"
dkim._domainkey IN TXT "t=y; p=MIGfMA0GCSq...ewIDAQAB;"
Uma vez concluídos os seus testes pode remover os parâmetros t=y; para que as suas configurações realmente conseguem sucesso. Não esqueça adaptar também no seu programa dkim-milter que aceita as políticas SSP e ADSP sugeridas.
Finalmente acrescento o seguinte, não fiquem com t=y ou com políticas moles. De certa forma então não valeu a pena de fazer todo este trabalho. Implementam o sistema, testem ele e sejam rigorosos. Só assim podemos ganhar o combate anti-spam e aos poucos acabar com a quantidade de fraudes. Lembrem desse detalhe. existe uma proposta de lei que quer responsabilizar o provedor de acesso internet onde o invasor estava conectado quando invadiu a conta de alguém. Para não pagar o prejuízo seja firma e não atende os pedidos dos spammers (sejam eles caseiros o sujeitos mesmos), feche o seu sistema e use o que tiver para proteger o seu investimento e as caixas postais do usuários honestos.
Caso gostaria ajudar na divulgação dessa práticas, linke este artigo no seu website, no seu blog ou onde quiser. Pegue o endereço completo no seu navegador.
Fonte: InfoMatik
http://www.matik.com.br/content/view/59/9/
Links Uteis:
http://www.espcoalition.org/senderid/
DKIM Wizard
http://www.port25.com/support/domainkeysdkim-wizard/
DKIM Wizard:
Create DKIM records for your domain: http://www.port25.com/support/support_dkwz.php
Nenhum comentário:
Postar um comentário