Re: [GIT PULL] 9p update for 5.10-rc7 (restore splice ops)

Re: [GIT PULL] 9p update for 5.10-rc7 (restore splice ops)

[Linus Torvalds]

On Thu, Dec 3, 2020 at 2:33 AM Dominique Martinet
<asmadeus@codewreck.org> wrote:
>
>
> Hi Linus,
>
> Someone just reported splice got disabled in 5.10-rc1, here's a couple
> of patches to turn it back on using generic helpers.

Pulled.

> (Thanks for letting me know my mails got flagged as spam last time, I've
> taken the time to setup dkim/dmarc which brings its share of problems
> with some mailing lists but hopefully will help here)

It looks good here, but I would suggest you edit your DKIM configuration a bit.

In particular, you have "List-ID" in your set of header files that
DKIM hashes, and that means that any mailing list that then adds that
header will destroy your DKIM hash.

So you seem to make it almost intentionally hard for your DKIM to be
valid when you send emails to a list.

I'd suggest you keep the DKIM hash to just the basic fields that your
MUA will fill in, ie things like

  Date:From:To:Cc:Subject:References:In-Reply-To:Message-ID

because if somebody messes with *those*, then I think they are doing
something wrong - in ways that adding a "List-ID" as it goes through a
mailing list is not.

(But I'm not a DKIM expert, just a spam hater).

              Linus

Re: [GIT PULL] 9p update for 5.10-rc7 (restore splice ops)

[Dominique Martinet]

Linus Torvalds wrote on Thu, Dec 03, 2020:
> Pulled.

Thanks!

> > (Thanks for letting me know my mails got flagged as spam last time, I've
> > taken the time to setup dkim/dmarc which brings its share of problems
> > with some mailing lists but hopefully will help here)
> 
> It looks good here, but I would suggest you edit your DKIM configuration a bit.
> 
> In particular, you have "List-ID" in your set of header files that
> DKIM hashes, and that means that any mailing list that then adds that
> header will destroy your DKIM hash.

Hmm, good catch, but that one was on me just now -- I just resent the
mail as I got it through the v9fs list to reuse recipients instead of
the one I had sent before so I did send a bogus list-id, which happened
to get signed.
... looking at list archives it looks like majordomo took that to be a
spam and didn't forward the mail at all, that's a discrete way to sneak
a direct mail without any Cc!
I was about to add it to ignored headers for signing but I'll just have
to be careful about that now. Or figure how to make mutt drop it first.


The problems I had with dkim are all lists that add footers so really
not much to do about header filtering (normally lists would change the
from when they do that or change subject, but for some reason the two
I'm thinking of don't, one of the two even strips dkim headers so even
the body length flag (l=) isn't helping)
I haven't had problems with kernel lists which don't mess with key
headers, good job admins.


Anyway, it's a bit off topic -- good to know new mail didn't go to spam
at least :)
-- 
Dominique

Re: [GIT PULL] 9p update for 5.10-rc7 (restore splice ops)

[Linus Torvalds]

On Thu, Dec 3, 2020 at 2:15 PM Dominique Martinet
<asmadeus@codewreck.org> wrote:
>
> The problems I had with dkim are all lists that add footers so really
> not much to do about header filtering

Yeah, that's obviously always going to be a problem with DKIM.

But I think all the kernel mailing lists are good now - at least
partly because I used to complain about it.

The one thing that vger still does - or at least did not that long ago
- is to change whitespace in headers. But that is perfectly acceptable
SMTP behavior, and it's a problem only when somebody is using
"c=strict/strict" in their DKIM setup. And honestly, that's a
completely invalid DKIM setting, I don't understand how the DKIM
people ever thought it was ok (probably some company politics or other
because some vendor was too incompetent to implement the proper
relaxed hashing).

          Linus