gmail dkim = neutral (sem assinatura)

Question

Depois de testar muito e refazer meus passos, ainda não consigo acessar o Google Mail para validar.

Meu servidor de e-mail é o Debian 5.0 com o exim

Exim version 4.72 #1 built 31-Jul-2010 08:12:17
Copyright (c) University of Cambridge, 1995 - 2007
Berkeley DB: Berkeley DB 4.8.24: (August 14, 2009)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS move_frozen_messages Content_Scanning DKIM Old_Demime
Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
GnuTLS compile-time version: 2.4.2
GnuTLS runtime version: 2.4.2
Configuration file is /var/lib/exim4/config.autogenerated

Minha configuração de transporte SMTP remoto:

remote_smtp:
  debug_print = "T: remote_smtp for $local_part@$domain"
  driver = smtp
  helo_data = mailer.mydomain.com
  dkim_domain = mydomain.com
  dkim_selector = mailer
  dkim_private_key = /etc/exim4/dkim/mailer.mydomain.com.key
  dkim_canon = relaxed

.ifdef REMOTE_SMTP_HOSTS_AVOID_TLS
  hosts_avoid_tls = REMOTE_SMTP_HOSTS_AVOID_TLS
.endif
.ifdef REMOTE_SMTP_HEADERS_REWRITE
  headers_rewrite = REMOTE_SMTP_HEADERS_REWRITE
.endif
.ifdef REMOTE_SMTP_RETURN_PATH
  return_path = REMOTE_SMTP_RETURN_PATH
.endif
.ifdef REMOTE_SMTP_HELO_FROM_DNS
  helo_data=REMOTE_SMTP_HELO_DATA
.endif

O caminho para a minha chave privada está correto.

Eu vejo um cabeçalho DKIM nas minhas mensagens quando elas acabam na minha conta do Gmail:

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mydomain.com; s=mailer;
    h=Content-Type:MIME-Version:Message-ID:Date:Subject:Reply-To:To:From; bh=nKgQAFyGv<snip>tg=;
    b=m84lyYvX6<snip>RBBqmW52m1ce2g=;

No entanto, os cabeçalhos do Gmail sempre reportam dkim = neutral (sem assinatura):

dkim=neutral (no signature) [email protected]

Meus resultados de DNS:

dig +short txt mailer._domainkey.mydomain.com
mailer._domainkey. mydomain.com descriptive text "v=DKIM1\; k=rsa\; t=y\; p=LS0tLS1CRUdJ<snip>M0RRRUJBUVV" "BQTRHTkFEQ0J<snip>GdLamdaaG" "JwaFZkai93b3<snip>laSCtCYmdsYlBrWkdqeVExN3gxN" "mpQTzF6OWJDN3hoY21LNFhaR0NjeENMR0FmOWI4Z<snip>tLQo="

Note que a chave pública base64 tem 364 caracteres, então eu tive que quebrar a chave usando bind9.

$ORIGIN _domainkey. mydomain.com.
mailer                  TXT     ("v=DKIM1; k=rsa; t=y; p=LS0tLS1CRUdJTiBQVUJM<snip>U0liM0RRRUJBUVV"
                                "BQTRHTkFEQ0JpUUtCZ1<snip>15MGdLamdaaG"
                                "JwaFZkai93b3lDK21MR<snip>YlBrWkdqeVExN3gxN"
                                "mpQTzF6OWJDN3hoY21L<snip>Ci0tLS0tRU5E"
                                "IFBVQkxJQyBLRVktLS0tLQo=")

Alguém pode me apontar na direção certa? Eu realmente aprecio isso.

    

Answer 1

Não quebre a chave. Basta adicioná-lo como uma única string. Ele irá wordwrap na maioria dos editores. Minha chave parece com o seguinte.

rsa1._domainkey                 IN      TXT     "v=DKIM1; t=s; p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKq2Ul9a5ixDPQm9WMoPI9fUEZU8FZwfux/O9Sl5+GDCR4rt0CsBzyZj4PY5DTtVHix++EZkR5rVdM4W59DtweKCK6XVntq4Y4GSm+gfZkf/fq45BSCQNilbYux4xqsHQIDAQAB"

Eu não acredito que o DKIM suporte a remontagem de strings. Se você estiver usando um formato de várias linhas, verifique se ele é reagrupado em uma única peça. Se for servido com as cotações extras, provavelmente será interrompido. Sua pesquisa de DNS mostra que esse é o caso.

Em geral, vejo registros SPF aparecendo como "v=spf1" "a" "-all" , que é lido como vspf1a-all . Esse registro deve ser entregue como v=spf1 a -all , mas funcionaria como "v=spf1 " "a " "-all" . O SPF não especifica o suporte para partes citadas concatenando as partes como estão sem introduzir espaços extras. Isso permite que as linhas sejam quebradas no meio da palavra.

EDIT: Estou testando usando uma chave formatada em várias strings. No entanto, precisarei aguardar até as atualizações de DNS. [email protected] me diz que minha nova chave não existe.

O formato que recebo do bind não corresponde ao formato que a documentação me leva a acreditar que devo receber. A documentação indica que eu deveria ver uma única string concatenando os fragmentos que eu inseri. Em vez disso, vejo os fragmentos como inseridos no arquivo de zona.

O teste com ligação indica que os fragmentos de texto podem ter até 255 caracteres. Qualquer coisa além disso precisa ser dividida. Em qualquer caso, dois desses fragmentos provavelmente excederão a capacidade de um pacote UPD.

Uma revisão do RFC indica que um tamanho de chave de 2048 bits é provavelmente o limite prático. Há um aviso para os implementadores de que eles podem ter que lidar com fragmentos TXT e remontá-los em ordem.

    

Answer 2

Você ofusca os dados que são públicos de qualquer maneira, o que não nos ajuda a ajudá-lo.

Por exemplo, não podemos verificar se você atualizou o número de série SOA e que a alteração foi feita em todos os servidores NS e que isso foi feito com um TTL negativo na SOA baixo o suficiente para que o Gmail não seja razoavelmente não vendo dados.

O uso de várias seqüências "..." nos registros TXT do DNS não combina em uma cadeia de caracteres e fornece várias sequências. Cabe então ao aplicativo / protocolo / especificação dizer como lidar com as strings; por exemplo, "junte-se ao espaço entre eles", "junte-se diretamente", "use apenas primeiro".

A especificação DKIM diz para se unir diretamente, mas isso está diretamente no tipo de área que tende a ser negligenciada pelos implementadores. Encorajo-o a fornecer uma string como a única string dentro do registro TXT e ver se isso muda as coisas.

Eu uso o Exim com o DKIM e o Gmail sempre valida; sua configuração do Exim está correta. Então, seu DNS não está visível ou o Gmail não gosta de várias strings no registro TXT.

Você também pode experimentar alguns dos serviços de teste DKIM:

• Serviço de teste de autenticação do remetente < [email protected]>
• [email protected]
• Os três endereços em: link