On Fri, Jun 12, 2020 at 11:32:20PM +0300, Reco wrote:
Hi.
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, l0f...@tuta.io 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.
No, the mail should fail because the body has literally changed (all the
html tags are gone).
