Os nossos serviços, honorários e produtos estão compatíveis com qualquer porte de empresa. O nosso cliente principal possui uma conexão Internet e uma rede local, ou é, ou pretende montar um provedor de acesso Internet. O nosso objetivo principal é encontrar a solução com melhor relação custo/beneficio para o parceiro. Consulte-nos e pede um orçamento sem compromisso.
Como configurar DKIM e Domainkeys
Matik 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 Destino
O 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 Este endereço de e-mail está sendo protegido de spam, você precisa de Javascript habilitado para vê-lo 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.br

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
Configuração do Sistema MTA

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 voce encontra na Internet.

Observação: As informações a seguir são corretas e baseam-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-nós.

nome é um nome, pode definir livremente o que quiser. Serve apenas para diferenciar caso usa chaves diferentes.
_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.
A confusão que falei encima ocorre devido a instruções incorretas de usar outros parametros entre as aspas. É confuso, mesmo para administradores experientes, porque existem aqui pequenas diferenças entre DK e DKIM mas o importante é que os parametros 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.

Existem apenas dois parametros adicionais que podem ser usados aqui. O paramtro 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 parametro 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.
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.

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:

_ssp._domainkey IN TXT "dkim=all"
e ou
_adsp._domainkey IN TXT "dkim=discardable"
Já sabemos da confusão e como são definições únicas sugero 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.

Em política geral

o=~ mensagens desse domínio podem aparecer sem assintura
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
Estes parametros pode ser divulgados numa linha de política de assinatura geral que define-se somente com a palavra _domainkey numa linha DNS, sintaxe é:

_domainkey IN TXT "o=-; t=y; r= Este endereço de e-mail está sendo protegido de spam, você precisa de Javascript habilitado para vê-lo ;"

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= Este endereço de e-mail está sendo protegido de spam, você precisa de Javascript habilitado para vê-lo ;"
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 parametros 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.

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




- Gerar Código de Link - 10341 Acessos - Imprimir

  Comentários (4)
 1 Enviado por eduardorocha82, em 30/03/2012 18:24
Muito legal o artigo, parabens! 
 
Tenho um servidor de emails que envia emails com "from" de outros dominios (dos meus clientes), e no return-path uso o meu dominio para controlar os retornos. Hoje já tenho um registro de DKIM e assino as mensagens com o DKIM do meu dominio. 
 
Minha dúvida é: 
 
Como uso o "from" com o dominio do meu cliente, o correto seria eu assinar com o DKIM dele? 
 
Pergunto isso, pois quando envio um email para o Gmail, ele valida o dkim como "pass", pois pelo que percebo o gmail usa o dominio do "return-path", e no return-path uso o meu dominio. Agora quando envio para o Yahoo, ele fez duas validacoes, uma baseada no meu dominio que acusa como "pass", e outra baseada no FROM, onde ele acusa como "bad". 
 
Qual seria o correto, já que eu uso o return-path do meu dominio e o from do meu cliente? 
 
Obrigado
 2 Enviado por admin, em 31/03/2012 05:11
A dúvida não é simples para responder porque a parte mais importante vc não informa, o certificado DKIM ... 
O que importa é o parametro d=  
 
DKIM avalia sempre o return-path e não o from, isso porque o from é facilmente "configurável" 
 
Nunca use grandes provedores como referência, todos eles, gmail, hotmail, msn, terra, uol e outros, usam práticas de seu interesse e nenhum deles cumpre as normas de acordo IETFs no pé da letra 
 
também precisa entender, que DKIM apenas certifica que a assinatura é válida ou não, a assinatura não garante legitimidade do remetente 
 
porém, a validade da assinatura DKIM é avaliada a base da informação do DNS do domínio do remetente, se existe ou não ADSP e o indicador d= na assinatura, quando alguma coisa não bate, as assinatura pode ser avaliada como incorreta, essa avaliação final, espacialmente em caso de ausência de ADSP, depende do entendimento do administrador do servidor de destino  
 
Aqui também, representamos a ideia que nenhuma prática de assinatura é válida quando não existe política ou apenas politica vaga. Tanto com DKIM quanto SID/SPF.  
 
Só porque alguém coloca uma assinatura no email podemos assumir que é legitima essa mensagem? Claro que Não.  
 
Igual e mais fácil de entender com SID/SPF, quem tem a "cobrinha" no SPF record, ~all, está de brincadeira ... 
 
Sem DKIM, SPF/SID não temos certeza da legitimidade da msg. Com, mas com política vaga também não. Para que então?  
 
Bom, desculpe o desvio, mas a resposta da sua pergunta é o seguinte, cada um dos seus domínios deveria ter uma assinatura DKIM no DNS do domínio em questão, também deveria ter DKIM ADSP no DNS e cada msg deve ser assinada com o DKIM do domínio. 
 
Você pode testar sua configuração enviando email para Este endereço de e-mail está sendo protegido de spam, você precisa de Javascript habilitado para vê-lo e recebe uma resposta imediata (automática) onde pode analisar os erros ou confirmar o correto cabeçalho da sua mensagem. 
 
 
mas, apesar de ser válido, sabemos muito bem do uso pratico de destintos FROM/RETURN-PATH e essa pratica não é bem vista em servidores de boa reputação.  
 
Você pode resolver essa questão de forma mais inteligente. Por exemplo pode usar um return-address do mesmo domínio (=FROM) e no seu servidor de email vc encaminha a nível MTA a resposta para a conta que quiser.  
 
Assim sua msg fica sem discrepância nos cabeçalhos, mas eventualmente ainda fica se entregando pelo body mas isso já é outra questão. 
 
boa sorte.
 3 Enviado por Este endereço de e-mail está sendo protegido de spam, você precisa de Javascript habilitado para vê-lo , em 24/10/2012 10:44
vc poderia me ajuda implementa esta chave em meu server ? 
estou tendo problemas com hotmail sobre isto no eu ip
 4 Enviado por Este endereço de e-mail está sendo protegido de spam, você precisa de Javascript habilitado para vê-lo , em 28/03/2013 12:47
Intelliencge and simplicity - easy to understand how you think.

Comentar
Seja objetivo, não ofenda e não envie propaganda por favor.
Nome:
E-mail
Comentário:

Código:* Code

 
< Anterior   Próximo >

Enlace de Rádio a Distância
linkMontar um link ou enlace de rádio para grandes distâncias não é nada fácil, mas também nenhum bicho de sete cabeças. Muitos montam as antenas e experimentam. Outros fazem testes de visado com binóculos. O método com binóculo é válido enquanto consegue ver o ponto distante, a partir de 3-4km, inclusive com bons aparelhos, fica complicado. Para não gastar muito tempo e dinheiro por nada precisa de um método mais seguro. Aqui vem a dica para não entrar no desespero.

Artigo inteiro
 


Matik nas Redes Sociais

Infomatik no Facebook Infomatik no Twitter Infomatik no Google+ HPower no Linkedin opiniões Infomatik no Blogger Visite-nos no Orkut Infomatik no Facebook




Buscar no Site


Seja responsável, preserve o Meio Ambiente.
Preserve o Meio Ambiente, evite o uso de papel!

Comentários recentes

Quanto já gastou no seu proved...
Estas informações foi bem esclarecedora para minha pesquisa....
de José Raimundo Nogueira Santos - Ler todo ...

DNS - Como funciona? Master, S...
pode explicar o que tem errado com "O DNS serve" ?
de admin - Ler todo ...

Como configurar SPF?
O Hotmail está recusando meus emails, eu possuo um Cloud na ...
de Marcelo - Ler todo ...

Ser Provedor via Rádio é Ilusã...
Foi mal se não fui muito objetivo, mas faltou uma observa...
de clayton brito - Ler todo ...

Ser Provedor via Rádio é Ilusã...
Olá, Tem um ano que montei um "provedor" via rádio, uso A...
de Clayton Brito - Ler todo ...

Estatisticas

Acessos: 8508894


Integração VoIP Inteligente


Site Tags

255.255.255.252   acesso   alguns   antena   antenas   bom   chave   configuração   dados   das   dkim   dns   domínio   ele   email   endereço   essa   este   estão   existe   fica   freebsd   fácil   hora   isso   mail   mensagem   mensagens   muitos   nos   outro   outros   podem   podemos   porque   porém   programa   quer   rede   rádio   sabe   saber   seja   sendo   servidores   serviço   spam   spf   todas   windows   wireless  

Webmail Login

Nome de Usuário

Senha
Hospedagem Email
Seu Domínio .COM.BR é aqui. Sem rolo, sem propaganda, sem SPAM, sem Vírus, rápido, seguro e confidencial. Com SID e DKIM.
Hospedagem Matik Quer hospedar seu Site WWW, ERP ou CRM? A Matik é o seu lugar!
DNS Outsourcing Seguro, Rápido e com Garantia 24x7. DNSSEC, TSIG, DDNS, rDNS. A sua necessidade na mão de profissionais.
ns_casal.png
AP da Matik (WCE) O único que realmente amarra MAC ao IP. Acabou cloning, até 4 rádios num AP, até 150 clientes em cada rádio, navegando claro. Esquece que já viu.
WIP Cache Boost O único sistema que cumpre a promessa. Full Cache TPROXY de streaming mídia integrado num servidor de controle de banda e muito mais.