DKIM failures for gitlab mail

Viktor Dukhovni ietf-dane at
Wed Nov 30 17:11:48 UTC 2022

On Wed, Nov 30, 2022 at 05:33:44PM +0100, Joachim Breitner wrote:

> I noticed that a small number of Gitlab notification emails end up in
> my spamfilter. While there is not much you can do about triggering some
> bayesian style spam filter at my email provider (, I did
> notice this in the headers:
> X-Spam-Status: No, score=2.704 tagged_above=2 required=6
>         tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HS_RSPAMD_10_11=2.5,
>         HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001,
>         URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
> Authentication-Results: (amavisd-new);
>         dkim=fail (1024-bit key) reason="fail (bad RSA signature)"
> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
>         s=mail; t=1669733134;
>         bh=D0NUcHiskEnwSP99umP3zo8Fz8fl74OgAJ8NRDKCsp4=;
>         h=Date:From:Reply-To:To:In-Reply-To:References:Subject:List-Id:
>          List-Unsubscribe;
>         b=R+WMLfhRZZdYxMd6K6w+iodDe8EHzwONNArNyboqsU5NnafPRhKZ1UeGxO/BCMvEK
>          M7XHRRrBsPfRYpTph7xSGY427KGXieASVg1GDhAiwKSLBCiqDdkBaoJLLUIfUD02NS
>          ouI3tvQ9mddNdaEK7retq8N+29hzs/ezf9cpgy+Q=

Indeed the signature in "b=" was not made by the key at  Running the below:

        printf "%s\n%s\n%s\n" \
            R+WMLfhRZZdYxMd6K6w+iodDe8EHzwONNArNyboqsU5NnafPRhKZ1UeGxO/BCMvE \
            KM7XHRRrBsPfRYpTph7xSGY427KGXieASVg1GDhAiwKSLBCiqDdkBaoJLLUIfUD0 \

        dig +short -t txt |
        perl -MMIME::Base64 -ne '
            /^"v=DKIM1;/ or next;
            print decode_base64($1) if m{;\s*p=(\S+?)(?:;|$)}
            ' |
        openssl pkey -pubin -inform DER

    openssl rsautl -raw -encrypt -pubin \
        -inkey <( printf "%s\n" "$pkey" ) \
        -in <(printf "%s\n" "$sig" | openssl base64 -d) |
        xxd -p

the output is:


Which is not a PKCS#1.5 padded signature block.  So either the
"b=" value was corrupted in transit, or it was signed by a key
that is different from what is published in DNS.

> but maybe Postfix  is not using the right key?

Strictly speaking that's not Postfix itself, but some DKIM milter, but
nits aside, more likely a stale public key is published in DNS.


More information about the ghc-devs mailing list