Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

From: Jaroslav Kysela <perex@perex.cz>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: Mark Brown <broonie@kernel.org>, Takashi Iwai <tiwai@suse.de>,
	alsa-devel@alsa-project.org,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	sound-open-firmware@alsa-project.org
Subject: Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])
Date: Wed, 10 May 2023 09:50:24 +0200	[thread overview]
Message-ID: <31969101-c1cf-4956-6446-2243ccda0c65@perex.cz> (raw)
In-Reply-To: <20230509-mug-private-mess-6a36d2@meerkat>

On 09. 05. 23 20:22, Konstantin Ryabitsev wrote:
> On Tue, May 09, 2023 at 11:54:18AM +0200, Jaroslav Kysela wrote:
>> The signature is correct in the encapsulated original e-mail. The b4 should
>> be improved in my opinion.
> 
> This is non-fixable. The "mitigations" send messages with a completely
> different message-id, and this breaks pretty much everything. For example, a
> message sent to another list would have the original message-id, but a
> different one if someone retrieves it via the alsa-project subscription. So,
> if someone responds to the message with the bogus rewritten message-id, it
> would be in the wrong place in the thread.
> 
> This is just not usable for patch workflows.
> 
>> For example, here is the original message:
>>
>> https://lore.kernel.org/alsa-devel/168311377075.26.14919941665402646886@mailman-core.alsa-project.org/
> 
> This demonstrates the above problem. This message has a bogus message-id, but
> it sets in-reply-to of the cover letter. Someone sending their reviewed-by
> trailer to this patch would, in fact, send it with the cover letter as the
> parent (meaning it should apply to the entire series).

The tools should be improved IMHO. The capsule contains References: so if 
tools extract the wrapped e-mail to get the original Message-ID:, we're good.

>> I guess that the vger servers have similar issues, because servers with
>> DMARC enabled on the ingress side can reject e-mails. It's related to e-mail
>> standards.
> 
> It is perfectly possible to operate a mailing list server and be
> DMARC-compliant (at least for DKIM-signed messages) without requiring any of
> the horrible things mailman-3 is doing:
> 
> https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html

I wish that it was as easy. I don't see any references to RFCs in this text, 
so we cannot verify the contents. As our mailing list does not modify the 
headers and body, the DKIM is correct for our messages, but it does not work 
practically (the mitigation was turned on recently, so I know how many bounces 
were present).

Also, RFC7960 does not describe this:

https://datatracker.ietf.org/doc/html/rfc7960#section-4.1.3

especially:

https://datatracker.ietf.org/doc/html/rfc7960#section-3.2.3

and see note in:

https://datatracker.ietf.org/doc/html/rfc7960#section-3.2.3.1

So "keep everything unmodified" for DKIM is just only one part of the problem. 
Perhaps, there's a RFC update somewhere which adds another note.

				Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.