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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
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@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
