Re: Emails from kvack.org going into spam

[Jann Horn <jannh@google.com>]

On Fri, Oct 16, 2020 at 3:54 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> Does anyone know who is the admin for kvack.org?
>
> I was cleaning my GMail spam mail box and saw lots of messages from
> Jann Horn in the spam filter. Since he is not a spammer I investigated
> what is going on.
>
> I see it is because GMail is flagging all of Jann's messages as having
> a DKIM failure and Jann's employeer domain 'google.com' is enforcing a
> DMARC policy:
>
> Authentication-Results: mx.google.com;
>        dkim=neutral (body hash did not verify) header.i=@google.com header.s=20161025 header.b=UzPVodG7;
>        spf=pass (google.com: domain of owner-linux-mm@kvack.org designates 205.233.56.17 as permitted sender) smtp.mailfrom=owner-linux-mm@kvack.org;
>        dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=google.com
>
> Selecting a message from Jann that went through LKML and kvack:
>
>   https://lore.kernel.org/lkml/20201015000041.1734214-1-jannh@google.com/raw
>   https://lore.kernel.org/linux-mm/20201015000041.1734214-1-jannh@google.com/raw
>
> And checking the DKIM:
>
>   $ opendkim-testmsg < raw.lkml
>   $ opendkim-testmsg < raw.mm
>   opendkim-testmsg: dkim_eom(): Bad signature
>
> Confirms that Jann sent the message correctly, but kvack is breaking
> the signature while vger is not. The DMARC policy on Jann's email is
> causing receivers to junk his email as spam. I expect I'm not the only
> one.
>
> I see that kvack is modifying the message in transit. Notably it
> changed the transfer encoding from
>  Content-Transfer-Encoding: 8bit
> to
>  Content-Transfer-Encoding: quoted-printable
>
> And mangled the body accordingly. Changing the
> Content-Transfer-Encoding definitely breaks the signature.

Oof... I thought I had solved everything once I had a setup that
didn't break with VGER (which replaces existing "Sender" headers)...

As far as I can tell, 8bit encoding is the default behavior of "git
send-email"? That's what the manpage says...

I guess I can try to work around it for now by changing git's
"sendemail.transferEncoding" from the default "auto" (which uses 8bit
if possible) to "quoted-printable"... but of course it would be nicer
to fix this on the list's side.

I'll try to flip that config flag and resend my most recent patch series...