[SAC] [postgis-devel] DMARC/DKIM mitigation on maling lists

[Laurențiu Nicola]

On Tue, Oct 31, 2023, at 03:36, Greg Troxel wrote:
> I think the way to debug this is to store both the original message as
> it went to the mailman server and the one as delivered and then diff
> them.  I have had some success guessing at what was munged and finding a
> version that passed, but diff is really vastly easier.

I added more details to https://trac.osgeo.org/osgeo/ticket/3011#comment:7. I'm almost certain the Sender header is to blame.

The Mailman developers discussed it in 2006, but it didn't go anywhere. I don't think DKIM existed in 2006.

> I find it odd for outgoing mail from people to have Sender: as for
> normal human-sent mail, it should just be From:.  And, I would not
> really expect Sender: to be covered by DKIM.

My messages from Fastmail don't have a Sender header, but it's still covered by DKIM so it can't be spoofed. Gmail doesn't include it in DKIM, though.

> I just sent a normal email to another person, and my outgoing DKIM header is
>  h=From:To:Cc:Subject:References:Date:In-Reply-To;

It will depend on the configuration (as we've seen with Gmail), but some people even recommend signing an extra empty header instance, to prevent new ones from being added:

https://serverfault.com/questions/1145777/dkim-signing-duplicate-header-signing-in-dkim-signature/1145782#1145782

There is a discussion in https://datatracker.ietf.org/doc/html/rfc6376#section-5.4.

Specifically, this snippet is non-normative, but it says:

> For this reason, signing fields present in the message such as Date, Subject, Reply-To, Sender, and all MIME header fields are highly advised.

Laurentiu