Re: Add printf/scanf -Wformat checking

On 16/10/2025 18:12, Linus Torvalds wrote:
> On Thu, Oct 16, 2025 at 4:04 AM Ben Dooks <[email protected]> wrote:
>>
>> [re-send as I can't type sparse and messages didn't get to the list]
> 
> You may need to re-send again after fixing your mailer setup, because
> while it made it to the list, I suspect a lot of people didn't
> actually get it, because it fails DKIM checks and that then tends to
> mean that it gets marked as spam.
> 
> At least it did for me - but I check my spam folder daily, so I noticed.
> 
> The reason it fails DKIM is that your codethink DKIM setup is scrogged.
> 
> The DKIM message headers look like this:
> 
>    DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
> d=codethink.co.uk; s=imap4-20230908;
> 
> so far, all good. You have DKIM, it uses relaxed/relaxed, all great.
> But then it continues with the list of headers that are hashed:
> 
>    h=Sender:Content-Transfer-Encoding:
> MIME-Version:Message-Id:Date:Subject:To:From:Reply-To:Cc:
> 
> All still good so far, and those are the right headers. But they are
> pretty much the *only* right headers, because the list of headers then
> goes on with
> 
>       Content-Type:
> Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
> Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
> List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
> 
> and that's just bogus.
> 
> Having email list headers in the DKIM header hashing means that any
> well-behaved mailing list that adds its own subscription headers will
> now result in a different hash, and DKIM will fail, and anybody who
> reads the list with a sane MUA will not see the emails you sent.
> 
> So by all means keep the "In-Reply-To" and "References" headers in the
> DKIM list, but get rid of all the "List-Help" etc headers, because
> they are actively wrong and bad.
> 
> I've seen this before, and I have been told that there's some Debian
> DKIM help page for DKIM that lists those headers. I don't know the
> details, but that help page is really actively wrong and should be
> fixed.
> 
> Typically, you should really only list the headers you really care
> about: things that *matter*. Things that make it clear that it was
> from you, and what the subject and thread was.
> 
> Other headers shouldn't be hashed, exactly because there are valid
> reasons why those headers may then be added by intermediate mailers).
> 
> Anyway, what this results in is that when I look at the headers, I see this:
> 
>    ARC-Authentication-Results: i=1; smtp.subspace.kernel.org;
> dmarc=pass (p=reject dis=none) header.from=codethink.co.uk; spf=pass
> smtp.mailfrom=codethink.com; dkim=pass (2048-bit key)
> header.d=codethink.co.uk [email protected] header.b=x51xpGj+;
> arc=none smtp.client-ip=188.40.203.114
>    Authentication-Results: smtp.subspace.kernel.org; dmarc=pass
> (p=reject dis=none) header.from=codethink.co.uk
> 
> ie the list receiver is happy, because at the time the list gets the
> email directly from you, the DKIM hash matches, and so DMARC rules at
> that time say "all good".
> 
> But then when the list re-sends the email out to list subscribers,
> they will get something like this:
> 
>    Authentication-Results: mx.google.com;
>         dkim=fail [email protected] header.s=imap4-20230908
> header.b=x51xpGj+;
> 
> because the list expander has added headers
> 
>    List-Id: <linux-sparse.vger.kernel.org>
>    List-Subscribe: <mailto:[email protected]>
>    List-Unsubscribe: <mailto:[email protected]>
> 
> (and possibly others) so now the header hash no longer matches,
> because you've told dkim to hash those headers. They obviously weren't
> there in your original email, so now the hash that codethink computed
> is no longer matching the headers that the list sends out.
> 
> And this is a well-behaved mailing list that does what mailing lists
> *should* do, in adding those headers. It's really your DKIM that is
> actively wrong.
> 
> If you remember where you got the bad list of headers from, maybe you
> can report this problem upstream too?

So our operations people dug into this, and it looks to be the default
for Debian and possibly the upstream Debian too. From the ticket:
  >    We don't explicitly set dkim_sign_headers in our exim.conf, so 
according to the docs, this defaults to the macro _DKIM_SIGN_HEADERS
>     pulling the source code from the Debian packlage for this, _DKIM_SIGN_HEADERS is set by the macro PDKIM_DEFAULT_SIGN_HEADERS:
> 
> #define PDKIM_DEFAULT_SIGN_HEADERS "From:Sender:Reply-To:Subject:Date:"\
>                              "Message-ID:To:Cc:MIME-Version:Content-Type:"\
>                              "Content-Transfer-Encoding:Content-ID:"\
>                              "Content-Description:Resent-Date:Resent-From:"\
>                              "Resent-Sender:Resent-To:Resent-Cc:"\
>                              "Resent-Message-ID:In-Reply-To:References:"\
>                              "List-Id:List-Help:List-Unsubscribe:"\
>                              "List-Subscribe:List-Post:List-Owner:List-Archive"
> 
> looking upstream @ https://code.exim.org/exim/exim.git - ./src/src/miscmods/pdkim/pdkim.h on the master branch
> 
> #define PDKIM_DEFAULT_SIGN_HEADERS "From:Sender:Reply-To:Subject:Date:"\
>                              "Message-ID:To:Cc:MIME-Version:Content-Type:"\
>                              "Content-Transfer-Encoding:Content-ID:"\
>                              "Content-Description:Resent-Date:Resent-From:"\
>                              "Resent-Sender:Resent-To:Resent-Cc:"\
>                              "Resent-Message-ID:In-Reply-To:References:"\
>                              "List-Id:List-Help:List-Unsubscribe:"\
>                              "List-Subscribe:List-Post:List-Owner:List-Archive"
> 
> So yeah, this is just the default exim config...

I think this is now fixed, will re-send later.


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

https://www.codethink.co.uk/privacy.html