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. 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 them please? Reco
