chave pública DKIM não recuperável

1

Já tive um servidor de email configurado por um bom tempo agora. Tem funcionado bem, todos os principais provedores de e-mail aceitam e-mail do meu servidor sem nenhum problema. No entanto, no momento em que configurei o servidor, também configurei o DKIM e achei que estava funcionando o tempo todo. Eu fui recentemente para mail-tester.com e informou que não poderia recuperar minha chave pública. Ele vê que o cabeçalho DKIM é adicionado corretamente ao email, o que é bom, mas sem a chave pública é obviamente inútil para validação. dig mail._domainkey.website.ca TXT retorna

; <<>> DiG 9.10.3-P4-Ubuntu <<>> mail._domainkey.website.ca TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32970
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mail._domainkey.website.ca. IN TXT

;; ANSWER SECTION:
mail._domainkey.website.ca. 60 IN TXT "v=DKIM1; h=sha256; k=rsa; s=email;" "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDr0rbblJ2j7QrjLC2JGbRHqsU4kr3eNZ7cLL0o1VrR3O966++99SuIqUwwiaTg5lsgYvGuBlN2A5ekJK7Q9pjw5J9+yYY14jx0vxVjfS+kjfqn/tNp5+pHWWnnviZ2b9SIvqg36l/v0bMcPJVM8HuhQLFooz1M2wYi9QoQt5eslwIDAQAB"

;; Query time: 53 msec
;; SERVER: 172.31.0.2#53(172.31.0.2)
;; WHEN: Fri Apr 07 07:38:44 UTC 2017
;; MSG SIZE  rcvd: 331

Então, o que está acontecendo? A entrada está formatada incorretamente? Eu vejo vários exemplos pela web, alguns com aspas, outros sem. Eu tentei de ambas as maneiras agora. Também adicionei a mesma entrada que default._domainkey , mas que talvez ainda não tenha sido propagada pelo DNS. O mesmo servidor também reclamou que meu registro SPF estava presente, mas não foi duplicado como um registro TXT. Isso é prática normal? Por que você precisaria tanto de um SPF quanto de um TXT?

Agradecemos antecipadamente a todos os especialistas do DKIM por aí;)

EDIT: Acabei de verificar que o seletor (o campo s = na seção DKIM dos cabeçalhos de e-mail) está definido como mail. Portanto, mail._domainkey deve ser a entrada correta.

EDIT2: Meu provedor de DNS é CloudFlare.

EDIT3: Acho que posso ter reduzido o problema, mas ainda não tenho ideia de como corrigi-lo. mail-tester.com diz

We were not able to retrieve your public key.
Please ensure that you inserted your DKIM TXT DNS record on your domain mail.website.ca using the selector mail.

Estou pensando que, como o campo d = no cabeçalho é mail.website.ca, ele está realmente tentando encontrar o registro mail._domainkey.mail.website.ca, o que obviamente não existe. Mas como consertar isso? Devo gerar uma nova chave e descartar a parte de email do domínio? Ou devo apenas adicionar outro registro DNS? Estou curioso para saber qual é a melhor prática.

EDIT 4: Tudo bem, parece que o mail-tester.com agora pode ver o registro TXT chamado mail._domainkey.mail, mas ele ainda reclama que a chave pública é inválida. Eu decidi testar meu DKIM enviando um email para outro servidor que eu controlei. Observando os registros, o servidor de e-mail era capaz de obter a chave pública. Tanto o SpamAssassin quanto o OpenDKIM disseram que eles puderam verificar, o que é uma boa notícia (como isso não estava acontecendo antes). Então, pelo menos, resolvi a parte importante do problema. Ainda estou muito curioso para descobrir por que o mail-tester.com ainda está rejeitando o registro TXT (é quase certo que devido à formatação) e estou preocupado que outras implementações do DKIM possam ter o mesmo problema. Vou deixar esta questão na esperança de que alguém possa lançar alguma luz.

    
por Aurelius 07.04.2017 / 09:45

1 resposta

1

O seletor é mail , mas o registro contém s = email . Você não precisa dos campos "s" e "h" no registro. Além disso, as citações de quebra não são necessárias e você pode precisar adicionar um ponto-e-vírgula após a chave:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDr0rbblJ2j7QrjLC2JGbRHqsU4kr3eNZ7cLL0o1VrR3O966++99SuIqUwwiaTg5lsgYvGuBlN2A5ekJK7Q9pjw5J9+yYY14jx0vxVjfS+kjfqn/tNp5+pHWWnnviZ2b9SIvqg36l/v0bMcPJVM8HuhQLFooz1M2wYi9QoQt5eslwIDAQAB;
    
por 26.09.2017 / 11:22