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