Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])
On 09. 05. 23 11:37, Mark Brown wrote:
On Tue, May 09, 2023 at 09:12:55AM +0200, Jaroslav Kysela wrote:
On 08. 05. 23 9:52, Takashi Iwai wrote:
[alsa-devel rewriting mails in a way that renders them useless with b4]
Jaroslav, could you investigate it? I checked again, and it seems that all "approved" posts from non-subscribers are modified to the sender addresses with alsa-project.org. I guess there must be some option to prevent it.
The answer is DMARC. And the "mangling" applies only to senders which domains have restricted DMARC settings (reject or quarantine) - collabora.com has quarantine. More information:
https://lore.kernel.org/alsa-devel/6f003598-4cae-a521-233f-2c19eb439359@pere...
I am open to any suggestions, but the default mailman settings (do not do anything) causes that some (mostly gmail) users do not receive their e-mails because the ALSA's mail server has a bad reputation. Many companies are using the google mail service for their domains nowadays.
The information is not lost - the original e-mail is just encapsulated (as an attachmnent) to new with the "allowed from" header for DMARC. But yes, it requires some more work (reply to the attachment, update scripts).
Copying in Konstantin - as I said this is massively disruptive to using b4 with anything that's been mangled, to the point where the messages are unusable without substantial manual mangling (and signature verification fails too). It'd be more usable to just not have the messages from the list getting to lore and manually bounce patches to the list.
The signature is correct in the encapsulated original e-mail. The b4 should be improved in my opinion.
For example, here is the original message:
https://lore.kernel.org/alsa-devel/168311377075.26.14919941665402646886@mail...
As you see, the header and all signatures are correct in the attachment:
From: AngeloGioacchino Del Regno angelogioacchino.delregno@collabora.com Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key, unprotected) header.d=collabora.com header.i=@collabora.com header.a=rsa-sha256 header.s=mail header.b=HSzFx8Gb
Is it possible to take steps to improve the reptuation of the ALSA servers so this isn't needed, or could we migrate the lists elsewhere (I
It is not possible to talk with gmail administrators. I tried that several times. The outgoing ALSA server is not on any spam list.
know we set up linux-sound@vger at one point with the idea of migrating).
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.
Jaroslav
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).
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
-K
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
On Wed, May 10, 2023 at 09:50:24AM +0200, Jaroslav Kysela wrote:
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.
It is. We've been operating DMARC-compliant mailing lists for many years now without needing to mangle any messages.
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).
Can you please show me the message that was no longer DMARC-compliant after passing through your mailing list server? I will point out what made them non-DMARC-compliant, and it won't be some builtin incompatibility between DMARC and mailing lists.
Also, RFC7960 does not describe this:
https://datatracker.ietf.org/doc/html/rfc7960#section-4.1.3
especially:
These talk specifically about messages that were modified by the mailing list software.
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.
I can demonstrate to you millions of email messages that passed through the mailing list that are still perfectly DMARC compliant -- you seem convinced that it's not possible. For example, here's the authentication header set by GMail for a message that I recently received via the tools mailing list:
Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=YVg2o3VH; spf=pass (google.com: domain of [omitted]@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=[omitted]@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
So, I'm just going to repeat this: operating a mailing list and remaining DMARC compliant is perfectly possible, provided:
- the original message is DKIM-signed - all existing headers are unmodified - the message body is unmodified
-K
On 10. 05. 23 17:34, Konstantin Ryabitsev wrote:
So, I'm just going to repeat this: operating a mailing list and remaining DMARC compliant is perfectly possible, provided:
- the original message is DKIM-signed
- all existing headers are unmodified
- the message body is unmodified
Example of e-mail which is rejected by google's mx servers:
https://lore.kernel.org/alsa-devel/20230510142227.32945-1-vitalyr@opensource...
From the postfix e-mail queue:
https://gist.github.com/perexg/ac06eacd8b3a8f741ef5602ec748e0a8
SMTP error:
reason=host alt1.aspmx.l.google.com[142.251.9.27] said: 550-5.7.26 Unauthenticated email from cirrus.com is not accepted due to domain's 550-5.7.26 DMARC policy. Please contact the administrator of cirrus.com domain 550-5.7.26 if this was a legitimate mail. Please visit 550-5.7.26 https://support.google.com/mail/answer/2451690 to learn about the 450 4.7.26 DMARC initiative. mz11-20020a1709071b8b00b009665976cbddsi3525670ejc.170 - gsmtp (in reply to end of DATA command)
Jaroslav
On Wed, May 10, 2023 at 06:19:15PM +0200, Jaroslav Kysela wrote:
On 10. 05. 23 17:34, Konstantin Ryabitsev wrote:
So, I'm just going to repeat this: operating a mailing list and remaining DMARC compliant is perfectly possible, provided:
- the original message is DKIM-signed
- all existing headers are unmodified
- the message body is unmodified
Example of e-mail which is rejected by google's mx servers:
https://lore.kernel.org/alsa-devel/20230510142227.32945-1-vitalyr@opensource...
Thank you for this example -- it plainly illustrates the problem, which is that Mailman 3 mangles messages.
If you compare the above message with the message that passed via vger, you will notice what went wrong:
-CC: alsa-devel@alsa-project.org, patches@opensource.cirrus.com, - linux-kernel@vger.kernel.org, - Vitaly Rodionov vitalyr@opensource.cirrus.com +CC: alsa-devel@alsa-project.org, patches@opensource.cirrus.com, + linux-kernel@vger.kernel.org, Vitaly Rodionov vitalyr@opensource.cirrus.com
For some bizarre reason Mailman-3 decided to make the CC header "more pretty" by stripping the angle brackets around addresses. Since it's a DKIM-signed header, this invalidates the signature and results in DMARC violations.
The answer, unfortunately, is to stop using Mailman-3. It's not usable for patch-based workflows.
-K
On 10. 05. 23 18:43, Konstantin Ryabitsev wrote:
On Wed, May 10, 2023 at 06:19:15PM +0200, Jaroslav Kysela wrote:
On 10. 05. 23 17:34, Konstantin Ryabitsev wrote:
So, I'm just going to repeat this: operating a mailing list and remaining DMARC compliant is perfectly possible, provided:
- the original message is DKIM-signed
- all existing headers are unmodified
- the message body is unmodified
Example of e-mail which is rejected by google's mx servers:
https://lore.kernel.org/alsa-devel/20230510142227.32945-1-vitalyr@opensource...
Thank you for this example -- it plainly illustrates the problem, which is that Mailman 3 mangles messages.
If you compare the above message with the message that passed via vger, you will notice what went wrong:
-CC: <alsa-devel@alsa-project.org>, <patches@opensource.cirrus.com>, - <linux-kernel@vger.kernel.org>, - Vitaly Rodionov <vitalyr@opensource.cirrus.com> +CC: alsa-devel@alsa-project.org, patches@opensource.cirrus.com, + linux-kernel@vger.kernel.org, Vitaly Rodionov <vitalyr@opensource.cirrus.com>For some bizarre reason Mailman-3 decided to make the CC header "more pretty" by stripping the angle brackets around addresses. Since it's a DKIM-signed header, this invalidates the signature and results in DMARC violations.
The answer, unfortunately, is to stop using Mailman-3. It's not usable for patch-based workflows.
Whoops. It seems that mm3 guys knows about it:
https://gitlab.com/mailman/mailman/-/merge_requests/1039
I tried to apply the noted workaround. Crossing fingers.
Thank you for your help.
Jaroslav
participants (2)
-
Jaroslav Kysela -
Konstantin Ryabitsev