Início / server / Perguntas / 1171804
Accepted
E. K.
Asked: 2025-01-28 18:00:30 +0800 CST

O que causa `dkim=permerror` em todos os e-mails recebidos(!), mas os e-mails enviados são assinados e recebidos normalmente?

  • 772

Quais são as causas potenciais para a configuração de verificação de e-mails recebidos(!) do OpenDKIM dkim=permerrorno Authentication-Resultscabeçalho de cada e-mail recebido? Isso inclui aqueles e-mails que passam se eu os enviar para outra caixa de correio administrada por algum provedor que define dkim=passpara eles. Então eu sei que apenas meu OpenDKIM pensa que esses e-mails de alguma forma não passam, e isso afeta todos os remetentes de todos os lugares.

Estou com dificuldade para encontrar informações na internet sobre as diferentes causas permerrordisso.

E o que poderia fazer com que o motivo exato do erro fosse omitido? Estranhamente, não há parênteses adicionados, o que vejo mencionado na internet às vezes, como permerror (no key), mas meu OpenDKIM não parece fazer isso por algum motivo.

A configuração do OpenDKIM que eu uso é bem curta:

PidFile   /var/run/opendkim/opendkim.pid

SignHeaders   From,Sender,To,CC,Subject,Message-Id,Date

OversignHeaders   From,Sender,To,CC,Subject,Message-Id,Date

AlwaysAddARHeader   yes

Mode   sv

UserID   opendkim

ExternalIgnoreList   <myemaildomain here>, localhost

InternalHosts   <myemaildomain here>

KeyTable   /etc/opendkim/KeyTable.txt

SigningTable   refile:/etc/opendkim/SigningTable.txt

Omiti os arquivos da tabela de chaves e da tabela de assinaturas, pois o e-mail de saída funciona perfeitamente de qualquer maneira. O problema são apenas as verificações do que os outros me enviam.

Embora eu esteja interessado em uma resposta genérica, esta é a versão específica do OpenDKIM que eu uso:

# opendkim -V
opendkim: OpenDKIM Filter v2.11.0
    Compiled with OpenSSL 3.3.2 3 Sep 2024
    SMFI_VERSION 0x1000001
    libmilter version 1.0.1
    Supported signing algorithms:
        rsa-sha1
        rsa-sha256
        ed25519-sha256
    Supported canonicalization algorithms:
        relaxed
        simple
    libopendkim 2.11.0:
email

1 respostas

  1. Best Answer

    A causa é mencionada neste comentário:

    Parece que no meu caso, 8 minutos de desvio de tempo do tempo real causaram essa rejeição em massa. Isso me faz pensar por que, já que certamente alguns minutos não podem causar problemas de expiração de certificado em uma escala maior.

    Não é o certificado, mas a assinatura, que expira. De opendkim.conf(5):

    ClockDrift (inteiro)

    Define a tolerância em segundos a ser aplicada ao determinar se uma assinatura foi expirada ou gerada no futuro. O padrão é 300.

    O desvio de tempo de oito minutos é certamente maior que o valor padrão de cinco minutos.

    Além disso, a assinatura pode declarar sua expiração por meio x=de tag, conforme definido no RFC 6376, 3.5 :

    x=Expiração da assinatura (inteiro decimal sem sinal em texto simples; RECOMENDADO, o padrão é sem expiração). O formato é o mesmo da t=tag, representado como uma data absoluta, não como um delta de tempo do carimbo de data/hora da assinatura. O valor é expresso como um inteiro sem sinal em ASCII decimal, com as mesmas restrições no valor da t=tag. As assinaturas PODEM ser consideradas inválidas se o tempo de verificação no Verificador for posterior à data de expiração. O tempo de verificação deve ser o tempo em que a mensagem foi recebida pela primeira vez no domínio administrativo do Verificador, se esse tempo estiver disponível de forma confiável; caso contrário, o tempo atual deve ser usado. O valor da x=tag DEVE ser maior que o valor da t=tag se ambos estiverem presentes.

    A solução real para esse problema, no entanto, não é aumentar o permitido ClockDrift, mas configurar o servidor de e-mail verificador para manter seu relógio em dia, por exemplo, usando o Network Time Protocol (NTP).

    • 2

relate perguntas