Skip to contentSkip to conversation

Emails from kvack.org going into spam

DISCUSSION Jason Gunthorpe 4 participants 5 messages Oct 16, 2020 Memory management

lore
Share & tools
lore
#0 lore raw

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) [email protected] header.s=20161025 header.b=UzPVodG7;
       spf=pass (google.com: domain of [email protected] designates 205.233.56.17 as permitted sender) [email protected];
       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/[email protected]/raw
https://lore.kernel.org/linux-mm/[email protected]/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.

This seems to be a fairly big problem - it is extra hard for people to contribute. Setting up a text based email flow is already hard, but having to also somehow obtain an email address that doesn't use DMARC is becoming an increasingly tough bar to clear.

eg what will people even do if/when Google decides to enable DMARC on gmail.com as well?

Is it possible that this list software can be reconfigured to match the vger lists that do seem to work OK?

Is moving the list to vger an option?

Thanks,
Jason

#1 lore raw
Quoted 1 line · Jason Gunthorpe

Does anyone know who is the admin for kvack.org?

That's Ben. Adding cc.

Quoted 54 lines

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) [email protected] header.s=20161025 header.b=UzPVodG7;
       spf=pass (google.com: domain of [email protected] designates 205.233.56.17 as permitted sender) [email protected];
       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/[email protected]/raw
https://lore.kernel.org/linux-mm/[email protected]/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.

This seems to be a fairly big problem - it is extra hard for people to contribute. Setting up a text based email flow is already hard, but having to also somehow obtain an email address that doesn't use DMARC is becoming an increasingly tough bar to clear.

eg what will people even do if/when Google decides to enable DMARC on gmail.com as well?

Is it possible that this list software can be reconfigured to match the vger lists that do seem to work OK?

Is moving the list to vger an option?

Thanks,
Jason

#2 lore raw
Quoted 4 lines · Matthew Wilcox
Quoted 1 line · Jason Gunthorpe

Does anyone know who is the admin for kvack.org?

That's Ben. Adding cc.

Without suggestions for how to fix the issue, there's not much I can do. majordomo doesn't modify the message body - that was changed years ago to deal with the first round of DKIM breakage. Postfix must be mangling things, but I have no idea how to prevent that. I wish people wouldn't keep coming up with new ways to break mailing lists.

-ben

Quoted 55 lines
Quoted 54 lines

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) [email protected] header.s=20161025 header.b=UzPVodG7;
       spf=pass (google.com: domain of [email protected] designates 205.233.56.17 as permitted sender) [email protected];
       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/[email protected]/raw
https://lore.kernel.org/linux-mm/[email protected]/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.

This seems to be a fairly big problem - it is extra hard for people to contribute. Setting up a text based email flow is already hard, but having to also somehow obtain an email address that doesn't use DMARC is becoming an increasingly tough bar to clear.

eg what will people even do if/when Google decides to enable DMARC on gmail.com as well?

Is it possible that this list software can be reconfigured to match the vger lists that do seem to work OK?

Is moving the list to vger an option?

Thanks,
Jason

Signature · 1 line
"Thought is the essence of where you are now."
#3 lore raw
Quoted 9 lines · Benjamin LaHaise
Quoted 4 lines · Matthew Wilcox
Quoted 1 line · Jason Gunthorpe

Does anyone know who is the admin for kvack.org?

That's Ben. Adding cc.

Without suggestions for how to fix the issue, there's not much I can do. majordomo doesn't modify the message body - that was changed years ago to deal with the first round of DKIM breakage.

First round? I looked some more and it is not just Google senders, but Facebook and others. This is a bug chunk of the major kernel contributing companies effected :(

Quoted 2 lines

Postfix must be mangling things, but I have no idea how to prevent that.

If so, it is probably the hand off from majordomo to postfix is not 8bit clean? Weitse had some guidance on how that works:

http://postfix.1071664.n5.nabble.com/On-DKIM-and-Content-Transfer-Encoding-td68767.html

Seems he confirms that indeed postfix auto downgrades if it is not all done correctly.

The big hammer is to try this:

disable_mime_output_conversion (default: no)
Disable the conversion of 8BITMIME format to 7BIT format. Mime output conversion is needed when the destination does not advertise 8BITMIME support.

This feature is available in Postfix 2.0 and later.

In 2020 I bet you can safely set that to yes. Lots of internet hits related to that config and DKIM breakage with Postfix.

But probably this is an issue with integrating majordomo with postfix, ie it doesn't set the -B8BITMIME when calling sendmail or something? Postfix is sensitive to this, other mailers like exim are not.

Quoted 2 lines

I wish people wouldn't keep coming up with new ways to break mailing lists.

Running mailing lists has always been hard :(

Jason

#4 lore raw
In reply to Jason Gunthorpe
Quoted 31 lines · Jason Gunthorpe

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) [email protected] header.s=20161025 header.b=UzPVodG7;
       spf=pass (google.com: domain of [email protected] designates 205.233.56.17 as permitted sender) [email protected];
       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/[email protected]/raw
https://lore.kernel.org/linux-mm/[email protected]/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.

Quoted 8 lines

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...