Re: [OT] Regular DKIM issues on this ML (was: Re: why !oh why Debian and application list)
On Fri, Jun 12, 2020 at 04:16:23PM -0400, Michael Stone wrote:
> On Fri, Jun 12, 2020 at 12:36:29PM -0400, Michael Stone wrote:
> > On Fri, Jun 12, 2020 at 09:52:57AM -0400, Michael Stone wrote:
> > > On Fri, Jun 12, 2020 at 03:48:42PM +0200, email@example.com wrote:
> > > > My email below got a DKIM issue.
> > >
> > > It validated fine here, not a debian list issue.
> > For the record, I looked at the wrong email. The right one did fail DKIM validation while passing through debian. (Note that it goes from DKIM_VALID to
> > DKIM_INVALID in what looks like two subsequent checks on bendel.) On my system that one says that it fails dkim because the body was altered. Looking at
> > the body my best guess would be that it's a normalization/line length issue on the part of the dkim signer, but without the original message that's just a
> > guess.
> More information from the OP, it looks like the message sent to the list was base64 encoded html. So I'm guessing that the list software autoconverted that to
> plain text--which would mean there's no way to preserve a valid DKIM signature.
There might be a way. Current OP DKIM policy is (I have no idea why
certain headers are listed twice):
DKIM-Signature: ... h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender;
Removing Content-Type (and maybe Content-Transfer-Encoding) from OP's
DKIM policy should do the trick, although it can has certain undesirable
side-effects if MTA in question is used for other purposes. Of course,
refraining from sending html e-mails here would be easier solution ;)
I'd like to see a headers of this problematic e-mail too. Can you post