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 (mailbox.org), 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: spamfilter01.heinlein-hosting.de (amavisd-new); dkim=fail (1024-bit key) reason="fail (bad RSA signature)" header.d=gitlab.haskell.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gitlab.haskell.org; 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 mail._domainkey.gitlab.haskell.org. Running the below: sig=$( printf "%s\n%s\n%s\n" \ R+WMLfhRZZdYxMd6K6w+iodDe8EHzwONNArNyboqsU5NnafPRhKZ1UeGxO/BCMvE \ KM7XHRRrBsPfRYpTph7xSGY427KGXieASVg1GDhAiwKSLBCiqDdkBaoJLLUIfUD0 \ 2NSouI3tvQ9mddNdaEK7retq8N+29hzs/ezf9cpgy+Q= ) pkey=$( dig +short -t txt mail._domainkey.gitlab.haskell.org | 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: 509bfc93a492f1b5328308e51624d9a7ed1378861f577b11413c5034bc0c 673d61660434d4bc30844e7648da0f9605923805973a313a8c3bc82215cc ac447e47551087c544a0592ac3ae48474584bad7d9ca5b850a67493a7977 d28aaa3a9a7580d165dc4f31ff484bdbc40e94a2be1750e71c51c555b5c1 6bc051947bb07ae4 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. -- Viktor.